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-288: IPv4 Address Allocation And Assignment Policies For The RIPE NCC Internet Numbers Registration Procedures Service Region
delete: <p> delete: <b> This document is obsoleted by ripe-72, version 0.7 of this documen delete: </b> t delete: </p> delete: <p> This document describes 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 <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>
IPv4 Address Allocation And Assignment Policies For The RIPE NCC Internet Numbers Registration Procedures Service Region