Document ID: ripe-TBA
Date: TBA
This document relates to Version 2.0 of RIPE policy proposal 2010-01 Temporary Internet Number Assignment Policies. If approved, it will modify ripe-492. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.
| ADDITION TO DOCUMENT >> | The new text is shown in blue. |
| ORIGINAL TEXT |
NEW TEXT
|
|
The text from the current policy document that will be replaced is displayed here. |
The proposed new text will be displayed here. |
All other text in the document will not be replaced.
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/groups/wg/ap
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
| ORIGINAL TEXT |
NEW TEXT
|
|
8.0 Assignments for Internetworking Experiments |
8.0 PA vs. PI Address Space |
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".
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/policy
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 IPv4 address assignments should be made with the following goals in mind:
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.
Please note that all communication with the RIPE NCC must be in English.
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).
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.
As of 1 July 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to three 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.
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.
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).
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).
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 [email protected].
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.
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.
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.
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/request-forms-supporting-notes
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
Assignments may only be based on realistic expectations recorded in the documentation.
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.
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.
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
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.
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.
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.