|
apnic-089-v004.txt |
|
apnic-089-v005.txt |
|
|
——————————————————————- |
|
——————————————————————- |
|
|
APNIC Document identity |
|
APNIC Document identity |
|
|
|
|
|
|
|
Title: IPv6 Address Allocation and Assignment Policy |
|
Title: IPv6 Address Allocation and Assignment Policy |
|
|
|
|
|
|
|
Short title: ipv6-address-policy |
|
Short title: ipv6-address-policy |
|
|
Document ref: APNIC-089 |
|
Document ref: APNIC-089 |
|
|
|
Version: 004 |
|
Version: 005 |
|
|
Date of original publication: 1 July 2002 |
|
Date of original publication: 1 July 2002 |
|
|
|
Date of this version: 15 January 2007 |
|
Date of this version: 19 March 2007 |
|
|
Review scheduled: n/a |
|
Review scheduled: n/a |
|
|
Obsoletes: Previous versions |
|
Obsoletes: Previous versions |
|
|
Status: Obsolete |
|
Status: Obsolete |
|
|
Comments: n/a |
|
Comments: n/a |
|
|
——————————————————————– |
|
——————————————————————– |
|
|
|
|
|
|
|
IPv6 Address Allocation and Assignment Policy |
|
IPv6 Address Allocation and Assignment Policy |
|
|
|
|
|
|
|
Status of this Memo |
|
Status of this Memo |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 102 |
|
skipping to change at line 102 |
|
|
5.4.1. Assignment address space size |
|
5.4.1. Assignment address space size |
|
|
5.4.2. Assignment of multiple /48s to a single end site |
|
5.4.2. Assignment of multiple /48s to a single end site |
|
|
5.4.3. Assignment to operator’s infrastructure |
|
5.4.3. Assignment to operator’s infrastructure |
|
|
|
|
|
|
|
5.5. Registration |
|
5.5. Registration |
|
|
|
|
|
|
|
5.6. Reverse lookup |
|
5.6. Reverse lookup |
|
|
|
|
|
|
|
5.7. Existing IPv6 address space holders |
|
5.7. Existing IPv6 address space holders |
|
|
|
|
|
|
|
|
5.8. Assignments to IXPs and critical infrastructure |
|
5.8. Portable assignments |
|
|
|
|
|
|
|
|
5.8.1. Internet Exchange Points |
|
5.8.1. Small multihoming assignments |
|
|
5.8.2. Critical infrastructure |
|
5.8.2. Internet Exchange Points |
|
|
|
|
5.8.3. Critical infrastructure |
|
|
|
|
|
|
|
6. References |
|
6. References |
|
|
|
|
|
|
|
7. Appendix A: HD-Ratio |
|
7. Appendix A: HD-Ratio |
|
|
|
|
|
|
|
8. Appendix B: Background information |
|
8. Appendix B: Background information |
|
|
|
|
|
|
|
8.1. Background |
|
8.1. Background |
|
|
8.2. Why a joint policy |
|
8.2. Why a joint policy |
|
|
8.3. The size of IPv6’s address space |
|
8.3. The size of IPv6’s address space |
|
|
|
|
|
|
|
skipping to change at line 136 |
|
skipping to change at line 137 |
|
|
document are intended to be adopted by each registry. However, |
|
document are intended to be adopted by each registry. However, |
|
|
adoption of this document does not preclude local variations in each |
|
adoption of this document does not preclude local variations in each |
|
|
region or area. |
|
region or area. |
|
|
|
|
|
|
|
[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast address |
|
[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast address |
|
|
space that IANA may allocate to the RIRs. In accordance with |
|
space that IANA may allocate to the RIRs. In accordance with |
|
|
[RFC2928, RFC2373bis, IAB-Request], IANA has allocated initial ranges |
|
[RFC2928, RFC2373bis, IAB-Request], IANA has allocated initial ranges |
|
|
of global unicast IPv6 address space from the 2001::/16 address block |
|
of global unicast IPv6 address space from the 2001::/16 address block |
|
|
to the existing RIRs. This document concerns the initial and |
|
to the existing RIRs. This document concerns the initial and |
|
|
subsequent allocations of the 2000::/3 unicast address space, for |
|
subsequent allocations of the 2000::/3 unicast address space, for |
|
|
|
which RIRs formulate allocation and assignment policies. Because end |
|
which RIRs formulate allocation and assignment policies. |
|
|
sites will generally be given /48 assignments [RFC 3177, RIRs- |
|
|
|
|
on-48s], the particular emphasis of this document is on policies |
|
|
|
|
relating the bits within 2000::/3 to the left of the /48 boundary. |
|
|
|
|
However, since some end sites will receive /64 and /128 assignments, |
|
|
|
|
all bits to the left of /64 are in scope. |
|
|
|
|
|
|
|
|
|
This policy is considered to be an interim policy. It will be |
|
This policy is considered to be an interim policy. It will be |
|
|
reviewed in the future, subject to greater experience in the |
|
reviewed in the future, subject to greater experience in the |
|
|
administration of IPv6. |
|
administration of IPv6. |
|
|
|
|
|
|
|
2. Definitions |
|
2. Definitions |
|
|
|
|
|
|
|
[note: some of these definitions will be replaced by definitions from |
|
[note: some of these definitions will be replaced by definitions from |
|
|
other RIR documents in order to be more consistent.] |
|
other RIR documents in order to be more consistent.] |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 228 |
|
skipping to change at line 224 |
|
|
2.6. Assign |
|
2.6. Assign |
|
|
|
|
|
|
|
To assign means to delegate address space to an ISP or end-user, for |
|
To assign means to delegate address space to an ISP or end-user, for |
|
|
specific use within the Internet infrastructure they operate. |
|
specific use within the Internet infrastructure they operate. |
|
|
Assignments must only be made for specific purposes documented by |
|
Assignments must only be made for specific purposes documented by |
|
|
specific organizations and are not to be sub-assigned to other |
|
specific organizations and are not to be sub-assigned to other |
|
|
parties. |
|
parties. |
|
|
|
|
|
|
|
2.7. Utilization |
|
2.7. Utilization |
|
|
|
|
|
|
|
|
Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts |
|
The actual usage of addresses within each assignment will be |
|
|
(/48). The actual usage of addresses within each assignment will be |
|
|
|
|
quite low, when compared to IPv4 assignments. In IPv6, “utilization” |
|
quite low, when compared to IPv4 assignments. In IPv6, “utilization” |
|
|
|
is only measured in terms of the bits to the left of the /48 |
|
is only measured in terms of the bits to the left of the /56 |
|
|
boundary. In other words, utilization refers to the assignment of |
|
boundary. In other words, utilization refers to the assignment of |
|
|
|
/48s to end sites, and not the number of addresses assigned within |
|
/56s to end sites, and not the number of addresses assigned within |
|
|
individual /48s at those end sites. |
|
individual /56s at those end sites. |
|
|
|
|
|
|
|
Throughout this document, the term utilization refers to the |
|
Throughout this document, the term utilization refers to the |
|
|
|
allocation of /48s to end sites, and not the number of addresses |
|
allocation of /56s to end sites, and not the number of addresses |
|
|
assigned within individual /48s within those end sites. |
|
assigned within individual /56s within those end sites. |
|
|
|
|
|
|
|
2.8. HD-Ratio |
|
2.8. HD-Ratio |
|
|
|
|
|
|
|
The HD-Ratio is a way of measuring the efficiency of address |
|
The HD-Ratio is a way of measuring the efficiency of address |
|
|
assignment [RFC 3194]. It is an adaptation of the H-Ratio originally |
|
assignment [RFC 3194]. It is an adaptation of the H-Ratio originally |
|
|
defined in [RFC1715] and is expressed as follows: |
|
defined in [RFC1715] and is expressed as follows: |
|
|
|
|
|
|
|
Log (number of allocated objects) |
|
Log (number of allocated objects) |
|
|
HD = ———————————————— |
|
HD = ———————————————— |
|
|
Log (maximum number of allocatable objects) |
|
Log (maximum number of allocatable objects) |
|
|
|
|
|
|
|
where (in the case of this document) the objects are IPv6 site |
|
where (in the case of this document) the objects are IPv6 site |
|
|
|
addresses (/48s) assigned from an IPv6 prefix of a given size. |
|
addresses (/56s) assigned from an IPv6 prefix of a given size. |
|
|
|
|
|
|
|
2.9. End site |
|
2.9. End site |
|
|
|
|
|
|
|
An end site is defined as an end user (subscriber) who has a business |
|
An end site is defined as an end user (subscriber) who has a business |
|
|
relationship with a service provider that involves: |
|
relationship with a service provider that involves: |
|
|
|
|
|
|
|
– that service provider assigning address space to the end user |
|
– that service provider assigning address space to the end user |
|
|
– that service provider providing transit service for the end user |
|
– that service provider providing transit service for the end user |
|
|
to other sites |
|
to other sites |
|
|
– that service provider carrying the end user’s traffic. |
|
– that service provider carrying the end user’s traffic. |
|
|
|
|
|
|
|
skipping to change at line 416 |
|
skipping to change at line 411 |
|
|
5.1. Initial allocation |
|
5.1. Initial allocation |
|
|
|
|
|
|
|
5.1.1. Initial allocation criteria |
|
5.1.1. Initial allocation criteria |
|
|
|
|
|
|
|
To qualify for an initial allocation of IPv6 address space, an |
|
To qualify for an initial allocation of IPv6 address space, an |
|
|
organization must: |
|
organization must: |
|
|
|
|
|
|
|
a) be an LIR; |
|
a) be an LIR; |
|
|
b) not be an end site; |
|
b) not be an end site; |
|
|
c) plan to provide IPv6 connectivity to organizations to which it |
|
c) plan to provide IPv6 connectivity to organizations to which it |
|
|
|
will assign /48s, by advertising that connectivity through its |
|
will make assignments, by advertising that connectivity through |
|
|
single aggregated address allocation; and |
|
its single aggregated address allocation; and |
|
|
d) have a plan for making at least 200 /48 assignments to other |
|
d) have a plan for making at least 200 assignments to other |
|
|
organizations within two years. |
|
organizations within two years. |
|
|
|
|
|
|
|
Private networks (those not connected to the public Internet) may |
|
Private networks (those not connected to the public Internet) may |
|
|
also be eligible for an IPv6 address space allocation provided they |
|
also be eligible for an IPv6 address space allocation provided they |
|
|
meet equivalent criteria to those listed above. |
|
meet equivalent criteria to those listed above. |
|
|
|
|
|
|
|
5.1.2. Minimum initial allocation size |
|
5.1.2. Minimum initial allocation size |
|
|
|
|
|
|
|
Organizations that meet the initial allocation criteria are eligible |
|
Organizations that meet the initial allocation criteria are eligible |
|
|
to receive a minimum allocation of /32. |
|
to receive a minimum allocation of /32. |
|
|
|
|
|
|
|
skipping to change at line 457 |
|
skipping to change at line 452 |
|
|
|
|
|
|
|
5.2. Subsequent allocation |
|
5.2. Subsequent allocation |
|
|
|
|
|
|
|
Organizations that hold an existing IPv6 allocation may receive a |
|
Organizations that hold an existing IPv6 allocation may receive a |
|
|
subsequent allocation in accordance with the following policies. |
|
subsequent allocation in accordance with the following policies. |
|
|
|
|
|
|
|
5.2.1. Subsequent allocation criteria |
|
5.2.1. Subsequent allocation criteria |
|
|
|
|
|
|
|
Subsequent allocation will be provided when an organization (ISP/LIR) |
|
Subsequent allocation will be provided when an organization (ISP/LIR) |
|
|
satisfies the evaluation threshold of past address utilization in |
|
satisfies the evaluation threshold of past address utilization in |
|
|
|
terms of the number of sites in units of /48 assignments. The HD- |
|
terms of the number of sites in units of /56 assignments. The HD- |
|
|
Ratio [RFC 3194] is used to determine the utilization thresholds that |
|
Ratio [RFC 3194] is used to determine the utilization thresholds that |
|
|
justify the allocation of additional address as described below. |
|
justify the allocation of additional address as described below. |
|
|
|
|
|
|
|
5.2.2. Applied HD-Ratio |
|
5.2.2. Applied HD-Ratio |
|
|
|
|
|
|
|
|
The HD-Ratio value of 0.8 is adopted as indicating an acceptable |
|
The HD-Ratio value of 0.94 is adopted as indicating an acceptable |
|
|
address utilization for justifying the allocation of additional |
|
address utilization for justifying the allocation of additional |
|
|
address space. Appendix A provides a table showing the number of |
|
address space. Appendix A provides a table showing the number of |
|
|
assignments that are necessary to achieve an acceptable utilization |
|
assignments that are necessary to achieve an acceptable utilization |
|
|
value for a given address block size. |
|
value for a given address block size. |
|
|
|
|
|
|
|
5.2.3. Subsequent Allocation Size |
|
5.2.3. Subsequent Allocation Size |
|
|
|
|
|
|
|
When an organization has achieved an acceptable utilization for its |
|
When an organization has achieved an acceptable utilization for its |
|
|
allocated address space, it is immediately eligible to obtain an |
|
allocated address space, it is immediately eligible to obtain an |
|
|
additional allocation that results in a doubling of the address space |
|
additional allocation that results in a doubling of the address space |
|
|
|
|
|
|
|
skipping to change at line 500 |
|
skipping to change at line 495 |
|
|
properly evaluate the HD-Ratio when a subsequent allocation becomes |
|
properly evaluate the HD-Ratio when a subsequent allocation becomes |
|
|
necessary. |
|
necessary. |
|
|
|
|
|
|
|
5.4. Assignment |
|
5.4. Assignment |
|
|
|
|
|
|
|
LIRs must make IPv6 assignments in accordance with the following |
|
LIRs must make IPv6 assignments in accordance with the following |
|
|
provisions. |
|
provisions. |
|
|
|
|
|
|
|
5.4.1. Assignment address space size |
|
5.4.1. Assignment address space size |
|
|
|
|
|
|
|
|
Assignments are to be made in accordance with the existing guidelines |
|
End-users are assigned an end site assignment from their LIR or ISP. |
|
|
[RFC3177,RIRs-on-48], which are summarized here as: |
|
The exact size of the assignment is a local decision for the LIR or |
|
|
|
|
ISP to make, using a minimum value of a /64 (when only one subnet is |
|
|
– /48 in the general case, except for very large subscribers |
|
anticipated for the end site) up to the normal maximum of /48, |
|
|
– /64 when it is known that one and only one subnet is needed by |
|
except in cases of extra large end sites where a larger assignment |
|
|
design |
|
can be justified. |
|
|
– /128 when it is absolutely known that one and only one device is |
|
|
|
|
connecting. |
|
|
|
|
|
|
|
|
|
RIRs/NIRs are not concerned about which address size an LIR/ISP |
|
RIRs/NIRs are not concerned about which address size an LIR/ISP |
|
|
actually assigns. Accordingly, RIRs/NIRs will not request the |
|
actually assigns. Accordingly, RIRs/NIRs will not request the |
|
|
detailed information on IPv6 user networks as they did in IPv4, |
|
detailed information on IPv6 user networks as they did in IPv4, |
|
|
except for the cases described in Section 4.4 and for the purposes of |
|
except for the cases described in Section 4.4 and for the purposes of |
|
|
measuring utilization as defined in this document. |
|
measuring utilization as defined in this document. |
|
|
|
|
|
|
|
5.4.2. Assignment of multiple /48s to a single end site |
|
5.4.2. Assignment of multiple /48s to a single end site |
|
|
|
|
|
|
|
When a single end site requires an additional /48 address block, it |
|
When a single end site requires an additional /48 address block, it |
|
|
|
|
|
|
|
skipping to change at line 544 |
|
skipping to change at line 537 |
|
|
is regarded as one assignment regardless of the number of users using |
|
is regarded as one assignment regardless of the number of users using |
|
|
the PoP. A separate assignment can be obtained for the in-house |
|
the PoP. A separate assignment can be obtained for the in-house |
|
|
operations of the operator. |
|
operations of the operator. |
|
|
|
|
|
|
|
5.5. Registration |
|
5.5. Registration |
|
|
|
|
|
|
|
When an organization holding an IPv6 address allocation makes IPv6 |
|
When an organization holding an IPv6 address allocation makes IPv6 |
|
|
address assignments, it must register assignment information in a |
|
address assignments, it must register assignment information in a |
|
|
database, accessible by RIRs as appropriate (information registered |
|
database, accessible by RIRs as appropriate (information registered |
|
|
by an RIR/NIR may be replaced by a distributed database for |
|
by an RIR/NIR may be replaced by a distributed database for |
|
|
|
registering address management information in future). Information |
|
registering address management information in future). Information |
|
|
is registered in units of assigned /48 networks. When more than a |
|
is registered in units of assigned /48 networks. When more than a |
|
|
/48 is assigned to an organization, the assigning organization is |
|
/48 is assigned to an organization, the assigning organization is |
|
|
responsible for ensuring that the address space is registered in an |
|
responsible for ensuring that the address space is registered in an |
|
|
RIR/NIR database. |
|
RIR/NIR database. |
|
|
|
|
|
|
|
RIR/NIRs will use registered data to calculate the HD-Ratio at the |
|
RIR/NIRs will use registered data to calculate the HD-Ratio at the |
|
|
time of application for subsequent allocation and to check for |
|
time of application for subsequent allocation and to check for |
|
|
changes in assignments over time. |
|
changes in assignments over time. |
|
|
|
|
|
|
|
IRs shall maintain systems and practices that protect the security of |
|
IRs shall maintain systems and practices that protect the security of |
|
|
personal and commercial information that is used in request |
|
personal and commercial information that is used in request |
|
|
|
|
|
|
|
skipping to change at line 587 |
|
skipping to change at line 580 |
|
|
Organizations that received /35 IPv6 allocations under the previous |
|
Organizations that received /35 IPv6 allocations under the previous |
|
|
IPv6 address policy [RIRv6-Policies] are immediately entitled to have |
|
IPv6 address policy [RIRv6-Policies] are immediately entitled to have |
|
|
their allocation expanded to a /32 address block, without providing |
|
their allocation expanded to a /32 address block, without providing |
|
|
justification, so long as they satisfy the criteria in Section 5.1.1. |
|
justification, so long as they satisfy the criteria in Section 5.1.1. |
|
|
The /32 address block will contain the already allocated smaller |
|
The /32 address block will contain the already allocated smaller |
|
|
address block (one or multiple /35 address blocks in many cases) that |
|
address block (one or multiple /35 address blocks in many cases) that |
|
|
was already reserved by the RIR for a subsequent allocation to the |
|
was already reserved by the RIR for a subsequent allocation to the |
|
|
organization. Requests for additional space beyond the minimum /32 |
|
organization. Requests for additional space beyond the minimum /32 |
|
|
size will be evaluated as discussed elsewhere in the document. |
|
size will be evaluated as discussed elsewhere in the document. |
|
|
|
|
|
|
|
|
5.8. Assignments to IXPs and critical infrastructure |
|
5.8. Portable assignments |
|
|
|
|
|
|
|
|
5.8.1 Internet Exchange Points |
|
5.8.1. Small multihoming assignments |
|
|
|
|
|
|
|
|
|
An organization is eligible to receive a portable assignment from |
|
|
|
|
APNIC if it is currently multihomed or plans to be multihomed |
|
|
|
|
within three months. |
|
|
|
|
|
|
|
|
|
An organization is considered to be multihomed if its network receives |
|
|
|
|
full-time connectivity from more than one ISP and has one or more |
|
|
|
|
routing prefixes announced by at least two of its ISPs. |
|
|
|
|
|
|
|
|
|
The minimum assignment made under these terms is /48. |
|
|
|
|
|
|
|
|
|
Address space assigned under these terms that is not used for |
|
|
|
|
multihoming within three months of assignment by APNIC will be |
|
|
|
|
reclaimed. |
|
|
|
|
|
|
|
|
|
5.8.2. Internet Exchange Points |
|
|
|
|
|
|
|
Internet Exchange Points are eligible to receive a portable assignment |
|
Internet Exchange Points are eligible to receive a portable assignment |
|
|
from APNIC to be used exclusively to connect the IXP participant devices |
|
from APNIC to be used exclusively to connect the IXP participant devices |
|
|
to the Exchange Point. |
|
to the Exchange Point. |
|
|
|
|
|
|
|
The minimum assignment made under these terms is /48. |
|
The minimum assignment made under these terms is /48. |
|
|
|
|
|
|
|
Global routability of the portable assignment is left to the discretion |
|
Global routability of the portable assignment is left to the discretion |
|
|
of the IXP and its participants. |
|
of the IXP and its participants. |
|
|
|
|
|
|
|
|
5.8.2 Critical infrastructure |
|
5.8.3. Critical infrastructure |
|
|
|
|
|
|
|
The following critical infrastructure networks, if operating in the Asia |
|
The following critical infrastructure networks, if operating in the Asia |
|
|
Pacific region, are eligible to receive a portable assignment: |
|
Pacific region, are eligible to receive a portable assignment: |
|
|
|
|
|
|
|
– root domain name system (DNS) server; |
|
– root domain name system (DNS) server; |
|
|
|
– global top level domain (gTLD) nameservers; |
|
– global top level domain (gTLD) nameservers; |
|
|
– country code TLD (ccTLDs) nameservers; |
|
– country code TLD (ccTLDs) nameservers; |
|
|
– IANA; |
|
– IANA; |
|
|
– Regional Internet Registry (RIRs); and |
|
– Regional Internet Registry (RIRs); and |
|
|
– National Internet Registry (NIRs). |
|
– National Internet Registry (NIRs). |
|
|
|
|
|
|
|
Assignments to critical infrastructure are available only to the actual |
|
Assignments to critical infrastructure are available only to the actual |
|
|
operators of the network infrastructure performing such functions. Registrar |
|
operators of the network infrastructure performing such functions. Registrar |
|
|
organisations which do not actually host the network housing the registry |
|
organisations which do not actually host the network housing the registry |
|
|
infrastructure, will not be eligible for an assignment under this policy. |
|
infrastructure, will not be eligible for an assignment under this policy. |
|
|
|
|
|
|
|
The maximum assignment made under these terms is /32 per operator. |
|
The maximum assignment made under these terms is /32 per operator. |
|
|
|
|
|
|
|
Exchanges made under this policy remain subject to the address space license |
|
Exchanges made under this policy remain subject to the address space license |
|
|
policy. |
|
policy. |
|
|
|
|
|
|
|
skipping to change at line 665 |
|
skipping to change at line 674 |
|
|
The HD-Ratio is not intended to replace the traditional utilization |
|
The HD-Ratio is not intended to replace the traditional utilization |
|
|
measurement that ISPs perform with IPv4 today. Indeed, the HD-Ratio |
|
measurement that ISPs perform with IPv4 today. Indeed, the HD-Ratio |
|
|
still requires counting the number of assigned objects. The primary |
|
still requires counting the number of assigned objects. The primary |
|
|
value of the HD-Ratio is its usefulness at determining reasonable |
|
value of the HD-Ratio is its usefulness at determining reasonable |
|
|
target utilization threshold values for an address space of a given |
|
target utilization threshold values for an address space of a given |
|
|
size. This document uses the HD-Ratio to determine the thresholds at |
|
size. This document uses the HD-Ratio to determine the thresholds at |
|
|
which a given allocation has achieved an acceptable level of |
|
which a given allocation has achieved an acceptable level of |
|
|
utilization and the assignment of additional address space becomes |
|
utilization and the assignment of additional address space becomes |
|
|
justified. |
|
justified. |
|
|
|
|
|
|
|
|
The utilization threshold T, expressed as a number of individual /48 |
|
The utilization threshold T, expressed as a number of individual /56 |
|
|
prefixes to be allocated from IPv6 prefix P, can be calculated as: |
|
prefixes to be allocated from IPv6 prefix P, can be calculated as: |
|
|
|
|
|
|
|
|
((48-P)*HD) |
|
((56-P)*HD) |
|
|
T = 2 |
|
T = 2 |
|
|
|
|
|
|
|
|
Thus, the utilization threshold for an organization requesting |
|
Thus, the utilization threshold for an organization requesting |
|
|
subsequent allocation of IPv6 address block is specified as a |
|
subsequent allocation of IPv6 address block is specified as a |
|
|
function of the prefix size and target HD ratio. This utilization |
|
function of the prefix size and target HD ratio. This utilization |
|
|
|
refers to the allocation of /48s to end sites, and not the |
|
refers to the allocation of /56s to end sites, and not the |
|
|
utilization of those /48s within those end sites. It is an address |
|
utilization of those /56s within those end sites. It is an address |
|
|
allocation utilization ratio and not an address assignment |
|
allocation utilization ratio and not an address assignment |
|
|
utilization ratio. |
|
utilization ratio. |
|
|
|
|
|
|
|
|
In accordance with the recommendations of [RFC 3194], this document |
|
This document adopts an HD-Ratio of 0.94 as the utilization |
|
|
adopts an HD-Ratio of 0.8 as the utilization threshold for IPv6 |
|
threshold for IPv6 address space allocations. |
|
|
address space allocations. |
|
|
|
|
|
|
|
|
|
The following table provides equivalent absolute and percentage |
|
The following table provides equivalent absolute and percentage |
|
|
address utilization figures for IPv6 prefixes, corresponding to an |
|
address utilization figures for IPv6 prefixes, corresponding to an |
|
|
|
HD-Ratio of 0.8 |
|
HD-Ratio of 0.94 |
|
|
|
|
|
|
|
|
P 48-P Total /48s Threshold Util% |
|
P 56-P Total /56s Threshold Util % |
|
|
|
|
|
|
|
|
48 0 1 1 100.0% |
|
56 0 1 1 100.0 |
|
|
47 1 2 2 87.1% |
|
55 1 2 2 95.9 |
|
|
46 2 4 3 75.8% |
|
54 2 4 4 92.0 |
|
|
45 3 8 5 66.0% |
|
53 3 8 7 88.3 |
|
|
44 4 16 9 57.4% |
|
52 4 16 14 84.7 |
|
|
43 5 32 16 50.0% |
|
51 5 32 26 81.2 |
|
|
42 6 64 28 43.5% |
|
50 6 64 50 77.9 |
|
|
41 7 128 49 37.9% |
|
49 7 128 96 74.7 |
|
|
40 8 256 84 33.0% |
|
48 8 256 184 71.7 |
|
|
39 9 512 147 28.7% |
|
47 9 512 352 68.8 |
|
|
38 10 1024 256 25.0% |
|
46 10 1,024 676 66.0 |
|
|
37 11 2048 446 21.8% |
|
45 11 2,048 1,296 63.3 |
|
|
36 12 4096 776 18.9% |
|
44 12 4,096 2,487 60.7 |
|
|
35 13 8192 1351 16.5% |
|
43 13 8,192 4,771 58.2 |
|
|
34 14 16384 2353 14.4% |
|
42 14 16,384 9,153 55.9 |
|
|
33 15 32768 4096 12.5% |
|
41 15 32,768 17,560 53.6 |
|
|
32 16 65536 7132 10.9% |
|
40 16 65,536 33,689 51.4 |
|
|
31 17 131072 12417 9.5% |
|
39 17 131,072 64,634 49.3 |
|
|
30 18 262144 21619 8.2% |
|
38 18 262,144 124,002 47.3 |
|
|
29 19 524288 37641 7.2% |
|
37 19 524,288 237,901 45.4 |
|
|
28 20 1048576 65536 6.3% |
|
36 20 1,048,576 456,419 43.5 |
|
|
27 21 2097152 114105 5.4% |
|
35 21 2,097,152 875,653 41.8 |
|
|
26 22 4194304 198668 4.7% |
|
34 22 4,194,304 1,679,965 40.1 |
|
|
25 23 8388608 345901 4.1% |
|
33 23 8,388,608 3,223,061 38.4 |
|
|
24 24 16777216 602249 3.6% |
|
32 24 16,777,216 6,183,533 36.9 |
|
|
23 25 33554432 1048576 3.1% |
|
31 25 33,554,432 11,863,283 35.4 |
|
|
22 26 67108864 1825677 2.7% |
|
30 26 67,108,864 22,760,044 33.9 |
|
|
21 27 134217728 3178688 2.4% |
|
29 27 134,217,728 43,665,787 32.5 |
|
|
20 28 268435456 5534417 2.1% |
|
28 28 268,435,456 83,774,045 31.2 |
|
|
19 29 536870912 9635980 1.8% |
|
27 29 536,870,912 160,722,871 29.9 |
|
|
18 30 1073741824 16777216 1.6% |
|
26 30 1,073,741,824 308,351,367 28.7 |
|
|
17 31 2147483648 29210830 1.4% |
|
25 31 2,147,483,648 591,580,804 27.5 |
|
|
16 32 4294967296 50859008 1.2% |
|
24 32 4,294,967,296 1,134,964,479 26.4 |
|
|
15 33 8589934592 88550677 1.0% |
|
23 33 8,589,934,592 2,177,461,403 25.3 |
|
|
14 34 17179869184 154175683 0.9% |
|
22 34 17,179,869,184 4,177,521,189 24.3 |
|
|
13 35 34359738368 268435456 0.8% |
|
21 35 34,359,738,368 8,014,692,369 23.3 |
|
|
12 36 68719476736 467373275 0.7% |
|
20 36 68,719,476,736 15,376,413,635 22.4 |
|
|
11 37 137438953472 813744135 0.6% |
|
19 37 137,438,953,472 29,500,083,768 21.5 |
|
|
10 38 274877906944 1416810831 0.5% |
|
18 38 274,877,906,944 56,596,743,751 20.6 |
|
|
9 39 549755813888 2466810934 0.4% |
|
17 39 549,755,813,888 108,582,451,102 19.8 |
|
|
8 40 1099511627776 4294967296 0.4% |
|
16 40 1,099,511,627,776 208,318,498,661 18.9 |
|
|
7 41 2199023255552 7477972398 0.3% |
|
15 41 2,199,023,255,552 399,664,922,315 18.2 |
|
|
6 42 4398046511104 13019906166 0.3% |
|
14 42 4,398,046,511,104 766,768,439,460 17.4 |
|
|
5 43 8796093022208 22668973294 0.3% |
|
13 43 8,796,093,022,208 1,471,066,903,609 16.7 |
|
|
4 44 17592186044416 39468974941 0.2% |
|
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 |
|
|
|
|
|
|
|
8. Appendix B: Background information |
|
8. Appendix B: Background information |
|
|
|
|
|
|
|
8.1. Background |
|
8.1. Background |
|
|
|
|
|
|
|
The impetus for revising the 1999 Provisional IPv6 policy started |
|
The impetus for revising the 1999 Provisional IPv6 policy started |
|
|
with the APNIC meeting held in Taiwan in August 2001. Follow-on |
|
with the APNIC meeting held in Taiwan in August 2001. Follow-on |
|
|
discussions were held at the October, 2001 RIPE and ARIN meetings. |
|
discussions were held at the October, 2001 RIPE and ARIN meetings. |
|
|
During these meetings, the participants recognized an urgent need for |
|
During these meetings, the participants recognized an urgent need for |
|
|
more detailed, complete policies. One result of the meetings was the |
|
more detailed, complete policies. One result of the meetings was the |
|
|
|
|
|
|
|
skipping to change at line 782 |
|
skipping to change at line 799 |
|
|
allocation policies could also result in the adoption of practices |
|
allocation policies could also result in the adoption of practices |
|
|
that lead to premature exhaustion of the address space. |
|
that lead to premature exhaustion of the address space. |
|
|
|
|
|
|
|
It should be noted that the 128-bit address space is divided into |
|
It should be noted that the 128-bit address space is divided into |
|
|
three logical parts, with the usage of each component managed |
|
three logical parts, with the usage of each component managed |
|
|
differently. The rightmost 64 bits, the Interface Identifier |
|
differently. The rightmost 64 bits, the Interface Identifier |
|
|
[RFC2373], will often be a globally-unique IEEE identifier (e.g., mac |
|
[RFC2373], will often be a globally-unique IEEE identifier (e.g., mac |
|
|
address). Although an “inefficient” way to use the Interface |
|
address). Although an “inefficient” way to use the Interface |
|
|
Identifier field from the perspective of maximizing the number of |
|
Identifier field from the perspective of maximizing the number of |
|
|
addressable nodes, the numbering scheme was explicitly chosen to |
|
addressable nodes, the numbering scheme was explicitly chosen to |
|
|
|
simplify Stateless Address Autoconfiguration [RFC2462]. |
|
simplify Stateless Address Autoconfiguration [RFC2462]. The middle |
|
|
|
|
bits of an address indicate the subnet ID. |
|
|
The middle 16 bits of an address indicate the subnet ID. Per [RFC |
|
|
|
|
3177, RIRs-on-48s], this field will often be inefficiently utilized, |
|
|
|
|
but the operational benefits of a consistent width subnet field were |
|
|
|
|
deemed to be outweigh the drawbacks. |
|
|
|
|
|
|
|
|
|
The decisions to inefficiently utilize the bits to the right of /48 |
|
|
|
|
were made under the knowledge and assumption that the bits to the |
|
|
|
|
left of /48 would be managed prudently and that if done so, will be |
|
|
|
|
adequate for the expected lifetime of IPv6 [RFC3177]. |
|
|
|
|
|
|
|
|
|
8.4. Acknowledgment |
|
8.4. Acknowledgment |
|
|
|
|
|
|
|
The initial version of this document was produced by The JPNIC IPv6 |
|
The initial version of this document was produced by The JPNIC IPv6 |
|
|
policy drafting team consisting of Akihiro Inomata, Akinori Maemura, |
|
policy drafting team consisting of Akihiro Inomata, Akinori Maemura, |
|
|
Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and |
|
Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and |
|
|
Toshiyuki Yamasaki. Special thanks goes out to this team, who worked |
|
Toshiyuki Yamasaki. Special thanks goes out to this team, who worked |
|
|
over a holiday in order to produce an initial document quickly. |
|
over a holiday in order to produce an initial document quickly. |
|
|
|
|
|
|
|
An editing team was then organized by representatives from each of |
|
An editing team was then organized by representatives from each of |
|
|
|
|
|
|
| End of changes. 28 change blocks. |
|
107 lines changed or deleted |
|
115 lines changed or added |
|
| This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |
