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" available from the RIPE NCC web site
at:
http://www.ripe.net/info/resource-admin/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:
- 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 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
- 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).
| ADDITION
TO DOCUMENT >> |
Every organisation controlling an IP address should provide at least one working contact e-mail address where notifications of abuse emanating from that IP address can be sent.
All persons and organisations assigned an IP address should act to prevent abusive messages originating from that IP address. |
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 /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" found at:
https://lirportal.ripe.net/newmember/index.html
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 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 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
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.
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 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
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.
6.9
Anycasting TLD Nameservers
If the name server set of a ccTLD or a gTLD without anycasting
technology applied would not pass the 'IANA Administrative Procedure for
Root Zone Name Server Delegation and Glue Data' the TLD administrator
may receive a single dedicated /24 network prefix for the sole purpose
of anycasting name servers, as described in RFC 3258.
The prefix will be assigned by the RIPE NCC directly to the TLD,
upon a request submitted via an existing LIR and will be registered with
a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned
to the RIPE NCC if not in use for anycast DNS any longer.
|
you are here: RIPE -> RIPE Draft Documents
