--------------------------------------------------------------------
APNIC Document identity
Title: APNIC guidelines for IPv6 allocation and assignment
requests
Short title: ipv6-guidelines
Document ref: APNIC-114
Version: 011
Date of original publication: 2 July 2004
Date of this version: xx July 2023
Review scheduled: n/a
Obsoletes: apnic-114-010
Status: Draft
Comments: Implements prop-145
---------------------------------------------------------------------
About this document
-------------------
These guidelines are intended to complement the document IPv6 address
allocation and assignment policy.
http://www.apnic.net/policy/ipv6-address-policy
These guidelines will be updated from time to time, in consultation with
the Asia Pacific and global Internet communities, to ensure they remain
appropriate to the current addressing environment.
Table of contents
-----------------
Section 1: Background
1. Introduction
2. Scope
3. Additional guidance
4. Goals of address space management
5. Application of guidelines
Section 2: General guidelines
6. Definitions
7. Sparse Delegation Framework
7.1. Avoiding Fragmentation
8. Allocations to LIRs
8.1. Initial allocation criteria
8.1.1. A plan for 200 assignments
8.1.2. Existing LIRs with IPv4 allocations from APNIC or an
NIR
8.1.3. Initial allocation larger than /32
8.1.4. Expanding allocations received before August
2004
8.1.5. Supporting documentation
8.2. Subsequent allocation criteria
8.2.1. Prior allocations to be used first
8.2.2. Special circumstances
9. Portable assignment criteria
9.1. Initial assignments
9.1.1. Multihoming assignment
9.1.2. Internet Exchange assignment
9.1.3. Critical Infrastructure assignment
9.1.4. Provider Independent assignment
9.2. Subsequent assignments
10. Delegations by LIRs
10.1. LIR assignments to end sites
10.1.1. Second opinion request
10.1.2. Supporting documentation
10.2. Sub-allocations by LIRs
11. Reverse DNS delegation
11.1. Reverse DNS delegations in ip6.int and ip6.arpa
12. Registration requirements
12.1. Updating registration details
12.2. Registering contact persons
Section 1: Background
------------------------------------------------------------------------
1. Introduction
----------------
These guidelines are developed within the APNIC community and are
consistent with the goals and policies applicable to IPv6 address space
management. They are intended to assist organizations requesting IPv6
address space only.
Nothing in these guidelines should be considered to replace or modify
any of the specific policies defined in other APNIC documents.
2. Scope
---------
This document applies to the management of global unicast IPv6 public
address space in the Asia Pacific region.
This document does not apply to IPv4, multicast, or unique local IPv6
unicast addresses, or Autonomous System Numbers. It should be read in
conjunction with other APNIC documents, particularly APNIC-089: IPv6
address allocation and assignment policy.
http://www.apnic.net/policy/ipv6-address-policy
3. Additional guidance
-----------------------
These guidelines are not intended to be exhaustive. Additional guidance
and examples are available from the help information available for each
APNIC request form and in FAQs and other information on the APNIC web
site:
- Resource guides
http://www.apnic.net/publications/media-library/documents
- APNIC FAQs
http://www.apnic.net/faq
- RFC 3596 DNS Extensions to Support IP Version 6
http://www.apnic.net/external-pages/rfcs/ietf-rfc-3596
- RFC 6177 IPv6 Address Assignment to End Sites
http://www.apnic.net/external-pages/rfcs/ietf-rfc-6177
4. Goals of address space management
-------------------------------------
In this document, all reference to the goals of address space management
refer to the goals described in the IPv6 address allocation and
assignment policy, namely:
- uniqueness;
- registration;
- aggregation;
- conservation;
- fairness; and
- minimized overhead.
5. Application of guidelines
-----------------------------
This document is primarily intended to guide ISPs when making
assignments to their customers or requesting address space from APNIC.
The issues discussed in this document reflect many of the considerations
used by APNIC in evaluating requests for initial allocations and
subsequent allocations.
It is intended that NIRs will either adopt these, or similar, guidelines
for their own members.
Section 2: General guidelines
------------------------------------------------------------------------
6. Definitions
---------------
Terms not defined in this document have the meaning given to them in the APNIC
Definition Document and Policy Document.
https://www.apnic.net/about-apnic/corporate-documents/documents/corporate/definitions/
https://www.apnic.net/community/policy/resources
7. Sparse Delegation Framework
-------------------------------
APNIC delegates blocks of IPv6 address space to resource holders
according to a "sparse delegation" algorithm. This delegation
process is designed to maximize the growth potential for each
delegation by maximizing the distance between them.
The following illustration shows the order in which a sequence of
16 delegations would be made in an available free pool using
APNIC's sparse delegation algorithm.
Sparse Delegation Sequence
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | | | | | | | 2 | | | | | | |
| | | 3 | | | | | | 4 | | |
| 5 | | 6 | | 7 | | 8 |
9 10 11 12 13 14 15 16
The sparse delegation algorithm used, selects the starting address
for each new delegation by calculating the mid-point between the
next two start addresses that are furthest apart in the free pool.
The algorithm works from the beginning address of the free pool to
the end address before returning to the first available slot at the
beginning of the pool.
The effect is to successively sub-divide each remaining free block
in two, the addresses after that point being used for the new
delegation and the preceding addresses being left available for
subsequent delegation.
In accordance with APNIC's IPv6 address allocation and assignment
policy, where possible, subsequent delegations to the same resource
holder are made from an adjacent address block by growing the
delegation into the free space remaining, unless disaggregated
ranges are requested for multiple discrete networks.
7.1. Avoiding Fragmentation
While the free space between sparse delegations is initially
very large, the size of available blocks reduces as more
sub-divisions occur. To minimize this effect, APNIC manages
its central pool by making similar sized delegations from a
number of sub-pools, with large delegations made from one
pool, small delegations made from another, and so on.
In this way, the high frequency of smaller delegations will
not cause sub-divisions of free space available to large
address block holders, as they are taken from different
sub-pools.
For more information about the resource ranges managed by
APNIC see:
http://www.apnic.net/resources
8. Allocations to LIRs
-----------------------
APNIC will allocate IPv6 address space to a network with global or local
connectivity, provided the network meets the criteria stated in "IPv6
address allocation and assignment policy".
The following networks are examples of the types of organizations that
most commonly apply for an IPv6 allocation from APNIC.
This list is not intended to be exhaustive:
- An organization providing IPv6 connectivity to the global
Internet.
- An organization providing IPv6 connectivity to end sites.
- An organization providing IPv6 access to shared facilities,
storage, computing, or other services.
- A large organization providing IPv6 connectivity to its own group
or subsidiaries.
8.1. Initial allocation criteria
To qualify for an initial allocation of IPv6 address space, an
organization must meet the criteria stated in section 5.2.1 of
"IPv6 address allocation and assignment policy". Under d) in
section 5.2.1, an organization can choose from one of the two
alternative criteria:
1. Have a plan for making at least 200 assignments to other
organizations within two years, OR
2. Be an existing LIR with IPv4 allocations from APNIC, or
from an NIR, which will make IPv6 assignments or
sub-allocations to other organizations and announce the
allocations in the inter-domain routing system within two
years
These two alternative criteria are explained in sections
8.1.1. and 8.1.2. below.
8.1.1. A plan for 200 assignments
An organization must provide a plan to make at least
200 assignments within two years. However, APNIC
regards the existence of the plan as a demonstration
of the LIR's readiness to commence IPv6 services and
does not assess the feasibility of the plan.
For example:
An LIR with at least 200 customers currently using
IPv4 address space can meet the initial allocation
criteria of 200 assignments if it plans to provide
them with IPv6 connectivity service within two years.
IPv4 sub-allocations made by an LIR to downstream ISPs
can be used to justify the corresponding amount of /56
assignments.
For example:
If a CATV provider has 4,000 IP static connection
customers in IPv4 and 5% of the customers (200
customers) are expected to subscribe to IPv6 services,
then this provider will meet the initial allocation
criteria of 200 assignments. (A /56 can be assigned to
end sites using either static or dynamic addressing).
If an LIR assigns a single static IP address in IPv4,
the ISP can assign up to a /48 in IPv6. The LIR may
also assign a smaller prefix in accordance with
recommendations in RFC 6177.
8.1.2. LIRs with existing IPv4 allocations from APNIC or an
NIR
To qualify under this criterion, an organization must:
- Document an existing IPv4 allocation made to it by
APNIC, or an NIR
- Commit to making IPv6 assignments and/or
sub-allocations
- Agree to announce the IPv6 allocation in the routing
table within two years
Note: Historical IP ranges do not meet the criteria of
being "an existing IPv4 allocation from APNIC, or an
NIR". Historical IP ranges are defined in Section 2.2
of: Policies for historical Internet resources in the
APNIC Whois Database.
http://www.apnic.net/policy/historical-resource-policies
8.1.3. Initial allocations larger than /32
LIRs can use existing IPv4 customers and IPv4 network
infrastructure to justify an initial allocation larger
than a /32 by providing documentation on the number of
their existing IPv4 users as well as the extent of
their IPv4 network infrastructure.
The HD ratio is used to determine the appropriate size
of the IPv6 allocation based on IPv4 customer and
infrastructure assignments. For more information,
refer to section 5.2.3 of the "IPv6 address allocation
and assignment policy".
http://www.apnic.net/policy/ipv6-address-policy
LIRs are likely to be eligible for an initial
allocation if they meet both of the following
conditions:
- They have received an IPv4 allocation as an LIR, or
meet the criteria to receive an IPv4 allocation; and
- They plan to transfer the existing IPv4
infrastructure or customers partly, or wholly, to
IPv6 in two years.
LIRs are still requested to provide information on how
many /56s they expect to assign within the first two
years.
8.1.4. Expanding allocations received before August 2004
Organizations that received an initial allocation of
IPv6 can take advantage of the August 2004 policy
permitting initial allocations larger than /32.
To expand the initial allocation size without needing
to meet subsequent allocation criteria, the LIR must
have received its initial allocation before 16 August
2004 and must meet the initial allocation criteria
described in Section 5. of the "IPv6 address
allocation and assignment policy".
http://www.apnic.net/policy/ipv6-address-policy
For more information, see: prop-021: Expansion of the
initial allocation space for existing IPv6 address
space holders.
http://www.apnic.net/policy/proposals/prop-021
8.1.5. Supporting documentation
The APNIC IPv6 Allocation Request Form gives LIRs the
opportunity to include additional documentation to
support the request for an initial IPv6 allocation.
Examples of the types of information an LIR can
include in the "Additional information" section of the
form to support the request are:
- network diagrams
- approximate deployment dates
- a brief description of IPv6 deployment method (use
of IPv6 tunneling, dual stack, etc.)
- service plans (web hosting, access service, etc.)
- network equipment information to demonstrate that
the LIR has a plan to implement IPv6-ready
infrastructure; and
- IPv4 infrastructure and/or customer information if
the LIR chooses the option of using existing IPv4
infrastructure to justify the request (see Section
8.1.2.).
When requesting an initial allocation from APNIC,
network equipment information such as the vendor and
model name of an LIR's equipment, is not mandatory;
however, if an LIR requests a large pool of address
space for CATV or ADSL operations, APNIC may ask for
information on the network's equipment.
8.2. Subsequent allocation criteria
8.2.1. Prior allocations to be used first
An LIR is not eligible to receive subsequent
allocations until its current assignments reach a HD
ratio of 0.94 based on /56 assignments.
8.2.2. Special circumstances
An LIR may request an exception to the HD 0.94 rule
when:
- It has a demonstrated need for an assignment that is
larger than the amount of remaining space,
- It is announcing its existing IPv6 allocation and
can demonstrate a need or requirement to build
discrete networks,
- It requires the additional allocation for technical
reasons such as for IPv4 to IPv6 transitional
technologies, or
- It can demonstrate other reasons accepted by APNIC
as valid circumstance, or in accord with applicable
policies.
9. Portable assignment criteria
--------------------------------
Organizations with a previously delegated IPv4 assignment from APNIC are
eligible for an appropriately sized IPv6 block under Section 5.1 of the
IPv6 address allocation and assignment policy.
Organizations are also able to demonstrate a need for direct assignment
of IPv6 address blocks under the following conditions.
- Multihoming assignment
- Internet Exchange assignment
- Critical Infrastructure assignment
- Provider Independent assignment
9.1. Initial assignments
APNIC will allocate a minimum of a /48 to organizations that
meet the following criteria.
9.1.1. Multihoming assignment
1. To be eligible for an IPv6 assignment under this
policy, an organization needs to be, or plan to be,
receiving fulltime connectivity from more than one
ISP, and
2. have one or more of its routing prefixes announced
by at least two ISPs.
9.1.2. Internet Exchange assignment
1. An Internet Exchange Point (IX or IXP) is a layer 1
and layer 2-network structure that interconnects
three or more Autonomous Systems (AS) for the
purpose of Internet traffic interchange.
2. Addresses delegated under this policy must be used
exclusively to connect participant devices to the
Exchange Point.
9.1.3. Critical Infrastructure assignment
1. Critical infrastructure assignments are available
only to the actual operators of network
infrastructure that perform the functions
described in the policy.
2. Examples of Critical Infrastructure networks are
listed at 5.9.3 of the IPv6 address allocation and
assignment policy.
3. The maximum assignment made under these terms is
/32 per operator.
9.1.4. Provider Independent assignment
Direct assignment of IPv6 addresses is possible where
an organization can demonstrate other reasons accepted
by APNIC as valid circumstance, or in accord with
applicable policies.
For example, organizations that can demonstrate;
1. the network is statically addressed and of a size
or complexity that make renumbering operationally
impractical, together with evidence that dynamic or
multiple addressing options are either not
available from the relevant ISP or are unsuitable;
or
2. that any future renumbering of the relevant network
could potentially interfere with services of a
critical medical or civic nature, or
3. other reasons accepted by APNIC as valid
circumstance, or in accord with applicable
policies.
Note: A larger address block may be assigned according
to demonstrated need. Only one IPv6 address block is
to be assigned to an organization upon an initial
request; subnets of this block may be assigned by the
organization to its different sites if needed.
9.2. Subsequent assignments
Eligibility for subsequent Provider Independent assignments
under Section 5.9.4 of the IPv6 address allocation and
assignment policy is subject to the following conditions:
- An address block larger than /48 may be assigned if;
1. the network address plan demonstrates that the need is
above a /48 0.94 HD-ratio, or
2. the network plan is for multiple discrete networks. That
is, the organization can demonstrate a need or
requirement to build discrete networks, and
3. the organization can demonstrate the use of the previous
assignment generated the minimum possible number of
global routing announcements and the maximum aggregation
of that block, and
4. how the subsequent assignment would be managed to
minimize the growth of the global IPv6 routing table.
10. Delegations by LIRs
-----------------------
10.1. LIR assignments to end sites
An LIR can assign a /64 to /48 to an end site customer
network based on their requirements.
The following guidelines may be useful:
- /64 where it is known that only one subnet is required.
- /56 for small sites where it is expected only a few subnets
will be required within the next two years. Subscribers can
receive a /56 when connecting through on-demand or
always-on connections such as small office and home office
enterprises.
- /48 for larger sites, or if an end site is expected to grow
into a large network.
An LIR must submit a second opinion request to APNIC if it
plans to assign more than a /48 to a single end site (see
Section 10.1.2 below).
http://www.apnic.net/second-opinion
10.1.1. Second opinion request
Currently, the global Internet community considers a
/48 assignment to be sufficient address space for an
end site.
Therefore, when an end site requires an assignment
larger than /48, or it requires additional /48
assignments after the initial assignment, the LIR must
first submit a second opinion request.
http://www.apnic.net/second-opinion
10.1.2. Supporting documentation
The APNIC Second Opinion Request Form gives LIRs the
opportunity to include additional documentation to
support the request for an assignment to an end site
that is larger than a /48.
Examples of the types of information an LIR can
include in the Additional information section of the
form to support the request are:
- Network diagram of an end site
- Network equipment information
- Full details to justify multiple /48 assignments to
an end site (for example, the number of clients (PCs
or other network equipment), or other information
which justify multiple /48 assignments)
10.2. Sub-allocations by LIRs
LIRs do not need to submit a second opinion request before
making sub-allocations to downstream ISPs (please see Section
8.2 above). However, APNIC encourages LIRs to contact APNIC
hostmasters for advice if LIRs are unsure how much address
space to sub-allocate.
11. Reverse DNS delegation
--------------------------
LIRs should maintain reverse DNS delegations for their customers'
networks. If a network is not specifically associated with an LIR then
the reverse DNS delegation should be maintained by APNIC. In both IPv4
and IPv6 networks, it is the LIR's responsibility to delegate or to
maintain PTR records for its customers' networks.
The size of a reverse DNS delegation by an LIR to an end site will
usually be a /48, which is the recommended minimum assignment to an end
site specified in RFC 6177. However, it is possible to delegate a prefix
longer than /48. Some organizations may delegate such a prefix in their
internal network.
11.1. Reverse DNS delegations in ip6.int and ip6.arpa
As specified in RFC 3596, reverse DNS delegations in the
ip6.int tree have been deprecated, and APNIC has now removed
all ip6.int reverse delegations from the APNIC Whois
Database.
For more information, see: Reverse DNS delegations resource
guide
http://www.apnic.net/dns
12. Registration requirements
-----------------------------
LIRs are responsible for promptly and accurately registering their
allocations, sub-allocations, and assignments in the APNIC Whois
Database, as follows:
- All allocations and sub-allocations must be registered.
- Assignments for networks equal to or larger than /48 must be
registered.
- Registration of assignments smaller than /48 is optional and may
be registered at the discretion of the LIR and the network
administrator.
When an LIR makes a sub-allocation to a downstream ISP, the LIR is
responsible for ensuring that assignments from the sub-allocated range
are registered in the database; however, the LIR may delegate the
responsibility to the downstream ISP.
If an LIR registers an assignment smaller than a /48, it will be counted
as a utilized /48 when assessing existing address utilization for future
IPv6 allocation requests.
Note: Privacy of customer assignments (prop-007-v001) was implemented in
2004. APNIC policy no longer requires the registration of assignments
and sub-allocations to be publicly available. The registration of
customer assignments is still required, but will be 'hidden' by default.
12.1. Updating registration details
LIRs must update the APNIC Whois Database when any of the
registration information changes. This is the responsibility
of the LIR concerned, but may be formally delegated to the end
user as a condition of the original assignment.
12.2. Registering contact persons
Administrative and technical contact persons must be
registered. In addition, it is mandatory to register an
Incident Report Team (IRT) object for each allocation and
assignment record in the APNIC Whois Database.
The registered administrative contact (admin-c) must be
someone who is physically located at the site of the network,
subject to the following exceptions:
- For residential networks or users, the network's technical
contact may be registered as admin-c.
- For networks in exceptional circumstances that make it
impractical to maintain an on-site administrative contact,
an off-site person may be registered as the admin-c.
The technical contact (tech-c) need not be physically located
at the site of the network, but must be a person who is
responsible for the day-to-day operation of the network.