Fwd: The IESG Approved the Expansion of the AS Number Registry
Seems relevant. Begin forwarded message:
From: IESG Secretary <iesg-secretary@ietf.org> Date: November 29, 2006 10:32:38 AM EST To: IETF Announcement list <ietf-announce@ietf.org> Subject: The IESG Approved the Expansion of the AS Number Registry
-------- Original Message -------- Subject: The IESG Approved the Expansion of the AS Number Registry Date: Mon, 27 Nov 2006 09:56:13 -0500 From: IESG Secretary To: IANA CC: IESG
Dear IANA,
The IESG has approved the expansion of the size of the AS Number registry described in draft-ietf-idr-as4bytes-12.txt before the approval of the document. Please expand the AS Number space to include the values 65536 through 4294967295, initially marked as "Held by IANA".
Allocations can be made to the RIRs prior to the publication of this RFC.
Thank You, The IESG
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Afraid so. I'm hoping to be out of the industry before calls for 128 bit AS#s come down the pipe and people (at that time) are laughing about how silly 32 bit AS#s seem. Does anyone have a current projection of when AS# (16 bit) exhaust will occur? Thanks, Deepak Marshall Eubanks wrote:
Seems relevant.
Begin forwarded message:
From: IESG Secretary <iesg-secretary@ietf.org> Date: November 29, 2006 10:32:38 AM EST To: IETF Announcement list <ietf-announce@ietf.org> Subject: The IESG Approved the Expansion of the AS Number Registry
-------- Original Message -------- Subject: The IESG Approved the Expansion of the AS Number Registry Date: Mon, 27 Nov 2006 09:56:13 -0500 From: IESG Secretary To: IANA CC: IESG
Dear IANA,
The IESG has approved the expansion of the size of the AS Number registry described in draft-ietf-idr-as4bytes-12.txt before the approval of the document. Please expand the AS Number space to include the values 65536 through 4294967295, initially marked as "Held by IANA".
Allocations can be made to the RIRs prior to the publication of this RFC.
Thank You, The IESG
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
On Wed, 29 Nov 2006, Deepak Jain wrote:
Afraid so. I'm hoping to be out of the industry before calls for 128 bit AS#s come down the pipe and people (at that time) are laughing about how silly 32 bit AS#s seem.
Does anyone have a current projection of when AS# (16 bit) exhaust will occur?
anyone have a swag at the number of things that this (32bit asn) touches? netflow bgp (duh!) provisioning databases/systems web-pages (really the backend parts like routeviews query/search tools) yeesh :(
On 30 Nov 2006, at 07:02, Chris L. Morrow wrote:
On Wed, 29 Nov 2006, Deepak Jain wrote:
Afraid so. I'm hoping to be out of the industry before calls for 128 bit AS#s come down the pipe and people (at that time) are laughing about how silly 32 bit AS#s seem. anyone have a swag at the number of things that this (32bit asn) touches?
Yes, and it means plenty of work for us all - hurray. But we need to take action to preserve the availability of new AS numbers for new network builders. RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago. It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks. There were no definitive answers when John Payne asked on the list about images supporting 32 bit as numbers - are any independent bodies going to setup a route behind a 32-bit ASN so that we can start public reachability testing ? Andy
Andy Davidson wrote:
RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago.
Actually, all 5 RIRs will accept requests for 32 bit ASNs from 1/1/2007.
It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks.
I couldn't agree more. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment."
On Fri, 1 Dec 2006, Andy Davidson wrote:
RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago. It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks.
So, all of the current devices need to get upgraded before 'day one' of 32-bit ASN use... that'll be fun :) Why is RIPE passing out the 32-bit ASN's now? aren't there still plenty (+20k or so) 16-bit ASN's out there for assignment? (perhaps I'm missing something on the need to allocate the new asn's?)
There were no definitive answers when John Payne asked on the list about images supporting 32 bit as numbers - are any independent bodies going to setup a route behind a 32-bit ASN so that we can start public reachability testing ?
Given a 32-bit ASN I'd be happy to upgrade code on a connected device and announce a route... of course I'm not sure my upstream will do the right thing with the announcement since it doesn't know (probably) about 32-bit asn's...
On Fri, 01 Dec 2006 16:02:55 +0000 (GMT) "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> wrote:
On Fri, 1 Dec 2006, Andy Davidson wrote:
RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago. It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks.
So, all of the current devices need to get upgraded before 'day one' of 32-bit ASN use... that'll be fun :) Why is RIPE passing out the 32-bit ASN's now? aren't there still plenty (+20k or so) 16-bit ASN's out there for assignment? (perhaps I'm missing something on the need to allocate the new asn's?)
Testing -- better to find out now what breaks, before we really need it. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Fri, 1 Dec 2006, Steven M. Bellovin wrote:
On Fri, 01 Dec 2006 16:02:55 +0000 (GMT) "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> wrote:
So, all of the current devices need to get upgraded before 'day one' of 32-bit ASN use... that'll be fun :) Why is RIPE passing out the 32-bit ASN's now? aren't there still plenty (+20k or so) 16-bit ASN's out there for assignment? (perhaps I'm missing something on the need to allocate the new asn's?)
Testing -- better to find out now what breaks, before we really need it.
understood, but I took the 'RIPE has been assigning 32-bit ASN's since....' to mean that people actually expected them to work.
So, all of the current devices need to get upgraded before 'day one' of 32-bit ASN use... that'll be fun :) Why is RIPE passing out the 32-bit ASN's now? ARIN will begin passing out 32 bit ASN's to anyone who asks as of January 1, 2007. This is the same policy as RIPE so I don't see what the big deal is.
aren't there still plenty (+20k or so) 16-bit ASN's out there for assignment? (perhaps I'm missing something on the need to allocate the new asn's?) By all means let's wait until the last possible second to upgrade ASN support. The waiting approach has worked so well for IPV6 :) Seriously though- why not let people start registering now. The only way we'll know if 32 bit ASN's will work is if we start using them.
-Don
On Fri, 1 Dec 2006, Donald Stahl wrote:
So, all of the current devices need to get upgraded before 'day one' of 32-bit ASN use... that'll be fun :) Why is RIPE passing out the 32-bit ASN's now? ARIN will begin passing out 32 bit ASN's to anyone who asks as of January 1, 2007. This is the same policy as RIPE so I don't see what the big deal is.
Uhm, I think I mis-read the date on the original :( I thought they HAD been passing them out, not WILL BE :( need more coffee :(
aren't there still plenty (+20k or so) 16-bit ASN's out there for assignment? (perhaps I'm missing something on the need to allocate the new asn's?) By all means let's wait until the last possible second to upgrade ASN support. The waiting approach has worked so well for IPV6 :) Seriously though- why not let people start registering now. The only way we'll know if 32 bit ASN's will work is if we start using them.
agreed, let's NOT do the v6 thing... do the 32-bit asn's give us more than just 'more bits' ? :) (Sorry, I couldn't resist). So, yes, let's get someone to start testing, I'd just caution on assigning the 32-bit asn's for real-users, since much of the net might not be able to use them, partial reachability will/could-be a problem.
aren't there still plenty (+20k or so) 16-bit ASN's out there for assignment? (perhaps I'm missing something on the need to allocate the new asn's?) By all means let's wait until the last possible second to upgrade ASN support. The waiting approach has worked so well for IPV6 :) Seriously though- why not let people start registering now. The only way we'll know if 32 bit ASN's will work is if we start using them.
agreed, let's NOT do the v6 thing... do the 32-bit asn's give us more than just 'more bits' ? :) (Sorry, I couldn't resist). So, yes, let's get someone to start testing, I'd just caution on assigning the 32-bit asn's for real-users, since much of the net might not be able to use them, partial reachability will/could-be a problem.
Wouldn't this just mean (Since Jan 1 2007 hasn't come to pass yet) setting up a Quagga router and plugging it into your existing network? Seems to me that without real support for the existing operating systems... um, the old neighbor xxx.xxx.xxx.xxx remote-as [32bit ASN notation] would pretty much end the experiment. I can easily imagine setting up some test beds with multi-hop so people can test their implementation with real "talkers" -- lol, which is a lot like the way IPV6 is/was set up. If anyone wants to play with this, we'll do our part and set up an AS in the development space of 32bit-AS land and peer with anyone who wants to bang on it... DJ
agreed, let's NOT do the v6 thing... do the 32-bit asn's give us more than just 'more bits' ? :) (Sorry, I couldn't resist). So, yes, let's get someone to start testing, I'd just caution on assigning the 32-bit asn's for real-users, since much of the net might not be able to use them, partial reachability will/could-be a problem. The good news is that 32 bit ASN's won't be assigned by default until
2009. Starting on January 1, 32 bit ASN's will be assigned- but only to those people explicitly requesting them. All in all it seems like a sensible migration strategy. -Don
* Chris L. Morrow:
So, all of the current devices need to get upgraded before 'day one' of 32-bit ASN use... that'll be fun :)
| 6. Transition | | The scheme described in this document allows a gradual transition | from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one | Autonomous System or one BGP speaker at a time. Routers on stub ASs don't need upgrading at all, for instance.
On Fri, 1 Dec 2006, Florian Weimer wrote:
* Chris L. Morrow:
So, all of the current devices need to get upgraded before 'day one' of 32-bit ASN use... that'll be fun :)
| 6. Transition | | The scheme described in this document allows a gradual transition | from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one | Autonomous System or one BGP speaker at a time.
Routers on stub ASs don't need upgrading at all, for instance.
but filter lists and such I imagine might :(
* Chris L. Morrow:
| 6. Transition | | The scheme described in this document allows a gradual transition | from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one | Autonomous System or one BGP speaker at a time.
Routers on stub ASs don't need upgrading at all, for instance.
but filter lists and such I imagine might :(
Only if you want to keep your fine-grained filters, which shouldn't be a problem over the next few years. From a purely BGP 4 perspective, the transition looks like a new tier 1 ISP entering the stage. (But if more than one of your peers switch, you better upgrade as well.)
On Fri, 01 Dec 2006 17:04:38 GMT, "Chris L. Morrow" said:
On Fri, 1 Dec 2006, Florian Weimer wrote:
Routers on stub ASs don't need upgrading at all, for instance.
but filter lists and such I imagine might :(
But the industry *did* learn its lesson with 69/8, didn't it? </snark>
On Dec 1, 2006, at 4:50 AM, Andy Davidson wrote:
RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago. It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks.
Is there any possibility we can now get a block of ASNs set aside for documentation purposes, akin to example.com and/or the TEST network? A block of ASNs for this purpose would be very helpful for folks writing docs, would reduce the possibility of 'cut-and-paste hijacking', and would also allow more accurate documentation (many products and tools have special handling for the designated private ASNs which make documentation difficult). ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice All battles are perpetual. -- Milton Friedman
Roland Dobbins wrote:
On Dec 1, 2006, at 4:50 AM, Andy Davidson wrote:
RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago.
Is there any possibility we can now get a block of ASNs set aside for documentation purposes, akin to example.com and/or the TEST network? A block of ASNs for this purpose would be very helpful for folks writing docs, would reduce the possibility of 'cut-and-paste hijacking', and would also allow more accurate documentation (many products and tools have special handling for the designated private ASNs which make documentation difficult).
This is an excellent idea, but please do not select the first block after 16 bit numbers are up (can you say buffer overflow?). Something random, in the middle, would be better. -- The weaker the data available upon which to base one's conclusion, the greater the precision which should be quoted in order to give the data authenticity. Norman Augustine
Etaoin Shrdlu wrote:
This is an excellent idea, but please do not select the first block after 16 bit numbers are up (can you say buffer overflow?). Something random, in the middle, would be better.
2752512-2818047 ? Pete
On Fri, Dec 01, 2006 at 09:49:25PM +0200, Petri Helenius wrote:
Etaoin Shrdlu wrote:
This is an excellent idea, but please do not select the first block after 16 bit numbers are up (can you say buffer overflow?). Something random, in the middle, would be better.
2752512-2818047 ?
0x2A0000 - 0x2AFFFF, IOW ? [Just for those who were curious why those numbers but not curious enough to actually check.] -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On 11/29/06, Deepak Jain <deepak@ai.net> wrote:
Afraid so. I'm hoping to be out of the industry before calls for 128 bit AS#s come down the pipe and people (at that time) are laughing about how silly 32 bit AS#s seem.
I hope to be long dead before we exhaust >4 billion ASNs. If I'm still alive then, someone probably transferred my brain into a positronic neural network, and Earth is long since uninhabitable by organic life. But I wouldn't doubt if some threads like this are still running on HSNOG (Hyperspace Network Off-topic Gripes). Hm. I think I need to get some lunch before the office cafeteria closes. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
At 01:06 PM 30/11/2006, Deepak Jain wrote:
Does anyone have a current projection of when AS# (16 bit) exhaust will occur?
14 October 2010 http://www.potaroo.net/tools/asns/ regards, Geoff
14 October 2010
Thanks very much for this link (and the summary). I see an interesting (if not surprising) trend in Advertised AS Count. Up until 2001 it was accelerating... and after 2001 its stayed linear. However, unadvertised AS count which was basically stagnant has increased markedly before then. If this is an observation others have already made... um, consider me out of the loop. :) Deepak
Thanks very much for this link (and the summary). I see an interesting (if not surprising) trend in Advertised AS Count. Up until 2001 it was accelerating... and after 2001 its stayed linear. However, unadvertised AS count which was basically stagnant has increased markedly before
then. Those are not unadvertised ASNs. Those are only ASNs which have been issued but are undetectable by his monitoring tools. That doesn't mean that they are not advertised, just that his tool cannot detect them. Given the fact that the Internet is now thoroughly global with rich interconnectivity in most regions of the globe, it is hardly surprising that lots of ASNs do not get advertised globally. The trend you see is likely cause by rich local interconnectivity becoming the norm rather than a few circuits from the capital city to some big U.S. city. --Michael Dillon
On Nov 29, 2006, at 2:36 PM, Marshall Eubanks wrote:
Seems relevant.
Any word from vendors on supporting images? I found some old presentations that said Juniper (ERX) and Redback had announced supporting images and Cisco had an unannounced version, but thats all.
Begin forwarded message:
From: IESG Secretary <iesg-secretary@ietf.org> Date: November 29, 2006 10:32:38 AM EST To: IETF Announcement list <ietf-announce@ietf.org> Subject: The IESG Approved the Expansion of the AS Number Registry
-------- Original Message -------- Subject: The IESG Approved the Expansion of the AS Number Registry Date: Mon, 27 Nov 2006 09:56:13 -0500 From: IESG Secretary To: IANA CC: IESG
Dear IANA,
The IESG has approved the expansion of the size of the AS Number registry described in draft-ietf-idr-as4bytes-12.txt before the approval of the document. Please expand the AS Number space to include the values 65536 through 4294967295, initially marked as "Held by IANA".
Allocations can be made to the RIRs prior to the publication of this RFC.
Thank You, The IESG
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
On 30-Nov-2006, at 12:59, John Payne wrote:
On Nov 29, 2006, at 2:36 PM, Marshall Eubanks wrote:
Seems relevant.
Any word from vendors on supporting images? I found some old presentations that said Juniper (ERX) and Redback had announced supporting images and Cisco had an unannounced version, but thats all.
http://www.potaroo.net/drafts/draft-huston-idr-as4bytes-survey-00.txt has some relevant info, although that draft is a year or so old now. Joe
Joe Abley wrote:
On 30-Nov-2006, at 12:59, John Payne wrote:
On Nov 29, 2006, at 2:36 PM, Marshall Eubanks wrote:
Seems relevant.
Any word from vendors on supporting images? I found some old presentations that said Juniper (ERX) and Redback had announced supporting images and Cisco had an unannounced version, but thats all.
http://www.potaroo.net/drafts/draft-huston-idr-as4bytes-survey-00.txt has some relevant info, although that draft is a year or so old now.
Last time I spoke to them, the Juniper and Cisco versions only ran on a subset of their routers. Their claim was that almost nobody had asked for this so it doesn't have any priority. For those using software routers: there is an unannounced patch for Quagga that supports this. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment."
On Fri, 1 Dec 2006, Henk Uijterwaal wrote:
Last time I spoke to them, the Juniper and Cisco versions only ran on a subset of their routers. Their claim was that almost nobody had asked for this so it doesn't have any priority.
'the power of the market place!' ... perhaps now is the time to call your local (Juniper|Cisco|Other) router vendor sales rep and ask? :)
On Dec 1, 2006, at 10:54 AM, Chris L. Morrow wrote:
On Fri, 1 Dec 2006, Henk Uijterwaal wrote:
Last time I spoke to them, the Juniper and Cisco versions only ran on a subset of their routers. Their claim was that almost nobody had asked for this so it doesn't have any priority.
'the power of the market place!' ... perhaps now is the time to call your local (Juniper|Cisco|Other) router vendor sales rep and ask? :)
I've hit up my big 3 vendors... no response yet, but it is holiday season
participants (18)
-
Andy Davidson -
Chris L. Morrow -
Deepak Jain -
Donald Stahl -
Etaoin Shrdlu -
Florian Weimer -
Geoff Huston -
Henk Uijterwaal -
Joe Abley -
John Payne -
Joseph S D Yao -
Marshall Eubanks -
Michael.Dillon＠btradianz.com -
Petri Helenius -
Roland Dobbins -
Steven M. Bellovin -
Todd Vierling -
Valdis.Kletnieks＠vt.edu