You are here: Home > Publications > RIPE Document Store > RIPE NCC Internet Numbers Registration Procedures

Changes to RIPE NCC Internet Numbers Registration Procedures

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted
ripe-065: ripe-581: This document describes the policy for reverse delegation of IPv4 and IPv6 address space in the RIPE NCC Internet Numbers Registration Procedures service region.
delete: <p> insert: <p class=" ">

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

insert: <h3>

Contents insert: </h3>

insert: <p>

insert: <a class="anchor-link" href="#definition"> 1.0 Definition insert: </a> insert: </p>

insert: <p>

insert: <a class="anchor-link" href="#introduction"> 2.0 Introduction insert: </a> insert: </p>

insert: <p>

insert: <a class="anchor-link" href="#reverse_delegation"> 3.0 Reverse Delegation in the RIPE NCC Service Region insert: </a> insert: </p>

insert: <p>

insert: <a class="anchor-link" href="#procedures"> 4.0 Procedures insert: </a> insert: </p>

insert: <p>

insert: <a class="anchor-link" href="#references"> 5.0 References insert: </a> insert: </p>

insert: <p>

insert: <a class="anchor-link" href="#attribution"> 6.0 Attribution insert: </a> insert: </p>

insert: <h3>

insert: <a name="definition"> insert: </a> 1.0 Definition insert: </h3>

insert: <p style="padding-left: 30px; ">

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

insert: <p style="padding-left: 30px; ">

insert: <b> 1.2 Early registration: insert: </b> IPv4 address space assigned or allocated before the establishment of the Regional Internet Registries (RIRs). insert: </p>

insert: <p>

insert: </p>

insert: <p>

insert: </p>

insert: <h3>

insert: <a name="introduction"> insert: </a> 2.0 Introduction insert: </h3>

insert: <p>

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 [ insert: <a class="anchor-link" href="#ref1"> 1 insert: </a> ] and [ insert: <a class="anchor-link" href="#ref2"> 2] insert: </a> . insert: </p>

insert: <h3>

insert: <a name="reverse_delegation"> insert: </a> 3.0 Reverse Delegation in the RIPE NCC Service Region insert: </h3>

insert: <p>

The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC. insert: </p>

insert: <p>

The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database. insert: </p>

insert: <p>

Address space holders may delegate authority to another party. insert: </p>

insert: <p>

insert: </p>

insert: <p>

insert: </p>

insert: <h3>

insert: <a name="procedures"> insert: </a> 4.0 Procedures insert: </h3>

insert: <p>

The procedures related to reverse delegation and information about the requirements the RIPE NCC enforces are published at: insert: </p>

insert: <p>

insert: <a href="http://www.ripe.net/reverse/"> http://www.ripe.net/reverse/ insert: </a> insert: </p>

insert: <h3>

insert: <a name="references"> insert: </a> 5.0 References insert: </h3>

insert: <p>

insert: <a name="ref1"> insert: </a> [1] [ insert: <a class="external-link" href="ftp://ftp.ripe.net/rfc/rfc3172.txt"> RFC 3172 insert: </a> ] "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")" insert: </p>

insert: <p>

insert: <a name="ref2"> insert: </a> [2] [ insert: <a class="external-link" href="ftp://ftp.ripe.net/rfc/rfc3596.txt"> RFC 3596 insert: </a> ] "DNS Extensions to Support IP Version 6", [ insert: <a class="external-link" href="ftp://ftp.ripe.net/rfc/rfc3363.txt"> RFC 3363 insert: </a> ] “Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System”, [ insert: <a class="external-link" href="ftp://ftp.ripe.net/rfc/rfc3364.txt"> RFC 3364 insert: </a> ] “Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version (IPv6)” insert: </p>

insert: <h3>

insert: <a name="attribution"> insert: </a> 6.0 Attribution insert: </h3>

insert: <p>

This document is obsoleted compiled from policies developed by ripe-72, version 0.7 of the RIPE community. insert: </p>

insert: <p>

The following people actively contributed to this documen delete: </b> t delete: </p> delete: <p> This document describes the procedures for the reassignment of IP policy by making proposals through the RIPE Policy Development Process: insert: </p>

insert: <p>

Olaf Kolkman
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 <hostmaster@ripe.net>. 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 information about reassigned network numbers must be reported delete: <br /> 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 <ripe-dbm@ripe.net> and <hostmaster@nic.ddn.mil> 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 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 ncc@ripe.net. delete: </p> Leo Vegoda insert: </p>

Policy For Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Internet Numbers Registration Procedures Service Region