Re: inevitability of PI
Keith Moore wrote: For once, Tony and I are in agreement. This has nothing to do with operations; it has everything to do with the programming model that the v6 Internet supports. I am saving this email :-) Who am I to argue with such overwhelming opposition. Cheers Leif 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: Moving forward on Site-Local and Local Addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On onsdag, aug 6, 2003, at 10:30 Europe/Stockholm, Aidan Williams wrote: -2. Realize that if the issue at stake here has more to do with getting addresses than with their actual scope/range, something probably can be done working with the registries. I don't think that is true. The local-ness of these addresses avoids the issue of having to scalably route the PI space. I can't see significant differences in process between globally unique local address allocation and a globally unique PI address allocation. Bingo! So let's kill SLs and start working on the real issue... - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkLrqarNKXTPFCVEQLyUQCgt7+tzyMngo5TUPuI7WbC1OHVn+YAn08g wAzxQnfB+CeFXihapfelJMD1 =VTbj -END PGP SIGNATURE- 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: Real life scenario - requirements (local addressing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why do this example give me the feeling that we are arguing over sacrificing the functionality for the majority for a few special cases. The real problem is a long-term scalable private address solution. There are other WG(s) looking at that. - - kurtis - On torsdag, aug 7, 2003, at 03:54 Europe/Stockholm, Andrew White wrote: A 'real life' deployment scenario. (a) I set up a local network. I currently have no ISP, but I want my network to 'just work' out of the box. This network consists of (initially) three routers, plus other infrastructure. (b) Sometime later I decide I want internet connectivity, so I connect to an ISP. I add my ISP provided address to my network in addition to the address/es that are there already. For argument's sake, let's say the ISP doesn't have IPv6 capability, so I use a 6to4 address. I do not want my internal addressing exposed outside the network, so I filter my addresses. I do use the ISPs addresses for external connectivity. (c+d) Meanwhile, my friend has done the same thing, except that his ISP DOES offer IPv6, so he has a 'real' IPv6 address. (e) We connect our two local networks together (either by VPN tunnel or a wireless link - doesn't matter). We can now send local traffic to each other, and out either ISP. (f) Sometime later I disconnect my ISP, and we use just his ISP. (g) Sometime later I disconnect my network from his. (h) Sometime later I register with a new ISP, and get a new IPv6 prefix. Salient points: (1) At points (a), (c) and (g) we have networks that are standalone and have no connection to an ISP or the global internet. Further, the networks in (a) and (c) have never had such a connection. The users don't want to have to register to get an address that works. (2) In (b), the external (6to4) prefix is unstable. Many ISPs allocate a temporary IPv4 internet address, and change these frequently. (3) The set of global prefixes valid for the network changes over time. (a) None (b) #1 (my 6to4) (e) #1 and #2 (friend's v6) (f) #2 (g) None (h) #3 (my new v6) (4) The only 'reliable' address that the hosts in my network have is the local one they started with. This example is quite similar to Tony's research ship example, with the possible caveat that a research ship might be big and organised enough to register with an ISP to get an address space plus connectivity they never intend to use. Consequences: - I need some form of local addressing that is not dependent on anyone or anything connected to the global internet. - I need this local addressing unique enough that I can safely join my network and my friend's network together and allow them to swap prefixes. - I want hosts in my network to prefer my local address scheme when talking to other hosts in my network. I want hosts in my network to prefer one of the local schemes when talking to hosts in my friend's network (since I don't want the packets to leave 'our' network). I want hosts in my network to prefer global addresses when talking externally. - I want my local addresses filtered at appropriate borders, preferably without having to set it up myself. - The ISPs probably want my local addresses filtered too. Looks suspiciously like the filtered local address proposal, doesn't it? -- Andrew White 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] -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkYgaarNKXTPFCVEQJGPQCfQyCGGvUIDc62X8dV6GUgd6eec/sAoKX1 QpWklU58OMWlsP71UNC/j6Z0 =FArS -END PGP SIGNATURE- 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: Moving forward on Site-Local and Local Addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am away on vacation and have missed all the fun...for what i matters, I think A is the way to go. That sends a clear signal to network managers, implementors etc. B and C will leave us in a vacuum. - - kurtis - On måndag, aug 4, 2003, at 20:06 Europe/Stockholm, Bob Hinden wrote: [IPv6 working group chair hat on] I think the working group has been making good progress on replacing site-local addresses and wanted to get feed back from the working group on how we should move forward. This is not intended to directly relate to the ongoing appeal of the working groups decision to deprecate the usage site-local addresses, but to get feedback on how to proceed. I think it is very important that we move forward on this issue and not rehash what has happened in the past. We now have a combined local addressing requirements document draft-hain-templin-ipv6-limitedrange-00.txt, a specific alternative to site-local addresses draft draft-hinden-ipv6-global-local-addr-02.txt (accepted as a working group item at the Vienna IETF), and will soon have a draft describing why site-local addresses are being deprecated and doing the formal deprecation (authors identified and outline discussed at the Vienna IETF). Note that all of these documents will proceed through the normal working group and IETF processes of last calls and review. I think legitimate questions have been raised about how the working group should go about deprecating site-local addresses given their maturity in the current specifications and use in deployed products. Specifically should they be deprecated independently from having an alternative solution available, at the same time an alternative is available, or sometime after an alternative is available. A forth alternative is to not replace site-local addresses in any form, but I think the working group has made it clear that this is not a reasonable alternative. I would like to hear from the working group on how we should proceed. I think the choices are: A) Deprecate Site-Local addresses independently from having an alternative solution available. This would mean that the working group should treat the deprecation, and requirements and solution documents outlined above independently from each other. If there was no consensus on an alternative a replacement would not happen. B) Deprecate Site-Local addresses at the same time as a alternative solution is agreed to. This would mean advancing both documents at the same time and making them include normative references to each other to insure that they were published at the same time. This would result in the deprecation only happening if a consensus was reached on an alternative. C) Deprecate Site-Local addresses after an alternative is defined, standardized, and in operational practice. This would mean not advancing a deprecation document until there was operational evidence that the alternative was working and shown to be an improvement over Site-Local addresses. Note: In the above choices Deprecate Site-Local addresses means publishing an RFC that does the formal deprecation. Please respond to the list with your preference, or if there is an alternative approach that is an improvement from the ones I outlined. I hope that many of you will respond. Thanks, Bob 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] -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzj19KarNKXTPFCVEQJZzQCdHjcxPaPeKuBHmvNVqf0Y4DQfGewAoJpN BZoTYaGChp06+4mtxxKHZO+i =FDvu -END PGP SIGNATURE- 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: Moving forward on Site-Local and Local Addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On tisdag, aug 5, 2003, at 00:14 Europe/Stockholm, Michel Py wrote: If we were not able to fix site-locals I wonder where the silver bullet to replace them is. Solve the multi6 problem. Look at Geoffs presentations from the last IEPG. There is still time. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzj6iKarNKXTPFCVEQJ97wCeM2ajKPvg1S2jHzY6CoVeww7HJIcAoMdU LUuH/Icj2BZj830afDbRrEwq =e/s2 -END PGP SIGNATURE- 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: What to do with FEC0? [was Re: Moving forward on Site-Local and Local Addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm expecting, by the way, that the deprecation will leave fec0::/10 to be treated as global-scope unicast addresses, rather than making fec0::/10 addresses cease to function altogether. That's an interesting expectation. As co-author of the planned deprecation draft, I'd been assuming a more classical deprecation action, in which we would simply state the previous semantics of FEC0::/10, state that the prefix SHOULD NOT be used, but leave it permanently assigned by IANA. This would break nothing that runs today. What do people think? As with reusing /8s in IPv4, keep as IANA reserved for a while, then use. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkB8qarNKXTPFCVEQJ3XACgsCcM7FbMBmbPoTNl6Olbsz/iVPoAoNLX 5mOa6NR4cLbZpozUGb220Zai =GhoZ -END PGP SIGNATURE- 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: Moving forward on Site-Local and Local Addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On tisdag, aug 5, 2003, at 01:57 Europe/Stockholm, Jeroen Massar wrote: Fortunatly there are clued ISP's who do filter accordingly to: http://www.space.net/~gert/RIPE/ipv6-filters.html I would advise and even try to pursuade people to run them in strict mode... I am still more worried about ever reaching a 1000 routes, or any significant number of routes... - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzj9mKarNKXTPFCVEQKElACfaFS4X1Az6+br8rX9B1KDBdqf7wMAnij0 +pNubI1qlaGv12anRQ3Lt/zT =QLv9 -END PGP SIGNATURE- 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: Moving forward on Site-Local and Local Addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If we had new routing technology that could handle globally routable provider independent addresses, then it would have to be deployed in most routers in the Internet before it would be useful. Probably all routers from the site boundary to the core of the Internet. Given that I suspect any solution in this area would not be an incremental changes to a routers implementation (i.e., not another BGP extension), perhaps even changes to the routers route lookup engines (in hardware in many cases) this would likely take a long time to accomplish. Also, a bit of a chicken and egg deployment problem that everyone working on IPv6 understands too well. We will need to go through this anyway. Local scoped addresses will probably make that transition even harder. We don't have any structure in place to allocate and register these types of addresses. The registries might be able to do it, but as they are currently structured they are mostly focused on ISPs, not individual sites. This would require some major changes in their structure and perhaps funding models. Right now every site would have to be an LIR. Erh, no. Perhaps every enterprise the sites belong to though. Assuming routing technology was available and all of the routers were modified to support the new routing technology, then there would have to be some incentive for the ISP to want to carry these type of routes. They are great for the customers, but it makes it easy for their customers to switch ISPs. We have seen how well the phone providers have embraced provider independent phone numbers. They only agreed to support them after governmental action. This has not been a problem in most European countries that I know of. But I am no expert on this. I know that in Sweden it is currently the other way around. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzj8wqarNKXTPFCVEQL1iACfYlhbH1E/PWlb/+/XogOp/9M9proAoMl8 goDWYdJi5Z+ds0MsxXJM0sZV =iDGL -END PGP SIGNATURE- 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: Moving forward on Site-Local and Local Addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The same is true if we create a swamp again and allow individual /48s in the global routing table. Then IPv6 will become IPv4 with more bits, and in the current economy the net result will be more NAT-aware apps. I'm sorry to say it bluntly, but today IPv4 is unavoidable and if the only edge IPv6 has is a bigger address space I'm afraid it won't be enough to cut it. IPv6 IS IPv4 with more bits. 1. Even if we say that NATv6 is evil, there is little we can do to prevent it from happening except providing a solution that would bring somehow similar advantages. We don't need to encourage it... - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzj/qqarNKXTPFCVEQJJ0wCg3io0+MLVfB/pl+2qMao2FOsdIVwAoOl9 IYMty33YJrXtYX0rDeLIG2uq =/SJh -END PGP SIGNATURE- 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: Real life scenario - requirements (local addressing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On torsdag, aug 7, 2003, at 06:25 Europe/Stockholm, Andrew White wrote: Because (in the current context) there's no such thing? A local address is an address that promises to be filtered. Where? What determines the cope? Configuration? Then it's easier filtering global addresses. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkZb6arNKXTPFCVEQLfnACdE+4Of0Q9Sm1q2sgYDcLnAduMYO8AmgOH aU8pwyUyaDmpSuGy9MYUrTHh =mXDA -END PGP SIGNATURE- 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: Fourth alternative [was Re: Moving forward ....]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On onsdag, aug 6, 2003, at 06:40 Europe/Stockholm, Michel Py wrote: That being said, the hard facts are that a) as of today 42% of my IPv6 BGP routing table is made of /48s, /64s and other crud and b) lots of ISP will think twice before refusing my $2.5k/yr to announce my prefix. That is also because the ISPs realize that the current ~400 routes are far from a problem. Actually the 130k routes in IPv4 is not creating a problem either. Other characteristics of BGP might, but I haven't seen a reference to the number of routes creating a problem. Yes, they will cost the ISPs money, but that is why they are accepting your money. Filtering routes have it's advantages, especially in IPv4. With 400 routes, I still fail to see the problem. On the contrary, it tells me we have plenty of time to solve the real problem. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkKsqarNKXTPFCVEQLnngCgumYK3h6qjsqZyF3zPhVrr7EYAwwAnRH9 8u8GKMxnvcBIAxYq8hxIvmOT =/sYB -END PGP SIGNATURE- 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: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
(The reason for the late reply and all the late emails is that my laptop had a disk crash during my vacation, but I had a backup with mails I had replied to but not sent...) Tony, On Thursday, August 7, 2003, at 09:06 PM, Tony Hain wrote: This whole discussion is about multihoming, which points out the failure of the approach to move the multihoming discussion into a separate WG. Multi6 should be closed NOW, and that work should be folded back into the IPv6 WG so there can be a comprehensive approach to the issues (this is independent of the fact that the thread in an Ops WG is really about rearchitecting the Internet). I disagree with this. The multihoming problem is not a ipv6 problem alone. As we stand now, all discussions about multihoming are assumed to be taking place over there, so we don't recognize the address selection discussion as being the same thing. This is not entirely true. I remember the chairs in Vienna actually asking what we should do with this issue and where it belongs. This was also brought up in the multi6 meeting. So the issue is recognized as being similar, if not the same. Best regards, - kurtis - 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: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
On Thursday, August 7, 2003, at 11:37 PM, Michel Py wrote: which points out the failure of the approach to move the multihoming discussion into a separate WG. Multi6 should be closed NOW. As a matter of fact, by reading its charter it should have been rechartered or shutdown in September 2001, almost two years ago. But I hear that being two years behind objectives without any result is not a big deal in the IETF. Why do this when there finally is momentum? What makes the solutions better if we just move them to another WG? The charter and milestones are issues that needs to be address though. - kurtis - 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: WG focus (was: Re: Multi-homing (was RE: Moving backward [Re: Fourth alternative [wasRe: Moving forward ....]])
Agreed! - kurtis - On Friday, August 8, 2003, at 07:30 PM, Alain Durand wrote: Tony, I do not think it will work. Way too many efforts failed in the v6 wg and it is time to focus, not create again a mega wg. I have an alternate suggestion: - recharter the ipv6 wg to focus on advancing the protocol elements. - move the discussion on the operational requirements around the issues of address stability/locality/availability to v6Ops. after all, v6ops is the operational wg for IPv6! - if multi6 and/or v6ops conclude that some fundamental changes need to happen wrt the address architecture, charter an ad-hoc wg to focus on this problem. I think this course of action will enable us to make progress on this sensitive issue. - Alain. Tony Hain wrote: Brian E Carpenter wrote: I share Tony's frustration with long hiatus in multi6, but it seems to be unstuck at the moment. I also agree that it's hard to separate the topics, but I see no practical advantage in repatriating the multihoming issue into this WG, which already has a diverse agenda. Yes it is unstuck, but I strongly suggest it be brought back into this WG because (1) it is way outside the bounds of figuring out how to operate a multihomed network, and into rearchitecting the system in ways that will seriously undermine all assumptions about reachability and security, (2) is completely off the radar of anyone that did not stick it out through the dead time, (3) is the root of the discussion here about the utility of simultaneous use of addresses with different reachability characteristics. Tony 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: apps people?
Fred, multi-homed sites - this is being worked on by another group. granted it is a difficult problem. And, what are the solutions being proposed by that other group? (Don't worry; I know about multi6.) Is it HIP? Is it globally-routable PI? Is it something else? As they say at PacBell Park: You can't know the players without a program! there are two design teams as well as a number of individual submissions. HIP is one of the individual (well) proposals. Globally-routable-like features are the goal of most of the proposals. Globally-routable-as-is-addresses have AFAIK only been proposed by me, and then in a very short-lived bridging solution into something else. You are right that we don't know what the outcome of the design-teams will be, and we don't know how we will make the selection between them. Ideally, they are not to far enough and can be merged. But this is dependent on a lot more issues than what have been discussed here. Best regards, - kurtis - 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]
Weekly posting summary for ipng@sunroof.eng.sun.com
Messages | Bytes| Who +--++--+ 18.52% | 20 | 17.85% |96111 | [EMAIL PROTECTED] 12.96% | 14 | 12.25% |65968 | [EMAIL PROTECTED] 8.33% |9 | 7.70% |41466 | [EMAIL PROTECTED] 4.63% |5 | 6.11% |32869 | [EMAIL PROTECTED] 4.63% |5 | 4.84% |26074 | [EMAIL PROTECTED] 4.63% |5 | 4.48% |24096 | [EMAIL PROTECTED] 3.70% |4 | 4.84% |26057 | [EMAIL PROTECTED] 3.70% |4 | 4.44% |23893 | [EMAIL PROTECTED] 3.70% |4 | 3.45% |18572 | [EMAIL PROTECTED] 2.78% |3 | 3.82% |20568 | [EMAIL PROTECTED] 2.78% |3 | 2.79% |15045 | [EMAIL PROTECTED] 2.78% |3 | 2.57% |13833 | [EMAIL PROTECTED] 2.78% |3 | 2.13% |11487 | [EMAIL PROTECTED] 1.85% |2 | 2.40% |12938 | [EMAIL PROTECTED] 1.85% |2 | 2.02% |10869 | [EMAIL PROTECTED] 1.85% |2 | 1.69% | 9095 | [EMAIL PROTECTED] 1.85% |2 | 1.64% | 8838 | [EMAIL PROTECTED] 1.85% |2 | 1.61% | 8675 | [EMAIL PROTECTED] 1.85% |2 | 1.58% | 8502 | [EMAIL PROTECTED] 1.85% |2 | 1.28% | 6873 | [EMAIL PROTECTED] 0.93% |1 | 1.17% | 6299 | [EMAIL PROTECTED] 0.93% |1 | 1.09% | 5866 | [EMAIL PROTECTED] 0.93% |1 | 1.06% | 5719 | [EMAIL PROTECTED] 0.93% |1 | 0.95% | 5125 | [EMAIL PROTECTED] 0.93% |1 | 0.94% | 5082 | [EMAIL PROTECTED] 0.93% |1 | 0.82% | 4437 | [EMAIL PROTECTED] 0.93% |1 | 0.79% | 4274 | [EMAIL PROTECTED] 0.93% |1 | 0.78% | 4183 | [EMAIL PROTECTED] 0.93% |1 | 0.77% | 4138 | [EMAIL PROTECTED] 0.93% |1 | 0.74% | 3981 | [EMAIL PROTECTED] 0.93% |1 | 0.73% | 3917 | [EMAIL PROTECTED] 0.93% |1 | 0.64% | 3457 | [EMAIL PROTECTED] +--++--+ 100.00% | 108 |100.00% | 538307 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. 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: Moving forward on Site-Local and Local Addressing
IPv6 IS IPv4 with more bits. On the contrary it is much more if you go down behind the user and look at the protocol and implementation. It depends on ones view. I am debating this with Geoff now on his Myth article and there will another article soon. /jim 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]
IPv6 Link-Local Use Issue for Applications
Folks, Below is a picture of two links: Link 1 and Link 2. Link 1 has Host-L1-B and Host-L1-C. Link 2 has Host-L2-E and Host-L2-F. A multihomed Host-LX-D0 is connected to both Link 1 and Link 2. All hosts have both a Link-Local address FE80:: and a Global Address 3FFE:YY::. Note that Host-L1-B and Host-L2-E have the same Link-Local address as FE80::MAC1. This is permitted in IPv6 for separate links. Host-L1-BHost-L1-C 3FFE:AB::MAC1 3FFE:AC::MAC2 FE80::MAC1FE80::MAC2 Link 1 ___|_|___ 3FFE:AD::MAC3 |FE80::MAC3 |--- Host-LX-D0 |FE80::MAC6 Link 2__|3FFE:A0::MAC6 | | FE80::MAC1FE80::MAC5 3FFE:AE::MAC1 3FFE:AF::MAC5 Host-L2-E Host-L2-F If Host-LX-D0 user wants to ftp or telnet to Host-L2-E using FE80::MAC1 as an address 'ftp FE80::MAC1' being a multihomed host the routing or interface redirection (depending on how you wanted to implement) really does not know if it is for Link 1 or Link 2 as both will be in the destination cache potentially and duplicated, and this would be compliant to the IPv6 standard. But if Host-LX-D0 used Host-L2-E's global address 3FFE:AE::MAC1 there would be no problem, as IPv6 does not permit duplicate prefixes across links. What some implementations have done is require the user to specify the interface in addition to the address for link local (Linux did this as a note) 'ftp FE80::MAC1%Ethernet0' and other implementations perform a round robin to find the correct link-local address. The '%' is an artifact of the getaddrinfo() API as parameter. But this does not really solve the problem completely. How does the user know which Link to use for the link-local address? What if the user sent the message to the wrong link, especially in a mission critical situation (e.g. Patient in Hospital, Telecommunications Grid, Soldiers Device in Combat). This is not good and also has security issues that can be resolved with IPsec, but an encrypted packet to the wrong link is still not good as there is a chance in the diagram above that all Hosts are in fact using same PKI and IPsec encrypt and decrypt, and the packet could be accepted. IPv6 efforts in the IETF will not solve the future scoping capabilities within the IPv6 architecture any time soon, and it will be even longer to get scoping widely implemented in the market and tested well through interoperability events. The industry requires a solution today, and I would argue there is no solution. The solution that will work for now is make a statement in the IETF and in industry IPv6 implementation documentation that link-local addresses SHOULD not be used as an IPv6 address type by applications. That link-local addresses SHOULD not be included in the DNS. That link-local adddresses SHOULD be restricted to IETF protocols on Hosts to perform Neighbor Discovery, Stateless Address Configuration, DHCPv6, or other operation protocols to bring a Host up on a network. The bottom line is link-local address are not usable for applications. Would like to hear what my colleagues in IETF IPv6 WG think about this issue? This mail will also be sent to the IPv6 Forum deployment effort and to several users I know of that are deploying IPv6 currently, to hear from the operational and implementation community too. Thanks /jim 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: Real life scenario - requirements (local addressing)
Kurt Erik Lindqvist wrote: Why do this example give me the feeling that we are arguing over sacrificing the functionality for the majority for a few special cases. It's a special case that potentially includes most home users, SOHO users, and personal area networks. Surely there won't be more than a few hundred of them? (removes tongue from cheek) -- Andrew White 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: IPv6 Link-Local Use Issue for Applications
Bound, Jim wrote: Below is a picture of two links: Link 1 and Link 2. Link 1 has Host-L1-B and Host-L1-C. Link 2 has Host-L2-E and Host-L2-F. A multihomed Host-LX-D0 is connected to both Link 1 and Link 2. All hosts have both a Link-Local address FE80:: and a Global Address 3FFE:YY::. Note that Host-L1-B and Host-L2-E have the same Link-Local address as FE80::MAC1. This is permitted in IPv6 for separate links. It was my understanding that duplicate MACs are not permitted by the MAC allocations, which are *supposed* to guarantee that each physical interface device has a unique MAC. Which would imply that a link-local addressed based on a MAC is in fact globally unique, by definition? What have I missed? -- Andrew White 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: IPv6 Link-Local Use Issue for Applications
But this does not really solve the problem completely. How does the user know which Link to use for the link-local address? we could use LLMNR to resolve names to link-local addresses, or vice versa. i have done it and it works okay. under our current implementation, LLMNR daemon talks to libc resolver by normal DNS protocol (port 53) so link identifier will be lost. however, if we use different inter-process communication, or integrate LLMNR into libc, we won't lose link identification (and we can set sin6_scope_id right). The solution that will work for now is make a statement in the IETF and in industry IPv6 implementation documentation that link-local addresses SHOULD not be used as an IPv6 address type by applications. That link-local addresses SHOULD not be included in the DNS. That link-local adddresses SHOULD be restricted to IETF protocols on Hosts to perform Neighbor Discovery, Stateless Address Configuration, DHCPv6, or other operation protocols to bring a Host up on a network. The bottom line is link-local address are not usable for applications. I completely agree that link-local address SHOULD NOT be on public DNS database. i have already asked the author of draft-ietf-dnsop-dontpublish-unreachable-03.txt to include the text, and it is included. itojun 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: IPv6 Link-Local Use Issue for Applications
On Tue, 19 Aug 2003 11:17:33 +1000 Andrew White [EMAIL PROTECTED] wrote: Bound, Jim wrote: Below is a picture of two links: Link 1 and Link 2. Link 1 has Host-L1-B and Host-L1-C. Link 2 has Host-L2-E and Host-L2-F. A multihomed Host-LX-D0 is connected to both Link 1 and Link 2. All hosts have both a Link-Local address FE80:: and a Global Address 3FFE:YY::. Note that Host-L1-B and Host-L2-E have the same Link-Local address as FE80::MAC1. This is permitted in IPv6 for separate links. It was my understanding that duplicate MACs are not permitted by the MAC allocations, which are *supposed* to guarantee that each physical interface device has a unique MAC. Which would imply that a link-local addressed based on a MAC is in fact globally unique, by definition? What have I missed? a) MAC addresses are reasonably easily to change. You can't guarantee that the end-users will follow the recommendations ie. enable the locally administered bit. Most networking people I've met don't know there is a locally administered bit in a MAC address. b) There have been cases where manufacturers have allocated non-unique MAC addresses. What is worse is that these duplications have apparently tended to happen within the same batch of NICs, and have been encountered when somebody goes to deploy a group of say 20 new NICs they have just bought, and encounter one or more duplications. c) MAC addresses are typically placed in outgoing ethernet frame headers by the device driver, not by the NIC itself, which is why it changing the MAC address of an interface is usually functionally quite easy. The device driver gets the MAC address to use from an EEPROM or something similar from the card. Bugs in that part of the device driver can cause duplicates. You can generally _assume_ MAC addresses are globally unique, which is why they are used as node IDs in IPv6, IPX, but there aren't any guarantees. Further, global uniqueness of MAC addresses is really only so that the device can be plugged in and work out of the box. For the network to actually work, the MAC address only has to be unique on the segment it is attached to. Regards, Mark. 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: IPv6 Link-Local Use Issue for Applications
It was my understanding that duplicate MACs are not permitted by the MAC allocations, which are *supposed* to guarantee that each physical interface device has a unique MAC. Which would imply that a link-local addressed based on a MAC is in fact globally unique, by definition? What have I missed? The rule you state is only per Link. Not multiple links. There is no rule that you cannot duplicate link-locals on separate links only prefixes. /jim -- Andrew White 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: IPv6 Link-Local Use Issue for Applications
But this does not really solve the problem completely. How does the user know which Link to use for the link-local address? we could use LLMNR to resolve names to link-local addresses, or vice versa. i have done it and it works okay. Hmmm. I can see that but need to go reread LLMNR. But so far when I chase it I find a glitch and another failure mode. I even thought if the multihomed node sees a duplicate on a multi segment link it could do something to inform the network but that still does not get around how does the user know? But if LLMNR works we can check it out. As I said I have to go reread. under our current implementation, LLMNR daemon talks to libc resolver by normal DNS protocol (port 53) so link identifier will be lost. however, if we use different inter-process communication, or integrate LLMNR into libc, we won't lose link identification (and we can set sin6_scope_id right). Yes for that link for sure. But not clear how that helps for multihome multilink? The solution that will work for now is make a statement in the IETF and in industry IPv6 implementation documentation that link-local addresses SHOULD not be used as an IPv6 address type by applications. That link-local addresses SHOULD not be included in the DNS. That link-local adddresses SHOULD be restricted to IETF protocols on Hosts to perform Neighbor Discovery, Stateless Address Configuration, DHCPv6, or other operation protocols to bring a Host up on a network. The bottom line is link-local address are not usable for applications. I completely agree that link-local address SHOULD NOT be on public DNS database. i have already asked the author of draft-ietf-dnsop-dontpublish-unreachable-03.txt to include the text, and it is included. OK I have not read this but will. Thanks /jim itojun 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: IPv6 Link-Local Use Issue for Applications
On Mon, 18 Aug 2003 21:00:36 -0400 Bound, Jim [EMAIL PROTECTED] wrote: The solution that will work for now is make a statement in the IETF and in industry IPv6 implementation documentation that link-local addresses SHOULD not be used as an IPv6 address type by applications. agree emphatically. LL should only be used by special-purpose apps that are aware of LL and its limitations. (and no, LLMNR doesn't solve the problem. LLMNR in its current form is a worse mistake than Site Local.) 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: IPv6 Link-Local Use Issue for Applications
Jim, as long as the application is link-local aware, and treats the scope-id properly, this is not a problem. Most stacks I'm aware of handle this situation correctly. But this means getting the address directly off something on the link, and not through some external lookup mechanism like the global DNS. Link-local addresses are ambiguous off link, and therefore should not (or rather, MUST NOT) appear in the global DNS. For the most part, this limits the use of link-local addresses to applications that are aware of the link. --Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bound, Jim Sent: Monday, 18 August, 2003 18:01 To: [EMAIL PROTECTED] Cc: Bound, Jim Subject: IPv6 Link-Local Use Issue for Applications Folks, Below is a picture of two links: Link 1 and Link 2. Link 1 has Host-L1-B and Host-L1-C. Link 2 has Host-L2-E and Host-L2-F. A multihomed Host-LX-D0 is connected to both Link 1 and Link 2. All hosts have both a Link-Local address FE80:: and a Global Address 3FFE:YY::. Note that Host-L1-B and Host-L2-E have the same Link-Local address as FE80::MAC1. This is permitted in IPv6 for separate links. Host-L1-BHost-L1-C 3FFE:AB::MAC1 3FFE:AC::MAC2 FE80::MAC1FE80::MAC2 Link 1 ___|_|___ 3FFE:AD::MAC3 |FE80::MAC3 |--- Host-LX-D0 |FE80::MAC6 Link 2__|3FFE:A0::MAC6 | | FE80::MAC1FE80::MAC5 3FFE:AE::MAC1 3FFE:AF::MAC5 Host-L2-E Host-L2-F If Host-LX-D0 user wants to ftp or telnet to Host-L2-E using FE80::MAC1 as an address 'ftp FE80::MAC1' being a multihomed host the routing or interface redirection (depending on how you wanted to implement) really does not know if it is for Link 1 or Link 2 as both will be in the destination cache potentially and duplicated, and this would be compliant to the IPv6 standard. But if Host-LX-D0 used Host-L2-E's global address 3FFE:AE::MAC1 there would be no problem, as IPv6 does not permit duplicate prefixes across links. What some implementations have done is require the user to specify the interface in addition to the address for link local (Linux did this as a note) 'ftp FE80::MAC1%Ethernet0' and other implementations perform a round robin to find the correct link-local address. The '%' is an artifact of the getaddrinfo() API as parameter. But this does not really solve the problem completely. How does the user know which Link to use for the link-local address? What if the user sent the message to the wrong link, especially in a mission critical situation (e.g. Patient in Hospital, Telecommunications Grid, Soldiers Device in Combat). This is not good and also has security issues that can be resolved with IPsec, but an encrypted packet to the wrong link is still not good as there is a chance in the diagram above that all Hosts are in fact using same PKI and IPsec encrypt and decrypt, and the packet could be accepted. IPv6 efforts in the IETF will not solve the future scoping capabilities within the IPv6 architecture any time soon, and it will be even longer to get scoping widely implemented in the market and tested well through interoperability events. The industry requires a solution today, and I would argue there is no solution. The solution that will work for now is make a statement in the IETF and in industry IPv6 implementation documentation that link-local addresses SHOULD not be used as an IPv6 address type by applications. That link-local addresses SHOULD not be included in the DNS. That link-local adddresses SHOULD be restricted to IETF protocols on Hosts to perform Neighbor Discovery, Stateless Address Configuration, DHCPv6, or other operation protocols to bring a Host up on a network. The bottom line is link-local address are not usable for applications. Would like to hear what my colleagues in IETF IPv6 WG think about this issue? This mail will also be sent to the IPv6 Forum deployment effort and to several users I know of that are deploying IPv6 currently, to hear from the operational and implementation community too. Thanks /jim 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:
regarding draft-hinden-ipv6-global-local-addr-02
Bob: I have read carefully your Unique Local IPv6 Unicast Addresses internet draft, and here are my reactions: First, as regards IPv6 engineering strategy: the use of non-globally routable, globally unique (or nearly so) PI addresses as proposed in the Local IPv6 addresses ID would alleviate many (but, of course, not quite all) of the difficulties previously identified as arising from use of Site-Local addressing. With the proposed deprecation of Site-Local addressing, a great clamor has arisen for some convention which might provide an improvment over S-L where stable local addressing is required. Your draft seems to define such a convention. While the Local IPv6 addresses proposal does not resolve quite _all_ the issues surrounding address allocations for local environments (more on this below), the current draft nevertheless has much to commend it. In short, I am of the opinion that the mechanisms and practices proposed in INTERNET-DRAFT Unique Local IPv6 Unicast Addresses, or some very similar scheme, should be adopted. Please see below for notes on issues which are likely to continue to fester even after adoption of a scheme such as proposed in the current draft. Now, concerning specific elements of the proposal: Section 3.1 Format The proposals herein are unobjectionable. The suggestion of a /7 space divided into one /8 for local assigns and one /8 for central assigns seems reasonable to me. I am somewhat less sanguine than are you concerning the assumption that the central-assign /8 will never be exhausted, but, as pointed out in the draft, it is possible to augment the space with an additional /7 at some later time if necessary. It might be prudent to ask (or direct) the IANA to reserve another /7 for later use, with the proviso that the additional space will be freed after an agreed length of time if allocation rates prove no higher than expected. After all, the v4 design wallahs didn't think they would exhaust the 32-bit space either. 3.2.1 Centrally Assigned Global IDs I do not see (although I may have overlooked it) any requirement that the allocation authority ensure that a prefix generated in response to a request for a centrally assigned global ID be unique. Since one of the purposes of most central assignment mechanisms is to ensure non-duplication of allocations, it would seem useful to require an allocation authority to enforce uniqueness of assignments which it originates. Although, as pointed out in the text, risk of duplicate assigments is quite low, a simple search of the escrow database or some similar repository of previously assigned values would be, at a minimum, useful; I think it should be required. The imposition of a small, one-time fee for each allocation seems entirely reasonable to me, as does the requirement that allocation requests may be submitted by means other than network facilities, as well as via online access. Although not mentioned (at least to my memory) in the text, good operational practice would militate in favor of an allocation records repository mirrored in at least two widely separated geographic locations, and accessible by wholly independent network paths; however, it is to my mind an open question whether or not we need to specify this level of operational detail in the draft. *.*.* not enumerated above These sections seem entirely unobjectionable, subject to notes below. Additionally, as noted above, the conventions and mechanisms described in the extant draft will not (and, by my reading, do not purport to) resolve all the issues discussed in the IPv6 WG with regard to use of site-local addressing. In my view, additional work, almost all well beyond the scope of said draft, will be required before many of the issues enumerated below are susceptible of resolution. However, the mere fact that the draft is not catholic (note small 'c') in its obviation of problems in no way detracts from the soundness and desirability of the concepts and conventions described in said draft. Specifically, what is proposed in said draft does not: * Drive a stake through the heart of NAT It would appear that the fondest desire of many in the IPv6 WG is to consign NAT to a rapid, and exceeding painful, death. While this may be an admirable goal (for NAT is truly a pernicious beast, and productive of far more trouble than benefit), experience to date seems to show that we will not see the demise of NAT until the designers and admins of user networks have no requirements which can be satisfied by the use of NAT, or have available for each requirement which might be satisfied by a NAT implementation an alternative facility which is functionally markedly superior and administratively much less troublesome than current NAT boxes. However, the provision of globally unique address allocations (if we discount the very low risk of a collision arising from the random prefix generation algorithm) does substantially (perhaps markedly) reduce the number of
Re: IPv6 Link-Local Use Issue for Applications
On 2003-08-19 at 04:14, Mark Smith wrote: a) MAC addresses are reasonably easily to change. You can't guarantee that the end-users will follow the recommendations ie. enable the locally administered bit. Most networking people I've met don't know there is a locally administered bit in a MAC address. b) There have been cases where manufacturers have allocated non-unique MAC addresses. What is worse is that these duplications have apparently tended to happen within the same batch of NICs, and have been encountered when somebody goes to deploy a group of say 20 new NICs they have just bought, and encounter one or more duplications. c) MAC addresses are typically placed in outgoing ethernet frame headers by the device driver, not by the NIC itself, which is why it changing the MAC address of an interface is usually functionally quite easy. The device driver gets the MAC address to use from an EEPROM or something similar from the card. Bugs in that part of the device driver can cause duplicates. You are forgetting: d) Some manufacturers allocate only one MAC address per host, with the expectation that two interfaces would never end up on the same network. Sun was the canonical example, but you can turn that behaviour off in the PROM. I do not know how modern Sun machines behave. /Benny 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]
