How to read this draft document:
This document relates to the policy proposal 2014-03, “Remove Multihoming Requirement for AS Number Assignments”. If approved, it will modify ripe-525. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.
We indicate changes to existing text in the document like this:
The text from the current policy document that will be replaced is displayed here.
The proposed text change will be displayed here.
All other text in the document will not be replaced.
This document describes the policies for the assignment of globally unique Autonomous System (AS) Numbers within the RIPE NCC service region. These policies are developed by the RIPE Community following the RIPE Policy Development Process.
An Autonomous System (AS) is a group of IP networks run by one or more network operators with a single clearly defined routing policy. When exchanging exterior routing information, each AS is identified by a unique number. Exterior routing protocols such as BGP, described in RFC1771, "A Border Gateway Protocol 4 (BGP-4)", are used to exchange routing information between Autonomous Systems. An AS will normally use some interior gateway protocol to exchange routing information on its internal networks.
In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930.
A network must be multihomed in order to qualify for an AS Number.
When requesting an AS Number the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.
A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need.
To discourage excessive resource consumption, the sum of AS Numbers assigned to a single organisation must not exceed 1,000.
When requesting a 16-bit AS Number, the network must be multihomed within nine months of the assignment. Failure to multihome within this timeframe will result in deregistration of the assignment. A 32-bit AS Number is exempt from the multihoming requirement.The routing policy of an Autonomous System should be defined in RPSL in the RIPE Database.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.
If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers. The RIPE NCC can then reassign the AS Number to another organisation.
The RIPE NCC assigns 32-bit AS Numbers according to the following timeline:
From 1 January 2007 the RIPE NCC will process applications that specifically request 32-bit only AS Numbers (AS Numbers that can not be represented with 16 bits) and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, the RIPE NCC will assign a 16-bit AS Number.
From 1 January 2009 the RIPE NCC will process applications that specifically request 16-bit AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit AS Number, the RIPE NCC will assign a 32-bit only AS Number.
From 1 January 2010 the RIPE NCC will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and it will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool.
The RIPE NCC will register the resources issued in the RIPE Database.
[RFC1771] "A Border Gateway Protocol 4 (BGP-4)" http://www.ietf.org/rfc/rfc1771.txt
[RFC1930] " Guidelines for creation, selection, and registration of an Autonomous System (AS)" http://www.ietf.org/rfc/rfc1930.txt
[RFC2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC http://www.ietf.org/rfc/rfc2026.txt see Sec. 4.2.1
This document is compiled from policies developed by the RIPE community.
The following people actively contributed by making proposals through the RIPE Policy Development Process:
Nick Hilliard, Geoff Huston