Ahhhh. OK. Now I see. Don't do client stuff so did not see that. Thanks. /jim [A people who would give up their freedom out of fear did not deserve it in the first place. Ben Franklin]
> -----Original Message----- > From: Samita Chakrabarti [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 25, 2002 12:31 AM > To: Bound, Jim > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to > switch default source address selection > > > > > > > > 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. > > > > That's what I was aiming for; a short and simple advanced api > socket extension doc as a guideline for MIPv6 compatible applications. > > 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] --------------------------------------------------------------------
