Skip to main content
  • Legend
  • Added
  • Deleted

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.

Contents

1.0 Definition Link: #1
2.0 Assignment Criteria 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: #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 RFC 1771 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.

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

The RIPE NCC will assign complete class C blocks to individual NICs
and NOCs. They can be requested from <[email protected]>.

B) In order to prevent implementation problems, network numbers ending
with 0 or 255 should NOT be reassigned.

C) Full information about reassigned network numbers must be reported
back to the RIPE NCC in full RIPE database format (ref ripe-13).
The complete entries should be sent immediately after reassignment to
<[email protected]>.
The RIPE NCC is ready to accept block entries for the RIPE database.
For block syntax, please contact the RIPE NCC.

D) Reassignment of class C network numbers should be done in a manner
that facilitates Supernetting (see next section).

E) Requests for network numbers should be reasonable. All NICs and NOCs
should prevent stockpiling of network numbers.

F) On first request from the RIPE NCC, the class C network numbers not
yet reassigned, must be returned to the RIPE NCC.


Supernetting

NICs and NOCs reassigning IP network numbers are urgently requested to
read the Supernetting proposal by Vince Fuller et al. This document can
be obtained from the rfc section of the RIPE document store or other RFC
servers. It is called rfc1338.txt.
The Supernetting proposal was made to reduce the increase of routing
table size in the current Internet. It proposes to create a hierarchy
of IP network numbers, which can then be aggregated resulting in less
routing table entries in routing equipment. While this proposal has not
been formally adopted we expect that something at least along the same
principle will be implemented in the near future.

Here is how it works: 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/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 A needs 8 class C network numbers, the numbers should
be given out in such a way that the routing information for each of
these 8 networks could appear as one entry with the correct mask in
routers.

More concretely:

Service provider S hands out networks 192.24.8 through 192.24.15 to
organisation A. These networks can then appear in routing equipment as a
supernet route to 192.24.8 with mask 255.255.248.0. This way 8 class C
network numbers appear as one routing table entry.

The guidelines that can be derived from the Supernetting proposal are:

A) Service providers should reserve blocks of class C network numbers from
their allocation for each organisations requesting class C network numbers.

B) The size of these blocks should always be a power of 2.

C) The numbers in these blocks should be contiguous.

D) The blocks should start on bit boundaries.
(ie powers of 2, AND multiples of the block size)

E) The blocks reserved for an organisation should be sufficient for a
reasonable expected growth over the next few years.

F) Multi-homed organizations may obtain address space from one of their
providers, the RIPE NCC, or the global NIC, as is appropriate to their
network configuration. These organisations are strongly encouraged to
contact the RIPE NCC for guidance.



If you have any questions concerning this, please do not hesitate to
call or mail us at [email protected]. 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.

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

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