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 11:55:48 -0800 (PST)

Hi Ed,

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

OK.  

> 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, you have a private API which does part of default address selection
mechanism plus it can direct the implementation to choose homeaddr or
COA by passing interface handle with the API.

I was advocating a smiliar way of doing things by using a setsockopt()
socket api. 

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

I don't have a mobile node implementation. I was thinking folks may use a
logical interface for configuring homeaddr while away from home.
Is your implementation based on linux ?

Thanks for your input,
-Samita

> 
> > -----Original Message-----
> > 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
> >
> >
> >
> > > > 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 15:13:24 -0700

Samita -

We are in the business of building and selling RTOS-independent and
processor-independent IPv4 and IPv6 protocol stacks specifically for
embedded systems, so our MN implementation will be proprietary. We are doing
our own MIPv6 implementation for MN/CN.

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

> Sent: Monday, December 02, 2002 12:56 PM
> To: [email-masked]
> Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default
> source address selection
>
>
> Hi Ed,
>