RE: globally unique site local addresses
I don't think it necessarily requires registration - usually a traceroute toward the leaked route will give a good indication where it is coming from. This assumes that the only type of leaking that you are concerned about is route leaking. It would also be good, in many cases, to be able to understand who owns an address that is leaked by other means (i.e. network management protocols). Margaret 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]
Re: unique enough [RE: globally unique site local addresses]
On Sat, 23 Nov 2002, Margaret Wasserman wrote: FEC0::/10 has about 38 usable bits there. That's enough for unique enough. No need for even that. Let's assume /16 - /40 -- 24 bits would be enough too. By birthday paradox, even in that case, collisions should only be probable if you communicate thousands of different sites simultaneously and there are referrals and third party interconnections. I don't think that you can, or should put the new globally-unique, provider independent address space inside the FECO::/10 allocation. As far as I know, we still plan to allow the FECO::/10 prefix to be used for disconnected sites, and perhaps other moderate usage. Oh? I am not sure about goals what we're actually trying to solve. IMO, putting some randomness in the fec0::/10 solves nearly all, or all, the problems with current _site-local_ addresses. (I'm not sure because the requirements list doesn't exist yet :-). Naturally, people will want to have truly globally unique, routable, provider-independent, etc. addresses. But there is no free lunch. Have we been through this road yet? Yes, I believe so, with no apparent success. Let's define our scope better than that and leave the latter for e.g. multi6 to consider (e.g. geographically automatically allocated PI space). -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
RE: globally unique site local addresses
On Sun, 2002-11-24 at 04:12, Michel Py wrote: This sounds like a terrible idea. Site-locals are not for everyone, and we certainly don't want to encourage their use by making it plug and play. Agreed, for site-locals alone it is a terrible idea. Philosophically I'm with you, although I tend to be somewhat cynical about it (and I must confess to playing the Devil's advocate a little with my proposal). Site locals are here and I'm convinced that people will find all kinds of uses for them, whenever they are convenient to use or meet a specific need that globally routable addresses don't. It's not very fruitful to concentrate on discouraging the use of site-locals. Rather, the focus should be on eliminating the reasons that make people resort to them. Plug-n-play router configuration is a worthy goal in itself (and I'm not only talking about site-locals now), since with IPv6 people that can barely figure out how to get the router out the box suddenly find themselves with plenty of address space and are likely to be setting up networks of their own. I hope the zerouter BOF comes to something. We need a good solution for this. MikaL 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]
RE: globally unique site local addresses
Hi Dan, |There could be another model, where the end-site would request the block |to one of their ISPs and the ISP access the IANA or RIR web site on |behalf of the customer. Let's not encourage ISPs to be in the address allocation business any more than necessary. :) Besides, what if you don't have an ISP? I agree - I think that whatever we do on this topic we MUST NOT assume anything like ISP intervention. This is key for home, mobile adhoc networks where these kinds of addresses are potentially useful. best regards, John 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]
Re: globally unique site local addresses
Michel, In any case, a modest suggestion: Let's separate the GUPI prefix generation and registration processes, and make them sequential. I have another suggestion: Let's split the FEC0::/10 space in two parts: One for the unregistered good-enough and one for the registered truly unique. By default, the good enough would be used and a random/hash method would be used. But the network administrator would have a choice of getting a truly unique registered prefix instead. This would likely need to access some web page and pay a nominal fee. If the address space is split, then we have a guarantee that the hash process used for good enough will not grab addresses in the range that is used for truly unique. Let me try to briefly analyse the differences between the methods, the mixed space and the split space methods: - In either method, you can generate a prefix and register it as a GUPI prefix belonging to you right away. - In the mixed space method, you may have to need a couple of prefixes before you get one registered. OTOH, if you really need a registered prefix, you can combine generation and registration, and start configuring your routers only once you have got a prefix registered. Thus, no big difference in practise. - In the mixed space method, you can generate a prefix now and try to register it later, with a fairly large probability of succeeding. In the split space method, if you only later need a genuinely globally unique address and are not willing to pay for one now, you have to renumber. - In the split space method, you can tell directly from a prefix whether it is genuinely globally unique or not. In the mixed space method you can query the registry whether the prefix has been registered, but even if it is, there may be also other sites that are using the prefix. The probability of the existence of such sites is low, though. - In the split space method, you can be almost sure that nobody else is using your globally unique prefix, and if they do, they do it in error. In the mixed space method, you cannot be sure that nobody else is using your prefix, but if they do, you know that they cannot register it. Thus, from my point of view, the differences seem to boil down into two issues: 1. In the mixed space method, you can defer your registration and still have a fairly large probability of succeeding later in registration. 2. In the split space method, you can have more confidence that no-one else is using your truly unique prefix. I can't say which is better. --Pekka Nikander 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]
Re: globally unique site local addresses
Michel Py wrote: There is room for both models at the same, and good enough is not going to be good enough for everybody. Margaret Wasserman wrote: I would need to see a very compelling case for why two types of globally-unique/provider-independent addressing are needed before I would like to see two models. Good enough ones are easy to generate without too much human intervention, for example, without any connection to the registry. OTOH, they are not necessarily unique, and therefore not good enough for some people. IMHO, both types are needed. I think that one of the benefits of globally-unique/provider- independent addresses over site-locals is that it is possible to tell (when one is leaked in any of the possible ways) exactly where the address came from... This would, of course, work best if the addresses were actually unique, rather than mostly-unique. Requiring that everybody registers their GUPI addresses will not make everyone to register them. OTOH, you could argue that if we mandate registration, and someone uses some prefix without registering them, it's their problem. In any case, a modest suggestion: Let's separate the GUPI prefix generation and registration processes, and make them sequential. The prefix generation could be a semi-automatic hashing based process, generating a prefix that is only statistically unique. If real uniqueness is required, the administrator could take the generated prefix and attempt to register it against a modest fee. It that succeeds, good. If that particular prefix is already taken, the admin can generate a new prefix and try again. Registration would require not only registering the prefix but also showing the input. That would discourage people from hoarding easy prefixes or adjacent prefixes, since looking for suitable hash input for such prefixes would not be that easy. Furthermore, if really needed, the fee can be gradually raised as the registry starts to fill up, thereby discouraging new registrations. The basic benefit of this method is that there would be only one way of generating GUPI addresses, and that would be an easy one. Additionally, the method would initially keep the GUPI prefix space sparce and evenly distributed; that might be advanteous. For example, deferring regisration of one's prefix would not be that risky, since the probability of succeeding later would be still fairly high. --Pekka Nikander 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]
RE: globally unique site local addresses
Pekka, Pekka Nikander wrote: Good enough ones are easy to generate without too much human intervention, for example, without any connection to the registry. OTOH, they are not necessarily unique, and therefore not good enough for some people. IMHO, both types are needed. Agreed. In any case, a modest suggestion: Let's separate the GUPI prefix generation and registration processes, and make them sequential. I have another suggestion: Let's split the FEC0::/10 space in two parts: One for the unregistered good-enough and one for the registered truly unique. By default, the good enough would be used and a random/hash method would be used. But the network administrator would have a choice of getting a truly unique registered prefix instead. This would likely need to access some web page and pay a nominal fee. If the address space is split, then we have a guarantee that the hash process used for good enough will not grab addresses in the range that is used for truly unique. It is clear that the biggest the block for good enough, the lesser potential collisions. Therefore the truly unique addresses should use only a modest portion of the FEC0::/10 block and leave the lion's share to the hash algorithm. Thoughts? Michel. 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]
Re: unique enough [RE: globally unique site local addresses]
Margaret, It is actually my (weak) understanding that taking more inputs does not actually result in more uniqueness, at least for random number generation. Does anyone know how that works for hashing? AFAIK, the bigest problem with random number generation is non-random seed data. Adding more sources of randomness helps in that. In this case, relying in just one MAC address as a seed for a hash function is probably not good enough, but e.g. taking the MAC address *and* the machine's current idea of date time in millisecond precision probably is. As another issue, just picking a cryptographically strong hash function and using it as a random number generator is typically *not* good enough for many uses of random numbers, but IMHO it is OK for generating these kinds of identifiers. Thus, if we want a method for automatically generating prefixes for globally unique enough site local addresses, a decent method might be sha1( current date and time in ms | interface MAC ) where the date time would be a 64 bit integer and the MAC address either 48 or 64 bit MAC, the 48 bit version enlarged to 64 bits. Note that there is no need for time synchronization. If there are more implementations of MD5 than SHA-1, MD5 would be good here, too. In the case of a collision, the algorithm can be simply rerun. The new result will be completely different. --Pekka Nikander 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]
RE: unique enough [RE: globally unique site local addresses]
It is actually my (weak) understanding that taking more inputs does not actually result in more uniqueness, at least for random number generation. Does anyone know how that works for hashing? This is well explained in RFC 1750, Randomness Recommendations for Security, D. Eastlake, S. Crocker, J. Schiller, December 1994. In short, you need to make sure that the various strings you are hashing provide you the desired level of entropy -- would be 38 bits in this example. -- Christian Huitema 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]
RE: globally unique site local addresses
Pekka, Pekka Nikander wrote: Thus, from my point of view, the differences seem to boil down into two issues: 1. In the mixed space method, you can defer your registration and still have a fairly large probability of succeeding later in registration. 2. In the split space method, you can have more confidence that no-one else is using your truly unique prefix. I agree with the analysis. I can't say which is better. I think that the split space is better, for the following reason: truly unique is a paid feature. People that pay for the feature will want a guarantee that they will get what they paid for, which is truly unique, which means the only model that works is split space. Michel. 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]
Re: globally unique site local addresses
On Sun, 24 Nov 2002, Pekka Nikander wrote: Michel Py wrote: There is room for both models at the same, and good enough is not going to be good enough for everybody. Margaret Wasserman wrote: I would need to see a very compelling case for why two types of globally-unique/provider-independent addressing are needed before I would like to see two models. Good enough ones are easy to generate without too much human intervention, for example, without any connection to the registry. OTOH, they are not necessarily unique, and therefore not good enough for some people. IMHO, both types are needed. [...] Whether completely unique is required epends on what they're to be used for. Myself, I can't see _any_ reason why anyone would require complete uniqueness (except for being able to globally route them, which is a problem I don't think we should be pursuing here). Nearly enough uniqueness with about 38 bits is more than enough. Even with the birthday paradox, where all the networks would be interconnected, about hundreds of thousands of sites would have to all-interconnected, thousands with a very good probability of uniqueness. But sure, e.g. reserving fee::/12 (pun intended :-), fef::/12 reserved) manual assignments would be ok, but I think people would just not use them at all, or use them for entirely wrong purposes -- which is why registering them should not be free. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
Re: globally unique site local addresses
Pekka Nikander wrote: Good enough ones are easy to generate without too much human intervention, for example, without any connection to the registry. OTOH, they are not necessarily unique, and therefore not good enough for some people. IMHO, both types are needed. Pekka, I still don't know if we really need the perfectly unique site local addresses. The question is: if you need perfectly unique addresses, why can't you use normal, global addresses? There we already have an existing registration process and standards. My thinking is that global addresses + statistically unique site-locals would cover most of the need we have, and it does not pay to construct complexity for the small amount of folks who would need perfect uniqueness. Of course, this is a judgement call. (You and me are perhaps the wrong persons to argue about this; input from corporate network managers and ISPs would be needed.) Jari 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]
RE: globally unique site local addresses
Jari, Jari Arkko wrote: The question is: if you need perfectly unique addresses, why can't you use normal, global addresses? There we already have an existing registration process and standards. Pardon me? There is no such thing for end-sites as of today. My thinking is that global addresses + statistically unique site-locals would cover most of the need we have, and it does not pay to construct complexity for the small amount of folks who would need perfect uniqueness. Since truly unique would have a fee, the people that pay the fee will finance the development effort. From an enterprise standpoint, $50 a year is not significant if it buys the *guarantee* that the address is unique. The truly unique feature is like insurance. Michel. 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]
RE: unique enough [RE: globally unique site local addresses]
Pekka / Margaret My $0.02 about the hash/random/collision issue: It's a non-issue. The prefix generation happens only one time for the site. Collisions would not be detected until two sites merge or establish a VPN connection. The site gets its GUPI /48 prefix once, then the network administrator configures all routers within the site with subnets that fit in that prefix. This could be automated, but the fact of the matter is that there needs to be a router somewhere that seeds this prefix. If what you are talking about is automatic subnet number generation, this would be a zeroconf issue. Besides the fact that making site-locals too easy is bad, I don't see why obtaining the prefix should be generated by a router. It is clear that the first thing the network administrator would do is to write down the /48 s/he will be using, and would be the one requesting the prefix in the first place. Also, whatever the random/hash algorithm is chosen and published, it also is clear that the first thing that the network administrator would do is to go to the web to find if someone has already written an applet that would do the job. All we need is a few web sites in the world that provide a good random number generator. Michel. 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]
Re: Proposal for MIPv6 APIs to switch default source address selection
= in order to use the API, an application needs to be changed. So with only the API, the only way to influence the Co@/H@ choice is to change all common applications... So the API will get only very limited use and the smart user should still wait for a device to fulfill his needs. Yes, the applications need to change to accomodate MobileIP. The goal should be to change them minimally. Thus a API would help in this case, as it may turn the knob to tell the kernel which address to use instead of a default address. The application may not need to specify the exact COA, the kernel can choose the correct one corresponding to the default homeaddress ( assuming application has knowledge about the correct home address). This will be useful for multi-homed mobile nodes as well. they need to use COA for local cases in the visited link. = yes, all the short term not bound to the home applications could like to use a Co@. There are a lot of situations where to get communications killed by movements is not a problem... It will not be desirable to restart common applications upon movement, however small their numbers may be. Then we will loose essence of MobileIP. some existing apps would have to be modified or written for MIPv6 anyway. = we have to keep the number of such applications as low as possible. I don't know how many apps fall in this category, may be we should think about that. Off the top of my head, they could be dns-client, printer-client, or any application that requests service discovery in the local network. -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 PROTECTED]
RE: draft-ietf-ipv6-node-requirements-01.txt
John, I have not found any more deprecated cases. But will keep looking just in case. For the M bit. If it is set to a client then the client must find a stateful server for managed addresses to be unconditionally mandatory compliant. Rationale is if the M bit is set the network administrators are telling nodes to do use a stateful mechanism to get addresses. And network administrators are in charge of that policy and they have opted to not use stateless for all addresses or any addresses in this case. /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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 7:52 PM To: Bound, Jim; [EMAIL PROTECTED] Subject: RE: draft-ietf-ipv6-node-requirements-01.txt Hi Jim, Today in v6ops I think I heard that compliance to the ND M bit being set is optional. That I think is wrong. But the node reqs doc states that dhcpv6 is unconditionally optional which is probably correct because stateful may not imply dhcpv6 today. But if the M bit is set the host node (non router) must look for a stateful node. We need to get this right. P.S. John - I will have all my input on this to you in the next few weeks. But it looks real good. I like the terminology too. Glad you think that the document looks good. Review it let me know what you think - especially suggest what text you think is needed for the M bit. John 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]
RE: Proposal for MIPv6 APIs to switch default source address selection
Just as note thus far with mipv6 testing and technology interoperation with other mipv6 vendors not one application has had to be altered to support mipv6 (e.g. ftp, telnet, streaming video/audio, sip, and a few others). Clearly they had to be ported to IPv6 but nothing special was done for mipv6. The above statement is for the server, router, and handhelds we are testing with at this time and putting in test labs deploying IPv6 in test beds. I don't see draft 19 from draft 18 as big deal either. But I can see optimizations per Samita's comments below helping with very fast movement, and having socket options to set to affect that movement is quite smart and someone should proceed with the work (I can't to much IETF work now sorry). /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: Sunday, November 24, 2002 11:59 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Proposal for MIPv6 APIs to switch default source address selection = in order to use the API, an application needs to be changed. So with only the API, the only way to influence the Co@/H@ choice is to change all common applications... So the API will get only very limited use and the smart user should still wait for a device to fulfill his needs. Yes, the applications need to change to accomodate MobileIP. The goal should be to change them minimally. Thus a API would help in this case, as it may turn the knob to tell the kernel which address to use instead of a default address. The application may not need to specify the exact COA, the kernel can choose the correct one corresponding to the default homeaddress ( assuming application has knowledge about the correct home address). This will be useful for multi-homed mobile nodes as well. they need to use COA for local cases in the visited link. = yes, all the short term not bound to the home applications could like to use a Co@. There are a lot of situations where to get communications killed by movements is not a problem... It will not be desirable to restart common applications upon movement, however small their numbers may be. Then we will loose essence of MobileIP. some existing apps would have to be modified or written for MIPv6 anyway. = we have to keep the number of such applications as low as possible. I don't know how many apps fall in this category, may be we should think about that. Off the top of my head, they could be dns-client, printer-client, or any application that requests service discovery in the local network. -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 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]
Re: Enforcing unreachability of site local addresses
I think that we should stop calling these addresses site-local, as that is prone to confusion. We would create a separate set of globally-unique/provider-independent (GUPI? Pronounced guppy or goopy, depending on how much you like them? :-)) addresses for use as local addresses in Internet connected sites. I've started calling them PIGs for Provider Independent Globals :) 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]
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.. Correct. When an app uses bind(), in most cases it assumes that the bound-to- address is an interface address of the node. So, if the home-addr and temporary addresses are configured as logical interfaces of COA interface (in visited network) of the mobile node, binding to a specific source address would work. But for multi-homed nodes or a node which has multiple home-addresses and COAs, the client apps may not want to bind to any particular source address and it wants to let the kernel decide to choose the correct topological address corresponding to the local network. Since the apps need to be generic to handle all cases, binding to a source address would not work always. 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. I'd say for connected and bound sockets, getsockname() would return the correct topological source address. Thanks, -Samita 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]
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]
