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
Link: #Definition Link: #1 2.0 Assignment Criteria
Link: #AssignmentCriteria 3.0 Returning AS Numbers
Link: #Returning 4.0 Transferring AS Numbers
Link: #Transferring Link: #2
3.0 Assignments for Internet Experiments Link: #3
3.1 Defining the Experiment Link: #31
3.2 Non-commercial Basis Link: #32
3.3 Period of the Resource Registration Link: #33
4.0 Returning AS Numbers Link: #4 5.0 32-bit AS Numbers
Link: #ASnumbers 6.0 Registration
Link: #Registration 7.0 References
Link: #References 8.0 Attribution Link: #Attribution Link: #5
6.0 Registration Link: #6
7.0 References Link: #7
8.0 Attribution Link: #8

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 RFC 1771 , "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 RFC 1930 .

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

Link: http://www.ripe.net/publications/docs/contract-req ”.

3.0 Link: http://www.ripe.net/ripe/docs/contract-req.html ”.

3.0 Assignments for Internet Experiments

Organisations often require deployment tests for new Internet services and technologies. These require numbering resources for the duration of the test. The policy goal of resource conservation is of reduced importance when resources are issued on a temporary basis.

3.1 Defining the Experiment

The experiment for which the organisation receives numbering resources must be documented. This may be in the form of a current IETF Experimental RFC (see RFC 2026 Link: ftp://ftp.ripe.net/rfc/rfc2026.txt , Section 4.2.1 or an “experiment proposal” detailing the resources required and the activities to be carried out. A single AS Number will be assigned. If more than one AS Number is required for the experiment, this should be indicated and explained in the request.

The experiment proposal must be made public (e.g. published on a website), upon registration of the resources by the RIPE NCC. When the experiment is concluded the results must be published free of charge and free from disclosure constraints.

3.2 Non-commercial Basis

Resources issued for an experiment must not be used for commercial purposes.

3.3 Period of the Resource Registration

The resources will be issued on a temporary basis for a period of one year. Renewal of the resources' registration is possible on receipt of a new request that details any continuation of the experiment during the extended period.

The resources issued cannot be used for a commercial service following the conclusion of the experiment. At the end of the assignment period the AS Number must be returned to the RIPE NCC.

4.0

Returning AS Numbers

If an organisation no longer uses the AS Number, it should must 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

The transfer of Internet number resources is governed by the RIPE Document, "RIPE Resource Transfer Policies Link: http://www.ripe.net/publications/docs/transfer-policies ".

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