Subject: When should mobile nodes use their care-of address, etc...

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 16 Aug 2000 11:23:38 -0700

Hello,

During the last IETF, there was a discussion about when a mobile node
should use its care-of address for communications.  One possible answer
is "never".  Mobile IPv6 was designed to avoid extra signaling overhead
that might result from the use of the home address.  However, if the
mobile node can make the following assertions:

1. No mobility events will occur
2. The other endpoint does not need the mobile node's DNS name
3. The other endpoint is not concerned with the mobile node's
   home address

or, alternatively, if (3), and the mobile node does not expect to
receive any packets from the other endpoint, then it is likely to
be safe for the mobile node to use its care-of address.  These
considerations, by the way, are the same as for IPv4.  Another
interesting factor is what might be meant by (1).  If the layer-2
protocols handle local mobility over a wide enough range, then
there is a corresponding relaxation on how rarely the conditions
might be satisfied.

I claim that it is up to the application to make these determinations,
or else it is up to the context in which the user invokes the
applications.  Sometimes the same application may, or may not, have
requirements for smooth network connectivity in the face of mobility
events.  Anything that is considered a "session" is an example of
something that is likely to fail to satisfy the abovementioned
conditions.

During the IPng meeting, there was a proposal to create a mailing
list for discussion of these issues.  If the mailing list is already
in operation, I'd like to join up.  I hope this message will be
considered relevant.

This whole problem is merely a particular example of a much larger
issue regarding the association of application invocation context
and IP addressability.  For instance, if a user wishes to associate
various "identities" to various IP addresses, then the user might
try to get applications to select IP source addresses that appropriately
express the desired identity to the other endpoint of the application's
communication.  From this point, we "could" devolve into more extended
discussion about the dual role of the IP(v6) address as a way to
encode both an identity and a route.  I do not propose to regurgitate
that entire discussion again, but I do note that it is highly relevant.

Instead, I would like to point out that in particular the use of
anonymous IPv6 addresses has to be considered as something under
the control of the application invoked by the user.  Thus, it is not
realistically possible to specify default source selection rules for
the use of anonymized IPv6 addresses.  Sometimes a user wishes to
be anonymous, and sometimes a user does NOT wish to be anonymous.
I do not think it is appropriate for the network protocol stack to
try to second-guess the user's intentions.

This note is already too long, but there is much more to say.
I look forward to seeing whether others are as interested in these
issues.

Regards,
Charlie P.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Wed, 16 Aug 2000 22:59:29 -0400

Hi Charlie,

This response is not as IETFer but as member of implementation team
working with customers to deploy Mobile IP and with GPRS GSM for now and
eventually ALL-IP and ALL Mobile IP for IPv4 and IPv6 on our platforms.

>mobile node can make the following assertions:

I think "never" is too restrictive a concept pretty much universally
except for death, but definitely invalid for protocol optimizations.

>3. The other endpoint is not concerned with the mobile node's

OK I will take these as assumptions.

>there is a corresponding relaxation on how rarely the conditions

If your last sentence is TRUE which is TRUE for deployment now as best I
can tell the relaxation is clearly OK.  But to sway those to support
this in the standards arena you will need other bullets too once (1) may
in fact occur because of ALL Mobile IP, not that I think we do, I think we
should just do this now and it makes sense but I am getting used to
hanging around and working on stuff just to do what I knew we would do
two years before we could actually do it. (yes it is confusing and so is
the sentence).  So we hopefully can proceeed to work this idea and beat it
until its a dead horse, make it PS, and then the benefit can be practiced.

Another issue is that roaming Cell Phones and PDAs and other handhelds
will not be the only Mobile Nodes.  A LapTop will roam but most likely
will be stationary for longer period of time satisfying (1).  And once
communications is established (2) and (3) are pretty safe bets too.

>something that is likely to fail to satisfy the abovementioned

I suggest its a system parameter on the MN as I hope most
applications do not have to know the inner workings of Mobile IP.
It can be a system parameter that can support individual, group, or
system wide application granularity.  I don't think it should be an API
or 2 Year IETF effort to discuss it and define it and build a camel
instead of a horse.  What has to be done is a simple statement to permit
the behavior as extension to Mobile IPv4 and IPv6.  Clearly this needs
to be defended and discussed, but just the permission of it, and the market
will figure out how to use it.  thank you. 

>in operation, I'd like to join up.  I hope this message will be

Well me or someone on my team would like to join too when its known if it
exists or will exist.

>that entire discussion again, but I do note that it is highly relevant.

I suggest we don't go there.  From past history we will just go in
circles, cause a white paper to be written that does not solve the
problem, and this time we may even have a melt down and loose critical
IETF resources into the ozone.  But its your own trip.  But I have found
Trips on EIDs have been very bad Trips.  In fact you may have a social
responsibility if we could loose IETFers to the ozone to not go
there :----)

>try to second-guess the user's intentions.

I agree 100%.  In fact I will take it further.  I think its a users
right to not believe in this entire privacy issue about IPv6 and decide
to live with the perceived risk (especially on private Intranets).  
Anonymous address processing will cost something on a node that uses them 
and users may not want the interference.  Users rule a the end of the day 
because they pay, and second guessing their intentions is not something
I will ever build as an engineer unless they ask me to.  Most users
assume personal responsbility for their intentions I know, and know the
trade-offs or ask people like me when it comes to networking.

>This note is already too long, but there is much more to say.

Good note though and good idea because if we can send to the
care-of-adress directly it is simply faster and heck to any user faster
is better.

>I look forward to seeing whether others are as interested in these

Count me in Charlie,
thanks
/jim

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Aug 2000 11:24:47 +0200

In your previous mail you wrote:

   During the last IETF, there was a discussion about when a mobile node
   should use its care-of address for communications.

=> yes, I asked for more flexibility in the (source) address selection
mechanism.

   One possible answer is "never".  Mobile IPv6 was designed to avoid
   extra signaling overhead that might result from the use of the home
   address.

=> "never" is the proposed solution in the current draft
(draft-ietf-ipngwg-default-addr-select-01.txt). IMHO a finer control
is needed. The current text is:

   >Rule 5: Prefer home addresses. 
   >If SA is a home address and SB is a care-of address, then prefer SA. 
   >Similarly, if SB is a home address and SA is a care-of address, then 
   >prefer SB. 
   >An implementation MAY support a per-connection configuration 
   >mechanism (for example, a socket option) to reverse the sense of 
   >this preference and prefer care-of addresses over home addresses. 

   However, if the mobile node can make the following assertions:

=> this can be enough to reverse the "never" in "always" but a
per-connection config is not enough. And of course there are many
cases between never and always, like "close enough" to home or
visited network.

   Another interesting factor is what might be meant by (1).

=> there is a good example of (1): the use of mobility for "smart"
nomadism, ie. for instance you have a laptop with an address in
Nokia labs in the Silicon Valley and when you go to Nokia labs
in the New England you'd like to keep this address for receiving
your mail through your prefered MTA, but use the local address for
all other things like printing documents.

=> this is done by the per-connection (ie. socket option) hook.

   applications.

=> then you believe we need more flexibility here too?

=> as far as I know there is no other mailing list than the IPng one
for discussion of these issues. I wrote a proposal and sent it
to authors of the draft. We have done no progress since the end of
the IETF meeting (jetlag + holidays?) but I'd like to resume the
discussion if more work is needed...

=> I have coded a notion of proximity with longest prefix matching
(the one used in routing), is it enough?

=> Rule 7 is as inflexible as rule 5. Is the per-connection (socket option)
hook enough? I believe you'd like to have a per-context (binary) control.

=> I am interested... There are two points I'd like to see explained:
 - add binary choices of rules 5 and 7 in the policy table in order to
   have finer control (note that for rule 5 binary is not enough).
 - what are the proposed granularities for the policy table (only one
   node-global table, an optional table in environment (per user, per
   session, per process-group, ...), ...).
And for the last point what difference between the source and destination
selection (implementations can be done at different layers)? I think
there should be no difference but they are some implementation trade-offs...

Regards

[email-masked]