Changes to RIPE NCC Internet Numbers Registration Procedures
| Legend | (+) Added | (-) Deleted |
|---|---|---|
| Changed | Tag Added | Tag Deleted |
insert: <strong> Abstract delete: <br /> delete: <br /> delete: <br /> insert: </strong> insert: </h3>
insert: <p class="western">This document describes the procedures policies for the reassignment 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. insert: </p>
insert: <p class="western">insert: </p>
insert: <h3>insert: <strong> Contents insert: </strong> insert: </h3>
insert: <p class="western"> 1.0 insert: <a class="anchor-link" title="" href="#Definition" target="_self"> Definition insert: <br />
insert: </a> 2.0 insert: <a class="anchor-link" title="" href="#AssignmentCriteria" target="_self"> Assignment Criteria insert: <br />
insert: </a> 3.0 insert: <a class="anchor-link" title="" href="#Returning" target="_self"> Returning AS Numbers insert: <br />
insert: </a> 4.0 insert: <a class="anchor-link" title="" href="#Transferring" target="_self"> Transferring AS Numbers insert: <br />
insert: </a> 5.0 insert: <a class="anchor-link" title="" href="#ASnumbers" target="_self"> 32-bit AS Numbers insert: <br />
insert: </a> 6.0 insert: <a class="anchor-link" title="" href="#Registration" target="_self"> Registration insert: <br />
insert: </a> 7.0 insert: <a class="anchor-link" title="" href="#References" target="_self"> References insert: <br />
insert: </a> 8.0 insert: <a class="anchor-link" title="" href="#Attribution" target="_self"> Attribution insert: </a> insert: </p>
insert: </p>
insert: <h3>insert: <a name="Definition"> insert: </a> 1.0 Definition insert: </h3>
insert: <p class="western">An Autonomous System (AS) is a group of IP delete: <br /> networks run by one or more network numbers from blocks obtained from the RIPE Network Coordination delete: <br /> Centre. It deals operators with items a single clearly defined routing policy. When exchanging exterior routing information, each AS is identified by a unique number. Exterior routing protocols such as providing BGP, described in insert: <a href="ftp://ftp.ripe.net/rfc/rfc1771.txt"> RFC1771 insert: </a> , "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. insert: </p>
insert: <p class="western">insert: </p>
insert: <h3>insert: <a name="AssignmentCriteria"> insert: </a> 2.0 Assignment Criteria insert: </h3>
insert: <p class="western">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 insert: <a href="ftp://ftp.ripe.net/rfc/rfc1930.txt"> RFC1930 insert: </a> . insert: </p>
insert: <p class="western">A network must be multihomed in order to qualify for the RIPE delete: <br /> database, an AS Number. insert: </p>
insert: <p class="western">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 well as reassignment used in the RIPE Database. insert: </p>
insert: <p class="western">The RIPE NCC will assign 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 “ insert: <a href="http://www.ripe.net/publications/docs/contract-req" data-linktype="external" data-val="http://www.ripe.net/publications/docs/contract-req"> Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region insert: </a> ”. insert: </p>
insert: <p class="western">insert: </p>
insert: <h3>insert: <strong> insert: <a name="Returning"> insert: </a> 3.0 Returning AS Numbers insert: </strong> insert: </h3>
insert: <p class="western">If an organisation no longer uses the AS Number, it should be returned to the public pool 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 /> 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 /> AS Numbers. The mission of the RIPE NCC is to give network numbers to the various delete: <br /> service providers and NICs. The NICs and NOCs RIPE NCC 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 AS Number Allocation Procedure delete: <br /> delete: <br /> Service providers to another organisation. insert: </p>
insert: <p class="western">insert: </p>
insert: <h3>insert: <strong> insert: <a name="Transferring"> insert: </a> 4.0 Transferring AS Numbers insert: </strong> insert: </h3>
insert: <p>The transfer of Internet number resources is governed by the RIPE Document, " insert: <a href="http://www.ripe.net/publications/docs/transfer-policies" data-val="http://www.ripe.net/publications/docs/transfer-policies" data-linktype="external"> RIPE Resource Transfer Policies insert: </a> ". insert: </p>
insert: <p>insert: </p>
insert: <h3>insert: <strong> insert: <a name="ASnumbers"> insert: </a> 5.0 32-bit AS Numbers insert: </strong> insert: </h3>
insert: <p>The RIPE NCC assigns 32-bit AS Numbers according to the following timeline: insert: </p>
insert: <ul>- insert: <li>
- From 1 January 2007 the RIPE NCC will process applications that specifically request 32-bit only AS Numbers (AS Numbers that 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 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 class B network number must be accompanied 32-bit only AS Number, the RIPE NCC will assign a 16-bit AS Number. insert: </li> insert: </ul>
- insert: <li>
- 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 delete: <br /> a justification 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. insert: </li> insert: </ul>
- insert: <li>
- 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. insert: </li> insert: </ul>
insert: <strong> insert: </strong> insert: </p>
insert: <h3>insert: <strong> insert: <a name="Registration"> insert: </a> 6.0 Registration insert: </strong> insert: </h3>
insert: <p>The RIPE NCC will register the resources issued in terms the RIPE Database. insert: </p>
insert: <p>insert: <strong> insert: </strong> insert: </p>
insert: <h3>insert: <strong> insert: <a name="References"> insert: </a> 7.0 References insert: </strong> insert: </h3>
insert: <p class="western">[RFC1771] "A Border Gateway Protocol 4 (BGP-4)" insert: <a href="http://www.ietf.org/rfc/rfc1771.txt"> http://www.ietf.org/rfc/rfc1771.txt insert: </a> insert: </p>
insert: <p class="western">[RFC1930] " Guidelines for creation, selection, and registration 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 an Autonomous System (AS)" insert: <a href="http://www.ietf.org/rfc/rfc1930.txt"> http://www.ietf.org/rfc/rfc1930.txt insert: </a> insert: </p>
insert: <p class="western">[RFC2026] "The Internet Registry, particularly the US NIC. delete: <br /> delete: <br /> delete: <br /> Class C Allocation Procedures 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 information about reassigned network numbers must be reported delete: <br /> back to the RIPE NCC in full RIPE database format (ref ripe-13). delete: <br /> The complete entries should be sent immediately after reassignment to delete: <br /> <[email protected]>. delete: <br /> The RIPE NCC is ready to accept block entries for the RIPE database. delete: <br /> For block syntax, please contact the RIPE NCC. 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. Standards Process -- Revision 3 IETF Experimental RFC insert: <a href="http://www.ietf.org/rfc/rfc2026.txt"> http://www.ietf.org/rfc/rfc2026.txt insert: </a> see Sec. 4.2.1 insert: </p>
insert: <p class="western">insert: </p>
insert: <h3>insert: <strong> insert: <a name="Attribution"> insert: </a> 8.0 Attribution insert: </strong> insert: </h3>
insert: <p class="western">This document can delete: <br /> be obtained is compiled from the rfc section of the RIPE document store or other RFC delete: <br /> servers. It is called rfc1338.txt. delete: <br /> policies developed by the RIPE community. insert: </p>
insert: <p class="western">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 following people actively contributed by making proposals 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 /> 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> the RIPE Policy Development Process: insert: </p>
insert: <p class="western">Nick Hilliard, Geoff Huston insert: </p>
insert: <p class=" ">insert: <strong> insert: </strong> insert: </p>
insert: <p class="western">insert: </p>
