Draft: PA/PI Unification IPv6 Address Space - New Policy Text

Abstract

This document defines registry policies for the allocation and sub-allocation of globally unique IPv6 addresses to RIPE NCC members and their customers. It was initially developed in 1999 through joint discussions among the APNIC, ARIN and RIPE communities. It has been updated over time by the RIPE community following the Policy Development Process (PDP).

Contents

1.0 Introduction

2.0 Definitions

2.1 Internet Registry (IR)

2.2 Regional Internet Registry (RIR)

2.3 Local Internet Registry (LIR)

2.4 Sponsoring LIR

2.5 End User

2.6 End Site

2.7 Allocation

2.8 Sub-allocation

2.9 Aggregation

2.10 Utilisation

2.11 HD-Ratio

3.0 Goals of IPv6 Address Space Management

3.1 Uniqueness

3.2 Registration

3.3 Aggregation

3.4 Conservation

3.5 Fairness

3.6 Minimised Overhead

3.7 Conflict of Goals

4.0 IPv6 Policy Principles

4.1 Address Space Not to be Considered Property

4.2 Routability Not Guaranteed

4.3 Consideration of IPv4 Infrastructure

5.0 Policies for Allocations and Sub-allocations

5.1 Initial Allocation

5.1.1 Initial Allocation Criteria

5.1.2 Initial Allocation Size

5.1.3 Initial Allocations made to the LIR

5.1.4 Initial Allocations made to the End User

5.2 Additional Allocation

5.2.1 Additional Allocation Criteria

5.2.2 Applied HD-Ratio

5.2.3 Additional Allocation Size

5.3 Sub-allocations

5.3.1 Sub-allocations Made by the LIR or the End User

5.3.2 Sub-allocation Size

5.3.3 Sub-allocation to Operator's Infrastructure

5.4 Registration

5.5 Reverse Lookup

5.6 Existing IPv6 Address Space Holders

5.6.1 LIRs Holding an Allocation

5.6.2 End Users Holding an Allocation

6.0 Special Purposes

6.1 Allocations for Anycasting TLD and Tier 0/1 ENUM Nameservers

6.2 Allocations of Internet Exchange Points

6.3 Allocations for Internet DNS Root Servers

7.0 References

8.0 Appendix A: HD-Ratio

9.0 Appendix B: Background Information

9.1 Background

9.2 Acknowledgment

10.0 Attribution

1.0 Introduction

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

It also describes the policies for IPv6 address space allocated for special purposes, such as Internet Exchange Points and Internet Root Servers.

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 describes the policies concerning the IPv6 allocations and sub-allocations as developed by the RIPE community.

2.0 Definitions

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.

[FC2]

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 their respective regional communities and recognised by IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their service regions.

2.3 Local Internet Registry (LIR)

A Local Internet Registry (LIR) is an IR that primarily sub-allocates address space to the users of the network services that it provides.

2.4 Sponsoring LIR

Members of the RIPE NCC (LIRs) can request allocations on behalf of a third party, and the RIPE NCC will allocate resources directly to this third party. In these cases, the role of the LIR is to facilitate the administrative processes and to maintain a link between the RIPE NCC and the third party that holds the resources. An LIR fulfilling this role is called the Sponsoring LIR for the third party. Third parties can choose another LIR to be their Sponsoring LIR at any time.

2.5 End User

End Users are the private persons or organisations that can receive sub-allocations from an LIR or allocations from the RIPE NCC via a Sponsoring LIR.

2.6 End Site

An End Site is defined as an LIR's or End User's network, device, POP or customer. Sub-allocations made to End Sites are considered to be in use by the End Site and should not be further sub-allocated.

2.7 Allocation

To “allocate” means to distribute address space to LIRs or End Users for the purpose of subsequent distribution by them.

2.8 Sub-allocation

To “sub-allocate” means to distribute address space to customers or members for the purpose of subsequent distribution (sub-allocation) or usage by them.

2.9 Aggregation

To “aggregate” means to register multiple sub-allocations that are of the same size and are used for the same purpose in one RIPE Database object.

2.10 Utilisation

The actual usage of addresses within each sub-allocation may be low when compared to IPv4. 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 sub-allocation of network prefixes to End Sites and not the number of addresses in use within the /56.

2.11 HD-Ratio

The HD-Ratio is a way of measuring the efficiency of address sub-allocation (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 networks sub-allocated from an IPv6 prefix of a given size.

More details are found in Appendix A.

3.0 Goals of IPv6 Address Space Management

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

Every allocation or sub-allocation of address space must be globally unique. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.

3.2 Registration

All allocations, sub-allocations or aggregations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.

Only allocations, sub-allocations or aggregations registered in the RIPE Database are considered valid. Registering objects in the database is the final step in making an allocation, sub-allocation or aggregation. Registration data (range, contact information, status, etc.) has to be maintained and must be correct at all times.

3.3 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, IRs 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.4 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.5 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.6 Minimised Overhead

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

3.7 Conflict of Goals

The goals described above will often conflict with each other, or with the needs of IRs or their customers. When IRs evaluate allocation requests, they must 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.0 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

The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is registered for use rather than owned as an asset.

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

Specifically, IP addresses are allocated based on demonstrated and justified need. These allocations are registered in the RIPE Database. The allocation is only valid for as long as the original criteria under which the organisation qualified for an allocation are still valid.

In cases where the organisation is not using the address space as intended, or is not complying with the policies and/or the responsibilities associated with it, the RIPE NCC reserves the right to deregister the address space.

When requesting additional address space or changes to existing address space, these requests will be evaluated according to the IPv6 policies that are current at that time.

4.2 Routability Not Guaranteed

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

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

4.3 Consideration of IPv4 Infrastructure

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

5.0 Policies for Allocations and Sub-allocations

The RIPE NCC will make allocations to LIRs or End Users (via a Sponsoring LIR) according to sections 5.1 and 5.2 below.

5.1 Initial Allocation

5.1.1 Initial Allocation Criteria

To qualify for an initial allocation of IPv6 address space, an LIR or an End User must have a plan for making sub-allocations to other customers and/or End Sites within two years.

5.1.2 Initial Allocation Size

Allocations made by the RIPE NCC to the LIR have a minimum allocation size of a /32 and may be up to a /29 with no additional documentation required.

Allocations made by the RIPE NCC to the End User have a minimum allocation size of a /32.

LIRs or End Users may qualify for a larger initial allocation by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users, the extent of the organisation's infrastructure and by taking into account growth plans for up to two years in the future.

/48 allocations can be made by the RIPE NCC to End Users that do not expect to ever need more or for special purposes. Special purposes are covered in section 6 of this policy. When an organisation requests a /48 allocation, it must specifically mention in its request that it does not plan to use anything larger in the foreseeable future.

5.1.3 Initial Allocations made to the LIR

To qualify for an allocation, an LIR must submit a request to the RIPE NCC for evaluation.

5.1.4 Initial Allocations made to the End User

To qualify for an allocation, an End User must meet the requirements of the policies described in the RIPE Document ripe-452 or its updates.

The RIPE NCC will allocate the prefix directly to the End User upon a request properly submitted to the RIPE NCC by the Sponsoring LIR.

5.2 Additional Allocation

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

5.2.1 Additional Allocation Criteria

A /32 (or larger when documented) additional allocation may be provided when different routing requirements are demonstrated.

An additional allocation will also be provided when an LIR or End User satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56s. The HD-Ratio (RFC 3194) is used to determine the utilisation thresholds that justify the allocation of additional addresses as described below.

5.2.2 Applied HD-Ratio

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

5.2.3 Additional Allocation Size

When an LIR or an End User has achieved an acceptable utilisation level for its allocated address space, it is immediately eligible to receive an additional allocation that results in a doubling of the address space allocated to it. If an LIR or End User 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 or, where possible, based on the usage of the previous two years.

Where possible, the additional allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one or more bits to the left. An exception is the case when an additional allocation is needed for different routing requirements.

5.3 Sub-allocations

5.3.1 Sub-allocations Made by the LIR or End User

An LIR or End User can make a sub-allocation to a customer encouraging optimum utilisation of the total address block allocated. When more than a /48 is to be sub-allocated to the same customer, the LIR or the End User (via the Sponsoring LIR) must request an approval from the RIPE NCC.

5.3.2 Sub-allocation Size

End Sites or End Users are sub-allocated an IPv6 block. The size of the sub-allocation is a local decision for the LIR or End User to make, using the minimum value of a /64 (if only one subnet is anticipated for the End Site).

A sub-allocation of a /56 or shorter is recommended when two or more subnets are anticipated for the End Site.

5.3.3 Sub-allocation to Operator's Infrastructure

An LIR or an End User may sub-allocate a network prefix per point of presence (PoP) as the service infrastructure of an IPv6 service operator. Each sub-allocation to a PoP is regarded as one regardless of the number of users using the PoP. A separate sub-allocation can be obtained for the operator's in-house operations.

5.4 Registration

When an LIR or an End User holding an IPv6 address allocation makes allocations, sub-allocations or aggregations, these must be registered in the RIPE Database. Multiple sub-allocations which have the same justification can be aggregated. The status “AGGREGATED” can be used in the RIPE Database as long as the inet6num object includes an attribute showing the sub-allocation size within that aggregation. The sub-allocation size can be a number between 48 and 64. Aggregations are multiple contiguous sub-allocations of the same size made to different End Sites for the same purpose. Sub-allocations larger than a /48 cannot be part of an aggregation. These must be registered separately in the RIPE Database.

In the case of an audit or when making a request for a subsequent allocation, the LIR or the End User must be able to present statistics showing the number of individual sub-allocations made in all objects with a status of “AGGREGATED” in such a way that the RIR is able to calculate and verify the actual HD-Ratio.

5.5 Reverse Lookup

When an RIR allocates IPv6 address space to an LIR or an End User, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each LIR or End User should properly manage its reverse lookup zone. When making sub-allocations, the LIR or the End User can delegate to its customer, upon request, the responsibility to manage the reverse lookup zone that corresponds to the sub-allocated block.

5.6 Existing IPv6 Address Space Holders

5.6.1 LIRs Holding an Allocation

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 LIR's existing allocations and avoid allocating non-contiguous space.

5.6.2 End Users Holding an Allocation

The RIPE NCC has previously made IPv6 assignments. These assignments have been transformed automatically by the RIPE NCC in IPv6 allocations.

End Users holding an allocation lower than a /32 (except those made for special purposes) can request an extension of this allocation to a /32. Where this extension is not possible, the organisation has the option to return the allocation and automatically receive a /32 (or larger if justified).

6.0 Special Purposes

Allocations made by the RIPE NCC for these special purposes are subject to the policies described in the RIPE Document ripe-452 or its updates.

These allocations will be made from a separate “designated block” to facilitate filtering practices and must be returned to the RIPE NCC if no longer in use for the purpose they were allocated for.

6.1 Allocations for 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 BCP 126/RFC 4786.

These allocations are registered with a status of “ALLOCATED-FOR-ANYCAST” or “ALLOCATED-FOR-ENUM” in the RIPE Database and must be returned to the RIPE NCC if no longer in use for infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services.

6.2 Allocations for Internet Exchange Points

The organisations applicable under this policy are Internet Exchange Points (IXPs), which are 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. These organisations must have at least three ISPs connected and there must be a clear and open policy for others to join.

These organisations may receive one /48 allocation. The prefix must be used for the sole purpose of operating the IXP. The allocation is registered with a status of “ALLOCATED-FOR-IXP” in the RIPE Database and must be returned to the RIPE NCC if no longer in use for IXP services.

6.3 Allocations for Internet DNS Root Servers

DNS resolvers and resolving name servers need to be pre-configured with the network addresses of the root name servers. This makes these addresses special and not easily changed.

Each (current or future) Internet DNS root server (as listed in the DNS root-servers.net zone) in the RIPE NCC service region will be allocated a block of IPv6 address space for the purpose of root server operations. The size of the block shall be the same as the size of the minimum allocation to LIRs at the time of the root server allocation.

The allocated prefix must be used for root server operations and support functions directly related to these operations, such as monitoring, statistics, etc. The allocated prefix is bound to the root server service itself and is not associated with the organisation(s) that operate the root server at a particular point in time. The allocation is registered with a status of “ALLOCATED-FOR-INTERNET-DNS-ROOT” in the RIPE Database.

These organisations should not use the address space to provide any services that are not related to the root server.

If the operational responsibility for a root server moves to a new organisation, the RIPE NCC should be notified so it can make the necessary updates to reflect this change.

If the new location of the root server is outside the RIPE NCC service region, the address space must be returned to the RIPE NCC and a new allocation or assignment must be requested from the appropriate RIR.

If a root server stops operating completely, the address space must be returned to the RIPE NCC. The RIPE NCC will mark the prefix as "reserved" for a suitably long period of time.

7.0 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

8.0 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 the subsequent allocation of an 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.

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.

9.0 Appendix B: Background information

9.1 Background

In 1999, the first provisional IPv6 policy was published in all regions.

This document was replaced in 2002 by a joint policy document. At the time it was considered important to have one policy for all regions to prevent RIR shopping. Regional policies started diverging from each other from 2004 onwards.

9.2 Acknowledgment

The following people contributed to the initial version of this document: Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, Toshiyuki Yamasaki, Thomas Narten, David Kessens, John Crain, Steve Deering, Gert Doering, Richard Jimmerson, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Ray Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Wittbrodt and Wilfried Woeber.

10.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 (PDP):

Brett Carr, Ondrej Sury, Jordi Palet Martinez, Andy Davidson, Rob Evans, Kurtis Lindqvist, Geoff Huston, Elvis Daniel Velea, Daniel Stolpe, Olaf Sonderegger.