This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. It was developed through joint discussions among the APNIC, ARIN and RIPE communities.

Contents

1. Introduction
1.1. Overview
2. Definitions
2.1. Internet Registry (IR)
2.2. Regional Internet Registry (RIR)
2.3. National Internet Registry (NIR)
2.4. Local Internet Registry (LIR)
2.5. Allocate
2.6. Assign
2.7. Utilisation
2.8. HD-Ratio
2.9. End Site
3. Goals of IPv6 address space management
3.1. Goals
3.2. Uniqueness
3.3. Registration
3.4. Aggregation
3.5. Conservation
3.6. Fairness
3.7. Minimised Overhead
3.8. Conflict of Goals
4. IPv6 Policy Principles
4.1. Address space not to be considered property
4.2. Routability not guaranteed
4.3. Minimum Allocation
4.4. Consideration of IPv4 Infrastructure
5. Policies for allocations and assignments
5.1. Initial allocation
5.1.1. Initial allocation criteria
5.1.2. Initial allocation size
5.2. Subsequent allocation
5.2.1. Subsequent allocation criteria
5.2.2. Applied HD-Ratio
5.2.3. Subsequent Allocation Size
5.3. LIR-to-ISP allocation
5.4. Assignment
5.4.1. Assignment address space size
5.4.2. Assignments shorter than a /48 to a single End Site
5.4.3. Assignment to operator's infrastructure
5.5. Registration
5.6. Reverse lookup
5.7. Existing IPv6 address space holders
6. Anycasting TLD and Tier 0/1 ENUM Nameservers
7. IPv6 Provider Independent (PI) Assignments
7.1. IPv6 Provider Independent (PI) Assignments for LIRs
8. References
9. Appendix A: HD-Ratio
10. Appendix B: Background information
10.1. Background
10.2. Why a joint policy?
10.3. The size of IPv6's address space
10.4. Acknowledgment

1. Introduction

1.1. Overview

This document describes policies for the allocation and assignment of globally unique Internet Protocol version 6 (IPv6) address space.

[RFC 4291] designates 2000::/3 to be global unicast address space that the Internet Assigned Numbers Authority (IANA) may allocate to the RIRs. In accordance with [RFC 4291], IANA allocated initial ranges of global unicast IPv6 address space from the 2000::/3 address block to the RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies. All bits to the left of /64 are in scope.

This policy is subject to future review and potential revision, subject to continuing experience in the administration of IPv6.

2. Definitions

[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]

The following terms and their definitions are of particular importance to the understanding of the goals, environment and policies described in this document.

Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below.

2.1. Internet Registry (IR)

An Internet Registry is an organisation that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.

2.2. Regional Internet Registry (RIR)

Regional Internet Registries are established and authorised by respective regional communities and recognised by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions.

2.3. National Internet Registry (NIR)

A National Internet Registry primarily allocates address space to its members or constituents, which are generally LIRs organised at a national level. NIRs exist mostly in the Asia Pacific region.

2.4. Local Internet Registry (LIR)

A Local Internet Registry is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.

2.5. Allocate

To “allocate” means to distribute address space to IRs for the purpose of subsequent distribution by them.

2.6. Assign

To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.

2.7. Utilisation

The actual usage of addresses within each assignment may be low when compared to IPv4 assignments. In IPv6, "utilisation" is only measured in terms of the bits to the left of the efficiency measurement unit (/56). In other words, "utilisation" effectively refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual End Site assignments.

Throughout this document, the term "utilisation" refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual subnets within those End Sites.

2.8. HD-Ratio

The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an adaptation of the H-Ratio originally defined in [RFC 1715] and is expressed as follows:

      Log (number of allocated objects)
HD = ----------------------------------------------
      Log (maximum number of allocatable objects)

where (in the case of this document) the objects are IPv6 site addresses assigned from an IPv6 prefix of a given size.

2.9. End Site

An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:

• that service provider assigning address space to the End User
• that service provider providing transit service for the End User to other sites
• that service provider carrying the End User's traffic
• that service provider advertising an aggregate prefix route that contains the End User's assignment

3. Goals of IPv6 address space management

3.1. Goals

IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the Internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.

3.2. Uniqueness

Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.

3.3. Registration

Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users.

The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.

3.4. Aggregation

Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs and to limit the expansion of Internet routing tables.

This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.

IPv6 address policies should seek to avoid fragmentation of address ranges.

Further, RIRs should apply practices that maximise the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.

3.5. Conservation

Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.

3.6. Fairness

All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor.

3.7. Minimised overhead

It is desirable to minimise the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.

3.8. Conflict of goals

The goals described above will often conflict with each other, or with the needs of individual IRs or End Users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.

In IPv6 address policy, the goal of aggregation is considered to be the most important.

4. IPv6 Policy Principles

To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below.

4.1. Address space not to be considered property

It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.

The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license.

RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment.

4.2. Routability not guaranteed

There is no guarantee that any address allocation or assignment will be globally routable.

However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.

4.3. Minimum allocation

The minimum allocation size for IPv6 address space is /32.

4.4. Consideration of IPv4 infrastructure

Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure.

5. Policies for Allocations and Assignments

5.1. Initial allocation

5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an organisation must:

a) be an LIR;

b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.

5.1.2. Initial allocation size

Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary.

Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure.

5.2. Subsequent allocation

Organisations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below.

5.2.2. Applied HD-Ratio

The HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilisation for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilisation value for a given address block size.

5.2.3. Subsequent allocation size

When an organisation has achieved an acceptable utilisation for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.

If an organisation needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.

5.3. LIR-to-ISP allocation

There is no specific policy for an organisation (LIR) to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.

5.4. Assignment

LIRs must make IPv6 assignments in accordance with the following provisions.

5.4.1. Assignment address space size

End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).

5.4.2. Assignments shorter than a /48 to a single End Site

When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level.

Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.

5.4.3. Assignment to operator's infrastructure

An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.

5.5 Registration

When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database.

These registrations can either be made as individual assignments or by inserting a object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users.When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'.

In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR' in such a way the RIR is able to calculate and verify the actual HD-ratio.

5.6. Reverse lookup

When an RIR/NIR delegates IPv6 address space to an organisation, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organisation should properly manage its reverse lookup zone. When making an address assignment, the organisation must delegate to an assignee organisation, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.

5.7. Existing IPv6 address space holders

LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without providing further documentation. 

The RIPE NCC should allocate the new address space contiguously with the LIRs’ existing allocations and avoid allocating non-contiguous space under this policy section.

6. 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 /48 prefixes per TLD and four /48 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.

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 infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services any longer.

7. IPv6 Provider Independent (PI) Assignments

To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.

The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets.

Additional assignments may also be made when the need is demonstrated and documented based on address usage, or because different routing requirements exist for additional assignments. When possible, these further assignments will be made from an adjacent address block.

Assignments will be made from a separate 'designated block' to facilitate filtering practices.

The PI assignment cannot be further assigned to other organisations.

7.1 IPv6 Provider Independent (PI) Assignments for LIRs

LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.

The LIR must return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid.

If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both.

8. References

[RFC 1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, ftp://ftp.ripe.net/rfc/rfc1715.txt

[RFC 2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC ftp://ftp.ripe.net/rfc/rfc2026.txt see Sec. 4.2.1

[RFC 2462] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T. Narten, 1998, ftp://ftp.ripe.net/rfc/rfc2462.txt

[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt

[RFC 2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000 ftp://ftp.ripe.net/rfc/rfc2928.txt

[RFC 3194] "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, ftp://ftp.ripe.net/rfc/rfc3194.txt

[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt

[RFC 4786] "Operation of Anycast Services",  J. Abley, K. Lindqvist. December 2006, ftp://ftp.ripe.net/rfc/rfc4786.txt

9. Appendix A: HD-Ratio

The utilisation threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6 prefix P, can be calculated as:

T = 2^((56-P)*HD)

Thus, the utilisation threshold for an organisation requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilisation refers to the use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.

In accordance with the recommendations of [RFC 3194], this document adopts an HD-Ratio of 0.94 as the utilisation threshold for IPv6 address space allocations.

The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94.

10. Appendix B: Background information

10.1. Background

The impetus for revising the 1999 provisional IPv6 policy started with the APNIC meeting held in Taiwan in August 2001. Follow-on discussions were held at the October 2001 RIPE and ARIN meetings. During these meetings, the participants recognised an urgent need for more detailed, complete policies. One result of the meetings was the establishment of a single mailing list to discuss a revised policy together with a desire to develop a general policy that all RIRs could use. This document does not provide details of individual discussions that lead to policies described in this document; detailed information can be found in the individual meeting minutes at the www.apnic.net, www.arin.net, and www.ripe.net web sites.

In September 2002 at the RIPE 43 Meeting in Rhodes, Greece, the RIPE community approved the policy allowing Internet experiments to receive temporary assignments. As a result, Section 6 was added to this document in January 2003.

10.2. Why a joint policy?

IPv6 addresses are a public resource that must be managed with consideration to the long-term interests of the Internet community. Although regional registries adopt allocation policies according to their own internal processes, address policies should largely be uniform across registries. Having significantly varying policies in different regions is undesirable because it can lead to situations where "registry shopping" can occur as requesting organisations request addresses from the registry that has the most favorable policy for their particular desires. This can lead to the policies in one region undermining the efforts of registries in other regions with regards to prudent stewardship of the address space. In cases where regional variations from the policy are deemed necessary, the preferred approach is to raise the issue in the other regional registries in order to develop a consensus approach that all registries can support.

10.3. The size of IPv6's address space

Compared to IPv4, IPv6 has a seemingly endless amount of address space. While superficially true, short-sighted and wasteful allocation policies could also result in the adoption of practices that lead to premature exhaustion of the address space.

It should be noted that the 128-bit address space is divided into three logical parts, with the usage of each component managed differently. The rightmost 64 bits, the Interface Identifier [RFC 4291], will often be a globally unique IEEE identifier (e.g., mac address). Although an "inefficient" way to use the Interface Identifier field from the perspective of maximizing the number of addressable nodes, the numbering scheme was explicitly chosen to simplify Stateless Address Autoconfiguration [RFC 2462].

The middle bits of an address indicate the subnet ID. This field may often be inefficiently utilised, but the operational benefits of a consistent width subnet field were deemed to be outweigh the drawbacks. This is a variable length field, determined by each LIR's local assignment policy.

10.4. Acknowledgment

The initial version of this document was produced by the JPNIC IPv6 policy drafting team consisting of Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this team, who worked over a holiday in order to produce an initial document quickly.

An editing team was then organised by representatives from each of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of the RIPE IPv6 Working Group).

The editing team would like to acknowledge the contributions to this document of Takashi Arano, John Crain, Steve Deering, Gert Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Wittbrodt and Wilfried Woe

 This document outlines policies for temporary direct assignments of IPv4/IPv6 address space and Autonomous System (AS) Numbers in the RIPE NCC service region.

Contents

1.0 Introduction

2.0 Internet Registry Number Resource Pool Reservation

2.1 RIPE NCC Assignment Procedures

3.0 End User Term and Limitations

3.1 Assignment Time Limits

3.2 Realistic Expectations

3.3 IPv4 Address Utilisation Rate

3.4 Compliance with Other RIPE NCC Assignment Policies

4.0 Attribution

1.0 Introduction

This policy allows the RIPE NCC to assign number resources for temporary direct assignment purposes and, for this purpose, to reserve pools of IPv4/IPv6 addresses, AS Numbers and any other numbers for which it acts as Regional Internet Registry (RIR).

2.0 Internet Registry Number Resource Pool Reservation

The RIPE NCC is authorised to reserve pools of IPv4 addresses, IPv6 addresses, 16-bit AS Numbers and 32-bit AS Numbers for the purpose of direct assignment under this policy.

2.1 RIPE NCC Assignment Procedures

The RIPE NCC may assign number resources to End Users on a temporary deployment basis for a specific time-limited purpose. Examples of specific purposes include, but are not limited to, academic research and experimental purposes, conferences and other types of events which require network connectivity for short periods of time, and other strictly time-limited projects such as deployment tests for new Internet services and technologies.

Resources issued for temporary assignments must not be used for purposes other than those specified in the application, and they may be returned to the RIPE NCC at any time during the approved assignment period. The number resources will be automatically de-registered and returned to the appropriate reservation pool at the end of the approved assignment period.

The RIPE NCC will register the issued number resources in the RIPE Database for the duration of the assignment and will note the start and end dates of the assignment period for each database object.

3.0 End User Terms and Limitations

3.1 Assignment Time Limits

Depending on the specified purpose of the assignment request, different upper time limits may apply. For conferences and other events of short, fixed duration, the maximum assignment time period will be one month longer than the scheduled length of the conference/event but no longer than two months in any case.

For longer term projects and research purposes, the number resources may be issued on a temporary basis for a period of up to six calendar months, or one month longer than the expected life of the project/research/experiment, whichever is shorter.

In the case where an End User requires number resources for research purposes, and where the research project details are made public upon registration of the number resources by the RIPE NCC, and where the End User commits to making public the results of their research project free of charge and free from disclosure constraints, then the requested number resources may be issued for a period of up to one calendar year.

At the RIPE NCC’s discretion renewal of the registration of the resources may be possible in exceptional circumstances on receipt of a new request that details continuation of the End User's requirements during the extended period. Should this request be denied by the RIPE NCC, an appeal may be made using the RIPE NCC Conflict Arbitration Procedure.

3.2 Realistic Expectations

Assignments may only be based on realistic expectations recorded on the request form. The RIPE NCC may require the End User to provide documentation or other evidence supporting the End User's assignment request.

3.3 IPv4 Address Utilisation Rates

The utilisation rate of an assignment must be such that at least 50% of the total space applied for at the time of the assignment will be concurrently used at peak periods during the assignment.

3.4 Compliance with Other RIPE NCC Assignment Policies

In all respects not covered by this document, temporary assignment policies are subject to all other RIPE NCC policies regarding standard direct assignment of number resources.

4.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Nick Hilliard

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

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

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:

1. Public IP addresses are assigned to be globally unique according to the goals described in Section 3 of this document.
2. Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used.
   For a detailed description of “Address Allocation for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at: ftp://ftp.ripe.net/rfc/rfc1918.txt
   For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at: ftp://ftp.ripe.net/rfc/rfc2993.txt
3. Some address ranges are reserved for special use purposes. These are described in RFC 3330 and are beyond the scope of this document. RFC 3330 can be found at: ftp://ftp.ripe.net/rfc/rfc3330.txt

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

1. 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.
2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
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.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.

3.2 Language

Please note that all communication with the RIPE NCC must be in English.

4.0 Registration Requirements

All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).

5.0 Policies and Guidelines for Allocations

An allocation is a block of IPv4 addresses from which assignments are taken.

The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months.

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 lir-help@ripe.net.

The minimum size of a sub-allocation is /24. This is the smallest prefix length that can be reverse delegated and allows for a reasonable number of small assignments to be made by a downstream network operator.

An LIR may sub-allocate up to an IPv4 /20 (4096 addresses) to a downstream network operator every twelve months.

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

However, downstream network operators may receive sub-allocations totalling more than a /20 from more than one LIR.

The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community’s policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community’s policies when those operators have sub-allocations.

The RIPE NCC considers sub-allocated space as “used” when evaluating requests from the LIR for an additional IPv4 allocation. 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 will be signed to establish the current allocation owner.

Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.

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:

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

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

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

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

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

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

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

6.3 Utilisation Rates

Assignments’ immediate utilisation should be at least 25% of the assigned space. After one year, this should be at least 50% of the space unless special circumstances are defined.

Assignments may only be based on realistic expectations recorded in the documentation.

6.4 Reservations Not Supported

End Users are not permitted to reserve address space based on long-term plans. This violates the goal of conservation and fragments the address space when initial forecasts are not met. Evaluation of IP address space requests must be based on a demonstrated need. Unused, or inefficiently used address space assigned in the past should be used to meet the current request, or returned. Once an organisation has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network.

6.5 Administrative Ease

The current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Examples of this include, but are not limited to, ease of billing administration and network management.

6.6 Validity of an Assignment

All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.

For these reasons it is important that LIRs make sure that assignments approved by the RIPE NCC are properly registered in the database. The inetnum object or objects for approved assignments must use the netname(s) approved by the RIPE NCC and not be larger than the approved size. Additionally, the date in the first “changed:” attribute must not be earlier than the date of the approval message from the RIPE NCC.

The RIPE NCC reviews assignments made by LIRs when evaluating requests for additional allocations (see 5.3). It also runs consistency checks as part of the auditing activity requested by the community as described in the RIPE Document “RIPE NCC Audit Activity” found at:

http://www.ripe.net/ripe/docs/audit

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.

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.

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.

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.

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

Contents

1.0 Definition

2.0 Introduction

3.0 Reverse Delegation in the RIPE NCC Service Region

4.0 Procedures

5.0 References

6.0 Attribution

1.0 Definition

1.1 Reverse delegation: The process by which the authority for certain reverse DNS zones is assigned to a specific set of DNS servers.

1.2 Early registration: IPv4 address space assigned or allocated before the establishment of the Regional Internet Registries (RIRs).

2.0 Introduction

The RIPE NCC provides the necessary support to enable resolution of IPv4 and IPv6 address space into domain names. This service is implemented under the in-addr.arpa and ip6.arpa sub-domains described in [1] and [2].

3.0 Reverse Delegation in the RIPE NCC Service Region

The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC.

The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database.

Address space holders may delegate authority to another party.

4.0 Procedures

The procedures related to reverse delegation and information about the requirements the RIPE NCC enforces are published at:

http://www.ripe.net/reverse/

5.0 References

[1] [RFC 3172] "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"

[2] [RFC 3596] "DNS Extensions to Support IP Version 6", [RFC 3363] “Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System”, [RFC 3364] “Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version (IPv6)”

6.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed to this policy by making proposals through the RIPE Policy Development Process:

Olaf Kolkman
Leo Vegoda

This policy originated from the work of the Abuse Contact Management Task Force. The task force examined the collection and maintenance of resource registration information in the RIPE Database, including potential areas for improvement and alternative approaches.

This policy introduces a new contact attribute named "abuse-c:”, that can be included in inetnum, inet6num and aut-num objects.

Content

1.0    Abuse Contact Information
2.0    Attribution

1.0 Abuse Contact Information

The "abuse-c:" will reference a role object holding abuse contact information. The positioning of the “abuse-c:” attributes will make use of the hierarchical nature of the resource data to minimize the workload on resource holders. Internet number resources need to have an “abuse-c:” attribute.

The “abuse-c:” will be mandatory for all aut-nums.

Due the hierarchical nature of IP address objects, at least every direct allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited objects might have their own “abuse-c:” attribute or they will be covered by the higher level objects.

The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders’ networks.

The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.

As per current practice, other "e-mail:" attributes can be included for any other purposes.

2.0 Attribution

This document is developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Tobias Knecht

Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Recovered IPv4 Pool to be utilized post RIR IPv4 exhaustion as defined in Section 1. The Recovered IPv4 Pool will initially contain any fragments that may be left over in the IANA. It will also hold any space returned to the IANA by any other means.

Contents

1.0 Recovered IPv4 Pool

2.0 Allocation of returned IPv4 address space by the IANA

3.0 Reporting

4.0 References

5.0 Attribution

1.0 Recovered IPv4 Pool

The Recovered IPv4 Pool will be administered by the IANA. It will contain:

1. Any fragments left over in the IANA inventory after the last /8s of IPv4 space are delegated to the RIRs
   • The IANA inventory excludes "Special use IPv4 addresses" as defined in BCP 153 and any addresses allocated by the IANA for experimental use.
2. Any IPv4 space returned to the IANA by any means.

The Recovered IPv4 Pool will stay inactive until the first RIR has less than a total of a /9 in its inventory of IPv4 address space.

When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as stated in Section 2.0 below.

2.0 Allocation of returned IPv4 address space by the IANA

1. Allocations from the IANA may begin once the pool is declared active.
2. In each "IPv4 allocation period", each RIR will receive a single “IPv4 allocation unit” from the IANA.
3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year
4. The IANA will calculate the size of the "IPv4 allocation unit” at the following times:
   • When the Recovered IPv4 Pool is first activated
   • At the beginning of each IPv4 allocation period

To calculate the "IPv4 allocation unit" at these times, the IANA will use the following formula:

No RIR may get more than this calculation used to determine the IPv4 allocation unit even when they can justify a need for it.

The minimum "IPv4 allocation unit" size will be a /24. If the calculation used to determine the IPv4 allocation unit results in a block smaller than a /24, the IANA will not distribute any addresses in that IPv4 allocation period.

3.0 Reporting

The IANA may make public announcements of IPv4 address transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website [1] and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation, and to which Registry they have been allocated.

4.0 References

[1] "IANA IPv4 Address Space Registry", February 2011 http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

5.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, Douglas Onyango, Medel Ramirez, Philip Smith, Masato Yamanishi.

This document describes the policies for the assignment of globally unique Autonomous System (AS) Numbers within the RIPE NCC service region. These policies are developed by the RIPE Community following the RIPE Policy Development Process.

Contents

1.0 Definition

2.0 Assignment Criteria

3.0 Returning AS Numbers

4.0 32-bit AS Numbers

5.0 Registration

6.0 References

7.0 Attribution

1.0 Definition

An Autonomous System (AS) is a group of IP networks run by one or more network operators with a single clearly defined routing policy. When exchanging exterior routing information, each AS is identified by a unique number. Exterior routing protocols such as BGP, described in RFC1771, "A Border Gateway Protocol 4 (BGP-4)", are used to exchange routing information between Autonomous Systems. An AS will normally use some interior gateway protocol to exchange routing information on its internal networks.

2.0 Assignment Criteria

In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930.

A network must be multihomed in order to qualify for an AS Number.

When requesting an AS Number the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.

The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.

3.0 Returning AS Numbers

If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers. The RIPE NCC can then reassign the AS Number to another organisation.

4.0 32-bit AS Numbers

The RIPE NCC assigns 32-bit AS Numbers according to the following timeline:

• From 1 January 2007 the RIPE NCC will process applications that specifically request 32-bit only AS Numbers (AS Numbers that can not be represented with 16 bits) and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, the RIPE NCC will assign a 16-bit AS Number.

• From 1 January 2009 the RIPE NCC will process applications that specifically request 16-bit AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit AS Number, the RIPE NCC will assign a 32-bit only AS Number.

• From 1 January 2010 the RIPE NCC will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and it will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool.

5.0 Registration

The RIPE NCC will register the resources issued in the RIPE Database.

6.0 References

[RFC1771] "A Border Gateway Protocol 4 (BGP-4)" http://www.ietf.org/rfc/rfc1771.txt

[RFC1930] " Guidelines for creation, selection, and registration of an Autonomous System (AS)" http://www.ietf.org/rfc/rfc1930.txt

[RFC2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC http://www.ietf.org/rfc/rfc2026.txt see Sec. 4.2.1

7.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Nick Hilliard, Geoff Huston

This document describes the new value of the "status:" attribute and the "assignment-size:" of the inet6num object

1.0 Motivation

For verification of efficient use of allocated space, there is a requirement for LIRs to keep records of IPv6 address assignments made to End Users. However, for calculating the efficiency (HD-ratio) there is no need to keep track of personal data associated with these assignments. The number and size of the assignments is sufficient to calculate the HD-ratio and verify efficiency.

To standardise these registrations and to provide an open and transparent method of verification, this document introduces a new value of the "status:" attribute for inet6num objects (AGGREGATED-BY-LIR) and a new attribute called "assignment-size:". This new value allows for the creation of inet6num objects indicating these are aggregated End User assignments, using the "assignment-size" attribute to indicate the size of the individual End User assignments in this aggregate

2.0 Database Objects Affected

Only inet6num objects may contain a "status:" value of "AGGREGATED-BY-LIR" or attribute called "assignment size:". When the inet6num has a status of "AGGREGATED-BY-LIR", the "assignment-size" attribute is required. In all other cases the attribute is optional.

3.0 Usage

The <AGGREGATED-BY-LIR> value allows to register individual End User assignments by means of a less specific aggregate object that contains multiple assignments of the same size, which is indicated in the "assignment size:" attribute.

This allows for efficient registration of assignments in cases where there is no need or it is not possible to register the details of individual End Users. An example of this would be the use of dynamic address pools for broadband Internet access.

If, for instance, you wish to create a pool of 1000 /56 assignments, you would create an object similar to:

 inet6num:                  2000::/46
 status:                    AGGREGATED-BY-LIR
 assignment-size:           56
 <…>

This would indicate block of a /46 is further split into /56 End User assignments. Optionally the "remarks:" and "description:" attributes can be used to further clarify the usage or for instance give hints such as "used for dynamic assignments".

When needed, more specific inet6num objects are allowed to indicate a different assignment size within a certain range however, only one level of more specifics is allowed.

4.0 Functionality

When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules:

• The inet6num object may contain an optional attribute called "assignment-size:".
• The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself.
• A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or “AGGREGATED-BY-LIR”.
• When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:" attribute becomes required.

This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs).

This document does not stipulate performance requirements in the provision of services by the IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN.

2. Definitions

2.1 Recovered address space

Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than one year at the time of the report.

2.2 IPv4 address holdings

IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices.

3. Details of the Policy

This policy is to be implemented in two phases:

• Phase I: Recovery of IPv4 address space
• Phase II: Allocation of recovered IPv4 address space by the IANA

3.1 Phase I: Recovery of IPv4 address space

Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'.

Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool.

During Phase I, no allocations will be made from the recovered IPv4 pool.

3.2 Phase II: Allocation of recovered IPv4 address space by the IANA

Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool.

3.2.1 Allocation of IPv4 address space

1. For the purposes of this policy, an 'IPv4 allocation period' is defined as a six-month period following 1 March or 1 September in each year.
2. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-two) boundary.
3. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described section 3.2.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool.

3.2.2 IPv4 address space allocation criteria

A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period.

3.2.3 Initial allocation of IPv4 address space

Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilisation figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process.

3.3 Reporting

1. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR.
2. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR.
3. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated.
4. The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated.

Acknowledgement

The following people contributed to the creation of this document by making proposals through the RIPE Policy Development Process (PDP):
Adiel A. Akplogan, Raul Echeberria, Maemura Akinori, Geoff Huston, Axel Pawlik, Ray Plzak, Oscar A. Robles-Garay, Nigel Titley, Paul Wilson.

This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs).

This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO).

1. Allocation Principles

IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other[1].

This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool.

2. Initial Allocations

Each new RIR will be allocated a new ASN block.

3. Additional Allocations

An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met:

1. The RIR has assigned/allocated 80% of the previously received ASN block, or
2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months.

An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for.

4. Announcement of IANA Allocations

The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process.

This document describes how the RIPE NCC can allocate/assign resources to itself.

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.

1.1 Scope

This document describes the policy for allocating or assigning resources to the RIPE NCC. This policy applies to all resources, current and future, allocated to the RIPE NCC, its subsidiaries or affiliates. This document does not describe any specific resource or a policy restricted to a specific resource; it does however impact how the resource-specific policies should be interpreted when applied to the RIPE NCC as the entity requesting resources. This document does not describe or impact any policy where it is applied to regular LIRs.

2.0 RIPE NCC as a Resource Holder

Any resources allocated/assigned to the RIPE NCC will be registered in the RIPE Database. All policies set for allocating or assigning resources to LIRs apply equally to the RIPE NCC. The RIPE NCC as a resource holder should fulfil the same basic requirements also expected of normal LIRs, such as returning unused resources. As an exception from normal LIRs, RIPE NCC as a resource holder is exempted from signing any of the normal contracts required for number resource allocation/assignment.

While the RIPE NCC will still handle most of the tasks involved with allocating/assigning resources itself, it will not approve the validity of its own requests.

3.0 Pool of Arbiters

Defined in the RIPE Document, RIPE NCC Conflict Arbitration Procedure, the pool of arbiters has been appointed by the RIPE NCC Executive Committee (and approved by the General Meeting). The arbiters' function is to mediate in any conflict between the RIPE NCC and one of its members. In addition to executing the RIPE NCC Conflict Arbitration Procedure, the pool of arbiters will also evaluate the validity of all requests for resources made by the RIPE NCC.

4.0 Evaluating a Request

When an assignment/allocation request is received, it is processed by the RIPE NCC IP Resource Analysts (IPRAs) who will give a formal written opinion on whether the request is consistent with current assignment/allocation guidelines. This opinion is evaluated by a majority of the pool of arbiters (of which there is an odd number), who are entitled to approve the request only if the IPRA team find that the request is consistent with current rules.

Both the IPRA recommendation and the reasoning of the pool of arbiters will be announced publicly. For the purpose of evaluating, the request will be treated as if it were filed by a regular LIR.

If the request is approved, the resources will then be allocated/assigned by the RIPE NCC to the RIPE NCC and registered in the RIPE Database.

5.0 Conflict Resolution

Should either or both the RIPE NCC IPRAs and the pool of arbiters reject a request, or if the request cannot be granted by applying the standard LIR policies, the RIPE NCC can file a request to the RIPE Plenary Meeting to have its case heard. It is then up to the RIPE Plenary to decide whether the request should be granted or not. At no point can the RIPE NCC allocate/assign resources to itself without prior consent of either the pool of arbiters or the RIPE Plenary.

This document describes the contractual requirements necessary for End Users of provider independent resources.

Contents

1.0 Introduction
1.1 Scope
2.0 Contractual Responsibilities of End Users and LIRs
3.0 Rationale for Contractual Relationship Requirement

1.0 Introduction

The RIPE NCC has historically assigned provider independent resources without requiring a contractual relationship link between the End User and the RIPE NCC.  This policy has made it impossible to maintain an accurate database of resource utilisation, as there has been no effective ability for the RIPE NCC to ensure that End Users keep their contact information up-to-date, and to ensure that resources which are assigned to End Users which no longer fulfil the original assignment conditions are returned to the RIPE NCC for re-assignment.

The intention of this policy document is to ensure that the RIPE NCC, as the intermediate manager of provider independent resource assignments to End Users, can confirm that the End User exists, continues to exist and that they continue to fulfil their obligations to comply with the original assignment conditions. This position can be ensured by the presence of either an indirect or a direct contractual link between the End User and the RIPE NCC.

1.1 Scope

This policy document describes the contractual requirements for End Users of provider independent resources which have been assigned either directly by the RIPE NCC or through a Local Internet Registry in the RIPE NCC Service area.  Provider independent resources include autonomous system numbers, provider independent IPv4 address assignments, anycast assignments, provider independent IXP IPv6 address assignments, and all future provider independent resource assignments to End Users. The policies described in this document apply both to new provider independent number resources assigned by the RIPE NCC and also to all provider independent number resources previously assigned by the RIPE NCC or by a RIPE NCC Local Internet Registry.

2.0 Contractual Responsibilities of End Users and LIRs

End Users of provider independent resources are responsible for maintaining a contractual link to the RIPE NCC either through a sponsoring LIR or else directly to the RIPE NCC for the purposes of managing these resources.

In order to ensure that this contractual link is implemented for all End Users who applied for provider independent resources before there was a requirement to have a contractual link to the RIPE NCC, the RIPE NCC will make reasonable attempts to contact these End Users – either directly or indirectly through the End Users’ LIRs – in order to ensure that this contractual link is put in place.  If the RIPE NCC is unable to contact the End User of the provider independent resources within a period of three months, the resources will return by default to the RIPE NCC and will be made available for re-assignment to other End Users.

If the End User wishes to cease their current contractual relationship, they must first have a new contractual relationship in place with either another sponsoring LIR or else with the RIPE NCC.  In either case, such contractual changes must be communicated to the RIPE NCC each time they occur. If such a contract is terminated and a new contract is not realised with another sponsoring LIR or the RIPE NCC, the resources will return by default to the RIPE NCC.

The preferred model of the RIPE community is for End Users to have contractual relationship with a sponsoring LIR instead of directly with the RIPE NCC.

The details of any such contracts are outside the scope of this document.  However, at the minimum, all contracts should include:

• Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date
• Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database
• Notice that none of the provider independent resources may be sub-assigned to a third party
• Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources
• A clear statement that the resources will return by default to the RIPE NCC if
• The resource holder cannot be contacted
• The annual fee to the LIR is not paid
• A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time

3.0 Rationale for Contractual Relationship Requirement

Previously, End Users received direct number resource assignments from the RIPE NCC via a request sent by an existing LIR. While an End User may or may not have had a contract with the LIR sending the request to the RIPE NCC on their behalf, the RIPE NCC did not mandate that such a contractual link should exist with that End User. The absence of a contract between the End User and the LIR or the RIPE NCC has caused several problems.

• The link between the RIPE NCC and the End User is broken when the End User moves from the LIR that requested the resources on behalf of the End User to another service provider. This results in the RIPE NCC losing contact with the resource holder.

• Such a situation creates a potential environment for resource hijacking to occur.

• If the End User ceased to exist or no longer required the provider independent resources but did not inform the RIPE NCC, the process of reclaiming any resource is almost impossible without the existence of a contractual link. As IPv4 address exhaustion progresses, reclamation of IPv4 address space resources will increase in importance.

• All other receivers of resources are LIRs and have a contract with the RIPE NCC. End Users receive Internet resources from the RIPE NCC, just like LIRs. Therefore, the End User should also be obliged to enter into an equivalent contract to avoid creating an unfair alternative for receiving resources.

• Some ISPs prefer to receive Internet number resources as an End User rather than becoming an LIR even though they provide services to their own customers and therefore sub-assign address space assigned by the RIPE NCC. Such End User ISPs often receive several separate PI prefixes as this can be a cheaper alternative for them.  Sub-assignment of PI address space in this manner is in contravention of the RIPE policies concerning direct resource assignment policies. It is also detrimental to aggregation of routing prefixes in the global routing tables.

For these reasons, without contractual links in place between the End User and the RIPE NCC, it is impossible for the RIPE NCC to fulfil its obligations of responsible stewardship of Internet resources.

1.0 Introduction
2.0 Definition
3.0 Policy
4.0 Warning
5.0 Obtaining the Address Space

1.0 Introduction

Internet Exchange Points (IXPs) are used to exchange Internet traffic between different Internet Service Providers (ISPs). Many Exchange Point operators require address space for the peering mesh that is independent from any of the address space in use by member networks.

2.0 Definition

An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity whose purpose is to facilitate the exchange of Internet traffic between ISPs.

There must be a minimum of three ISPs connected and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be acquired through the appropriate means (e.g. an upstream ISP).

3.0 Policy

Requesting organisations that meet the definition in section 2.0 may receive address space to meet their needs. If the requesting organisation is confident that it will never need more than a single network then a /64 will be assigned.

Otherwise, a /48 will be assigned.

The prefix will be assigned by the RIPE NCC directly to the IXP, upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. IXP IPv6 address 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”.

4.0 Warning

Networks assigned under this policy may not be globally routable.

5.0 Obtaining the Address Space

Address space for IXPs qualifying under this policy can be requested by using the form "IPv6 Request Form for Internet Exchange Points" available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html

This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy.

Policy

In order to fulfill the requirements of this policy, at the time it is adopted, one /8 will be reserved by IANA for each RIR. The reserved allocation units will no longer be part of the available space at the IANA pool. IANA will also reserve one /8 to any new RIR at the time it is recognized.

The process for the allocation of the remaining IPv4 space is divided in two consecutive phases:

1. Existing Policy Phase:

During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA either cannot be fulfilled with the remaining IPv4 space available at the IANA pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty.

This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process (Exhaustion Phase) will be initiated.

2. Exhaustion Phase:

During this phase IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units).

2.1. Size of the final IPv4 allocations:

In this phase IANA will automatically allocate one /8 to each RIR from the reserved space as defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses.

2.2. Allocation of the remaining IPv4 Address space:

After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST:

A) Immediately notify the NRO about the activation of the second phase (Exhaustion Phase) of this policy.

B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space.

C) Proceed to allocate one /8 to each RIR from the reserved space.

This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs).

This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO.

Contents:

1. Allocation Principles
2. Initial Allocations
3. Additional Allocations
   3.1 Calculation of AVAILABLE SPACE
   3.2 Calculation of NECESSARY SPACE
4. Announcement of IANA allocations

1. Allocation Principles

The unit of IPv6 allocation (and therefore the minimum IPv6 allocation) from IANA to an RIR is a /12. The IANA will allocate sufficient IPv6 address space to the RIRs to support their registration needs for at least an 18 month period. The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work.

2. Initial Allocations

On inception of this policy, each current RIR with less than a /12 unallocated address space, shall receive an IPv6 allocation from IANA. Any new RIR shall, on recognition by ICANN receive an IPv6 allocation from the IANA.

3. Additional Allocations

An RIR is eligible to receive additional IPv6 address space from the IANA when either of the following conditions are met.

• The RIR's AVAILABLE SPACE of IPv6 addresses is less than 50% of a /12.

• The RIR's AVAILABLE SPACE of IPv6 addresses is less than its established NECESSARY SPACE for the following nine months.

In either case, IANA shall make a single IPv6 allocation, sufficient to satisfy the established NECESSARY SPACE of the RIR for an 18 month period.

3.1 Calculation of AVAILABLE SPACE

The AVAILABLE SPACE of IPv6 addresses of a RIR shall be determined as follows:

AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING DURING THE FOLLOWING THREE MONTHS - FRAGMENTED SPACE

- FRAGMENTED SPACE is determined as the total amount of available blocks smaller than the RIR's minimum allocation size within the RIR's currently available stock.

3.2 Calculation of NECESSARY SPACE

If the applying Regional Internet Registry does not establish any special needs for the period concerned, NECESSARY SPACE shall be determined as follows:

NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING THE PAST SIX MONTHS * LENGTH OF PERIOD IN MONTHS

If the applying RIR anticipates that due to certain special needs the rate of allocation for the period concerned will be different from the previous six months, it may determine its NECESSARY SPACE as follows:

• Calculate NECESSARY SPACE as its total needs for that period according to its projection and based on the special facts that justify these needs.

• Submit a clear and detailed justification of the above mentioned projection (Item A).

If the justification is based on the allocation tendency prepared by the Regional Internet Registry, data explaining said tendency must be enclosed.

If the justification is based on the application of one or more of the Regional Internet Registry's new allocation policies, an impact analysis of the new policy/policies must be enclosed.

If the justification is based on external factors such as new infrastructure, new services within the region, technological advances or legal issues, the corresponding analysis must be enclosed together with references to information sources that will allow verification of the data.

If IANA does not have elements that clearly question the Regional Internet Registry's projection, the special needs projected for the following 18 months, indicated in Item A above, shall be considered valid.