> > 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.
I completely agree. > 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. alper > 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 PROTECTED]] > > > Sent: Thursday, November 21, 2002 9:49 PM > > > To: Francis Dupont > > > Cc: Samita Chakrabarti; [EMAIL PROTECTED]; > > > [EMAIL PROTECTED] > > > 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 PROTECTED] > > > > > > > > > > -------------------------------------------------------------------- > > > 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 PROTECTED] > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
