Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection

From: Samita Chakrabarti <[email-masked]>
Date: Sun, 24 Nov 2002 21:30:41 -0800 (PST)

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

> 
> 
> > -----Original Message-----
> > From: Alper E. YEGIN [mailto:[email-masked]] 
> > Sent: Thursday, November 21, 2002 9:49 PM
> > To: Francis Dupont
> > Cc: Samita Chakrabarti; [email-masked]; 
> > [email-masked]
> > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to 
> > switch default source address selection 
> > 
> > 
> > 
> > 
> > > In your previous mail you wrote:
> > > 
> > >    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.
> > 
> > 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
> > > 
> > > [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: "Alper E. YEGIN" <[email-masked]>
Date: Sat, 30 Nov 2002 14:22:42 -0800

> > We need to ship the base and advanced apis now.

I completely agree.

> extension doc as a guideline for MIPv6 compatible applications.

The default address selection draft contemplates about such an API:

   Implementations should provide a mechanism allowing an application
   to reverse the sense of this preference and prefer care-of addresses
   over home addresses (e.g., via appropriate API extensions). Use of
   the mechanism should only affect the selection rules for the
   invoking application.

I think we should work on a separate Mobile IP API, that can encompass
this and more.

alper