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

   Mirjam Khne
   Paul Rendek
   Sabrina Wilmot
   Leo Vegoda

   Document ID: ripe-288
   Date: 28 October 2003
   Obsoletes: ripe-104, ripe-105, ripe-127, ripe-136, ripe-140, ripe-159,
   ripe-185, ripe-234
     ___________________________________________________________________

Abstract

   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 RIPE Network
   Coordination Centre (RIPE NCC) facilitates and supports this
   process. These policies apply to the RIPE NCC and the Local
   Internet Registries (LIRs) within the RIPE NCC service region.

   Information on the Address Policy WG is available at:

     http://www.ripe.net/ripe/wg/address-policy/index.html
     ___________________________________________________________________

Table of Contents

   1.0 Introduction

     1.1 Scope

   2.0 IPv4 Address Space 3.0 Goals of the Internet Registry System

     3.1 Confidentiality
     3.2 Language

   4.0 Registration Requirements 
   5.0 Policies and Guidelines for Allocations

     5.1 First Allocation
     5.2 Slow-start Mechanism 5.3 Additional Allocations
     5.4 Sub-allocations

   6.0 Policies and Guidelines for Assignments

     6.1 Documentation for Assignments
     6.2 Network Infrastructure and End User Networks
     6.3 Utilisation Rates
     6.4 Reservations Not Supported
     6.5 Administrative Ease
     6.6 Validity of an Assignment
     6.7 Efficiency
     6.8 Renumbering
   
  7.0 Assignment Window 
  
  8.0 Assignments for Internetworking
     Experiments 
  
  9.0 PA vs. PI Address Space 
  
  10.0 Record Keeping 
 
  11.0 LIR Audit 
 
  12.0 Closing an LIR by the RIPE NCC
     ___________________________________________________________________
     
1.0 Introduction

   The RIPE NCC is an independent association and serves as one of
   four Regional Internet Registries (RIRs). Its service region
   incorporates Europe, the Middle East, Central Asia and African
   countries located north of the equator. The RIPE NCC is responsible
   for the allocation and assignment of Internet Protocol (IP) address
   space, Autonomous System Numbers (ASNs) and the management of
   reverse domain names within this region. The distribution of IP
   address space follows the hierarchical scheme described in the
   document "Internet Registry System" available from the RIPE NCC web
   site at:
   
     http://www.ripe.net/ripencc/about/regional/rir-system.html

1.1 Scope

   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. These
   policies must be implemented by all RIPE NCC member LIRs.


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:
     
     http://www.ripe.net/ripe/docs/internet-registries.html#policy

2.0 IPv4 Address Space
   
   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: 

1. Public IP addresses are assigned to be globally unique according to
   the goals described in Section 3 of this document.

2. Some address ranges are set aside for the operation of private IP
   networks. Anyone 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.  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:
     
     ftp://ftp.ripe.net/rfc/rfc1918.txt 

   For information on the "Architectural Implications of NAT", please
   refer to RFC 2993, found at:
     
     ftp://ftp.ripe.net/rfc/rfc2993.txt 

3.  Some address ranges are reserved for special use purposes. These
    are described in RFC 3330 and are beyond the scope of this
    document. RFC 3330 can be found at:
   
     ftp://ftp.ripe.net/rfc/rfc3330.txt
   
3.0 Goals of the Internet Registry System
   
   Public IPv4 address assignments should be made with the following
   goals in mind:
   
   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.

   Aggregation: Distributing IPv4 addresses in an hierarchical manner
   permits the aggregation of routing information. This helps to
   ensure proper operation of Internet routing.
   
   Conservation: Public IPv4 address space must be fairly distributed
   to the End Users operating networks. To maximise the lifetime of
   the public IPv4 address space, addresses must be distributed
   according to need, and stockpiling must be prevented.
   
   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.

3.1 Confidentiality
   
   Internet Registries (IRs) have a duty of confidentiality to their
   registrants. Information passed to an IR must be securely stored
   and should 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.
     
3.2 Language

   Please note that all communication with the RIPE NCC must be in
   English.
   
4.0 Registration Requirements
   
   All assignments and allocations must be registered in the RIPE
   Database.  This is necessary to ensure uniqueness and to support
   network operations.
     
   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).
    
5.0 Policies and Guidelines for Allocations
       
   An allocation is a block of IPv4 addresses from which assignments
   are taken.
   
   All LIRs receiving address space from 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.
   
   If an LIR is planning to exchange or transfer address space it
   needs to contact the RIPE NCC so that the changes can be properly
   registered.  Please note that the LIR always remains responsible
   for the entire allocation it receives from the RIPE NCC until the
   allocation is transferred to another LIR or returned. The LIR must
   ensure that all policies are applied.
   
5.1 First Allocation
   
   The RIPE NCC's minimum allocation size is /20.  In order to receive
   an initial allocation an LIR must demonstrate an existing efficient
   utilisation of at least a /22, or need for immediate, efficient
   utilisation of at least a /22 of address space. When justification
   is based on a combination of immediate need and existing usage the
   existing assignments must be renumbered into the LIR's new
   allocation. In both cases, the address space needs of the LIR's own
   infrastructure and End Users connecting to the LIR are considered.

   Verification of previous efficient utilisation is based on the
   sub-allocations and assignments registered in the RIPE
   Database. Only assignments registered in the RIPE Database are
   considered valid.
   
   Details of how to join the RIPE NCC can be found in the RIPE
   document "Procedure for Becoming a Member of the RIPE NCC" found
   at:
   
     http://www.ripe.net/ripe/docs/new-lir.html

5.2 Slow-start Mechanism
   
   The slow-start mechanism was put into place to ensure a consistent
   and fair policy for all LIRs with respect to allocations.
   
   Address space is allocated to LIRs at the rate that the addresses
   are sub-allocated and assigned by the LIRs. An allocation larger
   than the minimum size can be made if a need is demonstrated. The
   size of future allocations is based on the usage rate of previous
   allocation(s).
   
5.3 Additional Allocations
   
   An LIR may receive an additional allocation when about eighty
   percent (80%) of all the address space currently allocated to it is
   used in valid assignments or sub-allocations. A new allocation can
   be made if a single assignment or sub-allocation requires a larger
   set of addresses than can be satisfied with the address space
   currently held by the LIR.
   
   Reservations are not considered valid assignments or
   sub-allocations. It may be useful for internal aggregation to keep
   some address space free for future growth in addition to the actual
   assignment. However, the LIR must be aware that these internal
   reservations are not counted as valid usage. The space must be
   sub-allocated or assigned before the LIR can request another
   allocation.
   
   To obtain a new allocation, an LIR should submit a request to the
   RIPE NCC using the "IPv4 Additional Allocation Request Form"
   available from the RIPE Document Store at:
   
     http://www.ripe.net/ripe/docs/add-allocation.html
   
   Additional address space will only be allocated after the
   information supplied with the request has been verified and a new
   allocation deemed necessary.  The RIPE NCC will do its best to
   allocate contiguous address space in order to support
   aggregation. This cannot be guaranteed as it depends on factors
   outside the RIPE NCC's influence (e.g. the number of new LIRs and
   the time needed to utilise the allocation).
   
5.4 Sub-allocations
   
   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 9.0.
   
   LIRs wishing to convert their allocations to PA status should
   contact the RIPE NCC via e-mail at <lir-help@ripe.net>.

   The minimum size of a sub-allocation is /24. This is the smallest
   prefix length that can be reverse delegated and allows for a
   reasonable number of small assignments to be made by a downstream
   network operator.
   
   An LIR may sub-allocate IPv4 address space up to 400% of its Assignment
   Window (AW) to an organisation every twelve months. Thus, an LIR
   with an AW of /26 may make a /24 sub-allocation. LIRs with an AW
   smaller than /26 may not make sub-allocations as the minimum
   sub-allocation size is /24. The AW policy is described in Section
   7.0.
   
   LIRs may make sub-allocations to multiple downstream network
   operators.
   
   Downstream network operators efficiently using a /22 sub-allocation
   qualify to receive a /20 PA allocation from the RIPE NCC if they
   decide to become an LIR themselves.
   
   The maximum size of a sub-allocation is /20 even if this is less
   than 400% of the LIR's AW. For example, an LIR with a /21 AW may
   not sub-allocate a /19 to a downstream network. However, downstream
   network operators may receive sub-allocations totalling more than a
   /20 from more than one LIR.
   
   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.
   
   The RIPE NCC considers sub-allocated space as "used" when
   evaluating requests from the LIR for an additional IPv4
   allocation. LIRs are still required to demonstrate about 80% usage
   for all their allocations. Where an LIR has made many
   sub-allocations with little assigned within them, the RIPE NCC will
   ask the LIR to justify the reasons for the sub-allocations.  LIRs
   should note that evaluating a request for an allocation is
   different from evaluating a request for an assignment. With
   assignments, the evaluator can see the network plans for a single
   organisation. With allocations, the evaluator is often presented
   with sales and marketing plans. The addressing requirements of
   individual organisations cannot be examined.
   
   It is recommended that LIRs make use of a slow-start mechanism when
   making a sub-allocation for a downstream network operator. There
   are two main advantages to this: the LIR can ensure that the
   address space it sub-allocates is used efficiently; also the LIR
   can determine the ability of the downstream organisation to operate
   within the policies set by the RIPE community.
   
   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 reseller 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.
   
6.0 Policies and Guidelines for Assignments
   
   Conservation and aggregation are often conflicting goals. When the
   Internet Registry System goals are in conflict with the interests
   of individual End Users or service providers, careful analysis and
   judgement is necessary to find an appropriate compromise. The rules
   and guidelines in this document are intended to help LIRs and End
   Users in their search for equitable compromises.
   
   Please note that LIRs must request approval from the RIPE NCC for
   assignments that are larger than the LIR's AW (Section 7.0). LIRs
   are always welcome to approach the RIPE NCC for a second opinion on
   requests even if they fall within the LIR's AW.
   
6.1 Documentation for Assignments
   
   In order to determine the address space requirements for a network,
   relevant information must be gathered. The details needed for
   justification of each End User organisation's assignments include
   the addressing requirements, network infrastructure and future
   plans. The current address space usage of the organisation should
   also be determined to ensure that an existing assignment is not
   duplicated.
   
   This information is essential in making the appropriate assignment
   decisions. Balancing the overall goals of the Internet Registry
   System (Section 3.0) with the requirements of the network in
   question is needed for every network. The level of detail is
   dependent on the complexity of the network. The LIR must ensure
   that the necessary information is complete before making an
   assignment.  The RIPE NCC provides forms for gathering the required
   information. The information requested in the forms must be
   collected by the LIR. LIRs may use these forms for their customers'
   requests or develop their own forms. Local forms can be used if
   they record all the required data.  This is very important when an
   LIR makes assignments using its AW.
   
   If a request needs to be approved by the RIPE NCC or if information
   is required in the event of an audit, the information must be
   submitted on the version of the request form in place at the time
   of the assignment.  The current versions of all request forms can
   be found at:
   
     http://www.ripe.net/ripe/docs/internet-registries.html#request
   
6.2 Network Infrastructure and End User Networks
   
   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 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 User's.
   
   An explanation of how to register objects in the database can be
   found in the "RIPE Database User Manual: Getting Started" found at:
   
     http://www.ripe.net/ripe/docs/db-start.html
   
6.3 Utilisation Rates
   
   Assignments' immediate utilisation should be at least 25% of the
   assigned space. After one year, this should be at least 50% of the
   space unless special circumstances are defined. Assignments may
   only be based on realistic expectations recorded in the
   documentation.

6.4 Reservations Not Supported
   
   End Users are not permitted to reserve address space based on
   long-term plans. This violates the goal of conservation and
   fragments the address space when initial forecasts are not
   met. Evaluation of IP address space requests must be based on a
   demonstrated need. Unused, or inefficiently used address space
   assigned in the past should be used to meet the current request, or
   returned. Once an organisation has used its assigned address space,
   it can request additional address space based on an updated
   estimate of growth in its network.
   
6.5 Administrative Ease
   
   The current rate of consumption of the remaining unassigned IPv4
   address space does not permit the assignment of addresses for
   administrative ease. Examples of this include, but are not limited
   to, ease of billing administration and network management.
   
6.6 Validity of an Assignment
   
   All assignments are valid as long as the original criteria on which
   the assignment was based are still valid and the assignment is
   properly registered in the RIPE Database. If an assignment is made
   for a specific purpose and that purpose no longer exists, the
   assignment is no longer valid. If an assignment is based on
   information that turns out to be invalid, the assignment is no
   longer valid.
     
   For these reasons it is important that LIRs make sure that
   assignments approved by the RIPE NCC are properly registered in the
   database. The inetnum object or objects for approved assignments
   must use the netname(s) approved by the RIPE NCC and not be larger
   than the approved size. Additionally, the date in the first
   "changed:" attribute must not be earlier than the date of the
   approval message from the RIPE NCC.
   
   The RIPE NCC reviews assignments made by LIRs when evaluating
   requests for additional allocations (see 5.3). It also runs
   consistency checks as part of the auditing activity requested by
   the community as described in the RIPE document "RIPE NCC
   Consistency and Auditing Activity" found at:
   
     http://www.ripe.net/ripe/docs/audit.html
   
6.7 Efficiency
   
   Where large amounts of address space are assigned for a purpose
   that is often satisfied with smaller amounts (e.g. transient
   connections or virtual server hosting), the RIPE NCC may verify the
   existing usage before approving additional assignments.
   
6.8 Renumbering
   
   In general, addresses can be replaced on a one-to-one basis. Valid
   assignments can be replaced with the same number of addresses if
   the original assignment criteria are still met. The addresses to be
   replaced must still be in use. End Users are required to submit a
   new request if more than half the original assignment is not in
   use. When the renumbering request exceeds the new LIR's AW (see
   Section 7.0) the request needs to be sent to the RIPE NCC for
   approval.
   
   The RIPE community generally accepts that a period of three months
   is enough time to migrate a network to new address space. Where the
   End User wants to keep both assignments for more than three months,
   an agreement should be obtained from the RIPE NCC for the proposed
   time frame.

   Once a network has been renumbered, the old assignment must be
   removed from the RIPE Database.  7.0 Assignment Window
   
   An AW refers to the maximum number of addresses that can be
   assigned by the LIR without prior approval from the RIPE NCC,
   either to their own network or to an End User's network. The size
   of the AW is expressed in CIDR notation.
   
   The AW policy was developed to achieve various levels of support
   based on the level of experience of the LIR. The RIPE NCC may
   review assignments made with the LIR's AW to ensure that the LIR is
   assigning address space according to the RIPE community's
   policies. This is important to assure the fair distribution of
   address space and to meet the goals of aggregation, conservation
   and registration. Documentation for assignments made with an AW
   need to contain the same information as in a completed request form
   found at:
   
     http://www.ripe.net/ripe/docs/internet-registries.html#request
   
   All new LIRs start with an AW of zero (0). This means that every
   assignment requires prior approval from the RIPE NCC.
   
   The AW is applied differently depending on whether the assignment
   is for an End User or for the LIR's infrastructure.
   
   There is no constraint on how often the LIR uses its AW for its own
   infrastructure. These assignments may not exceed the LIR's AW. This
   means that an LIR with a /25 AW can make numerous individual /25
   assignments to its own network infrastructure without having to
   send each request to the RIPE NCC. However, where a single
   assignment would exceed a /25 the LIR would need to request
   approval for that assignment from the RIPE NCC.
   
   LIRs must specify which assignments to their own infrastructure
   have used the AW. Such assignments must have a "remarks:" attribute
   with the value <INFRA-AW> in the inetnum object registered in the
   RIPE Database.  It is important that a separate "remarks:"
   attribute is used solely for this purpose.
   
   An AW can be applied to an End User network once per 12-month
   period.  This means an LIR can make more than one assignment to an
   End User in any 12 month period but the total amount of address
   space cannot be larger than the LIR's AW. An LIR's AW is refreshed
   on the anniversary of an assignment. When an LIR has made several
   assignments to an organisation over the period of a year their AW
   for that organisation will be fully restored on the anniversary of
   the last assignment. The LIR may only assign additional addresses
   to the same End User after approval from the RIPE NCC.
   
   AWs are regularly reviewed by the RIPE NCC Hostmasters. LIRs may
   approach the RIPE NCC for an evaluation of its AW at any
   time. Please note that LIRs are always welcome to approach the RIPE
   NCC for a second opinion on requests even if they fall within the
   LIR's AW.

   As the proficiency of the LIR contacts increases, the size of their
   AW may be raised. This is determined based on: 

   * correctly completed documentation presented to the RIPE NCC

   * good judgement shown in the evaluation of address space requests

   * past assignments have been properly registered
   
   An established LIR is responsible for training its new LIR contacts
   to handle address space assignments according to the policies
   described in this document and their procedures. Less experienced
   LIR contacts may make errors both in judgement and procedure. If
   errors happen repeatedly, the AW of the LIR may be decreased to
   prevent the LIR from making invalid assignments. The AW may again
   be increased based on the criteria stated above.
   
   The AW may also be lowered after or during an audit if invalid
   assignments are noted.
   
   Information on training courses and training material can be found
   at:
   
     http://www.ripe.net/training/
   
8.0 Assignments for Internetworking Experiments
   
   Organisations often require deployment tests for new Internet
   services and technologies. These require numbering resources for
   the duration of the test. The policy goal of resource conservation
   is of reduced importance when resources are issued on a temporary
   basis.
   
   An organisation receiving numbering resources must document the
   experiment. This may be in the form of a current IETF Experimental
   RFC (http://www.ietf.org/rfc/rfc2026.txt Sec. 4.2.1) or an
   "experiment proposal" detailing the resources required and the
   activities to be carried out.
   
   The assignment size will be equal to the existing minimum
   allocation size on the date the request is received. Where the
   experiment requires a variation to this rule it should be noted in
   the resource request.
   
   The experiment proposal must be made public (e.g. published on web
   site), upon registration of the resources by the RIPE
   NCC. Following the conclusion of the experiment the results must be
   published free of charge and free from disclosure constraints.
   
   Resources issued must not be used for commercial purposes during or
   following the conclusion of the experiment.
   
   The resources will be issued on a temporary basis for a period of
   one year. Renewal of the resource's registration is possible on
   receipt of a new request that details continuation of the
   experiment during the extended period.  The RIPE NCC will register
   the resources issued in the RIPE Whois Database.
   
   The request must be made by an LIR using the appropriate request
   form.  Details of the experiment should be noted in the form found
   at:
     
     http://www.ripe.net/ripe/docs/internet-registries.html#request
   
9.0 PA vs. PI Address Space
   
   LIRs are allocated 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 will have to be
   returned and the network renumbered.
   
   In contrast, PI address space cannot be aggregated. It can remain
   assigned to a network as long as the criteria for the original
   assignment are met. However, PI addresses are expensive to route as
   no use of aggregation can be made. They might not be globally
   routable.
     
   The use of PA address space should always be recommended.

   LIRs must make it clear to End Users which type of address space is
   assigned. Clear contractual arrangements are recommended and are
   mandatory for PA space. 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.
   
   End Users requesting PA space should be given this or a similar
   warning:
   
     Assignment of this IP address 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 address space if you
     continue to require global uniqueness of those addresses.
   
   End Users requesting PI space should be given this or a similar
   warning:
   
     Assignment of this IP address space is valid as long as the
     criteria for the original assignment are still met. However,
     assignment of address space does NOT imply that this address
     space will be ROUTABLE ON ANY PART OF THE INTERNET. It is
     expected that users will have to pay a premium for actual routing
     of PI addresses as opposed to PA addresses. It may eventually
     become impossible to get relatively small amounts of PI space
     routed on most of the Internet. We strongly suggest you contact
     any prospective service provider for information about issues
     related to service when using PI addresses.
   
   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:
     
   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.
   
   ALLOCATED PI: This address space has been allocated to an LIR or
   RIR and all assignments made from it are portable. Assignments can
   be kept as long as the criteria for the original assignment are
   met.  Sub-allocations cannot be made from this type of address
   space.
   
   ALLOCATED UNSPECIFIED: This address space has been allocated to an
   LIR or RIR. Assignments may be PA or PI. This status is intended to
   document past allocations where assignments of both types exist. It
   is avoided for new allocations. Sub-allocations cannot be made from
   this type of address space.
     
   SUB-ALLOCATED PA: This address space has been sub-allocated by an
   LIR to a 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.
   
   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 inetnum should
   be registered.
   
   LIR-PARTITIONED PI: 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 inetnum should
   be registered.
     
   EARLY-REGISTRATION: This is used by the RIPE Database
   administration when transferring pre-RIR registrations from the
   ARIN Database. The value can be changed by database users. Only the
   RIPE Database administrators can create objects with this value.
   
   NOT-SET: This indicates that the registration was made before the
   "status:" attributes became mandatory for inetnum objects. The
   object has not been updated since then. New objects cannot be
   created with this value. The value can be changed by database
   users.
     
   ASSIGNED PA: This address space has been assigned to an End User
   for use with services provided by the issuing LIR. It cannot be
   kept when terminating services provided by the LIR.  ASSIGNED PI:
   This address space has been assigned to an End User and can be kept
   as long as the criteria for the original assignment are met.
   
   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.
   
   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.
   
   The RIPE NCC no longer allocates PI address space. Consequently,
   many LIRs do not have PI allocations from which to make PI
   assignments. If an LIR has an End User that requires PI address
   space they are able to support them by sending these requests to
   the RIPE NCC on behalf of the End User. This support includes
   helping End Users prepare a properly documented request. The RIPE
   NCC will make PI assignments when justified.
   
10.0 Record Keeping
     
   All documentation related to an IP address request and
   sub-allocation or assignment must be maintained by the LIR for
   future reference. This data is needed for the evaluation of
   subsequent requests for the same organisation, for audits by the
   RIR, and for the resolution of any questions that may arise
   regarding assignments. The records must include: 

   * The original request

   * All supporting documentation 

   * All related correspondence between the LIR and the End User

   * The assignment decision, including the reasons behind any unusual
   decision
  
   * The details of the person responsible for making the decision
   
   The history of events and the people responsible should be clearly
   recorded. In order to help the exchange of information, it is
   strongly recommended that documents are kept electronically and are
   readily accessible. If requested, any of this information should be
   made available to the RIPE NCC in English.
   
11.0 LIR Audit
   
   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 Consistency and Auditing Activity" found at:
   
     http://www.ripe.net/ripe/docs/audit.html
   
12.0 Closing an LIR by the RIPE NCC The RIPE NCC may close an LIR for
   any of the following reasons: 

   * the LIR does not pay money owed to the RIPE NCC

   * the LIR cannot be contacted by the RIPE NCC for a significant
   period of time

   * the LIR consistently violates the RIPE community's policies
   
   The RIPE NCC takes on responsibility for address space held by
   closing LIRs.
   
