ACSP Suggestion 2007.1: The IPv6 Assignment and Allocation Policy Proposal

Suggestion

Author: Peter Sherbin   
Submitted On: 02 January 2007

Description:

Version 2007.1 - 3 January 2007

Contents

  1. Introduction
    1.1. Overview
  2. Definitions
    2.1. Regional Internet Registry (RIR)
    2.2. National Internet Registry (NIR)
    2.3. Internet Operator (IO)
    2.4. Tax Agency (TA)
    2.5. Allocate
    2.6. Assign
    2.7. Utilization
    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. Minimized overhead
    3.8. Conflict of goals
  4. IPv6 Policy Principles
    4.1. Address Space not to be considered to be property
    4.2. Routability not guaranteed
    4.3. Minimum allocation
  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. Assignments from TA
    5.3.1. Assignment address space size
    5.3.2. Assignment of multiple /48s to single end site
    5.3.3. Assignment to operator’s infrastructure
    5.4. Registration (reassignment information)
    5.4.1. Residential Customer Privacy
    5.5. Reverse lookup
    5.6. Existing IPv6 address space holders
    5.7 Direct assignments from ARIN to end user organizations
    5.7.1 Criteria
    5.7.2 Initial assignment size
    5.7.3 Subsequent assignment size
  6. References
  7. Appendix A - HD-Ratio

Abstract
This document proposes new registry policies for the assignment and allocation of globally-unique IPv6 addresses to individuals and organizations.
1.1. Introduction
1.1. Overview
Report from the IAB Workshop on Routing and Addressing (draft-iab-raws-report-00.txt) identifies “the need to devise a scalable routing and addressing system” for the Internet as the highest priority.
This document describes new policies for the allocation and assignment of globally-unique Internet Protocol Version 6 (IPv6) address space. Proposed policies are intended to be adopted by each registry. Adoption of the policies does not preclude regional variations.
(RFC2373, RFC2373bis) designate 2000::/3 to be global unicast address space that IANA may allocate to the RIRs. In accordance with (RFC2928, RFC2373bis, IAB-Request), IANA has allocated initial ranges of global unicast IPv6 address space from the 2001::/16 address block to the existing RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies.
If this proposal becomes a policy it may be reviewed in the future reflecting greater experience in the IPv6 administration.
2. Definitions
The following terms and their definitions are important to understand the goals, environment, and policies described in this document.
IPv6 address space is managed globally in accordance with the proposed hierarchical structure shown below.
2.1. Regional Internet Registry (RIR)
Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to distribute public IP address space to its members or customers and for registering those distributions.
2.2. National Internet Registry (NIR)
A National Internet Registry (NIR) primarily allocates address space to its members or constituents, which are generally Internet Operators and Tax Agencies, organized at a national level. NIRs exist mostly in the Asia Pacific region.
2.3. Internet Operator (IO)
An Internet Operator (IO) is an entity supporting a part of the global Internet routing infrastructure. IO’s function is to aggregate and route packets from End Users. IO follows aggregation rules set by its RIR and it does not distribute IP addresses.
2.4 Tax Agency (TA)
A Tax Agency (TA) is a given state tax authority that assigns address space to all its registrants bearing an identification number.
2.5. Allocate
To allocate means to distribute address space to RIR, NIR or TA for the purpose of subsequent distribution by them.
2.6. Assign
To assign means to delegate address space to an end-user. End-users may keep assigned addresses as long as they keep identification numbers from their TA. Assigned IP addresses can be returned to the original TA at any time but they are not to be sub-assigned to other parties.
2.7. Utilization
In IPv6, “utilization” is only measured in terms of the bits to the left of the /56 boundary. In other words, utilization refers to the assignment of /56s to end sites, and not the number of addresses assigned within individual /56s at those end sites.
Throughout this document, the term utilization refers to the allocation of /56s to end sites, and not the number of addresses assigned within individual /56s 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 (RFC1715) and is expressed as follows:
HD = Log (number of allocated objects)
Log (maximum number of allocatable objects)
where (in the case of this document) the objects are IPv6 site addresses (/56s) assigned from an IPv6 prefix of a given size.
2.9. End site
An end site is defined as an end user who has an identification number from the local TA.
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. Address space management involves balancing a set of sometimes competing goals. The following are the goals of 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 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 to end users.
The goal of registration should be applied within the context of 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 IOs, 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 maximize 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. Minimized Overhead
It is desirable to minimize 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 RIRs or end users. All RIRs 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 to be property
IP address space is not a freehold property.
The policies in this document are based upon the understanding that globally-unique IPv6 unicast address space is not owned.
In those cases where a requesting organization or an individual are not using the address space as intended, RIRs reserve the right to revoke the assigned address space.
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 /20.
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 organization must:
a. be a RIR, a NIR or a TA
b. not be an end site
5.1.2. Initial allocation size
Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /20.
Organizations may qualify for an initial allocation greater than /20 by submitting documentation that justifies the request.
5.2. Subsequent allocation
Organizations 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 organization (RIR, NIR, TA) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments. The HD-Ratio (RFC 3194) is used to determine the utilization 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 acceptable address utilization 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 utilization value for a given address block size.
5.2.3. Subsequent Allocation Size
When an organization has achieved an acceptable utilization 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 organization 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. Assignments from TA
TA must make IPv6 assignments in accordance with the following provisions.
5.3.1. Assignment address space size
End-users receive an end site assignment from their TA. The following guidelines may be useful (but they are only guidelines):
• /56 for sites expected to need only a few subnets over the next 5 years
• /48 for larger sites
RIRs/NIRs are not concerned about which address size TAs actually assign. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 address assignments, except for the purposes of measuring utilization as defined in this document.
5.3.2. Assignment of multiple /48s to a single end site
When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s 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 /48s 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.
5.3.3. Assignment to operator’s infrastructure
RIR/NIR may assign routing aggregation numbers to IO according to routing architecture determined by IETF.
5.4. Registration
When TA makes IPv6 address assignments, it must register assignment information in an RIR/NIR database. Information is registered in units of assigned /56 networks.
RIR/NIR 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.
RIR/NIR and TA 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.4.1. Residential Customer Privacy
TA shall maintain the privacy of residential customers.
5.5. Reverse lookup
RIR/NIR delegates to IO the responsibility to manage the reverse lookup zone that corresponds to the IPv6 address space assigned to EU of that IO. Each IO should properly manage its reverse lookup zone. IO must delegate to its EU, upon request, the responsibility to manage the reverse lookup zone that corresponds to that EU assigned address.
5.6. Existing IPv6 address space holders
Organizations 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 organization. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document.
5.7. Direct assignments from ARIN to EU organizations
5.7.1. Criteria
To qualify for a direct assignment, an organization must:
a. not be a TA; and
b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect.
5.7.2. Initial assignment size
Organizations that meet the direct assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets.
These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44.
5.7.3. Subsequent assignment size
Additional assignments may be made when the need for additional subnets is justified. When possible, assignments will be made from an adjacent address block.
6. References
(RFC1715) “The H Ratio for Address Assignment Efficiency”, C. Huitema. November 1994, RFC 1715.
(IAB-Request) “Email from IAB to IANA”, http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt.
(RFC2373) “IP Version 6 Addressing Architecture”, R. Hinden, S. Deering. July 1998, RFC 2373.
(RFC2373bis) http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt.
(RFC2928) “Initial IPv6 Sub-TLA ID Assignments”, R. Hinden, S. Deering, R. Fink, T. Hain. September 2000, RFC 2928.
(RFC3177) “IAB/IESG Recommendations on IPv6 Address”. IAB, IESG. September 2001, RFC 3177.
(RFC3194) “The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio”, A. Durand, C. Huitema. November 2001, RFC 3194.
(RIRs-on-48) http://www.arin.net/policy/archive/IPv6reassign.html,
(RIRv6-Policies)
http://www.afrinic.net/policy.htm
http://www.arin.net/policy/nrpm.html#IPv6
http://lacnic.net/en/politicas/index.html
http://www.ripe.net/ripe/docs/IPv6policy.html
http://www.apnic.net/docs/policy/IPv6-address-policy.html
7. Appendix A: HD-Ratio
The HD-Ratio requires counting the number of assigned objects. The primary value of the HD-Ratio is its usefulness at determining reasonable target utilization threshold values for an address space of a given size. This document uses the HD-Ratio to determine the thresholds at which a given allocation has achieved an acceptable level of utilization and the assignment of additional address space becomes justified.
The utilization 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 utilization threshold for an organization requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilization refers to the allocation of /56s to end sites, and not the utilization of those /56s within those end sites. It is an address allocation utilization ratio and not an address assignment utilization ratio.
The following table provides equivalent absolute and percentage address utilization figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94
P 56 - P Total /56s Threshold Util %
56 0 1 1 100.0%
55 1 2 2 95.9%
54 2 4 4 92.0%
53 3 8 7 88.3%
52 4 16 14 84.7%
51 5 32 26 81.2%
50 6 64 50 77.9%
49 7 128 96 74.7%
48 8 256 184 71.7%
47 9 512 352 68.8%
46 10 1,024 676 66.0%
45 11 2,048 1,296 63.3%
44 12 4,096 2,487 60.7%
43 13 8,192 4,771 58.2%
42 14 16,384 9,153 55.9%
41 15 32,768 17,560 53.6%
40 16 65,536 33,689 51.4%
39 17 131,072 64,634 49.3%
38 18 262,144 124,002 47.3%
37 19 524,288 237,901 45.4%
36 20 1,048,576 456,419 43.5%
35 21 2,097,152 875,653 41.8%
34 22 4,194,304 1,679,965 40.1%
33 23 8,388,608 3,223,061 38.4%
32 24 16,777,216 6,183,533 36.9%
31 25 33,554,432 11,863,283 35.4%
30 26 67,108,864 22,760,044 33.9%
29 27 134,217,728 43,665,787 32.5%
28 28 268,435,456 83,774,045 31.2%
27 29 536,870,912 160,722,871 29.9%
26 30 1,073,741,824 308,351,367 28.7%
25 31 2,147,483,648 591,580,804 27.5%
24 32 4,294,967,296 1,134,964,479 26.4%
23 33 8,589,934,592 2,177,461,403 25.3%
22 34 17,179,869,184 4,177,521,189 24.3%
21 35 34,359,738,368 8,014,692,369 23.3%
20 36 68,719,476,736 15,376,413,635 22.4%
19 37 137,438,953,472 29,500,083,768 21.5%
18 38 274,877,906,944 56,596,743,751 20.6%
17 39 549,755,813,888 108,582,451,102 19.8%
16 40 1,099,511,627,776 208,318,498,661 18.9%
15 41 2,199,023,255,552 399,664,922,315 18.2%
14 42 4,398,046,511,104 766,768,439,460 17.4%
13 43 8,796,093,022,208 1,471,066,903,609 16.7%
12 44 17,592,186,044,416 2,822,283,395,519 16.0%
11 45 35,184,372,088,832 5,414,630,391,777 15.4%
10 46 70,368,744,177,664 10,388,121,308,479 14.8%
9 47 140,737,488,355,328 19,929,904,076,845 14.2%
8 48 281,474,976,710,656 38,236,083,765,023 13.6%
7 49 562,949,953,421,312 73,357,006,438,603 13.0%
6 50 1,125,899,906,842,620 140,737,488,355,328 12.5%
5 51 2,251,799,813,685,250 270,008,845,646,446 12.0%
4 52 4,503,599,627,370,500 518,019,595,058,136 11.5%

Timeframe: six to twelve months (accommodating the new architecture considered by IETF at the moment)

Status: Completed   Updated: 04 January 2007

Tracking Information

ARIN Comment

4 January 2007

Author referred to the Internet Resource Policy Development Process (IRPEP).

Suggestion 2007.1 is now closed.

Related