[arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments

Thu May 7 17:45:04 EDT 2009

Just to give a little background, there's a lot of information out there
on this issue.  It's likely that other RIR's will run out of 16bit ASN's
before ARIN does if they do not create a re-allocation policy to help
their 16bit pools last after their block allocations come to an end.
Vendor support is VERY scattered depending on vendor and platform.  Greg
Henkins at F10 and I have done several presentations on this very topic at
past NANOGs/GPF's/APRICOT's.  The bottom line is that AS23456 is not a
very scalable nor workable solution for many people.  I think inevitably
we are going to have to extend the 32 bit deadline to accommodate
vendors integration into mainline builds for legacy equipment that is
still being supported.  From the data I've been looking at July of 2011
appears to be the exhaust for the first RIR.  As such, I am fine with
the way that this policy is written, though I think some flexibility put
into the policy for the cutoff for 32bit only asns might be the best
bet.

-Chris

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Aaron Hughes
Sent: Thursday, May 07, 2009 5:36 PM
To: Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments

Fellow PPML participates,

Just to make sure this is 100% clear.  RIPE is very likely to run out of
16bit ASNs next year as they appear to have no reclamation process
(based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the
RIPE region). This means, operator support will happen.

ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013.
If we simply let ARIN give out 16it until they run out and they start
issuing 32bit, we will get BOTH the benefit of continuing to hand out
16bit ASNs AND push for operational support.

Global proliferation of 4-byte ASNs in 2010-2011 is a foregone
conclusion.  More to the point, ARIN has ~3.5 years of 2-byte inventory
because of their efficiency. So the proposal to stop ARIN from unifying
the two pools is unnecessary.

Cheers,
Aaron

On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote:
> 
> I oppose this policy as written.
> 
> Looking at ARIN's historical statistics, it appears as though ARIN
issues 1,600 to 1,700 ASNs each year.
> 
> Looking at IANA's stats:
> 35840-36863 Assigned by ARIN 2005-02
> 39936-40959 Assigned by ARIN 2006-03-29
> 46080-47103 Assigned by ARIN 2008-03-27
> 53248-54271 Assigned by ARIN 2009-04-21
> 54272-55295 Assigned by ARIN 2009-04-21
> Excluding April 2009, ARIN has only requested 3,072 ASNs since
February 2005.
> 
> Looking again at ARIN's historical statistics, they have issued 6,550
ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the
IANA.
> 
> Where's the difference?
> In San Antonio, Leslie gave a presentation that included information
about returned and revoked ASNs. Slide 10 of the presentation indicates
4,357 ASNs have been returned to ARIN since January 2005.
> 
> So it looks like ARIN is recycling unused ASNs, prolonging the
lifespan of the free 16-bit ASN pool.
> Projecting this forward, at current consumption rates it should take
approximately 32 months for ARIN to use up the 2,048 ASNs issued on
2009-04-21 by IANA, which puts us somewhere near December 2012.
> 
> ARIN's historical statistics:
> https://www.arin.net/knowledge/statistics/historical.html
> IANA's stats:
> http://www.iana.org/assignments/as-numbers/
> Presentation foils:
>
https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesd
ay/rsd.ppt
> 
> Cheers,
> Aaron
> 
> 
> On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote:
> > I disagree.  We are still waiting to get a release of the code train
we 
> > use on the Cisco 7600 platform that supports 32-bit ASNs.  It sounds

> > like they're finally getting close, but I think a further extension 
> > probably would be helpful.
> > 
> > We'll have a much better view of what's required by the fall
meeting, 
> > when this is up for discussion.  Since that will be our last chance
to 
> > change policy before the current 1 Jan 2010 deadline, I definitely
think 
> > this needs to be on the agenda.
> > 
> > -Scott
> > 
> > Owen DeLong wrote:
> > > NIT:  The revised text of 5.1 (or at least specific amendments to
it) 
> > > should be
> > > stated as part of the Policy statement. The rationale section is
not a 
> > > binding
> > > part of the policy.
> > >
> > > Substance: This policy simply isn't needed. Current software for
most
> > > routers supports 32 bit ASNs. There's been ample warning for
providers
> > > and other organizations to update their management systems,
scripts,
> > > etc. If they haven't done it by now, they are only going to do it
in 
> > > response
> > > to the change actually happening.  Putting it off further does not
really
> > > benefit the community.
> > >
> > > I am opposed to this policy as written.
> > >
> > >> ## * ##
> > >>
> > >>
> > >> Policy Proposal Name: Extend 16 bit ASN Assignments
> > >>
> > >> Proposal Originator: Marla Azinger
> > >>
> > >> Proposal Version: 1
> > >>
> > >> Submission Date: 6 May 2009
> > >>
> > >> Proposal type: Modify
> > >>
> > >> Policy term: Permanent
> > >>
> > >> Policy statement: This proposal is to modify section 5.1 in the
NRPM to
> > >> extend the 16-bit ASN assignment timeframe for one more year
further
> > >> than the current text. The expiration requiring removal of
section 5.1
> > >> is also being removed.
> > >>
> > >> Rationale:
> > >>
> > >> Currently users of 32-bit ASN?s are encountering technical issues
that
> > >> they can?t immediately overcome and therefore require 16-bit
ASN?s to
> > >> operate. As a result in the ARIN region to date, 204 of the 216
32-bit
> > >> ASN?s that have been assigned have been returned and exchanged
for a 16
> > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction
between
> > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on
the
> > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s
to be
> > >> assigned. If these changes are made then ARIN RIR ASN policy will
read
> > >> clearly and remove any misconceptions of 16-bit cutoff post run
out and
> > >> enable technology to catch up to the ASN bit change. The
expiration date
> > >> that requires removal of section 5.1 after zero distinction
occurs is to
> > >> be removed. Instead section 5.1 will be left in place in the NRPM
for
> > >> value added historical purposes.
> > >>
> > >> The revision of 5.1 would read as follows:
> > >>
> > >> 5.1 16-bit and 32-bit AS Numbers
> > >>
> > >> ? Commencing 1 January 2007, ARIN will process applications that
> > >> specifically request 32-bit only AS Numbers and assign such AS
numbers
> > >> as requested by the applicant. In the absence of any specific
request
> > >> for a 32-bit only AS Number, a 16-bit only AS Number will be
assigned.
> > >>
> > >> ? Commencing 1 January 2009, ARIN will process applications that
> > >> specifically request 16-bit only AS Numbers and assign such AS
Numbers
> > >> as requested by the applicant. In the absence of any specific
request
> > >> for a 16-bit only AS Number, a 32-bit only AS Number will be
assigned.
> > >>
> > >> ? Commencing 1 January 2011, ARIN will cease to make any
distinction
> > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and
will
> > >> operate AS number assignments from an undifferentiated 32-bit AS
Number
> > >> pool.
> > >>
> > >> Terminology
> > >>
> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 -
65535
> > >>
> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range
65,536 -
> > >> 4,294,967,295
> > >>
> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - 
> > >> 4,294,967,295
> > >>
> > >> Timetable for implementation: Immediate
> > >>
> > >>
> > >> _______________________________________________
> > >> PPML
> > >> You are receiving this message because you are subscribed to
> > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > >> Unsubscribe or manage your mailing list subscription at:
> > >> http://lists.arin.net/mailman/listinfo/arin-ppml
> > >> Please contact info at arin.net if you experience any issues.
> > >
> > >
------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > --
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> -- 
> 
> Aaron Hughes 
> aaronh at bind.com
> (703) 244-0427
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> http://www.bind.com/
> -- 
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-- 

Aaron Hughes 
aaronh at bind.com
(703) 244-0427
Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
http://www.bind.com/
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.