RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes.
Only if EVERY ASN were allocated and active. You and I both know this doesn't begin to approach reality. Slightly more than half of current ASNs are actually in the routing table. The ASN issuance rate is not
These are the same arguments that are presented each time something new comes along to replace something old. When IPv4 first came along nobody thought all of the 4 billion plus address could ever be used; but we were wrong. 16-bit ASNs have served their place and will continue to serve for the time being. Those who fail to plan, plan to fail. It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses. As you had mentioned though, in the near term this definitely would not be scalable, but who knows what is going to happen 10, 15, or more years from now. I think your numbers may be a little off 2^32 = 4,294,967,296; current world population give or take a few million is hovering around 6,300,000,000 according to the US Gov. If everyone and the mother would like an ASN (Which is highly unlikely) you would need just a few more to make that work. Chris -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Pekka Savola Sent: Monday, November 29, 2004 11:41 AM To: Owen DeLong Cc: Jeroen Massar; Cliff Albert; nanog@merit.edu Subject: Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI] On Mon, 29 Nov 2004, Owen DeLong wrote: likely
to go up simply because we go to 32 bit ASNs. Probably we are really talking about a need for 20 bit ASNs or so, generally, but, 32 bits is a much more convenient boundary for lots of code implementations and lots of hardware, so, 32 bits is the chosen number for the sake of simplicity.
Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be "no need" (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table. Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god. It's better to try to stick to 16 bit ASNs for now, and make stricter policies and reclaim the space if needed. -- 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 Mon, 29 Nov 2004, Chris Burton wrote:
It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses.
I find this hard to believe. When there is 64K times as much the resource, there is no way the policies would get stricter, because it can easily and logically be argued that they don't need to be stricter.
As you had mentioned though, in the near term this definitely would not be scalable, but who knows what is going to happen 10, 15, or more years from now.
So, let's delay the move until we know how to make it more scalable.
I think your numbers may be a little off 2^32 = 4,294,967,296; current world population give or take a few million is hovering around 6,300,000,000 according to the US Gov. If everyone and the mother would like an ASN (Which is highly unlikely) you would need just a few more to make that work.
Yeah, I know the calculations :). Everyone can already get an IPv4 address too, right? All we need is an AS number NAT.. oops, it's there already. Face it, with 32 bit ASNs, pretty much anyone could have an ASN if they wanted to unless the policies were very strict, and it would be very difficult to justify why it would have to be strict because there is so vast resource to be used. -- 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 Tuesday, November 30, 2004 7:44 AM +0200 Pekka Savola <pekkas@netcore.fi> wrote:
On Mon, 29 Nov 2004, Chris Burton wrote:
It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses.
I find this hard to believe. When there is 64K times as much the resource, there is no way the policies would get stricter, because it can easily and logically be argued that they don't need to be stricter.
Reality denies your statement. Currently, one could at least argue, that IPv6 policies are significantly stricter than IPv4 policies. The ratio between IPv6 addresses and IPv4 addresses is much much more than 64K times as much. As such, your argument falls very flat very early just based on current experience.
As you had mentioned though, in the near term this definitely would not be scalable, but who knows what is going to happen 10, 15, or more years from now.
So, let's delay the move until we know how to make it more scalable.
Let's not. The reality is that going to 32bit ASNs isn't because we want to assign 4 billion ASNs tomorrow. It's because we realize that in a few years, there will be a need for more than 64K ASNs and 32 bits is the next easy-to-code boundary. Given that in general practice, somewhere around 0.6 of assigned ASNs are actually visible in the global routing table, I don't think the sky will fall simply because 32 bit ASNs are available. The same controls will still be in place at the RIRs unless some deliberate action is made with consensus of the RIR constituency to change them.
I think your numbers may be a little off 2^32 = 4,294,967,296; current world population give or take a few million is hovering around 6,300,000,000 according to the US Gov. If everyone and the mother would like an ASN (Which is highly unlikely) you would need just a few more to make that work.
Yeah, I know the calculations :). Everyone can already get an IPv4 address too, right? All we need is an AS number NAT.. oops, it's there already.
Face it, with 32 bit ASNs, pretty much anyone could have an ASN if they wanted to unless the policies were very strict, and it would be very difficult to justify why it would have to be strict because there is so vast resource to be used.
It needs to be strict because, as you have pointed out, the assignment of an ASN has potential consequences beyond simply ASN exhaustion. The current ASN policies are not there primarily to keep from running out of ASNs. The general attitude towards this from the RIRs has been "32 bit ASNs are coming soon anyway, so, ASN exhaustion is not the issue". Owen -- If it wasn't crypto-signed, it probably didn't come from me.
On Tue, 30 Nov 2004, Owen DeLong wrote:
--On Tuesday, November 30, 2004 7:44 AM +0200 Pekka Savola <pekkas@netcore.fi> wrote:
On Mon, 29 Nov 2004, Chris Burton wrote:
It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses.
I find this hard to believe. When there is 64K times as much the resource, there is no way the policies would get stricter, because it can easily and logically be argued that they don't need to be stricter.
Reality denies your statement. Currently, one could at least argue, that IPv6 policies are significantly stricter than IPv4 policies. The ratio between IPv6 addresses and IPv4 addresses is much much more than 64K times as much. As such, your argument falls very flat very early just based on current experience.
And they have been under constant attack since the beginning. Lots of folks (like you :) have been suggesting creating all kinds of PI space, to use more of the bits because they are available. The pressure is building up. Do you think the situation would be any different with 32-bit space? We could certainly _try_ to be strict (provided that there's sufficient consensus in the community that this is the way to go), but similar to the v6 allocation policies, sooner or later it would likely budge in some direction.
Face it, with 32 bit ASNs, pretty much anyone could have an ASN if they wanted to unless the policies were very strict, and it would be very difficult to justify why it would have to be strict because there is so vast resource to be used.
It needs to be strict because, as you have pointed out, the assignment of an ASN has potential consequences beyond simply ASN exhaustion. The current ASN policies are not there primarily to keep from running out of ASNs. The general attitude towards this from the RIRs has been "32 bit ASNs are coming soon anyway, so, ASN exhaustion is not the issue".
Agree. I think the RIRs, despite the resolution how to go forward, take heed from this. -- 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 Tuesday, November 30, 2004 19:52 +0200 Pekka Savola <pekkas@netcore.fi> wrote:
On Tue, 30 Nov 2004, Owen DeLong wrote:
--On Tuesday, November 30, 2004 7:44 AM +0200 Pekka Savola <pekkas@netcore.fi> wrote:
On Mon, 29 Nov 2004, Chris Burton wrote:
It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses.
I find this hard to believe. When there is 64K times as much the resource, there is no way the policies would get stricter, because it can easily and logically be argued that they don't need to be stricter.
Reality denies your statement. Currently, one could at least argue, that IPv6 policies are significantly stricter than IPv4 policies. The ratio between IPv6 addresses and IPv4 addresses is much much more than 64K times as much. As such, your argument falls very flat very early just based on current experience.
And they have been under constant attack since the beginning. Lots of folks (like you :) have been suggesting creating all kinds of PI space, to use more of the bits because they are available. The pressure is building up.
The v6 allocation policies and lack of PI space are under attack from people like me (and a lot of people not much like me, btw) because they do not meet the needs of a significant portion of the community. While I have seen a number of people recognize the need for >16 bit ASNs under the current policy, I have not seen a lot of people saying that the ASN policy is too strict and not meeting the needs of the community. There is a world of difference between the situations with ASNs and the situation with IP addresses... 1. EVERYONE needs IP addresses (or at least probably will). 2. MOST people these days know what an IP address is at some level. 3. MOST people would think of some sort of mechanical contraption if you asked them what an AUTONOMOUS SYSTEM was. They would be puzzled by the idea of numbering one. The suppression of v4 availability due to routing table issues and the perceived shortage of addresses received _TEMPORARY_ support from the broader community on faith and belief that IETF was working towards real solutions to these problems in IPNG, and, this was a necessary stop-gap measure to accomodate operations while that was developed. Then, along came NAT and a lot more people started to realize that for most things, they can live with non-routable provider independent space and use NAT to accomplish most of what they need. Since they couldn't get routable PI space for the time being, this was acceptable. Then, ISPs began to realize that non-portable address space was a fantastic tool for preventing customer churn. As such, for many years, ISPs dominated ARIN (and I suspect other RIRs) policy and maintained somewhat of a stranglehold on PI space being available only to the largest and most technically adept customers (the ones that would find a way to move regardless if they weren't getting good service). Finally, end-users started participating more in ARIN and the ARIN policy process, and, we managed just last year to finally get policy adopted that allows for smaller organizations to get PI space in v4 again. Still, there has not been a single proposal aimed at reducing the requirements for ASN assignment. I just don't see moving the bit-boundary on ASNs as creating the kind of land-rush and gloom-and-doom scenario you propose. There is community consensus around keeping the network operational. I think people recognize that 500,000 ASNs is a bad thing today. I don't think 32bit ASNs will mean we hit that for several decades.
Do you think the situation would be any different with 32-bit space? We could certainly _try_ to be strict (provided that there's sufficient consensus in the community that this is the way to go), but similar to the v6 allocation policies, sooner or later it would likely budge in some direction.
Yes, I think that with ASN space (regardless of the boundary), the situation is very different. The number of organizations not served by current IP allocation and assignment policies is huge. The number of organizations that are suffering because of ASN policies, OTOH, is relatively small.
Agree. I think the RIRs, despite the resolution how to go forward, take heed from this.
I think they are well aware of it. I know that ARIN is. Owen
participants (3)
-
Chris Burton -
Owen DeLong -
Pekka Savola