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:
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
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
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
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.pptWhen 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
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.
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:
* 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
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
What this quote means is that it is 65536 times more cost-effective to deploy 4 byte ASN than to mess with legacy assignments.
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
* 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
* Randy Bush:
the real path is to move forward, increase income, and grow.
Sure. I was enlightened when someone posted to a RIPE mailing list,
"we are heading towards a future where address space is scarce" (my
words, not his). But the exact opposite is true.
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
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
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