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

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 2 Dec 2002 10:52:25 -0800 (PST)

> > That's what I was aiming for; a short and simple advanced api socket
> > 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.

Let me work a draft for MIPv6 adv-API extension. If you're thinking about
the draft you folks already have, then as I mentioned before, that is in
a different scope and perhaps it can address some of the mobileIP application
level guidelines. I don't see a reason a why we need to have a single document
which encompasses advanced socket APIs and application level APIs.

Also, we would like to see some more comments on the list from folks that
have not participated on this discussion yet, but have an opinion about it.

Thanks,
-Samita

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

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 2 Dec 2002 11:02:39 -0700

We are actually planning on having 2 completely separate interfaces in the
Mobile Node (when the MN is away from home):

1) virtual home interface (addresses are auto-configured on this interface
using Home Prefix Discovery when the MN is away from home).
2) real device interface, with auto-configured CoA's. We refer to this as
the "mobile interface".

We have an API that enables a user to select an appropriate local/source
address matching a specified destination address (per default address
selection algorithm, although we have a simplified version), and they can
pass an interface handle to this API to restrict the source address to be on
the specified interface. In this way, they can either choose the source
address to be a home address (i.e. the interface is the virtual home
interface), or a CoA (the interface is the "mobile interface"). Then, they
would bind the selected local address to a socket.

So, we don't configure the home addresses on the same interface as the
CoA's. I'm not sure what your implementation is doing, I suspect you use the
same interface for both.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Samita
> Chakrabarti
> Sent: Monday, December 02, 2002 11:52 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default
> source address selection
>
>
>