Alper, I agree with you. Src addr sel will address the common case but not the exception and as the draft states it should never overrrule the choice of the application. I can imagine as part of the mobile ip binding lookup additional data structure entries as part of the mobile ipv6 kernel parts. In this manner we would not have to do this in user space and routers could do it as part of its fast path esp for HA. If Samita moves forward with this work we could do all this mostly with socket options too to direct the kernel. And leave the src addr selection of mobile to implementation as should have IPv6 WG.
/jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 21, 2002 1:33 PM > To: Samita Chakrabarti > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Proposal for MIPv6 APIs to switch default source > address selection > > > > Hi Samita, > > > 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. > > 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 > > > > 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 > > > > > > 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 PROTECTED] > > > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > 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 PROTECTED] > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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 PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
