[ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text

Geoff Huston gih at apnic.net
Sat Feb 4 15:43:59 EST 2006

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 ?


There are only 4 changes that have been applied - as noted below



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"


       - 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

       - 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.


       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".


       "16-bit only AS Numbers" refers to AS numbers in the range 0 -

       "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)


       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

       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.


       [1] Daily AS Number Report, http://www.potaroo.net/tools/asns
       [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality,
       [3] BGP Support for Four-octet AS Number Space,

Timetable for implementation:

       Procedures to support this proposal need to be implemented by 1
       January 2007

More information about the ARIN-PPML mailing list