[ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text
Scott Leibrand
sleibrand at internap.com
Sat Feb 4 22:20:05 EST 2006
On 02/04/06 at 7:28pm -0500, Marshall Eubanks <tme at multicasttech.com> wrote:
> Thanks. (I knew there weren't many, which is why I wanted a diff.)
>
> I support this as written.
Ditto.
-Scott
> On Feb 4, 2006, at 3:43 PM, Geoff Huston wrote:
>
> > At 06:04 AM 4/02/2006, Marshall Eubanks wrote:
> >> Dear Geoff;
> >>
> >> Could you possibly send to the list a diff with the previous
> >> version ?
> >>
> >> Regards
> >> Marshall
> >
> >
> > sure
> >
> > There are only 4 changes that have been applied - as noted below
> >
> > Geoff
> >
> > ==========================================
> >
> > Policy Proposal 2005-9: 4-Byte AS Number
> >
> > Author: Geoff Huston
> >
> > Proposal Version: Revision 1 (February 3, 2006)
> >
> > Proposal type: modify
> >
> > Policy term: temporary
> >
> > Policy statement:
> >
> > This policy proposal nominates 3 dates for changes to the
> > current AS Number allocation policy for the registry:
> >
> > | - Commencing 1 January 2007 the registry will process
> >
> > Global change "On 1 January" to "Commencing 1 January
> >
> > | applications that specifically request 32-bit only AS Numbers
> >
> > Global change "4-byte" to "32-bit"
> >
> > and allocate 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 allocated by the
> >
> > global change "2-byte" to "16-bit"
> >
> > registry.
> >
> > - Commencing 1 January 2009 the registry will process
> > applications that specifically request 16-bit only AS Numbers
> > and allocate 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 allocated by the
> > registry.
> >
> > - Commencing 1 January 2010 the registry will cease to make any
> > distinction between 16-bit only AS Numbers and 32-bit only AS
> > Numbers, and will operate AS number allocations from an
> > undifferentiated 32-bit AS Number allocation pool.
> >
> > Nomenclature
> >
> > It is proposed to identify 32-bit AS Numbers using a syntax of
> > | "<high order 16 bit value in decimal>.<low order 16 bit value in
> >
> > global change ":" to "."
> >
> > decimal>". Accordingly, a 32-bit AS number of value 65546
> > (decimal) would be identified as "1.10".
> >
> >
> > 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 1.0 -
> > 65535.65535 (decimal range 65,536 - 4,294,967,295)
> >
> > "32-bit AS Numbers" refers to AS Numbers in the range 0.0 -
> > 65535.65535 (decimal range 0 - 4,294,967,295)
> >
> >
> > Rationale:
> >
> > Recent studies of AS number consumption rates indicate that the
> > existing 16-bit pool of unallocated AS Numbers will be exhausted
> > sometime in the period between 2010 and 2016, absent of any
> > concerted efforts of recovery of already-allocated AS Numbers
> > [1] [2]. Standardization work in the IETF has produced a
> > document that is currently being submitted as a Proposed
> > Standard that will expand the AS Number space to a 32-bit field
> > [3].
> >
> > It is noted that some advance period may be required by network
> > operators to undertake the appropriate procedures relating to
> > support of 32-bit AS numbers, and while no flag day is required
> > in the transition to the longer AS Number field, it is
> > recognised that a prudent course of action is to allow for
> > allocation of these extended AS numbers well in advance of an
> > anticipated 16-bit AS Number exhaustion date.
> >
> > This policy proposal details a set of actions and associated
> > dates for RIR AS Number allocation policies to assist in an
> > orderly transition to use of the 32-bit AS Number space.
> >
> > The essential attributes of this policy proposal are to
> > facilitate the ease of transitional arrangements by equipment
> > vendors, network managers and network operations staff, to
> > provide the industry with some predictability in terms of dates
> > and associated actions with respect to registry operational
> > procedures for AS Number allocations.
> >
> > References
> >
> > [1] Daily AS Number Report, http://www.potaroo.net/tools/asns
> > [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality,
> > http://www.nanog.org/mtg-0510/wilhelm.html
> > [3] BGP Support for Four-octet AS Number Space,
> > draft-ietf-idr-as4bytes-12.txt
> >
> >
> > Timetable for implementation:
> >
> > Procedures to support this proposal need to be implemented by 1
> > January 2007
> >
> >
> >
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>
More information about the ARIN-PPML
mailing list