This documents obsoletes ripe-65, version 0.6 of this document
Abstract
This document describes the procedures for the reassignment of IP
network numbers from blocks obtained from the RIPE Network Coordination
Centre. It deals with items as providing information for the RIPE
database, as well as reassignment of IP addresses in light of
the "Supernetting" proposal, as documented in RFC 1338, by Vince Fuller
et al.
Introduction
Since May 1st 1992, the RIPE Network Coordination Centre (NCC) is
acting as a delegated registry for IP networks numbers to NICs and NOCs
in Europe. It is RIPE NCC policy not to give out network numbers to
individual organisations, who should refer in turn, to their IP network
service provider.
The mission of the RIPE NCC is to give network numbers to the various
service providers and NICs. The NICs and NOCs can then reassign the
actual IP network numbers to organisations requesting IP network
numbers.
Class B Network Number Allocation Procedure
Service providers can request Class B network numbers on a one-by-one
basis from the RIPE NCC. Because class B address space is a critical
resource, a request for a class B network number must be accompanied by
a justification in terms of the requesting organisation's size, current
network and expected network growth. The requestor should also make
clear why they cannot use a block of class C network numbers to achieve
their goals. The RIPE NCC will review requests using the same standards
as any other Internet Registry, particularly the US NIC.
Class C Allocation Procedures
NICs and NOCs accepting a block of class C numbers agree to adhere to
the following procedures:
A) 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.
1.0 Definition Link: #Definition
2.0 Assignment Criteria Link: #AssignmentCriteria
3.0 Returning AS Numbers Link: #Returning
4.0 Transferring AS Numbers Link: #Transferring
5.0 32-bit AS Numbers Link: #ASnumbers
6.0 Registration Link: #Registration
7.0 References Link: #References
8.0 Attribution Link: #Attribution
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 Link: ftp://ftp.ripe.net/rfc/rfc1771.txt , "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 Link: ftp://ftp.ripe.net/rfc/rfc1930.txt .
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.
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 Link: http://www.ripe.net/ripe/docs/contract-req ”.
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:
Non-approved transfers will be published in aggregate statistics. In the statistics the following information will be published:
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.
The RIPE NCC assigns 32-bit AS Numbers according to the following timeline:
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 Link: 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 Link: http://www.ietf.org/rfc/rfc1930.txt
[RFC2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC http://www.ietf.org/rfc/rfc2026.txt Link: 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