You are here: Home > Publications > RIPE Document Store > IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region

Changes to IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region

Legend	(+) Added	(-) Deleted
Changed	Tag Added	Tag Deleted

ripe-730: IPv4 Address Allocation and Assignment Policies for the ripe-072: RIPE NCC Service Region Internet Numbers Registration Procedures

delete: <h2> insert: 

insert:  This documents obsoletes ripe-65, version 0.6 of this document insert:  insert:  
insert:  
Abstract delete: </h2> delete:  insert:  
insert:  
insert:  
This document describes the RIPE community's current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The procedures for the reassignment of IP insert:  
network numbers from blocks obtained from the RIPE Network Coordination insert:  
Centre. It deals with items as providing information for the RIPE insert:  
database, as well as reassignment of IP addresses in light of insert:  
the "Supernetting" proposal, as documented in RFC 1338, by Vince Fuller insert:  
et al. insert:  
insert:  
insert:  
Introduction insert:  
insert:  
insert:  
Since May 1st 1992, the RIPE Network Coordination Centre (RIPE NCC) facilitates (NCC) is insert:  
acting as a delegated registry for IP networks numbers to NICs and supports this process. These policies apply to the NOCs insert:  
in Europe. It is RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC policy not to give out network numbers to insert:  
individual organisations, who should refer in turn, to their IP network insert:  
service region. delete:  delete:  Information on the Address Policy WG is available at: delete:   delete: <a data-val="6a73933dbb6a4d9655588d6896c4c379" href="../../../resolveuid/6a73933dbb6a4d9655588d6896c4c379" data-linktype="internal"> https://www.ripe.net/participate/ripe/wg/ap delete: </a> delete:  delete: <h2> Contents delete: </h2> delete:  1.0 delete: <a class="anchor-link" title="" href="#1" target="_self"> Introduction delete: </a> delete:  delete:  1.1 delete: <a class="anchor-link" title="" href="#11" target="_self"> Scope delete: </a> delete:  delete:  2.0 delete: <a class="anchor-link" title="" href="#2" target="_self"> IPv4 Address Space delete: </a> delete:  delete:  3.0 delete: <a class="anchor-link" title="" href="#3" target="_self"> Goals of the Internet Registry System delete: </a> delete:  delete:  3.1 delete: <a class="anchor-link" title="" href="#31" target="_self"> Confidentiality delete: </a> delete:  delete:  3.2 delete: <a class="anchor-link" title="" href="#32" target="_self"> Language delete: </a> delete:  delete:  4.0 delete: <a class="anchor-link" title="" href="#4" target="_self"> Registration Requirements delete: </a> delete:  delete:  5.0 delete: <a class="anchor-link" title="" href="#5" target="_self"> Policies and Guidelines for Allocations delete: </a> delete:  delete:  5.1 delete: <a class="anchor-link" title="" href="#51" target="_self"> Allocations made by the RIPE NCC to LIRs delete:   delete: </a> delete:  delete:  5.1bis delete: <a href="#51bis" data-linktype="anchor" data-val="9"> Allocations made by the RIPE NCC to LIRs when using a Waiting List delete: </a> delete:  delete:  5.2 delete: <a class="anchor-link" title="" href="#52" target="_self"> Unforeseen circumstances delete: </a> delete:  delete:  5.3 delete: <a class="anchor-link" title="" href="#53" target="_self"> Address Recycling delete: </a> delete:  delete:  5.4 delete: <a class="anchor-link" title="" href="#54" target="_self"> Sub-allocations delete: </a> delete:  delete:  5.5 delete: <a class="anchor-link" title="" href="#55" target="_self"> Transfers of Allocations delete: </a> delete:  delete:  6.0 delete: <a class="anchor-link" title="" href="#6" target="_self"> Policies and Guidelines for Assignments delete: </a> delete:  delete:  6.1 delete: <a class="anchor-link" title="" href="#61" target="_self"> Assignments to Internet Exchange Points delete: </a> delete:  delete:  6.2 delete: <a class="anchor-link" title="" href="#62" target="_self"> Network Infrastructure and End User Networks delete: </a> delete:  delete:  6.3 delete: <a class="anchor-link" title="" href="#63" target="_self"> Validity of an Assignment delete: </a> delete:  delete:  6.4 delete: <a class="anchor-link" title="" href="#64" target="_self"> Transfers of PI space delete: </a> delete:  delete:  7.0 delete: <a class="anchor-link" title="" href="#7" target="_self"> Types of Address Space delete: </a> delete:  delete:  8.0 delete: <a class="anchor-link" title="" href="#8" target="_self"> LIR Audit delete: </a> delete:  delete:  9.0 delete: <a class="anchor-link" title="" href="#9" target="_self"> Closing an LIR by the RIPE NCC delete: </a> delete:  delete: <h2> delete: <a name="1"> delete: </a> 1.0 Introduction delete: </h2> delete:  The provider. insert:  
insert:  
The mission of the RIPE NCC is an independent association to give network numbers to the various insert:  
service providers and serves as one of five Regional NICs. The NICs and NOCs can then reassign the insert:  
actual IP network numbers to organisations requesting IP network insert:  
numbers. insert:  
insert:  
insert:  
Class B Network Number Allocation Procedure insert:  
insert:  
Service providers can request Class B network numbers on a one-by-one insert:  
basis from the RIPE NCC. Because class B address space is a critical insert:  
resource, a request for a class B network number must be accompanied by insert:  
a justification in terms of the requesting organisation's size, current insert:  
network and expected network growth. The requestor should also make insert:  
clear why they cannot use a block of class C network numbers to achieve insert:  
their goals. The RIPE NCC will review requests using the same standards insert:  
as any other Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Registry, particularly the US NIC. insert:  
insert:  
insert:  
Class C Allocation Procedures insert:  
insert:  
NICs and Central Asia. NOCs accepting a block of class C numbers agree to adhere to insert:  
the following procedures: insert:  
insert:  
A) The RIPE NCC will assign complete class C blocks to individual NICs insert:  
and NOCs. They can be requested from <[email protected]>. insert:  
insert:  
B) In order to prevent implementation problems, network numbers ending insert:  
with 0 or 255 should NOT be reassigned. insert:  
insert:  
C) Full information about reassigned network numbers must be reported insert:  
back to the RIPE NCC in full RIPE database format (ref ripe-13). insert:  
The complete entries should be sent immediately after reassignment to insert:  
<[email protected]>. insert:  
The RIPE NCC is responsible for the allocation ready to accept block entries for the RIPE database. insert:  
For block syntax, please contact the RIPE NCC. insert:  
insert:  
D) Reassignment of class C network numbers should be done in a manner insert:  
that facilitates Supernetting (see next section). insert:  
insert:  
E) Requests for network numbers should be reasonable. All NICs and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) NOCs insert:  
should prevent stockpiling of network numbers. insert:  
insert:  
F) On first request from the RIPE NCC, the class C network numbers not insert:  
yet reassigned, must be returned to the RIPE NCC. insert:  
insert:  
insert:  
Supernetting insert:  
insert:  
NICs and the management of reverse domain names within this region. The distribution of NOCs reassigning IP space follows the hierarchical scheme described in the document " delete: <a data-linktype="internal" target="_self" title="" href="resolveuid/24c9d290050ce09f71440263ed95a927" data-val="24c9d290050ce09f71440263ed95a927" class="internal-link"> Internet Registry System delete: </a> ". delete:  delete: <h3 class="western"> delete: <a name="11"> delete: </a> 1.1 Scope delete: </h3> delete:  network numbers are urgently requested to insert:  
read the Supernetting proposal by Vince Fuller et al. This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. can insert:  
be obtained from the rfc section of the RIPE document store or other RFC insert:  
servers. It is called rfc1338.txt. insert:  
The Supernetting proposal was made to reduce the increase of routing insert:  
table size in the current Internet. It proposes to create a hierarchy insert:  
of IP network numbers, which can then be aggregated resulting in less insert:  
routing table entries in routing equipment. While this proposal has not insert:  
been formally adopted we expect that something at least along the same insert:  
principle will be implemented in the near future. insert:  
insert:  
Here is how it works: insert:  
insert:  
If an organisation A needs 8 class C network numbers, the numbers should insert:  
be given out in such a way that the routing information for each of insert:  
these 8 networks could appear as one entry with the correct mask in insert:  
routers. insert:  
insert:  
More concretely: insert:  
insert:  
Service provider S hands out networks 192.24.8 through 192.24.15 to insert:  
organisation A. These policies must be implemented by all RIPE NCC member LIRs. delete:  delete:  networks can then appear in routing equipment as a insert:  
supernet route to 192.24.8 with mask 255.255.248.0. This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community's policies for ASN assignment and IPv6 are published in the RIPE Document Store at: delete:   delete: <a href="http://www.ripe.net/ripe-policies" data-linktype="external" data-val="http://www.ripe.net/ripe-policies"> https://www.ripe.net/ripe-policies delete: </a> delete:  delete: <h2> delete: <a name="2"> delete: </a> 2.0 IPv4 Address Space delete: </h2> delete:  For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses: delete:  delete: <ol> delete: <li> delete:  Public IP addresses are distributed to be globally unique according to the goals described in Section 3 of this document. The two types of IPv4 address described in this documents are Provider Aggregatable (PA) and Provider Independent (PI). delete:  delete: </li> delete: <li> delete:  Some address ranges are set aside for the operation of private IP networks. Anyone way 8 class C insert:  
network numbers appear as one routing table entry. insert:  
insert:  
The guidelines that can be derived from the Supernetting proposal are: insert:  
insert:  
A) Service providers should reserve blocks of class C network numbers from insert:  
their allocation for each organisations requesting class C network numbers. insert:  
insert:  
B) The size of these blocks should always be a power of 2. insert:  
insert:  
C) The numbers in these blocks should be contiguous. insert:  
insert:  
D) The blocks should start on bit boundaries. insert:  
(ie powers of 2, AND multiples of the block size) insert:  
insert:  
E) The blocks reserved for an organisation should be sufficient for a insert:  
reasonable expected growth over the next few years. insert:  
insert:  
F) Multi-homed organizations may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used. delete:   For a detailed description of “Address Allocation for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at: delete: <a href="ftp://ftp.ripe.net/rfc/rfc1918.txt"> ftp://ftp.ripe.net/rfc/rfc1918.txt delete: </a> delete:   For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at: delete: <a href="ftp://ftp.ripe.net/rfc/rfc2993.txt"> ftp://ftp.ripe.net/rfc/rfc2993.txt delete: </a> delete:  delete: </li> delete: <li> delete:  Some address ranges are reserved for special use purposes. These are described in the delete: <a href="https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"> IANA IPv4 Special-Purpose Address Registry delete: </a> and are beyond the scope of this document. delete:  delete: </li> delete: </ol> delete: <h2> delete: <a name="3"> delete: </a> 3.0 Goals of the Internet Registry System delete: </h2> delete:  Public IPv4 address assignments should be made with the following goals in mind: delete:  delete: <ol> delete: <li> delete:  Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified. delete:  delete: </li> delete: <li> delete:  Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing. delete:  delete: </li> delete: <li> delete:  Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks. delete:  delete: </li> delete: <li> delete:  Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. delete:  delete: </li> delete: </ol> delete: <h3 class="western"> delete: <a name="31"> delete: </a> 3.1 Confidentiality delete: </h3> delete:  Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality. delete:  delete: <h3 class="western"> delete: <a name="32"> delete: </a> 3.2 Language delete: </h3> delete:  Please note that all communication with the RIPE NCC must be in English. delete:  delete: <h2> delete: <a name="4"> delete: </a> 4.0 Registration Requirements delete: </h2> delete:  All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. delete:   delete:   Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained). delete:  delete: <h2> delete: <a name="5"> delete: </a> 5.0 Policies and Guidelines for Allocations delete: </h2> delete:  An allocation is a block of IPv4 addresses from which assignments are taken. delete:  delete:  All LIRs receiving obtain address space from one of their insert:  
providers, the RIPE NCC, or the global NIC, as is appropriate to their insert:  
network configuration. These organisations are strongly encouraged to insert:  
contact the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document. delete:  delete: <h3> delete: <a name="51"> delete: </a> 5.1 Allocations made by the RIPE NCC to LIRs delete: </h3> delete:  Details of how to join the RIPE NCC can be found in the RIPE Document " delete: <a data-val="1debfd86d3d2ea24a7ce6695202c44f0" href="resolveuid/1debfd86d3d2ea24a7ce6695202c44f0" data-linktype="internal"> Procedure for Becoming a Member of the RIPE NCC delete: </a> " delete:  delete:  On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: delete:  delete: <ol> delete: <li> delete:  The size of the allocation made will be exactly one /22. delete:  delete: </li> delete: <li> delete:  The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). delete:  delete: </li> delete: <li> delete:  The LIR must confirm it will make assignment(s) from the allocation. delete:  delete: </li> delete: </ol> delete:  Once an equivalent of a /22 can no longer be allocated, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve waiting list. At that point in time the contents of section 5.1 of this policy document will be automatically replaced with the contents of section 5.1bis and section 5.1bis will be deleted from this policy document. delete:  delete: <h3> delete: <a id="51bis"> delete: </a> 5.1bis Allocations made by the RIPE NCC to LIRs when using a Waiting List delete: </h3> delete:  On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: delete:  delete: <ol> delete: <li> All allocation requests are placed on a first-come-first-served waiting list. No guarantees are given about the waiting time. delete: </li> delete: </ol> delete: <ol start="2"> delete: <li> The size of the allocation made will be exactly one /24. delete: </li> delete: </ol> delete: <ol start="3"> delete: <li> The sum of all allocations made to a single LIR by the RIPE NCC is limited to a maximum of 256 IPv4 addresses (a single /24). for guidance. insert:  
insert:  
insert:  
insert:  
If this allocation limit has been reached or exceeded, an LIR cannot request an IPv4 allocation under this policy. delete: </li> delete: </ol> delete:  In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous /24 allocations again. delete:  delete: <h3> delete: <a name="52"> delete: </a> 5.2 Unforeseen circumstances delete: </h3> delete:  A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. delete:  delete:  In the event that this /16 remains unused at the time the remaining addresses covered by this policy you have been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document. delete:  delete: <h3> delete: <a name="53"> delete: </a> 5.3 Address Recycling delete: </h3> delete:  Any IPv4 address space that was originally assigned by the RIPE NCC for exclusive use by Internet Exchange Points (IXPs) will be added to the reserved IXP pool upon return. delete:  delete:  Other address space blocks of a /24 or larger that are returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1 – smaller blocks will be put into the reserved pool for IXP use. delete:  delete:  This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. delete:  delete: <h3> delete: <a name="54"> delete: </a> 5.4 Sub-allocations delete: </h3> delete:  Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0. delete:  delete:  LIRs wishing to convert their allocations to PA status must contact the RIPE NCC by email at delete: <a href="mailto:[email protected]"> [email protected] delete: </a> . delete:  delete:  LIRs may make sub-allocations to multiple downstream network operators. delete:  delete:  The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations. delete:  delete:  Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator. delete:  delete: <h3> delete: <a name="55"> delete: </a> 5.5 Transfers of Allocations delete: </h3> delete:  The transfer of Internet number resources is governed by the RIPE Document, " delete: <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 delete: </a> ". delete:  delete:  delete:  delete: <h2> delete: <a name="6"> delete: </a> 6.0 Policies and Guidelines for Assignments delete: </h2> delete: <h3> delete: <a name="61"> delete: </a> 6.1. Assignments to Internet Exchange Points delete: </h3> delete:  A /15 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive a single number resource block according to the following: delete:  delete: <ol> delete: <li> Organisations receiving space under this policy must be IXPs and must meet the definition as described in section two of the RIPE Document " delete: <a href="http://www.ripe.net/publications/docs/ipv6-policy-ixp"> IPv6 Address Space for Internet Exchange Points delete: </a> ". delete: </li> delete: <li> This space will be used to run an IXP peering LAN only; other uses are forbidden. delete: </li> delete: <li> Assignments will only be made to IXPs that have applied for an IPv6 assignment for their peering LAN (or have already received one). delete: </li> delete: <li> New IXPs will be assigned a /24 by default. Once they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement up to maximum of a /22. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined. On request or once there are no more assignments of /24 (or larger) available, assignments can be made down to /27. delete: </li> delete: <li> IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), and any IPv4 space assigned from this pool that is no longer in use, must be returned to the pool within 180 days of disuse or a new assignment. delete: </li> delete: </ol> delete: <h3> delete: <a name="62"> delete: </a> 6.2 Network Infrastructure and End User Networks delete: </h3> delete:  IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses questions concerning this, please do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. hesitate to insert:  
call or mail us at [email protected].

delete:  An explanation of how to register objects in the database can be found in the "RIPE Database User Manual: Getting Started" found at: delete:   delete: <a href="https://apps.db.ripe.net/docs/" data-val="https://apps.db.ripe.net/docs/" data-linktype="external"> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation delete: </a> delete:  delete: <h3> delete: <a style="font-size: 1.6em;" name="63"> delete: </a> 6.3 Validity of an Assignment delete: </h3> delete:  An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database. Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid. An assignment that was based on information that turns out to be incorrect is no longer valid. delete:  delete: <h3 class="western"> delete: <a name="64"> delete: </a> 6.4 Transfers of PI space delete: </h3> delete:  The transfer of Internet number resources is governed by the RIPE Document, " delete: <a href="http://www.ripe.net/publications/docs/transfer-policies" data-linktype="external" data-val="http://www.ripe.net/publications/docs/transfer-policies"> RIPE Resource Transfer Policies delete: </a> ". delete:  delete:  delete:  delete: <h2> delete: <a name="7"> delete: </a> 7.0 Types of Address Space delete: </h2> delete:  LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. delete:  delete:  Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning: delete:  delete:  delete:  Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses. delete:  delete:  delete:  LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are: delete:  delete: <ul> delete: <li> delete:  ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider. delete:  delete: </li> delete: <li> delete:  ALLOCATED UNSPECIFIED: This address space has been allocated to the RIPE NCC or other RIRs for further distribution. If the address space is administered by the RIPE NCC, more specific objects with other values may exist. delete:  delete: </li> delete: <li> delete:  SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider. delete:  delete: </li> delete: <li> delete:  LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific delete:  inetnum delete:  must be registered. delete:  delete: </li> delete: <li> delete:  LEGACY: This indicates the Internet number resource was obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries. delete:  delete: </li> delete: <li> delete:  ASSIGNED PA: This address space has been assigned to the issuing LIR infrastructure or an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. delete:  delete: </li> delete: <li> delete:  ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties. delete:  delete: </li> delete: <li> delete:  ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services. delete:  delete: </li> delete: </ul> delete:  The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status. delete:  delete:  Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate. delete:  delete:  In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses. delete:  delete:  The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1. delete:  delete: <h2> delete: <a name="8"> delete: </a> 8.0 LIR Audit delete: </h2> delete:  The RIPE community asked the RIPE NCC to audit LIR operations and ensure consistent and fair implementation of the community's policies. Details of this activity are described in the RIPE Document "RIPE NCC Audit Activity" found at: delete: <a href="http://www.ripe.net/ripe/docs/audit"> http://www.ripe.net/ripe/docs/audit delete: </a> delete:  delete: <h2> delete: <a name="9"> delete: </a> 9.0 Closing an LIR by the RIPE NCC delete: </h2> delete:  The RIPE NCC may close an LIR for any of the following reasons: delete:  delete: <ul> delete: <li> delete:  the LIR does not pay money owed to the RIPE NCC delete:  delete: </li> delete: <li> delete:  the LIR cannot be contacted by the RIPE NCC for a significant period of time delete:  delete: </li> delete: <li> delete:  the LIR consistently violates the RIPE community's policies delete:  delete: </li> delete: </ul> delete:  The RIPE NCC takes on responsibility for address space held by closing LIRs. delete: 

IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Internet Numbers Registration Procedures