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 PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Samita > > Chakrabarti > > Sent: Monday, December 02, 2002 11:52 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; [EMAIL PROTECTED] > > 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 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] --------------------------------------------------------------------
