Out of interest, is there a report that details the number of unused older AS's in the Internet and what is being done to recover them to recycle, as we approach the 53k mark and the 32 bit numbering scheme, it strikes me that we probably have a lot of stagnant AS's out there due to takeovers etc.. Any thoughts? Simon
On Mar 17, 2009, at 11:47 AM, Simon Brilus wrote:
Out of interest, is there a report that details the number of unused older AS's in the Internet and what is being done to recover them to recycle, as we approach the 53k mark and the 32 bit numbering scheme, it strikes me that we probably have a lot of stagnant AS's out there due to takeovers etc..
Any thoughts?
Simon
It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt TV
tvest@eyeconomics.com wrote:
On Mar 17, 2009, at 11:47 AM, Simon Brilus wrote:
Out of interest, is there a report that details the number of unused older AS's in the Internet and what is being done to recover them to recycle, as we approach the 53k mark and the 32 bit numbering scheme, it strikes me that we probably have a lot of stagnant AS's out there due to takeovers etc..
Any thoughts?
Simon
It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt
When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do 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 ------------------------------------------------------------------------------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily.
At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote:
It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt
When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this.
Henk
Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to the assigning LIR and after 3 months - just reclaim it. -Hank
Hank Nussbacher wrote:
At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote:
It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt
When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this.
Henk
Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to the assigning LIR and after 3 months - just reclaim it.
-Hank
Your making an assumption that globally unique ASN's must show up in the public internet routing table. The only requirement, at least in the ARIN region, for obtaining a globally unique ASN is a unique routing policy or multihoming - therefor your method could lead to a lot of false positives. I won't even get into issues around bad contact data in whois. However, if enough folks believe this a worthwhile effort, at least in the ARIN region, you will have to ask ARIN to pursue this either through the ARIN policy development process or the ARIN consultation and suggestion process...my guess would be suggestion process. Suggestion submission: https://www.arin.net/app/suggestion/ Policy Proposal process: https://www.arin.net/policy/pdp_appendix_b.html for reference... requirements for obtaining an ASN in the ARIN region: Multi-homed NRPM 5 * provide the exterior gateway protocol to be used * provide the IP addresses currently in use on your network * provide the AS number and name of each of your upstream providers/peers * provide verification (reassigned address block, a copy of your signed contract) your organization has contractually agreed to service with at least two of the upstream providers/peers listed on your request * if requesting an additional AS number, provide documentation detailing how the network for the requested ASN is autonomous from all existing ASes in your network Unique Routing Policy NRPM 5 * demonstrate the AS's routing policy will differ from the routing policies of its border peers * if requesting an additional AS number, provide documentation detailing how the network for the requested ASN is autonomous from all existing ASes in your network --Heather -- ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u@verizonbusiness.com =====================================================
On Wed, 18 Mar 2009, Hank Nussbacher wrote:
At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote:
It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this. Henk Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to the assigning LIR and after 3 months - just reclaim it.
How about just nailing everyone who has invalid contact info? That would certainly be incentive to get it updated. Nothing else seems to work. -Dan
At 12:40 PM 18-03-09 -0700, goemon@anime.net wrote:
On Wed, 18 Mar 2009, Hank Nussbacher wrote:
It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt
When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this. Henk Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to
At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote: the assigning LIR and after 3 months - just reclaim it.
How about just nailing everyone who has invalid contact info? That would certainly be incentive to get it updated. Nothing else seems to work.
-Dan
How about making it financially worth it? RIRs charge for resources - like IPs and ASNs: http://www.ripe.net/ripe/docs/charging2009.html 1 ASN = /21 in money terms. It takes me about 3-5 hours of work to track down and get an old unused ASN to be deallocated. How about updating the 2010 charging model so that LIRs that return ASNs are compensated? -Hank
* Hank Nussbacher:
It takes me about 3-5 hours of work to track down and get an old unused ASN to be deallocated. How about updating the 2010 charging model so that LIRs that return ASNs are compensated?
I don't think this is a good way of using RIR funds. Why should the old guys receive even more special treatment? RIPE's charging scheme already discriminates heavily against newcomers.
On Fri, 20 Mar 2009, Florian Weimer wrote:
* Hank Nussbacher:
It takes me about 3-5 hours of work to track down and get an old unused ASN to be deallocated. How about updating the 2010 charging model so that LIRs that return ASNs are compensated?
I don't think this is a good way of using RIR funds. Why should the old guys receive even more special treatment? RIPE's charging scheme already discriminates heavily against newcomers.
I disagree. Older LIRs have more allocations which compensates for the time factor of the algorithm. Older allocations need almost no human handling by the RIR vs a new LIR of a year which has a oodles of tickets that need human intervention. -Hank
Hank Nussbacher wrote:
On Fri, 20 Mar 2009, Florian Weimer wrote:
* Hank Nussbacher:
It takes me about 3-5 hours of work to track down and get an old unused ASN to be deallocated. How about updating the 2010 charging model so that LIRs that return ASNs are compensated?
I don't think this is a good way of using RIR funds. Why should the old guys receive even more special treatment? RIPE's charging scheme already discriminates heavily against newcomers.
I disagree.
Older LIRs have more allocations which compensates for the time factor of the algorithm. Older allocations need almost no human handling by the RIR vs a new LIR of a year which has a oodles of tickets that need human intervention.
-Hank
I don't think old vs new really matters.. pardon me for sticking w/ ARIN in this example.. I can follow their fee structure easiest - and doesn't have the old vs new: (https://www.arin.net/fees/fee_schedule.html) ARIN charges $100/yr for ASN's ... any "compensation" for returning an ASN should be less than the $100 they charge? Would it make any financial sense to compensate someone $500 for returning an ASN that only generates $100 a year? (Remember that the RIR's are non-profits..) I tend to agree w/ Randy.. it's time and money better spent focusing our efforts on supporting 4byte ASN (and v6 for that matter) Attempts at recovering 2byte ASN's (and v4 space..) are short term solutions, at best extend the 'free pool' for a short and unpredictable period of time, while incurring more headache, expense, and arguing, than working toward supporting the inevitable. --h
What this quote means is that it is 65536 times more cost-effective to deploy 4 byte ASN than to mess with legacy assignments. On Mar 20, 2009, at 12:50 PM, Heather Schiller wrote:
I tend to agree w/ Randy.. it's time and money better spent focusing our efforts on supporting 4byte ASN (and v6 for that matter) Attempts at recovering 2byte ASN's (and v4 space..) are short term solutions, at best extend the 'free pool' for a short and unpredictable period of time, while incurring more headache, expense, and arguing, than working toward supporting the inevitable.
James R. Cutler james.cutler@consultant.com
On Fri, 20 Mar 2009, Heather Schiller wrote:
I don't think old vs new really matters.. pardon me for sticking w/ ARIN in this example.. I can follow their fee structure easiest - and doesn't have the old vs new: (https://www.arin.net/fees/fee_schedule.html)
ARIN charges $100/yr for ASN's ... any "compensation" for returning an ASN should be less than the $100 they charge? Would it make any financial sense to compensate someone $500 for returning an ASN that only generates $100 a year? (Remember that the RIR's are non-profits..)
Well old vs new does have consequences. I have many ASNs issued since 1996, yet they were never charged. See 2006: ftp://ftp.ripe.net/ripe/docs/ripe-360.pdf "Note: AS Numbers, PI IPv4 and IPv6 special purpose assignments issued before 1 October 2004 will NOT count toward the 2006 billing score." As it had been up till that point. Yet in 2007: ftp://ftp.ripe.net/ripe/docs/ripe-392.pdf that rule changed and suddenly older allocations were suddenly billed. So a LIR that issued ASNs to customers and only charged them a one-time fee in 1996-2006 (processing and handling) is suddenly saddled with additional costs that they can no longer pass on to the customer. I wonder what ARIN did in that regards. Regards, Hank
* Hank Nussbacher:
Older LIRs have more allocations which compensates for the time factor of the algorithm. Older allocations need almost no human handling by the RIR vs a new LIR of a year which has a oodles of tickets that need human intervention.
And how much of that is the result of not returning old resources to the RIR? My own experience as an end user is not that good: After insisting repeatedly, only one of the LIRs we contacted eventually removed our historic PA assignment from the RIPE database (years after the last contract ended). It's just a tiny amount of resources which was involved, but I guess even those sum up in the end. Presumably, the current environment encourages LIRs to treat this as some sort of inner reserve. And as long as the LIR's resource requirements are not stagnant, this isn't even a significant problem from a global perspective.
It takes me about 3-5 hours of work to track down and get an old unused ASN to be deallocated. How about updating the 2010 charging model so that LIRs that return ASNs are compensated?
I don't think this is a good way of using RIR funds. Why should the old guys receive even more special treatment? RIPE's charging scheme already discriminates heavily against newcomers.
beancounters know how cut expenses, not how to increase sales. thus, they (though well-meaning) shrink the company and eventually drive it into the ground. the real path is to move forward, increase income, and grow. perhaps there is a lesson here. move on to 4-byte asns. randy
On Sat, Mar 21, 2009 at 08:44:23AM -0700, Randy Bush wrote:
perhaps there is a lesson here. move on to 4-byte asns.
randy
er... 'parm me sir, but aren't -all- ASNs 4 bytes? i mean, for lo these many years we cheated and only used the first two bytes... but the spec always called out four bytes. --bill
On 21/03/2009 16:36, bmanning@vacation.karoshi.com wrote:
er... 'parm me sir, but aren't -all- ASNs 4 bytes?
i mean, for lo these many years we cheated and only used the first two bytes... but the spec always called out four bytes.
There seems to be a bug in my router:
router(config)#router bgp 196641 ^ % Invalid input detected at '^' marker.
router(config)#
Do you know of anyone I could call who can fix this? Nick
Not all of Cisco IOS supports 4-byte ASN. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/dat... Alex Nick Hilliard wrote:
On 21/03/2009 16:36, bmanning@vacation.karoshi.com wrote:
er... 'parm me sir, but aren't -all- ASNs 4 bytes?
i mean, for lo these many years we cheated and only used the first two bytes... but the spec always called out four bytes.
There seems to be a bug in my router:
router(config)#router bgp 196641 ^ % Invalid input detected at '^' marker.
router(config)#
Do you know of anyone I could call who can fix this?
Nick
On Sun, Mar 22, 2009 at 10:56:06PM +0000, Nick Hilliard wrote:
On 21/03/2009 16:36, bmanning@vacation.karoshi.com wrote:
er... 'parm me sir, but aren't -all- ASNs 4 bytes?
i mean, for lo these many years we cheated and only used the first two bytes... but the spec always called out four bytes.
There seems to be a bug in my router:
router(config)#router bgp 196641 ^ % Invalid input detected at '^' marker.
router(config)#
Do you know of anyone I could call who can fix this?
Nick
your using the wrong protocol.. :) or the wrong version of a vendors code. try EGP and you should be fine w/ 4byte ASNs. --bill
bmanning@vacation.karoshi.com writes:
On Sun, Mar 22, 2009 at 10:56:06PM +0000, Nick Hilliard wrote:
On 21/03/2009 16:36, bmanning@vacation.karoshi.com wrote:
er... 'parm me sir, but aren't -all- ASNs 4 bytes?
i mean, for lo these many years we cheated and only used the first two bytes... but the spec always called out four bytes.
There seems to be a bug in my router:
router(config)#router bgp 196641 ^ % Invalid input detected at '^' marker.
router(config)#
Do you know of anyone I could call who can fix this?
Nick
your using the wrong protocol.. :) or the wrong version of a vendors code. try EGP and you should be fine w/ 4byte ASNs.
rfc 827, page 3: Autonomous systems will be assigned 16-bit identification numbers (in much the same ways as network and protocol numbers are now assigned), and every EGP message header contains one word for this number. -r
Autonomous systems will be assigned 16-bit identification numbers (in much the same ways as network and protocol numbers are now assigned), and every EGP message header contains one word for this number.
Was that a 36-bit word? --lyndon I think 3B2 code deserves its own place in hell. Poring over the ESS#5 code, someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have gotten the exact string wrong but it's close). It took us a while to figure out why. Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when programs blew up they were pointing to "f(", and the worlds most amazing kludge for detecting nil pointers was born. -- Dave Presotto
Lyndon Nerenberg <lyndon@orthanc.ca> writes:
Autonomous systems will be assigned 16-bit identification numbers (in much the same ways as network and protocol numbers are now assigned), and every EGP message header contains one word for this number.
Was that a 36-bit word?
16-bit "word" in the sense of a PDP-11 or DG Nova, not 36-bit "word" in the sense of a Univac-1100 or DECSYSTEM-20. Be glad that it wasn't a 12-bit "word" in the sense of a PDP-8. (page 33, same RFC) -r
When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this.
sounds a lot like IPv4 space, eh?
Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to the assigning LIR and after 3 months - just reclaim it.
because property is unused publicly does not affect the rights of its owner(s). otherwise old car collector wannabes could have a heyday. perhaps the world would be a better place if we spent less energy on net vigilanteism and more on moving to IPv6 and 4-byte AS numbers. randy
On Wed, Mar 18, 2009 at 9:44 AM, Randy Bush <randy@psg.com> wrote:
Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to the assigning LIR and after 3 months - just reclaim it.
because property is unused publicly does not affect the rights of its owner(s). otherwise old car collector wannabes could have a heyday.
Randy, A. AS numbers are not property. B. If they were property (and they're not), then at least in NANOG's region there are adequate laws regarding escheat of unclaimed property. I interpret this to be what Hank was going for: attempt to contact anyone with a registered but apparently unused AS number and "escheat" the ones that go unclaimed back to the registries. Whether or not this is a worthwhile activity is an entirely different question for which I intentionally decline to offer an opinion. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 18/03/2009, at 6:18 PM, Henk Uijterwaal wrote:
When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there.
I make it 25 June 2011 given current use patterns (http://www.potaroo.net/tools/asn16/ )
Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this.
thats the problem - there are current 14902 AS numbers that allocated but not visible in my part of the public Internet, but its entirely inknown to what extent these numbers are used in various forms of private or semi-private contests Geoff
participants (16)
-
Alex H. Ryu -
bmanning＠vacation.karoshi.com -
Florian Weimer -
Geoff Huston -
goemon＠anime.net -
Hank Nussbacher -
Heather Schiller -
Henk Uijterwaal -
James R. Cutler -
Lyndon Nerenberg -
Nick Hilliard -
Randy Bush -
Robert E. Seastrom -
Simon Brilus -
tvest＠eyeconomics.com -
William Herrin