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

From: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Nov 2002 22:17:54 -0500

Alper,

This is a good architecture for an API.  But if Samita and others are
willing to build an API spec for Mobile IP in the IETF using base BSD
sockets that is a good idea.

As far as your comment about src addr selection I don't buy it without
seeing real code. That is why we need this api draft.

/jim
[Honor, Commitment, Integrity]

> -----Original Message-----
> From: Alper E. YEGIN [mailto:[email-masked]] 
> Sent: Thursday, November 21, 2002 9:56 AM
> To: Samita Chakrabarti; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Proposal for MIPv6 APIs to switch default source 
> address selection
> 
> 
> 
> 
> 
> > 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.
> 
> 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
> 
> 
> 
> > 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]
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Nov 2002 22:14:53 -0500

This API should be its own spec and reference other API docs.  This way
the focus of the work would be MIPv6 specific and also not slow down
other API docs in process.

I also think that Francis is correct on the COA issues for src addr
selection.

/jim

> From: Francis Dupont [mailto:[email-masked]] 
> Sent: Thursday, November 21, 2002 9:40 AM
> To: Samita Chakrabarti
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
>  In your previous mail you wrote:
> 
>    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: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Nov 2002 22:23:40 -0500

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

> Sent: Thursday, November 21, 2002 1:33 PM
> To: Samita Chakrabarti
> Cc: [email-masked]; [email-masked]
> > 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 ?
> > > >
> document,
> > > > as they are quite Mobile IP specific in usage.
> > > >
> > > > -Samita
> > > >
> > > > 
> > > >        useful for short-term communication that may 
> easily be retried
> > > > queries
> will
> > > >        no particular knowledge that the communication 
> being sent fits
> > > >        within this general type of communication, 
> however, the mobile
> > > >        While not at its home link, the mobile node MUST NOT use 
> > > > its
> home
> > > >        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

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Nov 2002 22:26:08 -0500

Francis,

What you did would work with what I stated too.  After the kernel gets
done the getsockname could send back all data but I think we would need
a new api and options to the kernel?

/jim

> Sent: Thursday, November 21, 2002 6:15 PM
> To: Alper E. YEGIN
> Cc: Samita Chakrabarti; [email-masked]; 
> [email-masked]
> Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to 
> switch default source address selection 
> 
> 
>    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.
>    
> => 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: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Nov 2002 22:30:39 -0500

Alper,

OK I was behind you folks are going where I would go.  I would assume
bind-update will update the correct topological one to use in the kernel
that way the app does not have to be smart unless it wants too using a
new api as you suggest.  This way apps don't have to change as we begin
to deploy mipv6.

I would suggest strongly we just have a good api draft and leave the
rest to implementors and not try to parse this in the ietf and we all
are not going to agree how we do stuff in our kernels anyway and we
don't get into a 2 year debate like src addr sel.

A simple api ext doc would be great.  But not part of the advanced api.
We need to ship the base and advanced apis now.

/jim

> Sent: Thursday, November 21, 2002 9:49 PM
> To: Francis Dupont
> >    the source address, it can use the Mobile IP API to 
> figure out which
> >    explicitly "bind" the socket to the desired address. 
> IMO, this would
> not enough, 
> > the best is to give the home address and the care-of address for 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,
> > I added a clone of getsockname() which returns the real 
> source address 
> > after MIPv6 processing.
> 
> 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
> 
> > 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: Samita Chakrabarti <[email-masked]>
Date: Sun, 24 Nov 2002 20:59:15 -0800 (PST)

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

Yes, the applications need to change to accomodate MobileIP. The goal
should be to change them minimally. Thus a API would help in this case,
as it may turn the knob to tell the kernel which address to use instead
of a default address. The application may not need to specify the exact
COA, the kernel can choose the correct one corresponding to the default
homeaddress ( assuming application has knowledge about the correct home
address). This will be useful for multi-homed mobile nodes as well.
 
>    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...
> 

It will not be desirable to restart common applications upon movement,
however small their numbers may be.
Then we will loose essence of MobileIP.

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

I don't know how many apps fall in this category, may be we should think
about that. Off the top of my head, they could be dns-client, printer-client,
or any application that requests service discovery in the local network.

-Samita

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 25 Nov 2002 00:08:04 -0500

Just as note thus far with mipv6 testing and technology interoperation
with other mipv6 vendors not one application has had to be altered to
support mipv6 (e.g. ftp, telnet, streaming video/audio, sip, and a few
others).   Clearly they had to be ported to IPv6 but nothing special was
done for mipv6.  The above statement is for the server, router, and
handhelds we are testing with at this time and putting in test labs
deploying IPv6 in test beds. I don't see draft 19 from draft 18 as big
deal either.

But I can see optimizations per Samita's comments below helping with
very fast movement, and having socket options to set to affect that
movement is quite smart and someone should proceed with the work (I
can't to much IETF work now sorry).

/jim
[A people who would give up their freedom out of fear did not deserve it
in the first place. Ben Franklin]

> From: Samita Chakrabarti [mailto:[email-masked]] 
> Sent: Sunday, November 24, 2002 11:59 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > => 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.
> >
> 
> Yes, the applications need to change to accomodate MobileIP. 
> The goal should be to change them minimally. Thus a API would 
> help in this case, as it may turn the knob to tell the kernel 
> which address to use instead of a default address. The 
> application may not need to specify the exact COA, the kernel 
> can choose the correct one corresponding to the default 
> homeaddress ( assuming application has knowledge about the 
> correct home address). This will be useful for multi-homed 
> mobile nodes as well.
>  
> > => 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...
> > 
> 
> 
> It will not be desirable to restart common applications upon 
> movement, however small their numbers may be. Then we will 
> loose essence of MobileIP.
> 
> I don't know how many apps fall in this category, may be we 
> should think about that. Off the top of my head, they could 
> be dns-client, printer-client, or any application that 
> requests service discovery in the local network.
> 
> -Samita
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 25 Nov 2002 11:42:26 -0500

Ahhhh.  OK.  Now I see. Don't do client stuff so did not see that.
Thanks.

/jim

> Sent: Monday, November 25, 2002 12:31 AM
> To: Bound, Jim
> Cc: [email-masked]; 
> [email-masked]; [email-masked]; 
> Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to 
> > A simple api ext doc would be great.  But not part of the advanced 
> > api. We need to ship the base and advanced apis now.
> > 
> 
> That's what I was aiming for; a short and simple advanced api 
> socket extension doc as a guideline for MIPv6 compatible applications.
> 
> I agree that the server side apps do not require change, but 
> some client side apps should change (like dns-client, 
> printer-client etc.) so that they don't have to send packets 
> all the way to the home-agent for doing the local job.
> 
> Thanks for your comments.
> -Samita
> 
> > 
> >