Subject: Proposal for MIPv6 APIs to switch default source address selection

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 20 Nov 2002 20:53:47 -0800

I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
document. The following requirements in MIPv6 spec indicates that there
is a need for Socket API which will allow the MIPv6 applications to
choose
COA as mobile node's source address (in a visited network), while
default
address selection draft prefers home address as the default source
address
(section 5 and 6 rule 4). The  MIPV6 API should also take care of
choosing 
temporary address and non-temporary address from the application level.
Also, there is a need to choose link-local or site-local address as
source
address (depending on the scope) for the MN while visiting (see below).

My question is, if anybody in IPv6 working group is currently working on
such
API for default address selection draft ?

If not, I propose to add these APIs to the MIPv6 Advanced API document,
as they are quite Mobile IP specific in usage.

-Samita

--------------------------------------------------------------------

 Mobile IPv6 draft 19 Section 11.3.1  states,   

       The mobile node MAY choose to directly use one of its care-of
       addresses as the source of the packet, not requiring the use
       of a Home Address option in the packet.  This is particularly
       useful for short-term communication that may easily be retried
       if it fails.  An example of this type of communication might
       be DNS queries sent by the mobile node [27, 28].  Using the
       mobile node's care-of address as the source for such queries will
       generally have a lower overhead than using the mobile node's
       home address, since no extra options need be used in either
       the query or its reply.  Such packets can be routed normally,
       directly between their source and destination without relying
       on Mobile IPv6.  If application running on the mobile node has
       no particular knowledge that the communication being sent fits
       within this general type of communication, however, the mobile
       node SHOULD NOT use its care-of address as the source of the
       packet in this way.

       :  :    :

       While not at its home link, the mobile node MUST NOT use its home
       address (or the home address destination option) in Neighbor
       Discovery messages on the visited link.  The mobile node also
       MUST NOT use its home address when communicating with link-local
       or site-local peers on the visited link, if the scope of the home
       address is larger than the scope of the peer's address.
--------------------------------------------------------------------
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: Samita Chakrabarti <[email-masked]>
Date: Wed, 20 Nov 2002 21:16:06 -0800

YOSHIFUJI Hideaki / 吉藤英明 wrote:
> 
> In article <[email-masked]> (at Wed, 20 Nov 2002 20:53:47 -0800), Samita Chakrabarti <[email-masked]> says:
> 
> I believe they should be handled by ipv6wg if the document contains
> temporary address vs public address and/or scope preferences.
> 

One alternative has been suggested that initially they could be written
into the MIPv6 Adv-API
document which perhaps can be folded into future IPv6 ADV-API RFC. I
agree that the APIs to
switch source address selection would be useful for non-MIPv6 cases as
well.

Thanks for your input.
-Samita

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Nov 2002 15:40:16 +0100

In your previous mail you wrote:

   I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
   document. The following requirements in MIPv6 spec indicates that there
   is a need for Socket API which will allow the MIPv6 applications to
   choose COA as mobile node's source address...

=> the problem of this API is that it is not useful because nobody wants
to change all applications to use it. So we need also a way to change
the choice (or better, to choose in a clever way, for instance using
the "distance" between the CoA prefix and the destination address)
from the context of applications. I suggest this many times but
it was rejected by address selection document author as out of the
scope of the document... (this is one of the reasons I still believe to
put the document on the standard track is an error).

Thanks

[email-masked]

PS: we have to do the same thing for every rules not using the preference
table.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 21 Nov 2002 06:56:03 -0800

> temporary address and non-temporary address from the application level.

Hi Samita,

Please see our Mobile IP API draft:

http://www.ietf.org/internet-drafts/draft-yokote-mobileip-api-01.txt

It allows the user of the API to determine home addresses and the
corresponding
care-of addresses used on the host. Than, it's the application's choice
to pick one of them. It can make an appropriate decision by using
this knowledge.

I think this selection logic should reside in the application, not
below. So, I'm not sure if this really relates to
draft-ietf-ipv6-default-addr-select draft.

alper

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 21 Nov 2002 07:50:26 -0800

> to change all applications to use it. So we need also a way to change

I am not sure why you are saying that all applications needs to change
for this.
In general applications may not need to change as by default they will
use the default
address selection mechanism set by the IPv6 kernel. But for MobileIP
situation it is
necessary  for apps to use homeaddr in most situations, but they need to
use COA
for local cases in the visited link. I don't think those specific apps
for MIPv6 exist
today and some existing apps  would have to be modified or written for
MIPv6 anyway.

> PS: we have to do the same thing for every rules not using the preference

Yes, it's a generic IPv6 socket advanced socket API for which mobileip
has obvious usage.

-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 21 Nov 2002 08:08:04 -0800

Hello Alper,

> http://www.ietf.org/internet-drafts/draft-yokote-mobileip-api-01.txt

I did take a look at the draft that you folks have for mobile IP
applications. 

That draft gives a general overview of mobile application usage, but I
am
addressing a different scope (which is more equivalent to having an
extension
to IPv6 advanced Socket API document for Mobile IP). The mobileip socket
applications
will use those Advanced socket APIs(which I am proposing) to change to
default behavior in the kernel.
Moreover, a socket api to switch the default source address selection
would be
useful in general(I am happy to see that in Bob Hinden's slides in the
ipng
meeting today as well).

draft-yokote-mobileip-api-01.txt, IMO, provides guideline for the
generic MobileIP
specific application level APIs, which is in a different scope than
Advanced socket APIs
that are perceived from the current rfc2292bis.

-Samita

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 21 Nov 2002 10:32:54 -0800

Hi Samita,

> default behavior in the kernel.

An alternative approach could be: If the application cares about
the source address, it can use the Mobile IP API to figure out which
ones are home address, which ones are care-of address, and than
explicitly "bind" the socket to the desired address. IMO, this would
also satisfy the needs of the Mobile IPv6 mobile node.

alper

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Wed, 20 Nov 2002 23:59:12 -0500 (EST)

--yoshfuji

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Nov 2002 23:39:45 +0100

=> in order to use the API, an application needs to be changed.
So with only the API, the only way to influence the Co@/H@ choice
is to change all common applications... So the API will get only
very limited use and the smart user should still wait for a device
to fulfill his needs.

   they need to use COA for local cases in the visited link.

=> yes, all the short term not bound to the home applications
could like to use a Co@. There are a lot of situations where
to get communications killed by movements is not a problem...

   some existing apps  would have to be modified or written for
   MIPv6 anyway.
   
=> we have to keep the number of such applications as low as possible.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Nov 2002 00:14:46 +0100

=> this is similar to what I implemented in the past.
But a function giving the list of addresses with status is not enough,
the best is to give the home address and the care-of address for
a destination. As first info is getsockname() for bound sockets,
I added a clone of getsockname() which returns the real source
address after MIPv6 processing.
Note this doesn't solve the need of a control for smarter choice
between Co@/H@. I proposed some and implemented two: use always
the H@ and use it but a Co@ when the destination is in the same
link then a Co@. They were global (still better than none :-).

Thanks

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 21 Nov 2002 18:48:46 -0800

> a destination. 

I see. When the mobile node has more than one pair of 
home_address-care_of_address, then it won't really know which
one to pick. So, maybe, instead of exporting all this information
to the apps and giving them the control, it might be better 
to enable the app to say "bind this socket to any address, preferably
topologically correct (i.e., a CoA, or home address when at home)".
I suspect this is what Samita had in her mind.. 

> As first info is getsockname() for bound sockets,

Or, don't change the getsockname(), but instead call 
mip_get_one_mobile_node() afterwards to identify if the address is bound
to a care-of address. Note that this binding can dynamically any time,
and subsequent mip_get_one_mobile_node() calls are sufficient to capture
the changes.

alper

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Nov 2002 04:35:43 +0100

=> not, my idea is as the application cares about the source,
connect a socket to the destination and look at the source selected
by the kernel. For mobility I add look at the real source selected
(i.e., a Co@), not only the visible source (i.e., the H@).
Note that all applications using raw sockets have to setup themselves
the source so this kind of code is not uncommon.

   > address after MIPv6 processing.
   
   Or, don't change the getsockname(),

=> I didn't change it: it still returned the bound address, i.e.,
the H@ on a MN.

   but instead call mip_get_one_mobile_node() afterwards to identify
   if the address is bound to a care-of address.

=> the address is not bound to a Co@ but the BC lookup will push
the bound address (the H@) to a H@O and a Co@ will replace it
at the source (in the IPv6 header). The function should simulate
the MIPv6 processing (aka BC lookup) and return its result on
the source address.

   Note that this binding can dynamically any time,
   and subsequent mip_get_one_mobile_node() calls are sufficient to capture
   the changes.
   
=> yes, the result of this function should not be cached.

Thanks