Skip to main content

Draft document

This policy proposal has been accepted

The new RIPE Document is: ripe-638

How to read this draft document:

This document relates to the policy proposal 2014-13, “Allow AS Number Transfers”. 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:

ORIGINAL TEXT

NEW TEXT

The text from the current policy document that will be replaced is displayed here.

The proposed text change will be displayed here.


Abstract

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.

Contents

1.0 Definition

2.0 Assignment Criteria

3.0 Returning AS Numbers

4.0 Transferring AS Numbers

5.0 32-bit AS Numbers

6.0 Registration

7.0 References

8.0 Attribution

1.0 Definition

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.

2.0 Assignment Criteria

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.

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

3.0 Returning AS Numbers

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.

3.0 Returning AS Numbers

If an organisation no longer uses the AS Number, it should be returned to the public pool of AS Numbers. The RIPE NCC can then reassign the AS Number to another organisation.

4.0 Transferring AS Numbers

Any holder of Autonomous System (AS) Numbers is allowed to re-assign AS Numbers that were previously assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry System.

AS Numbers may only be re-assigned in accordance with the RIPE Policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.

Re-assignments must be reflected in the RIPE Database. This re-assignment can either be on a permanent or non-permanent basis.

The RIPE NCC will record the change of AS Numbers after the transfer.

The RIPE NCC will publish a separate list of all AS Numbers transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.

The list will contain information about approved and non-approved transfers.

The following information will be published for approved transfers:

  • The name of the transferring party
  • The name(s) of the receiving party or parties
  • The transferred AS Number
  • The date each AS Number was transferred

Non-approved transfers will be published in aggregate statistics. In the statistics the following information will be published:

  • The Number of requested transfers not approved after the RIPE NCC’s evaluation
  • The sum of the AS Numbers included in the requested transfers

Neither the AS Numbers nor the organisations involved will be identified in these statistics.

Please note that the transferring party always remains responsible for the AS Number it receives from the RIPE NCC until the transfer of the resource to another party is completed or if the resource is returned.

Re-assigned AS Numbers are no different from AS Numbers assigned directly by the RIPE NCC and so must be used by the receiving party according to the policies described in this document.


5.0 32-bit AS Numbers

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.

6.0 Registration

The RIPE NCC will register the resources issued in the RIPE Database.

7.0 References

[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

8.0 Attribution

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