Important IPv6 Policy Issue -- Your Input Requested
I would like to bring to the attention of Nanog an IPv6 policy issue that I think is slipping under the radar right now. The IETF IPv6 working group is considering two proposals right now for IPv6 "private networks". Think RFC-1918 type space, but redefined for the IPv6 world. Those two drafts can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt These drafts came up in the ARIN meeting, and I posted my analysis of the problems with both at: http://www.arin.net/mailing_lists/ppml/2849.html I will post a very brief summary of my objections, for the first (unique-local): - I believe the math is wrong on the rate of collisions, primarily because it assumes in a large organization there is a central coordination function to pick and distribute these addresses. However, since the whole point of "unique local" addresses is that there need be no coordination, I can easily see a case where a large conglomerate (Ford, GE, whatever) coming together with another will have both sides bringing hundreds, if not thoundsands of prefixes to the table as each division or other subgroup picks their own. - I think the likelyhood people will use the suggested hash methods to pick addresses is extremely low. People will either pick "human friendly" (1, 2, 3, 4, etc) or treat the space more like CIDR (where there is central delegation), both of which move the likelyhood of collision to near 1. In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today. The second proposal (ula-central) is much more dangerous. - It is not good engineering to give something away for free with no method of recovery, even if that resource is plentiful. - The IETF should not be creating a new worldwide RIR. - The IETF should not be dictating fees (free). (more to the point, a worldwide RIR, with the language and other issues will be expensive, yet it has no method of income) - Since this is a free method of globally unique space it has a high likelyhood of being routed on portions of the public internet. Indeed, this problem was quickly dismissed by the authors (see http://www1.ietf.org/mail-archive/web/ipv6/current/msg03848.html), who completely missed the boat. It's not the rich who would demand their prefix be routed, but the poor. We already have situations where parts of Africa and Asia claim the fees for IP space are too high. If they had access to "free" "global" space they would jump on it, and later if the rest of the world wanted to contact that region they would almost certainly have to route it as well. - The "ownership should be private", yet the reason for a registry is to verify ownership and prevent hoarding. I'm not sure how those are combatable. - I think the IPv6 groups continue in their fantasy that people will manage multiple, complete overlay networks to fix numbering issues. More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet. Since this is a list of providers, I encourage you to read the drafts, and submit your comments to the working group. The information for the working group is at http://www.ietf.org/html.charters/ipv6-charter.html, and includes their mailing list archives and information on how to subscribe and/or post. Even if you disagree with me, much like voting the important thing is that you voice your opinion. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On 8 Nov 2004, at 14:25, Leo Bicknell wrote:
In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today.
Just out of interest, why do you think 1918-style space for v6 is needed? Joe
In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote:
Just out of interest, why do you think 1918-style space for v6 is needed?
I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6. However, both of these proposals go well beyond how 1918 space works today, and both make promises of "global uniqueness" that are at best inappropriate, at worst a road to disaster. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On 8 Nov 2004, at 14:53, Leo Bicknell wrote:
In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote:
Just out of interest, why do you think 1918-style space for v6 is needed?
I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6.
I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.) I know of lots of networks that use RFC1918 addresses because of a (perceived, whatever) scarcity of IPv4 addresses, but presumably that argument doesn't necessarily follow for v6 networks, where ever customer site gets a /48. There is some value in RFC1918 addresses being used in v4 in cases where an extensive internal infrastructure is expensive to renumber, and PI addresses are not available. It is not clear that RFC1918 addresses are the only solution to this problem, though.
Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6.
This sounds like a direct path to IPv6 NAT.
However, both of these proposals go well beyond how 1918 space works today, and both make promises of "global uniqueness" that are at best inappropriate, at worst a road to disaster.
Agreed, the proposals (as you outlined; I haven't read them) sound like they are full of holes. However, I worry about any natural assumption that RFC1918-like addresses are required for v6, simply because they are used in v4: it seems to me that the major reason to deploy v6 is to eliminate the very address scarcity that RFC1918 addresses are used to mitigate. Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing ;-) Joe
In a message written on Mon, Nov 08, 2004 at 03:08:13PM -0500, Joe Abley wrote:
I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.)
By "applications" I did not mean "software programs" but rather "methods of designing networks".
I know of lots of networks that use RFC1918 addresses because of a (perceived, whatever) scarcity of IPv4 addresses, but presumably that argument doesn't necessarily follow for v6 networks, where ever customer site gets a /48.
A company may change providers often and want to use 1918 style space to not have to renumber part of the network, or may choose IPv6 NAT as superior to overlay networks. Indeed, I suspect overlay networks are going to be hugely unpopular.
This sounds like a direct path to IPv6 NAT.
While I do not encourage IPv6 NAT, anyone who thinks IPv6 will put the NAT Genie back in the bottle is smoking some serious crack. Lots of people like NAT for lots of reasons, and I am 100% positive there will be IPv6 NAT used by a lot of people. One obvious use if these proposals pass is to use your non-routable global unique prefix internally and NAT at the borders. Since a lot of people think this is effective security, I think it will be a common configuration.
Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing ;-)
Many people share your opinion, and I think it is a good one to voice. That said at the end of the day most engineers are going to treat IPv6 as "IPv4 with bigger addresses". I know most of the IPv6 proponents just wrote me off as a loon by saying that, but I do believe it's reality and you need look no further than the existing test networks to see that it's the case. People who have become used to CIDR, and NAT and such aren't going to forget those idea's because someone told them "rigid boundaries are good" and "you don't need private space anymore". -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Mon, 8 Nov 2004, Joe Abley wrote:
Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing ;-)
You're definitely not alone with this feeling :-). It's just that there are some conceivable scenarios, like intermittent connectivity (+local connectivity during the outage) which seems to call for either local addressing or global PI addressing, and the latter has not gained much momentum.. IPv6 site multihoming for bigger enterprises is also one area where (at the moment) something like ULAs have some questionable uses. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.)
There are a number of good and reasonable uses for RFC1918 addresses. Just assume a individual/business/corporate LAN with client/server applications and statically configured ip numbering. RFC1918 addresses are perfect. NAT allows this network to be connected through any provider(s) to the Internet. There is no risk of collision of the internal address with publically routed addresses. To do without RFC1918 type address space it expect to a. Obtain unique, permanent address space for personal/business/corporate use b. Receive this unique, permanent address space at no cost c. Have this unique address space routed via any provider of my choosing Adi
On 8 Nov 2004, at 18:18, Adi Linden wrote:
I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.)
There are a number of good and reasonable uses for RFC1918 addresses.
[one reasonable use]
Yes, I mentioned that in the paragraph following the one you quoted. There is more than one way to skin that cat, however, and not every way requires RFC1918 address analogues to be made available in v6. Joe
--On måndag 8 november 2004 17.18 -0600 Adi Linden <adil@adis.on.ca> wrote:
RFC1918 addresses are perfect.
My AFS, Kerberos, and active FTP sessions think that you are being very, very optimistic about the usability of non-unique adresses and kludgy middleboxen who think they understand networking. There /are/ other protocols besides HTTP, you know. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
My AFS, Kerberos, and active FTP sessions think that you are being very, very optimistic about the usability of non-unique adresses and kludgy middleboxen who think they understand networking.
Don't forget IPSec, and Cisco skinny IP telephone protocol, and of course more importantly, my half-life game server. I'd have to agree, NAT is a kludgy fix at best.
On Mon, Nov 08, 2004 at 05:18:49PM -0600, Adi Linden wrote:
There are a number of good and reasonable uses for RFC1918 addresses. Just assume a individual/business/corporate LAN with client/server applications and statically configured ip numbering. RFC1918 addresses are perfect. NAT allows this network to be connected through any provider(s) to the Internet. There is no risk of collision of the internal address with publically routed addresses.
To do without RFC1918 type address space it expect to
a. Obtain unique, permanent address space for personal/business/corporate use b. Receive this unique, permanent address space at no cost c. Have this unique address space routed via any provider of my choosing
I see this a lot recently: You are mixing up RfC1918 and NAT. If I have globally unique addresses I can NAT them as well as 10/8. One has nothing to do with the other. Having to NAT RfC1918 addresses to reach the internet, does not imply that I have to have RfC1918 to be able to do NAT. Nils
There are a number of good and reasonable uses for RFC1918 addresses. Just assume a individual/business/corporate LAN with client/server applications and statically configured ip numbering. RFC1918 addresses are perfect. NAT allows this network to be connected through any provider(s) to the Internet. There is no risk of collision of the internal address with publically routed addresses.
To do without RFC1918 type address space it expect to
a. Obtain unique, permanent address space for personal/business/corporate use b. Receive this unique, permanent address space at no cost c. Have this unique address space routed via any provider of my choosing
I see this a lot recently: You are mixing up RfC1918 and NAT.
If I have globally unique addresses I can NAT them as well as 10/8. One has nothing to do with the other.
Having to NAT RfC1918 addresses to reach the internet, does not imply that I have to have RfC1918 to be able to do NAT.
What are my options today to obtain ip address space? My requirements are well met by a /27 subnet. ARIN won't give me a globally unique /27 for personal use. So the /27 comes from my service provider, which has several caveats. I cannot multi-home. I cannot keep my address space when changing providers. I most likely cannot keep my address space moving to a different city but staying with the same provider. About half of the devices within my on private network are statically defined and for local use only. They will never need global access. Because they are awkward to configure I do not want to renumber, ever. My solution is to use RFC1918 address space for this network. RFC1918 address space is free and plentiful for my purposes. It is provider independent. It is globally unique in the sense that no other publically routed network is using them. My globally unique address will come from my provider of the day. NAT is my technology of choice to connect to the global internet, but other solutions are possible. If I understand correctly, ipv6 will force me into using provider dependent globally unique address space. Unless my provider of the day is required to assign me address space that is and/or permanently assigned and portable it does not meet my needs. Why not? I am not willing to renumber when I change providers. I have no problem using NAT to obtain connectivity from provider B using providers A address space internally. But that only works if provider A is prevented from reusing 'my' addresses if I terminate my contract. And what do I do if I build my network without ties to any provider? Can I go to ARIN to get globally unique address space, an ipv6 /48? Without RFC1918 that would be my only choice to prevent from overlapping my network with someone elses. If you're telling me that I can get provider independent globally routable address space for a small network at a reasonable cost I'd jump for joy and never look at RFC1918 again. But I don't see that offered as an option, so an RFC1918 block in ipv6 makes all the sense in the world to me. Adi
On Thu, 2004-11-11 at 09:36 -0600, Adi Linden wrote: <SNIP>
Having to NAT RfC1918 addresses to reach the internet, does not imply that I have to have RfC1918 to be able to do NAT.
What are my options today to obtain ip address space? My requirements are well met by a /27 subnet. ARIN won't give me a globally unique /27 for personal use. So the /27 comes from my service provider, which has several caveats. I cannot multi-home. I cannot keep my address space when changing providers. I most likely cannot keep my address space moving to a different city but staying with the same provider.
A /27 will be nicely filtered out at most ISP's anyway, thus it doesn't make sense to announce that in the global routing table and adding another useless entry, A /27 contains at most 32 hosts (even less when doing proper broadcast etc), thus I don't see the problem in renumbering there actually ;) Unfortunately not everybody is big enough to play along in the big routing game. If you where a big enough fish you would also be able to get a nice spot in the routing tables, but you will need to have at least a /24 at the moment... I guess you also want to announce a /64 into the IPv6 BGP tables ? Everybody else would want to, and then we have to expand to 32bit ASN's, hey wait IPv4 is 32bit, and then we are using 32bit ASN's to route IPv6, thus basically we are using the IPv4 addresses to route IPv6, there is a limit somewhere I hope ;) Though as long as we keep with 16bit ASN's there should not be a huge problem as long as every ASN only announces one prefix, then we would be at 65k prefixes maximum, which is 1/3rd of the current IPv4 space. Currently there are only ~650 prefixes in the IPv6 global routing tables, thus it can grow a bit for some while. Greets, Jeroen
I guess you also want to announce a /64 into the IPv6 BGP tables ?
Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? So if RFC 2462 is right, and you use DNS outside your network and you update that DNS at the moment of switching providers, everything on your network automatically acquires new IPv6 globally routable addresses as soon as the gateway router is connected to the new provider. Seems to me that with a little bit of help from a "Change providers" tool, this would be virtually painless without the need to own or announce a small globally unique prefix. --Michael Dillon
First issue is that IPv6 interfaces support both the old & new prefixes at the same time, so the provider change case is not as dramatic as people fear based on past IPv4 experience. Second: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-0 1.txt talks about other issues that make renumbering non-trivial. Tony
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Michael.Dillon@radianz.com Sent: Thursday, November 11, 2004 8:22 AM To: nanog@Merit.edu Subject: IPV6 renumbering painless?
I guess you also want to announce a /64 into the IPv6 BGP tables ?
Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? So if RFC 2462 is right, and you use DNS outside your network and you update that DNS at the moment of switching providers, everything on your network automatically acquires new IPv6 globally routable addresses as soon as the gateway router is connected to the new provider. Seems to me that with a little bit of help from a "Change providers" tool, this would be virtually painless without the need to own or announce a small globally unique prefix.
--Michael Dillon
In a message written on Thu, Nov 11, 2004 at 04:22:28PM +0000, Michael.Dillon@radianz.com wrote:
Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? So if RFC 2462 is right, and you use DNS outside your network and you update that DNS at the moment of switching providers, everything on your network automatically acquires new IPv6 globally routable addresses as soon as the gateway router is connected to the new provider. Seems to me that with a little bit of help from a "Change providers" tool, this would be virtually painless without the need to own or announce a small globally unique prefix.
That is how it has been designed, however there are some practical problems with this system: - Until very recently DNS software did not support A6 records at all, and "chain" support for A6 records still seems to be a work in progress. - I presume the problem with using DNS to find your DNS servers is obvious, so you probably still need a mechanism (static config, DHCP) to push out nameserver addresses to all boxes at some point in the cut over. - This solution works only to update the interface IP address on a box, and does not address any of the other application configurations that might need to be updated, including but not limited to: - ACL's on the box or routers to allow/disallow the new network. - Network analysis tools to include the new network. - IGP or BGP configuration to include the new network. - Also note, if you are unable to have the two services overlap (eg, must disconnect from the first, and then hours, days, weeks) connect to the second you have the potential to lose access to all your boxes locally in the mean time with this system. The solution is some sort of site-local/1918/ula address overlay. It is the last point that leads to the most interesting problem. If you create a local overlay network to always maintain access to your local boxes, then is it actually easier to push out an additional IP address to every end box, and update your IGP, firewall rules, and other configs, or is it easier to run NAT at the edge to convert your local network to public IP's? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
So if RFC 2462 is right, and you use DNS outside
its not.
That is how it has been designed, however there are some practical problems with this system:
- Until very recently DNS software did not support A6 records at all, and "chain" support for A6 records still seems to be a work in progress.
as in -DEAD- A6 records are DEAD. not useful. not in the code base... DEAD.
Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
--On Thursday, November 11, 2004 11:37 AM -0500 Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Thu, Nov 11, 2004 at 04:22:28PM +0000, Michael.Dillon@radianz.com wrote:
Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? So if RFC 2462 is right, and you use DNS outside your network and you update that DNS at the moment of switching providers, everything on your network automatically acquires new IPv6 globally routable addresses as soon as the gateway router is connected to the new provider. Seems to me that with a little bit of help from a "Change providers" tool, this would be virtually painless without the need to own or announce a small globally unique prefix.
That is how it has been designed, however there are some practical problems with this system:
I still think that we should pursue making the design work and not adopt cruft as standards (ULA).
- Until very recently DNS software did not support A6 records at all, and "chain" support for A6 records still seems to be a work in progress.
This is getting resolved and I suspect will be long since functional by the time v6 comes to widespread deployment consideration.
- I presume the problem with using DNS to find your DNS servers is obvious, so you probably still need a mechanism (static config, DHCP) to push out nameserver addresses to all boxes at some point in the cut over.
If you're willing to use DHCP, then, why not use a similar helper mechanism to find the resolver... Host that doesn't know it's resolver or can no longer reach it's resolver sends some form of a standardized "Who's my resolver" query to the link-local broadcast address. If there's a resolver on the local link, then the resolver(s) respond "I am." If not, the router is either configured with resolver addresses and can respond "They are." or is configured with a resolver-helper address which would function identically to the current dhcp-helper addresses. In this case, as long as the router had an interface on a link which contained a resolver, no reconfiguration of the route would be necessary, since it could use the resolvers link-local address. In fact, the router could dynamically learn the resolvers through a similar mechanism. If your organization is large enough to involve reconfiguring a significant number of routers, it is unlikely to be small enough to have to use PA space instead of getting PI space in the v6 world.
- This solution works only to update the interface IP address on a box, and does not address any of the other application configurations that might need to be updated, including but not limited to:
- ACL's on the box or routers to allow/disallow the new network.
I would argue that ACL's in the v6 world should probably include A6 support.
- Network analysis tools to include the new network.
Again, no reason these can't be based on A6 resolution instead of hard-coded IP addresses.
- IGP or BGP configuration to include the new network.
If you are large enough for IGP configuration for the new network to be a major undertaking, then, you probably qualify for PI space. If you are large enough that BGP is more than a couple of routers that need changing, you probably qualify for PI space.
- Also note, if you are unable to have the two services overlap (eg, must disconnect from the first, and then hours, days, weeks) connect to the second you have the potential to lose access to all your boxes locally in the mean time with this system. The solution is some sort of site-local/1918/ula address overlay.
??? Why not simply perform the address switch somewhere in the middle. You should be able to get the prefix for use with the new provider some time before the link comes up, and, if you're disconnected, there's no harm in continuing to use the old provider's prefix during that time. This makes no sense to me.
It is the last point that leads to the most interesting problem. If you create a local overlay network to always maintain access to your local boxes, then is it actually easier to push out an additional IP address to every end box, and update your IGP, firewall rules, and other configs, or is it easier to run NAT at the edge to convert your local network to public IP's?
If you take the last point as a given, but, to me, the last point seems irrational. I still think NAT is evil cruft that had a purpose in the V4 world, but, is highly undesirable in the v6 world. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
Wow, IPv6 misinformation is reaching unprecendented heights here on NANOG... On 11-nov-04, at 18:46, Owen DeLong wrote:
Seems to me that with a little bit of help from a "Change providers" tool, this would be virtually painless without the need to own or announce a small globally unique prefix.
That is how it has been designed, however there are some practical problems with this system:
I still think that we should pursue making the design work and not adopt cruft as standards (ULA).
ULAs aren't cruft. They serve a purpose. If you don't need them, don't use them and they won't get in your way. The actual distribution of new IP addresses to boxes is fairly trivial in IPv6. DNS is somewhat problematic but nothing a good search and replace can't handle. The real issues are IP address based access restrictions and problems with ingress filtering when addresses from two ISPs are in use at the same time.
- Until very recently DNS software did not support A6 records at all, and "chain" support for A6 records still seems to be a work in progress.
This is getting resolved and I suspect will be long since functional by the time v6 comes to widespread deployment consideration.
Quite the opposite. There was A6 support in BIND AFAIK, but it's removed as it's unworkable. Learn to love AAAA.
If your organization is large enough to involve reconfiguring a significant number of routers, it is unlikely to be small enough to have to use PA space instead of getting PI space in the v6 world.
There is currently no PI in IPv6 unless you're an internet exchange or a root server. Whether there will be is anyone's guess, but it's not currently in the pipeline.
I still think NAT is evil cruft that had a purpose in the V4 world, but, is highly undesirable in the v6 world.
Regardless of the merit of NAT, there is little merit in IPv6+NAT as it has all the downsides of both. If you can live with NAT, stay in IPv4 and talk to the IPv6 world over IPv4<->IPv6 NAT.
I still think that we should pursue making the design work and not adopt cruft as standards (ULA).
ULAs aren't cruft. They serve a purpose. If you don't need them, don't use them and they won't get in your way.
ULAs aren't cruft so long as providers do not start exchanging ULA routes in the general routing table. When economics start forcing this issue, then ULAs become a crufty form of PI space. Since I believe the economics will force this issue sooner rather than later, I regard ULAs as cruft whether you agree or not.
The actual distribution of new IP addresses to boxes is fairly trivial in IPv6. DNS is somewhat problematic but nothing a good search and replace can't handle. The real issues are IP address based access restrictions and problems with ingress filtering when addresses from two ISPs are in use at the same time.
Agreed. That is why I would like to see access restrictions move to something more meaningful than the IP address. Of course, doing so, requires some easy form of strong host authentication, such as AH on all packets that must traverse access restrictions. Ingress filtering shouldn't be that hard, since at least on a theoretical level you shouldn't, in those cases, be leaking provider A's addresses to provider B's network and certainly, answers are unlikely to come back from the other provider.
- Until very recently DNS software did not support A6 records at all, and "chain" support for A6 records still seems to be a work in progress.
This is getting resolved and I suspect will be long since functional by the time v6 comes to widespread deployment consideration.
Quite the opposite. There was A6 support in BIND AFAIK, but it's removed as it's unworkable. Learn to love AAAA.
That's most unfortunate. A6 had much more promise than AAAA for a variety of applications. Oh well.
If your organization is large enough to involve reconfiguring a significant number of routers, it is unlikely to be small enough to have to use PA space instead of getting PI space in the v6 world.
There is currently no PI in IPv6 unless you're an internet exchange or a root server. Whether there will be is anyone's guess, but it's not currently in the pipeline.
If we allow ULA, there definitely will be. If we don't, then, it will be interesting to see how many ISPs spring up with a single customer (themselves).
I still think NAT is evil cruft that had a purpose in the V4 world, but, is highly undesirable in the v6 world.
Regardless of the merit of NAT, there is little merit in IPv6+NAT as it has all the downsides of both. If you can live with NAT, stay in IPv4 and talk to the IPv6 world over IPv4<->IPv6 NAT.
Agreed. Owen
Owen DeLong wrote:
I still think that we should pursue making the design work and not adopt cruft as standards (ULA).
ULAs aren't cruft. They serve a purpose. If you don't need them, don't use them and they won't get in your way.
ULAs aren't cruft so long as providers do not start exchanging ULA routes in the general routing table. When economics start forcing this issue, then ULAs become a crufty form of PI space. Since I believe the economics will force this issue sooner rather than later, I regard ULAs as cruft whether you agree or not.
Your basic argument is that people really want PI space, and as long as the ISPs continue to bias the RIR policies against organized PI space there will be pressure for a grey-market in anything that can be used as PI. A structured and manageable, non-swamp but non-perfect-aggregation approach to PI is described in draft-hain-ipv6-pi-addr-07.txt. Comments welcome. Tony
On 11 Nov 2004, at 18:24, Iljitsch van Beijnum wrote:
Wow, IPv6 misinformation is reaching unprecendented heights here on NANOG...
[...]
There is currently no PI in IPv6 unless you're an internet exchange or a root server. Whether there will be is anyone's guess, but it's not currently in the pipeline.
... or you're an organisation who plans to delegate addresses to customers (number and timeline dependent on RIR). Joe
On Thu, Nov 11, 2004 at 07:28:13PM -0500, Joe Abley wrote:
There is currently no PI in IPv6 unless you're an internet exchange or a root server. Whether there will be is anyone's guess, but it's not currently in the pipeline.
... or you're an organisation who plans to delegate addresses to customers (number and timeline dependent on RIR).
Actually s/customers/other organisations/... at least in RIPE's policy wording. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 12-nov-04, at 1:28, Joe Abley wrote:
There is currently no PI in IPv6 unless you're an internet exchange or a root server. Whether there will be is anyone's guess, but it's not currently in the pipeline.
... or you're an organisation who plans to delegate addresses to customers (number and timeline dependent on RIR).
This would be called PA.
On 11 Nov 2004, at 19:47, Iljitsch van Beijnum wrote:
On 12-nov-04, at 1:28, Joe Abley wrote:
There is currently no PI in IPv6 unless you're an internet exchange or a root server. Whether there will be is anyone's guess, but it's not currently in the pipeline.
... or you're an organisation who plans to delegate addresses to customers (number and timeline dependent on RIR).
This would be called PA.
No. The address delegated to customers (the /48s) would be PA addresses: you would be the Provider, and the addresses would be Aggregatable by your /32 (or whatever). That /32 (or whatever) would be Provider Independent (PI), and you would never need to renumber regardless of how many times you yourself changed providers. Joe
iljitsch@muada.com (Iljitsch van Beijnum) writes:
Wow, IPv6 misinformation is reaching unprecendented heights here on NANOG...
yes. for example, you wrote...
There is currently no PI in IPv6 unless you're an internet exchange or a root server.
...but i really do think of 2001:4f8::/32 as PI, even though ISC is neither an IX nor a rootserver. (f-root has its own /48, which is something else.) -- Paul Vixie
On 12-nov-04, at 5:03, Paul Vixie wrote:
There is currently no PI in IPv6 unless you're an internet exchange or a root server.
...but i really do think of 2001:4f8::/32 as PI, even though ISC is neither an IX nor a rootserver. (f-root has its own /48, which is something else.)
ARIN says: NetRange: 2001:04F8:0000:0000:0000:0000:0000:0000 - 2001:04F8:FFFF:FFFF:FFFF:F FFF:FFFF:FFFF CIDR: 2001:04F8:0000:0000:0000:0000:0000:0000/32 [...] NetType: Direct Allocation I don't exactly know what this means, but something called "allocation" that's bigger than what a single organization could possibly need for its own use doesn't smell like PI to me.
On 12 Nov 2004, at 03:27, Iljitsch van Beijnum wrote:
ARIN says:
NetRange: 2001:04F8:0000:0000:0000:0000:0000:0000 - 2001:04F8:FFFF:FFFF:FFFF:F FFF:FFFF:FFFF CIDR: 2001:04F8:0000:0000:0000:0000:0000:0000/32 [...] NetType: Direct Allocation
I don't exactly know what this means, but something called "allocation" that's bigger than what a single organization could possibly need for its own use doesn't smell like PI to me.
That is exactly what PI is. The word "allocate" used by RIRs usually corresponds to PI. The corresponding word for PA is "assign". Some clarification is perhaps useful. PI: If organisation A has addresses assigned directly from an RIR, that means those addresses are Provider-Independent. The addresses are not tied to a particular provider. They were not assigned by a provider. Organisation A can change providers at will without renumbering. The addresses are Provider-Independent. That's what PI stands for. PA: If organisation A takes some of that PI space and assigns it to organisation B, then the addresses received by organisation B are not Provider-Independent: they are instead tied to organisation A. Organisation A is the Provider. It would be possible for organisation A to announce an aggregate which covered the routes corresponding to B's addresses. That makes B's addresses Provider Aggregatable. That's what PA stands for. Furthermore, IPv6 PI space is easy for ISPs (LIRs) to get. Really very easy indeed. Cast all thoughts of difficult justification and record-keeping that you might associate with v4 allocations from your mind, at least for your initial v6 request. In order to obtain a /32 PI allocation you can meet the initial allocation requirements by telling the RIR you have a plan to make a number of /48 assignments to other organisations within two years. For RIPE, APNIC and ARIN that number is 200. For LACNIC, that number appears to be 1. http://www.apnic.net/docs/policy/ipv6-address-policy.html http://www.arin.net/policy/index.html#six5 http://www.ripe.net/ripe/docs/ipv6policy.html http://lacnic.net/en/ipv6.html To say "there is currently no PI in IPv6 unless you're an internet exchange or a root server" is incorrect. IPv6 PI addresses are easy for ISPs to get. Joe
On 12 Nov 2004, at 09:56, Joe Abley wrote:
The word "allocate" used by RIRs usually corresponds to PI. The corresponding word for PA is "assign".
And just to make this bit clearer (since, now that I look at it, it's a bit murky): if an RIR allocates addresses to an organisation, that organisation is allowed to make assignments from it to other organisations. If an RIR assigns addresses to an organisation, sub-assignments are not allowed. So most PI space is allocated (i.e. provided to LIRs so that they can assign PA space to other organisations). Some PI space is assigned (criticial infrastructure and exchange points). I'll leave all the RIR staff on this list to correct all my other mistakes. Joe
That is exactly what PI is. The word "allocate" used by RIRs usually corresponds to PI. The corresponding word for PA is "assign".
Um, sorry, Joe, not quite... RIRs use "ALLOCATE" to define space that they have allocated to a "PROVIDER" who will then act as an "LIR" and delegate the space to "other organizations". RIRs use "ASSIGN" to define space that is designated to a particular end-user who will not act as an "LIR" and will not delegate the space to "other organizations". In the v4 world, at least for the ARIN RIR, there is a significant difference in cost between being an LIR (which also gives you automatic membership status in ARIN, but, causes your annual fees to be based on the amount of space allocated to you) and a "Direct End User" (which means you pay initial fees for each assignment, but, your annual fee is $100 per ORGID regardless of how much space or how many ASNs you consume). In part, this fee structure makes sense because LIRs are requiring additional support from ARIN to maintain SWIP or pursue RWHOIS entries. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
Hmmm....It walks like a duck: Can be advertised to any v6 ISP. Talks like a duck: Does not have to be returned to ISP when changing transit providers. Floats like a duck: Provides globally unique v6 addresses to said organization Must be made of wood and so it must be a witch. I don't care whether you want to call it PI space or not, the bottom line is that it has all the same practical uses and effect as PI space, and, this is exactly what the real world is likely to do with v6 for any organization that wants to multihome without renumbering. They'll get an AS and they'll get a /32, and, suddenly, each department within the company will become a "customer" of the IT-ISP department. I'm not saying this is clean, friendly, nice, whatever. However, it is what people are really going to do with the current v6 address allocation policies. Owen --On Friday, November 12, 2004 9:27 AM +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 12-nov-04, at 5:03, Paul Vixie wrote:
There is currently no PI in IPv6 unless you're an internet exchange or a root server.
...but i really do think of 2001:4f8::/32 as PI, even though ISC is neither an IX nor a rootserver. (f-root has its own /48, which is something else.)
ARIN says:
NetRange: 2001:04F8:0000:0000:0000:0000:0000:0000 - 2001:04F8:FFFF:FFFF:FFFF:F FFF:FFFF:FFFF CIDR: 2001:04F8:0000:0000:0000:0000:0000:0000/32 [...] NetType: Direct Allocation
I don't exactly know what this means, but something called "allocation" that's bigger than what a single organization could possibly need for its own use doesn't smell like PI to me.
-- If it wasn't crypto-signed, it probably didn't come from me.
On Fri, 2004-11-12 at 08:56 -0800, Owen DeLong wrote:
Hmmm....It walks like a duck: Can be advertised to any v6 ISP. Talks like a duck: Does not have to be returned to ISP when changing transit providers. Floats like a duck: Provides globally unique v6 addresses to said organization
Must be made of wood and so it must be a witch.
I was almost expecting you to start screaming "ding dong the witch is dead" in relation to IPv6 or something ;)
I don't care whether you want to call it PI space or not, the bottom line is that it has all the same practical uses and effect as PI space, and, this is exactly what the real world is likely to do with v6 for any organization that wants to multihome without renumbering. They'll get an AS and they'll get a /32, and, suddenly, each department within the company will become a "customer" of the IT-ISP department.
Fortunately there are 'only' 65k ASN's, thus that would mean only 65k routes in the routing table, which should be quite practical. Seeing only ~650 routes now I don't see that happening that soon, especially with the slowness of deployment of IPv6 in the US, though it is catching on ;). Left to wonder though what happens when we run out of ASN's, 32bit ones?
I'm not saying this is clean, friendly, nice, whatever. However, it is what people are really going to do with the current v6 address allocation policies.
As those policies are decided upon by the membership, feed your input to ARIN/RIPE/APNIC/LACNIC... Greets, Jeroen
Fortunately there are 'only' 65k ASN's, thus that would mean only 65k routes in the routing table, which should be quite practical. Seeing only ~650 routes now I don't see that happening that soon, especially with the slowness of deployment of IPv6 in the US, though it is catching on ;). Left to wonder though what happens when we run out of ASN's, 32bit ones?
32bit ASNs are already in the works. I would expect not more than 2-3 years before you see widespread 32bit ASN code in routers.
As those policies are decided upon by the membership, feed your input to ARIN/RIPE/APNIC/LACNIC...
My RIR is ARIN, and, I am an active participant in the ARIN process. However, my comments on this issue started because I believe ULA will make ARIN or other RIR policies regarding allocation virtually irrelevant because economic pressure will drive ISPs to globally route ULA prefixes, which allocation is not controlled by RIR policy. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
At 09:39 AM 12-11-04 -0800, Owen DeLong wrote:
Fortunately there are 'only' 65k ASN's, thus that would mean only 65k routes in the routing table, which should be quite practical. Seeing only ~650 routes now I don't see that happening that soon, especially with the slowness of deployment of IPv6 in the US, though it is catching on ;). Left to wonder though what happens when we run out of ASN's, 32bit ones?
32bit ASNs are already in the works. I would expect not more than 2-3 years before you see widespread 32bit ASN code in routers.
Hmmmm: Routing Table Report 04:00 +10GMT Sat 13 Nov, 2004 Analysis Summary ---------------- BGP routing table entries examined: 150665 Prefixes after maximum aggregation: 88779 Unique aggregates announced to Internet: 71952 Total ASes present in the Internet Routing Table: 18421 <---- 30% usage and we need 32 bit ASNs? -Hank
Total ASes present in the Internet Routing Table: 18421 <---- 30% usage and we need 32 bit ASNs?
george and geoff's movie gives an interesting perspective on number of asns allocated and number of asns announced. like address space, i suspect we have a general issue of if and how we recover unused resources. what may make this more difficult than one might think at first blush is what george and geoff's movie points out, unused resources tend to be those that were allocated long ago. and we all know how easy it is to contact those folk. randy
At 09:25 AM 13-11-04 -0800, Randy Bush wrote:
Total ASes present in the Internet Routing Table: 18421 <---- 30% usage and we need 32 bit ASNs?
george and geoff's movie gives an interesting perspective on number of asns allocated and number of asns announced.
like address space, i suspect we have a general issue of if and how we recover unused resources. what may make this more difficult than one might think at first blush is what george and geoff's movie points out, unused resources tend to be those that were allocated long ago. and we all know how easy it is to contact those folk.
As a LIR who has returned 36 ASNs to RIPE over the past 3 years (we still have 48 allocated and active), I can admit that it takes hours of work. Once a quarter I scan the routing tables for those that have dropped off or become single homed. Then we try to contact them and get them to become multihomed. If not, phone calls and postal letters ensue with deadlines. Then if they removed my MD5 password, I have to get RIPE DBM involved (like if the company went bankrupt and disappeared from the world with no one home). Then remove all the whois data that references that ASN. It takes 3-4 hours of work to remove a single defunct ASN. I guess the IETF and router vendors prefer larger fields than having LIRs do the work they are supposed to do. -Hank
randy
I guess the IETF and router vendors prefer larger fields than having LIRs do the work they are supposed to do.
i don't think i would phrase it just that way. it may be that the rirs, and the ivtf are not optimistic that lirs will do it. and lirs, because of being nearer the folk holding the resources, are the ones who can make the local phone calls. so i agree, in many cases, it is the lirs who need to do the work. and where's the profit for them in that? the root problem in this and in the strafing of the routing table commons is that people are thinking locally and acting, or not acting, globally. what they seem not to see is that short term "where is the profit in that for me this quarter" will add up to far greater opex and capex for them and for all of us in the future. randy
On Sat Nov 13, 2004 at 07:11:57PM +0200, Hank Nussbacher wrote:
Total ASes present in the Internet Routing Table: 18421 <----
30% usage and we need 32 bit ASNs?
Ah, but they're already allocating in the 34000's. Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x(01)37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x(01)37701) | non sit, noli Internet Operations | WWW: http://www.siemens.co.uk/sbs/ | id reficere Siemens Business Services, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK This email contains confidential information and is for the exclusive use of the addressee(s). If you are not the addressee, then any distribution, copying or use of this email is prohibited. If received in error, please advise the sender and delete/destroy it immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email. Siemens Business Services Media Holdings Ltd. Registered No: 04128934 England Registered Office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ
On 13-nov-04, at 18:11, Hank Nussbacher wrote:
30% usage and we need 32 bit ASNs?
Usage is of course irrelevant, what counts is how many free ones are left. This number is well below 70%. We would be better off upgrading to 32 bits AS numbers sooner rather than later (unless we're confident we'll never run out of 16 bit ones) because this way there are enough 16 bit AS numbers left. The current 32 bit AS number proposal (that has been around for at least 4 years now) should work very well for routers that aren't upgraded as long as only leaf sites use the 32 bit AS numbers. 32 bit AS numbers for transit ASes are best avoided until everyone has upgraded.
On Sun, 14 Nov 2004 18:10:03 +0100, Iljitsch van Beijnum said:
only leaf sites use the 32 bit AS numbers. 32 bit AS numbers for transit ASes are best avoided until everyone has upgraded.
Umm... I'll bite.. ;) How do we know/tell that "everyone" has upgraded? (As opposed to just saying "It's been N+4 years now, everybody must have upgraded by *now*"?) Of course, we *could* always declare "everybody" as "98% of the sites that have good contact info in the various Whois databases are ready to go, the rest know about the issue, and those with bum contact info will get what they deserve when we deploy" :)
On 15-nov-04, at 18:03, Valdis.Kletnieks@vt.edu wrote:
only leaf sites use the 32 bit AS numbers. 32 bit AS numbers for transit ASes are best avoided until everyone has upgraded.
How do we know/tell that "everyone" has upgraded? (As opposed to just saying "It's been N+4 years now, everybody must have upgraded by *now*"?)
Well, how do you know that everyone has upgraded from BGP3 to BGP4?
Of course, we *could* always declare "everybody" as "98% of the sites that have good contact info in the various Whois databases are ready to go, the rest know about the issue, and those with bum contact info will get what they deserve when we deploy" :)
The idea is that the new AS numbers are encoded in new path attributes. For backward compatibility, a "special" AS number is put in the places where a 16 bit number is expected. For obvious reasons, there isn't a corresponding 16 bit AS number for every 32 bit one. So to a 16 bit router all 32 bit ASes look like a single very big AS. Now this shouldn't lead to any problems as long as you don't look too hard at the 16 bit version of the AS path. For leaf sites this shouldn't be a big deal, but for a transit AS the world is going to look a bit confusing when observed through 16 bit glasses when 32 bit AS numbers are becoming common. So practically, we would have to wait until the big N venders support this (for N ≥ 2), wait a bit more and then see if we can start unloading those 32 bit ASes on some poor unexpecting wannabe-multihomers. :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-11-14, at 18.10, Iljitsch van Beijnum wrote:
On 13-nov-04, at 18:11, Hank Nussbacher wrote:
30% usage and we need 32 bit ASNs?
Usage is of course irrelevant, what counts is how many free ones are left. This number is well below 70%.
We would be better off upgrading to 32 bits AS numbers sooner rather than later (unless we're confident we'll never run out of 16 bit ones) because this way there are enough 16 bit AS numbers left. The current 32 bit AS number proposal (that has been around for at least 4 years now) should work very well for routers that aren't upgraded as long as only leaf sites use the 32 bit AS numbers. 32 bit AS numbers for transit ASes are best avoided until everyone has upgraded.
"32-bits should be enough for anyone", right? :-) While I do think we need to start the upgrade process, I actually think that we still need to find a process to reclaim unused resources. Otherwise we will be back here sooner than later. And it will be much harder to get these resources back when the net is even larger than today... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQZj0gKarNKXTPFCVEQIS9QCdFzA4dD9rrfaXpaA6dziFpUGHLnoAoK/y nfctV6BhpuFJBvh2IXEl2tXt =jnCA -----END PGP SIGNATURE-----
ASNs issued today are subject to annual renewal. While this is a small charge and doesn't go up based on the number of ASNs, so, not 100% effective at reclaiming all unused resources, it does, at least, reclaim resources in use by defunct organizations that are no longer paying the maintenance for them. Owen --On Monday, November 15, 2004 07:24:59 PM +0100 Kurt Erik Lindqvist <kurtis@kurtis.pp.se> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-11-14, at 18.10, Iljitsch van Beijnum wrote:
On 13-nov-04, at 18:11, Hank Nussbacher wrote:
30% usage and we need 32 bit ASNs?
Usage is of course irrelevant, what counts is how many free ones are left. This number is well below 70%.
We would be better off upgrading to 32 bits AS numbers sooner rather than later (unless we're confident we'll never run out of 16 bit ones) because this way there are enough 16 bit AS numbers left. The current 32 bit AS number proposal (that has been around for at least 4 years now) should work very well for routers that aren't upgraded as long as only leaf sites use the 32 bit AS numbers. 32 bit AS numbers for transit ASes are best avoided until everyone has upgraded.
"32-bits should be enough for anyone", right? :-)
While I do think we need to start the upgrade process, I actually think that we still need to find a process to reclaim unused resources. Otherwise we will be back here sooner than later. And it will be much harder to get these resources back when the net is even larger than today...
- - kurtis -
-----BEGIN PGP SIGNATURE----- Version: PGP 8.1
iQA/AwUBQZj0gKarNKXTPFCVEQIS9QCdFzA4dD9rrfaXpaA6dziFpUGHLnoAoK/y nfctV6BhpuFJBvh2IXEl2tXt =jnCA -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-11-16, at 02.24, Owen DeLong wrote:
ASNs issued today are subject to annual renewal. While this is a small charge and doesn't go up based on the number of ASNs, so, not 100% effective at reclaiming all unused resources, it does, at least, reclaim resources in use by defunct organizations that are no longer paying the maintenance for them.
Yes, but are they being resused? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQZmp2qarNKXTPFCVEQK14wCg5vqd47Dud5JzlzYOT/8UgHYbz6kAoPp5 fLly4V9OFf8JxiQ6gecklCzP =uhxv -----END PGP SIGNATURE-----
On Tue, 2004-11-16 at 08:18 +0100, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-11-16, at 02.24, Owen DeLong wrote:
ASNs issued today are subject to annual renewal. While this is a small charge and doesn't go up based on the number of ASNs, so, not 100% effective at reclaiming all unused resources, it does, at least, reclaim resources in use by defunct organizations that are no longer paying the maintenance for them.
Yes, but are they being resused?
I have seen IPv6 prefixes, that were allocated and then returned, being allocated to another organization with somewhat a period of 6 months in between. Thus one can assume that ASN will be re-used too. Of course I think that the few couple of prefixes I happen to have seen this happening with where 'given back' from the originally owning organization and not reclaimed from them. Meaning that the RIR knew that it was not in use anymore. Fortunately there are of course systems like RIS (http://ris.ripe.net) to figure this out. Then again, allocations, be they ASN's, IPv6 or IPv4 prefixes, are not only allocated for the public internet usage, but solely to be globally unique. Greets, Jeroen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-11-16, at 08.28, Jeroen Massar wrote:
I have seen IPv6 prefixes, that were allocated and then returned, being allocated to another organization with somewhat a period of 6 months in between.
Good!
Thus one can assume that ASN will be re-used too. Of course I think that the few couple of prefixes I happen to have seen this happening with where 'given back' from the originally owning organization and not reclaimed from them. Meaning that the RIR knew that it was not in use anymore. Fortunately there are of course systems like RIS (http://ris.ripe.net) to figure this out. Then again, allocations, be they ASN's, IPv6 or IPv4 prefixes, are not only allocated for the public internet usage, but solely to be globally unique.
I am less interested in how these resources where reclaimed. I think that shouldn't matter. I think it's better that we start reclaiming and reusing to gain some experience. Again, that will be so much easier to do sooner than later... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQZnoqqarNKXTPFCVEQJ9fgCgivxjgO4casQ1yELuOB8xfN0dPXIAn1u9 Wjre0YUoiZDvE1GNLuTzSPgM =Ccg6 -----END PGP SIGNATURE-----
On Tue, 16 Nov 2004 08:28:55 +0100, Jeroen Massar <jeroen@unfix.org> wrote:
On Tue, 2004-11-16 at 08:18 +0100, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-11-16, at 02.24, Owen DeLong wrote:
ASNs issued today are subject to annual renewal. While this is a small charge and doesn't go up based on the number of ASNs, so, not 100% effective at reclaiming all unused resources, it does, at least, reclaim resources in use by defunct organizations that are no longer paying the maintenance for them.
Yes, but what about the (dozens, hundreds?) of entities that are hoarding (and renewing) ASNs? These unused resources are gone forever - since they are seen as a scarce resource, they are kept artificially alive (even though the orgs know full well there is neither a use nor a justification for them). //Alif
On Fri, 2004-11-19 at 06:48 -0600, J.A. Terranson wrote:
On Tue, 16 Nov 2004 08:28:55 +0100, Jeroen Massar <jeroen@unfix.org> wrote:
On Tue, 2004-11-16 at 08:18 +0100, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-11-16, at 02.24, Owen DeLong wrote:
ASNs issued today are subject to annual renewal. While this is a small charge and doesn't go up based on the number of ASNs, so, not 100% effective at reclaiming all unused resources, it does, at least, reclaim resources in use by defunct organizations that are no longer paying the maintenance for them.
Yes, but what about the (dozens, hundreds?) of entities that are hoarding (and renewing) ASNs? These unused resources are gone forever - since they are seen as a scarce resource, they are kept artificially alive (even though the orgs know full well there is neither a use nor a justification for them).
Then demonstrate to the RIR's that the ASN is unused or kept artificially alive and let them recover it... Nobody is complaining about companies who simply registered [a-z]*.com for instance... someone will make profit, good for them and you are too late to jump into that game. That is always with scarce resources. The first persons to say that gold was special and had a high value is (most likely, nanog !=history) quite wealthy now, just like some folks who got some nice /8's in the beginning don't have an address shortage, domains where available for the pickup in the beginning etc... Greets, Jeroen
Any org viewing ASNs as a scarce resource is wasting money keeping ASNs. Any org that financially broken will probably not continue to pay it's bills in the long run. I believe these are the exception and not the rule. Like I said, the long-term answer to this is 32bit ASNs. I don't think hoarding will account for a significant portion of the ASN space in the long run. Owen --On Friday, November 19, 2004 6:48 AM -0600 "J.A. Terranson" <alif.terranson@gmail.com> wrote:
On Tue, 16 Nov 2004 08:28:55 +0100, Jeroen Massar <jeroen@unfix.org> wrote:
On Tue, 2004-11-16 at 08:18 +0100, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-11-16, at 02.24, Owen DeLong wrote:
ASNs issued today are subject to annual renewal. While this is a small charge and doesn't go up based on the number of ASNs, so, not 100% effective at reclaiming all unused resources, it does, at least, reclaim resources in use by defunct organizations that are no longer paying the maintenance for them.
Yes, but what about the (dozens, hundreds?) of entities that are hoarding (and renewing) ASNs? These unused resources are gone forever - since they are seen as a scarce resource, they are kept artificially alive (even though the orgs know full well there is neither a use nor a justification for them).
//Alif
-- If it wasn't crypto-signed, it probably didn't come from me.
On 16/11/2004 01:24, Owen DeLong wrote:
ASNs issued today are subject to annual renewal. While this is a small charge and doesn't go up based on the number of ASNs, so, not 100% effective at reclaiming all unused resources, it does, at least, reclaim resources in use by defunct organizations that are no longer paying the maintenance for them.
At least for RIPE-issued AS#s, it's damned near impossible to give them back once they've been used for peering. As a result of mergers, I've been left with AS16102 that's no longer required but it's referenced from a number of other ASes as a result of having been used for peering in the past. Some of the ASes it's been reference from are abandoned (Company no longer exists as AS isn't in the global routing table, or it exists and is still peering but the owner has no BGP clue left on staff) which means I can't delete it from the database. I've bought this up with a couple of people and I believe it's been discussed in the appropriate RIPE WGs, but AS# exhaustion isn't currently regarded as a pressing enough issue that anyone has thought up a suitable solution. I guess when we do start running *really* short on AS#s, RIRs will start being much more aggress reclaiming unused AS#s and we'll probably see quite a few suddenly become usable.
On 2004-11-14, at 18.10, Iljitsch van Beijnum wrote:
On 13-nov-04, at 18:11, Hank Nussbacher wrote:
30% usage and we need 32 bit ASNs?
Usage is of course irrelevant, what counts is how many free ones are left. This number is well below 70%.
We would be better off upgrading to 32 bits AS numbers sooner rather than later (unless we're confident we'll never run out of 16 bit ones) because this way there are enough 16 bit AS numbers left. The current 32 bit AS number proposal (that has been around for at least 4 years now) should work very well for routers that aren't upgraded as long as only leaf sites use the 32 bit AS numbers. 32 bit AS numbers for transit ASes are best avoided until everyone has upgraded.
"32-bits should be enough for anyone", right? :-)
While I do think we need to start the upgrade process, I actually think that we still need to find a process to reclaim unused resources. Otherwise we will be back here sooner than later. And it will be much harder to get these resources back when the net is even larger than today...
- kurtis -
-- Ryan O'Connell - CCIE #8174 <ryan@complicity.co.uk> - http://www.complicity.co.uk I'm not losing my mind, no I'm not changing my lines, I'm just learning new things with the passage of time
Hi Ryan, On Nov 18, 2004, at 11:10 pm, Ryan O'Connell wrote: [...]
At least for RIPE-issued AS#s, it's damned near impossible to give them back once they've been used for peering.
As a result of mergers, I've been left with AS16102 that's no longer required but it's referenced from a number of other ASes as a result of having been used for peering in the past. Some of the ASes it's been reference from are abandoned (Company no longer exists as AS isn't in the global routing table, or it exists and is still peering but the owner has no BGP clue left on staff) which means I can't delete it from the database.
I've bought this up with a couple of people and I believe it's been discussed in the appropriate RIPE WGs, but AS# exhaustion isn't currently regarded as a pressing enough issue that anyone has thought up a suitable solution. I guess when we do start running *really* short on AS#s, RIRs will start being much more aggress reclaiming unused AS#s and we'll probably see quite a few suddenly become usable.
Unfortunately, it can be difficult to remove references to an AS Number. Especially when the maintainer of a referring object has disappeared. That being said, we do get a steady trickle of AS Numbers returned. When there a hanging references, we do our best to help remove them. Once we cannot find any references to an aut-num in the RIPE database we will make the ASN available for re-assignment. This takes a minimum of three months. In some cases it can take considerably longer. We are happy to help people return unused and unneeded resources to the available pool. Just let us know and we'll get the process started. Regards, -- leo vegoda Registration Services Manager RIPE NCC
Thus spake "Paul Vixie" <vixie@vix.com>
iljitsch@muada.com (Iljitsch van Beijnum) writes:
Wow, IPv6 misinformation is reaching unprecendented heights here on NANOG...
yes. for example, you wrote...
There is currently no PI in IPv6 unless you're an internet exchange or a root server.
...but i really do think of 2001:4f8::/32 as PI, even though ISC is neither an IX nor a rootserver. (f-root has its own /48, which is something else.)
So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions. Most companies do not have the advantages you apparently take for granted; the IETF thus far has been adamant that only ISPs will get PI space, no matter how big an end-user site may be, exceptions for the IETF/IANA leadership's employers notwithstanding. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
(note: i'm still not speaking for arin.)
...but i really do think of 2001:4f8::/32 as PI, even though ISC is neither an IX nor a rootserver. (f-root has its own /48, which is something else.)
So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32?
your question is interesting for several reasons. for one thing, most present and past (and probably future) members of iesg try to stay as far away from me as possible. not that iesg enters into this, or iana. and while i was recently elected to the arin board, i have no historical "political" relationship to arin at all. but if i did, it wouldn't matter. arin has policies, which are ultimately set by its members, and arin has auditors. nothing will ever be given out by arin as part of a secret-handshake deal. if isc hadn't qualified for the ipv6 /32 we now use, then arin would not have allocated/assigned/??? it to us. the only way in which my special relationship with some arin staffers has ever helped me is when i'm doing something the wrong way they have taken me aside and explained my errors to me, for which i am grateful. (presumably, others "less well connected" just get back a form letter.)
I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions.
i think you're wrong. and as a member-elect of arin's board, i hope you're wrong. because as a public benefit corporation, arin can't act that way, and the kind of favoritism you're describing is exactly the kind of corruption that auditors are trained to look for.
Most companies do not have the advantages you apparently take for granted;
on the contrary, i think that they do (or that i don't).
the IETF thus far has been adamant that only ISPs will get PI space,
ietf doesn't decide. ietf recommends. the members of the RIR's decide.
no matter how big an end-user site may be, exceptions for the IETF/IANA leadership's employers notwithstanding.
want to back up that statement? apply for an ipv6 prefix from arin, and let us (all of nanog) know how it goes. -- Paul Vixie
At 12:32 PM -0600 11/13/04, Stephen Sprunk wrote:
So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The initial allocation size for IPv6 was set by the public policy process to be /32. Association with various Internet bodies has no effect (either way :-) on the received allocation size. From <http://www.arin.net/policy>: ... 6.5.1.2. Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. I have no public comment regarding the ULA proposal, but want to be clear that it is ARIN's goal to apply policies fairly and equitably to all existing and potential members of the Internet community. I am not aware of any complaints in this area in the history of the organization, and so I'm definitely interested from hearing from anyone who feels otherwise. /John John Curran Chair, American Registry for Internet Numbers (ARIN) -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQZZ7jYdtk0FNoZyOEQL7+gCgslGVJSFLsXAlBcgnTz6QmVD0vygAoIj0 RFK60W+OsZvN+4WCnqXP9zva =xTvs -----END PGP SIGNATURE-----
On 13 Nov 2004, at 13:32, Stephen Sprunk wrote:
Thus spake "Paul Vixie" <vixie@vix.com>
There is currently no PI in IPv6 unless you're an internet exchange or a root server.
...but i really do think of 2001:4f8::/32 as PI, even though ISC is neither an IX nor a rootserver. (f-root has its own /48, which is something else.)
So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions.
Nobody is required to count hosts or subnets in order to justify a request for PI v6 space from an RIR. All an applicant needs to do is meet the criteria laid out in the policies, and addresses are assigned or allocated. Anybody who wants to examine the real policies should go and look at the source documents at ARIN, but to paraphrase them here, an applicant who operates an exchange point, or operates critical Internet infrastructure can obtain a PI /48 assignment from ARIN for that purpose; an applicant who has a plan to assign PA addresses to 200 other organisations within 2 years can get a /32 to make the assignments from. The policies specify other requirements for subsequent address requests, and for organisations that need more than a /32 worth of addresses, but for people applying for their first block that paragraph sums it up (however, read the source documents at <http://www.arin.net> rather than taking my word for it). I would expect ARIN staff to ensure that applications were reasonable, accurate and met the criteria set out in the policy before handing out any resources. ARIN staff have always been very rigourous in this regard whenever I have had occasion to send them a request. Joe
On Sat, 13 Nov 2004, Joe Abley wrote:
So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions.
Nobody is required to count hosts or subnets in order to justify a request for PI v6 space from an RIR. All an applicant needs to do is meet the criteria laid out in the policies, and addresses are assigned or allocated.
Anybody who wants to examine the real policies should go and look at the source documents at ARIN, but to paraphrase them here, an applicant who operates an exchange point, or operates critical Internet infrastructure can obtain a PI /48 assignment from ARIN for that purpose; an applicant who has a plan to assign PA addresses to 200 other organisations within 2 years can get a /32 to make the assignments from.
Actually, the policy also specifies that you must not be an end-site. I'd be particularly interested in knowing what ISC said who would be their 200 other organizations who they intended to allocate the address space (their employees?), and how ISC would not be an end-site. This is a more generic issue, of course. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Most of the existing IPv6 policy set went into effect August 1, 2002, in the ARIN region. The provisional IPv6 policy set in place before that did not exclude end-sites from obtaining IPv6 address space from ARIN. Richard Jimmerson Director of External Relations American Registry for Internet Numbers (ARIN)
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Pekka Savola Sent: Sunday, November 14, 2004 4:31 AM To: Joe Abley Cc: Stephen Sprunk; Paul Vixie; North American Noise and Off-topic Gripes Subject: who gets a /32 [Re: IPV6 renumbering painless?]
So you're claiming that any IPv6 PI applicant without your
On Sat, 13 Nov 2004, Joe Abley wrote: political
connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions.
Nobody is required to count hosts or subnets in order to justify a request for PI v6 space from an RIR. All an applicant needs to do is meet the criteria laid out in the policies, and addresses are assigned or allocated.
Anybody who wants to examine the real policies should go and look at the source documents at ARIN, but to paraphrase them here, an applicant who operates an exchange point, or operates critical Internet infrastructure can obtain a PI /48 assignment from ARIN for that purpose; an applicant who has a plan to assign PA addresses to 200 other organisations within 2 years can get a /32 to make the assignments from.
Actually, the policy also specifies that you must not be an end-site.
I'd be particularly interested in knowing what ISC said who would be their 200 other organizations who they intended to allocate the address space (their employees?), and how ISC would not be an end-site.
This is a more generic issue, of course.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Sun, Nov 14, 2004 at 07:43:18PM -0500, Richard Jimmerson wrote:
Most of the existing IPv6 policy set went into effect August 1, 2002, in the ARIN region. The provisional IPv6 policy set in place before that did not exclude end-sites from obtaining IPv6 address space from ARIN.
And this is why folks like Cisco and Nokia got allocations too. They were just quick enough to take advantage of the back-then still relaxed policy. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
I believe that to be true. In fact, I don't think Paul's connections probably made it particularly easier for him to get his space to any extent other than he might have some level of established credibility for the claims made in his justification. (i.e. his honest may be a bit less suspect than someone unknown to the RIR staff). Owen --On Saturday, November 13, 2004 12:32 PM -0600 Stephen Sprunk <stephen@sprunk.org> wrote:
Thus spake "Paul Vixie" <vixie@vix.com>
iljitsch@muada.com (Iljitsch van Beijnum) writes:
Wow, IPv6 misinformation is reaching unprecendented heights here on NANOG...
yes. for example, you wrote...
There is currently no PI in IPv6 unless you're an internet exchange or a root server.
...but i really do think of 2001:4f8::/32 as PI, even though ISC is neither an IX nor a rootserver. (f-root has its own /48, which is something else.)
So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions.
Most companies do not have the advantages you apparently take for granted; the IETF thus far has been adamant that only ISPs will get PI space, no matter how big an end-user site may be, exceptions for the IETF/IANA leadership's employers notwithstanding.
S
Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
-- If it wasn't crypto-signed, it probably didn't come from me.
Wow, IPv6 misinformation is reaching unprecendented heights here on NANOG...
http://www.ipv6forum.org leads to lots of basic resources that will help you understand IPv6.
Quite the opposite. There was A6 support in BIND AFAIK, but it's removed as it's unworkable. Learn to love AAAA.
Found this statement in this IPv6 Howto http://www.join.uni-muenster.de/Dokumente/Howtos/Howto_IPv6-Nameservice.php?... Without going further into details, please note that these new records and notations were "deprecated". After RFC2874 was published, the internet community raised fears that chained resource records would slow down name lookups, would raise the danger of severe misconfiguration and might even break the nameservice. Due to this, A6 and DNAME records were degraded to experimental (RFC3363), which practically means 'deprecated'. Further information why this was necessary is explained in RFC3364. If you need to know more, check the two RFCs.
Regardless of the merit of NAT, there is little merit in IPv6+NAT as it has all the downsides of both. If you can live with NAT, stay in IPv4 and talk to the IPv6 world over IPv4<->IPv6 NAT.
Or upgrade to NAP (Network Architecture Protection) *grin* --Michael Dillon
On Fri, 2004-11-12 at 10:58 +0000, Michael.Dillon@radianz.com wrote:
Regardless of the merit of NAT, there is little merit in IPv6+NAT as it has all the downsides of both. If you can live with NAT, stay in IPv4 and talk to the IPv6 world over IPv4<->IPv6 NAT.
Or upgrade to NAP (Network Architecture Protection) *grin*
That is actually exactly what should be told to any administrator that asks for "IPv6 NAT": "No, in IPv6 it is done differently, it is then called NAP, which is waaay cooler and saves you a lot of money and troubles". Greets, Jeroen
Regardless of the merit of NAT, there is little merit in IPv6+NAT as it has all the downsides of both. If you can live with NAT, stay in IPv4 and talk to the IPv6 world over IPv4<->IPv6 NAT.
Or upgrade to NAP (Network Architecture Protection) *grin*
"No, in IPv6 it is done differently, it is then called NAP, which is waaay cooler and saves you a lot of money and troubles".
Newsflash. NAT is not going to die. It is supply and demand. There is a demand for NAT and it will stay here until every single publication that enterprise CFO reads keeps saying for 5 years that NAT is useless. So, is there any chance that the super-smart network community pulls its collective head out of the sand? Alex
Thus spake "Owen DeLong" <owen@delong.com>
If your organization is large enough to involve reconfiguring a significant number of routers, it is unlikely to be small enough to have to use PA space instead of getting PI space in the v6 world.
That depends. I consulted with an oil company that wanted to put IP connectivity out to all their gas stations (40,000 of them), with 64+ hosts per site, but would never qualify for PI space (under v4 or v6) because zero of those hosts would need Internet connectivity. ULAs would be a perfect solution for them. In fact, they have since merged with another oil company of equal size, meaning they'd need two ULA prefixes just to provide a single subnet to each site.
I would argue that ACL's in the v6 world should probably include A6 support.
Security folks rarely, if ever, trust DNS enough to use it in ACLs. And you're assuming that putting half a million entires in their ACLs is even remotely possible with today's routers. With ULAs, you just put in one or two entries and you're done. Not to mention the nightmare of keeping track of that many DNS records... Oh, and as others have mentioned, A6 is dead.
If you are large enough for IGP configuration for the new network to be a major undertaking, then, you probably qualify for PI space. If you are large enough that BGP is more than a couple of routers that need changing, you probably qualify for PI space.
IMHO, you are overly optimistic on how easily end-user sites can get PI space.
??? Why not simply perform the address switch somewhere in the middle. You should be able to get the prefix for use with the new provider some time before the link comes up, and, if you're disconnected, there's no harm in continuing to use the old provider's prefix during that time. This makes no sense to me.
Multi6's current wet dream is that if the connection to a provider goes down, that prefix will be automatically un-delegated from all the downstream routers and hosts. If your last connection goes away, you have no addresses left except link-local. For sites which frequently detach from one network and attach to another, this is murder on internal communications. Even a site that is normally multihomed may experience severe internal communication failures if a subset of their links flap. Most application protocols assume that a TCP failure means the remote host is unavailable or aborted the transaction, and few will transparently try a different address pair and resume a transaction transparently to the user.
If you take the last point as a given, but, to me, the last point seems irrational. I still think NAT is evil cruft that had a purpose in the V4 world, but, is highly undesirable in the v6 world.
I don't think anyone here disagrees with the idea that NAT is evil. That's not the problem ULAs are intended to solve. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? ...
That is how it has been designed, however there are some practical problems with this system:
- Until very recently DNS software did not support A6 records at all, and "chain" support for A6 records still seems to be a work in progress.
A6 is dead. If you renumber, all your AAAA's will have to be changed, and you will have to establish new PTR zones. It's now just like IPv4 with regard to DNS, except for the RRtype (AAAA vs A). There is no IPv6 renumbering support in DNS. Dead, dead, dead. For years now. Several of those responsible for the killing are present on this mailing list, so perhaps they will explain just why A6 apparently needed killing. -- Paul Vixie
From: Michael.Dillon@radianz.com Date: Thu, 11 Nov 2004 16:22:28 +0000 Sender: owner-nanog@merit.edu
I guess you also want to announce a /64 into the IPv6 BGP tables ?
Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? So if RFC 2462 is right, and you use DNS outside your network and you update that DNS at the moment of switching providers, everything on your network automatically acquires new IPv6 globally routable addresses as soon as the gateway router is connected to the new provider. Seems to me that with a little bit of help from a "Change providers" tool, this would be virtually painless without the need to own or announce a small globally unique prefix.
We have renumbered IPv6 space a couple of times when we were developing our addressing plan. (We have a /32.) Renumbering was pretty trivial for most systems, but servers requiring a fixed address were usually configured with an explicit prefix. This should not have been the case, but most people configured IPv6 addresses pretty much like IPv4 and specified the entire 128 bits. Of course, after a renumbering, this gets fixed, so those systems are usually OK the next time. DNS is an issue, but still pretty easy IF you set things properly. This is more likely than having servers set up right as the right way is usually what most people would tend to do without thinking about it. On the whole, it's pretty fast and easy, but there are always a few bumps in the road. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
On Thu, Nov 11, 2004 at 08:44:57AM -0800, Kevin Oberman wrote:
We have renumbered IPv6 space a couple of times when we were developing our addressing plan. (We have a /32.) Renumbering was pretty trivial for most systems, but servers requiring a fixed address were usually configured with an explicit prefix. This should not have been the case, but most people configured IPv6 addresses pretty much like IPv4 and specified the entire 128 bits. Of course, after a renumbering, this gets fixed, so those systems are usually OK the next time.
"specified the entire 128 bits"... how do you specify only part of it? What determines the rest? "fixed" as in "now using stateless autoconfig"? Fun... change NIC and you need to change DNS. Thanks, but no thanks. Not for non-mobile devices which need to be reachable with sessions initiated from remote (basically: servers). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Daniel Roesen wrote:
...
"fixed" as in "now using stateless autoconfig"? Fun... change NIC and you need to change DNS. Thanks, but no thanks. Not for non-mobile devices which need to be reachable with sessions initiated from remote (basically: servers).
You are allowed to do either / both, or DHCP. If you are talking about a server you want a static value, while it may not make sense to explicitly manage every client. If you don't want to statically configure devices there is always DHCPv6. The point is you can do what you do today, then there are new capabilities for autoconfiguration that can be used when it makes sense to lower operational costs. Tony
On Thu, Nov 11, 2004 at 12:05:26PM -0800, Tony Hain wrote:
"fixed" as in "now using stateless autoconfig"? Fun... change NIC and you need to change DNS. Thanks, but no thanks. Not for non-mobile devices which need to be reachable with sessions initiated from remote (basically: servers).
You are allowed to do either / both, or DHCP. If you are talking about a server you want a static value, while it may not make sense to explicitly manage every client. If you don't want to statically configure devices there is always DHCPv6. The point is you can do what you do today, then there are new capabilities for autoconfiguration that can be used when it makes sense to lower operational costs.
Well, but all you said is in no way different to the IPv4 world and thus doesn't make renumbering any more easier than in IPv4. And yes, I think all the workstations WILL need to do DHCP and not use stateless autoconfig. Workstations are being managed by IT departments, and they do want to be able to SSH to them all and have DNS forward/reverse mapping. I can see NOTHING in IPv6 which makes real world networks any easier to renumber than IPv4 networks ASIDE the fact that if /48 addressing is used, renumbering becomes a search-and-replace thing for large parts of it. Stateless autoconfig doesn't really provide any added value for ad-hoc mobile clients than DHCP does in v4 - au contraire, as all the other information a DHCP server might offer is not provided with stateless autoconfig. Stateless autoconfig DOES have uses, but those are for most of us just exotic corner cases, IMHO. Regards, Daniel (who will soon renumber his private network /48 a third time since he has IPv6 connectivity) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Fri, Nov 12, 2004 at 01:44:50AM +0100, Daniel Roesen wrote:
And yes, I think all the workstations WILL need to do DHCP and not use stateless autoconfig. Workstations are being managed by IT departments, and they do want to be able to SSH to them all and have DNS forward/reverse mapping.
Ohh, Autoconfig (with the MAC-Address in the host bits) actually makes it easier for me to log into a workstation. I just keep 2 lists: 1) all prefixes in my network 2) all Macaddresses in use. Now I can loop through all prefixes and try to ping the macaddress I want to reach (with the occasional fffe in the middle). Hoping that the MAC is really unique (we do not use 3com cards anymore) I can actually find a specific Laptop on my network easy without even knowing where the user is.
I can see NOTHING in IPv6 which makes real world networks any easier to renumber than IPv4 networks ASIDE the fact that if /48 addressing is used, renumbering becomes a search-and-replace thing for large parts of it.
I agree to that, though.
Stateless autoconfig doesn't really provide any added value for ad-hoc mobile clients than DHCP does in v4 - au contraire, as all the other information a DHCP server might offer is not provided with stateless autoconfig.
Knowing what the host-part of the IP-Address will be for the a specific device is an advantage I believe. Nils
Daniel Roesen writes:
On Thu, Nov 11, 2004 at 08:44:57AM -0800, Kevin Oberman wrote:
We have renumbered IPv6 space a couple of times when we were developing our addressing plan. (We have a /32.) Renumbering was pretty trivial for most systems, but servers requiring a fixed address were usually configured with an explicit prefix. This should not have been the case, but most people configured IPv6 addresses pretty much like IPv4 and specified the entire 128 bits. Of course, after a renumbering, this gets fixed, so those systems are usually OK the next time.
"specified the entire 128 bits"... how do you specify only part of it?
On Solaris, you would use the "token" option (see the extract from "man ifconfig" output below). You can simply put "token ::1234:5678" into /etc/hostname6.bge0. I assume that other sane OSes have similar mechanisms. 602 token address/prefix_length 603 Set the IPv6 token of an interface to be used for 604 address autoconfiguration. 605 606 example% ifconfig hme0 inet6 token ::1/64 607
What determines the rest?
The prefix advertised in prefix advertisements.
"fixed" as in "now using stateless autoconfig"? Fun... change NIC and you need to change DNS. Thanks, but no thanks. Not for non-mobile devices which need to be reachable with sessions initiated from remote (basically: servers).
The above mechanism solves this problem even with stateless autoconfiguration. Agree? I think it's an advantage if servers can get their prefixes from router announcements rather than from local config files. Sure, you still have to update the DNS at some point(s) during renumbering, but that can't be avoided anyway. -- Simon.
On Fri, Nov 12, 2004 at 05:19:36PM +0100, Simon Leinen wrote:
"specified the entire 128 bits"... how do you specify only part of it?
On Solaris, you would use the "token" option (see the extract from "man ifconfig" output below). You can simply put "token ::1234:5678" into /etc/hostname6.bge0. I assume that other sane OSes have similar mechanisms.
Ah thanks. No, not seen anywhere in Linux or *BSD.
What determines the rest?
The prefix advertised in prefix advertisements.
OK, but this doesn't have any effect on your "Listen", "NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf, "ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and "listen-on*" in named.conf, [...] Not to forget all the IP address based ACLs.
"fixed" as in "now using stateless autoconfig"? Fun... change NIC and you need to change DNS. Thanks, but no thanks. Not for non-mobile devices which need to be reachable with sessions initiated from remote (basically: servers).
The above mechanism solves this problem even with stateless autoconfiguration. Agree?
The NIC-change problem? Yes, agreed. But generates new problem: Plug server accidently in wrong VLAN (and thus other subnet) and you'll might get an IP address collision. I know ND DAD prevents the worst for that case in the immediate term, but when the original holder gets reconnected/rebootet, THIS one is off their air. But you're right, typos in IPv4 might provoke similar desasters so I rest this specific case. :-)
I think it's an advantage if servers can get their prefixes from router announcements rather than from local config files. Sure, you still have to update the DNS at some point(s) during renumbering, but that can't be avoided anyway.
Given that a server often has to know it's exact IP address very often (especially if it has multiple IP addresses associated with it's public interface), it's not a real relief compared to the other struggles you have when subnet changes. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Daniel Roesen writes:
On Fri, Nov 12, 2004 at 05:19:36PM +0100, Simon Leinen wrote:
On Solaris, you would use the "token" option (see the extract from "man ifconfig" output below). You can simply put "token ::1234:5678" into /etc/hostname6.bge0. I assume that other sane OSes have similar mechanisms.
Ah thanks. No, not seen anywhere in Linux or *BSD.
That's why I put in the qualification :-) -- Simon.
Daniel Roesen wrote:
On Fri, Nov 12, 2004 at 05:19:36PM +0100, Simon Leinen wrote:
"specified the entire 128 bits"... how do you specify only part of it?
On Solaris, you would use the "token" option (see the extract from "man ifconfig" output below). You can simply put "token ::1234:5678" into /etc/hostname6.bge0. I assume that other sane OSes have similar mechanisms.
Ah thanks. No, not seen anywhere in Linux or *BSD.
I would expect it to be an configuration option for rtsold(8) in KAME- derived stacks and not in ifconfig(8). Errr... Not that I see it in there either. Trying to check a more recent KAME code base brings me to a real question I've had. Does http://www.kame.net/ have an IPv4 mirror somewhere? $ dig @orange.kame.net www.kame.net any ; <<>> DiG 8.3 <<>> @orange.kame.net www.kame.net any ; (2 servers found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54483 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.kame.net, type = ANY, class = IN ;; ANSWER SECTION: www.kame.net. 1D IN AAAA 2001:200:0:8002:203:47ff:fea5:3085 ;; AUTHORITY SECTION: kame.net. 1D IN NS orange.kame.net. kame.net. 1D IN NS ns1.itojun.org. ;; ADDITIONAL SECTION: orange.kame.net. 1D IN A 203.178.141.194 orange.kame.net. 1D IN AAAA 2001:200:0:8002:203:47ff:fea5:3085 ;; Total query time: 160 msec ;; FROM: sec-tools.corp.globalstar.com to SERVER: 203.178.141.194 ;; WHEN: Fri Nov 12 14:05:13 2004 ;; MSG SIZE sent: 30 rcvd: 151 -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On Fri, 2004-11-12 at 14:08 -0800, Crist Clark wrote: <SNIP>
Trying to check a more recent KAME code base brings me to a real question I've had. Does http://www.kame.net/ have an IPv4 mirror somewhere?
$ dig +short www.kame.net any 2001:200:0:8002:203:47ff:fea5:3085 203.178.141.194 But otherwise: http://www.kame.net.ipv4.sixxs.org will also work as that proxies any IPv6 site into IPv4. Greets, Jeroen
"specified the entire 128 bits"... how do you specify only part of it?
On Solaris, you would use the "token" option ...
Ah thanks. No, not seen anywhere in Linux or *BSD.
we (ISC) asked KAME about this, and they suggested: % cat /etc/start_if.nge0 ifconfig nge0 inet6 fe80::1 ...which for freebsd 5.2.1 at least, has the right effect. rtsol still runs, and once the upper 64 bits are known, the obvious thing happens: % ifconfig nge0 | grep :: inet6 fe80::1%nge0 prefixlen 64 scopeid 0x5 inet6 2001:4f8:3:bb::1 prefixlen 64 autoconf ...so it's not as easy as the solaris "token" thing described earlier in this thread, but it actually works fine and it's become universal on ISC's hosts. -- Paul Vixie
OK, but this doesn't have any effect on your "Listen", "NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf, "ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and "listen-on*" in named.conf, [...]
True. However, in all of the cases above except named.conf, names are a perfectly valid substitute for the IP address.
Not to forget all the IP address based ACLs.
I suspect that eventually, we will discover that ADDRESS-based ACLs simply do not scale to a V6 world, and, you will see support for other strategies, such as host-name based ACLs.
Given that a server often has to know it's exact IP address very often (especially if it has multiple IP addresses associated with it's public interface), it's not a real relief compared to the other struggles you have when subnet changes.
In most of those instances, the server can get it's address from a nameservice, and, only really needs to know the unique name for the correct address. Owen
On Fri, Nov 12, 2004 at 05:06:17PM -0800, Owen DeLong wrote:
OK, but this doesn't have any effect on your "Listen", "NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf, "ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and "listen-on*" in named.conf, [...]
True. However, in all of the cases above except named.conf, names are a perfectly valid substitute for the IP address.
No. Those configs are read at boot-time. Now think about a power outage recovery. Server comes up but cannot reach DNS when services are starting up. Boom, your server's services bail out and are dead in the water. To prevent this, you might fill your /etc/hosts with the own FQDN-to-IP mappings, but this again has the problem of being pretty static.
Not to forget all the IP address based ACLs.
I suspect that eventually, we will discover that ADDRESS-based ACLs simply do not scale to a V6 world, and, you will see support for other strategies, such as host-name based ACLs.
Layer 3 doesn't know host names. Nor does layer 4. Applications do. Security requirements do often mandate working access control even when DNS doesn't work or is compromised. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
--On Saturday, November 13, 2004 2:56 +0100 Daniel Roesen <dr@cluenet.de> wrote:
On Fri, Nov 12, 2004 at 05:06:17PM -0800, Owen DeLong wrote:
OK, but this doesn't have any effect on your "Listen", "NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf, "ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and "listen-on*" in named.conf, [...]
True. However, in all of the cases above except named.conf, names are a perfectly valid substitute for the IP address.
No. Those configs are read at boot-time. Now think about a power outage recovery. Server comes up but cannot reach DNS when services are starting up. Boom, your server's services bail out and are dead in the water. To prevent this, you might fill your /etc/hosts with the own FQDN-to-IP mappings, but this again has the problem of being pretty static.
Or... Recognizing that you have a dependency on DNS, you include S10WaitForDns in your rc3.d and don't continue the bootstrap until DNS is reachable. Of course, if you're all _THAT_ worried about it, you make your host a secondary for the domains it needs to know about and have it run a caching resolver that is authoritative for the local domains which only binds to the localhost port, so, no problem and not static. Then, you just need to start BIND before you start those services.
Not to forget all the IP address based ACLs.
I suspect that eventually, we will discover that ADDRESS-based ACLs simply do not scale to a V6 world, and, you will see support for other strategies, such as host-name based ACLs.
Layer 3 doesn't know host names. Nor does layer 4. Applications do. Security requirements do often mandate working access control even when DNS doesn't work or is compromised.
Security requirements are that you not permit packets that should not be when DNS is not working. Nothing says the router cannot run a resolver pass when parsing the ACL or when told to refresh the ACL to translate the configured names into IP addresses. Nothing precludes a periodic automatic refresh. Hope this helps show that these problems can be mitigated in more scalable ways. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
* Owen DeLong <owen@delong.com> [2004-11-13 09:11]:
Or... Recognizing that you have a dependency on DNS, you include S10WaitForDns in your rc3.d and don't continue the bootstrap until DNS is reachable.
in my what? ;) this is just sick, in any case.
Not to forget all the IP address based ACLs. I suspect that eventually, we will discover that ADDRESS-based ACLs simply do not scale to a V6 world, and, you will see support for other strategies, such as host-name based ACLs. Layer 3 doesn't know host names. Nor does layer 4. Applications do. Security requirements do often mandate working access control even when DNS doesn't work or is compromised. Security requirements are that you not permit packets that should not be when DNS is not working. Nothing says the router cannot run a resolver pass when parsing the ACL or when told to refresh the ACL to translate the configured names into IP addresses. Nothing precludes a periodic automatic refresh.
this is completely unacceptable and fails the point entirely.
Hope this helps show that these problems can be mitigated in more scalable ways.
why do the v6 proponents always pretend that they can change everything? there's a reason for how things are now, and many of them are good reasons (and some are poor, yes). v6 should solve 1) the address space problem 2) autoconfiguation however, by giving this to academics with much too much time on their hands, v6 transformed into unusable crap, and we are where we are now, as in, no real world relevance for v6, and it doesn't look like that will change anytime soon. face some facts, you are not going to change the way the net works in such ways. go back to the drawing board and start cutting out the crap. then v6 (or whatever it might be called then) has a chance.
On 13-nov-04, at 10:02, Henning Brauer wrote:
* Owen DeLong <owen@delong.com> [2004-11-13 08:46]:
I suspect that eventually, we will discover that ADDRESS-based ACLs simply do not scale to a V6 world
which I see as an issue with v6 and not the ACLs.
Yes, because address based access restrictions never get in the way of renumbering in IPv4. Filtering based on IP addresses is a broken concept. I'm not a huge fan of sprinkling crypto over everything, but if you want certain people to have access to some stuff and not others, IPsec/SSL are the way to go.
FWIW, I think TLS is a cleaner approach than SSL, but, otherwise, I agree with Iljitsch. Owen
On Sat, 13 Nov 2004, Iljitsch van Beijnum wrote:
On 13-nov-04, at 10:02, Henning Brauer wrote:
Filtering based on IP addresses is a broken concept.
I'm not a huge fan of sprinkling crypto over everything, but if you want certain people to have access to some stuff and not others, IPsec/SSL are the way to go.
there are things putting random packets over the network today, trying to exploit services you might be using, or your customers might be using. IPSEC everywhere is 'nice' but not horribly practical. SSL is nice, until your SSL libraries have remotely exploitable DoS or root vulnerabilities... how many times over the last 12 months has openssl been upgraded due to 'security' issues?
Btw - using Solaris + no_stack_exec + old ssl - appear to be 100% secure from all random attacks (it can be broken - in theory, see articles from 'Solar designer' - but it is absolutely inpractical for hacking). I watched such system (absolutely not patched, with apache and openssl, untouched for 3 years - we kept it as a honeypot - no single exploit). And if you add IP filter + non standard port protects your 100% even if your service have broken library. As a result - it is safer to run old openssl + filter + solaris, vs running SuSe linux + automated upgrade + unfiltered openssl. It is wekk known thing - want best security - do not use anything standard, customize everything. So, step 1 - filter; step 2 -customize; and step 3 - update. Just updates without first 2 steps are much more dangerous, vs no updates but first 2 steps. PS. Why is it in IPv6 thread? And why IP filtering is broken? Even primitive firewall can do enough p[rotection to make any random packets useless. ----- Original Message ----- From: "Christopher L. Morrow" <christopher.morrow@mci.com> To: "Iljitsch van Beijnum" <iljitsch@muada.com> Cc: "Henning Brauer" <hb-nanog@bsws.de>; <nanog@merit.edu> Sent: Saturday, November 13, 2004 7:09 PM Subject: Re: IPV6 renumbering painless?
On Sat, 13 Nov 2004, Iljitsch van Beijnum wrote:
On 13-nov-04, at 10:02, Henning Brauer wrote:
Filtering based on IP addresses is a broken concept.
I'm not a huge fan of sprinkling crypto over everything, but if you want certain people to have access to some stuff and not others, IPsec/SSL are the way to go.
there are things putting random packets over the network today, trying to exploit services you might be using, or your customers might be using. IPSEC everywhere is 'nice' but not horribly practical. SSL is nice, until your SSL libraries have remotely exploitable DoS or root vulnerabilities... how many times over the last 12 months has openssl been upgraded due to 'security' issues?
On Fri, 12 Nov 2004, Simon Leinen wrote:
Daniel Roesen writes:
On Thu, Nov 11, 2004 at 08:44:57AM -0800, Kevin Oberman wrote:
We have renumbered IPv6 space a couple of times when we were developing our addressing plan. (We have a /32.) Renumbering was pretty trivial for most systems, but servers requiring a fixed address were usually configured with an explicit prefix. This should not have been the case, but most people configured IPv6 addresses pretty much like IPv4 and specified the entire 128 bits. Of course, after a renumbering, this gets fixed, so those systems are usually OK the next time.
"specified the entire 128 bits"... how do you specify only part of it?
On Solaris, you would use the "token" option (see the extract from "man ifconfig" output below). You can simply put "token ::1234:5678"
one presumes solaris <> 7 or 8 then, which solaris would this be in?
: man ifconfig | grep token Reformatting page. Please Wait... done
I'd note that a simple: echo "up" >> /etc/hostname6.hme0 will get you 'autoconfigured' v6 on solaris 8 though, and add to /etc/inet/ipnodes: <node address> <node name> and fix /etc/nsswitch.conf: ipnodes: files dns after that, ping/traceroute/telnet/ftp all work correctly with ipv6. I was cursing sun/solaris until I figured that part out :)
I think it's an advantage if servers can get their prefixes from router announcements rather than from local config files. Sure, you still have to update the DNS at some point(s) during renumbering, but that can't be avoided anyway.
and change that all when the interface on the server fries out and a replacement is put into the box, with a new 'autoconfigured' ip address... or if your 'service' is a virtual ip on a server... things get complicated, it's 'fun' :) Autoconfig has it's place, which is far from 'everywhere'. -chris ipv6-n00b
On 11-nov-04, at 16:36, Adi Linden wrote:
What are my options today to obtain ip address space? My requirements are well met by a /27 subnet. ARIN won't give me a globally unique /27 for personal use. So the /27 comes from my service provider, which has several caveats. I cannot multi-home. I cannot keep my address space when changing providers. I most likely cannot keep my address space moving to a different city but staying with the same provider.
This is not unlike the situation in IPv6 where you will get a /48. :-)
About half of the devices within my on private network are statically defined and for local use only. They will never need global access. Because they are awkward to configure I do not want to renumber, ever. My solution is to use RFC1918 address space for this network.
Use unique site locals for them in IPv6.
NAT is my technology of choice to connect to the global internet, but other solutions are possible.
You were talking about devices that need no connection to the rest of the world. So how does NAT enter the picture?
If I understand correctly, ipv6 will force me into using provider dependent globally unique address space.
For anything that needs to connect to the internet at large, yes. For stuff that only needs to be reachable from within your sites and people you work close together with, ULAs fit the bill.
Unless my provider of the day is required to assign me address space that is and/or permanently assigned and portable it does not meet my needs. Why not? I am not willing to renumber when I change providers. I have no problem using NAT to obtain connectivity from provider B using providers A address space internally. But that only works if provider A is prevented from reusing 'my' addresses if I terminate my contract.
Think of it this way: provider A is called IANA. They seem to offer a great deal: you get to keep your address space forever, and it costs (next to) nothing. However, your connectivity sucks: there is none. We'll all have to learn some new tricks with IPv6. A model that appeals to me is to give all hosts within a site a unique site local address, and everything that needs external connectivity an address from the ISP of the week. Then, treat all the ULAs as "internal" and all the ISP derived addresses as "external". This means there is no need to have extensive access lists that contain ISP derived addresses, as all access to internal resources must be done using the ULAs, which don't change. (When properly implemented, default address selection will make sure the appropriate source/destination addresses are used for different types of connections.)
About half of the devices within my on private network are statically defined and for local use only. They will never need global access. Because they are awkward to configure I do not want to renumber, ever. My solution is to use RFC1918 address space for this network.
Use unique site locals for them in IPv6.
Aren't unique site locals associated with the mac address? Adi
On 15-nov-04, at 23:10, Adi Linden wrote:
Aren't unique site locals associated with the mac address?
Not really. Unique site local addresses as such don't have anything to do with MAC addresses. However, most IPv6 addresses (including, presumably, unique site locals when they are deployed) contain a MAC address in the bottom 64 bits. This happens when stateless autoconfiguration is used: routers broadcast (well, multicast) the top 64 bits and hosts fill in the lower 64 bits with a unique value. This was the MAC address (if available) until privacy advocates came along and now there is also RFC 3041 which uses random numbers for this. Note though that it is by no means required to use stateless autoconfiguration: you can set the address(es) manually, or you can use DHCP for IPv6. Also note that (AFAIK) of the major OSes and out of the box, only Windows supports RFC 3041, and Windows and MacOS don't (yet?) come with DHCPv6 support, and it doesn't look like it's easy to add it yourself (like in the *nix world) either.
--On torsdag 11 november 2004 09.36 -0600 Adi Linden <adil@adis.on.ca> wrote:
RFC1918 address space is free and plentiful for my purposes. It is provider independent. It is globally unique in the sense that no other publically routed network is using them. My globally unique address will come from my provider of the day. NAT is my technology of choice to connect to the global internet, but other solutions are possible.
You are probably going to fare well behind your D-Link residential plastic box. Most people do, as long as they accept the spoon-feeding media model and stay away from potentially dangerous things like trying to challenge who gets to publicise things and whatnot. Anyway, there are other issues with non-unique addresses. Enterprises *WILL* use them, in large, expensive-to-renumber-since-we're-stupid-and-don't-use-DNS schemes. Enterprises merge. I'll gladly hand out the marshmallows to roast on the crash-and-burn fire when "unique behind my firewall" isn't.
If I understand correctly, ipv6 will force me into using provider dependent globally unique address space.
Yes, as long as you don't run a LIR. (One can argue whether this is The Way, I don't agree, but basically, this is what stands for now)
Unless my provider of the day is required to assign me address space that is and/or permanently assigned and portable it does not meet my needs. Why not? I am not willing to renumber when I change providers.
You are stuck in a v4 model. Renumbering is fun and healthy. In a residential setting, it should be near automagic.
I have no problem using NAT to obtain connectivity from provider B using providers A address space internally.
Your applications might have issues. Mine do, and I don't like them complaining. Unique is Good(tm).
But that only works if provider A is prevented from reusing 'my' addresses if I terminate my contract.
They are not yours, and why bother anyway? Just digits. (if you say "security", wrong answer, go back and relearn.)
And what do I do if I build my network without ties to any provider? Can I go to ARIN to get globally unique address space, an ipv6 /48? Without RFC1918 that would be my only choice to prevent from overlapping my network with someone elses.
There is an issue here -- various schemes have been presented (research ships, planes, anything) that are exotic at best, yet we can't completely ignore them. However, I do not think non-unique prefixen are the way to go. See above under "mergers". -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
I see this a lot recently: You are mixing up RfC1918 and NAT.
If I have globally unique addresses I can NAT them as well as 10/8. One has nothing to do with the other.
Having to NAT RfC1918 addresses to reach the internet, does not imply that I have to have RfC1918 to be able to do NAT.
but having 1918, site-loco, whatever, and wanting to reach the internet REQUIRES nat. we'll love it in ipv6; can't let things be too simple, eh? randy
Randy Bush wrote:
I see this a lot recently: You are mixing up RfC1918 and NAT.
If I have globally unique addresses I can NAT them as well as 10/8. One has nothing to do with the other.
Having to NAT RfC1918 addresses to reach the internet, does not imply that I have to have RfC1918 to be able to do NAT.
but having 1918, site-loco, whatever, and wanting to reach the internet REQUIRES nat. we'll love it in ipv6; can't let things be too simple, eh?
The existence of the address space does not require nat. Being stuck in the mindset where there is only one address on an interface leads people to believe that nat is an automatic result local addresses. Assigning a local prefix for local purposes (like a printer or lightswitch) at the same time as a global prefix for those things that need to reach the Internet does not require nat. Tony
In a message written on Thu, Nov 11, 2004 at 11:16:04AM -0800, Tony Hain wrote:
The existence of the address space does not require nat. Being stuck in the mindset where there is only one address on an interface leads people to believe that nat is an automatic result local addresses. Assigning a local prefix for local purposes (like a printer or lightswitch) at the same time as a global prefix for those things that need to reach the Internet does not require nat.
It's not clear to me that having multiple addresses on every machine makes anything simpler or easier. In particular, if I'm multi-homed to two networks, the "IPv6 way" seems to have each box have an IP address on each network. Which means each box gets to decide which address to use for outgoing connections. For those of us used to managing this on the central router(s) or nat box(es) that's a rather strange idea. If you want to continue to have central control to balance your traffic then we need an entirely new method to communicate with the end hosts (or maybe even individual applications on the end host) to indicate which network is "preferred". Having to double the size of every ACL in your network (once for the local address, once for the "public" address) does not seem simpler. It also seems dangerous, since almost all devices have a limit to ACL size. As if larger addresses wasn't already enough penality on those boxes now we have to list each machine twice. Finally, and perhaps most importantly, the notion that there will be no PI space, is well, laughable. The notion that everyone, no matter how big or how small will add and remove IP Addresses from every device on their network every time they connect or disconnect from an ISP does not sound like a step forward from either public PI space, or from using 1918 space and NAT. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On 11 Nov 2004, at 15:01, Leo Bicknell wrote:
In a message written on Thu, Nov 11, 2004 at 11:16:04AM -0800, Tony Hain wrote:
The existence of the address space does not require nat. Being stuck in the mindset where there is only one address on an interface leads people to believe that nat is an automatic result local addresses. Assigning a local prefix for local purposes (like a printer or lightswitch) at the same time as a global prefix for those things that need to reach the Internet does not require nat.
It's not clear to me that having multiple addresses on every machine makes anything simpler or easier.
In particular, if I'm multi-homed to two networks, the "IPv6 way" seems to have each box have an IP address on each network.
Rather than engage in another invigorating argument as to why the original vision of v6 multihoming is flawed in practice, it may suffice to say that these issues have been debated extensively in multi6, and commenting on the (several) proposed solutions to the general multi-homing problem on the multi6 list may be more productive than re-hashing the reason for multi6's existence on the nanog list. Joe
On Thu, 11 Nov 2004 15:01:36 EST, Leo Bicknell said:
Having to double the size of every ACL in your network (once for the local address, once for the "public" address) does not seem simpler. It also seems dangerous, since almost all devices have a limit to ACL size. As if larger addresses wasn't already enough penality on those boxes now we have to list each machine twice.
Actually, probably not - in the majority of cases, you can put in *one* ACL that drops (for example) all outbound packets for anything in the /32 and avoid having to list each machine twice. Yes, it's still double - but it's two subnet entries, not two copies of all 2,048 addresses in the subnet.... (Hint - you'd *have* to do it that way - you *cant* enumerate all the possible addresses in an IPv6 /64 unless your router has terabytes of memory...)
Hello, I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space. Wouldn't 0::10.0.0.0/104, 0::192.168.0.0/112, and 0::172.16.0.0/116 (or whatever the appropriate masks would be) all function as v6 addresses with exactly the same properties at the current RFC1918 space? Eric :)
I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space.
because there is not enough v6 address space? because we like nats? because we think we can't get space? randy
On Mon, Nov 08, 2004 at 01:04:28PM -0800, Randy Bush wrote:
I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space.
because there is not enough v6 address space? because we like nats?
There's no PI (yet) for IPv6, so NAT becomes necessary again. People don't like to give up the independence they have in IPv4 world.
because we think we can't get space?
For non-ISPs this is fact, given that there is no PI (yet). ISPs are allowed to multihome and have their independent address space, other's are told to be happy with vendor lock-in. IPv6 won't fly like that. But that's no news, but still heads are sticking deeply in the sandbox, unfortunately. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space.
because there is not enough v6 address space? because we like nats?
There's no PI (yet) for IPv6, so NAT becomes necessary again. People don't like to give up the independence they have in IPv4 world.
because we think we can't get space?
For non-ISPs this is fact, given that there is no PI (yet). ISPs are allowed to multihome and have their independent address space, other's are told to be happy with vendor lock-in.
IPv6 won't fly like that. But that's no news, but still heads are sticking deeply in the sandbox, unfortunately.
let me see if i understand. you propose a technical cluster <bleep> with which we are already horrifyingly familiar to fix an administrative problem? have i got it right? randy
On Mon, Nov 08, 2004 at 01:22:07PM -0800, Randy Bush wrote:
let me see if i understand. you propose a technical cluster <bleep> with which we are already horrifyingly familiar to fix an administrative problem? have i got it right?
No, you didn't. I didn't propose anything, and especially not NAT. I just reflect realities out there. Personally, I just wait for people to realize that they won't be able to force people into provider lock-in, allow one PI prefix per AS and THEN things can go off. With that, the global IPv6 table would be around 18k routes btw. As IPv4 and ASN are virtually unrestricted available today, I don't suspect any bigger growth rates in IPv6 land for ASNs and prefixes than in the IPv4 land. As such, I fail to see the problem with PI for IPv6 for a long long time to come. But that's just me silly. :-) And yes, I read multi6 WG. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hay, Daniel Roesen wrote: [...]
Personally, I just wait for people to realize that they won't be able to force people into provider lock-in, allow one PI prefix per AS and THEN things can go off. With that, the global IPv6 table would be around 18k routes btw. As IPv4 and ASN are virtually unrestricted available today, I don't suspect any bigger growth rates in IPv6 land for ASNs and prefixes than in the IPv4 land. As such, I fail to see the problem with PI for IPv6 for a long long time to come.
But that's just me silly. :-)
...not only you... "Lower your filters, Resistance is futile. You will be flooded with /48s" :-> No, i mean, this issue/discussion is several years old now. I haven't seen any movement in either direction - pro or contra IPv6-PI (or less strict IPv6-BGP filters to be correct) throughout the last years. There are many good reasons why it's simply a matter of fact, that even if you start IPv6-PI now, the IPv6-BGP tables won't reach the currernt IPv4 size for the whole lifetime of IPv6, let alone that you always have to carry around the IPv4 tables for a loooooooooooong time anyways, not to mention that current routers are already fast enough and have enough RAM for decades to come anyways (yes, "640k is enough for anyone" :-). This is simply stuck and one of the more important issues, why IPv6 doesn't work out yet (like you said, "It's less useful than IPv4"). Believe it or not, there's a real world outside. We might not like it from a technical point of view, but we build networks for "them" to use it, so I don't even see the point about refusing IPv6-PI by anyone who wants to push IPv6-deployment. But anyways, this thread is about something different, about RfC1918-equivalents. This shouldn't be mixed up in first place, but I don't really like the idea of private IPv6 Network range either, because it means there will be IPv6-NAT with all the problems that NAT might cause, but there really might be SOME people who want to have it just like that. Same thing as above... if people just LOVE RfC1918 and NAT, they might not want to have IPv6 because "it doesn't work with that". Again, believe it or not, the majority of people and even network-admins out there don't really care if a solution is "the best for the community" or "the best from a scientific point of view", they just want it to be simple and working. ...and i always thought that IPv6 was build to be "simple and working".
And yes, I read multi6 WG.
Sure, nice to have multi6 and new ideas, but i don't see them being implemented and useful until 2015 or so (no offencement, people of multi6 :-) Note: I don't say that new multihoming solutions are a wast of time, au contrair... but they _all_ won't replace the current (BGP-/PI-)multihoming solution in every case. -- ======================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================
In message <20041108195312.GA91916@ussenterprise.ufp.org>, Leo Bicknell writes:
In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wr= ote:
Just out of interest, why do you think 1918-style space for v6 is=20 needed?
I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6.
However, both of these proposals go well beyond how 1918 space works today, and both make promises of "global uniqueness" that are at best inappropriate, at worst a road to disaster.
There are cetainly main uses; one can quibble over whether or not they're "good"... That said, see draft-ietf-ipv6-unique-local-addr-07.txt In not very different form, it's likely to be approved soon by the IESG. --Steve Bellovin, http://www.research.att.com/~smb
At 3:37 PM -0500 11/8/04, Steven M. Bellovin wrote:
In That said, see draft-ietf-ipv6-unique-local-addr-07.txt In not very different form, it's likely to be approved soon by the IESG.
With due respect to my colleague Steve, I think this depends on what "not very different from" means. I'm currently holding a DISCUSS on this document, for reasons related to the ones Leo raised. In particular, I strongly believe that allocating this space: This document only allocates the prefix (FC00::/8) for centrally assigned local IPv6 addresses. The characteristics and technical allocation requirements for centrally assigned Local IPv6 addresses will be defined in a separate document. is very unwise. One of the problems with site local was the prefix got allocated but the work on what it would mean never got full community support. Doing the same thing twice just strikes me as dumb. I have some other very serious concerns about the extent to which the document presumes that these will be routed between ASes without recognizing that this means they could become the v6 swamp. So this discussion is *not* over, and I believe comments from operators to the WG and to the IESG are still very appropriate. regards, Ted Hardie
is very unwise. One of the problems with site local was the prefix got allocated but the work on what it would mean never got full community support. Doing the same thing twice just strikes me as dumb.
do you mean 1918 twice or site-loco twice? both are stoopid. either is stoopid. it'll be interesting to see if the ivtf does it again. stick to your guns. randy
In message <p06110400bdb59b451f59@[130.129.135.206]>, Ted Hardie writes:
At 3:37 PM -0500 11/8/04, Steven M. Bellovin wrote:
In That said, see draft-ietf-ipv6-unique-local-addr-07.txt In not very different form, it's likely to be approved soon by the IESG.
With due respect to my colleague Steve, I think this depends on what "not very different from" means. I'm currently holding a DISCUSS on this document, for reasons related to the ones Leo raised. In particular, I strongly believe that allocating this space:
This document only allocates the prefix (FC00::/8) for centrally assigned local IPv6 addresses. The characteristics and technical allocation requirements for centrally assigned Local IPv6 addresses will be defined in a separate document.
is very unwise. One of the problems with site local was the prefix got allocated but the work on what it would mean never got full community support. Doing the same thing twice just strikes me as dumb. I have some other very serious concerns about the extent to which the document presumes that these will be routed between ASes without recognizing that this means they could become the v6 swamp. So this discussion is *not* over, and I believe comments from operators to the WG and to the IESG are still very appropriate.
Thanks. Ted is quite right, of course. --Steve Bellovin, http://www.research.att.com/~smb
On Mon, 2004-11-08 at 14:53 -0500, Leo Bicknell wrote:
In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote:
Just out of interest, why do you think 1918-style space for v6 is needed?
I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6.
However, both of these proposals go well beyond how 1918 space works today, and both make promises of "global uniqueness" that are at best inappropriate, at worst a road to disaster.
Please read: http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt That contains most of the answers to your questions ;) Greets, Jeroen
In a message written on Tue, Nov 09, 2004 at 08:55:51AM +0100, Jeroen Massar wrote:
http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt
That contains most of the answers to your questions ;)
Not really. It explains to me what a group of people would like to see happen. Major vendors already have NAT for IPv6: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6... Indeed, NAT is being pushed by some vendors as a migration tool from IPv4 to IPv6. I have to believe if the code can do IPv4-IPv6 NAT, then doing IPv6 NAT to IPv6 NAT would be trivial. While I would hope we move away from NAT with IPv6, I realize there are brain dead people today with internal policies that read "All network segments must be protected by NAT." I know NAT != security. You know NAT != security. However, the vendors know they can charge these people for a box that does IPv6-IPv6 NAT, these people (in ignorance) want IPv6-IPv6 NAT. Therefor it will exist, and people will use it. So, while you can talk until you're blue in the face about why it may not be needed, good planning dictates you have to realize it will exist, and as such consider what the impact will be on the network. Good product design means designing for people who do stupid stuff with your product, to a certain degree. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
--On tisdag 9 november 2004 16.32 +0000 Alex Bligh <alex@alex.org.uk> wrote:
--On 09 November 2004 11:09 -0500 Leo Bicknell <bicknell@ufp.org> wrote:
I have to believe if the code can do IPv4-IPv6 NAT
I want to see IPv4-IPv4 NAT working first...
With sufficent thrust, pigs fly just fine. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
On Tue, 2004-11-09 at 11:09 -0500, Leo Bicknell wrote:
In a message written on Tue, Nov 09, 2004 at 08:55:51AM +0100, Jeroen Massar wrote:
http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt
That contains most of the answers to your questions ;)
Not really. It explains to me what a group of people would like to see happen.
It should also be the way you should want to see things happen, that is: no more NAT.
Major vendors already have NAT for IPv6:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6...
Indeed, NAT is being pushed by some vendors as a migration tool from IPv4 to IPv6. I have to believe if the code can do IPv4-IPv6 NAT, then doing IPv6 NAT to IPv6 NAT would be trivial.
NAT-PT is a transition mechanism from IPv4 towards IPv6. To quote the first paragraph of the above url: 8<-------------- Network Address Translation - Protocol Translation (NAT-PT) is an IPv6- IPv4 translation mechanism, as defined in RFC 2765 and RFC 2766, allowing IPv6-only devices to communicate with IPv4-only devices and vice versa. --------------->8 Where does this mention IPv6-IPv6 NAT ? It contains pictures too ;) It is fortunately not IPv6-IPv6 NAT, thus please don't say "major vendors are pushing it" and that "they already have it" and I hope nobody will come up with it either. The entity that does, should stay with IPv4 and not even take the trouble thinking of IPv6. Btw check the authors list of the draft and the companies they work for and guess which companies will not be doing anything in that order. There goes your 'major vendor' argument.
While I would hope we move away from NAT with IPv6, I realize there are brain dead people today with internal policies that read "All network segments must be protected by NAT." I know NAT != security. You know NAT != security. However, the vendors know they can charge these people for a box that does IPv6-IPv6 NAT, these people (in ignorance) want IPv6-IPv6 NAT. Therefor it will exist, and people will use it.
That is why the above draft exists, to get the ties aligned and in order. They have to get an understanding that NAT is not the way.
So, while you can talk until you're blue in the face about why it may not be needed, good planning dictates you have to realize it will exist, and as such consider what the impact will be on the network. Good product design means designing for people who do stupid stuff with your product, to a certain degree.
I fortunately type, not talk about this, unless it starts freezing here (hmm it is already going that direction but we have climate control here), my fingers won't become blue either ;) Greets, Jeroen
On 9-nov-04, at 17:09, Leo Bicknell wrote:
Indeed, NAT is being pushed by some vendors as a migration tool from IPv4 to IPv6. I have to believe if the code can do IPv4-IPv6 NAT, then doing IPv6 NAT to IPv6 NAT would be trivial.
There is a very big difference about NAT in IPv4 and NAT in IPv6, though: In IPv4, you can't ignore NAT because it's too widespread and it's impossible to iradicate it because there isn't enough address space. So people are bending over backwards to make their stuff NAT compatible. However, there is plenty of address space in IPv6 to go NATless, so protocol desingers and implementers are unlikey to add NAT workarounds for IPv6. This means it's very unlikely that applications that don't use simple client/server communication are going to work with NAT in IPv6.
In a message written on Tue, Nov 09, 2004 at 11:46:49PM +0100, Iljitsch van Beijnum wrote:
However, there is plenty of address space in IPv6 to go NATless, so protocol desingers and implementers are unlikey to add NAT workarounds for IPv6. This means it's very unlikely that applications that don't use simple client/server communication are going to work with NAT in IPv6.
As long as IPv4 exists, which I predict will be a long time, the "protocol designers" which are really application developers for your purposes, will write to the lowest common denominator. API's for all the major platforms already look like this; you open a TCP socket to an end address, be it IPv4 or IPv6 in a dual stack machine. So with the protocols still designed to work over IPv4 NAT, and the complexity of IPv6 NAT being roughly "s/long/long long/g" (yes, simplified, but you get my point) and recompiling your NAT code, I'm not sure what will be the barrier to IPv6 NAT. I would love to see a solid technical reason why IPv6 NAT will NOT work. In the absense of that I will stick to my guns and say that it will work and be available, and most likely sooner rather than later. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Tue, 9 Nov 2004, Leo Bicknell wrote:
As long as IPv4 exists, which I predict will be a long time, the "protocol designers" which are really application developers for your purposes, will write to the lowest common denominator. [...]
So with the protocols still designed to work over IPv4 NAT, [...]
Not quite true. With the coming of IPv6 (+NAT traversing technologies requiring only little of the network, like Teredo) in large scale to the home desktops (think Windows XP SP2), it's quite conceivable we're going to have large-scale v6-only applications relatively soon -- for the cases where the application in question would not have to deal with NAT traversal logic at all if it were to choose v6-only approach. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 10-nov-04, at 0:00, Leo Bicknell wrote:
with the protocols still designed to work over IPv4 NAT, and the complexity of IPv6 NAT being roughly "s/long/long long/g" (yes, simplified, but you get my point) and recompiling your NAT code, I'm not sure what will be the barrier to IPv6 NAT.
The main problem with NAT is protocols that embed IP addresses. I don't think many protocol implementations can be changed by a search and replace like operation, the same way simple apps can.
I would love to see a solid technical reason why IPv6 NAT will NOT work. In the absense of that I will stick to my guns and say that it will work and be available, and most likely sooner rather than later.
NAT doesn't work for MANY things by default. You have to add stuff to make it work. If this stuff isn't added for IPv6, your IPv6 NAT will only work with simple client/server apps. Also: what is the point? If you're going to do NAT anyway, why bother with IPv6?
At 02:36 PM 11/8/2004, you wrote:
On 8 Nov 2004, at 14:25, Leo Bicknell wrote:
In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today.
Just out of interest, why do you think 1918-style space for v6 is needed?
Well, you asked the original poster, but since you asked publicly, I'll answer with my reasons. Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments. Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too. Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside. Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.
On Mon, Nov 08, 2004 at 03:46:05PM -0500, Daniel Senie wrote:
Reason #3: A separate set of blocks should be set aside for use ONLY in documentation.
inet6num: 2001:0DB8::/32 netname: IPV6-DOC-AP descr: IPv6 prefix for documentation purpose [...] remarks: This address range is to be used for documentation remarks: purpose only. For more information please see remarks: http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html
Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment.
I don't see that this is "hard". The box will get a /48 from the ISP's DHCPv6 server (or whatever is used for that) and re-use subnets for that for inside routing. Like simply the first /64, and doing router advertisements on the inside ethernet for this subnet to allow autoconfig of the hosts of the home LAN. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Mon, 8 Nov 2004, Daniel Senie wrote:
Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments.
Sure, though see #3 which can be stolen for lab usage as well.
Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too.
For serious usage, I don't think the money involved is a major issues.
Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside.
Already done, 2001:db8::/32 is set aside for documentation.
Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.
Setting up local v6 addressing for this reason seems like a bad idea because there is no NAT and no global connectivity, so the box will need some automated configuration protocol in any case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
At 04:17 PM 11/8/2004, Pekka Savola wrote:
On Mon, 8 Nov 2004, Daniel Senie wrote:
Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments.
Sure, though see #3 which can be stolen for lab usage as well.
I'm not sure it's a great idea to tie these together, based on what I've seen in the past.
Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too.
For serious usage, I don't think the money involved is a major issues.
Translation: only rich companies are entitled. Smaller businesses are not entitled to space, and not entitled to use IPv6. For offline use, I guess IPv4 will be the permanent solution.
Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside.
Already done, 2001:db8::/32 is set aside for documentation.
Good.
Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.
Setting up local v6 addressing for this reason seems like a bad idea because there is no NAT and no global connectivity, so the box will need some automated configuration protocol in any case.
Autoconfiguration is probably not the answer to every piece of routing gear or every embedded system built. I guess designers will need to continue installing a serial port on every device to ensure there is some way to get into the device and configure it if autoconfiguration isn't able to conquer the world.
On 8-nov-04, at 23:42, Daniel Senie wrote:
Setting up local v6 addressing for this reason seems like a bad idea because there is no NAT and no global connectivity, so the box will need some automated configuration protocol in any case.
Autoconfiguration is probably not the answer to every piece of routing gear or every embedded system built. I guess designers will need to continue installing a serial port on every device to ensure there is some way to get into the device and configure it if autoconfiguration isn't able to conquer the world.
This is a solved problem. For instance, Apple sells wifi base stations that don't have a console port. When you turn the base station on, it will grab a link local address (169.254.0.0/16 in IPv4) and announce its presence using multicast DNS / zeroconf (Rendezvous in Applespeak). The configuration software can thus easily build a list of available base stations so the admin can configure them. However, there is a caveat as a host with a "real" address can't generally talk with one that has an 169.254.x.x address. In IPv6 this isn't a problem because all hosts must have link local addresses in addition to any global addresses.
First of all, as one of the proponents of ULAs in the IPv6 WG, I want to emphatically state that enabling IPv6 NAT was not the justification for ULAs. It might make doing so easier, which is unfortunate, but there are lots of other reasons that justify their creation and not creating ULAs is unlikely to prevent IPv6 NAT anyways because, as others here have noted, people will do it anyway with some other address range. The central point we kept coming back to was that local addressing of some sort will inevitably be used in many places, and providing a mechanism to prevent collisions was deemed worthwhile. Thus spake "Daniel Senie" <dts@senie.com>
At 02:36 PM 11/8/2004, you wrote:
Just out of interest, why do you think 1918-style space for v6 is needed?
Well, you asked the original poster, but since you asked publicly, I'll answer with my reasons.
Reason #1: Lab use. People should NEVER, EVER pick random space from public > space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments.
I don't think this use ever came up, but it makes sense.
Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too.
This was a big motivator. Disjoint or occasionally-connected networks need an address pool that is guaranteed to work within their own domain. Even if PI space were made available, that involves time, money, paperwork, etc. for people who currently don't have to deal with that when using RFC1918.
Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.
IMHO, link local addresses should be used for this. Reason #5: Thanks to prefix delegation, unavailability of PI addresses, etc. global addresses are viewed as "unstable". The current IPv6 multihoming model says that prefixes for each connection should be distributed and assigned to hosts throughout the domain; these prefixes may come and go as those connections go up and down, disrupting internal-only communication. Not acceptable. Reason #6: Many enterprises will want "internal-only" resources that never get assigned a global address, and ULAs fit this need well. Sure, we all know that this isn't true security, but it's a lot easier to simply block all ULAs at your border than to maintain lists of specific subnets out of your globals that should not talk to the outside world. Less maintenance means fewer errors and thus fewer leaks and security goofs. Reason #7: Following on to that, some companies elect to not assign PA addresses internally for any hosts, requiring them to go through proxies for any external access. Some use PI for this today, others use RFC1918, but since neither option is available in IPv6 they would use ULAs for this. Reason #8: Many companies need addresses to communicate with business partners privately and using global addresses complicates (and thus introduces human errors into) routing, ACLs, DNS, etc. when those globals are reached via a link other than their default route. This is currently a mess with RFC1918 addresses because each pair of companies must negotiate range(s) of addresses that aren't already in use in either network; N companies will have O(N^2) negotiations, which clearly doesn't scale. In closing, I'll note that the nature of the central registry was criticized no matter what was proposed; what is in the draft now is the least objectionable of what was floated, and it did survive consultation with the existing RIRs. I can't recall if a home was indeed found for it already, but there were several offers of organizations willing to provide the service at no cost, which is how that ended up in the draft. The central registry was split off from the main draft because it's not clear that consensus was achieved on that element and the chairs didn't want to hold up the rest of the draft. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
Just out of interest, why do you think 1918-style space for v6 is needed?
If we could assign every entity who wanted one sufficient non-routable, globally unique space, we wouldn't need 1918-style space. There are, however, three problems with this approach: 1) It encourages massive waste. Perhaps so massive that we would run out of space. 2) There is a cost associated with assigning globally-unique space no matter how you do it. This cost could be too high for some application -- RFC-1918-style space is free. 3) There is a concern that some recipients of this globally-unique unroutable space might use political pressure to get that space routed. This could potentially lead to an explosion of the number of routes in the global table. However, there are huge advantages. Private networks could seamlessly overlay the Internet and each other where desired with no risk of a future merger causing a numbering conflict. I think the first and second problems are solvable. The third problem, however, may be the deal killer. It's a very realistic concern that the technologies we develop and promote can be designed to make things we consider bad easier or harder to do. Technologies can encourage cooperative interoperability or free riding, privacy or interceptability, and so on. DS
2) There is a cost associated with assigning globally-unique space no matter how you do it. This cost could be too high for some application -- RFC-1918-style space is free.
you want unique space but not pay for the administration of it. absolutely brilliant.
3) There is a concern that some recipients of this globally-unique unroutable space might use political pressure to get that space routed. This could potentially lead to an explosion of the number of routes in the global table.
look, there are two camps o v6 space is effectively infinite and the routing table can handle 500k entries easy o v6 space is kinda small (sure wish they had done variable length), and we should worry about the routing table in the first case, let them eat cake and to hell with all this yakking. in the latter case, withdraw the allocations of golden space to special services, stop allocating monsterous /48s to ethernets when we know layer-2 does not scale, stop giving /32s to anyone who asks (or whatever the fashionable prefix of the week is, i can't keep track), etc. either this thing is big enough and gonna scale, or send the turkey back to the drawing boards. but don't add already well-known disasters on top of something in which you have insufficient faith to trust to scale well. randy
On Mon, Nov 08, 2004 at 02:25:00PM -0500, Leo Bicknell wrote:
More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet.
Well, thinking about the enterprise for a change might be a good idea, as the Enterprise markets are the one paying most of the ISPs in the end. And with the ISP-centric approach of the current address policies there is absolutely no chance IPv6 will ever make it to the big market. As long as I can neither multihome nor NAT my network, I have no chance to be independant of a provider. As the provider business itself is extremely unstable that is something no enterprise can possibly want. So there must be a way to be provider independent on my network, otherwise I am pretty much doomed. I do hate NAT and I think it is a major pain. Providers decided (they are the ones active in the working groups on Address policies, remember?) that their customers should not be able to be multihomed, because the equipment to handle this is too expensive, so I at least want a globally unique private address, so I do not have to double NAT, when I connect my network to some customers or suppliers network. I agree, that the proposed solutions are not perfect, but they at least give enterprise network admins the chance to do the right thing. With RfC1918 (shall we call it site local addressing, maybe?) I am almost forced to use the same address space as my customers and suppliers do. The two approaches mentioned only will give collisions, when one side uses them inappropriately. I think having the chance to do it right is better then not having it. Nils
On Mon, Nov 08, 2004 at 02:25:00PM -0500, Leo Bicknell wrote:
More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet.
Well, thinking about the enterprise for a change might be a good idea, as the Enterprise markets are the one paying most of the ISPs in the end. And with the ISP-centric approach of the current address policies there is absolutely no chance IPv6 will ever make it to the big market. Snip You bring up a very good point and one that is often ignored. The enterprise customers Do they understand IPv6 Do they want IPv6 Do they need IPv6 Are they writing IPv6 applications Right now there is no good reason for them to switch to ipv6 and they certainly aren't writing any apps for it. They are however waiting and hoping it doesn't happen.
On 8-nov-04, at 20:25, Leo Bicknell wrote:
I will post a very brief summary of my objections, for the first (unique-local):
- I believe the math is wrong on the rate of collisions, primarily because it assumes in a large organization there is a central coordination function to pick and distribute these addresses. However, since the whole point of "unique local" addresses is that there need be no coordination, I can easily see a case where a large conglomerate (Ford, GE, whatever) coming together with another will have both sides bringing hundreds, if not thoundsands of prefixes to the table as each division or other subgroup picks their own.
Well, if they can manage to interconnect all those networks a tiny amount of coordination isn't too much to ask for. Also, with the proper hashing this shouldn't be much of a problem even without coordination. Yes, no coordination and bad hashing won't work, but guess what: don't do that.
- I think the likelyhood people will use the suggested hash methods to pick addresses is extremely low. People will either pick "human friendly" (1, 2, 3, 4, etc) or treat the space more like CIDR (where there is central delegation), both of which move the likelyhood of collision to near 1.
In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today.
Your argument is that people are going to be stupid so we should skip ahead and give them the result of their stupidity. Now obviously there will be people who do it the stupid way, but at least unique site locals allow the people who don't do it the stupid way certain benefits. I don't see how this can ever be a bad thing. Also, you can still use the original IPv6 site local space, as I don't see it being reused for something else any time soon. But if you do, you'll probably discover that there is a reason why the IETF decided to deprecate those.
- It is not good engineering to give something away for free with no method of recovery, even if that resource is plentiful.
So we should play telco and sell a service that is so cheap that the users are basically only paying for the billing? (= metered local calls)
- Since this is a free method of globally unique space it has a high likelyhood of being routed on portions of the public internet. Indeed, this problem was quickly dismissed by the authors (see http://www1.ietf.org/mail-archive/web/ipv6/current/msg03848.html), who completely missed the boat. It's not the rich who would demand their prefix be routed, but the poor.
That's nice. But it simply can't be done for any significant number of PI prefixes. That's why we're going through so much trouble to create a multihoming mechanism that doesn't kill the routing system.
Since this is a list of providers, I encourage you to read the drafts, and submit your comments to the working group. The information for the working group is at http://www.ietf.org/html.charters/ipv6-charter.html, and includes their mailing list archives and information on how to subscribe and/or post.
Even if you disagree with me, much like voting the important thing is that you voice your opinion.
I suggest that everyone who is willing to spend the time, also looks into the "site local" debates that have plagued the IETF in recent years.
In a message written on Mon, Nov 08, 2004 at 10:46:48PM +0100, Iljitsch van Beijnum wrote:
Well, if they can manage to interconnect all those networks a tiny amount of coordination isn't too much to ask for. Also, with the proper hashing this shouldn't be much of a problem even without coordination. Yes, no coordination and bad hashing won't work, but guess what: don't do that.
It is too much to ask for, because you assume it's one company day one. What happens when AOL and Time Warner merge? There was no chance of coordination before that. Or how about Cisco? They buy what, 100-200 companies a year? My problem is that even with good hashing it doesn't take long for there to be a collision. And once there is a single collision the whole system is suspect. It's the promise of "if you do this extra work you'll never have to renumber" without delivering.
Your argument is that people are going to be stupid so we should skip ahead and give them the result of their stupidity. Now obviously there will be people who do it the stupid way, but at least unique site locals allow the people who don't do it the stupid way certain benefits. I don't see how this can ever be a bad thing.
No, my argument is that it only takes a few stupid people to make this entire system not work at all. Since the draft seems to promise it will work it is misleading people. Indeed, I have "proof" the IPv6 crowd realizes this won't work at all, and it's the other draft. If this draft had a chance of working then there would be no need to create a central registry to guarantee unique addresses. The very existence of that draft shows some people realize this method will not work.
- It is not good engineering to give something away for free with no method of recovery, even if that resource is plentiful.
So we should play telco and sell a service that is so cheap that the users are basically only paying for the billing? (= metered local calls)
No. My argument is not about money. In this system anyone can get something for free anytime they want. "Lose" your address block? Make it unusable for some purpose (eg, blacklisted)? Just want a second (third, fourth, millionth) block, just go get it. Get a block, then die? Well, no one else can ever use your personal block. If you get a personal block, then die, no one else can ever reuse that block. Every failed dot-com, that's address space we'll never be able to use again. I realize there is a lot of space, but this proposal really seems to ask the question "how fast can we waste space if we try", which is very dangerous in my opinion.
That's nice. But it simply can't be done for any significant number of PI prefixes. That's why we're going through so much trouble to create a multihoming mechanism that doesn't kill the routing system.
Bah, hand-waving that makes no sense. There are 33,000 allocated ASN's today. Give each one a PI prefix (however they might get it). That's 33,000 routes. Given my routers are fine with 140,000 now, and are being tested in labs to well over 1 million and I fail to see the issue. Let's assume they all have two PI prefixes for load balancing, ok, we're at 66,000, still no problem. More to the point, if most network admins have the choice of running a full overlay network and updating software on every end host to be more complex to make it understand the overlay networks or puting a few more prefixes in the routing table and upgrading your router I bet they will all pick the latter. The problem is not routing PI blocks for all the existing ISP and even companies. The problem is routing blocks for individuals. If ISP's fall to pressure to route these prefixes between themselves (after all, they are globally unique, so what's the harm?) and then you inject individual's prefixes into the table you now have a melt down. As with most system failures it takes multiple steps. However, I think these steps are likely. ISP's in Asia have complained forever that they don't get a fair share of the space. Well, here they can take, take, take and use as much as they need. ISP's in Africa have complained space costs too much (ARIN's fees, though low by US standards are several years sallary in some countries), and want a way around it. If those groups used this space even only internally at first between each other (after all, the purpose is to allow routing between organizations, just not to the global internet) eventually there will be great pressure to add them to the global table. It will be phrased as "UUNet won't accept prefixes from all of Asia" or similar. Then we end up having to accept them with none of the controls the RIR system puts in place for setting policy or anything else. Prefixes will instead be randomly assigned worldwide out of a single /7. Distilled down the proposal makes no sense. 1 You can have globally unique addresses. 2 You can use them between organizations. a If your organization is an ISP, please don't allow them on the "Internet". -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On 8-nov-04, at 23:15, Leo Bicknell wrote:
Well, if they can manage to interconnect all those networks a tiny amount of coordination isn't too much to ask for. Also, with the proper hashing this shouldn't be much of a problem even without coordination. Yes, no coordination and bad hashing won't work, but guess what: don't do that.
It is too much to ask for, because you assume it's one company day one. What happens when AOL and Time Warner merge? There was no chance of coordination before that. Or how about Cisco? They buy what, 100-200 companies a year?
If both companies use either registered globally unique space (which also has the important property you get to know who the packets come from when they show up in the wrong places) or use the unregistered variant with proper hashing, the chance of collisions is negligible. So it IS possible to make sure bad things don't happen in advance. I suspect most people who don't bother with the hashing are ones who don't expect to interconnect with anyone else using those addresses. Obviously some will be wrong about that. And unlike IPv4, it's easy to give all hosts more than one address and renumbering the hosts themselves is fairly straightforward.
My problem is that even with good hashing it doesn't take long for there to be a collision. And once there is a single collision the whole system is suspect. It's the promise of "if you do this extra work you'll never have to renumber" without delivering.
Disagree. You know the hashing space isn't 100% unique. And it doesn't need to be: it only needs to be unique between the people who use the new type of site local addresses to communicate between them. IIRC there are 40 bits so when a million or so of these prefixes are used you're going to start seeing some collisions - if you look globally. But the chance of two networks colliding is still one in a trillion (with good hashing) and the chance of a thousand networks colliding is almost zero. This is actually smaller than the chance that two ethernet cards have the same MAC address. (Once in a blue moon batches of NICs with the same MAC address are built, but the chance of finding two that clash is relatively large if you buy several because they are likely manufactured right after each other.) And there's still the registered variant.
No, my argument is that it only takes a few stupid people to make this entire system not work at all.
I don't see this.
If this draft had a chance of working then there would be no need to create a central registry to guarantee unique addresses. The very existence of that draft shows some people realize this method will not work.
With registered space you have the additional benefit that when packets leak, they can be traced back to the originator, and it's possible to delegate name service.
In this system anyone can get something for free anytime they want. "Lose" your address block? Make it unusable for some purpose (eg, blacklisted)? Just want a second (third, fourth, millionth) block, just go get it. Get a block, then die? Well, no one else can ever use your personal block.
I agree in principle. However, I think this means the administrative procedure must be changed rather than that it means this type of address space is a bad idea. I think all of this can be done in very similar vain to registering domains. Since there is plenty of competition there, this will probably be sufficiently cheap that even organizations in less developed countries can afford it.
That's nice. But it simply can't be done for any significant number of PI prefixes. That's why we're going through so much trouble to create a multihoming mechanism that doesn't kill the routing system.
Bah, hand-waving that makes no sense.
It's starting to, although there is still a lot of work to do. (Yes, long overdue...)
There are 33,000 allocated ASN's today. Give each one a PI prefix (however they might get it). That's 33,000 routes. Given my routers are fine with 140,000 now, and are being tested in labs to well over 1 million and I fail to see the issue.
Well, I can't _guarantee_ routers are going to explode when people start doing PI in IPv6, but I think they will, eventually. The big difference with IPv4 is that in IPv4, there is still a significant hurdle to multihoming, as you need at least a /24. In IPv4 _everyone_ gets to have a /48. And once so many important services sit in /48s that you can't filter them individually anymore, you need to allow all /48s in your routing tables and then you're at the mercy of how popular multihoming is going to be. It could easily end well (multihoming isn't that popular today) but the risk of it going very badly is just too big IMO. Also, remember that BGP convergence scales at O(n.log(n)). (You need to go through the existing routing table which is at best a log(n) operation for each new route.) This means the routing table growth needs to stay well below Moore or there's trouble.
More to the point, if most network admins have the choice of running a full overlay network and updating software on every end host to be more complex to make it understand the overlay networks or puting a few more prefixes in the routing table and upgrading your router I bet they will all pick the latter.
The trouble is that straight PI means painting ourselves in a corner. Sure, the room may be big and there may not be that much paint that it becomes a problem, but once you start there is no going back. I thought we could have our cake and eat it too by aggregating PI space geographically (http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr -01.txt for those who care) but the G word is taboo in the IETF. Oh well.
If those groups used this space even only internally at first between each other (after all, the purpose is to allow routing between organizations, just not to the global internet) eventually there will be great pressure to add them to the global table. It will be phrased as "UUNet won't accept prefixes from all of Asia" or similar. Then we end up having to accept them with none of the controls the RIR system puts in place for setting policy or anything else. Prefixes will instead be randomly assigned worldwide out of a single /7.
There are enough stubborn network operators to guarantee that this space will never be globally reachable the same way PA space is. So even if people get to use their PI prefixes for lots of things, they'll still need to have PA addresses too for global reachability. I actually think that would be a very good result is it allows for a dynamic tradeoff in routing table size and usability, while either extreme has the potential to be harmful. (Sure, it sucks to have to try more than one address but that's quickly becoming a reality as we move to IPv4+IPv6 dual stack networks anyway.)
On Tue, Nov 09, 2004, Iljitsch van Beijnum wrote:
And there's still the registered variant.
No, my argument is that it only takes a few stupid people to make this entire system not work at all.
I don't see this.
.. people to not use the hashing.
If this draft had a chance of working then there would be no need to create a central registry to guarantee unique addresses. The very existence of that draft shows some people realize this method will not work.
With registered space you have the additional benefit that when packets leak, they can be traced back to the originator, and it's possible to delegate name service.
I don't think he was objecting to the existance of the registry. I think he was objecting to the existance of /both/ drafts - why use hashing if you can use the RFC1918 registry? The registry which isn't allowed(?) to charge for its duties, which I'm sure will not be zero cost. I don't want to have to tell someone that the block they've /registered/ for is not internet routable, even though its guaranteed unique on the internet, they're not allowed to route it. Really, this won't fly very far. I have a few requests from my managers asking why department X can't talk to department Y - when department X is trying to expose some 10.x address. Inside a university. I'm sure I'm not alone here. Now, on the flip side, i've seen people who run RFC1918 'registries' out of 172.16/12 for things such as local IX (the RFC1918 addresses mean "free" is easier to distinguish. Crazy Australian Charging, don't ask.), local wireless networks just to name two. Heck, there was talk of 'unifying' the RFC1918 allocation(s) across Australia so these city based wireless groups could communicate by tunneling across the public internet! Crazy! adrian, going back under his rock. -- Adrian Chadd "You don't have a TV? Then what's <adrian@creative.net.au> all your furniture pointing at?"
In a message written on Tue, Nov 09, 2004 at 09:17:30AM +0100, Iljitsch van Beijnum wrote:
If both companies use either registered globally unique space (which also has the important property you get to know who the packets come from when they show up in the wrong places) or use the unregistered variant with proper hashing, the chance of collisions is negligible.
My comment here was directed at the unregistered variant. You'll notice the math in the paper assumes each company coming to the table has a single IPv6 unregistered prefix. My statement is that math does not reflect reality. Consider when Cisco wants to do a interconnect with AOL Time Warner, which due to the way they grow both bring 1,000 prefixes to the table. The chance of collision is actually quite high. Almost more interesting is consider the "financial interchange network" where 100 companies come together each with 20 networks. I believe even with that relatively small number of networks (2000 total) the probability of collision is well more than 50%. This is very similar to the birthday problem. http://mathforum.org/dr.math/faq/faq.birthdayprob.html It only takes 23 people (6% of the 365 available birthdays) to generate a 50% chance of collision, with them only bringing one birthday to the table. Bring 20 "birthdays" to the table for each one and that number drops by orders of magnitude.
And unlike IPv4, it's easy to give all hosts more than one address and renumbering the hosts themselves is fairly straightforward.
Another incorrect assumption. First, I want to dispel the notion right now that anyone is going to use IPv6 autoconfiguration. That's another head in the sand idea. We have two groups here. People who run "fixed infrastructure", which include network operators and server operators, and the second group is "end user workstations". The first group has always, and will always statically assign addresses. This will be true with IPv6. They want to know when they swap out a NIC the address doesn't change. They enter IP's in DNS and other systems where having them be static is key. The second group could use autoconfiguration, except it provides none of what they need. Look at the people using DHCP today. They need to get nameserver IP's, WINS server IP's, NTP server IP's, configuration file names and all sorts of other information. They will continue to require DHCP for those tasks. Indeed, just to do DNS mapping again DHCP is required. So, for both groups to "renumber" it's no different than today. One group will still have to manually add/subtract IP's. The other will have to update DHCP scopes, force renewals, and the like. Best I can tell renumbering will be NO LESS expensive in IPv6, and actually will be more expensive, since the IPv6 proponents seem bent on requiring everyone to have 6 addresses to do anything useful, so it will be address management effort x6.
Disagree. You know the hashing space isn't 100% unique. And it doesn't need to be: it only needs to be unique between the people who use the new type of site local addresses to communicate between them. IIRC there are 40 bits so when a million or so of these prefixes are used you're going to start seeing some collisions - if you look globally. But the chance of two networks colliding is still one in a trillion (with good hashing) and the chance of a thousand networks colliding is almost zero. This is actually smaller than the chance that two ethernet cards have the same MAC address. (Once in a blue moon batches of NICs with the same MAC address are built, but the chance of finding two that clash is relatively large if you buy several because they are likely manufactured right after each other.)
Again, see the birthday problem and do the math. I don't think the probability is nearly as remote as you think it is, or as the document would lead you to believe.
And there's still the registered variant.
Which brings us back to why are there two proposals. If there is any chance the randomly assigned ones will fail, then we should do globals. If they aren't going to fail, we should only do random. I have to believe the existence of the second proposal is an indication the first one won't meet it's goals.
With registered space you have the additional benefit that when packets leak, they can be traced back to the originator, and it's possible to delegate name service.
Except the draft doesn't allow for that. I quote: The ownership of the allocations is not needed to be public since the resulting addresses are intended to be used for local communication. The draft does not make that information public.
I think all of this can be done in very similar vain to registering domains. Since there is plenty of competition there, this will probably be sufficiently cheap that even organizations in less developed countries can afford it.
The draft also states, and I quote: - Permanent with no periodic fees. So yes, everyone will be able to afford it. There is not a competition angle here. There is a huge question of how you're going to run a registry with no funding though. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Almost more interesting is consider the "financial interchange network" where 100 companies come together each with 20 networks. I believe even with that relatively small number of networks (2000 total) the probability of collision is well more than 50%.
My company already does this (financial interchange network) using registered globally unique IPv4 addresses. When we transition to IPv6 I see no reason why we would not continue using globally registered IP addresses. The routability of these addresses is not relevant to us because our network is disjoint from the Internet, therefore the addresses only need to be routable on our network. Other organizations have similar types of international IP networks that are disjoint from the Internet. A competitor of ours, SWIFT, operates their own IP network and probably interconnects many of our customers as well. In the automotive industry in Europe there is the ENX http://www.enxo.com that is a similar disjoint network. When I was last involved with ENX it used existing IP backbones but traffic was exchanged over special dedicated peering connections with an enforceable SLA between the two peers monitored by the ENXO. I suppose that SITA must also run IP on their network these days. In all of these cases, companies do not just "come together". The interconnection is carefully planned and often involves some sort of partitioning of the companies' internal networks. For instance, many of our customers connect their trading floors to our network however those trading floors do not have direct connectivity with the Internet even though all of our customers do have Internet connectivity. We are now getting into a very complex area of enterprise network architecture which it is pointless to second guess, because somebody, somewhere will implement any architecture that you can imagine. The point is that when companies interconnect networks, they do not simply merge their internal networks with the internetwork. With our customers, the interconnect is done for a very specific defined purpose and engineers on both sides ensure that the interconnect does not carry traffic that is out of scope. In the case of corporate merger, there would likely be a network audit (due diligence) followed by a decision as to how to deal with the small number of collisions, either renumber them or install an IPv6 NAT device. The decision won't be made based on elegance or RFC compliance, rather it will be made based on the business case. I suspect that if you do the actual maths for companies the size of Microsoft and Time Warner, you will find that the number of collisions will be so low that the business case will lead to renumbering. If anyone disagrees the I would really like to see a worked example of the math.
Best I can tell renumbering will be NO LESS expensive in IPv6, and actually will be more expensive, since the IPv6 proponents seem bent on requiring everyone to have 6 addresses to do anything useful, so it will be address management effort x6.
Address management and renumbering are so important to today's enterprises that they all use some toolset involving LDAP directories, databases and DHCP servers. Multiplying the data content of the database times 6 does not necessarily change the level of effort. I'm surprised that no-one has pointed out how easy it is to get an IPv6 allocation today and set up a registry for globally unique IPv6 addresses for private networks. The initial allocations are large enough to not have to ever return to the RIR for more, and if a company can sell people on the idea of allocating globally unique IPv6 private addresses in the same way as IPv4 (i.e. /128 per host rather than /64) then it would last a long time. By the way, there is already the so-called deprecated site-local address range that folks can use. I assume that "deprecated" just means that you need to explicitly configure the ACLs at your border rather than relying on some automatic routing behavior. Perhaps the draft could be recast as a "best practice" for using site-local addresses via a hashing algorithm that makes collisions less likely. --Michael Dillon
On 9-nov-04, at 17:27, Leo Bicknell wrote:
My comment here was directed at the unregistered variant. You'll notice the math in the paper assumes each company coming to the table has a single IPv6 unregistered prefix.
My statement is that math does not reflect reality. Consider when Cisco wants to do a interconnect with AOL Time Warner, which due to the way they grow both bring 1,000 prefixes to the table. The chance of collision is actually quite high.
Why would a company need 1000 /48s, when a single /48 allows for 65536 subnets?
I believe even with that relatively small number of networks (2000 total) the probability of collision is well more than 50%.
Ok, let's assume there are already 2k networks connected. So a new one would have a one in 2^(40-9) chance of colliding. Do this 2k times and you're at one in 2^22. (Actually less because I'm overlooking the chance of successive collisions.)
This is very similar to the birthday problem. http://mathforum.org/dr.math/faq/faq.birthdayprob.html It only takes 23 people (6% of the 365 available birthdays) to generate a 50% chance of collision, with them only bringing one birthday to the table. Bring 20 "birthdays" to the table for each one and that number drops by orders of magnitude.
But if birthdays are only celebrated once every 3 million millennia (2^40 days) the number goes down again ever so slightly. :-)
And unlike IPv4, it's easy to give all hosts more than one address and renumbering the hosts themselves is fairly straightforward.
Another incorrect assumption. First, I want to dispel the notion right now that anyone is going to use IPv6 autoconfiguration.
We'll have to agree to disagree on this one, as I firmly believe very few people are going to use DHCP in IPv6.
That's another head in the sand idea. We have two groups here. People who run "fixed infrastructure", which include network operators and server operators, and the second group is "end user workstations".
The first group has always, and will always statically assign addresses. This will be true with IPv6. They want to know when they swap out a NIC the address doesn't change.
That's why your favorite C (and presumably other) boxes have the MAC addresses burned in the chassis rather than the NIC.
They enter IP's in DNS and other systems where having them be static is key.
Yes, renumbering the DNS still sux. :-)
The second group could use autoconfiguration, except it provides none of what they need. Look at the people using DHCP today. They need to get nameserver IP's, WINS server IP's, NTP server IP's, configuration file names and all sorts of other information.
Not so much. Autoconfiguration and some DNS resolvers is all I need.
So, for both groups to "renumber" it's no different than today.
There is still a big difference: you get to use the old and new addresses side by side for a while.
Best I can tell renumbering will be NO LESS expensive in IPv6, and actually will be more expensive, since the IPv6 proponents seem bent on requiring everyone to have 6 addresses to do anything useful, so it will be address management effort x6.
Renumbering is always bad, but there are degrees of badness. Fixed subnet masks, ample address space within subnets, multiple addresses all help, even if you discount autoconfiguration (which I don't) and all the filtering and DNS issues are of course the same.
With registered space you have the additional benefit that when packets leak, they can be traced back to the originator, and it's possible to delegate name service.
Except the draft doesn't allow for that. I quote:
The ownership of the allocations is not needed to be public since the resulting addresses are intended to be used for local communication.
The draft does not make that information public.
Well, someone should, if not the draft.
Ok, let me throw some cold reality water on this discussion... Having built the IP network for the second largest supermarket in the US, worked on the networks for the largest supermarket in the UK, the largest 'chemist' in the UK, built the largest website in the world (2.4 million cc transactions/month with over 460 servers) and coordinated an IP renumber for over 3,300 stores with 30+ devices each, I can say that insisting companies renumber their networks to fit into public IPv6 addresses just isn't going to happen. I have devices that have no need, never will have a need, to ever talk outside of the internal networks, nor do I want some brain dead user to drop some stupid little device on the network and tada, route access to some of my inside network simply because the addresses are valid. I want my inside addresses to be non accessible from the 'real world', ever. If IPv6 can't offer me the luxury (even if it is not valid or justified) then I see no reason to change from IPv4 to IPv6 in the core. Just do it on the periphery. It is VERY expensive to a corporation to accomplish a renumber, and if there is no benefit, then..... I imagine my position is not far off from MOST of the corporate network infrastructure maintainers out there. You must remember to take us into account when talking about global addressing policies. In the end, we pay most the bills. :-) Jerry
I have devices that have no need, never will have a need, to ever talk outside of the internal networks, nor do I want some brain dead user to drop some stupid little device on the network and tada, route access to some of my inside network simply because the addresses are valid. I want my inside addresses to be non accessible from the 'real world', ever.
this is a routing problem, not an addressing problem. trying to make it an addressing problem will end you with messes that we have today with 1918, for which you can read years of email on this list of "why can't i get to, through, reply, ...?" randy
On Wed, Nov 10, 2004 at 02:17:41AM -0500, Jerry Eyers wrote:
Ok, let me throw some cold reality water on this discussion...
...
in the UK, the largest 'chemist' in the UK, built the largest website in the world (2.4 million cc transactions/month with over 460 servers) and coordinated an IP renumber for over 3,300 stores
cold reality is about right. 2.4 million cc transactions/mo with over four hundred and sixty (460)! servers makes it the largest web site in the world? I better tell that to our datacenter folks or the guys over at amazon or msn or latency.net - Adam Rothschild does more than that on his laptop with a wifi card and a hacked-up wrt58g.
network infrastructure maintainers out there. You must remember to take us into account when talking about global addressing policies. In the end, we pay most the bills. :-)
And we thank you for it. /vijay
On Wed, 10 Nov 2004, Jerry Eyers wrote:
I have devices that have no need, never will have a need, to ever talk outside of the internal networks, nor do I want some brain dead user to drop some stupid little device on the network and tada, route access to some of my inside network simply because the addresses are valid. I want my inside addresses to be non accessible from the 'real world', ever. If IPv6 can't offer me the luxury (even if it is not valid or justified) then I see no reason to change from IPv4 to IPv6 in the core. Just do it on the periphery. It is VERY expensive to a corporation to accomplish a renumber, and if there is no benefit, then.....
Depending on putting devices on 1918 for security is dangerious. All it takes is one little misconfigured router (or less than strict filters) and any of your peer's customers can start talking to your backend database servers. Assuming that just because they are 1918 address they are not remotely visable is a dangerous simplification. eg I just hopped though 3 providers (using default routes) to ping a well known [1] 192.168.x.x address. [1] - In NZ. -- Simon J. Lyall. | Very Busy | Mail: simon@darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.
since this is a few days late on the conversation someone might have said this but.... On Tue, 9 Nov 2004, Iljitsch van Beijnum wrote:
On 8-nov-04, at 23:15, Leo Bicknell wrote:
Well, if they can manage to interconnect all those networks a tiny amount of coordination isn't too much to ask for. Also, with the proper hashing this shouldn't be much of a problem even without coordination. Yes, no coordination and bad hashing won't work, but guess what: don't do that.
It is too much to ask for, because you assume it's one company day one. What happens when AOL and Time Warner merge? There was no chance of coordination before that. Or how about Cisco? They buy what, 100-200 companies a year?
If both companies use either registered globally unique space (which also has the important property you get to know who the packets come from when they show up in the wrong places) or use the unregistered variant with proper hashing, the chance of collisions is negligible.
1) if they are smart 2) if they use the 'right' hash 3) if they expect to interconnect 4) if the network isn't a 'short term fix'. There are all sorts of 'new requirements' that are forcing companies to link to other places over IP that they would never have considered even a year or so ago. Most larger corporations have been running some form if 'internal network' for 10+years, I'd bet they didn't renumber on a regular basis as they moved from provider to provider or linked in new 'partners'... Thus they are already hitting the collision problems. I can see valid reasons to have /rfc-1918/ for ipv6, but that crutch for internal networks (security through obscurity) will always cause collisions in the end. I also don't see a way to avoid the problems here...
There are 33,000 allocated ASN's today. Give each one a PI prefix (however they might get it). That's 33,000 routes. Given my routers are fine with 140,000 now, and are being tested in labs to well over 1 million and I fail to see the issue.
Well, I can't _guarantee_ routers are going to explode when people start doing PI in IPv6, but I think they will, eventually. The big difference with IPv4 is that in IPv4, there is still a significant hurdle to multihoming, as you need at least a /24. In IPv4 _everyone_ gets to have a /48. And once so many important services sit in /48s that you can't filter them individually anymore, you need to allow all /48s in your routing tables and then you're at the mercy of how popular multihoming is going to be. It could easily end well (multihoming isn't that popular today) but the risk of it going very badly is just too big
Multihoming is quite popular actually, and getting more so each quarter. People don't want their business unnecessarily tied to a single vendor, especially one in 'financial trouble', or 'who has frequent meltdowns' (define meltdown as you please). For the last 4 years people have been encouraged, for good reasons I think, to multihome. Telling them next year that they can no longer easily multihome is going to cause significant issues... atleast for the deployment of v6 for true production uses.
Leo Bicknell wrote:
I would like to bring to the attention of Nanog an IPv6 policy issue that I think is slipping under the radar right now.
The IETF IPv6 working group is considering two proposals right now for IPv6 "private networks". Think RFC-1918 type space, but redefined for the IPv6 world. Those two drafts can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt
These drafts came up in the ARIN meeting, and I posted my analysis of the problems with both at:
I dont understand much about ipv6. Yes I am now internationaly recognized for the ipv6 noob and loser that I am. What I do know is that ostensibly we need it due to address shortage. Its also easy to see that a entire trainload of new technology has been hitched up to that wagon. No surprise that people are not pulling eachother down in their haste to jump on it To all of us happily using ip4 does ipv6 offer anything valuable other than more space? Do net admins who dread troubleshooting real networks with unrecognizable and unmemorizable addresses exist? Maintaining configuration where you will never spot a fat fingered address ever? And I mean even those who dont run "Real Networks (TM)" All those people who curse vendors who make them put in 128 bit key software unlock codes, raise your hands. (I actualy memorized one or two of them after four years) Is anybody keeping track of what percentage of ipv6 has already been spoken for in some way and what percentage of the categories spoken for are utilized in any way? Yes I know. 128 bits address space is infinite! You couldnt run out if you tried! (~100 more /7 proposals like the one mentioned in parent and ipv6 is in trouble)
On Mon, Nov 08, 2004 at 05:56:58PM -0500, Joe Maimon wrote:
To all of us happily using ip4 does ipv6 offer anything valuable other than more space?
Depends on who you are.
Do net admins who dread troubleshooting real networks with unrecognizable and unmemorizable addresses exist?
Actually, I find IPv6 addresses much more memorizable as you can give your addressing plan hierarchical structure and don't get about arbitrary numbers like in v4 CIDR where you don't even see where a subnet starts and ends. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
[snip]
I dont understand much about ipv6. Yes I am now internationaly recognized for the ipv6 noob and loser that I am.
What I do know is that ostensibly we need it due to address shortage. Its also easy to see that a entire trainload of new technology has been hitched up to that wagon. No surprise that people are not pulling eachother down in their haste to jump on it
I am not too sure about addr shortage and thus can't comment myself. But what we do know is that IPv6 provides a large amount of *subnets* and each subnet (minimum recommendation being /64) already contains lot more addrs than entire IPv4 space. So it could mean some new possibilities down the road (e.g. certain companies using ipv6 for product management, etc) as the technology changes.
To all of us happily using ip4 does ipv6 offer anything valuable other than more space?
Yes.. stateless autoconf by icmp and few others but I don't really care about those personally myself.
Do net admins who dread troubleshooting real networks with unrecognizable and unmemorizable addresses exist? Maintaining configuration where you will never spot a fat fingered address ever? And I mean even those who dont run "Real Networks (TM)"
Unmemorizable? I don't know about that one. I can memorize IPv6 addrs much faster and better than IPv4 addrs. I know it may sound like a paradox, but IPv6 addrs, once you get used to them, are neatly organized into TLA->NLA and all the way to Site level.
All those people who curse vendors who make them put in 128 bit key software unlock codes, raise your hands. (I actualy memorized one or two of them after four years)
Is anybody keeping track of what percentage of ipv6 has already been spoken for in some way and what percentage of the categories spoken for are utilized in any way?
Yes I know. 128 bits address space is infinite! You couldnt run out if you tried! (~100 more /7 proposals like the one mentioned in parent and ipv6 is in trouble)
Bad assumptions. -J -- James Jun TowardEX Technologies, Inc. Technical Lead IPv4 and Native IPv6 Colocation, Bandwidth, james@towardex.com and Web Hosting Services in the Metro Boston area cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
At 02:25 PM 08-11-04 -0500, Leo Bicknell wrote:
More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet.
I think you need to look at one of the authors - Nokia. Perhaps 2001:490::/32 and 3FFE:8130::/28 are not enough for what they have in mind. Perhaps someone from RIPE should sit down with Nokia (and perhaps all the other cell makers) and find out what they truly want and why these IETF drafts solve their problem. Perhaps just giving them what they want (and think they will need) will make this all go away? -Hank
Since this is a list of providers, I encourage you to read the drafts, and submit your comments to the working group. The information for the working group is at http://www.ietf.org/html.charters/ipv6-charter.html, and includes their mailing list archives and information on how to subscribe and/or post.
Even if you disagree with me, much like voting the important thing is that you voice your opinion.
--=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
*** END PGP VERIFIED MESSAGE ***
On Tue, 2004-11-09 at 10:09 +0200, Hank Nussbacher wrote:
At 02:25 PM 08-11-04 -0500, Leo Bicknell wrote:
More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet.
I think you need to look at one of the authors - Nokia. Perhaps 2001:490::/32 and 3FFE:8130::/28 are not enough for what they have in mind.
Their 6bone space will go away per 6/6/6. That /32 should provide for 65535 /48's, sites that is, which should be enough for most sites. If it isn't then just request a larger allocation: http://www.sixxs.net/tools/grh/tla/ * 1x /20 * 1x /21 * 1x /23 * 59x /24 * 1x /27 * 57x /28 * 2x /30 * 1x /31 * 719x /32 * 12x /35 The /24 + /28's are 6bone space thus theses will go away in ~1,5 years. The /35's should be upgraded to /32's, apparently IPv6 is not interesting enough for these operators though.
Perhaps someone from RIPE should sit down with Nokia (and perhaps all the other cell makers) and find out what they truly want and why these IETF drafts solve their problem. Perhaps just giving them what they want (and think they will need) will make this all go away?
Nokia makes Cellphones, but doesn't provide connectivity (afaik). Telia, the /20 above, does provide connectivity and they got, for them, enough space. If someone needs the space then just describe your problem to one of the RIR's and ask for the allocation. It can be done. Greets, Jeroen
At 09:43 AM 09-11-04 +0100, Jeroen Massar wrote:
Perhaps someone from RIPE should sit down with Nokia (and perhaps=20 all the other cell makers) and find out what they truly want and why thes= e=20 IETF drafts solve their problem. Perhaps just giving them what they want= =20 (and think they will need) will make this all go away?
Nokia makes Cellphones, but doesn't provide connectivity (afaik). Telia, the /20 above, does provide connectivity and they got, for them, enough space. If someone needs the space then just describe your problem to one of the RIR's and ask for the allocation. It can be done.
Perhaps Nokia wants to make cellphones with a fixed IPv6 number - as it leaves the factory? -Hank
Greets, Jeroen
On Tue, 2004-11-09 at 11:51 +0200, Hank Nussbacher wrote:
At 09:43 AM 09-11-04 +0100, Jeroen Massar wrote:
Perhaps someone from RIPE should sit down with Nokia (and perhaps=20 all the other cell makers) and find out what they truly want and why thes= e=20 IETF drafts solve their problem. Perhaps just giving them what they want= =20 (and think they will need) will make this all go away?
Nokia makes Cellphones, but doesn't provide connectivity (afaik). Telia, the /20 above, does provide connectivity and they got, for them, enough space. If someone needs the space then just describe your problem to one of the RIR's and ask for the allocation. It can be done.
Perhaps Nokia wants to make cellphones with a fixed IPv6 number - as it leaves the factory? -Hank
I have not seen any plans/deployment of Nokia having a globally covering cellphone network. Also I don't think that any telco would like that a cellphone maker suddenly is taking over their business, could be but nah I don't think so. If you really want to know why they need the prefix, why don't you just ask them. David Kessens is probably the person who you want to talk to, with him doing doing a lot of 6bone work and of course the RIPE IPv6 wg and a lot of IETF stuff... Greets, Jereon
On Tue, Nov 09, 2004 at 01:34:11PM +0100, Niels Bakker wrote:
* hank@mail.iucc.ac.il (Hank Nussbacher) [Tue 09 Nov 2004, 10:53 CET]:
Perhaps Nokia wants to make cellphones with a fixed IPv6 number - as it leaves the factory? -Hank
They could implement such an insane plan with a /64 until long after 32-bit time_t rolls over.
-- Niels.
hummm. looks like a classic blunder to me... so i ask the question (no its not retorical and i do know the correct answer :) what would such an address be used for? a fixed IP address assigned at the factory has all the attributes of an ethernet MAC address. :) e.g. it "names" the interface at layer2. i believe that an ip -ADDRESS- is an indication of -WHERE- in the topology a node currently sits, btu the address is not the name. so are IPv6 numbers "addresses" or "names"? or some bastard combination foisted on the poor operations community who is left with trying to figure it out? :) --bill
* bmanning@vacation.karoshi.com (bmanning@vacation.karoshi.com) [Tue 09 Nov 2004, 13:54 CET]:
what would such an address be used for? a fixed IP address assigned at the factory has all the attributes of an ethernet MAC address. :) e.g. it "names" the interface at layer2.
It numbers it. But it's less useful than a traditional MAC address as it's not as generally usable after connecting the device to a compatible network.
i believe that an ip -ADDRESS- is an indication of -WHERE- in the topology a node currently sits, btu the address is not the name.
so are IPv6 numbers "addresses" or "names"? or some bastard combination foisted on the poor operations community who is left with trying to figure it out? :)
They're identifiers on the network layer. Names are what hu-mans give services, devices etc. They consist of two parts, a network part and a host part. The network part identifies the topology, the host part identifies the exact place in that topology. It seems we went back to pre-CIDR days with IPv6 and made everything a /64 (at least in 2001::/16). That makes it at least easier to tell the parts apart. -- Niels.
In a message written on Tue, Nov 09, 2004 at 11:51:10AM +0200, Hank Nussbacher wrote:
Perhaps Nokia wants to make cellphones with a fixed IPv6 number - as it leaves the factory? -Hank
It was relayed to me that at least one group was asking about using IPv6 addresses to replace UPC codes, since they are running out of UPC codes. I believe they were told that would be inappropriate. However, if you can get addresses for free, and they are guaranteed to be globally unique, and not to appear on the public internet I'm not sure what the barrier to such an application would be.... -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Tue, 9 Nov 2004, Leo Bicknell wrote:
In a message written on Tue, Nov 09, 2004 at 11:51:10AM +0200, Hank Nussbacher wrote:
Perhaps Nokia wants to make cellphones with a fixed IPv6 number - as it leaves the factory? -Hank
It was relayed to me that at least one group was asking about using IPv6 addresses to replace UPC codes, since they are running out of UPC codes. I believe they were told that would be inappropriate.
And I bet someone will then think of a good reason why each product would then need a /64. :-) -Hank
However, if you can get addresses for free, and they are guaranteed to be globally unique, and not to appear on the public internet I'm not sure what the barrier to such an application would be....
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Tue, 9 Nov 2004, Leo Bicknell wrote:
In a message written on Tue, Nov 09, 2004 at 11:51:10AM +0200, Hank Nussbacher wrote:
Perhaps Nokia wants to make cellphones with a fixed IPv6 number - as it leaves the factory? -Hank
However, if you can get addresses for free, and they are guaranteed to be globally unique, and not to appear on the public internet I'm not sure what the barrier to such an application would be....
hmm, couple that with RFID and you could really make some $$...
* hank@mail.iucc.ac.il (Hank Nussbacher) [Tue 09 Nov 2004, 09:18 CET]:
I think you need to look at one of the authors - Nokia. Perhaps 2001:490::/32 and 3FFE:8130::/28 are not enough for what they have in mind. Perhaps someone from RIPE should sit down with Nokia (and perhaps all the other cell makers) and find out what they truly want and why these IETF drafts solve their problem. Perhaps just giving them what they want (and think they will need) will make this all go away?
I remember a RIPE meeting a few years ago where a BT Cellnet representative seriously asked to become an RIR with an initial /8 allocation for use among mobile operators. If I recall correctly, he was quietly laughed out of the room - and rightly so (as existing RIRs are more than capable of handling any address request they might have). I'm pretty sure Nokia, not being a network operator, has little use for large amounts of address space. For a mobile operator, I assume a standard allocation should be enough; and if not I'm sure the RIR community is reasonable enough to listen to the mobile operator's arguments. -- Niels.
participants (49)
-
Adi Linden -
Adrian Chadd -
Alex Bligh -
alex＠yuriev.com -
Alexei Roudnev -
bmanning＠vacation.karoshi.com -
Christopher L. Morrow -
Crist Clark -
Daniel Roesen -
Daniel Senie -
David Schwartz -
Eric Gauthier -
Hank Nussbacher -
Henning Brauer -
Iljitsch van Beijnum -
J.A. Terranson -
James -
Jeff Rosowski -
Jeroen Massar -
Jerry Eyers -
Joe Abley -
Joe Maimon -
John Curran -
Kevin Oberman -
Kurt Erik Lindqvist -
Leo Bicknell -
leo vegoda -
Michael.Dillon＠radianz.com -
Måns Nilsson -
Niels Bakker -
Nils Ketelsen -
Owen DeLong -
Paul Gilbert -
Paul Vixie -
Pekka Savola -
Petri Helenius -
Randy Bush -
Richard Jimmerson -
Ryan O'Connell -
Sascha Lenz -
Simon Leinen -
Simon Lockhart -
Simon Lyall -
Stephen Sprunk -
Steven M. Bellovin -
Ted Hardie -
Tony Hain -
Valdis.Kletnieks＠vt.edu -
vijay gill