Establishment of global IPv6 address policies


7 April 2003 By Takashi Arano

In RFC1881, the IETF community recognized the Internet Assigned Numbers Authority (IANA)as the appropriate entity to have the responsibility for the management of the IPv6 address space. IANA does this administration under the direction of the IAB and IESG. IANA, in turn, allocates IPv6 blocks to the RIRs for further allocation to their members. The IP address policies explained in this article are the framework by which RIRs, and other downstream IRs, manage these addresses.

IP address space, which is a finite public resource, must be managed in a prudent manner with regards to the long-term interests of the Internet. This responsibility is undertaken by RIRs, in accordance with an agreed set of specific technical goals which support Internet growth and stability, and management goals which support security and access to the resources. The six goals in IPv6 address space management are as follows.

1. Guarantee of uniqueness

Every assignment and/or allocation of address space must guarantee uniqueness worldwide, in order to allow each end node to be identified uniquely.

2. Registration

Every assignment and allocation of address space must be registered in a publicly accessible database. It is necessary that the database is able to immediately identify the party responsible for the management of any given IP address or block of addresses.

3. Aggregation of routing information

The idea is to ensure that as far as possible, sites connected close to each other in the network topology have adjacent address blocks, so that a single routing prefix announcement can cover many sites. This enables reduction of router loads and contributes to the scalability and stability of the Internet routing system.

4. Conservation

Although IPv6 provides an extremely large pool of address space, address policies should try to minimise wasteful assignments to organizations and make effective use of the available address space wherever possible.

5. Fairness

Since IP addresses are public resources, they should wherever possible be fairly assigned. Address policies need to avoid assigning more addresses to specific organizations, countries, regions, and industries.

6. Minimized Overhead

It is desirable to minimize the overhead associated with obtaining address space.

However, these six goals are mutually conflicting. If the focus is only on the aggregation of routing information, for instance, address space would be wasted and address conservation could not be achieved. On the other hand, an approach of maximising conservation would threaten aggregation, increase administrative overheads and reduce fairness in actual address policies. Thus address policies should be developed by balancing the above goals.

In the past, each registry, as an organization making allocation and assignments, developed its own policies independently. However, as a result of strong requests for a well-balanced policy, changes have been instigated by community consensus at Regional Open Policy Meetings. At these meetings, opinions are gathered from a wide range of interested parties which encourages well-balanced policy-making.

The former IPv6 address policy was first established in May 1999. This policy was developed provisionally by RIRs, based on the requirements of the IPv6 address architecture defined in RFC 2374.

However, because the policy was based on an IETF architectural document rather than on existing experience in address management, it had numerous inconsistencies and problems. As a provisional policy, it also left a lot of other details undefined. Now that the actual implementation of IPv6 is underway, it has become necessary to quickly revise this policy and establish a new policy appropriate for actual network use. Particularly in Japan and in the Asian region, there are many Internet Service Providers (ISP) who have already started commercial service and have been conducting experiments in this field. The need for a new, clearer, and comprehensive IPv6 policy in this region was the strongest in the world.

Within this background, a new IPv6 policy was proposed at the APNIC Open Policy Meeting in Taipei in August 2001. Following this, about a year later, consensus for all of the basic ideas of this policy was achieved at a series of RIRs' meetings in March and April 2002 (APNIC in Bangkok in March, ARIN in Las Vegas in April, RIPE-NCC in Amsterdam in April). On July 1st, 2002, the new IPv6 policy was established and implemented throughout the world.

The main points of the new policy are briefly discussed as follows. Please refer to the most recent document for more exact and detailed description at:

1. Compared to the IPv4 address policy, the goal of aggregation 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.

2. Initial allocation criteria 1

  1. Organizations that are eligible to receive an address assignment must:
    1. be a Local Internet Registry (LIR);
    2. not be an end site;
    3. have a plan for providing IPv6 connectivity to organizations to which they will assign /48s, by advertising that connectivity through their aggregated address allocations; and
    4. expect to make at least 200 /48 assignments within two years.
  2. Initial allocation size
    1. When an organization satisfies the above criteria, it is able to receive an allocation of /32.
    2. When an organization needs a larger block than /32, it may qualify to receive that allocation by providing the required documentation. In such case, IPv6 address requirements may be assessed according to existing IPv4 infrastructure and customer base.

3. Subsequent request criteria

  1. Address utilisation requirement
    1. IPv6 address space utilization is measured according to the "HD-Ratio" [RFC 3194], which is calculated as follows:

                      Log (number of assigned objects)
      HD Ratio = ---------------------------------------
                       Log (maximum number of assignable objects)
    2. A subsequent allocation may be provided when an organization has met the minimum address utilization requirement, in terms of the number of /48 site assignments which have been made. This minimum is an HD-Ratio of 0.8
  2. Subsequent allocation size
    1. When an organization meets the above criteria, it is able to receive an additional allocation that results in doubling of its address space.
    2. Where possible, this additional allocation will be provided from the neighbouring address.
    3. When an organization needs a larger amount of address space, it should submit documentation to justify the amount that will be needed for the next two years. Evaluation of the request will be based on this amount.

4. Assignment to an end site

  1. Definition of an end site

    An end site is defined as an end user (subscriber) who has a business relationship with a service provider such that:
    • the service provider assigns address space to the end user;
    • the service provider provides transit service for the end user to other sites;
    • the service provider carries the end user's traffic; and
    • the service provider advertises an aggregate prefix route that contains the end user's assignment.
  2. Assignment address space size (in accordance with RFC 3177)
    1. Except for very large subscribers, the general assignment size is /48.
    2. When it is known that subscribers have only one subnet according to their specification, an assignment of /64 will be provided.
    3. When it is absolutely known that only one device is connecting, an assignment of /128 will be provided.
  3. RIRs/NIRs are not concerned about which address an LIR/ISP assigns. Therefore, RIRs/NIRs will not require detailed information about users' networks. This point differs from the IPv4 address policy.
  4. When a single site needs multiple or additional /48 address blocks, it may be eligible to receive the assignment by providing documentation to justify its validity. This type of request will be evaluated at RIR/NIR level.
  5. A /48 address block can be assigned to operators' infrastructure per one PoP. Also, it is considered as one assignment regardless of the number of end users who use the PoP. In addition, other assignment for the operators' in-house work can also be obtained.

5. Registration in the database

  1. It is necessary that all information on address allocations and assignments that are /48 or larger is registered in the public database.
  2. RIRs/NIRs use the registration data when they calculate the HD-Ratio at the application for subsequent address allocation.
  3. IRs should operate a system protecting the security of personal and commercial information collected at the time of evaluation of the request.

6. Reverse DNS delegation

  1. When an RIR/NIR allocates IPv6 address space to organizations, it delegates the reverse zones that correspond to the allocated space at the same time.
  2. LIRs should manage those reverse zones properly. Also, when making assignments to end sites, LIRs should delegate the reverse zones of the assigned address to the organizations to which they allocated the address on their requests basis.

7. Existing IPv6 space holders

  1. An organization that has received a /35 allocation can immediately expand that space to a /32 without the need to provide technical justification.

Finally, I would like to express my appreciation for the editorial team of IPv6 address policy and the drafting team in Japan who supported this activity. Policies are "alive", and more revision will be required, subject to the future progress of IPv6 deployment and the experience gained therein. Your continuous support is highly appreciated.

I appreciate Paul Wilson and Anne Lord of APNIC who proofread this article and gave me a lot of useful suggestions.

Appendix: Abbreviation list in alphabetical order

APNIC: Asia Pacific Network Information Centre
ARIN: American Registry for Internet Numbers
IR: Internet Registry
LIR: Local Internet Registry
NIR: National Internet Registry
RIPE-NCC: Réseaux IP Européens Network Coordination Centre
RIR: Regional Internet Registry

1. IAB-Request

1. Please note that there are two types of "address distribution". One is that address blocks are provided not for the direct use by the organization that received address, but for subsequent distribution to the downstream. The other is to distribute the address to the downstream for the actual use. In address policies, we call the former "Allocation" and the latter "Assignment", and we strictly differentiate them.

This article is also available in PDF and ASCII

Expanded Coverage from ISOC

In-depth articles, papers, links and other resources on a variety of topics are available from the ISOC site at:

Examples in the News

Waiting for IP version 6 By Geoff Huston

Response by IPv6 Forum to ISP Column article entitled Waiting for IP version 6: by Geoff Huston

Relevant IETF RFCs

RFC 3363
Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)

RFC 3307
Allocation Guidelines for IPv6 Multicast Addresses

RFC 3306
Unicast-Prefix-based IPv6 Multicast Addresses

RFC 2732
Format for Literal IPv6 Addresses in URL's

For More Information

Related Organizations

About the Author

Photo of Takashi AranoTakashi Arano is CTO of Intec NetCore, Inc. After receiving his Master of Science degree from the University of Tokyo, he lead NTT's Internet department as chief engineer. He joined Intec NetCore in June 2002. Takashi has contributed to the Internet, especially in the address management and IPv6 area, by holding positions of ICAAN ASO Address Council (1999-), Chair of APNIC Address Policy SIG (2000-), and Program Chair of the first Global IPv6 Summit in Asia Pacific (2003).


The ISOC Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: Afilias, APNIC, ARIN, Microsoft, and the RIPE NCC, Sida. More information on the Platinum Sponsorship Program...

About the Background Paper Series

Published by:
The Internet Society
1775 Wiehle Avenue, Suite 102
Reston, Virginia 20190 USA
Tel: +1 703 326 9880
Fax: +1 703 326 9881

4, rue des Falaises
CH-1205 Geneva
Tel: +41 22 807 1444
Fax: +41 22 807 1445


Series Editor: Martin Kupres

Copyright C Internet Society 2005.
All rights reserved.