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

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

Contents

1.0 Definition Link: #definition

2.0 Introduction Link: #introduction

3.0 Reverse Delegation in the RIPE NCC Service Region Link: #reverse_delegation

4.0 Procedures Link: #procedures

5.0 References Link: #references

6.0 Attribution Link: #attribution

1.0 Definition

1.1 Reverse delegation: The process by which the authority for certain reverse DNS zones is assigned to a specific set of DNS servers.

1.2 Early registration: IPv4 address space assigned or allocated before the establishment of the Regional Internet Registries (RIRs).

2.0 Introduction

The RIPE NCC provides the necessary support to enable resolution of IPv4 and IPv6 address space into domain names. This service is implemented under the in-addr.arpa and ip6.arpa sub-domains described in [1 Link: #ref1 ] and [2] Link: #ref2 .

3.0 Reverse Delegation in the RIPE NCC Service Region

The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC.

The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database.

Address space holders may delegate authority to another party.

4.0 Procedures

The procedures related to reverse delegation and information about the requirements the RIPE NCC enforces are published at:

http://www.ripe.net/reverse/ Link: http://www.ripe.net/reverse/

5.0 References

[1] [RFC 3172 Link: ftp://ftp.ripe.net/rfc/rfc3172.txt ] "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"

[2] [RFC 3596 Link: ftp://ftp.ripe.net/rfc/rfc3596.txt ] "DNS Extensions to Support IP Version 6", [RFC 3363 Link: ftp://ftp.ripe.net/rfc/rfc3363.txt ] “Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System”, [RFC 3364 Link: ftp://ftp.ripe.net/rfc/rfc3364.txt ] “Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version (IPv6)”

6.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed to this policy by making proposals through the RIPE Policy Development Process:

Olaf Kolkman
Leo Vegoda