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

From: Richard Draves <[email-masked]>
Date: Wed, 16 Aug 2000 13:00:56 -0700

> 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 look at it slightly differently although the result might be the same. The
mobile node should use its care-of address only if there's a very high
probablility that a movement will not break the application. Either because
the duration of the connection is much shorter than usual inter-movement
time, or because the application can recover from broken connections.

> 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.

Ì agree with this - it should be up to the application. For example, suppose
a mobile node with care-of address CA and home address HA is opening a TCP
connection to a server D. If it's a telnet connection, you presumably want
to use HA. If it's a short-lived HTTP request, you presumably want to use
CA. Note that the mobile node might have both kinds of connections to D
simultaneously. So policies based solely on the addresses involved (D, CA,
HA) will not work.

(One could consider policies that use port number/protocol, like IPsec
policies. The Zhao/Castellucia/Baker paper takes this approach. But
ultimately, it's really application/user knowledge that's needed here.)

> 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.

I haven't heard of such a mailing list.
 
> 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.

I also agree that the use of anonymous addresses should be under the control
of the application. This is why my draft suggests, in both the mobility rule
and the privacy rule, that implementations may support a socket option to
control the preference.

I think a default rule is possible & necessary. For mobility, the default
should be to use the home address so movement will not break connections.
For privacy, the default should be to use the anonymous address. Without
these defaults, in practice there wouldn't be benefit.

Rich
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 17 Aug 2000 13:51:03 +0200

In your previous mail you wrote:

   I look at it slightly differently although the result might be the same. The
   mobile node should use its care-of address only if there's a very high
   probablility that a movement will not break the application.

=> for me if P(movement) = 0 then P(a movement will break the app) = 0
then if (1. No mobility events will occur) then care-of should be used.

   > something that is likely to fail to satisfy the abovementioned
   
   Ì agree with this - it should be up to the application.

=> but your draft doesn't implement what Charlie has written...

   For example, suppose
   
=> then a single global policy table is not enough? I agree.

=> the draft proposes a solution for application knowledge (socket option)
but not user knowledge (or do you suggest to add to every applications
some arguments and code in order to control address selections, I believe
this is not your intent, then clearly your draft needs something...)

=> I believe a socket option is not enough and the control should be done
through the contextual policy table too.

   I think a default rule is possible & necessary.

=> I agree, freedom is not anarchy!
   
[email-masked]

PS: can you explain how the control is done in your implementation?
PPS: perhaps an API for policy table control should be specified??
--------------------------------------------------------------------
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]
--------------------------------------------------------------------