|
apnic-089-v009.txt |
|
apnic-089-v010.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: 009 |
|
Version: 010 |
|
|
Date of original publication: 1 July 2002 |
|
Date of original publication: 1 July 2002 |
|
|
|
Date of this version: 8 November 2010 |
|
Date of this version: 9 August 2011 |
|
|
Review scheduled: n/a |
|
Review scheduled: n/a |
|
|
Obsoletes: Previous versions |
|
Obsoletes: Previous versions |
|
|
|
Status: Active |
|
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 |
|
|
|
|
|
|
|
This document was initially developed through joint discussions |
|
This document was initially developed through joint discussions |
|
|
among the APNIC, ARIN and RIPE communities. The document also |
|
among the APNIC, ARIN and RIPE communities. The document also |
|
|
incorporates APNIC-specific policies developed since that time. |
|
incorporates APNIC-specific policies developed since that time. |
|
|
|
|
|
|
|
skipping to change at line 39 |
|
skipping to change at line 40 |
|
|
organizations. This document obsoletes the “Provisional IPv6 |
|
organizations. This document obsoletes the “Provisional IPv6 |
|
|
assignment and allocation policy document”. |
|
assignment and allocation policy document”. |
|
|
|
|
|
|
|
This document was developed jointly by the communities of APNIC, |
|
This document was developed jointly by the communities of APNIC, |
|
|
ARIN, and RIPE. |
|
ARIN, and RIPE. |
|
|
|
|
|
|
|
Contents |
|
Contents |
|
|
|
|
|
|
|
1. Introduction |
|
1. Introduction |
|
|
|
|
|
|
|
|
1.1 Overview |
|
1.1 Overview |
|
|
|
|
|
|
|
2. Definitions |
|
2. Definitions |
|
|
|
|
|
|
|
2.1 Internet Registry (IR) |
|
2.1 Internet Registry (IR) |
|
|
2.2 Regional Internet Registry (RIR) |
|
2.2 Regional Internet Registry (RIR) |
|
|
2.3 National Internet Registry (NIR) |
|
2.3 National Internet Registry (NIR) |
|
|
2.4 Local Internet Registry (LIR) |
|
2.4 Local Internet Registry (LIR) |
|
|
2.5 Allocate |
|
2.5 Allocate |
|
|
2.6 Assign |
|
2.6 Assign |
|
|
2.7 Utilization |
|
2.7 Utilization |
|
|
|
|
|
|
|
skipping to change at line 87 |
|
skipping to change at line 88 |
|
|
5.1.2 Minimum size of IPv6 block |
|
5.1.2 Minimum size of IPv6 block |
|
|
|
|
|
|
|
5.2 Initial allocation |
|
5.2 Initial allocation |
|
|
|
|
|
|
|
5.2.1 Initial allocation criteria |
|
5.2.1 Initial allocation criteria |
|
|
5.2.2 Minimum initial allocation size |
|
5.2.2 Minimum initial allocation size |
|
|
5.2.3 Larger initial allocations |
|
5.2.3 Larger initial allocations |
|
|
|
|
|
|
|
5.3 Subsequent allocation |
|
5.3 Subsequent allocation |
|
|
|
|
|
|
|
|
5.3.1 Subsequent allocation criteria |
|
5.3.1 Applied HD-Ratio |
|
|
5.3.2 Applied HD-Ratio |
|
5.3.2 Alternative allocation criteria |
|
|
5.3.3 Subsequent Allocation Size |
|
5.3.3 Subsequent Allocation Size |
|
|
|
|
|
|
|
5.4 LIR-to-ISP allocation |
|
5.4 LIR-to-ISP allocation |
|
|
|
|
|
|
|
5.5 Assignment |
|
5.5 Assignment |
|
|
|
|
|
|
|
5.5.1 Assignment address space size |
|
5.5.1 Assignment address space size |
|
|
5.5.2 Assignment of multiple /48s to a single end site |
|
5.5.2 Assignment of multiple /48s to a single end site |
|
|
5.5.3 Assignment to operator’s infrastructure |
|
5.5.3 Assignment to operator’s infrastructure |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 111 |
|
skipping to change at line 112 |
|
|
5.7 Reverse lookup |
|
5.7 Reverse lookup |
|
|
|
|
|
|
|
5.8 Existing IPv6 address space holders |
|
5.8 Existing IPv6 address space holders |
|
|
|
|
|
|
|
5.9 Portable assignments |
|
5.9 Portable assignments |
|
|
|
|
|
|
|
5.9.1 Small multihoming assignments |
|
5.9.1 Small multihoming assignments |
|
|
5.9.2 Internet Exchange Points |
|
5.9.2 Internet Exchange Points |
|
|
5.9.3 Critical infrastructure |
|
5.9.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 |
|
|
8.4 Acknowledgment |
|
8.4 Acknowledgment |
|
|
|
|
|
|
|
|
1. Introduction |
|
1. Introduction |
|
|
|
|
|
|
|
1.1 Overview |
|
1.1 Overview |
|
|
|
|
|
|
|
|
This document describes policies for the allocation and |
|
This document describes policies for the allocation and assignment |
|
|
assignment of globally-unique Internet Protocol Version 6 (IPv6) |
|
of globally-unique Internet Protocol Version 6 (IPv6) address |
|
|
address space. It updates and obsoletes the existing Provisional |
|
space. It updates and obsoletes the existing Provisional IPv6 |
|
|
IPv6 Policies in effect since 1999 [RIRv6-Policies]. Policies |
|
Policies in effect since 1999 [RIRv6-Policies]. Policies described |
|
|
described in this document are intended to be adopted by each |
|
in this document are intended to be adopted by each registry. |
|
|
registry. However, adoption of this document does not preclude |
|
However, adoption of this document does not preclude local |
|
|
local variations in each region or area. |
|
variations in each region or area. |
|
|
|
|
|
|
|
[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast |
|
[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast |
|
|
address space that IANA may allocate to the RIRs. In accordance |
|
address space that IANA may allocate to the RIRs. In accordance |
|
|
with [RFC2928, RFC2373bis, IAB-Request], IANA has allocated |
|
with [RFC2928, RFC2373bis, IAB-Request], IANA has allocated |
|
|
initial ranges of global unicast IPv6 address space from the |
|
initial ranges of global unicast IPv6 address space from the |
|
|
2001::/16 address block to the existing RIRs. This document |
|
2001::/16 address block to the existing RIRs. This document |
|
|
concerns the initial and subsequent allocations of the 2000::/3 |
|
concerns the initial and subsequent allocations of the 2000::/3 |
|
|
unicast address space, for which RIRs formulate allocation and |
|
unicast address space, for which RIRs formulate allocation and |
|
|
assignment policies. |
|
assignment policies. |
|
|
|
|
|
|
|
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 |
|
[note: some of these definitions will be replaced by definitions |
|
|
from other RIR documents in order to be more consistent.] |
|
from other RIR documents in order to be more consistent.] |
|
|
|
|
|
|
|
The following terms and their definitions are of particular |
|
The following terms and their definitions are of particular |
|
|
importance to the understanding of the goals, environment, and |
|
importance to the understanding of the goals, environment, and |
|
|
policies described in this document. |
|
policies described in this document. |
|
|
|
|
|
|
|
Responsibility for management of IPv6 address spaces is |
|
Responsibility for management of IPv6 address spaces is |
|
|
|
distributed globally in accordance with the hierarchical |
|
distributed globally in accordance with the hierarchical structure |
|
|
structure shown below. |
|
shown below. |
|
|
|
|
|
|
|
Figure 1 Distribution Hierarchy |
|
Figure 1 Distribution Hierarchy |
|
|
|
|
|
|
|
+——–+ |
|
+——–+ |
|
|
| IANA | |
|
| IANA | |
|
|
+——–+ |
|
+——–+ |
|
|
| |
|
| |
|
|
+———–+ |
|
+———–+ |
|
|
| | |
|
| | |
|
|
+——–+ +——–+ |
|
+——–+ +——–+ |
|
|
|
|
|
|
|
skipping to change at line 197 |
|
skipping to change at line 198 |
|
|
2.1 Internet Registry (IR) |
|
2.1 Internet Registry (IR) |
|
|
|
|
|
|
|
An Internet Registry (IR) is an organization that is responsible |
|
An Internet Registry (IR) is an organization that is responsible |
|
|
for distributing IP address space to its members or customers and |
|
for distributing IP address space to its members or customers and |
|
|
for registering those distributions. IRs are classified according |
|
for registering those distributions. IRs are classified according |
|
|
to their primary function and territorial scope within the |
|
to their primary function and territorial scope within the |
|
|
hierarchical structure depicted in the figure above. |
|
hierarchical structure depicted in the figure above. |
|
|
|
|
|
|
|
2.2 Regional Internet Registry (RIR) |
|
2.2 Regional Internet Registry (RIR) |
|
|
|
|
|
|
|
|
Regional Internet Registries (RIRs) are established and |
|
Regional Internet Registries (RIRs) are established and authorized |
|
|
authorized by respective regional communities, and recognized by |
|
by respective regional communities, and recognized by the IANA to |
|
|
the IANA to serve and represent large geographical regions. The |
|
serve and represent large geographical regions. The primary role |
|
|
primary role of RIRs is to manage and distribute public Internet |
|
of RIRs is to manage and distribute public Internet address space |
|
|
address space within their respective regions. |
|
within their respective regions. |
|
|
|
|
|
|
|
2.3 National Internet Registry (NIR) |
|
2.3 National Internet Registry (NIR) |
|
|
|
|
|
|
|
A National Internet Registry (NIR) primarily allocates address |
|
A National Internet Registry (NIR) primarily allocates address |
|
|
space to its members or constituents, which are generally LIRs |
|
space to its members or constituents, which are generally LIRs |
|
|
organized at a national level. NIRs exist mostly in the Asia |
|
organized at a national level. NIRs exist mostly in the Asia |
|
|
Pacific region. |
|
Pacific region. |
|
|
|
|
|
|
|
2.4 Local Internet Registry (LIR) |
|
2.4 Local Internet Registry (LIR) |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 232 |
|
skipping to change at line 233 |
|
|
2.6 Assign |
|
2.6 Assign |
|
|
|
|
|
|
|
To assign means to delegate address space to an ISP or end-user, |
|
To assign means to delegate address space to an ISP or end-user, |
|
|
for specific use within the Internet infrastructure they operate. |
|
for 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 |
|
|
|
|
|
|
|
|
The actual usage of addresses within each assignment will be |
|
The actual usage of addresses within each assignment will be quite |
|
|
quite low, when compared to IPv4 assignments. In IPv6, |
|
low, when compared to IPv4 assignments. In IPv6, “utilization” is |
|
|
“utilization” is only measured in terms of the bits to the left |
|
only measured in terms of the bits to the left of the /56 |
|
|
of the /56 boundary. In other words, utilization refers to the |
|
boundary. In other words, utilization refers to the assignment of |
|
|
assignment of /56s to end sites, and not the number of addresses |
|
/56s to end sites, and not the number of addresses assigned within |
|
|
assigned within individual /56s 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 /56s to end sites, and not the number of addresses |
|
allocation of /56s to end sites, and not the number of addresses |
|
|
assigned within individual /56s 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 |
|
assignment [RFC 3194]. It is an adaptation of the H-Ratio |
|
|
originally defined in [RFC1715] and is expressed as follows: |
|
originally 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 (/56s) 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 |
|
An end site is defined as an end user (subscriber) who has a |
|
|
business relationship with a service provider that involves: |
|
business 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 |
|
* that service provider providing transit service for the end |
|
|
user to other sites |
|
user to other sites |
|
|
* that service provider carrying the end user’s traffic |
|
* that service provider carrying the end user’s traffic |
|
|
|
* that service provider advertising an aggregate prefix route |
|
* that service provider advertising an aggregate prefix route that |
|
|
that contains the end user’s assignment |
|
contains the end user’s assignment |
|
|
|
|
|
|
|
2.10 Internet Exchange Point (IXP) |
|
2.10 Internet Exchange Point (IXP) |
|
|
|
|
|
|
|
An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 |
|
An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 |
|
|
network structure that interconnects three or more Autonomous |
|
network structure that interconnects three or more Autonomous |
|
|
Systems (AS) for the purpose of Internet traffic interchange. |
|
Systems (AS) for the purpose of Internet traffic interchange. |
|
|
|
|
|
|
|
3. Goals of IPv6 address space management |
|
3. Goals of IPv6 address space management |
|
|
|
|
|
|
|
3.1 Goals |
|
3.1 Goals |
|
|
|
|
|
|
|
IPv6 address space is a public resource that must be managed in a |
|
IPv6 address space is a public resource that must be managed in a |
|
|
prudent manner with regards to the long-term interests of the |
|
prudent manner with regards to the long-term interests of the |
|
|
internet. Responsible address space management involves balancing |
|
internet. Responsible address space management involves balancing |
|
|
a set of sometimes competing goals. The following are the goals |
|
a set of sometimes competing goals. The following are the goals |
|
|
relevant to IPv6 address policy. |
|
relevant to IPv6 address policy. |
|
|
|
|
|
|
|
3.2 Uniqueness |
|
3.2 Uniqueness |
|
|
|
|
|
|
|
|
Every assignment and/or allocation of address space must |
|
Every assignment and/or allocation of address space must guarantee |
|
|
guarantee uniqueness worldwide. This is an absolute requirement |
|
uniqueness worldwide. This is an absolute requirement for ensuring |
|
|
for ensuring that every public host on the Internet can be |
|
that every public host on the Internet can be uniquely identified. |
|
|
uniquely identified. |
|
|
|
|
|
|
|
|
|
3.3 Registration |
|
3.3 Registration |
|
|
|
|
|
|
|
Internet address space must be registered in a registry database |
|
Internet address space must be registered in a registry database |
|
|
accessible to appropriate members of the Internet community. This |
|
accessible to appropriate members of the Internet community. This |
|
|
|
is necessary to ensure the uniqueness of each Internet address |
|
is necessary to ensure the uniqueness of each Internet address and |
|
|
and to provide reference information for Internet troubleshooting |
|
to provide reference information for Internet troubleshooting at |
|
|
at all levels, ranging from all RIRs and IRs to end users. |
|
all levels, ranging from all RIRs and IRs to end users. |
|
|
|
|
|
|
|
The goal of registration should be applied within the context of |
|
The goal of registration should be applied within the context of |
|
|
reasonable privacy considerations and applicable laws. |
|
reasonable privacy considerations and applicable laws. |
|
|
|
|
|
|
|
3.4 Aggregation |
|
3.4 Aggregation |
|
|
|
|
|
|
|
Wherever possible, address space should be distributed in a |
|
Wherever possible, address space should be distributed in a |
|
|
hierarchical manner, according to the topology of network |
|
hierarchical manner, according to the topology of network |
|
|
infrastructure. This is necessary to permit the aggregation of |
|
infrastructure. This is necessary to permit the aggregation of |
|
|
routing information by ISPs, and to limit the expansion of |
|
routing information by ISPs, and to limit the expansion of |
|
|
|
|
|
|
|
skipping to change at line 322 |
|
skipping to change at line 322 |
|
|
for both internal and external routing. |
|
for both internal and external routing. |
|
|
|
|
|
|
|
IPv6 address policies should seek to avoid fragmentation of |
|
IPv6 address policies should seek to avoid fragmentation of |
|
|
address ranges. |
|
address ranges. |
|
|
|
|
|
|
|
Further, RIRs should apply practices that maximize the potential |
|
Further, RIRs should apply practices that maximize the potential |
|
|
for subsequent allocations to be made contiguous with past |
|
for subsequent allocations to be made contiguous with past |
|
|
allocations currently held. However, there can be no guarantee of |
|
allocations currently held. However, there can be no guarantee of |
|
|
contiguous allocation. |
|
contiguous allocation. |
|
|
|
|
|
|
|
|
In addition, wherever possible, network operators announcing |
|
|
|
|
address space are strongly encouraged to avoid announcing |
|
|
|
|
deaggregated routes when announcing address blocks from a single |
|
|
|
|
Autonomous System unless this deaggregation is required for |
|
|
|
|
traffic engineering purposes. |
|
|
|
|
|
|
|
|
|
When contiguous blocks are delegated to a network operator, the |
|
|
|
|
operator is encouraged to announce the contiguous address blocks |
|
|
|
|
as a single aggregated prefix, with minimal additional |
|
|
|
|
announcements of deaggregated prefixes being made only for traffic |
|
|
|
|
engineering requirements. |
|
|
|
|
|
|
|
|
|
3.5 Conservation |
|
3.5 Conservation |
|
|
|
|
|
|
|
Although IPv6 provides an extremely large pool of address space, |
|
Although IPv6 provides an extremely large pool of address space, |
|
|
address policies should avoid unnecessarily wasteful practices. |
|
address policies should avoid unnecessarily wasteful practices. |
|
|
Requests for address space should be supported by appropriate |
|
Requests for address space should be supported by appropriate |
|
|
documentation and stockpiling of unused addresses should be |
|
documentation and stockpiling of unused addresses should be |
|
|
avoided. |
|
avoided. |
|
|
|
|
|
|
|
3.6 Fairness |
|
3.6 Fairness |
|
|
|
|
|
|
|
All policies and practices relating to the use of public address |
|
All policies and practices relating to the use of public address |
|
|
space should apply fairly and equitably to all existing and |
|
space should apply fairly and equitably to all existing and |
|
|
potential members of the Internet community, regardless of their |
|
potential members of the Internet community, regardless of their |
|
|
location, nationality, size or any other factor. |
|
location, nationality, size or any other factor. |
|
|
|
|
|
|
|
3.7 Minimized Overhead |
|
3.7 Minimized Overhead |
|
|
|
|
|
|
|
|
It is desirable to minimize the overhead associated with |
|
It is desirable to minimize the overhead associated with obtaining |
|
|
obtaining address space. Overhead includes the need to go back to |
|
address space. Overhead includes the need to go back to RIRs for |
|
|
RIRs for additional space too frequently, the overhead associated |
|
additional space too frequently, the overhead associated with |
|
|
with managing address space that grows through a number of small |
|
managing address space that grows through a number of small |
|
|
successive incremental expansions rather than through fewer, but |
|
successive incremental expansions rather than through fewer, but |
|
|
larger, expansions. |
|
larger, expansions. |
|
|
|
|
|
|
|
3.8 Conflict of goals |
|
3.8 Conflict of goals |
|
|
|
|
|
|
|
The goals described above will often conflict with each other, or |
|
The goals described above will often conflict with each other, or |
|
|
with the needs of individual IRs or end users. All IRs evaluating |
|
with the needs of individual IRs or end users. All IRs evaluating |
|
|
requests for allocations and assignments must make judgments, |
|
requests for allocations and assignments must make judgments, |
|
|
seeking to balance the needs of the applicant with the needs of |
|
seeking to balance the needs of the applicant with the needs of |
|
|
the Internet community as a whole. |
|
the Internet community as a whole. |
|
|
|
|
|
|
|
skipping to change at line 390 |
|
skipping to change at line 378 |
|
|
|
|
|
|
|
The policies in this document are based upon the understanding |
|
The policies in this document are based upon the understanding |
|
|
that globally-unique IPv6 unicast address space is licensed for |
|
that globally-unique IPv6 unicast address space is licensed for |
|
|
use rather than owned. Specifically, IP addresses will be |
|
use rather than owned. Specifically, IP addresses will be |
|
|
allocated and assigned on a license basis, with licenses subject |
|
allocated and assigned on a license basis, with licenses subject |
|
|
to renewal on a periodic basis. The granting of a license is |
|
to renewal on a periodic basis. The granting of a license is |
|
|
subject to specific conditions applied at the start or renewal of |
|
subject to specific conditions applied at the start or renewal of |
|
|
the license. |
|
the license. |
|
|
|
|
|
|
|
RIRs will generally renew licenses automatically, provided |
|
RIRs will generally renew licenses automatically, provided |
|
|
|
requesting organizations are making a good-faith effort at |
|
requesting organizations are making a good-faith effort at meeting |
|
|
meeting the criteria under which they qualified for or were |
|
the criteria under which they qualified for or were granted an |
|
|
granted an allocation or assignment. However, in those cases |
|
allocation or assignment. However, in those cases where a |
|
|
where a requesting organization is not using the address space as |
|
requesting organization is not using the address space as |
|
|
intended, or is showing bad faith in following through on the |
|
intended, or is showing bad faith in following through on the |
|
|
associated obligation, RIRs reserve the right to not renew the |
|
associated obligation, RIRs reserve the right to not renew the |
|
|
license. |
|
license. |
|
|
|
|
|
|
|
Note that when a license is renewed, the new license will be |
|
Note that when a license is renewed, the new license will be |
|
|
evaluated under and governed by the applicable IPv6 address |
|
evaluated under and governed by the applicable IPv6 address |
|
|
policies in place at the time of renewal, which may differ from |
|
policies in place at the time of renewal, which may differ from |
|
|
the policy in place at the time of the original allocation or |
|
the policy in place at the time of the original allocation or |
|
|
assignment. |
|
assignment. |
|
|
|
|
|
|
|
4.2 Routability not guaranteed |
|
4.2 Routability not guaranteed |
|
|
|
|
|
|
|
There is no guarantee that any address allocation or assignment |
|
There is no guarantee that any address allocation or assignment |
|
|
will be globally routable. |
|
will be globally routable. |
|
|
|
|
|
|
|
|
However, RIRs must apply procedures that reduce the possibility |
|
However, RIRs must apply procedures that reduce the possibility of |
|
|
of fragmented address space which may lead to a loss of |
|
fragmented address space which may lead to a loss of routability. |
|
|
routability. |
|
|
|
|
|
|
|
|
|
4.3 Minimum Allocation |
|
4.3 Minimum Allocation |
|
|
|
|
|
|
|
|
RIRs will apply a minimum size for IPv6 allocations, to |
|
RIRs will apply a minimum size for IPv6 allocations, to facilitate |
|
|
facilitate prefix-based filtering. |
|
prefix-based filtering. |
|
|
|
|
|
|
|
The minimum allocation size for IPv6 address space is /32. |
|
The minimum allocation size for IPv6 address space is /32. |
|
|
|
|
|
|
|
4.4 Consideration of IPv4 infrastructure |
|
4.4 Consideration of IPv4 infrastructure |
|
|
|
|
|
|
|
|
Subject to section 5.1.3, existing IPv4 networks may be |
|
Subject to section 5.2.3, existing IPv4 networks may be considered |
|
|
considered in determining the initial IPv6 allocation size. |
|
in determining the initial IPv6 allocation size. |
|
|
|
|
|
|
|
5. Policies for allocations and assignments |
|
5. Policies for allocations and assignments |
|
|
|
|
|
|
|
5.1 Initial IPv6 block for APNIC members with existing IPv4 space |
|
5.1 Initial IPv6 block for APNIC members with existing IPv4 space |
|
|
|
|
|
|
|
5.1.1 Criteria |
|
5.1.1 Criteria |
|
|
|
|
|
|
|
APNIC members that have received an IPv4 address block from APNIC |
|
APNIC members that have received an IPv4 address block from APNIC |
|
|
|
but have no IPv6 space can qualify for an appropriately sized |
|
but have no IPv6 space can qualify for an appropriately sized IPv6 |
|
|
IPv6 block under the matching IPv6 policy. For example, a member |
|
block under the matching IPv6 policy. For example, a member that |
|
|
that has received an IPv4 IXP assignment will be eligible to |
|
has received an IPv4 IXP assignment will be eligible to receive an |
|
|
receive an IPv6 IXP assignment. |
|
IPv6 IXP assignment. |
|
|
|
|
|
|
|
5.1.2 Minimum size of IPv6 block |
|
5.1.2 Minimum size of IPv6 block |
|
|
|
|
|
|
|
The size of the IPv6 delegation for members that meet this |
|
The size of the IPv6 delegation for members that meet this |
|
|
criteria will be based on the following: |
|
criteria will be based on the following: |
|
|
|
|
|
|
|
* A member that has an IPv4 allocation is eligible for a /32 IPv6 |
|
* A member that has an IPv4 allocation is eligible for a /32 IPv6 |
|
|
address block. |
|
address block. |
|
|
* A member that has an IPv4 assignment is eligible for a /48 IPv6 |
|
* A member that has an IPv4 assignment is eligible for a /48 IPv6 |
|
|
address block. |
|
address block. |
|
|
|
|
|
|
|
If an APNIC member wishes to receive an initial allocation or |
|
If an APNIC member wishes to receive an initial allocation or |
|
|
assignment larger than the sizes described above, the member will |
|
assignment larger than the sizes described above, the member will |
|
|
|
need to apply under the alternative criteria described in |
|
need to apply under the alternative criteria described in sections |
|
|
sections 5.2 and 5.5 below. |
|
5.2 and 5.5 below. |
|
|
|
|
|
|
|
5.2 Initial allocation |
|
5.2 Initial allocation |
|
|
|
|
|
|
|
5.2.1 Initial allocation criteria |
|
5.2.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 make assignments |
|
will make assignments. |
|
|
d. Meet one of the two following criteria: |
|
d. Meet one of the two following criteria: |
|
|
|
* Have a plan for making at least 200 assignments to other |
|
* Have a plan for making at least 200 assignments to other |
|
|
organizations within two years OR |
|
organizations within two years OR |
|
|
* Be an existing LIR with IPv4 allocations from an APNIC or |
|
* Be an existing LIR with IPv4 allocations from an APNIC or an |
|
|
an NIR, which will make IPv6 assignments or sub-allocations |
|
NIR, which will make IPv6 assignments or sub-allocations to |
|
|
to other organizations and announce the allocation in the |
|
other organizations and announce the allocation in the inter- |
|
|
inter-domain routing system within two years |
|
domain routing system 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 |
|
also be eligible for an IPv6 address space allocation provided |
|
|
they meet equivalent criteria to those listed above. |
|
they meet equivalent criteria to those listed above. |
|
|
|
|
|
|
|
5.2.2 Minimum initial allocation size |
|
5.2.2 Minimum initial allocation size |
|
|
|
|
|
|
|
Organizations that meet the initial allocation criteria are |
|
Organizations that meet the initial allocation criteria are |
|
|
eligible to receive a minimum allocation of /32. |
|
eligible to receive a minimum allocation of /32. |
|
|
|
|
|
|
|
5.2.3 Larger initial allocations |
|
5.2.3 Larger initial allocations |
|
|
|
|
|
|
|
Initial allocations larger than /32 may be justified if: |
|
Initial allocations larger than /32 may be justified if: |
|
|
|
|
|
|
|
1. The organization provides comprehensive documentation of |
|
1. The organization provides comprehensive documentation of |
|
|
planned IPv6 infrastructure which would require a larger |
|
planned IPv6 infrastructure which would require a larger |
|
|
allocation; or |
|
allocation; or |
|
|
2. The organization provides comprehensive documentation of all |
|
2. The organization provides comprehensive documentation of all |
|
|
of the following: |
|
of the following: |
|
|
|
* its existing IPv4 infrastructure and customer base, |
|
* its existing IPv4 infrastructure and customer base, |
|
|
* its intention to provide its existing IPv4 services via |
|
* its intention to provide its existing IPv4 services via IPv6, |
|
|
IPv6, and |
|
and |
|
|
* its intention to move some of its existing IPv4 customers |
|
* its intention to move some of its existing IPv4 customers to |
|
|
to IPv6 within two years. |
|
IPv6 within two years. |
|
|
|
|
|
|
|
In either case, an allocation will be made which fulfills the |
|
In either case, an allocation will be made which fulfills the |
|
|
calculated address requirement, in accordance with the HD-Ratio |
|
calculated address requirement, in accordance with the HD-Ratio |
|
|
based utilization policy. |
|
based utilization policy. |
|
|
|
|
|
|
|
5.3 Subsequent allocation |
|
5.3 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.3.1 Subsequent allocation criteria |
|
5.3.1 Applied HD-Ratio |
|
|
|
|
|
|
|
Subsequent allocation will be provided when an organization |
|
Subsequent allocation will be provided when an organization |
|
|
(ISP/LIR) satisfies the evaluation threshold of past address |
|
(ISP/LIR) satisfies the evaluation threshold of past address |
|
|
utilization in terms of the number of sites in units of /56 |
|
utilization in terms of the number of sites in units of /56 |
|
|
|
assignments. The HD-Ratio [RFC 3194] is used to determine the |
|
assignments. |
|
|
utilization thresholds that justify the allocation of additional |
|
|
|
|
address as described below. |
|
|
|
|
|
|
|
|
|
|
5.3.2 Applied HD-Ratio |
|
The HD- Ratio [RFC 3194] is used to determine the utilization |
|
|
|
|
thresholds that justify the allocation of additional address as |
|
|
|
|
described below. |
|
|
|
|
|
|
|
The HD-Ratio value of 0.94 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 |
|
assignments that are necessary to achieve an acceptable |
|
|
utilization value for a given address block size. |
|
utilization value for a given address block size. |
|
|
|
|
|
|
|
|
5.3.3 Subsequent allocation size |
|
5.3.2 Alternative allocation criteria |
|
|
|
|
|
|
|
|
|
Alternatively, a subsequent allocation may be provided where an |
|
|
|
|
organization (ISP/LIR) can demonstrate a valid reason for |
|
|
|
|
requiring the subsequent allocation. For guidelines on what will |
|
|
|
|
be considered a valid technical or other reason, see “APNIC |
|
|
|
|
guidelines for IPv6 allocation and assignment requests”. |
|
|
|
|
|
|
|
|
|
http://www.apnic.net/criteria/ipv6-guidelines |
|
|
|
|
|
|
|
|
|
5.3.3 Subsequent Allocation Size |
|
|
|
|
|
|
|
When an organization has achieved an acceptable utilization for |
|
When an organization has achieved an acceptable utilization for |
|
|
its allocated address space, it is immediately eligible to obtain |
|
its allocated address space, it is immediately eligible to obtain |
|
|
|
an additional allocation that results in a doubling of the |
|
an additional allocation that results in a doubling of the address |
|
|
address space allocated to it. Where possible, the allocation |
|
space allocated to it. Where possible, except where separate |
|
|
will be made from an adjacent address block, meaning that its |
|
disaggregated ranges are requested for multiple discreet networks, |
|
|
existing allocation is extended by one bit to the left. |
|
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 |
|
If an organization needs more address space, it must provide |
|
|
documentation justifying its requirements for a two-year period. |
|
documentation justifying its requirements for a two-year period. |
|
|
The allocation made will be based on this requirement. |
|
The allocation made will be based on this requirement. |
|
|
|
|
|
|
|
5.4 LIR-to-ISP allocation |
|
5.4 LIR-to-ISP allocation |
|
|
|
|
|
|
|
There is no specific policy for an organization (LIR) to allocate |
|
There is no specific policy for an organization (LIR) to allocate |
|
|
address space to subordinate ISPs. Each LIR organization may |
|
address space to subordinate ISPs. Each LIR organization may |
|
|
develop its own policy for subordinate ISPs to encourage optimum |
|
develop its own policy for subordinate ISPs to encourage optimum |
|
|
utilization of the total address block allocated to the LIR. |
|
utilization of the total address block allocated to the LIR. |
|
|
However, all /48 assignments to end sites are required to be |
|
However, all /48 assignments to end sites are required to be |
|
|
|
registered either by the LIR or its subordinate ISPs in such a |
|
registered either by the LIR or its subordinate ISPs in such a way |
|
|
way that the RIR/NIR can properly evaluate the HD-Ratio when a |
|
that the RIR/NIR can properly evaluate the HD-Ratio when a |
|
|
subsequent allocation becomes necessary. |
|
subsequent allocation becomes necessary. |
|
|
|
|
|
|
|
5.5 Assignment |
|
5.5 Assignment |
|
|
|
|
|
|
|
LIRs must make IPv6 assignments in accordance with the following |
|
LIRs must make IPv6 assignments in accordance with the following |
|
|
provisions. |
|
provisions. |
|
|
|
|
|
|
|
5.5.1 Assignment address space size |
|
5.5.1 Assignment address space size |
|
|
|
|
|
|
|
End-users are assigned an end site assignment from their LIR or |
|
End-users are assigned an end site assignment from their LIR or |
|
|
ISP. The exact size of the assignment is a local decision for the |
|
ISP. 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 |
|
LIR or ISP to make, using a minimum value of a /64 (when only one |
|
|
subnet is anticipated for the end site) up to the normal maximum |
|
subnet is anticipated for the end site) up to the normal maximum |
|
|
of /48, except in cases of extra large end sites where a larger |
|
of /48, except in cases of extra large end sites where a larger |
|
|
assignment can be justified. |
|
assignment can be justified. |
|
|
|
|
|
|
|
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 |
|
except for the cases described in Section 4.4 and for the purposes |
|
|
purposes of measuring utilization as defined in this document. |
|
of measuring utilization as defined in this document. |
|
|
|
|
|
|
|
5.5.2 Assignment of multiple /48s to a single end site |
|
5.5.2 Assignment of multiple /48s to a single end site |
|
|
|
|
|
|
|
When a single end site requires an additional /48 address block, |
|
When a single end site requires an additional /48 address block, |
|
|
it must request the assignment with documentation or materials |
|
it must request the assignment with documentation or materials |
|
|
|
that justify the request. Requests for multiple or additional |
|
that justify the request. Requests for multiple or additional /48s |
|
|
/48s will be processed and reviewed (i.e., evaluation of |
|
will be processed and reviewed (i.e., evaluation of justification) |
|
|
justification) at the RIR/NIR level. |
|
at the RIR/NIR level. |
|
|
|
|
|
|
|
Note: There is no experience at the present time with the |
|
Note: There is no experience at the present time with the |
|
|
assignment of multiple /48s to the same end site. Having the RIR |
|
assignment of multiple /48s to the same end site. Having the RIR |
|
|
review all such assignments is intended to be a temporary measure |
|
review all such assignments is intended to be a temporary measure |
|
|
|
until some experience has been gained and some common policies |
|
until some experience has been gained and some common policies can |
|
|
can be developed. In addition, additional work at defining |
|
be developed. In addition, additional work at defining policies in |
|
|
policies in this space will likely be carried out in the near |
|
this space will likely be carried out in the near future. |
|
|
future. |
|
|
|
|
|
|
|
|
|
5.5.3 Assignment to operator’s infrastructure |
|
5.5.3 Assignment to operator’s infrastructure |
|
|
|
|
|
|
|
An organization (ISP/LIR) may assign a /48 per PoP as the service |
|
An organization (ISP/LIR) may assign a /48 per PoP as the service |
|
|
infrastructure of an IPv6 service operator. Each assignment to a |
|
infrastructure of an IPv6 service operator. Each assignment to a |
|
|
PoP is regarded as one assignment regardless of the number of |
|
PoP is regarded as one assignment regardless of the number of |
|
|
|
users using the PoP. A separate assignment can be obtained for |
|
users using the PoP. A separate assignment can be obtained for the |
|
|
the in-house operations of the operator. |
|
in-house operations of the operator. |
|
|
|
|
|
|
|
|
5.6. Registration |
|
5.6 Registration |
|
|
|
|
|
|
|
|
When an organization holding an IPv6 address allocation makes |
|
When an organization holding an IPv6 address allocation makes IPv6 |
|
|
IPv6 address assignments, it must register assignment information |
|
address assignments, it must register assignment information in a |
|
|
in a database, accessible by RIRs as appropriate (information |
|
database, accessible by RIRs as appropriate (information |
|
|
registered by an RIR/NIR may be replaced by a distributed |
|
registered by an RIR/NIR may be replaced by a distributed database |
|
|
database for registering address management information in |
|
for registering address management information in future). |
|
|
future). Information is registered in units of assigned /48 |
|
Information is registered in units of assigned /48 networks. When |
|
|
networks. When more than a /48 is assigned to an organization, |
|
more than a /48 is assigned to an organization, the assigning |
|
|
the assigning organization is responsible for ensuring that the |
|
organization is responsible for ensuring that the address space is |
|
|
address space is registered in an RIR/NIR database. |
|
registered in an RIR/NIR database. |
|
|
|
|
|
|
|
|
RIR/NIRs will use registered data to calculate the HD-Ratio at |
|
RIR/NIRs will use registered data to calculate the HD-Ratio at the |
|
|
the time of application for subsequent allocation and to check |
|
time of application for subsequent allocation and to check for |
|
|
for changes in assignments over time. |
|
changes in assignments over time. |
|
|
|
|
|
|
|
|
IRs shall maintain systems and practices that protect the |
|
IRs shall maintain systems and practices that protect the security |
|
|
security of personal and commercial information that is used in |
|
of personal and commercial information that is used in request |
|
|
request evaluation, but which is not required for public |
|
evaluation, but which is not required for public registration. |
|
|
registration. |
|
|
|
|
|
|
|
|
|
Organizations that receive an allocation from APNIC can choose |
|
Organizations that receive an allocation from APNIC can choose |
|
|
whether or not their customer assignment registrations should be |
|
whether or not their customer assignment registrations should be |
|
|
publicly available. If the organization does not indicate a |
|
publicly available. If the organization does not indicate a |
|
|
choice, or it chooses to hide its customer assignment |
|
choice, or it chooses to hide its customer assignment |
|
|
registrations, then those records will not be visible in the |
|
registrations, then those records will not be visible in the |
|
|
public whois database. Whois queries on these records will return |
|
public whois database. Whois queries on these records will return |
|
|
details of the allocation. |
|
details of the allocation. |
|
|
|
|
|
|
|
In addition, it is mandatory to register an Incident Report Team |
|
In addition, it is mandatory to register an Incident Report Team |
|
|
|
(IRT) object for each allocation and assignment record in the APNIC |
|
(IRT) object for each allocation and assignment record in the |
|
|
Whois Database. |
|
APNIC Whois Database. |
|
|
|
|
|
|
|
|
5.7. Reverse lookup |
|
5.7 Reverse lookup |
|
|
|
|
|
|
|
When an RIR/NIR delegates IPv6 address space to an organization, |
|
When an RIR/NIR delegates IPv6 address space to an organization, |
|
|
it also delegates the responsibility to manage the reverse lookup |
|
it also delegates the responsibility to manage the reverse lookup |
|
|
zone that corresponds to the allocated IPv6 address space. Each |
|
zone that corresponds to the allocated IPv6 address space. Each |
|
|
organization should properly manage its reverse lookup zone. When |
|
organization should properly manage its reverse lookup zone. When |
|
|
|
making an address assignment, the organization must delegate to |
|
making an address assignment, the organization must delegate to an |
|
|
an assignee organization, upon request, the responsibility to |
|
assignee organization, upon request, the responsibility to manage |
|
|
manage the reverse lookup zone that corresponds to the assigned |
|
the reverse lookup zone that corresponds to the assigned address. |
|
|
address. |
|
|
|
|
|
|
|
|
|
5.8 Existing IPv6 address space holders |
|
5.8 Existing IPv6 address space holders |
|
|
|
|
|
|
|
Organizations that received /35 IPv6 allocations under the |
|
Organizations that received /35 IPv6 allocations under the |
|
|
previous IPv6 address policy [RIRv6-Policies] are immediately |
|
previous IPv6 address policy [RIRv6-Policies] are immediately |
|
|
|
entitled to have their allocation expanded to a /32 address |
|
entitled to have their allocation expanded to a /32 address block, |
|
|
block, without providing justification, so long as they satisfy |
|
without providing justification, so long as they satisfy the |
|
|
the criteria in Section 5.1.1. The /32 address block will contain |
|
criteria in Section 5.1.1. The /32 address block will contain the |
|
|
the already allocated smaller address block (one or multiple /35 |
|
already allocated smaller address block (one or multiple /35 |
|
|
address blocks in many cases) that was already reserved by the |
|
address blocks in many cases) that was already reserved by the RIR |
|
|
RIR for a subsequent allocation to the organization. Requests for |
|
for a subsequent allocation to the organization. Requests for |
|
|
additional space beyond the minimum /32 size will be evaluated as |
|
additional space beyond the minimum /32 size will be evaluated as |
|
|
discussed elsewhere in the document. |
|
discussed elsewhere in the document. |
|
|
|
|
|
|
|
5.9 Portable assignments |
|
5.9 Portable assignments |
|
|
|
|
|
|
|
5.9.1 Small multihoming assignments |
|
5.9.1 Small multihoming assignments |
|
|
|
|
|
|
|
An organization is eligible to receive a portable assignment from |
|
An organization is eligible to receive a portable assignment from |
|
|
APNIC if it is currently multihomed or plans to be multihomed |
|
APNIC if it is currently multihomed or plans to be multihomed |
|
|
within three months. |
|
within three months. |
|
|
|
|
|
|
|
An organization is considered to be multihomed if its network |
|
An organization is considered to be multihomed if its network |
|
|
|
receives full-time connectivity from more than one ISP and has |
|
receives full-time connectivity from more than one ISP and has one |
|
|
one or more routing prefixes announced by at least two of its |
|
or more routing prefixes announced by at least two of its ISPs. |
|
|
ISPs. |
|
|
|
|
|
|
|
|
|
The minimum assignment made under these terms is /48. |
|
The minimum assignment made under these terms is /48. |
|
|
|
|
|
|
|
Address space assigned under these terms and not used for |
|
Address space assigned under these terms and not used for |
|
|
multihoming three months after assignment by APNIC will be |
|
multihoming three months after assignment by APNIC will be |
|
|
reclaimed. |
|
reclaimed. |
|
|
|
|
|
|
|
5.9.2 Internet Exchange Points |
|
5.9.2 Internet Exchange Points |
|
|
|
|
|
|
|
Internet Exchange Points are eligible to receive a portable |
|
Internet Exchange Points are eligible to receive a portable |
|
|
|
|
|
|
|
skipping to change at line 682 |
|
skipping to change at line 677 |
|
|
|
|
|
|
|
Global routability of the portable assignment is left to the |
|
Global routability of the portable assignment is left to the |
|
|
discretion of the IXP and its participants. |
|
discretion of the IXP and its participants. |
|
|
|
|
|
|
|
5.9.3 Critical infrastructure |
|
5.9.3 Critical infrastructure |
|
|
|
|
|
|
|
The following critical infrastructure networks, if operating in |
|
The following critical infrastructure networks, if operating in |
|
|
the Asia Pacific region, are eligible to receive a portable |
|
the Asia Pacific region, are eligible to receive a portable |
|
|
assignment: |
|
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 |
|
Assignments to critical infrastructure are available only to the |
|
|
actual operators of the network infrastructure performing such |
|
actual operators of the network infrastructure performing such |
|
|
functions. Registrar organizations which do not actually host the |
|
functions. Registrar organizations which do not actually host the |
|
|
network housing the registry infrastructure, will not be eligible |
|
network housing the registry infrastructure, will not be eligible |
|
|
for an assignment under this policy. |
|
for an assignment under this policy. |
|
|
|
|
|
|
|
|
The maximum assignment made under these terms is /32 per |
|
The maximum assignment made under these terms is /32 per operator. |
|
|
operator. |
|
|
|
|
|
|
|
|
|
Exchanges made under this policy remain subject to the address |
|
Exchanges made under this policy remain subject to the address |
|
|
space license policy. |
|
space license policy. |
|
|
|
|
|
|
|
|
6. References |
|
6. References |
|
|
|
|
|
|
|
[RFC1715] “The H Ratio for Address Assignment Efficiency”, C. |
|
[RFC1715] “The H Ratio for Address Assignment Efficiency”, C. |
|
|
Huitema. November 1994, RFC 1715. |
|
Huitema. November 1994, RFC 1715. |
|
|
|
|
|
|
|
[IAB-Request] “Email from IAB to IANA”, |
|
[IAB-Request] “Email from IAB to IANA”, |
|
|
http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt. |
|
http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt. |
|
|
|
|
|
|
|
[RFC2373] “IP Version 6 Addressing Architecture”, R. Hinden, S. |
|
[RFC2373] “IP Version 6 Addressing Architecture”, R. Hinden, S. |
|
|
Deering. July 1998, RFC 2373. |
|
Deering. July 1998, RFC 2373. |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 732 |
|
skipping to change at line 726 |
|
|
RFC 3194. |
|
RFC 3194. |
|
|
|
|
|
|
|
[RIRs-on-48] |
|
[RIRs-on-48] |
|
|
http://www.arin.net/library/guidelines/ipv6_initial.html, |
|
http://www.arin.net/library/guidelines/ipv6_initial.html, |
|
|
|
|
|
|
|
[RIRv6-Policies] |
|
[RIRv6-Policies] |
|
|
http://www.arin.net/regserv/ipv6/ipv6guidelines.html, |
|
http://www.arin.net/regserv/ipv6/ipv6guidelines.html, |
|
|
|
|
|
|
|
http://www.ripe.net/ripe/docs/ripe-196.html, |
|
http://www.ripe.net/ripe/docs/ripe-196.html, |
|
|
|
|
|
|
|
|
http://archive.apnic.net/docs/drafts/ipv6/ipv6-policy- |
|
http://archive.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html. |
|
|
280599.html. |
|
|
|
|
|
|
|
|
|
7. Appendix A: HD-Ratio |
|
7. Appendix A: HD-Ratio |
|
|
|
|
|
|
|
The utilization threshold T, expressed as a number of individual |
|
The utilization threshold T, expressed as a number of individual |
|
|
/56 prefixes to be allocated from IPv6 prefix P, can be |
|
/56 prefixes to be allocated from IPv6 prefix P, can be |
|
|
calculated as: |
|
calculated as: |
|
|
|
|
|
|
|
T=2((56-P)*HD) |
|
T=2((56-P)*HD) |
|
|
|
|
|
|
|
Thus, the utilization threshold for an organization requesting |
|
Thus, the utilization threshold for an organization requesting |
|
|
|
|
|
|
|
skipping to change at line 777 |
|
skipping to change at line 770 |
|
|
49 7 128 96 74.7 |
|
49 7 128 96 74.7 |
|
|
48 8 256 184 71.7 |
|
48 8 256 184 71.7 |
|
|
47 9 512 352 68.8 |
|
47 9 512 352 68.8 |
|
|
46 10 1,024 676 66.0 |
|
46 10 1,024 676 66.0 |
|
|
45 11 2,048 1,296 63.3 |
|
45 11 2,048 1,296 63.3 |
|
|
44 12 4,096 2,487 60.7 |
|
44 12 4,096 2,487 60.7 |
|
|
43 13 8,192 4,771 58.2 |
|
43 13 8,192 4,771 58.2 |
|
|
42 14 16,384 9,153 55.9 |
|
42 14 16,384 9,153 55.9 |
|
|
41 15 32,768 17,560 53.6 |
|
41 15 32,768 17,560 53.6 |
|
|
40 16 65,536 33,689 51.4 |
|
40 16 65,536 33,689 51.4 |
|
|
|
39 17 131,072 64,634 49.3 |
|
39 17 131,072 64,634 49.3 |
|
|
38 18 262,144 124,002 47.3 |
|
38 18 262,144 124,002 47.3 |
|
|
|
37 19 524,288 237,901 45.4 |
|
37 19 524,288 237,901 45.4 |
|
|
36 20 1,048,576 456,419 43.5 |
|
36 20 1,048,576 456,419 43.5 |
|
|
35 21 2,097,152 875,653 41.8 |
|
35 21 2,097,152 875,653 41.8 |
|
|
34 22 4,194,304 1,679,965 40.1 |
|
34 22 4,194,304 1,679,965 40.1 |
|
|
33 23 8,388,608 3,223,061 38.4 |
|
33 23 8,388,608 3,223,061 38.4 |
|
|
32 24 16,777,216 6,183,533 36.9 |
|
32 24 16,777,216 6,183,533 36.9 |
|
|
31 25 33,554,432 11,863,283 35.4 |
|
31 25 33,554,432 11,863,283 35.4 |
|
|
30 26 67,108,864 22,760,044 33.9 |
|
30 26 67,108,864 22,760,044 33.9 |
|
|
29 27 134,217,728 43,665,787 32.5 |
|
29 27 134,217,728 43,665,787 32.5 |
|
|
28 28 268,435,456 83,774,045 31.2 |
|
28 28 268,435,456 83,774,045 31.2 |
|
|
27 29 536,870,912 160,722,871 29.9 |
|
27 29 536,870,912 160,722,871 29.9 |
|
|
26 30 1,073,741,824 308,351,367 28.7 |
|
26 30 1,073,741,824 308,351,367 28.7 |
|
|
|
|
|
|
End of changes. 57 change blocks. |
|
163 lines changed or deleted |
|
156 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/ |