1 Mataur

Iana Ipv6 Global Unicast Address Assignments Images

Publication date: 01 Oct 2015

This document is obsoleted by ripe-681


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.


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. Transfer of IPv6 resources
9. References
10. Appendix A: HD-Ratio
11. Appendix B: Background information
11.1. Background
11.2. Why a joint policy?
11.3. The size of IPv6's address space
11.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 users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation.

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

8. Transfer of IPv6 resources

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

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


Total /56s

/56s HD 0.94

Util %





























































































11. Appendix B: Background information

11.1. Background

Any holder of IPv6 address space is allowed to transfer complete or partial blocks of IPv6 address space that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry system.

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 size at the time of re-allocation.

Provider Independent (PI) address space may only be re-assigned in accordance with the RIPE Document, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The block that is to be re-assigned must not be smaller than the minimum assignment block size at the time of re-assignment.

Transfers must be reflected in the RIPE Database. This transfer may be on either a permanent or non-permanent basis.

The RIPE NCC will record the change of address space after the transfer.

The RIPE NCC will publish a list of all allocations and assignments 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 organisations involved will be identified in these statistics.

The transferring party always remains responsible for the entire address block it receives from the RIPE NCC until the transfer of address space to another party is completed or the address space is returned. The transferring party must ensure that all policies are applied.

Transferred address blocks are no different from the allocations or assignments made directly by the RIPE NCC and so they must be used by the receiving party according to the policies described in this document.

In this lesson we’ll take a look how you can create IPv6 prefixes and subnets so that you can configure your entire network with IPv6. We’ll start at the top where IANA (Internet Assigned Numbers Authority) is responsible for the global coordination of the IPv4 and IPv6 address space and move our way all the way to the bottom where we assign subnets and IPv6 addresses to our routers, switches and VLANs.

IPv6 Global Unicast Prefix Assignments

IANA “owns” the entire IPv6 address space and they assign certain prefixes to the RIRs (Regional Internet Registry). There are 5 RIRs at the moment:

  • AFRINIC: Africa
  • APNIC: Asia/Pacific
  • ARIN: North America
  • LACNIC: Latin America and some Caribbean Islands
  • RIPE NCC: Europe, Middle east and Central Asia

If you are interested, click here for an overview of all IPv6 prefix assignments by IANA.

When a large ISP (or large company) in North America wants IPv6 addresses then they will contact ARIN who will assign them an IPv6 prefix if they meet all requirements. The ISP can then assign prefixes to their customers.

Let’s take a look at some actual prefixes:

  • IANA is using the 2000::/3 prefix for global unicast address space.
  • According to this list, RIPE NCC received prefix 2001:4000::/23 from IANA.
  • A large ISP called Ziggo in The Netherlands receives prefix 2001:41f0::/32 from RIPE NCC.
  • The ISP assigns prefix 2001:41f0:4060::/48 to one of their customers.

Now it’s up to the customer what they want to do with their IPv6 prefix…

IPv6 Global Unicast Subnet Assignments

Our customer received prefix 2001:41f0:4060::/48 and they want to use it to configure IPv6 on their entire network. Where do we start? Take a look at the image below:

The 48-bit prefix that we received is typically called the global routing prefix or site prefix. The interface ID is normally 64 bit which means we have 16 bits left to create subnets.

If I want I can steal some more bits from the Interface ID to create even more subnets but there’s no need for this. Using 16 bits we can create 65.536 subnets …more than enough for most of us. Let’s see what we can do for our customer:

Leave a Comment


Your email address will not be published. Required fields are marked *