You are here: Home > RIPE Community > RIPE Document Readability > ASN > DRAFT: Autonomous System (AS) Number Assignment Policies

DRAFT: Autonomous System (AS) Number Assignment Policies

How to read this draft document:

This document relates to a project to improve the readability of RIPE policy documents. If approved, it will replace ripe-463. To show you how the new document will differ from the current one, we've both provided a summary of the changes made and listed both the current and the new text in this document.

We indicate changes to existing text in the document like this:

Current Text
Proposed Text
The text from the current policy document that will be replaced is displayed here.
The proposed text will be displayed here.

Summary of changes:

  • Wording throughout the document has been improved.
  • Renumbering of paragraphs

Specifics:

  • Abstract - Reworded and added details
  • Section 1.0 - Renamed “Definition” and text related to criteria moved to next paragraph “Assignment Criteria”
  • Section 1.1 - Renamed “Assignment Criteria” and text moved to “Definition”
  • Section 1.2 - 1.5 - All grouped under “Assignments for Internet Experiments”
  • Section 1.3 - Moved to "Defining the Experiment"
  • Section 1.6 - Moved to the end of the document.
  • Section 1.7 - Partly moved to “Assignment Criteria” and parts referring to procedures removed because this is not relevant to policy.
  • Section 1.8 - Renamed to Unused AS numbers. 'can' was changed to 'must' to better reflect the intention of the policy and to be consistent with other policy documents.

Added in new draft document:

  • Section 7.0 – References
  • Section 8.0 - Attribution

Current Text
Proposed Text

Abstract

This document provides a description of Autonomous System Numbers, their assignment procedures and guidelines on how to obtain them in RIPE NCC service region.

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 AS Number Assignment Policies and Procedures
1.1 Assignments for Internetworking Experiments
1.2 Defining the Experiment
1.3 Publication
1.4 Non-commercial Basis
1.5 Period of Temporary Resource Registration
1.6 Registration
1.7 Requesting an AS Number
1.8 Returning an AS Number
1.9 32-bit AS Numbers

Contents

1.0 Definition
2.0 Assignment Criteria
3.0 Assignments for Internet Experiments
3.1 Defining the Experiment
3.2 Non-commercial Basis
3.3 Period of the Resource Registration
4.0 Returning AS Numbers
5.0 32-bit AS Numbers
6.0 Registration
7.0 References
8.0 Attribution

 

1.0 AS Number Assignment Policies and Procedures

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 RFC 1771, "A Border Gateway Protocol 4 (BGP-4)", are used to exchange routing information between Autonomous Systems. More information on RFC 1771 can be found at:
ftp://ftp.ripe.net/rfc/rfc1771.txt

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. Sharing an AS Number among a set of networks that do not fall under the same organisational umbrella is possible but will sometimes require extra co-ordination among the various network administrators. (In some cases, some level of network re-engineering may be needed.) This may be the only way to implement the desired routing policy. For more information please see RFC 1930, "Guidelines for creation, selection, and registration of an Autonomous System (AS)" found at:
ftp://ftp.ripe.net/rfc/rfc1930.txt

Current guidelines require a network to be multi-homed for an AS Number to be assigned. Requests must show the routing policy of the Autonomous System. The policy is defined in the following attributes as part of the aut-num object: multiple fields of "import:" (describing accepted routing information from neighbouring ASs.); multiple fields of "export:" (describing generated routing information sent to peers); one or more (optional) fields of "default:" (indicating how default routing is done).

 

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

1.1 Assignments for Internetworking 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.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.

1.2 Defining the Experiment

An organisation receiving numbering resources must document the experiment. This may be in the form of a current IETF Experimental RFC (see RFC 2026, Sec. 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. Where the experiment requires a variation to this rule it should be noted in the resource request forms sent to the RIPE NCC.

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

1.3 Publication

The experiment proposal must be made public (e.g. published on web site), upon registration of the resources by the RIPE NCC. Following the conclusion of the experiment the results must be published free of charge and free from disclosure constraints.

 

 

1.4 Non-commercial Basis

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

 

3.2 Non-commercial Basis

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

 

1.5 Period of the Temporary Resource Registration

The resources will be issued on a temporary basis for a period of one year. Renewal of the resource’s 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.

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.

1.6 Registration

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

1.7 Requesting an AS Number

Regardless of whether the AS Number is required as an experimental assignment or otherwise, the RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region. The AS Number will be assigned by the RIPE NCC 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”.

The RIPE NCC provides a form for AS Number requests.

 

 

 

1.8 Returning an AS Number

If an organisation has an AS Number that is no longer in use, it can be returned to the public pool of AS Numbers by sending a message to hostmaster _at_ ripe _dot_ net. It can then be reassigned to another Autonomous System by the RIPE NCC.

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

1.9 32-bit AS Numbers

RIPE NCC will assign 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 will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool.

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

[RFC 1771] "A Border Gateway Protocol 4 (BGP-4)" ftp://ftp.ripe.net/rfc/rfc1771.txt

[RFC 1930] " Guidelines for creation, selection, and registration of an Autonomous System (AS)" ftp://ftp.ripe.net/rfc/rfc1930.txt

[RFC 2026] "The Internet Standards Process—Revision 3 IETF Experimental RFC ftp://ftp.ripe.net/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