Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 3 May 2000 00:46:30 +1000

The term "attendant" is used in the AAA draft for IPv6. You might be
thinking of the "MAP" in the HMIPv6 draft.
        Anyway, I don't think this is the right time to discuss extensions
to MIPv6. They should be assessed when the drafts you're referring to are
due for last call. The MIPv6 draft is independent of other proposals for
fast handoff and there is no need to associate it with them at this time.

> Some of the options for fast handover we've been discussing recently may
> call for an FA-like entity in IPv6. I've heard this variously referred
> to as an "attendent". Is the IPv6 mobility draft last call the right
> time to bring up this issue, or should it perhaps wait for a separate
> discussion
> and a separate draft?
>
>

---

From: Roberts Phil-QA3445 <[email-masked]>
Date: Tue, 2 May 2000 09:50:17 -0500

We want to send this draft to the printers so last call is too late for
this.  Subsequent work that's needed should go to separate supplemental
drafts.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, May 02, 2000 9:27 AM
To: [email-masked]
Subject: [MOBILE-IP] IPv6 Mobility Last Call Question

                jak

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 2 May 2000 10:25:46 -0500

James,

The IPV6 Mobility draft is not the place for this concept. I
would defer this to a separate discussion. Right now the key
objective is to get the IPv6 mobility draft through to the
IESG and on standards track.

-Basavaraj

> From: EXT James Kempf [mailto:[email-masked]]
> time to bring up this issue, or should it perhaps wait for a
> separate discussion
> and a separate draft?
>
>                 jak
>

---

From: James Kempf <[email-masked]>
Date: Tue, 2 May 2000 10:29:38 -0700

Hi Charlie,

>The "attendant" function is as described in the AAA requirements
>draft for Mobile IP.
>
>A foreign agent was created to hand out care-of addresses.
>If something does not hand out care-of addresses, I don't
>think it resembles a foreign agent.
>

I was thinking particularly of Pat and my proposal for FA assisted
handoff. This proposal is motivated by a desire to reduce the
requirements on mobile nodes (among other things). Since minimal
terminal involvement in handoff is of interest to the cellular
community, and IPv6 is being recommended as an early deployment
target for telephony, the question came up.

The fast handoff discussion has just started, and therefore it
is probably better to postpone the discussion on support until
it is concluded. But I hope that the fast handoff discusion
will keep IPv6 in mind.

                jak

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 3 May 2000 14:26:14 +0100

> If we use IP4 mobility, that is really just another "tunnel from the ISP
> to
> the home" with a scaling and single point of failure problem at the home
> agent. But if we could use IP6 mobility and treat the device in the
> home/SOHO as the special case of a mobile device which happens to move
> infrequently or not at all, the solution does all the requirements, is
> manageable, and scales fairly nicely. The "care-of router" even serves as
> a
> one-way tunnel for us.
>
>
Fred, I miss the point you are making. Why would a v6
mobility scale better than a v4? OK, you don't have tunnels
most of the time but I'm sure you need to store some info at
home and in the correspondent nodes.
I'm pretty sure I'm missing something,
so please enlighten me.

alessio

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 5 May 2000 02:43:33 +1000

Pete

> I've been thinking about this issue for some time.  I think there
> are good reasons for creating an IPv6 FA, although I'm not sure
> the current IPv6 draft is the right place to do it.
>
        I think something is needed but I don't agree with calling it "FA",
simply because we don't need to have the same functions that FA's do in
MIPv4 transferred to MIPv6.

> I am not saying that an IPv6 FA would serve as a tunnel endpoint,
> but there is definitely a need for some sort of "attendant" function
> and I think integrating that attendant with Mobile IP has advantages.
> Note that the existing IPv6 already requires some sort of entity
> sitting on the visited network to serve as a recipient of Binding
> Updates when handoff takes place.  There is a need to develop a
> security association with that entity at the time the MN first
> registers.  Even if you believe that a PKI will exist I think
> there are good reasons to involve a AAA infrastructure in the
> development of such an association.
>
        Yes I agree in part. AAA is obviously required by operators to have
access control and billing.
        The interworking between AAA and mobility is useful and necessary in
a handoff situation.
        However, that doesn't mean AAA as a function should be part of the
mobility management.
        I think the direction access control has taken in IPv6 is excellent
as it addresses access control as a separate function. Not to say that it
doesn't need to interwork with mobility, but that doesn't make them one
function.

> Such an entity would actually facilitate the kind of "ISP open access"
> that Fred described, rather than hindering it.
        Yes

> It could make sure that all traffic from a given user was tunneled back to
> a home
> network, by integrating the Mobile IP registration process with some
> kind of firewall features.
        Why would you want your traffic to be tunnelled back ?

> Mobile IP then would become the universal
> "dial-tone" for Internet access.  This scenario requires that
> registration requests be sent to an FA rather than directly to an HA,
> which is in conflict with the current definition of MIPv6.
        Again, even if you have an FA-like function in your network why does
that stop you from having two separate registrations, one for your HA and
one for your "new function".

> Remember, in MIPv4, we can set the "R" bit to require FA-routed
> registration even when using a co-located COA.  Maybe some kind
> of registration forwarding can be added to MIPv6.
        I don't see why that would be needed in IPv6

        Hesham

> James Kempf <[email-masked]> (JK) writes:
>
> JK> Some of the options for fast handover we've been discussing
> JK> recently may call for an FA-like entity in IPv6. I've heard this
> JK> variously referred to as an "attendent". Is the IPv6 mobility
> JK> draft last call the right time to bring up this issue, or should
> JK> it perhaps wait for a separate discussion and a separate draft?
>
> JK>                 jak

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 4 May 2000 21:26:25 +0100

>       It could make sure that all traffic from a given user was tunneled
> back to a home
Could attempt an answer: say you own a corporation and have a lot
of employees. It's nice to provide them with corporate net access
when they are on the road, but you don't like 'em to mess too
much with company data and want to enforce the same policies
you usally enforce when they are at home via firewalls.

Well, I would claim all the traffic  from the road warrior
should be controlled and if it is not tunneled back, say it's
forced to take a route back home before (possibly) going
out the internet.

How does MIPv6 support this? That is, does it have this
essential service capability?

thanks

alessio

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 5 May 2000 17:03:49 +1000

> essential service capability?
        Well that is of course a reasonable example.
        If I understand you correctly you're basically talking about being
able to do reverse tunnelling. I don't see why an FA is required for that
purpose. MIPv6 doesn't stop a MN from reverse tunnelling through the home
network. So given that the right policies are configured in the MN, nothing
I know of in the specs would stop that from happening. If I missed something
please let me know

        Hesham

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Fri, 5 May 2000 09:37:03 +0100

> If I understand you correctly you're basically talking about being able to
> do reverse tunnelling. I don't see why an FA is required for that purpose.
> MIPv6 doesn't stop a MN from reverse tunnelling through the home network.
> So given that the right policies are configured in the MN, nothing I know
> of in the specs would stop that from happening. If I missed something
> please let me know
>
>
This may be a solution, but is that part of the MIPv6 spec?
are those policies dependent on the NAI? If so there may be quite
a lot of configuration required on the MN. Also it would be nice it not
to be hardwired. I would suggest that a FA-like (or, not to appear
a v4 bigot, let's call it "care of router", but this is a political name
for foreign agent;)) approach would be better in that policies
are configured dynamically by interaction with AAA.

That is to say that we may do workaraounds, but the V6 equivalent of a
FA would make the thing better. IMHO.

alessio

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 5 May 2000 08:55:33 -0000

>FA would make the thing better. IMHO.

i disagree here. to solve this scenario, you'll also require
ip layer protection from the mn all the way to its corporation
(and perhaps extending into it all the way to the CN).
what we found in rfc2356 was that the only viable way to do
this was precisely to *NOT* use an FA.

perhaps what you want is mipv6+ipsra?

-gabriel

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Sat, 6 May 2000 00:51:10 +1000

> This may be a solution, but is that part of the MIPv6 spec?
        Sure, nothing in the spec stops that scenario as far as I know.

> a lot of configuration required on the MN.
>
        Policies or user profiles will be necessary to configure anyway.
Just look at how much configuration goes on today. I'm not an advocate for
configuration but I think some sort of a "user profile" is essential.

>  Also it would be nice it not
        That is to say that we may do workaraounds, but the V6 equivalent of
a
        FA would make the thing better. IMHO.

        I'm all for a "care of router", in fact we presented a draft in
Adelaide on a very similar concept (hmipv4/v6). I just believe it is needed
for a different reason, and that is fast handoffs. I also agree with you
that an interaction with AAA is an absolute necessity (also mentioned in our
draft) but I wouldn't like to see the two functions getting mixed so that
you would end up needing MIP to exercise access control. An interaction is
great but let's keep them as separate functions.
        Also by keeping "some" policies in the MN we can relief the network
node from the extra processing load => more scalability.  Again I'm not
suggesting letting the MN do everything but some policy enforcement in the
MN might be a good thing.

        Cheers,
        Hesham

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 6 May 2000 14:15:55 +0100

> perhaps what you want is mipv6+ipsra?
This is certainly a solution.

But sometimes the visited operator is trusted. Sometimes IPSEC is
not supported all the way to light weight terminals and still
having a FA (v4) or CoR (V6) may be useful, of course
provided that the serving operator can be trusted (a lot of
businesses, almost every business, rely on trust at a certain stage).

But, most important, if we go down the IPSRA way, the MIP
model is due to change quite a lot:  the home agent will be
most likely always provided by the visited network, which provides
internet access, and a VPN client must be used to access the
corporate net.  So, not allowing for a FA (sorry, CoR) implies
changes in the Mobile IP model when IPv6 is used. Food for thought.

alessio

---

From: Fred Baker <[email-masked]>
Date: Sat, 6 May 2000 11:50:40 -0700

Apologies if this is a duplicate. I seem to have a stuck mail server in San
Jose, and I'm resending some stuff I think may be in it.

At 02:26 PM 5/3/00 +0100, Casati, Alessio (Alessio) wrote:
>Why would a v6 mobility scale better than a v4?

Tell me if I misunderstand.

It is my understanding that in IP4 mobility, every packet goes through the
home agent, while in IP6 mobility, the call is set up through the home
agent but after that packets go directly to the care-of router.

In IP4, the home agent is a single point of failure for every packet going
to the mobile device. In IP6, it is a single point of failure only for
sessions being set up to the mobile device, and presumably if I have
multiple sessions to that device in parallel I could maintain some form of
super-state that knows the care-of router for all of them together.

We're talking at least one order of magnitude (mean session being on the
order of ten packets each direction), probably two (accounting for
aggregated sessions and larger files).

>I'm sure you need to store some info at home and in the correspondent nodes.

Yes, of course - a key aspect of mobility is that it has to know where the
mobile device is *right now*. But how often do you have to use it?

By the way, for the other solutions you also need some form of routing
state. You need to know the addresses you have positioned at the far end of
MPLS tunnels or whatever, and keep that correlation. And like V4 mobility
(if I understand it) the link into the ISP must be as large as all the
traffic that its users need to send at any given time with the routing
solutions. The nice thing I see about IP6 mobility (if I understand it) is
that we use the distributed characteristics of the Internet architecture to
make that link and processing bottleneck not exist.

---

From: Fred Baker <[email-masked]>
Date: Sat, 6 May 2000 11:52:57 -0700

At 11:00 AM 5/4/00 -0500, Pete McCann wrote:
>that Fred described, rather than hindering it.  It could make sure
>that all traffic from a given user was tunneled back to a home

Would that be an objective? I think the user would generally like to be
able to get his address from the ISP and access the services (which he pays
for) that the ISP offers, but in generally he has no desire that his
traffic go through the ISP. If they can go straight to the peer through the
intervening network, and avoid having a single point of failure or
congestion, he's happiest.

---

From: Fred Baker <[email-masked]>
Date: Sat, 6 May 2000 11:53:36 -0700

>forced to take a route back home before (possibly) going

I can imagine some benighted corporation making that rule for its
employees. Are you telling me that because some company might someday be
that obnoxious to its own employees, then that should be fundamental to the
protocol and hobble its scalability for more normal purposes?

I hope you don't quite mean that.

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Sun, 7 May 2000 14:46:36 +1000

Hi Alessio,

>
> I would add to that, that according to MIPv6 the
> correspondent node would not send traffic to
> the corporation after it has received the binding
> update, but to the visited network, and
> as such we have problems. We need to add to the
> spec the option to have CN's always
> send traffic to the HA, I would
> think.

      >The mobile node is not required to send Binding Updates
      >to any correspondent node.  If it does not, the mobile node
      >will get all its traffic from the HA.  The existing text
      >doesn't need to be changed in the regard.

 I think Charlie's answered this above. Just remember that the MIPv6 SW
_will_need_ to be configured. There is no way around that. So this is just
another configuration parameter. This is basically the option you're
referring to. It's a configuration option not a protocol option.

> >  I'm not an advocate for configuration but I think some sort of a "user
> > profile" is essential.
> >
> Yes, but maybe not stored on the mobile node :).
>
>
>          I also agree with you that an interaction with AAA is an absolute
> necessity (also mentioned in our draft) but I wouldn't like to see the two
> functions getting mixed so that you would end up needing MIP to exercise
> access control. An interaction is great but let's keep them as separate
> functions.
>
> AAA does provide useful services and MIP had already
> happened to benefit from them in V4, why not in V6?
>
        I never said there are no benefits for V6. There were two  AAAv6
drafts presented in Adelaide, and I'm sure MIPv6 will benefits from them.
But the great thing about both drafts (in my opinion ) is that they we re
aimed at providing a generic access control mechanism for IPv6. MIPv6 can
certainly interwork with the AAA function and benefit from it, but they
should remain two separate functions. Just like MIPv6 benefits and interacts
with IPsec but they are two separate functions.

> Well, what you may keep in the mobile are a NAI and
> credentials/authentication material.
>
> Policies are enforced by the network.
        Well I slightly disagree ;) I think in future with the existence of
various overlapping access technologies, a user profile might be necessary
and that might be a much more sophisticated one than a simple configuration
command for MIP (which is the case here with reverse tunnelling).

        Hesham

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sun, 7 May 2000 20:10:47 +0100

Hi Charlie

> ----------
> From:         C. Perkins/D. Reese[SMTP:[email-masked]]
> Reply To:     [email-masked]
> Sent:         06 May 2000 18:34
> To:   Casati, Alessio (Alessio)
> Cc:   [email-masked]
> Subject:      Re: [MOBILE-IP] IPv6 Mobility Last Call Question
>
>
> Hello Alessio,
>
Yes, the spec says the MN MAY send a BU.

I would like, at the protocol level, to
force the traffic to be tunneled back to the
corporation, concurrently with disabling sending BUs
to CNs.

In addition, would the WG like to add the
option to let the CoR do reverse tunneling, just
to save radio resources? That is good for V4,
I think that would be even better for V6, as the header
size is quite bigger.

Another item for discussion is:
How much is acceptable for a corporation
that a mobile node uses an IP address topologically
not belonging to the corporate net when sending packets as it is
away from home but still logically part of the corporate
network? Does it make corporate security policies enforcement
more complex? do we have any V6 firewall expert to provide help?

> What do you think about the AAAv6 draft?
>
I think it's good to start defining AAA for V6
network access. I think there are problems with reply protection
that need to be addressed (as already discussed in Adelaide).

I also think that mobile IP could require its own special
things, since I'm not sure that granting network access
would automatically be associated to granting mobility support
services. The allocation of HA may be subject to
authorization? Opinions?

alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sun, 7 May 2000 20:11:44 +0100

> referring to. It's a configuration option not a protocol option.
I would prefer avoiding host configuration if we could have some
flag set in a message back from the HA telling the MIPv6 SW to

-Turn off sending BUs
-Reverse tunnel to the corporate HA

It would avoid much pain with misconfigured hosts
in the future.

alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sun, 7 May 2000 20:15:08 +0100

> ----------
> From:         Fred Baker[SMTP:[email-masked]]
>
Yes, but not always. The binding cache for most of websites
will be quite busy if we would have millions of mobile nodes
hitting them, so the information stored in
web sites binding caches will inevitably be quite volatile.

I would say that MIPv6 implies websites processing thousands of BUs per
second
 and I see a lot of scalability problems (and low
efficiency in sending BUs to CNs such as websites). I could guess
that web sites may be in the business of managing millions of SAs
too, for MIPv6 purposes.

Let me say that V6 appears to have its own peculiar scalability
problems.

> super-state that knows the care-of router for all of them together.
I would claim that V6 home agents should be quite reliable anyway,
and actually need to be up, if you want to use MIPv6.
Recovering from a HA failure will be quite like today
recovering from a NAS failure.
The industry of NASes seems not to be suffering a lot.

Let me also say this is not certainly telling me
V6 scales better.

> aggregated sessions and larger files).
I would say I'm lost on this statement. I don't quite
get what you mean. You don't keep state per (traffic)session, but
per mobile node MIPv6 session. This is like in MIPv4.

> mobile device is *right now*. But how often do you have to use it?
As often as you want to send packets to a mobile node.

> solutions.
I really had to give up on this since I was not
able to recall/understand what are "the other solutions".
Please clarify.

Generally, I could buy scalability arguments If you
showed that V4 is O(n^2) and V6 O(n)
or V4 O(n)and V6 O(log n) where n is the number of users
a HA (and FA for V4, CoR for V6, of course) handles.

alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sun, 7 May 2000 20:20:18 +0100

> ----------
> From:         Fred Baker[SMTP:[email-masked]]
> Reply To:     Fred Baker
> Sent:         06 May 2000 19:53
I mean that when a roadwarrior is accessing the corporate net,
all traffic to and from the Internet must traverse the corporate
firewalls and use corporate proxies to make
enforcement of corporate (security) policies possible. Seems to be quite a
common practice not to want employees access inappropriate
internet resources when on the workplace. I would think also
when they are on the road, if they access the corporate net.

Of course the road warrior may well use other mobile services than
corporate net access to access the Net without having the traffic take
the corporate net route :).

This is to say, we need a protocol option allowing traffic to be tunneled
back to the corporation. This does not mean the protocol in its entirety
is affected, I think.

alessio

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 8 May 2000 10:10:58 +1000

> It would avoid much pain with misconfigured hosts
        Is there any significant SW module that gets installed without
configuration, no matter how little it may be ? If you avoid configuring
this particular option, I can name another half a dozen options that might
need configuration to allow for other special cases like the one you
mentioned. In fact when we implemented MIPv6 we had about 10 options to
configure and I'm sure if we look again we'll find more.
        I don't think everyone of those options should go in the specs. So
IMO you can't avoid host configuration because different users have
different needs.

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 8 May 2000 09:42:47 +0100

> configure and I'm sure if we look again we'll find more.
Well, saying you have to configure something does not mean you are happy to
configure even more. Sounds like a strange statement to me.

alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 8 May 2000 09:48:41 +0100

> Why impose packet-handling of the special case in the general
> case where distributed processing would get better packet handling
> characteristics?
>
Fred, seems like you are assuming I said that to make me appear
on the wrong side. In the non particular case the appropriate scenario
will apply. In the particular case, the particular scenario holds.

We could design quite easily the MIPv6 protocol to help enforce
some policies, versus configuring MN SW.

Anyway, I gave my input, up to the authors making
use of it (if it's worth).

cheers

alessio

---

From: Thomas Eklund <[email-masked]>
Date: Mon, 8 May 2000 11:11:44 +0200

Hi Allessio,

> back to the corporation. This does not mean the protocol in

We already have that option in default today in IPv6 if we use ipsec in
tunneling mode...

You can set up a tunnel from your mobile node to your firewall/router in
your home network...
And you have a IPv6 based VPN....

Regards Thomas

---

From: Thomas Eklund <[email-masked]>
Date: Mon, 8 May 2000 11:22:53 +0200

Hi Fred,
Besides route optimazation that you pointed out - mobile ipv6 can get
scaling benefits out of the hiearchical address architecture that ipv6 have.
And those scaling benefits can be HUGE if you use ipv6 in large networks
like inside a GPRS operator or CDMA2000 operator....
It is also much easier to enforce ingress filtering in the routers in the
vistited subnetworks...
Regards Thomas

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 8 May 2000 11:30:03 +0100

> And you have a IPv6 based VPN....
Perfect, but that is not the Mobile IP model.

that is IPSRA, which gabriel already mentioned.

alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 8 May 2000 11:35:52 +0100

Thom, could you stick to the discussion topics and avoid megastatements
on the virtues of IPv6 (which we are not discussing here).

It seems to me that we have a bunch of people that feel very hurt
when one expresses comments on *V6.

We are here to work on *V6 to make it ready for deployment.

alessio

> ----------
> From:         Thomas Eklund[SMTP:[email-masked]]
> Reply To:     Thomas Eklund
> Sent:         08 May 2000 10:22

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 8 May 2000 11:43:38 +0100

> ----------
> From:         [email-masked][SMTP:[email-masked]]
> Sent:         08 May 2000 11:18
> To:   [email-masked]; [email-masked]
> Subject:      RE: [MOBILE-IP] IPv6 Mobility Last Call Question
>
>
>       Hello,
>
> Actually, since there has been a lot of interest in adding optimized
> routing
> to MIPv4, why would you try to remove it from MIPv6 ??
>
did you read my messages? I would be surprised if you asked to
me this question if you read them.

> The radio resource saving is a general concern, not a MIP specific thing.
> Therefore it should be attacked by using header compression. The FA in
> MIPv4
> is there mainly as an care-of address distributor, which is not needed in
> MIPv6 anymore since we have address autoconfiguration.
>
Good, so tell ROHC to compress IP/IP headers. (I was not ruling
out compression of the user IP packet, after it was stripped off
from the encapsulating header). I'm not sure that we can compress
IPsec stuff, though. Try to check that.

> I'm neither a firewall nor a security gateway expert, but IMHO I think
> this
> is solved by having the Mobile Node apply the corporate security policies
> for every sent and received datagram.
>
Well, I already hear network administrators
having some doubt on this.

> Why not? There is nothing in the visited network that needs to be involved
> in MIPv6. Besides, the MN could be protecting its Binding Updates to the
> HA
> also with ESP, meaning that there is no way for the visited network to
> know
> what the MN is sending anyway.
>
How does this relate to authorization? I miss that.

> I think most of your concerns could be addressed by proper configuration
> of
> Binding Update sending, VPN, header compression, etc. after/prior to the
> MIPv6 stack has been activated.
>
I get suspicious of protocols/systems requiring too much configuration
for them to work properly. But this is only my taste.

alessio

---

From: Thomas Eklund <[email-masked]>
Date: Mon, 8 May 2000 13:43:35 +0200

Hi,

> IPsec stuff, though. Try to check that.
You cant compress an encrypted header or payload...
Because when you do compression you want to compress patterns in your data
that is predictable and in the header of field that are not changing or
fields that change in a controlled manner... If you have an encrypted packet
these pattern dont exist and it is practically impossible to compress...

> having some doubt on this.

This is described in the updated AAAv6 draft - i.e how you dynamically
update your packet and service filters of the authenticated user and the
authorized services....
(it will be re-submitted within a week or so..)

Regards Thomas

---

From: Thomas Eklund <[email-masked]>
Date: Mon, 8 May 2000 13:50:14 +0200

Well I think that the scalable address architechture IS a major difference
compared to v4 which you can take advantage of if you run mobile ipv6...

But to be honest you could achieve the same thing with ipv4 if you re-assign
the whole IPv4 based Internet (and we know that that will never happen) and
handed out the addresses in a hierarchical way and made CIDR and route
agregation mandatory...

Regards Thomas
> > scaling benefits out of the hiearchical address
> architecture that ipv6
> > have.

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 8 May 2000 23:19:17 +1000

> Security and Privacy.
>
> First off, I may know want everyone that I communicate with what my
> current
> geographic position is, and chances are they can get a pretty good idea
> given
> my IP address. So, BU MUST be able to be turned off.
>
        Which is already possible today as the spec is written.

---

From: Thomas Eklund <[email-masked]>
Date: Mon, 8 May 2000 15:18:58 +0200

Hi Pat,
> >
> > > -Turn off sending BUs
> > This option is like saying turn off toute optimazation, but
> why do you want
> > to do that when you have support for it?
> > Even a tiny thin client have enough memory for its CN's....
> Security and Privacy.
>
> First off, I may know want everyone that I communicate with
> what my current
> geographic position is, and chances are they can get a pretty
> good idea given
I dont agree.

In ipv6 you have the address diveded into two parts and it is only of
interest to a "spoofer" what your lower 64 bits are (i.e. your interface id
or EUI-64)..
And there is a draft how you add privacy to the interface part
(http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-01.t
xt*)
That means that you cant be tracked... Eventhough a spoofer sees where the
packets comes from he cant reveil from who it is originated...

In other words there are already a solution to the privacy issue... So the
privacy issue is not an valid for having the BU turned off...

>
> Second, Short of having all of the v6 nodes in the network
> share some secret,
Well my guess is that when you roll out all the SIM card you will have your
shared secret already there and your fixed IPv6 address from your home
ISP...

> or having the promised great unified PKI in the sky, route
> optimization will
> not be used by most clients due to lack of secure
> communication. So, until we
> can all trust each other, BU MUST be able to be turned off.
If you are communicating with a IPv6 CN you know that it has support for
IPsec..
This might be the case in GPRS...
People are discussing to add IPv6 in release 2000 of GPRS and my guess is
that it will be part of that.
Then the operators can use IPv6 inside their private networks today and have
a future proof solution... They can start giving out ipv6 address that are
globaly unique and get all the scaling benefits and get rid of the NAT
related problems with using private IPv4 address...

It should also be noted that Windows_2000 will support IPv6 in the next
release...
> My 2 cents,
> PatC

My 3 cents ...:-)

Regards Thomas

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 May 2000 13:57:35 -0700

---

From: Fred Baker <[email-masked]>
Date: Wed, 3 May 2000 16:07:58 -0700

---

From: Haseeb Akhtar <[email-masked]>
Date: Mon, 8 May 2000 09:57:21 -0500

> agent but after that packets go directly to the care-of router.
        This can be avoided with route optimization added to the IPv4
solution. That is, after the first
        packet, the rest of the packets from the CN will directly go to the
MN's COA.

        Haseeb

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 8 May 2000 18:18:19 +0100

> Furthermore, I strongly suggest that privacy decisions should
> be made depending on the correspondent node.  Some communications
> partners are people we are willing to trust with our location
> information, and some are not.  And, finally, some mobile users
> may be instructed not to trust anyone.
>
>
Charlie,

About location privacy: even if we don't send binding updates,
and even if we don't trust the CN, the CN ill kno enough info
from the link prefix included in the COA.

So, correlating application layer info with the prefix the CN can know
the link we are at.

This even if we have the non prefix info randomly change as we move from
link to link.

Alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 10 May 2000 09:53:18 +0100

> Also, if the employees can't be trusted to this extent we can't solve
> that with technology - it is a social problem that requires social
> solutions.
> (Many companies make statements about the possible effects of violating
> company security policies like connecting an externally accessible modem
> to the desktop allowing people to break in etc)
>
>
This statement is kind of strange, and would really mean that
Mobile IPv6 has not the service capabilities Mobile IPv4
has with reverse tunneling.

Just add to the biding update ACK from the Home Agent a flag to turn off
sending
binding updates to CNs and forcing reverse tunneling,
and we have solved the problem.

Thanks.

alessio

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 May 2000 21:44:14 -0700

Alessio said,
> Erik said:

Sorry, I was reacting to the general thread of discussion (where there
was mention of using MIPv6 technology to enforce corporate policy) and
not to specific suggestions you made.

> and we have solved the problem.

If we want to allow the HA to suggest policy to the MN it would make
sense to add such support.
But there might also be cases where it is the MN that is in control
of the "location privacy policy" i.e. the MN will decide when and to whom
it will send BU and send Home Address options vs. doing reverse tunneling.

  Erik

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 13 May 2000 10:48:31 +0100

> it will send BU and send Home Address options vs. doing reverse tunneling.
Agreed. I would also suggest that it should be clear in
the spec that the HA policy cannot be overridden
by the mobile node, as long as the address (logically)
used by the mobile is the Home Address.

alessio