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

From: Francis Dupont <[email-masked]>
Date: Mon, 02 Dec 2002 16:53:56 +0100

Yes, the applications need to change to accomodate MobileIP.

=> this is my concern.

   The goal should be to change them minimally.

=> a minimum greater than zero is not acceptable. IMHO the setsockopt()
solution is not what we need, and there is no easy alternative.
(the problem is in the address selection stuff which doesn't propose
reasonable ways to influence some parts of the policy).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 02 Dec 2002 17:12:50 +0100

> > 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.
   >
   > I'd say for connected and bound sockets, getsockname() would return the
   > correct topological source address.
   
   But that'd break the getsockname() function, which should return the local
   binding of the socket. If the socket is bound to a home address, that
   address
   should be returned by the function, even though it might be also
   (Mobile IP-)bound to a care-of address.
   
=> there are two things: the address the socket is bound to (should
be the home address in common cases) and the address which will be
in the source field on the wire (should be the care-of address).
getsockname() must return the first one but the mobile IP API should
give a way to retrieve the second.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 02 Dec 2002 17:17:01 +0100

> 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.
   
=> this suggests a setsockopt() API which is not usable.
What I suggest is:
 - a better solution for address selection exceptions
 - a get_the_care-of_which_shall_be_used for very special applications
   (which need this information to explicitely bind sources)

   I think we should work on a separate Mobile IP API, that can encompass
   this and more.
   
=> no, only the second item should be in the Mobile IP API. The first one
has to go in an address selection control API.

---

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

>    (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.
>    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).
>    
> => I disagree for the last point because it can be done using
> the address selection policy table. The issue is for choices
> which can't be coded in the table, i.e., mobility and temporary.
> 

 Yes, I aggree with your disagreement here. link-local source address
 (site-local perhaps out-of-scope now) can be handled by the default
 address selection draft.
 
 -Samita

---

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

-Samita

--------------------------------------------------------------------
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: Samita Chakrabarti <[email-masked]>
Date: Mon, 2 Dec 2002 10:52:25 -0800 (PST)

> I think we should work on a separate Mobile IP API, that can encompass

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