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