Changes to RIPE NCC Internet Numbers Registration Procedures

Abstract insert: </h2>

This document describes the policy for reverse delegation of IPv4 and IPv6 address space in the RIPE NCC service region. insert: </p>

Contents insert: </h3>

insert: <p>

insert: <a class="anchor-link" href="#intro"> 1.0 Introduction insert: </a> insert: <br />
insert: <a class="anchor-link" href="#delegation"> 2.0 Obtaining Delegation of an in-addr.arpa or ip6.arpa sub-domain insert: </a> insert: <br />
insert: <a class="anchor-link" href="#procedures"> 3.0 Procedures insert: </a> insert: <br />
insert: <a class="anchor-link" href="#references"> 4.0 References insert: </a> insert: </p>

insert: </blockquote>

insert: <a name="intro"> insert: </a> 1.0 Introduction insert: </h2>

The RIPE NCC provides, as part of its services, the necessary support to enable the reverse 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 [ insert: <a class="anchor-link" href="#references"> 1 insert: </a> ] and [ insert: <a class="anchor-link" href="#references"> 2 insert: </a> ]. insert: </p>

Reverse delegations for IPv4 and IPv6 addresses allocated by the RIPE NCC are made to Local Internet Registries (LIRs) and further delegated by the LIRs to Internet Service Providers or End Users. insert: </p>

insert: <a name="delegation"> insert: </a> 2.0 Obtaining Delegation of an in-addr.arpa or ip6.arpa sub-domain insert: </h2>

The RIPE NCC provides reverse delegation for address space that has been allocated or assigned by the RIPE NCC. It also provides systems to control reverse delegations relating to early registrations that have been transferred to the RIPE Database. Registrants of address space allocations or assignments may delegate authority for requesting reverse delegation from the RIPE NCC. insert: </p>

The RIPE NCC accepts requests for reverse delegation for address space that has been allocated by the RIPE NCC to an LIR or, in the case of PI address space, an assignment that has been made to an End User. insert: </p>

insert: <a name="procedures"> insert: </a> 3.0 Procedures insert: </h2>

The procedures for the reassignment of IP delete: <br /> network numbers from blocks obtained from the RIPE Network Coordination delete: <br /> Centre. It deals with items as providing information for the RIPE and delete: <br /> US NIC databases, as well as reassignment of IP addresses in light of delete: <br /> the "Supernetting" proposal, as documented in RFC 1338, by Vince Fuller delete: <br /> et al. delete: <br /> delete: <br /> delete: <br /> Introduction delete: <br /> delete: <br /> Since May 1st 1992, the RIPE Network Coordination Centre (NCC) is delete: <br /> acting as a delegated registry for IP networks numbers to NICs and NOCs delete: <br /> in Europe. It is RIPE NCC policy not to give out network numbers to delete: <br /> individual organisations, who should refer in turn, to their IP network delete: <br /> service provider. delete: <br /> delete: <br /> The mission of the RIPE NCC is to give network numbers to the various delete: <br /> service providers and NICs. The NICs and NOCs can then reassign the delete: <br /> actual IP network numbers to organisations requesting IP network delete: <br /> numbers. delete: <br /> delete: <br /> delete: <br /> Class B Network Number Allocation Procedure delete: <br /> delete: <br /> Service providers can request Class B network numbers on a one-by-one delete: <br /> basis from the RIPE NCC. Because class B address space is a critical delete: <br /> resource, a request for a class B network number must be accompanied by delete: <br /> a justification in terms of the requesting organisation's size, current delete: <br /> network and expected network growth. The requestor should also make delete: <br /> clear why they cannot use a block of class C network numbers to achieve delete: <br /> their goals. The RIPE NCC will review requests using the same standards delete: <br /> as any other Internet Registry, particularly the US NIC. delete: <br /> delete: <br /> delete: <br /> Class C Allocation Procedures delete: <br /> delete: <br /> delete: <br /> NICs and NOCs accepting a block of class C numbers agree to adhere to delete: <br /> the following procedures: delete: <br /> delete: <br /> A) The RIPE NCC will assign complete class C blocks to individual NICs delete: <br /> and NOCs. They can be requested from <[email protected]>. delete: <br /> delete: <br /> B) In order to prevent implementation problems, network numbers ending delete: <br /> with 0 or 255 should NOT be reassigned. delete: <br /> delete: <br /> C) Full and modifying reverse delegation and information about reassigned network numbers must be reported the requirements the RIPE NCC enforces to maintain the quality of the reverse delegations are published at: insert: </p>

insert: <p>

insert: <a data-val="275a3e401b56a46b5cf7b0a5a93c1492" href="resolveuid/275a3e401b56a46b5cf7b0a5a93c1492" data-linktype="internal" class="internal-link"> http://www.ripe.net/reverse/ insert: </a> insert: </p>

insert: </blockquote>

insert: <a name="references"> insert: </a> 4.0 References insert: </h2>

[1] "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"
back to the RIPE NCC and the US NIC in full RIPE database format (ref delete: <br /> ripe-13). The complete entries should be sent immediately after delete: <br /> reassignment to <[email protected]> and <[email protected]> delete: <br /> Unfortunately, the RIPE NCC is not yet ready to accept block entries for delete: <br /> the RIPE database, so you must send in each individual entry. delete: <br /> delete: <br /> D) Reassignment of class C network numbers should be done in a manner delete: <br /> that facilitates Supernetting (see next section). delete: <br /> delete: <br /> E) Requests for network numbers should be reasonable. All NICs and NOCs delete: <br /> should prevent stockpiling of network numbers. delete: <br /> delete: <br /> F) On first request from the RIPE NCC, the class C network numbers not delete: <br /> yet reassigned, must be returned to the RIPE NCC. delete: <br /> delete: <br /> delete: <br /> Supernetting delete: <br /> delete: <br /> NICs and NOCs reassigning IP network numbers are urgently requested to delete: <br /> read the Supernetting proposal by Vince Fuller et al. This document can delete: <br /> be obtained from the rfc section of the RIPE document store or other [ insert: <a href="ftp://ftp.ripe.net/rfc/rfc3172.txt"> RFC delete: <br /> servers. It is called rfc1338.txt. delete: <br /> The Supernetting proposal was made to reduce the increase of routing delete: <br /> table size in the current Internet. It proposes to create a hierarchy delete: <br /> of IP network numbers, which can then be aggregated resulting in less delete: <br /> routing table entries in routing equipment. While this proposal has not delete: <br /> been formally adopted we expect that something at least along the same delete: <br /> principle will be implemented in the near future. delete: <br /> delete: <br /> Here is how it works: delete: <br /> delete: <br /> If an organisation A needs 8 class C network numbers, the numbers should delete: <br /> be given out in such a way that the routing information for each of delete: <br /> these 8 networks could appear as one entry with the correct mask in delete: <br /> routers. delete: <br /> delete: <br /> More concretely: delete: <br /> delete: <br /> Service provider S hands out networks 192.24.8 through 192.24.15 to delete: <br /> organisation A. These networks can then appear in routing equipment as a delete: <br /> supernet route to 192.24.8 with mask 255.255.248.0. This way 8 class C delete: <br /> network numbers appear as one routing table entry. delete: <br /> delete: <br /> The guidelines that can be derived from the Supernetting proposal are: delete: <br /> delete: <br /> A) Service providers should reserve blocks of class C network numbers from delete: <br /> their allocation for each organisations requesting class C network numbers. delete: <br /> delete: <br /> B) The size of these blocks should always be a power of 2. delete: <br /> delete: <br /> C) The numbers in these blocks should be contiguous. delete: <br /> delete: <br /> D) The blocks should start on bit boundaries. delete: <br /> (ie powers of 2, AND multiples of the block size) delete: <br /> delete: <br /> E) The blocks reserved for an organisation should be sufficient for a delete: <br /> reasonable expected growth over the next few years. delete: <br /> delete: <br /> F) Multi-homed organizations may obtain address space from one of their delete: <br /> providers, the RIPE NCC, or the global NIC, as is appropriate to their delete: <br /> network configuration. These organisations are strongly encouraged to delete: <br /> contact the RIPE NCC for guidance. delete: <br /> delete: <br /> If you have any questions concerning this, please do not hesitate to delete: <br /> call or mail us at [email protected]. delete: </p> 3172 insert: </a> ] insert: </p>

[2] "DNS Extensions to Support IPv6 Address Aggregation and Renumbering" [ insert: <a href="ftp://ftp.ripe.net/rfc/rfc2874.txt"> RFC 2874 insert: </a> ] insert: </p>