Re: unique enough [RE: globally unique site local addresses]
Michel Py wrote: Erik Nordmark wrote: On the enterprise side I can see that folks have been bitting or are concerned about renumbering costs if they were to use PA addresses. But I don't have any data on how many consider having one PA prefix per ISP good enough since it allows some graceful cutover when changing ISPs. Not many. We have had many contributions that multiple addresses are a no-go to begin with. Er, multiple addresses are part of the IPv6 architecture. And SCTP deals with them, even if TCP doesn't. It may be something new and different, but there's no way you can declare it a no-go. Brian 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 Thu, Jan 23, 2003 at 10:04:13AM +0100, Brian E Carpenter wrote: Er, multiple addresses are part of the IPv6 architecture. And SCTP deals with them, even if TCP doesn't. It may be something new and different, but there's no way you can declare it a no-go. And we also have many different classes of multihoming scenario (just as we do with transition). There's unlikely to be one single shoehorn solution. Tim 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]
Brian, Erik Nordmark wrote: On the enterprise side I can see that folks have been bitting or are concerned about renumbering costs if they were to use PA addresses. But I don't have any data on how many consider having one PA prefix per ISP good enough since it allows some graceful cutover when changing ISPs. Michel Py wrote: Not many. We have had many contributions that multiple addresses are a no-go to begin with. Brian E Carpenter wrote: Er, multiple addresses are part of the IPv6 architecture. And SCTP deals with them, even if TCP doesn't. It may be something new and different, but there's no way you can declare it a no-go. This coin has two sides. One side is what you say above, which is very true. To set the record straight: contrary to multi6, ipv6mh has acknowledged since the beginning that multi-address host solutions are part of the big picture. They are in the charter and are being discussed. In Atlanta, we had a 1hr+ presentation from Lode Coene about SCTP, another by Christian Huitema about his solution. I'm not saying that multi-address solutions are bad, I'm the one that made them part of the big multihoming picture. That being said, the other side of the coin is that most enterprise network managers don't want multi-address schemes, and for good reasons. A large organization implements, on one form or another: - Defense in depth. - Internal firewalling. - Policy routing. - Some model like core/distribution/access. - Traffic engineering. That means several hundreds or several thousands access-lists, firewall policies, route-maps, etc. If you have three addresses per host, you triple the configuration and double the complexity, not to mention troubleshooting nightmares because you will now have to figure out which address is being used before beginning to troubleshoot. Not good. In many large organizations, there is a split between the Systems manager that could be open to a multi-address solution and the Network manager that does not want it. They might be office buddies, but they also are mortal enemies because they compete for the same scarce budget dollars. Bottom line is that in most situations, the network administrator is the one that calls the shots in terms of addressing. 3 times the complexity is effectively a no-go. In short: multiple addresses on hosts are half of the solution, but the other half is a globally unique address used as an identifier in a dual-space system. 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]
Erik Nordmark wrote: On the enterprise side I can see that folks have been bitting or are concerned about renumbering costs if they were to use PA addresses. But I don't have any data on how many consider having one PA prefix per ISP good enough since it allows some graceful cutover when changing ISPs. Not many. We have had many contributions that multiple addresses are a no-go to begin with. 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]
I have the following things running around in my brain, and they aren't converging: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. home? Having homes go from one, perhaps unstable, IPv4 address to a /48 PA address is a tremendous improvement. I don't see why homes would require global PI addresses today. On the enterprise side I can see that folks have been bitting or are concerned about renumbering costs if they were to use PA addresses. But I don't have any data on how many consider having one PA prefix per ISP good enough since it allows some graceful cutover when changing ISPs. Erik 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 Wed, 22 Jan 2003, Erik Nordmark wrote: I have the following things running around in my brain, and they aren't converging: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. home? Having homes go from one, perhaps unstable, IPv4 address to a /48 PA address is a tremendous improvement. I don't see why homes would require global PI addresses today. On the enterprise side I can see that folks have been bitting or are concerned about renumbering costs if they were to use PA addresses. But I don't have any data on how many consider having one PA prefix per ISP good enough since it allows some graceful cutover when changing ISPs. One thing I'd like to have people keep in mind is that solutions come with a price, in whatever form. I regard global PI addresses that are supposed to be globally routable having a terrible price. Of course having them would be nice, but it seems to be the disadvantages outweigh the benefits. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings 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]
If can we provide a compelling architecture without private address then there should be no private addresses, otherwise NAT is a force major issue and we have to redo all the applications which are broken by NAT (peeing against the wind has its obvious perils, so there is no reason to get upset.). I like to see this the other way around. If we invent new applications that won't work through NAT - people might find an incentive to not use it. - 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: unique enough [RE: globally unique site local addresses]
I also have the notion that the current approach of combining the locator and identifier in IPv4 and IPv6 has a lot of value that we tend to take for granted. It provides a degree of authentication that requires lots of cryptographic technology to replicate if they are separated. Instead of a bug, I think it is a feature :-) I have argued for years that this should be viewed as an engineering compromise rather than a design flaw. These days the prevailing view seems to be that it is a flaw, but the people who espouse that view haven't had to be the burden of actually making it work. 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]
Keith, I think your points on both topics are well taken. I also have the notion that the current approach of combining the locator and identifier in IPv4 and IPv6 has a lot of value that we tend to take for granted. It provides a degree of authentication that requires lots of cryptographic technology to replicate if they are separated. Instead of a bug, I think it is a feature :-) Bob a true separation of locator and identifier is a more fundamental change to the Internet architecture than moving from IPv4 to IPv6. as soon as you separate locator and identifier, you have the burden of providing a mapping service between the two, which is efficient, reliable, secure, and precise enough to be used for all applications. DNS (which is typically proposed as the solution) doesn't even come close. OTOH, mobileIP is a fairly close approximation to separating locator and identifier if you get past the notion that home agent is specific to a single host (as opposed to a set of hosts with a common prefix), and that home has anything to do with the normal physical location of a host. being able to get rid of the home agent when the host has a home and is at home is a useful optimization that works in some cases, but not in all or most cases. 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, Margaret Wasserman wrote: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. Little disgression about the meaning of PI: in many people minds, it means PI as we know it today for IPv4, which is exactly what we don't want for IPv6. It would be better to use another acronym such as GRUPI or GAPI. - We think that the use of NAT is one of the serious architectural problems facing the Internet today, and that NAT is blocking the advancement of the Internet in many ways. For an IPv6 Internet to be a success, we must avoid the wide-scale deployment of IPv6 NAT. - We don't currently have a fully developed plan for aggregable, scalable IPv6 PI addressing. Some folks are working on this problem, but no one has claimed to have a full answer yet. - We know that providing widely-used PI addresses in IPv6 will result in substantially larger routing tables than doing straight PA addressing. - We also know that routing table size is a real scaling factor in the IPv4 Internet, for which we have not determined an adequate solution. - Routing table growth is not (yet) a scaling problem for IPv6, because of limited deployment. However, wide deployment of IPv6 is also a criteria for success, so we need to build a scalable solution... - However, success must also include the avoidance of wide-scale IPv6 NAT deployment, which we can only achieve if we provide PI addresses... [Ad infinitim.] Good summary, IMHO. So, where do we go from here? Two-prong approach, see http://arneill-py.sacramento.ca.us/ipv6mh/roadmap.txt 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]
Ronald, Margaret Wasserman wrote: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. Ronald van der Pol wrote: I don't know yet if I agree or not :-) I agree that it is a good idea to explore the topic of PI addressing. But if you look at the requirements, it might be better to take a more fundamental approach and look into the separatiion of locator and identifier. Right. People don't care much about PI addresses if they have PI identifiers instead. 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]
But if you look at the requirements, it might be better to take a more fundamental approach and look into the separatiion of locator and identifier. Right. People don't care much about PI addresses if they have PI identifiers instead. a true separation of locator and identifier is a more fundamental change to the Internet architecture than moving from IPv4 to IPv6. as soon as you separate locator and identifier, you have the burden of providing a mapping service between the two, which is efficient, reliable, secure, and precise enough to be used for all applications. DNS (which is typically proposed as the solution) doesn't even come close. OTOH, mobileIP is a fairly close approximation to separating locator and identifier if you get past the notion that home agent is specific to a single host (as opposed to a set of hosts with a common prefix), and that home has anything to do with the normal physical location of a host. being able to get rid of the home agent when the host has a home and is at home is a useful optimization that works in some cases, but not in all or most cases. Keith 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]
You where not at the rebellion/ad-hoc/let's get out of here and go for bee multi6 meeting on Thursday in Atlanta. I was not actually aware of these meetings until later... I have since joined the mailing list. One thing I have been think of. Do we know what the increased prefix-length does to implementations and the effect on convergence times? What I would like to do is have someone load a bunch of routers up with the current 130k routes but with a prefix length of 128n bits, what happens? What is the cost? I don't know if anyone has studied this. It is a very interesting question. Not in the draft I have worked on now. In futuer? Yes, we will need a solution to the scaling problem, but that needs to be achieved with a routing solutions as well as perhaps a solution to addresses. Right. I think that we will actually need to make a fairly major change to the routing architecture of the Internet somewhere down the line, in order to support continued growth. I don't know what form it will take, but it will probably require some changes to IPv6, at least to the structure or allocation or IPv6 addresses. True, but it would cause IPv6 routing table growth... Do you have an answer for that? Without a question! But now we need to but time and deployment more than anything else. I'm not sure I can quite agree... I have the following things running around in my brain, and they aren't converging: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. - We think that the use of NAT is one of the serious architectural problems facing the Internet today, and that NAT is blocking the advancement of the Internet in many ways. For an IPv6 Internet to be a success, we must avoid the wide-scale deployment of IPv6 NAT. - We don't currently have a fully developed plan for aggregable, scalable IPv6 PI addressing. Some folks are working on this problem, but no one has claimed to have a full answer yet. - We know that providing widely-used PI addresses in IPv6 will result in substantially larger routing tables than doing straight PA addressing. - We also know that routing table size is a real scaling factor in the IPv4 Internet, for which we have not determined an adequate solution. - Routing table growth is not (yet) a scaling problem for IPv6, because of limited deployment. However, wide deployment of IPv6 is also a criteria for success, so we need to build a scalable solution... - However, success must also include the avoidance of wide-scale IPv6 NAT deployment, which we can only achieve if we provide PI addresses... [Ad infinitim.] So, where do we go from here? 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]
Date: Mon, 09 Dec 2002 09:50:04 -0500 From: Margaret Wasserman [EMAIL PROTECTED] Subject: Re: unique enough [RE: globally unique site local addresses] ... I have the following things running around in my brain, and they aren't converging: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. - We think that the use of NAT is one of the serious architectural problems facing the Internet today, and that NAT is blocking the advancement of the Internet in many ways. For an IPv6 Internet to be a success, we must avoid the wide-scale deployment of IPv6 NAT. By themselves, GRUPI addresses might prevent NAT6. But currently we can't handle the scaling issues with GRUPI addressess in the global routing structure, so that's a non-starter. And non-globablly-routable PI addresses won't by themselves prevent NAT6 (see below). ... So, where do we go from here? 1) We define a block for allocating GUPI addresses, and figure out how they will be allocated. 2) We define methods for allocating Site Local prefixes, possibly splitting up the SL address space into different blocks for different scenarios. I'm not convinced of the absolute need for GUPI addresses, since they are not going to be globally routable. But they do simplify some edge cases of merging/moving networks, make it easier to identify the offender when they leak into the global internet, and they might be a bit easier to deal with (than SL) in DNS. So, I don't have any objection to them. At the same time: 3) Start listing the issues with using local addressing on networks that are connected to the global internet (either GUPI or SL, the issues should the same), and then work to solve those issues. These are things like the DNS issues, and private routing between consenting sites. I think that preventing NAT6 is a big challenge. Neither SL nor GUPI addresses do anything to help us there. In fact, I think that GUPI addresses have the potential to justification of NAT6 worse. To properly run run an IPv6 network with global connectivity and with SL and/or GUPI addresses, each machine will need to be configured with at least two addresses. If it is perceived that this is difficult to do or not the proper way to do things (don't we keep discouraging running dual IPv4 networks over the same wire?), then I could see network administrators opting to use the private addresses on their networks, and using NAT6 to provide the global connectivity. And if you've *sold* them a guaranteed unique block of private address space (as opposed to them picking a SL network), I'd see them feeling even more justified in using that block. So, I don't think that providing GUPI addresses alone will do anything to prevent the use of NAT6. What will prevent NAT6 is to make sure that it is simple and easy to configure both globally routable and SL/GUPI addresses on the same network, and address the problems caused by having that configuration. Also anything to provide education about how using a firewall to protect your network is vastly superior to thinking that NAT provides security would be helpful. And lastly: 4) At this time, do not allocate globally routable/unique provider independent (GRUPI) addresses. The routing issues *have* to be figured out first. Once that happens, then I'm all for GRUPI addresses. But until there is some hope that the scaling issues can be overcome, we'd best not even start down that path. As for how far and wide SL/GUPI addresses should be used, I don't think we need to answer that up front. I think it really depends on how well we can address the issues caused by having them on networks connected to the global internet. The less we have solved, the more they should be restricted. -David Borman 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]
- We don't currently have a fully developed plan for aggregable, scalable IPv6 PI addressing. Some folks are working on this problem, but no one has claimed to have a full answer yet. AFAIK, addressing isn't the problem, routing of non-aggregatable addresses is. - We know that providing widely-used PI addresses in IPv6 will result in substantially larger routing tables than doing straight PA addressing. we don't know that. some people believe that. my belief is that such concerns are well-placed, though I don't share the belief that wide use of PI addresses inherently leads to having ISPs trying to globally route them. - We also know that routing table size is a real scaling factor in the IPv4 Internet, for which we have not determined an adequate solution. my understanding is that routing table size isn't the issue for IPv4. it was once, many years ago. last I knew, the current limiting factor was the complexity of the routing computation, and the consequent time required to adapt to changes in the topology. that's subtly different than routing table size. note however that routing table size could be an issue once again with IPv6, since flat routing of large #s of /48 prefixes would presumably exhaust the forwarding table space in most routers... Keith 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]
No. But I fail to see what we gain with creating a special block from where we assign PI addresses. The RIRs can equally well assign PI space from the current IPv6 unicast space. Sure, this will lead to growth in the size of the DFZ, but that is a routing problem. I think we're arguing the same side here... Agreed. I don't care what we call it... I don't think that this business requires more abreviation inflation:) I read your draft on multi6 regarding longer prefix multihoming, and was surprised to see your assertion regarding how far we are from having a route scaling problem in IPv6... You where not at the rebellion/ad-hoc/let's get out of here and go for bee multi6 meeting on Thursday in Atlanta. What I (and I think Thomas) said, was that we simply don't know this yet. With ~250 non 6bone routes in the DFZ we can't really telä if this is a scaling problem or not. When I configured my first BGP router we had just hit above 25k routes and people where telling me this was the end. I see a problem, but not for v6, and not now. We have no idea of how popular multihoming will be or what the impacts of cost etc will be. Maybe every mobile device will be multihomed, maybe the costs are to high? No one knows. We nee more data and experience. One thing I have been think of. Do we know what the increased prefix-length does to implementations and the effect on convergence times? What I would like to do is have someone load a bunch of routers up with the current 130k routes but with a prefix length of 128n bits, what happens? What is the cost? But, do you really think that we will continue to have fairly small routing tables if we allow every enterprise (and home?) to get its own portable address allocation? Or would we need to come up with some way to assign these addresses in an aggregable manner. In the cast above - no. But with 250 routes I am more worried about IPv6 not happening at all than us running out of scaling. You still have the dinner at stake with me. I guess that we will have (with good margin) a better understanding of the problem and the solutions in advance to a real scaling problem. Are you proposing a particular mechanism that would allow aggregation of PI address allocations? Not in the draft I have worked on now. In futuer? Yes, we will need a solution to the scaling problem, but that needs to be achieved with a routing solutions as well as perhaps a solution to addresses. True, but it would cause IPv6 routing table growth... Do you have an answer for that? Without a question! But now we need to but time and deployment more than anything else. - 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: unique enough [RE: globally unique site local addresses]
Kurt Erik Lindqvist wrote: No. Scores won't buy it. Let's not forget that one of the reasons behind the considerable success of NAT, despite its huge annoyances, it because NAT does provide some of the PI perks. PA is good for dial-up users and home/soho setups. Bigger, you find NAT, because for many the no-sweat ISP switch is worth more than the NAT-induced problems. In my experience, the number one reason for going to RFC1918/NAT is an ISP change. The ISP pulls out of a market or tanks, the customer looks at my proposal for renumbering, chokes at the bottom line, and says make sure we don't have to go through this again next time the ISP bellies up. Welcome to NAT. I am not completely convinced about the above. It would be really interesting to understand why enterprises decided to do NATs instead of PI space. My guess is that many of the companies that use NAT do it simply because they can not justify the /24. These probably don't qualify as enterprises, but nevertheless there has to be a reason to why some enterprises go for NAT, others for PI space. From my years at a large carrier I can't say there is a pattern. I wonder if it isn't as simple as knowledge. Few know how to actually apply for PI space. Sure. Their ISP told them it was hard to get space, and/or someone told them lies about NAT being a security feature. No mystery. Brian 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]
No. But I fail to see what we gain with creating a special block from where we assign PI addresses. The RIRs can equally well assign PI space from the current IPv6 unicast space. Sure, this will lead to growth in the size of the DFZ, but that is a routing problem. I think we're arguing the same side here... I'd like to see addresses available to enterprises (and home users, for that matter) with the following properties: 1) globally unique 2) provider independent (AKA portable) 3) globally routable 4) indistinguishable from provider-allocated addresses by routers, applications, etc. However, the concern that has been voiced by many in the IPv6 WG is that property (3) cannot be provided in a scalable manner. This has led to a belief that we can't have property (4), because ISPs will need to know which prefix advertisements to accept, and which to block... So let's give them PI space!!! We don't really need more abbreviations, we have the address space so far, we are still far from hitting the roof of the routing table in IPv6 I don't care what we call it... I read your draft on multi6 regarding longer prefix multihoming, and was surprised to see your assertion regarding how far we are from having a route scaling problem in IPv6... But, do you really think that we will continue to have fairly small routing tables if we allow every enterprise (and home?) to get its own portable address allocation? Or would we need to come up with some way to assign these addresses in an aggregable manner. Are you proposing a particular mechanism that would allow aggregation of PI address allocations? I know that there is a geography-based PI allocation proposal in mutli6, but I don't understand how they produce aggregation. There are multiple providers in every city, and those providers networks may not be topologically close to each other, even though they are geographically close. This would solve the uniqueness problem and take away the NAT worries. True, but it would cause IPv6 routing table growth... Do you have an answer for that? 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]
but until the ghost of Dijkstra comes out with a solution, graph theory still tells us that (2) and (3) are contradictory. or until some other things change, e.g. - ISPs are willing to route suboptimally (artifically make the graph simpler) - we work out a way to compute routes on-the-fly (caching ones that have been recently used) rather than pre-computing the entire table (this probably implies that we push route computation to the edges and source-route through the core) - we require certain interconnection paths (e.g. requiring major population centers to have a central peering point) in order to make the graph simpler in other words, a substantial change to the routing architecture (heavy technical change) and/or enforced constraints on interconnection (heavy political change) even if we solve the route computation problem, it's hard for me to imagine with forwarding tables containing ~ 2**48 prefixes. Keith 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]
1) globally unique 2) provider independent (AKA portable) 3) globally routable 4) indistinguishable from provider-allocated addresses by routers, applications, etc. Margaret, Routing solutions have to consider have to be considered with two angles, politics and graph theory. The points you are making may be great politics, but until the ghost of Dijkstra comes out with a solution, graph theory still tells us that (2) and (3) are contradictory. -- 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: unique enough [RE: globally unique site local addresses]
No. Scores won't buy it. Let's not forget that one of the reasons behind the considerable success of NAT, despite its huge annoyances, it because NAT does provide some of the PI perks. PA is good for dial-up users and home/soho setups. Bigger, you find NAT, because for many the no-sweat ISP switch is worth more than the NAT-induced problems. In my experience, the number one reason for going to RFC1918/NAT is an ISP change. The ISP pulls out of a market or tanks, the customer looks at my proposal for renumbering, chokes at the bottom line, and says make sure we don't have to go through this again next time the ISP bellies up. Welcome to NAT. I am not completely convinced about the above. It would be really interesting to understand why enterprises decided to do NATs instead of PI space. My guess is that many of the companies that use NAT do it simply because they can not justify the /24. These probably don't qualify as enterprises, but nevertheless there has to be a reason to why some enterprises go for NAT, others for PI space. From my years at a large carrier I can't say there is a pattern. I wonder if it isn't as simple as knowledge. Few know how to actually apply for PI space. 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: unique enough [RE: globally unique site local addresses]
What I am failing to understand is what we are looking for. The insert letterGUPI model will drive the development of NATs. Why do you think so? Well, see my mail to Keith. I think that people have to much strange ideas on what NATs will give them, that anything that will have a scope will lead them down that road. What I am failing to understand is what benefits the complexity and additional administration of either GUPIs or GUSLs will give us over just assigning plain IPv6 addresses. In particular, why do you think that GUPI addresses would drive the development of NATs any more than the current IPv6 site-local addresses? I think both have the potential to drive us down that road. SLs probably more than the other. Do you really think that it is realistic to just tell everyone to use provider-assigned addresses throughout their network? No. But I fail to see what we gain with creating a special block from where we assign PI addresses. The RIRs can equally well assign PI space from the current IPv6 unicast space. Sure, this will lead to growth in the size of the DFZ, but that is a routing problem. I just get the feeling that we are using to much duck tape to work around a different problem. We've been getting feedback from network administrators that they need a form of local addressing that allows their internal numbering, firewall configuration, etc. to be independent of their ISP-provided addresses. So let's give them PI space from the RIRs pools of IPv6 addresses. Currently I am more worried about the lack of assignments from the RIRs rather than them assigning to many. People want to use site-locals for this, but the ambiguity of site-locals causes all sorts of problems for applications, routing protocols, transport protocols, etc. especially when running on site border nodes (nodes that are in more than one site at the same time). It is my belief that if we ignore this problem, and simply limit site- locals to disconnected networks (a la RFC 1918 addresses), then IPv6 NAT will arise to allow sites to separate internal addressing from external addressing. So let's give them PI space!!! We don't really need more abbreviations, we have the address space so far, we are still far from hitting the roof of the routing table in IPv6 This would solve the uniqueness problem and take away the NAT worries. What we really need is a better way to solve this problem, one that doesn't have the problems of site-local addresses. And, that's why we're discussing GUPI addresses. Is there a better way to solve this problem that we haven't considered? Real addresses? - 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: unique enough [RE: globally unique site local addresses]
1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI. 3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it. I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3. why doesn't #1 suffice for #2? 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]
1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). T his is GUPI. 3. Global network layer PI identifiers. Although this is not directly linke d to the multihoming issue, it is likely that a scalable multihoming solution would provide it. I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3. why doesn't #1 suffice for #2? Keith are you sure you ment this? #2 works for #1 not the other way around. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [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: unique enough [RE: globally unique site local addresses]
why doesn't #1 suffice for #2? Keith are you sure you ment this? #2 works for #1 not the other way around. right you are. I transposed them. Keith 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]
Keith, Michel Py wrote: 1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI. 3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it. Keith Moore wrote: why doesn't #2 suffice for #1? [I transposed it back the way you meant] Because #2 does not exist today. You must provide #2 before you try to kill #1. Network administrators do not design production networks with promises. 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]
why doesn't #2 suffice for #1? [I transposed it back the way you meant] Because #2 does not exist today. You must provide #2 before you try to kill #1. well, then I strongly recommend that we do that. Keith 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]
What I am failing to understand is what we are looking for. The insert letterGUPI model will drive the development of NATs. Why do you think so? In particular, why do you think that GUPI addresses would drive the development of NATs any more than the current IPv6 site-local addresses? Do you really think that it is realistic to just tell everyone to use provider-assigned addresses throughout their network? We've been getting feedback from network administrators that they need a form of local addressing that allows their internal numbering, firewall configuration, etc. to be independent of their ISP-provided addresses. People want to use site-locals for this, but the ambiguity of site-locals causes all sorts of problems for applications, routing protocols, transport protocols, etc. especially when running on site border nodes (nodes that are in more than one site at the same time). It is my belief that if we ignore this problem, and simply limit site- locals to disconnected networks (a la RFC 1918 addresses), then IPv6 NAT will arise to allow sites to separate internal addressing from external addressing. What we really need is a better way to solve this problem, one that doesn't have the problems of site-local addresses. And, that's why we're discussing GUPI addresses. Is there a better way to solve this problem that we haven't considered? 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]
Margaret Wasserman wrote: Do you really think that it is realistic to just tell everyone to use provider-assigned addresses throughout their network? No. Scores won't buy it. Let's not forget that one of the reasons behind the considerable success of NAT, despite its huge annoyances, it because NAT does provide some of the PI perks. PA is good for dial-up users and home/soho setups. Bigger, you find NAT, because for many the no-sweat ISP switch is worth more than the NAT-induced problems. In my experience, the number one reason for going to RFC1918/NAT is an ISP change. The ISP pulls out of a market or tanks, the customer looks at my proposal for renumbering, chokes at the bottom line, and says make sure we don't have to go through this again next time the ISP bellies up. Welcome to NAT. Having two of the tier-1 ISPs in bankruptcy does not help this feeling. We've been getting feedback from network administrators that they need a form of local addressing that allows their internal numbering, firewall configuration, etc. to be independent of their ISP-provided addresses. Network administrators want three things: 1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI. 3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it. I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3. It is my belief that if we ignore this problem, and simply limit site-locals to disconnected networks (a la RFC 1918 addresses), then IPv6 NAT will arise to allow sites to separate internal addressing from external addressing. Agreed. And we should not underestimate the danger of this, as there is a lot of working v4 NAT code out there and transforming v4 NAT code into v6 NAT code is a lot less work that writing NAT from scratch 5 years ago. Most of the ALGs issues have been sorted out already. What we really need is a better way to solve this problem, one that doesn't have the problems of site-local addresses. And, that's why we're discussing GUPI addresses. Agreed. Unfortunately, one of the main issues with GUPI addresses is managing the risk they end up being a mess in the global routing table, à la IPv4 swamp. So far, the lack of a multihoming solution has been a strong enough disincentive to kill GUPI attempts in the egg before they were even born. Any GUPI proposal will have to address this. 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]
Uhm, if they are truely unique, the only difference to global addresses is that they won't be routed - right? Now, what is the difference between that and using global unicast address space that you do not announce? Virtually nothing, except that this address space would be provider-independent, so you would not have to renumber, etc. when you change ISPs. Also, your ISP would not be obligated to route it globally and would probably filter it. I'm actually in favor of a globally-unique/provider-independent address space that is routable, with borders of the address space administratively determined and enforced via filtering rules in routers/firewalls. But if there is no difference we are suggesting to create PI space right? And leave the scaling problem of the routing table to multi6 group where it belongs? What I am failing to understand is what we are looking for. The insert letterGUPI model will drive the development of NATs. Actually this would build NATs into the Internet architecture permanently. A number or people have pointed to the problems of this. That besides, if we now (I hope not) creates GUPI space, why do I then need site-locals as well? Why do we need a separate allocation for GUPI? This could be all of the unicast addresses in IPv6. Isn't this more or less 8+8? - 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: unique enough [RE: globally unique site local addresses]
The insert letterGUPI model will drive the development of NATs. that's just nuts. GUPIs don't encourage NATs any more than any other aspect of IPv6. I'm beginning to think that citing NATs as a reason for not doing something in IPv6 is like comparing someone to Hitler in a political discussion - it's such an extreme statement that it can't be evaluated. Keith 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 Tue, 26 Nov 2002, Pekka Nikander wrote: There is just one thing that I want to repeat: If you give people something that is globally unique and stable, that is, something that looks, smells and tastes as globally unique stable identifiers, they will start to use them as such, sooner or later. We should not underestimate the desirability of such identifiers in the face of changing prefixes. Not all innovation is limited within the IETF. I agree 100%. We should not try to make globally unique site-locals too attractive, because, well, they're not _meant_ to be attractive. We have globals in IPv6, you know. I'd actually like to use _globals_, not some site-local addresses. (in the random site-id proposal, the uniqueness probability may even be high to prevent this..) -- 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: unique enough [RE: globally unique site local addresses]
Pekka, Pekka Nikander wrote: There is just one thing that I want to repeat: If you give people something that is globally unique and stable, that is, something that looks, smells and tastes as globally unique stable identifiers, they will start to use them as such, sooner or later. We should not underestimate the desirability of such identifiers in the face of changing prefixes. Not all innovation is limited within the IETF. I totally agree with you, that's why I insist so much on enforcing non-routability of these addresses by having both the default black hole that Bob suggested and the default BGP discard that I suggested a while ago. Without these, GUPI would be transformed into PI before we know it and the routing table will explode. 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]
Michel, My $0.02 about the hash/random/collision issue: It's a non-issue. I would agree with you, but only if I shared the same view of the GUPI prefix usage. That is, if GUPIs are really used only by explicit administrator action in big corporations, then fine. But unfortunately I don't believe so. The prefix generation happens only one time for the site. Collisions would not be detected until two sites merge or establish a VPN connection. Agreed. Though, I can vision dynamic sites that are created and dismissed fairly often. OTOH, if we decide to define a GUPI address space, we can formulate the usage guidelines so that they should not be used in such a case, and that a still another type of addresses are needed for such sites. 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. Agreed. But I can also see a semi-automatic case; a SOHO or non-IT company configuring their network, and pushing a button to generate a site prefix for their network. Most probably they would not want to pay the *trouble* of registering their prefix; still the fee might be a non-issue for them. A site note: The reason for the registration fee is to discourage prefix hoarding. The fee can be lower than the trouble needed for registering a single prefix. (When registering multiple prefixes, the trouble for the subsequent prefixes is much lower than in the beginning, since learning is a big part of the initial trouble.) 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. Hmm. I would agree that this is the case today, more or less. But, iff small sites become common, the situation would be different. If I remember correctly, one of the design goals in the whole IPv6 standardization has been minimization of human intervention. That's the reason why we have address autoconfiguration, that's the reason why we have been developing router renumbering etc. Or am I mistaken? Thus, I think that *if* we create these GUPI prefixes, their creation should be semi-automatic. Not fully automatic since they are not always needed. But, sure, we can start with a completely manual process and revise it later, if people feel that there is some danger is such a semi-automatic creation. 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. There will be sites that do not have Internet access at the time they want to configure their prefix. Either they will hand pick one, most probably causing unnecessary collisions, or the process should be semi-automatic, with built-in assistance in routers or in router configuration software. --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]
Michel Py wrote: My $0.02 about the hash/random/collision issue: It's a non-issue. Pekka Nikander wrote: I would agree with you, but only if I shared the same view of the GUPI prefix usage. This much is clear. That is, if GUPIs are really used only by explicit administrator action in big corporations, then fine. But unfortunately I don't believe so. The prefix generation happens only one time for the site. Collisions would not be detected until two sites merge or establish a VPN connection. Agreed. Though, I can vision dynamic sites that are created and dismissed fairly often. OTOH, if we decide to define a GUPI address space, we can formulate the usage guidelines so that they should not be used in such a case, and that a still another type of addresses are needed for such sites. 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. Agreed. But I can also see a semi-automatic case; a SOHO or non-IT company configuring their network, and pushing a button to generate a site prefix for their network. Most probably they would not want to pay the *trouble* of registering their prefix; still the fee might be a non-issue for them. A site note: The reason for the registration fee is to discourage prefix hoarding. The fee can be lower than the trouble needed for registering a single prefix. (When registering multiple prefixes, the trouble for the subsequent prefixes is much lower than in the beginning, since learning is a big part of the initial trouble.) 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. Hmm. I would agree that this is the case today, more or less. But, iff small sites become common, the situation would be different. If I remember correctly, one of the design goals in the whole IPv6 standardization has been minimization of human intervention. That's the reason why we have address autoconfiguration, that's the reason why we have been developing router renumbering etc. Or am I mistaken? Thus, I think that *if* we create these GUPI prefixes, their creation should be semi-automatic. Not fully automatic since they are not always needed. But, sure, we can start with a completely manual process and revise it later, if people feel that there is some danger is such a semi-automatic creation. 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. There will be sites that do not have Internet access at the time they want to configure their prefix. Either they will hand pick one, most probably causing unnecessary collisions, or the process should be semi-automatic, with built-in assistance in routers or in router configuration software. --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]
Pekka, Michel Py wrote: My $0.02 about the hash/random/collision issue: It's a non-issue. Pekka Nikander wrote: I would agree with you, but only if I shared the same view of the GUPI prefix usage. This much is clear. However, I think the use you envision for GUPI is dangerous and will lead to NAT, which is also clear in the opinion you expressed about GUPI encouraging or discouraging NAT. In the example you use, a SOHO configuring their network, use of GUPI is a disaster, IMHO. Site-locals are not for SOHO sites, they need to talk to the public Internet. These people need to use global addresses. I don't challenge the need for globally unique PI addresses, but this would be GAPI not GUPI. As I mentioned before, we MUST NOT encourage the use of site-locals for people that don't understand their limitations, and this certainly applies to the SOHO example you used. GUPI still is site-local addresses, which are not routable on the public Internet, and will be successful in enterprises only if the comfort level of the administrator as reached the level that he is happy with the enforcement of non-routability. Back to what started this, the main four characteristics of GUPI are: 1. No fee and/or low fee. 2. No registration and/or easy registration. 3. Globally unique. 4. Not globally routable. I don't challenge the need for globally routable, globally unique identifiers. As a matter of fact, the scheme I proposed for GUPI is a spin-off GAPI. That being said, this is not the same battle. In the case of GUPI, we already have a block allocated for it: FEC0::/10. If we don't change the purpose of the block which is site-locals, there is a shorter path to success than GAPI that would require IANA to allocate a new block and is full of issues concerning the explosion of the global routing table. My message is: one problem at a time. GUPI is achievable short-term, not GAPI. Let's focus on what we can do now, which is globally unique, not globally routable and when this hurdle has been cleared then we can process towards globally unique and globally routable. 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]
On Mon, Nov 25, 2002 at 08:51:45AM -0800, Michel Py wrote: As I mentioned before, we MUST NOT encourage the use of site-locals for people that don't understand their limitations, and this certainly applies to the SOHO example you used. So how do I print to my net printer in between connections to my ISP when I get a different prefix each time I connect? I want some kind of addresses to use locally equivalent to Net10. Not for NAT, but to communicate internally while offline. I think this discussion has forgotten a lot of the pro/con points made in the previous 500-mail thread, and at Atlanta :) tim 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]
Tim, Michel Py wrote: As I mentioned before, we MUST NOT encourage the use of site-locals for people that don't understand their limitations, and this certainly applies to the SOHO example you used. Tim Chown So how do I print to my net printer in between connections to my ISP when I get a different prefix each time I connect? I want some kind of addresses to use locally equivalent to Net10. Not for NAT, but to communicate internally while offline. This is a perfectly valid use of site-locals, my point was that we should not generalize the use when there are alternative methods. To some extent, site-locals are too easy. If you _choose_ to use them, OK. But a router MUST NOT offer site-locals as a default. Let me emphasize again that none of this stuff goes anywhere is there is no default enforcement of non-routability along the lines that Bob Hinden, Christian Huitema and myself have contributed, and I have not heard many comments about that part. Indeed. I'm a little confused that GUPI = site-local, nothing really new only we're (in PekkaS's method) just randomising which site-local is used, so all the bad things of site-locals remain I hear that lots of the issues have something to do with ambiguity. By making site-locals globally unique (GUPI) we remove ambiguity and take some of the problems out. 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]
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: 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: 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: unique enough [RE: globally unique site local addresses]
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. 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]
48 bits MAC is not globally unique (found that out the hard way). But hashing several MACs on the links of a disconnected sites toghere with a timestamp will do I guess. 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? 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]
Uhm, if they are truely unique, the only difference to global addresses is that they won't be routed - right? Now, what is the difference between that and using global unicast address space that you do not announce? Virtually nothing, except that this address space would be provider-independent, so you would not have to renumber, etc. when you change ISPs. Also, your ISP would not be obligated to route it globally and would probably filter it. I'm actually in favor of a globally-unique/provider-independent address space that is routable, with borders of the address space administratively determined and enforced via filtering rules in routers/firewalls. 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]
Pekka Savola wrote: Take your name, address, phonenumber or whatever (it must be long enough, though), apply a hash function and BAM -- there you have unique enough site-id identifier. No need for any registrations etc. We still need to avoid user input for self-configuring home networks etc. How about a hash of the IEEE MAC address of the node that created the site? 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: unique enough [RE: globally unique site local addresses]
Pekka, Pekka Savola wrote: One idea IMO is that we don't even want to be aim for total, provable, complete uniqueness. Looking at some requirements, I believe unique enough is good enough. Take your name, address, phonenumber or whatever (it must be long enough, though), apply a hash function and BAM -- there you have unique enough site-id identifier. No need for any registrations etc. This is a valid approach also. However, one might argue that it would be nice to do it the right way and make them truly unique if it is not too much of a hassle. But I don't think we should be providing _globally routable_ addresses in the first place. They answer some other problems than the one that's an argument in the site-local discussion. Strongly agree. 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]
On Thu, 21 Nov 2002, Jari Arkko wrote: Take your name, address, phonenumber or whatever (it must be long enough, though), apply a hash function and BAM -- there you have unique enough site-id identifier. No need for any registrations etc. We still need to avoid user input for self-configuring home networks etc. How about a hash of the IEEE MAC address of the node that created the site? Sure -- and take some other things in consideration. (I don't know whether MAC address in itself will provide enough material for a reliable hash, but I could see a possibility of it working.) -- 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: unique enough [RE: globally unique site local addresses]
This is a valid approach also. However, one might argue that it would be nice to do it the right way and make them truly unique if it is not too much of a hassle. Uhm, if they are truely unique, the only difference to global addresses is that they won't be routed - right? Now, what is the difference between that and using global unicast address space that you do not announce? - 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: unique enough [RE: globally unique site local addresses]
Kurtis, Kurt Erik Lindqvist wrote: Uhm, if they are truely unique, the only difference to global addresses is that they won't be routed - right? Now, what is the difference between that and using global unicast address space that you do not announce? From the enterprise point of view the difference is that when a hacker (or your own staff) screws up the BGP filtering, it will not go far unless all ISPs in the Internet mess it up at the same time. 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]
