IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region |
 |
Randy Bush
Brett Carr
Daniel Karrenberg
Niall O'Reilly
Ondrej Sury
Nigel Titley
Filiz Yilmaz
Ingrid Wijte
Document
ID: ripe-484
Date: December 2009
Obsoletes: ripe-104, ripe-105,
ripe-127, ripe-136, ripe-140, ripe-159, ripe-185, ripe-234, ripe-288,
ripe-324, ripe-368, ripe-387, ripe-405, ripe-411, ripe-424, ripe-441,
ripe-449, ripe-471
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
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
5.5 Transfers of 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
6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers
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 five
Regional Internet Registries (RIRs). Its service region incorporates
Europe, the Middle East, and Central Asia. 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 space follows the hierarchical scheme described in
the document "Internet
Registry System".
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:
Public IP addresses are assigned to be globally unique according to
the goals described in Section 3 of this document.
- 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 RFC1918 found at:
ftp://ftp.ripe.net/rfc/rfc1918.txt
For
information on the “Architectural Implications of NAT”, please
refer to RFC2993, found at: ftp://ftp.ripe.net/rfc/rfc2993.txt
Some
address ranges are reserved for special use purposes. These are
described in RFC3330 and are beyond the scope of this document.
RFC3330 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.
The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months.
Starting on 1 July 2010, a gradual reduction in the allocation period will be applied as follows:
As of 1 July 2010, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to nine months.
As of 1 January 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to six months.
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.
5.1 First
Allocation
The
RIPE NCC’s minimum allocation size is /21.
Details
of how to join the RIPE NCC can be found in the RIPE Document
"Procedure for Becoming a Member of the RIPE NCC".
Members
can receive an initial IPv4 allocation when they have demonstrated a
need for IPv4 address space.
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 by email 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 up to an IPv4 /20 (4096 addresses) to
a downstream network operator every twelve months.
LIRs
may make sub-allocations to multiple downstream network operators.
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 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.
5.5 Transfers of
Allocations
Any
LIR is allowed to re-allocate complete or partial blocks of IPv4
address space that were previously allocated to them by either the
RIPE NCC or the IANA. Such address space must not contain any block
that is assigned to an End User.
Address
space may only be re-allocated to another LIR that is also a member
of the RIPE NCC. The block that is to be re-allocated must not be
smaller than the minimum allocation block size at the time of
re-allocation. An LIR may only receive a transferred allocation after
their need is evaluated and approved by the RIPE NCC, following the
policies set for receiving further allocations within RIPE region
(see the Section 5.3 Additional Allocations of this document).
Re-allocation
must be reflected in the RIPE Database. This re-allocation may be on
either a permanent or non-permanent basis.
LIRs
that receive a re-allocation from another LIR cannot re-allocate
complete or partial blocks of the same address space to another LIR
within 24 months of receiving the re-allocation.
The
RIPE NCC will record the change of allocation after the transfer.
Please note that the LIR always remains responsible for the entire
allocation it receives from the RIPE NCC until the transfer of
address space to another LIR is completed or the address space is
returned. The LIR must ensure that all policies are applied.
Re-allocated
blocks will be signed to establish the current allocation owner.
Re-allocated
blocks are no different from the allocations made directly by the
RIPE NCC and so they must be used by the receiving LIR according to
the policies described in this document.
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.
The End Users must be assigned with enough address space to meet their needs for a period of up to 12 months.
Starting on 1 July 2010, a gradual reduction in the assignment period will be applied as follows:
As of 1 July 2010, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to nine months.
As of 1 January 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to six months.
As of 1 July 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to three months.
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 Users.
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
The utilisation rate of an assignment must be such that at least 50% of the total space shall have been utilised halfway through the assignment period applied at the time of the assignment.
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 Audit 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.
6.9 Anycasting TLD
and Tier 0/1 ENUM Nameservers
The
organisations applicable under this policy are TLD managers, as
recorded in the IANA's Root Zone Database and ENUM administrators, as
assigned by the ITU. The organisation may receive up to four /24
prefixes per TLD and four /24 prefixes per ENUM. These prefixes must
be used for the sole purpose of anycasting authoritative DNS servers
for the stated TLD/ENUM, as described in BCP126/RFC4786 (http://www.ietf.org/rfc/rfc4786.txt).
Assignments
for authoritative TLD or ENUM Tier 0/1 DNS lookup services are
subject to the policies described in the RIPE Document entitled
"Contractual Requirements for Provider Independent Resource
Holders in the RIPE NCC Service Region".
Anycasting
assignments are registered with a status of 'ASSIGNED ANYCAST' in the
RIPE Database and must be returned to the RIPE NCC if not in use for
authoritative TLD or ENUM Tier 0/1 DNS lookup services via anycast
any longer.
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). Their AW will automatically be
set to a /21 (2048 addresses) six months after receiving their
first allocation. This means that all new LIRs need to request
approval before making each assignment until their AW has been
raised.
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 or a downstream network operator as the user of a
sub-allocation 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 RIPE NCC staff. LIRs may approach the RIPE
NCC for an evaluation of their AW six months after receiving
their first allocation and at any time after that. 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
judgment 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 judgment 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.
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 website),
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 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 must be returned and the network
renumbered.
In
contrast, Provider Independent (PI) address space is assigned to End
Users directly from the address pools managed directly by the RIPE
NCC. PI space cannot be re-assigned or further assigned to other
parties. PI address space can only remain assigned to a network as
long as the criteria for the original assignment are maintained.
Additionally, all new PI address space assignments are subject to the
policies described in the RIPE NCC document entitled “Contractual
Requirements for Provider Independent Resources Holders in the RIPE
NCC Service Region”.
As
PI addresses are not assigned from LIR-allocated PA address blocks,
they cannot be aggregated on the public Internet. Consequently, they
are expensive to route, and therefore may 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 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.
End
Users requesting PI space should be given this or a similar warning:
Assignment
of this IP space is valid as long as the criteria for the original
assignment are still met and is also subject to the policies
described in the RIPE NCC document entitled “Contractual
Requirements for Provider Independent Resources Holders in the RIPE
NCC Service Region”.
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
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.
- 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 (except for ALLOCATED PA). 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.
- 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.
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 Audit 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. Information on training courses and training material can be
found at:
http://www.ripe.net/training/
|
you are here: RIPE -> RIPE Document Store
