APNIC Home

diff_apnic-089-v007

 apnic-089-v006.txt   apnic-089-v007.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: 006 Version: 007
Date of original publication: 1 July 2002 Date of original publication: 1 July 2002
Date of this version: 4 August 2008 Date of this version: 10 February 2010
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
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. incorporates APNIC-specific policies developed since that time.
Abstract Abstract
This document defines registry policies for the assignment and This document defines registry policies for the assignment and
allocation of globally-unique IPv6 addresses to ISPs and other allocation of globally-unique IPv6 addresses to ISPs and other
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
Status of this Memo 1. Introduction
1. Introduction 1.1 Overview
1.1. Overview 2. Definitions
2. Definitions 2.1 Internet Registry (IR)
2.2 Regional Internet Registry (RIR)
2.3 National Internet Registry (NIR)
2.4 Local Internet Registry (LIR)
2.5 Allocate
2.6 Assign
2.7 Utilization
2.8 HD-Ratio
2.9 End site
2.10 Internet Exchange Point (IXP)
2.1. Internet Registry (IR) 3. Goals of IPv6 address space management
2.2. Regional Internet Registry (RIR)
2.3. National Internet Registry (NIR)
2.4. Local Internet Registry (LIR)
2.5. Allocate
2.6. Assign
2.7. Utilization
2.8. HD-Ratio
2.9. End site
2.10. Internet Exchange Point (IXP)
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
3.1. Goals 4. IPv6 Policy Principles
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 property
4.2 Routability not guaranteed
4.3 Minimum Allocation
4.4 Consideration of IPv4 infrastructure
4.1. Address space not to be considered property 5. Policies for allocations and assignments
4.2. Routability not guaranteed
4.3. Minimum Allocation
4.4. Consideration of IPv4 infrastructure
5. Policies for allocations and assignments 5.1 Initial IPv6 block for APNIC members with existing IPv4 space
5.1. Initial allocation 5.1.1 Criteria
5.1.2 Minimum size of IPv6 block
5.1.1. Initial allocation criteria 5.2 Initial allocation
5.1.2. Minimum initial allocation size
5.1.3. Larger initial allocations
5.2. Subsequent allocation 5.2.1 Initial allocation criteria
5.2.2 Minimum initial allocation size
5.2.3 Larger initial allocations
5.2.1. Subsequent allocation criteria 5.3 Subsequent allocation
5.2.2. Applied HD-Ratio
5.2.3. Subsequent Allocation Size
5.3. LIR-to-ISP allocation 5.3.1 Subsequent allocation criteria
5.3.2 Applied HD-Ratio
5.3.3 Subsequent Allocation Size
5.4. Assignment 5.4 LIR-to-ISP allocation
5.4.1. Assignment address space size 5.5 Assignment
5.4.2. Assignment of multiple /48s to a single end site
5.4.3. Assignment to operator’s infrastructure
5.5. Registration 5.5.1 Assignment address space size
5.5.2 Assignment of multiple /48s to a single end site
5.5.3 Assignment to operator’s infrastructure
5.6. Reverse lookup 5.6 Registration
5.7. Existing IPv6 address space holders 5.7 Reverse lookup
5.8. Portable assignments 5.8 Existing IPv6 address space holders
5.8.1. Small multihoming assignments 5.9 Portable assignments
5.8.2. Internet Exchange Points
5.8.3. Critical infrastructure
6. References 5.9.1 Small multihoming assignments
5.9.2 Internet Exchange Points
5.9.3 Critical infrastructure
7. Appendix A: HD-Ratio 6. References
8. Appendix B: Background information 7. Appendix A: HD-Ratio
8.1. Background 8. Appendix B: Background information
8.2. Why a joint policy
8.3. The size of IPv6’s address space
8.4. Acknowledgment
1. Introduction 8.1 Background
8.2 Why a joint policy
8.3 The size of IPv6’s address space
8.4 Acknowledgment
1.1. Overview 1. Introduction
This document describes policies for the allocation and assignment of 1.1 Overview
globally-unique Internet Protocol Version 6 (IPv6) address space. It
updates and obsoletes the existing Provisional IPv6 Policies in
effect since 1999 [RIRv6-Policies]. Policies described in this
document are intended to be adopted by each registry. However,
adoption of this document does not preclude local variations in each
region or area.
[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast address This document describes policies for the allocation and
space that IANA may allocate to the RIRs. In accordance with assignment of globally-unique Internet Protocol Version 6 (IPv6)
[RFC2928, RFC2373bis, IAB-Request], IANA has allocated initial ranges address space. It updates and obsoletes the existing Provisional
of global unicast IPv6 address space from the 2001::/16 address block IPv6 Policies in effect since 1999 [RIRv6-Policies]. Policies
to the existing RIRs. This document concerns the initial and described in this document are intended to be adopted by each
subsequent allocations of the 2000::/3 unicast address space, for registry. However, adoption of this document does not preclude
which RIRs formulate allocation and assignment policies. local variations in each region or area.
This policy is considered to be an interim policy. It will be [RFC2373, RFC2373bis] designate 2000::/3 to be global unicast
reviewed in the future, subject to greater experience in the address space that IANA may allocate to the RIRs. In accordance
administration of IPv6. 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.
2. Definitions This policy is considered to be an interim policy. It will be
reviewed in the future, subject to greater experience in the
administration of IPv6.
[note: some of these definitions will be replaced by definitions from 2. Definitions
other RIR documents in order to be more consistent.]
The following terms and their definitions are of particular [Note: some of these definitions will be replaced by definitions
importance to the understanding of the goals, environment, and from other RIR documents in order to be more consistent.]
policies described in this document.
Responsibility for management of IPv6 address spaces is distributed The following terms and their definitions are of particular
globally in accordance with the hierarchical structure shown below. importance to the understanding of the goals, environment, and
policies described in this document.
Responsibility for management of IPv6 address spaces is
distributed globally in accordance with the hierarchical
structure shown below.
Figure 1 Distribution Hierarchy
+——–+ +——–+
| IANA | | IANA |
+——–+ +——–+
| |
+———–+ +———–+
| | | |
+——–+ +——–+ +——–+ +——–+
| RIR | | RIR | Regional Internet | RIR | | RIR | Regional Internet
+——–+ +——–+ Registries (APNIC, ARIN, RIPE NCC, +——–+ +——–+ Registries (APNIC, ARIN, RIPE NCC,
skipping to change at line 181 skipping to change at line 187
+——–+ +——–+ +——–+ +——–+
|LIR/ISP | |LIR/ISP | Local Internet |LIR/ISP | |LIR/ISP | Local Internet
+——–+ +——–+ Registries (ISPs) +——–+ +——–+ Registries (ISPs)
| | | |
+——–+ | +——–+ |
| | | | | |
+——-+ +—-+ +—-+ +——-+ +—-+ +—-+
|EU(ISP)| | EU | | EU | End users |EU(ISP)| | EU | | EU | End users
+——-+ +—-+ +—-+ +——-+ +—-+ +—-+
2.1. Internet Registry (IR) 2.1 Internet Registry (IR)
An Internet Registry (IR) is an organization that is responsible for An Internet Registry (IR) is an organization that is responsible
distributing IP address space to its members or customers and for for distributing IP address space to its members or customers and
registering those distributions. IRs are classified according to for registering those distributions. IRs are classified according
their primary function and territorial scope within the hierarchical to their primary function and territorial scope within the
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 authorized by Regional Internet Registries (RIRs) are established and
respective regional communities, and recognized by the IANA to serve authorized by respective regional communities, and recognized by
and represent large geographical regions. The primary role of RIRs the IANA to serve and represent large geographical regions. The
is to manage and distribute public Internet address space within primary role of RIRs is to manage and distribute public Internet
their respective regions. address space within their respective regions.
2.3. National Internet Registry (NIR) 2.3 National Internet Registry (NIR)
A National Internet Registry (NIR) primarily allocates address space A National Internet Registry (NIR) primarily allocates address
to its members or constituents, which are generally LIRs organized at space to its members or constituents, which are generally LIRs
a national level. NIRs exist mostly in the Asia Pacific region. organized at a national level. NIRs exist mostly in the Asia
Pacific region.
2.4. Local Internet Registry (LIR) 2.4 Local Internet Registry (LIR)
A Local Internet Registry (LIR) is an IR that primarily assigns A Local Internet Registry (LIR) is an IR that primarily assigns
address space to the users of the network services that it provides. address space to the users of the network services that it
LIRs are generally ISPs, whose customers are primarily end users and provides. LIRs are generally ISPs, whose customers are primarily
possibly other ISPs. end users and possibly other ISPs.
2.5. Allocate 2.5 Allocate
To allocate means to distribute address space to IRs for the purpose To allocate means to distribute address space to IRs for the
of subsequent distribution by them. purpose of subsequent distribution by them.
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,
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 low, when compared to IPv4 assignments. In IPv6, “utilization” quite low, when compared to IPv4 assignments. In IPv6,
is only measured in terms of the bits to the left of the /56 “utilization” is only measured in terms of the bits to the left
boundary. In other words, utilization refers to the assignment of of the /56 boundary. In other words, utilization refers to the
/56s to end sites, and not the number of addresses assigned within assignment of /56s to end sites, and not the number of addresses
individual /56s at those end sites. assigned within 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 originally assignment [RFC 3194]. It is an adaptation of the H-Ratio
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 business An end site is defined as an end user (subscriber) who has a
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 user * that service provider providing transit service for the end
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 * that service provider advertising an aggregate prefix route
contains the end user’s assignment that 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 network An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2
structure that interconnects three or more Autonomous Systems (AS) for network structure that interconnects three or more Autonomous
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 a internet. Responsible address space management involves balancing
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 guarantee Every assignment and/or allocation of address space must
uniqueness worldwide. This is an absolute requirement for ensuring guarantee uniqueness worldwide. This is an absolute requirement
that every public host on the Internet can be uniquely identified. for ensuring that every public host on the Internet can be
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 is accessible to appropriate members of the Internet community. This
necessary to ensure the uniqueness of each Internet address and to is necessary to ensure the uniqueness of each Internet address
provide reference information for Internet troubleshooting at all and to provide reference information for Internet troubleshooting
levels, ranging from all RIRs and IRs to end users. at 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 Internet routing information by ISPs, and to limit the expansion of
routing tables. Internet routing tables.
This goal is particularly important in IPv6 addressing, where the This goal is particularly important in IPv6 addressing, where the
size of the total address pool creates significant implications for size of the total address pool creates significant implications
both internal and external routing. for both internal and external routing.
IPv6 address policies should seek to avoid fragmentation of address IPv6 address policies should seek to avoid fragmentation of
ranges. address ranges.
Further, RIRs should apply practices that maximize the potential for Further, RIRs should apply practices that maximize the potential
subsequent allocations to be made contiguous with past allocations for subsequent allocations to be made contiguous with past
currently held. However, there can be no guarantee of contiguous allocations currently held. However, there can be no guarantee of
allocation. contiguous allocation.
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 avoided. documentation and stockpiling of unused addresses should be
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 potential space should apply fairly and equitably to all existing and
members of the Internet community, regardless of their location, potential members of the Internet community, regardless of their
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 obtaining It is desirable to minimize the overhead associated with
address space. Overhead includes the need to go back to RIRs for obtaining address space. Overhead includes the need to go back to
additional space too frequently, the overhead associated with RIRs for additional space too frequently, the overhead associated
managing address space that grows through a number of small with 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, seeking requests for allocations and assignments must make judgments,
to balance the needs of the applicant with the needs of the Internet seeking to balance the needs of the applicant with the needs of
community as a whole. the Internet community as a whole.
In IPv6 address policy, the goal of aggregation is considered to be In IPv6 address policy, the goal of aggregation is considered to
the most important. be the most important.
4. IPv6 Policy Principles 4. IPv6 Policy Principles
To address the goals described in the previous section, the policies To address the goals described in the previous section, the
in this document discuss and follow the basic principles described policies in this document discuss and follow the basic principles
below. described below.
4.1. Address space not to be considered property 4.1 Address space not to be considered property
It is contrary to the goals of this document and is not in the It is contrary to the goals of this document and is not in the
interests of the Internet community as a whole for address space to interests of the Internet community as a whole for address space
be considered freehold property. to be considered freehold property.
The policies in this document are based upon the understanding that The policies in this document are based upon the understanding
globally-unique IPv6 unicast address space is licensed for use rather that globally-unique IPv6 unicast address space is licensed for
than owned. Specifically, IP addresses will be allocated and use rather than owned. Specifically, IP addresses will be
assigned on a license basis, with licenses subject to renewal on a allocated and assigned on a license basis, with licenses subject
periodic basis. The granting of a license is subject to specific to renewal on a periodic basis. The granting of a license is
conditions applied at the start or renewal of the license. subject to specific conditions applied at the start or renewal of
the license.
RIRs will generally renew licenses automatically, provided requesting RIRs will generally renew licenses automatically, provided
organizations are making a good-faith effort at meeting the criteria requesting organizations are making a good-faith effort at
under which they qualified for or were granted an allocation or meeting the criteria under which they qualified for or were
assignment. However, in those cases where a requesting organization granted an allocation or assignment. However, in those cases
is not using the address space as intended, or is showing bad faith where a requesting organization is not using the address space as
in following through on the associated obligation, RIRs reserve the intended, or is showing bad faith in following through on the
right to not renew the license. associated obligation, RIRs reserve the right to not renew the
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 policies evaluated under and governed by the applicable IPv6 address
in place at the time of renewal, which may differ from the policy in policies in place at the time of renewal, which may differ from
place at the time of the original allocation or assignment. the policy in place at the time of the original allocation or
assignment.
4.2. Routability not guaranteed 4.2 Routability not guaranteed
There is no guarantee that any address allocation or assignment will There is no guarantee that any address allocation or assignment
be globally routable. will be globally routable.
However, RIRs must apply procedures that reduce the possibility of However, RIRs must apply procedures that reduce the possibility
fragmented address space which may lead to a loss of routability. of fragmented address space which may lead to a loss of
routability.
4.3. Minimum Allocation 4.3 Minimum Allocation
RIRs will apply a minimum size for IPv6 allocations, to facilitate RIRs will apply a minimum size for IPv6 allocations, to
prefix-based filtering. facilitate 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 considered in Subject to section 5.1.3, existing IPv4 networks may be
determining the initial IPv6 allocation size. considered in determining the initial IPv6 allocation size.
5. Policies for allocations and assignments 5. Policies for allocations and assignments
5.1. Initial allocation 5.1 Initial IPv6 block for APNIC members with existing IPv4 space
5.1.1. Initial allocation criteria 5.1.1 Criteria
To qualify for an initial allocation of IPv6 address space, an APNIC members that have received an IPv4 address block from APNIC
organization must: but have no IPv6 space can qualify for an appropriately sized
IPv6 block under the matching IPv6 policy. For example, a member
that has received an IPv4 IXP assignment will be eligible to
receive an IPv6 IXP assignment.
a) be an LIR 5.1.2 Minimum size of IPv6 block
b) not be an end site
c) plan to provide IPv6 connectivity to organizations to which it
will make assignments, by advertising that connectivity through
its single aggregated address allocation
d) meet one of the two following criteria:
– have a plan for making at least 200 assignments to other
organizations within two years OR
– be an existing LIR with IPv4 allocations from APNIC or an NIR
that will make IPv6 assignments or sub-allocations to other
organizations and announce the allocation in the inter-domain
routing system within two years
Private networks (those not connected to the public Internet) may The size of the IPv6 delegation for members that meet this
also be eligible for an IPv6 address space allocation provided they criteria will be based on the following:
meet equivalent criteria to those listed above.
5.1.2. Minimum initial allocation size * A member that has an IPv4 allocation is eligible for a /32 IPv6
address block.
* A member that has an IPv4 assignment is eligible for a /48 IPv6
address block.
Organizations that meet the initial allocation criteria are eligible If an APNIC member wishes to receive an initial allocation or
to receive a minimum allocation of /32. assignment larger than the sizes described above, the member will
need to apply under the alternative criteria described in
sections 5.2 and 5.5 below.
5.1.3. Larger initial allocations 5.2 Initial allocation
Initial allocations larger than /32 may be justified if: 5.2.1 Initial allocation criteria
a) The organization provides comprehensive documentation of To qualify for an initial allocation of IPv6 address space, an
planned IPv6 infrastructure which would require a larger organization must:
allocation; or
b) The organization provides comprehensive documentation of all of 1. Be an LIR
the following: 2. Not be an end site
– its existing IPv4 infrastructure and customer base, 3. Plan to provide IPv6 connectivity to organizations to which it
– its intention to provide its existing IPv4 services via will make assignments, by advertising that connectivity
through its single aggregated address allocation
4. Meet one of the two following criteria:
* Have a plan for making at least 200 assignments to other
organizations within two years OR
* Be an existing LIR with IPv4 allocations from an APNIC or
an NIR, which will make IPv6 assignments or sub-allocations
to other organizations and announce the allocation in the
inter-domain routing system within two years
Private networks (those not connected to the public Internet) may
also be eligible for an IPv6 address space allocation provided
they meet equivalent criteria to those listed above.
5.2.2 Minimum initial allocation size
Organizations that meet the initial allocation criteria are
eligible to receive a minimum allocation of /32.
5.2.3 Larger initial allocations
Initial allocations larger than /32 may be justified if:
1. The organization provides comprehensive documentation of
planned IPv6 infrastructure which would require a larger
allocation; or
2. The organization provides comprehensive documentation of all
of the following:
* its existing IPv4 infrastructure and customer base,
* its intention to provide its existing IPv4 services via
IPv6, and IPv6, and
– its intention to move some of its existing IPv4 customers to * its intention to move some of its existing IPv4 customers
IPv6 within two years. to 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 based calculated address requirement, in accordance with the HD-Ratio
utilization policy. based utilization policy.
5.2. 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.2.1. Subsequent allocation criteria 5.3.1 Subsequent allocation criteria
Subsequent allocation will be provided when an organization (ISP/LIR) Subsequent allocation will be provided when an organization
satisfies the evaluation threshold of past address utilization in (ISP/LIR) satisfies the evaluation threshold of past address
terms of the number of sites in units of /56 assignments. The HD- utilization in terms of the number of sites in units of /56
Ratio [RFC 3194] is used to determine the utilization thresholds that assignments. The HD- Ratio [RFC 3194] is used to determine the
justify the allocation of additional address as described below. utilization thresholds that justify the allocation of additional
address as described below.
5.2.2. Applied HD-Ratio 5.3.2 Applied HD-Ratio
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 utilization assignments that are necessary to achieve an acceptable
value for a given address block size. utilization value for a given address block size.
5.2.3. Subsequent Allocation Size 5.3.3 Subsequent allocation size
When an organization has achieved an acceptable utilization for its When an organization has achieved an acceptable utilization for
allocated address space, it is immediately eligible to obtain an its allocated address space, it is immediately eligible to obtain
additional allocation that results in a doubling of the address space an additional allocation that results in a doubling of the
allocated to it. Where possible, the allocation will be made from an address space allocated to it. Where possible, the allocation
adjacent address block, meaning that its existing allocation is will be made from an adjacent address block, meaning that its
extended by one bit to the left. 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. The documentation justifying its requirements for a two-year period.
allocation made will be based on this requirement. The allocation made will be based on this requirement.
5.3. 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 develop address space to subordinate ISPs. Each LIR organization may
its own policy for subordinate ISPs to encourage optimum utilization develop its own policy for subordinate ISPs to encourage optimum
of the total address block allocated to the LIR. However, all /48 utilization of the total address block allocated to the LIR.
assignments to end sites are required to be registered either by the However, all /48 assignments to end sites are required to be
LIR or its subordinate ISPs in such a way that the RIR/NIR can registered either by the LIR or its subordinate ISPs in such a
properly evaluate the HD-Ratio when a subsequent allocation becomes way that the RIR/NIR can properly evaluate the HD-Ratio when a
necessary. subsequent allocation becomes necessary.
5.4. 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.4.1. Assignment address space size 5.5.1 Assignment address space size
End-users are assigned an end site assignment from their LIR or ISP. End-users are assigned an end site assignment from their LIR or
The exact size of the assignment is a local decision for the LIR or ISP. The exact size of the assignment is a local decision for the
ISP to make, using a minimum value of a /64 (when only one subnet is LIR or ISP to make, using a minimum value of a /64 (when only one
anticipated for the end site) up to the normal maximum of /48, subnet is anticipated for the end site) up to the normal maximum
except in cases of extra large end sites where a larger assignment of /48, except in cases of extra large end sites where a larger
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 purposes of except for the cases described in Section 4.4 and for the
measuring utilization as defined in this document. purposes of measuring utilization as defined in this document.
5.4.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, it When a single end site requires an additional /48 address block,
must request the assignment with documentation or materials that it must request the assignment with documentation or materials
justify the request. Requests for multiple or additional /48s will that justify the request. Requests for multiple or additional
be processed and reviewed (i.e., evaluation of justification) at the /48s will be processed and reviewed (i.e., evaluation of
RIR/NIR level. justification) at the RIR/NIR level.
Note: There is no experience at the present time with the assignment Note: There is no experience at the present time with the
of multiple /48s to the same end site. Having the RIR review all assignment of multiple /48s to the same end site. Having the RIR
such assignments is intended to be a temporary measure until some review all such assignments is intended to be a temporary measure
experience has been gained and some common policies can be developed. until some experience has been gained and some common policies
In addition, additional work at defining policies in this space will can be developed. In addition, additional work at defining
likely be carried out in the near future. policies in this space will likely be carried out in the near
future.
5.4.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 PoP infrastructure of an IPv6 service operator. Each assignment to a
is regarded as one assignment regardless of the number of users using PoP is regarded as one assignment regardless of the number of
the PoP. A separate assignment can be obtained for the in-house users using the PoP. A separate assignment can be obtained for
operations of the operator. the in-house operations of the operator.
5.5. Registration 5.6. Registration
When an organization holding an IPv6 address allocation makes IPv6 When an organization holding an IPv6 address allocation makes
address assignments, it must register assignment information in a IPv6 address assignments, it must register assignment information
database, accessible by RIRs as appropriate (information registered in a database, accessible by RIRs as appropriate (information
by an RIR/NIR may be replaced by a distributed database for registered by an RIR/NIR may be replaced by a distributed
registering address management information in future). Information database for registering address management information in
is registered in units of assigned /48 networks. When more than a future). Information is registered in units of assigned /48
/48 is assigned to an organization, the assigning organization is networks. When more than a /48 is assigned to an organization,
responsible for ensuring that the address space is registered in an the assigning organization is responsible for ensuring that the
RIR/NIR database. address space is registered in an 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
time of application for subsequent allocation and to check for the time of application for subsequent allocation and to check
changes in assignments over time. for 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
personal and commercial information that is used in request security of personal and commercial information that is used in
evaluation, but which is not required for public registration. request evaluation, but which is not required for public
registration.
Organizations that receive an allocation from APNIC can choose whether Organizations that receive an allocation from APNIC can choose
or not their customer assignment registrations should be publicly whether or not their customer assignment registrations should be
available. If the organization does not indicate a choice, or it chooses publicly available. If the organization does not indicate a
to hide its customer assignment registrations, then those records will choice, or it chooses to hide its customer assignment
not be visible in the public whois database. Whois queries on these registrations, then those records will not be visible in the
records will return details of the allocation. public whois database. Whois queries on these records will return
details of the allocation.
5.6. Reverse lookup 5.7. Reverse lookup
When an RIR/NIR delegates IPv6 address space to an organization, it When an RIR/NIR delegates IPv6 address space to an organization,
also delegates the responsibility to manage the reverse lookup zone it also delegates the responsibility to manage the reverse lookup
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 an making an address assignment, the organization must delegate to
assignee organization, upon request, the responsibility to manage the an assignee organization, upon request, the responsibility to
reverse lookup zone that corresponds to the assigned address. manage the reverse lookup zone that corresponds to the assigned
address.
5.7. Existing IPv6 address space holders 5.8 Existing IPv6 address space holders
Organizations that received /35 IPv6 allocations under the previous Organizations that received /35 IPv6 allocations under the
IPv6 address policy [RIRv6-Policies] are immediately entitled to have previous IPv6 address policy [RIRv6-Policies] are immediately
their allocation expanded to a /32 address block, without providing entitled to have their allocation expanded to a /32 address
justification, so long as they satisfy the criteria in Section 5.1.1. block, without providing justification, so long as they satisfy
The /32 address block will contain the already allocated smaller the criteria in Section 5.1.1. The /32 address block will contain
address block (one or multiple /35 address blocks in many cases) that the already allocated smaller address block (one or multiple /35
was already reserved by the RIR for a subsequent allocation to the address blocks in many cases) that was already reserved by the
organization. Requests for additional space beyond the minimum /32 RIR for a subsequent allocation to the organization. Requests for
size will be evaluated as discussed elsewhere in the document. additional space beyond the minimum /32 size will be evaluated as
discussed elsewhere in the document.
5.8. Portable assignments 5.9 Portable assignments
5.8.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 receives An organization is considered to be multihomed if its network
full-time connectivity from more than one ISP and has one or more receives full-time connectivity from more than one ISP and has
routing prefixes announced by at least two of its ISPs. one or more routing prefixes announced by at least two of its
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 that is not used for Address space assigned under these terms and not used for
multihoming within three months of assignment by APNIC will be multihoming three months after assignment by APNIC will be
reclaimed. reclaimed.
5.8.2. Internet Exchange Points 5.9.2 Internet Exchange Points
Internet Exchange Points are eligible to receive a portable assignment Internet Exchange Points are eligible to receive a portable
from APNIC to be used exclusively to connect the IXP participant devices assignment from APNIC to be used exclusively to connect the IXP
to the Exchange Point. participant devices 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
of the IXP and its participants. discretion of the IXP and its participants.
5.8.3. Critical infrastructure 5.9.3 Critical infrastructure
The following critical infrastructure networks, if operating in the Asia The following critical infrastructure networks, if operating in
Pacific region, are eligible to receive a portable assignment: the Asia 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
operators of the network infrastructure performing such functions. Registrar actual operators of the network infrastructure performing such
organisations which do not actually host the network housing the registry functions. Registrar organizations which do not actually host the
infrastructure, will not be eligible for an assignment under this policy. network housing the registry 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
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.
[RFC2373bis] draft-ietf-ipngwg-addr-arch-v3-07.txt. [RFC2373bis] draft-ietf-ipngwg-addr-arch-v3-07.txt.
[RFC2928] “Initial IPv6 Sub-TLA ID Assignments”, R. Hinden, S. [RFC2928] “Initial IPv6 Sub-TLA ID Assignments”, R. Hinden, S.
Deering, R. Fink, T. Hain. September 2000, RFC 2928. Deering, R. Fink, T. Hain. September 2000, RFC 2928.
[RFC3177] “IAB/IESG Recommendations on IPv6 Address”. IAB, IESG. [RFC3177] “IAB/IESG Recommendations on IPv6 Address”. IAB, IESG.
September 2001, RFC 3177. September 2001, RFC 3177.
[RFC3194] “The H-Density Ratio for Address Assignment Efficiency An [RFC3194] “The H-Density Ratio for Address Assignment Efficiency
Update on the H ratio”, A. Durand, C. Huitema. November An Update on the H ratio”, A. Durand, C. Huitema. November 2001,
2001, 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.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html.
7. Appendix A: HD-Ratio http://www.ripe.net/ripe/docs/ripe-196.html,
The HD-Ratio is not intended to replace the traditional utilization http://archive.apnic.net/docs/drafts/ipv6/ipv6-policy-
measurement that ISPs perform with IPv4 today. Indeed, the HD-Ratio 280599.html.
still 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 7. Appendix A: HD-Ratio
prefixes to be allocated from IPv6 prefix P, can be calculated as:
((56-P)*HD) The utilization threshold T, expressed as a number of individual
T = 2 /56 prefixes to be allocated from IPv6 prefix P, can be
calculated as:
Thus, the utilization threshold for an organization requesting T=2((56-P)*HD)
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.
This document adopts an HD-Ratio of 0.94 as the utilization Thus, the utilization threshold for an organization requesting
threshold for IPv6 address space allocations. 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 This document adopts an HD-Ratio of 0.94 as the utilization
address utilization figures for IPv6 prefixes, corresponding to an threshold for IPv6 address space allocations.
HD-Ratio of 0.94
P 56-P Total /56s Threshold Util % 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 56 0 1 1 100.0
55 1 2 2 95.9 55 1 2 2 95.9
54 2 4 4 92.0 54 2 4 4 92.0
53 3 8 7 88.3 53 3 8 7 88.3
52 4 16 14 84.7 52 4 16 14 84.7
51 5 32 26 81.2 51 5 32 26 81.2
50 6 64 50 77.9 50 6 64 50 77.9
49 7 128 96 74.7 49 7 128 96 74.7
48 8 256 184 71.7 48 8 256 184 71.7
skipping to change at line 759 skipping to change at line 799
12 44 17,592,186,044,416 2,822,283,395,519 16.0 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 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 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 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 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 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 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 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 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
The impetus for revising the 1999 Provisional IPv6 policy started 8.1 Background
with the APNIC meeting held in Taiwan in August 2001. Follow-on
discussions were held at the October, 2001 RIPE and ARIN meetings.
During these meetings, the participants recognized an urgent need for
more detailed, complete policies. One result of the meetings was the
establishment of a single mailing list to discuss a revised policy
together with a desire to develop a general policy that all RIRs
could use. This document does not provide details of individual
discussions that lead to policies described in this document;
detailed information can be found in the individual meeting minutes
at the www.apnic.net, www.arin.net, and www.ripe.net web sites.
8.2. Why a joint policy The impetus for revising the 1999 Provisional IPv6 policy started
with the APNIC meeting held in Taiwan in August 2001. Follow-on
discussions were held at the October, 2001 RIPE and ARIN
meetings. During these meetings, the participants recognized an
urgent need for more detailed, complete policies. One result of
the meetings was the establishment of a single mailing list to
discuss a revised policy together with a desire to develop a
general policy that all RIRs could use. This document does not
provide details of individual discussions that lead to policies
described in this document; detailed information can be found in
the individual meeting minutes at the www.apnic.net,
www.arin.net, and www.ripe.net web sites.
IPv6 addresses are a public resource that must be managed with 8.2 Why a joint policy
consideration to the long-term interests of the internet community.
Although regional registries adopt allocation policies according to
their own internal processes, address policies should largely be
uniform across registries. Having significantly varying policies in
different regions is undesirable because it can lead to situations
where “registry shopping” can occur as requesting organizations
request addresses from the registry that has the most favorable
policy for their particular desires. This can lead to the policies
in one region undermining the efforts of registries in other regions
with regards to prudent stewardship of the address space. In cases
where regional variations from the policy are deemed necessary, the
preferred approach is to raise the issue in the other regional
registries in order to develop a consensus approach that all
registries can support.
8.3. The size of IPv6’s address space IPv6 addresses are a public resource that must be managed with
consideration to the long-term interests of the internet
community. Although regional registries adopt allocation policies
according to their own internal processes, address policies
should largely be uniform across registries. Having significantly
varying policies in different regions is undesirable because it
can lead to situations where “registry shopping” can occur as
requesting organizations request addresses from the registry that
has the most favorable policy for their particular desires. This
can lead to the policies in one region undermining the efforts of
registries in other regions with regards to prudent stewardship
of the address space. In cases where regional variations from the
policy are deemed necessary, the preferred approach is to raise
the issue in the other regional registries in order to develop a
consensus approach that all registries can support.
Compared to IPv4, IPv6 has a seemingly endless amount of address 8.3 The size of IPv6’s address space
space. While superficially true, short-sighted and wasteful
allocation policies could also result in the adoption of practices
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.,
address). Although an “inefficient” way to use the Interface mac 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]. The middle simplify Stateless Address Autoconfiguration [RFC2462]. The
bits of an address indicate the subnet ID. middle bits of an address indicate the subnet ID.
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
policy drafting team consisting of Akihiro Inomata, Akinori Maemura, IPv6 policy drafting team consisting of Akihiro Inomata, Akinori
Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro
Toshiyuki Yamasaki. Special thanks goes out to this team, who worked Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this
over a holiday in order to produce an initial document quickly. team, who worked 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
the three RIRs (Takashi Arano, Chair of APNIC’s Policy SIG, Thomas of the three RIRs (Takashi Arano, Chair of APNIC’s Policy SIG,
Narten, Chair of ARIN‘s IPv6 WG, and David Kessens, Chair of RIPE Thomas Narten, Chair of ARIN‘s IPv6 WG, and David Kessens, Chair
NCC’s IPv6 WG). of RIPE NCC‘s IPv6 WG).
The editing team would like to acknowledge the contributions to this The editing team would like to acknowledge the contributions to
document of Takashi Arano, John Crain, Steve Deering, Gert Doering, this document of Takashi Arano, John Crain, Steve Deering, Gert
Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam
Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt, Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray
Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross,
Wittbrodt and Wilfried Woeber. Paul Wilson, Cathy Wittbrodt and Wilfried Woeber.
The final editing of this document was done by Thomas Narten. The final editing of the initial document was done by Thomas
Narten.
 End of changes. 194 change blocks. 
536 lines changed or deleted 574 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/