DRAFT v2: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region - Current Policy Text

How to read this draft document:

This document relates to the policy proposal 2013-03, “No Need – Post-Depletion Reality Adjustment and Cleanup”. If approved, it will modify ripe-592. 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.

We indicate changes to existing text in the document like this:

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.

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/groups/wg/ap

ORIGINAL TEXT	NEW TEXT
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 5.6 Use of last /8 PA 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 6.10 Provider Independent IPv4 Assignments for Multihoming 7.0 Assignment Window 8.0 PA vs. PI Address Space 9.0 Record Keeping 10.0 LIR Audit 11.0 Closing an LIR by the RIPE NCC	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 Allocations made by the RIPE NCC to LIRs 5.2 Unforeseen circumstances 5.3 Address Recycling 5.4 Sub-allocations 5.5 Transfers of Allocations 6.0 Policies and Guidelines for Assignments 6.1 Assignments to Internet Exchange Points 6.2 Network Infrastructure and End User Networks 6.3 Validity of an Assignment 7.0 Types of Address Space 8.0 LIR Audit 9.0 Closing an LIR by the RIPE NCC

ORIGINAL TEXT

NEW TEXT

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

5.6 Use of last /8 PA 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

6.10 Provider Independent IPv4 Assignments for Multihoming

7.0 Assignment Window

8.0 PA vs. PI Address Space

9.0 Record Keeping

10.0 LIR Audit

11.0 Closing an LIR by the RIPE NCC

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 Allocations made by the RIPE NCC to LIRs

5.2 Unforeseen circumstances

5.3 Address Recycling

5.4 Sub-allocations

5.5 Transfers of Allocations

6.0 Policies and Guidelines for Assignments

6.1 Assignments to Internet Exchange Points

6.2 Network Infrastructure and End User Networks

6.3 Validity of an Assignment

7.0 Types of Address Space

8.0 LIR Audit

9.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/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:

ORIGINAL TEXT	NEW TEXT
Public IP addresses are assigned to be globally unique according to the goals described in Section 3 of this document.	Public IP addresses are distributed to be globally unique according to the goals described in Section 3 of this document. The two types of IPv4 address described in this documents are Provider Aggregatable (PA) and Provider Independent (PI).

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.

ORIGINAL TEXT	NEW TEXT
3. 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. 4. 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.	[Removed point 3. Conservation.] 3. 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.

ORIGINAL TEXT

NEW TEXT

3. 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.

4. 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.

[Removed point 3. Conservation.]

3. 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).

ORIGINAL TEXT	NEW TEXT
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. 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 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 [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. 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. The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses. The list will contain information about approved and non-approved transfers. The following information will be published for approved transfers: the name of the transferring party, the block originally held by the transferring party, the name(s) of the receiving party or parties, each subdivided prefix (each partial block derived from that original block) transferred, the date each prefix was transferred Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published the number of requested transfers not approved after the RIPE NCC's evaluation the sum of the number of addresses included in the requested transfers. Neither the blocks nor the organizations involved will be identified in these statistics. 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 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. 5.6 Use of last /8 for PA Allocations The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows: Allocations for LIRs from the last /8 On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be exactly one /22. LIRs receive only one /22, even if their needs justify a larger allocation. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. Assignments to Internet Exchange Points A /16 from the final /8 will be held in reserve for exclusive use by Internet Exchange Points. On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one number resource (/24 to /22) according to the following: This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden. Organisations receiving space under this policy must be Internet Exchange Points and must meet the definition as described in section two of the RIPE document “IPv6 Address Space for Internet Exchange Points”. IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment. New Internet Exchange points will be assigned a /24. Internet exchange points may return this /24 (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment. IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use. Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN Unforeseen circumstances A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. In the event that this /16 remains unused at the time the remaining /8 covered by this policy has been distributed, it returns to the pool to be distributed as per clause 1. Post-depletion Address Recycling This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in clause 1. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary Insufficient address space In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.	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. 5.1 Allocations made by the RIPE NCC to LIRs The RIPE NCC's minimum allocation size is /22. Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC" On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: The size of the allocation made will be exactly one /22. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request. 5.2 Unforeseen circumstances A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. In the event that this /16 remains unused at the time the remaining addresses covered by this policy have been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document. 5.3 Address Recycling Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. 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 7.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. LIRs may make sub-allocations to multiple downstream network operators. 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. 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. 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. The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses. The list will contain information about approved and non-approved transfers. The following information will be published for approved transfers: the name of the transferring party, the block originally held by the transferring party, the name(s) of the receiving party or parties, each subdivided prefix (each partial block derived from that original block) transferred, the date each prefix was transferred Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published the number of requested transfers not approved after the RIPE NCC's evaluation the sum of the number of addresses included in the requested transfers. Neither the blocks nor the organizations involved will be identified in these statistics. 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 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. [NOTE: 5.6 included in 5.1, 5.2, 5.3 & 6.1]

ORIGINAL TEXT

NEW TEXT

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.

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

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 [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. 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.

The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.

The list will contain information about approved and non-approved transfers.

The following information will be published for approved transfers:

the name of the transferring party,
the block originally held by the transferring party,
the name(s) of the receiving party or parties,
each subdivided prefix (each partial block derived from that original block) transferred,
the date each prefix was transferred

Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published

the number of requested transfers not approved after the RIPE NCC's evaluation
the sum of the number of addresses included in the requested transfers.

Neither the blocks nor the organizations involved will be identified in these statistics.

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 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.

5.6 Use of last /8 for PA Allocations

The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:

Allocations for LIRs from the last /8

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
1. LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be exactly one /22.
2. LIRs receive only one /22, even if their needs justify a larger allocation.
3. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application.
4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.
Assignments to Internet Exchange Points

A /16 from the final /8 will be held in reserve for exclusive use by Internet Exchange Points. On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one number resource (/24 to /22) according to the following:
- This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.
- Organisations receiving space under this policy must be Internet Exchange Points and must meet the definition as described in section two of the RIPE document “IPv6 Address Space for Internet Exchange Points”.
- IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment.
- New Internet Exchange points will be assigned a /24. Internet exchange points may return this /24 (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment.
- IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use.
- Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN
Unforeseen circumstances
1. A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. In the event that this /16 remains unused at the time the remaining /8 covered by this policy has been distributed, it returns to the pool to be distributed as per clause 1.
Post-depletion Address Recycling

This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.
1. Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in clause 1.
2. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary
Insufficient address space

In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

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.

5.1 Allocations made by the RIPE NCC to LIRs

The RIPE NCC's minimum allocation size is /22.

Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC"

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

The size of the allocation made will be exactly one /22.
The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

5.2 Unforeseen circumstances

A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it.

In the event that this /16 remains unused at the time the remaining addresses covered by this policy have been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document.

5.3 Address Recycling

Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1.

This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.

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 7.0.

LIRs wishing to convert their allocations to PA status should contact the RIPE NCC by email at [email protected].

LIRs may make sub-allocations to multiple downstream network operators.

5.5 Transfers of Allocations

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.

The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.

The list will contain information about approved and non-approved transfers.

The following information will be published for approved transfers:

the name of the transferring party,
the block originally held by the transferring party,
the name(s) of the receiving party or parties,
each subdivided prefix (each partial block derived from that original block) transferred,
the date each prefix was transferred

Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published

the number of requested transfers not approved after the RIPE NCC's evaluation
the sum of the number of addresses included in the requested transfers.

Neither the blocks nor the organizations involved will be identified in these statistics.

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.

[NOTE: 5.6 included in 5.1, 5.2, 5.3 & 6.1]

ORIGINAL TEXT	NEW TEXT
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/request-forms-supporting-notes	A /16 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive one number resource (/24 to /22) according to the following:

ORIGINAL TEXT

NEW TEXT

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/request-forms-supporting-notes

A /16 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive one number resource (/24 to /22) according to the following:

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/data-tools/support/documentation/getting-started

ORIGINAL TEXT	NEW TEXT
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.	[NOTE: Removed 6.3, 6.4 & 6.5]

ORIGINAL TEXT

NEW TEXT

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.

[NOTE: Removed 6.3, 6.4 & 6.5]

ORIGINAL TEXT	NEW TEXT
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	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.

ORIGINAL TEXT

NEW TEXT

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

ORIGINAL TEXT	NEW TEXT
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/RFC 4786 (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. 6.10 Provider Independent IPv4 Assignments for Multihoming The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24 if an End User demonstrates: the need for Provider Independent (PI) IPv4 address space; and the intent to announce this address space for the purpose of multihoming to two or more Autonomous Systems which the End User does not own or control Cumulatively, no more than 255 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined above.	[NOTE: Removed 6.7, 6.8, 6.9 & 6.10]

ORIGINAL TEXT

NEW TEXT

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/RFC 4786 (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.

6.10 Provider Independent IPv4 Assignments for Multihoming

The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24 if an End User demonstrates:

the need for Provider Independent (PI) IPv4 address space; and
the intent to announce this address space for the purpose of multihoming to two or more Autonomous Systems which the End User does not own or control

Cumulatively, no more than 255 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined above.

[NOTE: Removed 6.7, 6.8, 6.9 & 6.10]

ORIGINAL TEXT	NEW TEXT
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/request-forms-supporting-notes 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.	[NOTE: Removed 7.0]

ORIGINAL TEXT

NEW TEXT

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/request-forms-supporting-notes

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.

[NOTE: Removed 7.0]

ORIGINAL TEXT	NEW TEXT
8.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.	7.0 Types of Address Space LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. Clear contractual arrangements are mandatory for PA space. 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. 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. It cannot be re-assigned or further assigned to other parties. 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. 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. The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.

ORIGINAL TEXT

NEW TEXT

8.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.

7.0 Types of Address Space

LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered.

Clear contractual arrangements are mandatory for PA space. End Users requesting PA space should be given this or a similar warning:

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. It cannot be re-assigned or further assigned to other parties.
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 or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.

ORIGINAL TEXT	NEW TEXT
9.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.	[NOTE: Removed 9.0]

ORIGINAL TEXT

NEW TEXT

9.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.

[NOTE: Removed 9.0]

ORIGINAL TEXT	NEW TEXT
10.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 11.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/lir-services/training	8.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 9.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.

ORIGINAL TEXT

NEW TEXT

10.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

11.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/lir-services/training

8.0 LIR Audit

9.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.

DRAFT v2: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region - Current Policy Text

How to read this draft document:

We indicate changes to existing text in the document like this:

Abstract

Contents

Contents

1.0 Introduction

1.1 Scope

2.0 IPv4 Address Space

3.0 Goals of the Internet Registry System

3.1 Confidentiality

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

5.6 Use of last /8 for PA Allocations

5.0 Policies and Guidelines for Allocations

5.1 Allocations made by the RIPE NCC to LIRs

5.2 Unforeseen circumstances

5.3 Address Recycling

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

6.10 Provider Independent IPv4 Assignments for Multihoming

7.0 Assignment Window

8.0 PA vs. PI Address Space

7.0 Types of Address Space

9.0 Record Keeping

10.0 LIR Audit

11.0 Closing an LIR by the RIPE NCC

8.0 LIR Audit

9.0 Closing an LIR by the RIPE NCC