DRAFT: IPv6 Address Allocation and Assignment Policy

How to read this draft document:

This document relates to RIPE policy proposal 2005-08: Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy. If approved, it will replace ripe-388. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

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

All other text in the document will not be replaced.

Abstract

Table of 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

ORIGINAL TEXT	NEW TEXT
5.4.2. Assignment of multiple /48s to a single end site	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. Assignments for Internet Experiments

6.1 Defining the experiment
6.2 Publication
6.3 Non-commercial basis
6.4 Period of the temporary resource registration
6.5 Registration
6.6 Making the request
6.7 Nota bene

7. References

8. Appendix A: HD-Ratio

9. Appendix B: Background information

9.1. Background
9.2. Why a joint policy
9.3. The size of IPv6's address space
9.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.

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

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 [RFC1715] and is expressed as follows:

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

2.9. End Site

An End Site is defined as an End User (subscriber) who has a business relationship 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

RIRs will apply a minimum size for IPv6 allocations to facilitate prefix-based filtering.

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

4.4. Consideration of IPv4 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) not be an End Site;

5.1.2. Initial allocation size

Organisations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32.

Organisations may qualify for an initial allocation greater than /32 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

5.2.2. Applied HD-Ratio

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

5.4.3. Assignment to operator's infrastructure

5.5. Registration

RIR/NIRs will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time.

IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.

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

Organisations that received /35 IPv6 allocations under the previous IPv6 address policy [RIRv6-Policies] are immediately entitled to have their allocation expanded to a /32 address block without providing justification so long as they satisfy the criteria in Section 5.1.1. The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organisation. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document.

6.0 Assignments for Internet Experiments

Organisations often require deployment tests for new Internet services and technologies. These require numbering resources for the duration of the test.

The policy goal of resource conservation is of reduced importance when resources are issued on a temporary basis.

6.1 Defining the experiment

An organisation receiving numbering resources must document the experiment. This may be in the form of a current IETF Experimental RFC (http://www.ietf.org/rfc/rfc2026.txt see Sec. 4.2.1) or an “experiment proposal” detailing the resources required and the activities to be carried out.

The assignment size will be equal to the existing minimum allocation size on the date the request is received. Where the experiment requires a variation to this rule it should be noted in the resource request.

6.2 Publication

The experiment proposal must be made public (e.g. published on web site), upon registration of the resources by the RIPE NCC. Following the conclusion of the experiment the results must be published free of charge and free from disclosure constraints.

6.3 Non-commercial basis

Resources issued for an experiment must not be used for commercial purposes.

6.4 Period of the Temporary Resource Registration

The resources will be issued on a temporary basis for a period of one year. Renewal of the resource’s registration is possible on receipt of a new request that details any continuation of the experiment during the extended period.

The resources issued cannot be used for a commercial service following the conclusion of the experiment.

6.5 Registration

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

6.6 Making the request

The request must be made by a Local Internet Registry (LIR) using the appropriate request form for the resource found at:

http://www.ripe.net/ripe/docs/internet-registries.html#request

7. References

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

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

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

[RFC3194] "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.

8. Appendix A: HD-Ratio

P    48-P          Total /48s        Threshold      Util%


48       0                   1                1     100.0%
47       1                   2                2      87.1%
46       2                   4                3      75.8%
45       3                   8                5      66.0%
44       4                  16                9      57.4%
43       5                  32               16      50.0%
42       6                  64               28      43.5%
41       7                 128               49      37.9%
40       8                 256               84      33.0%
39       9                 512              147      28.7%
38      10                1024              256      25.0%
37      11                2048              446      21.8%
36      12                4096              776      18.9%
35      13                8192             1351      16.5%
34      14               16384             2353      14.4%
33      15               32768             4096      12.5%
32      16               65536             7132      10.9%
31      17              131072            12417       9.5%
30      18              262144            21619       8.2%
29      19              524288            37641       7.2%
28      20             1048576            65536       6.3%
27      21             2097152           114105       5.4%
26      22             4194304           198668       4.7%
25      23             8388608           345901       4.1%
24      24            16777216           602249       3.6%
23      25            33554432          1048576       3.1%
22      26            67108864          1825677       2.7%
21      27           134217728          3178688       2.4%
20      28           268435456          5534417       2.1%
19      29           536870912          9635980       1.8%
18      30          1073741824         16777216       1.6%
17      31          2147483648         29210830       1.4%
16      32          4294967296         50859008       1.2%
15      33          8589934592         88550677       1.0%
14      34         17179869184        154175683       0.9%
13      35         34359738368        268435456       0.8%
12      36         68719476736        467373275       0.7%
11      37        137438953472        813744135       0.6%
10      38        274877906944       1416810831       0.5%
9       39        549755813888       2466810934       0.4%
8       40       1099511627776       4294967296       0.4%
7       41       2199023255552       7477972398       0.3%
6       42       4398046511104      13019906166       0.3%
5       43       8796093022208      22668973294       0.3%
4       44      17592186044416      39468974941       0.2%

9. Appendix B: Background information

9.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 experiments. As a result, Section 6 was added to this document in January 2003.

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

9.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 [RFC2373], 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 [RFC2462].

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

The final editing of the initial version of this document was done by Thomas Narten.