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