wdiff apnic-resource-policies.txt apnic-resource-policies-draftv15.txt

-----------------------------------------------------------------------------------------
APNIC Document identity

Title: APNIC Internet Number Resource Policies
Short title: apnic-resource-policies
Document ref: APNIC-127
Version: 014 015
Date of original publication: 05 March 2015
Date of this version: 07 May 2024 xx February 2025
Review scheduled: n/a
Obsoletes: apnic-127-v013 apnic-127-v014
Status: Active Draft
Comments: Implements prop-155 prop-154 and prop-156
-------------------------------------------------------------------------------------------
Table of Contents

Part 1: Policy Environment
1.0. Introduction
1.1. Scope
1.2. Hierarchy of resource distribution
2.0. Definitions
2.1. Address space
2.2. Autonomous System (AS)
2.3. Multihomed
2.4. Usage rate
2.5. Utilization
2.6. End-site
2.7. End-user
2.8. aut-num object
2.9. Routing policy
2.10. Transfers
2.11. Multiple Discrete Networks
3.0. Policy framework
3.1. Goals of resource management
3.2. Policy Environment
3.3. Applicants seeking address space from multiple IRs
4.0. Resource License
4.1. License Renewal
4.2. Closure and recovery
4.3. Claiming and re-delegating historical resources
5.0. Resource Management
5.1. How APNIC manages address space
5.2. LIR address space management
5.3. Registration requirements
5.4. Reverse lookup
5.5. Managing Historical resources
5.6. General requirements for requests
5.7. Experimental allocations policy

Part 2: IPv4 Policy
6.0. Initial IPv4 delegations
6.1. Minimum and maximum IPv4 delegations
6.2. IPv4 request criteria
6.2.1. IPv4 for LIRs
6.2.2. IPv4 for multihoming
6.2.3. IPv4 for critical infrastructure
6.2.4. IPv4 for Internet Exchange Points
7.0. Subsequent IPv4 delegations
7.1. Prior delegations to be used first
7.2. Special circumstances - large delegations

Part 3: IPv6 Policy
8.0. IPv6 allocations
8.1. Minimum IPv6 allocation
8.2. Initial IPv6 allocations
8.2.1. Account holders with existing IPv4 space
8.2.2. Account holders without existing IPv4 space
8.3. Subsequent IPv6 allocations
8.3.1. Existing IPv6 address resource holders
8.3.2. Applied HD-Ratio
8.3.3. Alternative allocation criteria
8.3.4. Size of subsequent allocation
9.0. IPv6 assignments
9.1. Criteria for IPv6 Assignments
9.1.1. IPv6 for multihoming
9.1.2. IPv6 critical infrastructure
9.1.3. IPv6 for Internet Exchange Points
9.1.4. Provider Independent IPv6 assignment

Part 4: ASN Policy
10.0. ASN assignments
10.1. Evaluation of eligibility
10.2. Requesting an ASN
10.3. Using ASN for own network
10.4. Providing ASN to customer
10.5. Two-byte only and four-byte AS Numbers
10.6. Route Origin Authorisation (ROA)
10.7. AS-SET

Part 5: Transfer Policy
11.0. IPv4 Transfers
11.1. IPv4 transfers within the APNIC region
11.1.1. Conditions on the space to be transferred
11.1.2. Conditions on source of the transfer
11.1.3. Conditions on recipient of the transfer
11.2. Inter-RIR IPv4 address transfers
11.2.1. Conditions on the space to be transferred
11.2.2. Conditions on the source of the transfer
11.2.3. Conditions on the recipient of the transfer
11.3. Transfer of Historical Internet resources
11.3.1. Transfer procedure
11.3.2. Policies applicable to transferred Historical resources

12.0. ASN Transfers
12.1. Transfers of ASNs between APNIC resource holders
12.1.1. Conditions on resource
12.1.2. Conditions on source of the transfer
12.1.3. Conditions on recipient of the transfer
12.2. Inter-RIR ASN transfers
12.2.1. Conditions on the space to be transferred
12.2.2. Conditions on the source of the transfer
12.2.3. Conditions on the recipient of the transfer

13.0. IPv6 Transfers
13.1. Provider Independent (PI) IPv6 assignment

14.0. Mergers & Acquisitions
14.1. Updating registration details
14.2. Effect on membership agreement
14.3. Consequences for allocations

15.

Part 6: Temporary Assignment Policy
15.1 Introduction
15.2 Assignments for Temporary Purposes
15.3 Temporary Assignments
15.4 Registration
15.5 Limitations
15.6 Account holders
15.7 Return of Resources
15.8 Unavailability of IP Resources

Part 7: Appendix A:
16.0. HD-Ratio

Part 1: Policy Environment

1.0. Introduction The Asia Pacific Network Information Centre (APNIC) is the Regional Internet Registry (RIR) for the
Asia Pacific. It is responsible for the regional distribution of public Internet address space and related resources,
including Internet Protocol version 4 (IPv4) address space, Internet Protocol version 6 (IPv6) address space, and
Autonomous System Numbers (ASNs). APNIC also coordinates the development and implementation of policies to manage those
resources.

This document outlines the overall principals and goals of Internet number resource distribution. It also details
specific policies for the distribution and management of these resources in the Asia Pacific region.

The policies and definitions described in this document were developed by the Internet community of the Asia Pacific
region through a consensus process facilitated by APNIC. The policies are to be implemented by APNIC, by National
Internet Registries (NIRs), and by Local Internet Registries
(LIRs) Registries(LIRs) throughout the region.

1.1. Scope This document describes policies for the responsible management of global Internet number resources in the
Asia Pacific region. Specifically, this document focuses on policies relating to:
* The delegation of Internet Protocol version 4 (IPv4) address space.
* The allocation and assignment of Internet Protocol version 6 (IPv6) address space.
* The assignment of Autonomous System Numbers (ASNs).

1.1.1. Additional guidelines and policies This document should be read in conjunction with other APNIC documents,
policies, and guidelines; including those dealing with membership and fees, as these documents may provide additional
operational guidance, or may impose additional requirements on resource holders.

In addition to the eligibility criteria described in this document, APNIC may publish other information relating to
Internet number resources, including:
* further descriptions of evaluation procedures.
* summaries of the best current practices that account holders requesting resources will generally be expected to adopt;
and
* other information that may assist account holders to request resources.

This document does not provide specific details of request evaluation by APNIC, or of expectations relating to specific
technologies. Such details are dependent on technological advances and may change frequently. Therefore, to assist
account holders to request resources, APNIC publishes separate guideline documents relating to specific technologies or
techniques as required.

These guidelines are developed within the APNIC community and will be consistent with the goals and policies described
in this document.

1.1.2. Private address space This document does not describe specific addressing policies related to multicast or
private address space. The use of private address space may be appropriate for addressing networks where there are no
technical requirements for the use of public address space. In general, private address space should be used for
networks not directly connected to the Internet.

1.2. Hierarchy of resource distribution IP addresses and ASNs are distributed in accordance with the hierarchical
structure initially described in RFC7020 and represented simply as this diagram.

+--------+ | IANA |
+--------+ |
+-----------+-----------+-----------+-----------+ | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ | ARIN | |RIPE NCC| | APNIC | | LACNIC | |
AfriNIC|
+--------+ +--------+ +--------+ +--------+ +--------+ |
+--------------+-------------+ | |
+------+ | | NIR | | National Internet
+------+ | Registries | |
+------+--+------+ | | | | | Local Internet
+------+ | | +------+ Registries | LIR | | | | LIR |
+------+ | | +------+ | | | |
+-----+ | | +-----+-----+ | | | | | |
+------+ | +------+ | +------+ | Internet Service | ISP | | | ISP | | | ISP | |
Providers
+------+ | +------+ | +------+ | | | | | | |
+----+ +----+ +----+ +----+ +----+ +----+ End-users | EU | | EU | | EU | | EU | | EU | |
EU |
+----+ +----+ +----+ +----+ +----+ +----+

[Figure 1: Diagram of distribution hierarchy]

In this hierarchy, IANA allocates address space to APNIC, to be redistributed throughout the Asia Pacific region. APNIC
allocates address space to Internet Registries (IRs) and delegates to them the authority to make assignments and
allocations. In some cases, APNIC assigns address space to end users. National and Local IRs allocate and assign
address space to their account holders under the guidance of APNIC and in accordance with the relevant policies and
principals described in this document.

2.0. Definitions Terms not defined in this document have the meaning given to them in the APNIC Definition Document.

https://www.apnic.net/about-apnic/corporate-documents/documents/corporate/definitions/

2.1. Address space Address space refers to public unicast IP address ranges such as IP version 4 (IPv4) and IP version
6 (IPv6).

2.1.1. Delegated address space APNIC "delegates" addresses to its account holders. These delegations can be for use on
their own infrastructure (an "assignment") or for subsequent delegation by the requestors to its customers
(an "allocation").

2.1.2. Allocated address space Allocated address space is address space that is distributed to IRs or other account
holders for the purpose of subsequent distribution by them.

2.1.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for
exclusive use within the Internet infrastructure they operate.

2.2. Autonomous System (AS) An Autonomous System (AS) is a connected group of one or more IP prefixes run by one or more
network operators under a single and clearly defined routing policy.

2.2.1. Autonomous System Number (ASN) An Autonomous System Number (ASN) is a unique two- or four-byte number associated
with an AS. The ASN is used as an identifier to allow the AS to exchange dynamic routing information with other
Autonomous Systems.

2.3. Multihomed Multihoming is a way of connecting an autonomous network to the public Internet through more than one
AS.

2.4. Usage rate Usage rate is the rate at which the LIR made delegations from relevant past address space, including
Historical delegations.

2.5. Utilization Utilization is a measure of IPv6 address usage where "utilization" is only measured in terms of the
bits to the left of the /56 boundary. In other words, utilization refers to the delegation of /56s to end sites, and
not the number of addresses assigned within individual /56s at those end sites.

2.5.1. HD-Ratio The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an adaptation
of the H-Ratio originally defined in [RFC1715] and is expressed as follows:

Log (number of allocated objects) HD = -------------------------------------------------------------
Log (maximum number of allocatable objects)

where (in the case of this document) the objects are IPv6 site addresses (/56s) assigned from an IPv6 prefix of a given
size.

2.6. End-site An end site is defined as the location of an end-user who has a business or legal relationship
(same relationship(same or
associated entities) with a service provider that involves:
* that service provider assigning address space to the end-user location
* that service provider providing transit service for the end-user location to other sites
* that service provider carrying the end-user's location traffic
* that service provider advertising an aggregate prefix route that contains the end-user's location assignment

2.7. End-user Service subscriber or customer of an LIR.

2.8. aut-num object An aut-num object is an object in the Whois database used to register ASN assignment details. For
the purposes of this document, aut-num object also refers to the ASN registration objects in NIR databases.

2.9. Routing policy The routing policy of an AS is a description of how network prefixes are exchanged between that AS
and other Autonomous Systems.

2.10. Transfers Resource transfers involve the re-allocation of current address blocks (or ASNs), or the re-allocation
of historical resources claimed and transferred to an APNIC account holder.

2.10.1. Counterpart RIR A counterpart RIR is the Regional Internet Registry that APNIC transfers resources to, or from,
in an inter-RIR transfer.

2.10.2. Source The source in a resource transfer is the organization which, prior to the transfer, is the legitimate
holder of the resources to be transferred. Where the source is in the APNIC region, the source must be a current APNIC
account holder, except in the case of an Historical resource transfer. Where the source is from another RIR region, it
must be that RIR's equivalent to the "Source" as defined here.

2.10.3. Recipient The recipient in a resource transfer is the organization which, after the transfer is completed, will
be the legitimate holder of the resources to be transferred. Where the recipient is in the APNIC region, the recipient
must be a current APNIC account holder. Where the recipient is from another RIR region, it must be that RIR's
equivalent to the "Recipient" as defined here.

2.11. Multiple Discrete Networks Where an organization demonstrates a compelling need, or requirement, to build discrete
networks due to regulatory, geographic, or operational reasons and these networks are advertised either internally, or
externally, the network may be defined by APNIC as being composed of discrete networks.

3.0. Policy framework IP address space and other number resources are public resources which must be managed in a
prudent manner with regards to the long-term interests of the Internet. Responsible management involves balancing a set
of sometimes competing goals. The following are the goals relevant to Internet number policy.

This document is intended to help IRs perform their role in consistent and equitable ways. IRs must maintain full
documentation of and transparency within the decision-making process.

3.1. Goals of resource management The goals described here were formulated by the Internet community and reflect the
mutual interest of all members of that community in ensuring that the Internet can function and grow to the maximum
extent possible.

It is APNIC's primary duty, as a custodian of a public resource, to ensure these goals are met within the Asia Pacific
region. APNIC does this by providing guidance and leadership in developing and implementing responsible policies and
practices.

It is the responsibility of every NIR and LIR to also ensure these goals are met within their respective regions and
communities.

3.1.1. Uniqueness Every assignment and allocation of address space must be guaranteed as globally unique. This is an
absolute requirement for ensuring that every public host on the Internet can be uniquely identified.

3.1.2. Registration All assignments and allocations made directly by APNIC to its account holders must be registered in
a publicly accessible database. This is necessary to ensure uniqueness and to provide information for Internet
troubleshooting at all levels, ranging from all RIRs and IRs to end-users.

It also reflects the expectation of the Internet community that custodians of these public resources should be
identifiable. The goal of registration should be applied within the context of reasonable privacy considerations and
applicable laws. Account holders that receive an allocation from APNIC can choose whether their customer assignment
registrations should be publicly available are not.

If the account holder does not indicate a choice, or chooses to hide its customer assignment registrations, then those
records will not be visible in the public Whois database. Whois queries on these records will return details of the
allocation.

3.1.3. Aggregation Address policies should seek to avoid fragmentation of address ranges. Wherever possible, address
space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is
necessary to permit the aggregation of routing information by network operators, and to limit the expansion of Internet
routing tables.

This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant
implications for both internal and external routing.

It is a condition of all delegations made under initial or subsequent LIR delegation criteria, that the address space is
aggregated by the LIR within a minimum number of routes announcements
(preferably announcements(preferably one).

LIRs must only delegate addresses to customers who will be using those addresses in relation to network connectivity
services provided by the LIR.

LIRs are expected to enter into agreements with their customers specifying that the end-user will hold the addresses
only for so long as the end-user remains a customer of that LIR. Such agreements should also be consistent with the
license under which the address space is being used by the LIR.

3.1.4. Contiguous delegations RIRs should apply practices that maximize the potential for subsequent allocations to be
made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.

APNIC will attempt to make any subsequent delegations contiguous with previous delegations but cannot guarantee that
this will be possible.

3.1.5. Conservation To maximize the lifetime of the available resource, address space must be distributed according to
actual need and for immediate use. Stockpiling address space and maintaining reservations are contrary to this goal.
Conservation also implies efficiency. Therefore, all users of address space should adopt techniques such as Variable
Length Subnet Masking (VLSM) and appropriate technologies that ensure the address space is not used wastefully.

Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful
practices.

Requests for address space should be supported by appropriate documentation and stockpiling of unused IPv6 addresses
should also be avoided.

3.1.6. Fairness All policies and practices relating to the use of public address space should apply fairly and equitably
to all existing and potential members of the Internet community, regardless of their location, nationality, size, or
any other factor.

3.1.7. Minimized Overhead It is desirable to minimize the overhead associated with obtaining address space. Overhead
includes the need to go back to RIRs for additional space too frequently. There is overhead associated with managing
address space that grows through a number of small successive incremental expansions rather than through fewer, but
larger, expansions.

3.2. Policy Environment Apart from the goals described above, other factors influence the APNIC policy environment.
These other factors include the expectations of the Internet community, current administrative structures, and
technological constraints.

The policy environment may change quickly or in unpredictable ways, so APNIC, on behalf of its account holders, must
monitor any changes and communicate any policy implications.

This section describes the factors in the current operating environment that has been most important in determining
current APNIC policies.

3.2.1. Routability There is no guarantee that any address allocation or assignment will be globally routable. The
routability of address space throughout the Internet can never be guaranteed by any single account holder. However, IRs
must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.

To reduce the number of globally advertised routes, network operators may implement route filtering policies based on
prefix length. As a result, small portable assignments are the most likely to suffer routability problems. Therefore,
APNIC policies encourage those seeking address space to request from upstream providers rather than from APNIC
directly.

The responsible management of ASNs is also necessary to help limit the expansion of global routing tables. Aggregating
contiguous IP address prefixes within single Autonomous Systems helps to minimize the number of routes announced to the
global Internet.

3.2.2. Internet growth rates Early strategies for distributing address space did not anticipate the rapid growth of the
Internet and the scaling problems that followed, affecting both the amount of address space available and routing.
Therefore, APNIC policies take account of past experience and seek to manage address space in a way that will maximize
future scaling of the Internet.

3.2.3. Collective responsibility APNIC shares with its account holders and their customers a collective responsibility
to ensure manageable and scalable Internet growth and to make decisions consistent with the goals described here.
Therefore, APNIC policies and procedures are developed by APNIC account holders and the broader Internet community as a
whole, in the common interest of those communities.

In implementing policies, APNIC and its account holders rely on an implicit trust that delegated responsibilities are
carried out in good faith. Specifically, APNIC must trust that the information gathered from account holders during the
request process is genuine and accurate.

3.2.4. Impartiality APNIC represents the interests of the Internet community in general and the Internet community of
the Asia Pacific region in particular. Therefore, APNIC must apply its policies fairly and equitably, without regard to
an account holder's size, geographic location, or any other factor.

3.2.5. Varying levels of expertise Different IRs and end-users have varying levels of experience and expertise. APNIC
policies allow for varying levels of assistance and monitoring, appropriate to ensure a consistent approach to address
space management throughout the Asia Pacific Internet community.

3.2.6. Address ownership The Internet community regards address space as a scarce, public resource that should only be
distributed according to demonstrated need. ISPs and other APNIC account holders that use address space are
considered "custodians" rather than "owners" of the resource. As address space becomes more scarce, address space
management policies may be adjusted by the community.

3.2.7. Address stockpiling Stockpiling addresses is harmful to the goals of conservation and fairness. APNIC policies
must prevent stockpiling and ensure efficient deployment of address space on the basis of immediate demonstrated
need.

3.2.8. Reservations not supported When an LIR wants to delegate address space for customers, it must use any address
space it currently holds. When evaluating address requests, reserved address space is not considered to be delegated.

3.2.9. Evaluations to be based on best practice APNIC should ensure that address space holders adopt current best
practice in the management of the resources they use. If appropriate technologies exist for improved management of
address space in particular situations, the community expects that those technologies should be used. APNIC consults
with its account holders and the broader Internet community to define and develop current best practice recommendations
relating to Internet addressing technologies and techniques.

3.2.10. Minimum practical delegation Because the goals of aggregation and conservation conflict, it is necessary to
apply a minimum practical size for address space delegation. This minimum size may be reviewed from time to time, as
technologies and administrative conditions evolve.

3.2.11. Slow start mechanism APNIC and NIRs apply a slow start mechanism to all new LIRs. The slow start is applied to
prevent delegations of large blocks of address space that may then remain substantially unused.

3.2.11.1. Exceptions to slow start In exceptional circumstances, an LIR may receive a greater initial delegation if it
can demonstrate that its immediate need for address space exceeds the standard slow start delegation. The documentation
required to justify an exception to the slow start may include (but is not limited to):
* Receipts for the purchase of equipment, Purchase Orders, or
* Signed project contracts indicating the immediate network requirements to be met by the LIR.

3.3. Applicants seeking address space from multiple IRs Applicants must obtain their address space from only one IR at a
time. Applicants requesting address space from any IR must declare all the address space they currently hold,
regardless of the source. Applicants making concurrent requests to more than one IR must declare the details of all
of those requests.

In certain circumstances (for example, where an applicant network is multihomed), strong technical reasons may justify
an applicant receiving address space from more than one source.

For the purposes of this section, a parent organization and its subsidiaries are considered to be a single organization.
Exceptions may arise in cases where the parts of the organization:
* Are separate legal entities,
* Maintain fully independent network infrastructures and are routed under different ASNs, or
* Can otherwise demonstrate a justified need to obtain address space from more than one IR.

4.0. Resource License It is contrary to the goals of this document and is not in the interests of the Internet community
as a whole, for Internet number resources to be considered freehold property.

Neither delegation nor registration confers ownership of resources. Account holders that use them are
considered "custodians" rather than "owners" of the resource and are not entitled to sell or otherwise transfer that
resource to other parties outside the provisions in this document.

Internet resources are regarded as public resources that should only be distributed according to demonstrated need. The
policies in this document are based upon the understanding that globally unique unicast address space is licensed for
use rather than owned.

4.1. License Renewal Specifically, APNIC will delegate Internet resources on a 'license' basis, with licenses subject to
renewal on a periodic basis (normally one year).

The granting of a license is subject to specific conditions as described in the APNIC membership agreements, service
agreements, and other relevant APNIC documents, at the start or renewal of the license.

IRs will generally renew licenses automatically, provided account holders are making a good-faith effort at meeting the
criteria under which they qualified for, or were granted an allocation or assignment. Licenses to account holders shall
be renewable on the following conditions:
* The original basis of the delegation remains valid, and
* That address space is properly registered at the time of renewal.

4.1.1. Review In those cases where an account holder is not using the address space as intended or is showing bad faith
in following through on the associated obligation, IRs reserve the right to not renew the license. However, individual
licenses shall only be subject to review if the relevant IR has reason to believe that the existing license terms are
no longer being complied with. IRs may implement their own procedures for the review of existing licenses as they see
fit.

When a license is renewed, the new license will be evaluated and governed subject to all policies and license conditions
effective at the time of renewal. These may differ from those in place at the time of the original delegation, provided
that a minimum notice period of one year is given of any substantial changes. Substantial changes to license conditions
are subject to the consensus of APNIC Members, in accordance with the APNIC Document Editorial Policy.

4.1.2. Validity of delegations A resource delegation is valid only while the original criteria on which it was made
remains valid. If a delegation becomes invalid, then the resource must be returned to the appropriate IR.

An allocation or assignment becomes invalid if it is:
* Made for a specific purpose that no longer exists, or
* Based on information that is later found to be false or incomplete.

4.2. Closure and recovery If an LIR holding APNIC address space ceases to provide Internet connectivity services, all of
its address space must be returned to APNIC. It is the responsibility of the LIR (or any liquidator or administrator
appointed to wind up the account holder's business) to advise all of its customers that address space will be returned
to APNIC, and that renumbering into new address space will be necessary. In the case that a new LIR takes over the
business or infrastructure of the closed LIR, the existing address space may be transferred to the new LIR, however
such a transfer is subject to re-examination by APNIC and may be treated as a new address request process.

4.3. Claiming and re-delegating historical resources Historical resources that are no longer published in the APNIC
Whois Database and are placed in reserved status because of EC resolution 2021-09 of 22 February 2021
(https://www.apnic.net/wp-content/uploads/2021/06/FINAL_merged_EC_meeting_minutes20210222_0304_public_final.pdf), can
be claimed by the custodians within 12 months of the date they were marked as reserved.

After 12 months, these resources will be placed in the free pool for re-delegation.

Any historical resources marked as reserved and/or reclaimed by APNIC due to account closures will lose their historical
status and become current resources for re-delegation.

5.0. Resource Management All NIRs and LIRs that receive address space from APNIC (either directly or indirectly) must
adopt delegation policies that are consistent with the policies described in this document.

NIRs and LIRs must ensure that address space for which they are responsible is only allocated or assigned subject to
agreements consistent with the license provisions in this document.

Also, NIRs must, wherever possible, apply slow start policies to their own account holders in a manner consistent with
the way APNIC applies such policies.

5.1. How APNIC manages address space

5.1.1. Reservation for future uses A /16 of IPv4 address space will be held in reserve for future uses, as yet
unforeseen. If the reserved /16 remains unused by the time the remaining available space has been delegated, the /16
will be returned to the APNIC pool for distribution under the policies described in this document.

5.1.2. Sparse allocation framework APNIC will document the sparse allocation algorithm framework used to select IPv6
address blocks for delegation, in document apnic-114: APNIC guidelines for IPv6 allocation and assignment requests.
This document is available at the following URL: http://www.apnic.net/ipv6-guidelines

5.1.3. IPv4 addresses returned to APNIC Any IPv4 resources received by APNIC will be placed into the APNIC IPv4 pool for
delegation under the policies described in this document. This placement applies to any IPv4 addresses APNIC receives
from IANA and/or holders of addresses in the APNIC Whois Database, subject to any future global policy for the
redistribution of addresses received by IANA from the RIRs.

5.1.4. Preventing the Use of Undelegated APNIC Address Space Undelegated APNIC Address Space (IPv4 or IPv6) should not
be publicly advertised by any Autonomous System. To prevent its use, APNIC will create RPKI ROAs with origin AS0
(AS zero) for all undelegated address space (marked as 'Available' and 'Reserved' in the
delegated-apnic-extended-latest stats file) for which it is the current administrator. While any current account holder
can create AS0 ROA for the resources they have under their account administration, only APNIC has the authority to
create AS0 ROAs for APNIC address space not yet delegated to an account holder. When APNIC delegates address space to
an account holder, APNIC will remove the prefix from the AS0 ROA.

5.2. LIR address space management LIRs may delegate address space to their customers subject to the following
provisions.

5.2.1. IPv4 address usage estimates Requests for delegations must be supported by usage estimates based on immediate and
projected future need. These requests must be accompanied by documentation that supports the estimates. The
estimates should be made for the following periods:
* Immediately,
* Within one year, and
* Within two years APNIC recommends that, as a general guideline, applicants should base their resource requests on the
assumption that 25% of the address space will be used immediately and 50% will be used within one year. The end-user
must provide documentation that supports its one-year usage estimate. If it is not possible for the end-user to
estimate confidently what the two-year usage rate will be, then APNIC or the NIR may make a delegation that will be
sufficient for the one-year needs only.

5.2.2. IPv4 Delegations to downstream IRs LIRs may delegate address space to their downstream customers, which are
operating networks, such as ISPs, subject to the following conditions:
* Delegations are non-portable and must be returned to the LIR if the downstream customer ceases to receive connectivity
from the LIR.
* The downstream customer is not permitted to further allocate the address space.

5.2.2.1. Effect of delegation to downstream IRs on upstream LIR's usage rate For the purposes of evaluating the LIR's
usage rate, address space delegated to downstream LIRs will be considered as "used". However, APNIC will give careful
consideration to the registration of delegations made by the downstream LIR to their customers and may request
supporting documentation as necessary.

5.2.3. Policies for LIR IPv6 allocation and assignment

5.2.3.1. LIR-to-ISP allocation There is no specific policy for an LIR to allocate address space to subordinate ISPs.
Each LIR may develop its own policy for subordinate ISPs to encourage optimum utilization of the total address block
allocated to the LIR. However, all /48 assignments to end sites are required to be registered either by the LIR or its
subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes
necessary.

5.2.3.2. Assignment address space size LIRs must make IPv6 assignments in accordance with the following provisions.
End-users are assigned an end site assignment from their LIR or ISP. The size of the assignment is a local decision for
the LIR or ISP to make, using a value of "n" x /64. RIRs/NIRs are not concerned about which address size an LIR/ISP
actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they do in
IPv4, except for the cases described in Section 8.2.1. and for the purposes of measuring utilization as defined in this
document.

5.2.3.3. Assignment of multiple /48s to a single end site Assignment larger than /48 (shorter prefix) or additional
assignments exceeding a total of /48 must be made based on address usage, or because of different routing requirements
exist for additional assignments. In case of a review or when making a request for a subsequent allocation, the LIR
must be able to present documentation justifying the need for assignments shorter than a /48 to a single end site.

5.3. Registration requirements

5.3.1. Requirements for Autonomous System Numbers (ASNs) and Addresses IRs are responsible for promptly and accurately
registering their ASN and address space use with APNIC as follows:
* All ASNs assigned must be publicly registered in the APNIC, or relevant NIR, Whois database, for which APNIC or NIR
will create the aut-num object.
* All the attributes of the aut-num object, must be registered in accordance with APNIC or NIR Whois database
documentation.
* All delegations from APNIC to the IR must be registered.
* All delegations to downstream IRs must be registered.
* Delegations made to networks greater than a /30 for IPv4 and /48 for IPv6 must be registered.
* Delegations made to networks of a /30 for IPv4 and /48 for IPv6 or less may be registered, at the discretion of the IR
and the network administrator.
* Delegations to hosts may be registered, at the discretion of the IR and the end-user. IRs can choose whether or not to
designate this information "public". Customer registration details that are not designated "public" will not be
generally available via the APNIC Whois database. The database record will instead direct specific Whois enquiries to
the IR concerned.

5.3.2. Updating registration details IRs must update their registration records and relevant objects when any of the
registration information changes. This is the responsibility of the IR concerned. However, this responsibility may be
formally assigned to the end-user as a condition of the original delegation. Further, APNIC recommends that the routing
policy of the AS is registered for each ASN assigned.

5.3.3. Registering Contact Persons Administrative and technical contact persons must be registered. 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 IR's technical contact may be registered as the 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. In
addition, it is mandatory to register an Incident Response Team (IRT) object for each resource record in the APNIC
Whois Database. Contact addresses listed in the IRT object (email, abuse-mailbox attributes) must be regularly
monitored and any abuse complaints sent to these contacts must be responded to promptly to resolve the complaints.
APNIC will validate IRT contacts periodically or every six (6) months to ensure they are accurate and contactable.
Account holders are required to complete these validation checks within fifteen (15) days of receiving the validation
check email from APNIC. If the IRT contacts fail the validation, APNIC will mark the IRT object invalid in the APNIC
Whois Database and follow up according to relevant policies and procedures. If validation still fails after thirty
(30) days, the account holder will have limited access to MyAPNIC until their IRT contacts are validated.

5.4. Reverse lookup

5.4.1. Responsibility to maintain IPv4 in-addr.arpa records LIRs should maintain in-addr.arpa resource records for their
customers' networks. If a network is not specifically associated with an LIR, then the in-addra.arpa records should be
maintained by either the appropriate NIR or APNIC.

5.4.2. IPv6 reverse lookup When an RIR/NIR delegates IPv6 address space to an account holder, it also delegates the
responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each account
holder should properly manage its reverse lookup zone. When making an address assignment, the account holder must
delegate to an assignee, upon request, the responsibility to manage the reverse lookup zone that corresponds to the
assigned address.

5.5. Managing Historical resources Historical resources were often delegated to organizations in a policy environment
quite different to those in use today. Historical resource holders should be aware of the current goals of Internet
resource management as outlined in this document. The following policies specifically apply to Historical resources.

5.5.1. Utilization of Historical IPv4 address space Utilization of Historical IPv4 address space is considered when any
organization holding Historical IPv4 addresses requests more IPv4 from APNIC.

5.5.2. Protecting Historical resource records in the APNIC Whois Database APNIC will protect all registrations of
Historical Internet resources with the APNIC-HM maintainer, a practice consistent with the management of current
resources. To ensure integrity of information, APNIC will not update historical information in the APNIC Whois Database
until the resource holder demonstrates the organization's right to the resources and enters a formal agreement with
APNIC either as a member account or Non-Member account.

5.5.3. Updating Historical resource registrations Detailed information on how to request an update to a historical
Internet resource registration is available on the historical resource page of the APNIC website.
http://www.apnic.net/services/manage-historical-resources Please note that resource holders will not be able to update
registration information if they fail to pay the fees associated with their member account or Non-Member account.
Historical resource holders with a current account have access to MyAPNIC, which allows account holders to manage their
resources and account information via a secure website.

5.5.4. Policies applicable to updated Historical resources Historical Internet resources that are updated under this
policy are subject to the registration requirements as specified above.

5.6. General requirements for requests In order to properly evaluate resource requests, APNIC must carefully examine all
relevant documentation relating to the networks in question. Such documentation may include network engineering plans,
sub-netting plans, descriptions of network topology, and descriptions of the network routing plans. Further, based on
request the following information may be requested such as equipment invoices and purchase orders, any address space
currently held by that applicant (including Historical address space), previous assignments made by that applicant
(including assignments made from Historical address allocations), and the intended use for the address space requested.
All documentation should conform to a consistent standard and any estimates and predictions that are documented must be
realistic and justifiable.

5.6.1. Security and confidentiality The documentation, which supports address space requests, involves information that
may be highly confidential to the commercial and infrastructure operations of all applicants and their customers.
Therefore, APNIC will reflect the trust implicit in its position by:

* applying and enforcing systems, practices, and procedures that protect the confidential information of its applicants
and their customers, and
* ensuring the employment of all staff, or agents, is based upon an explicit condition of confidentiality regarding such
information. APNIC provides for authorization and verification mechanisms within the APNIC Whois Database. It is the
responsibility of each IR, or end-user, to apply these mechanisms.

5.6.2. Equitable processing of requests APNIC will only process requests that have been completely and properly
documented. If the documentation contains errors or omissions, APNIC will advise the applicant as soon as possible.
APNIC may also request the applicant to provide further information or clarify relevant issues that are not clear in
the initial request. Once the errors and omissions are rectified, or the additional questions answered, APNIC will deal
with the request in the strict order in which it receives proper documentation. APNIC will make all reasonable efforts
to maintain a consistent and reliable level of service with respect to processing of requests and will maintain a
request tracking system for efficient request management. To provide fair treatment for all applicants, APNIC will not,
under any circumstance, provide any special treatment or make exceptions to the standard order of request processing.

5.7. Experimental allocations policy This Section describes the APNIC policies which apply to requests for Internet
resource allocations that are to be used for experimental purposes.

5.7.1. Introduction As the Internet continues to expand and evolve, there is an increased need for technologies and
practices to be refined and standardized. To achieve this, it is often necessary to experiment with proposed
technologies to evaluate their interaction with the installed base of the Internet. For a small proportion of these
experimental activities, it may be necessary to allocate or assign Internet resources on a temporary basis.

5.7.1.1. Scope and goal This section describes policies for the responsible management of global Internet resources in
the Asia Pacific region, specifically relating to the temporary allocation and assignment of Internet resources for
experimental purposes. The goal of this policy is to provide fair access to Internet resources for genuine researchers,
to encourage development of new technologies and refinement of standards.

5.7.2. Allocations for experimental purposes APNIC will allocate public Internet resources to be used for experimental
purposes. These experimental allocations are subject to the eligibility criteria, conditions, and restrictions
described below. An experiment is eligible for an allocation if it meets the criteria described in either Section
5.7.2.1 or Section 5.2.7.2 below. On 9 July 2022, APNIC reserved 59.191.232.0/21 IPv4 address space for experimental
allocations. This address space will be unreserved and put back in the general pool after five years for delegation to
account holders as per IPv4 policy in Section 6.0 below.

5.7.2.1. Publication of an experimental RFC Experiments are eligible for allocations if they are described in an RFC
designated by the IETF as "Experimental". The requestors must specifically refer to this RFC, describe
their participation in the experiment, and provide a summary of the experiment which details their requirement for
Internet resources.

5.7.2.2. Alternative publication approved by APNIC Experiments may be eligible for an allocation if they are described
in a document that is available free of charge and publicly accessible in a forum approved by APNIC. Under this
criterion, APNIC has the sole discretion to determine whether such an experiment is eligible. To do so, APNIC may
liaise with IETF working groups, other standards bodies, RIRs, or Internet experts to evaluate the status of the
document, the validity of the experiment it describes, and the Internet resource requirements of the experiment. The
requestors must specifically refer to the published document, describe their participation in the experiment, and
provide a summary of the experiment which details their requirement for Internet resources.

5.7.3. Experimental allocations

5.7.3.1. Public disclosure of experiment It is a condition for experimental allocations that all material details of the
experiments are published free of charge and without any constraints on their disclosure or use. The details to be
published include the objectives of the experiment, the practices, and any other relevant details. At the completion of
the experiment, the results must be published under the same terms. To this extent, the terms of APNIC's regular
non-disclosure provisions are specifically excluded from these requests. Although APNIC may consider requests for
certain aspects of a project to be subject to a non-disclosure agreement, it will not agree to any restrictions on the
public benefit to be gained from any experiments. APNIC may publish and maintain public archives of all experiments
which receive allocations under this policy.

5.7.3.2. Size of IP allocations In the case of experimental allocations of IP addresses, the allocation size will be
consistent with APNIC's standard minimum allocation size, unless the nature of the experiment specifically requires an
allocation of a different size.

5.7.3.3. APNIC input on proposed experiment During the request process, APNIC may comment on the objectives of the
experiment with regards to the requested amount of numbering resources. APNIC may also propose changes to the size of
the requested allocation. If the requestor does not agree with the proposed changes, then APNIC will seek advice from
the IETF, or another relevant standards body involved in publishing the experiment.

5.7.3.4. Duration of allocation licenses APNIC will make experimental allocations on a temporary license basis. Licenses
to use the resources will be valid for one year.

5.7.3.5. Extension of license At the end of the initial license period, the holder of the resources may apply to have
the license extended, to meet the objectives of the experiment, as publicly documented. It is intended that the
majority of the experiments to be considered under this policy will be concluded without extension of the original
license.

5.7.4. Registration All experimental allocations will be registered in the APNIC Whois Database. The registration
details will indicate the temporary nature of these allocations.

5.7.4.1. Restriction on commercial or undocumented uses APNIC may revoke an experimental allocation if the resources are
being used for commercial purposes or are being used for any activities not documented in the original request.

5.7.5. Fees for experimental allocations Experimental allocations are available to APNIC account holders only. New
applicants wishing to receive experimental allocation will need to become an APNIC account holder. If you are already a
member of APNIC, then you do not have to pay anything extra for an experimental allocation. Also, the experimental
allocation will not be counted in calculating the account holder's membership tier.

Part 2: IPv4 Policy

6.0. Initial IPv4 delegations

6.1. Minimum and maximum IPv4 delegations The current minimum delegation size for IPv4 is a /24 (256 addresses).

Since Thursday, 28 February 2019, each APNIC account holder is only eligible to receive IPv4 address delegations
totalling a maximum /23 from the APNIC 103/8 IPv4 address pool.

On Tuesday, 2 July 2019, the waiting list for non-103/8 resources was abolished and recovered non-103/8 resources will
be considered the same as 103/8 addresses in the remaining IPv4 pool for delegations according to the current policy.

Note: A waiting list will be created once APNIC runs out of all IPv4 addresses. Any requests received from the new
applicants for IPv4 resources will be put on this waiting list on a first come first request. APNIC will maintain one
IPv4 pool for all recovered as well as IANA delegated address space and this pool will be used to provide IPv4
resources to the waiting list requests.

To receive delegations from this pool, they must demonstrate their eligibility by meeting the criteria specified
below.

6.2. IPv4 request criteria To qualify for an IPv4 address delegation from APNIC, requestors must demonstrate their
eligibility under one of the following four criteria.
* IPv4 for LIRs
* IPv4 for multihoming
* IPv4 for critical infrastructure
* IPv4 for Internet Exchange Points

6.2.1. IPv4 for LIRs To be eligible for an initial IPv4 delegation, an LIR must:
* Have used a /24 from their upstream provider or demonstrate an immediate need for a /24,
* Have complied with applicable policies in managing all address space previously delegated to it (including Historical
delegations), and
* Demonstrate a detailed plan for use of at least a /23 within a year

6.2.2. IPv4 for multihoming An applicant is eligible to receive an IPv4 delegation if:
* currently multihomed, or
* currently using at least, a /24 from its upstream provider and intends to be multihomed, or
* intends to be multihomed, and advertise the prefixes within 6 months Applicants requesting a delegation under these
terms must demonstrate that they are able to use 25% of the requested addresses immediately and 50% within one
year.

6.2.3. IPv4 for critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific
region, are eligible to receive a delegation:
* Root domain name system (DNS) server
* Global top-level domain (gTLD) nameservers
* Country code TLD (ccTLDs) nameservers
* IANA
* Regional Internet Registry (RIRs), and
* National Internet Registry (NIRs) Delegations to critical infrastructure are available only to the actual operators of
the network infrastructure performing such functions. Registrar organizations that do not actually host the network
housing the registry infrastructure will not be eligible under this policy.

6.2.4. IPv4 for Internet Exchange Points
Internet Exchange Points (IXP) The minimum delegation size is /26 and the maximum is /22 IPv4 address.

New IXPs are eligible delegated a /26 IPv4 address by default.

IXPs can request a delegation of up to receive a /25 if they can demonstrate that they will have more than 60 peers on the IXP
fabric (peering LAN) in the next 12 months. IXPs can request a delegation from APNIC of up to a /23 or the current highest
delegation size if they can demonstrate that they will have more than 100 peers on the IXP fabric (peering LAN) in the
next 12 months. An IXP with a delegation less than /24 can request up to /23 IPv4, but only if 60% of the original
delegation has been used. The existing delegation must be returned by IXP within three months of the new delegation.

Existing Large IXPs that have previously used exclusively to connect their maximum delegation of /23 under the previous policy can request a
contiguous block (if available) of /22 if they have used 60% of their existing delegation. The existing delegation must
be returned by IXP within three months of the new delegation.

Any existing IXP participant devices that wants to start new POPs may request additional IPv4 addresses (which will be delegated in
accordance with the Exchange Point. above-mentioned criteria of /26 and /25) as long as the total delegation does not exceed /22.

Any IPv4 addresses delegated under this policy will not be announced in the global routing table (mistakes are exempted)
and must be used only for IXP peering; otherwise, APNIC will revoke the resources.

Global routability of the delegation outside this policy is left to the discretion of the IXP and its participants.

Any resources delegated under this policy are non-transferable.

7.0. Subsequent IPv4 delegations After receiving an initial LIR delegation, all subsequent delegations will depend on
the following:
* The LIR's verified usage rate (which is the rate at which the LIR made delegations from relevant past address space,
including Historical delegations)
* Their documented plans for address space, and
* Their degree of compliance with APNIC policies with respect to relevant past delegations. Based on these factors,
APNIC and NIRs will delegate address space to meet the LIR's estimated needs for a period up to one year up to the
maximum allowed delegation under Section 6.1. If APNIC or the NIR make a delegation based on a period of less than
one year, then they must inform the LIR of the length of the period and the reasons for selecting it.

7.1. Prior delegations to be used first An LIR is not eligible to receive a subsequent delegation from APNIC until its
current customer delegations account for at least eighty percent of the total address space it holds. This is referred
to as the "eighty percent rule".

7.2. Special circumstances - large delegations An LIR may request an exception to the eighty percent rule if it needs to
make a single delegation that is larger than the amount of pace it has remaining.

Part 3: IPv6 Policy

8.0. IPv6 allocations

8.1. Minimum IPv6 allocation The minimum allocation size for IPv6 address space is /32. Applicants that meet the initial
allocation criteria are eligible to receive the minimum allocation. Larger initial allocations may be justified if: 1.
The applicant provides comprehensive documentation of planned IPv6 infrastructure which would require a larger
allocation; or 2. The applicant 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
* its intention to move some of its existing IPv4 customers to IPv6 within two years. In either case, an allocation will
be made which fulfils the calculated address requirement, in accordance with the HD-Ratio based utilization policy.

8.2. Initial IPv6 allocations

8.2.1. Account holders with existing IPv4 space Subject to Section 8.1., existing IPv4 address space may be considered
in determining the initial IPv6 allocation size. APNIC applies a minimum size for IPv6 allocations to facilitate
prefix-based filtering. APNIC account holders that have been delegated an IPv4 address block from APNIC, but have no
IPv6 space, can qualify for an appropriately sized IPv6 block under the matching IPv6 policy. For example, an account
holder that has received an IPv4 IXP assignment will be eligible to receive an IPv6 IXP assignment. The size of the
IPv6 delegation for requestors that meet this criterion will be based on the following:
* An account holder that has an IPv4 allocation is eligible for a /32 IPv6 address block.
* An account holder that has an IPv4 assignment is eligible for a /48 IPv6 address block. If an APNIC account holder
wishes to receive an initial allocation or assignment larger than the sizes described above, the account holder will
need to apply under the alternative criteria described in Section 8.2.2. and Section 9.1 below.

8.2.2. Account holders without existing IPv4 space To qualify for an initial allocation of IPv6 address space, an
account holder must: 1. Be an LIR 2. Not be an end site 3. Plan, within two years, to provide IPv6 connectivity to
others/end-users to which it will make assignments. The allocation size, in case an address block bigger than the
default one (as indicated in Section 8.2.1.) is requested, will be based on the number of users, the extent of the
account holder's infrastructure, the hierarchical and geographical structuring of the networks, the
segmentation of infrastructure for security and the planned longevity of the allocation. 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.

8.3. Subsequent IPv6 allocations Account holders that hold an existing IPv6 allocation may receive a subsequent
allocation in accordance with the following policies.

8.3.1. Existing IPv6 address resource holders Resource holders that received /35 IPv6 allocation under the previous IPv6
address policy [RIRv6-Policies] are immediately entitled to have their allocation expanded to a /32 address block,
without providing justification, so long as they satisfy the criteria in Section 8.2.2. The /32 address block will
contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already
reserved by the RIR for a subsequent allocation to the account holder. Requests for additional space beyond the
minimum /32 size will be evaluated as discussed elsewhere in this document.

8.3.2. Applied HD-Ratio Subsequent allocation will be provided when an ISP/LIR satisfies the evaluation threshold of
past address utilization in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used
to determine the utilization thresholds that justify the allocation of additional address as described below. The
HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilization for justifying the allocation of
additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve
an acceptable utilization value for a given address block size.

8.3.3. Alternative allocation criteria Alternatively, a subsequent allocation may be provided where an 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

8.3.4. Size of subsequent allocation When an account holder has achieved an acceptable utilization for its allocated
address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address
space allocated to it. Where possible, except where separate disaggregated ranges are requested for multiple discrete
networks, 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 account holder needs more address space, it must provide documentation
justifying its new requirements. The allocation size will be based on the new needs (the number of users, the extent of
the infrastructure, the hierarchical and geographical structuring of the account holder's operations, the segmentation
of infrastructure for security and the planned longevity of the allocation).

9.0. IPv6 assignments APNIC account holders that have been delegated an IPv4 address block from APNIC, but have no IPv6
space, can qualify for an appropriately sized IPv6 block under the matching IPv6 policy. For example, an account holder
that has received an IPv4 IXP assignment will be eligible to receive an IPv6 IXP assignment.

9.1. Criteria for IPv6 Assignments To qualify for an IPv6 assignment from APNIC, requestors must demonstrate their
eligibility under one of the following four criteria.
* IPv6 for multihoming
* IPv6 for critical infrastructure
* IPv6 for Internet Exchange Points
* Provider Independent IPv6 assignment

9.1.1. IPv6 for multihoming An applicant is eligible to receive a portable assignment from APNIC if it is currently, or
plans to be, multihomed. The minimum assignment made under these terms is /48.

9.1.2. IPv6 critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific
region, are eligible to receive a portable assignment:
* Root domain name system (DNS) server;
* Global top-level domain (gTLD) nameservers;
* Country code TLD (ccTLDs) nameservers;
* IANA;
* Regional Internet Registry (RIRs); and
* National Internet Registry (NIRs). Assignments to critical infrastructure are available only to the actual operators
of the network infrastructure performing such functions. Registrar organizations which do not actually host the
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 account holder.

9.1.3. IPv6 for Internet Exchange Points Internet Exchange Points are eligible to receive a portable assignment from
APNIC to be used exclusively to connect the IXP participant devices to the Exchange Point. The minimum assignment made
under these terms is /48. Global routability of the portable assignment is left to the discretion of the IXP and its
participants.

9.1.4. Provider Independent (PI) IPv6 assignment Applicants who can commit to using and advertizing the IPv6 address
space within twelve (12) months from the date of their assignment are eligible for an IPv6 Provider Independent
delegation.

9.1.4.1. Initial assignment The initial IPv6 PI assignment to eligible applicants is /48.

9.1.4.2. Subsequent assignment For additional IPv6 PI address space requirements exceeding /48, account holders must
follow the Section 9.2, "Subsequent assignments," in APNIC guidelines for IPv6 allocation and assignment requests.

https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/ipv6-guidelines/#PI-subsequent

Subsequent IPv6 PI assignments requests will be evaluated based on the account holders demonstrated need and adherence
to IPv6 policies.

Part 4: ASN Policy

10.0. ASN assignments

10.1. Evaluation of eligibility An applicant is eligible for an ASN assignment if:
* the network is currently multihomed, or
* has the need to interconnect with other AS. An applicant will also be eligible if the requestor can demonstrate that
will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter). Requests for ASNs
under these criteria will be evaluated using the guidelines described in RFC1930 'Guidelines for the creation,
selection and registration of an Autonomous System' (AS).

10.2. Requesting an ASN Applicants may request an ASN from either APNIC or their relevant NIR. The applicant may request
an ASN for use in its own network, or for the purposes of providing the ASN to one of their customers, subject to the
terms of Sections 10.3. and Section 10.4. below.

10.3. Using ASN for own network Assignments to applicants that will use the ASN in their own network are subject to the
following additional terms: 1. The applicant is responsible for maintaining the registration described in Section
5.3.3. 2. The applicant is entitled to continue using the ASN, even if they change network peers or service providers.

10.4. Providing ASN to customer Assignments to account holders that will provide the ASN to one of its customers are
subject to the following additional terms: 1. The customer that will actually use the ASN must meet the criteria in
Section 10.0. 2. The requesting account holder is responsible for maintaining the registration described in Section
5.3.3. on behalf of their customer. 3. If the customer ceases to receive connectivity from the requesting account
holder it must return the ASN. The requesting account holder is expected to enter into an agreement with the customer
to this effect. 4. Any ASNs returned to the requesting account holder must then be returned to APNIC or the relevant
NIR. 5. Alternatively, the same ASN could be registered:
* via transfer to another APNIC member (upstream provider connecting that customer), or
* directly by the customer in cases when they become an APNIC/NIR member and receives
* that ASN via transfer.

10.5. Two-byte only and four-byte AS Numbers On 1 January 2010 APNIC ceased to make any distinction between two-byte
only AS Numbers and four-byte only AS numbers and operates the AS Number assignments from an undifferentiated four-byte
AS Number pool.

10.6. ROA/whois object with Private, Reserved and Unallocated (reserved/available) Origin ASN

The origin AS can only be from the IANA specified range and must not contain any IANA unallocated ASN and/or an ASN
from:

- 23456 # AS_TRANS RFC6793
- 64496-64511 # Reserved for use in docs and code RFC5398
- 64512-65534 # Reserved for Private Use RFC6996
- 65535 # Reserved RFC7300
- 65536-65551 # Reserved for use in docs and code RFC5398
- 65552-131071 # Reserved
- 4200000000-4294967294 # Reserved for Private Use RFC6996
- 4294967295 # Reserved RFC7300

APNIC account holders are not permitted from creating ROAs with the above-mentioned ASN, Any existing ROAs with these
ASN will not be automatically renewed and deleted after notifying the account holder.

AS0 (zero) is also a Reserved ASN (RFC7607) but will be exempted from this restriction as AS0 is reserved by the IANA
such that it may be used to identify non-routed networks (RFC6483 Sec 4).

If the Origin ASN has been marked as unallocated (reserved/available) or from the above-mentioned ASN list, APNIC will
notify the account holder to update the ROA with a valid ASN.

Same policy applies to corresponding ROAs for route/route6 whois objects.

10.7. AS-SET

An as-set (RFC 2622 Section 5.1) provides a way to document the relationship between ASes which can then be publicly
verified. RFC2622 further defines 2 categories for as-set which can be Hierarchical or Non Hierarchical. A hierarchical
set name is a sequence of set names and AS numbers separated by colons.

Non hierarchical as-set pose a security issue where any one can create an as-set without any authentication or
authorisation. Since many peering filters are based on as-set, creating a blank as-set or as-set with wrong members can
cause automated filters to apply empty prefix-filters to BGP session.

To prevent account holders from creating as-sets that already exist in other IRR databases, APNIC account holders are
only permitted to create hierarchical as-sets. At least one component of such a name must be an actual set name. All
the set name components of an hierarchical name has to be of the same type.

Any non hierarchical as-set can not be used as a parent to create a hierarchical as-set and this will not be allowed.

Part 5: Transfer Policy

11.0. IPv4 Transfers IPv4 addresses may be transferred in accordance with the following policies. APNIC does not
recognize transfers outside this policy and require organizations holding such transfers to return them to the
appropriate IR. The goal of the APNIC transfer policy is to help distribute IPv4 addresses from those who no longer
need the addresses, to those that need the addresses, but cannot obtain them from the free pool. APNIC recognizes there
will be situations where IPv4 resources may be transferred between:
* Current APNIC account holders
* Current APNIC account holders and organizations in other RIR regions
* Holders of Historical IPv4 addresses without an APNIC account to current APNIC account holders
* Organizations through a merger, acquisition, or takeover. Addresses delegated from the 103/8 free pool cannot be
transferred for a minimum of five years after the original delegation. During that time, if the reason for the
original request is no longer valid, the resources must be returned to APNIC as required in Section 4.0. Resource
License of this document. The policies in this document ensure that all transfers of IPv4 address space are
accurately reflected in the APNIC Whois Database. This ensures the integrity of the network and an accurate
description of the current state of address distribution. APNIC will maintain a public log of all number resource
(IPv4, IPv6, ASN) transfers, including unused (market) transfer, merger and acquisitions, and historical resource
transfer.

11.1. IPv4 transfers within the APNIC region APNIC will process and record IPv4 address transfer requests between
current APNIC account holders subject to the following conditions.

11.1.1. Conditions on the space to be transferred The minimum transfer size is a /24. The address block must be:
* In the range of addresses administered by APNIC
* Allocated or assigned to a current APNIC account holder
* The address block will be subject to all current APNIC policies from the time of transfer.
* Addresses delegated from the 103/8 free pool cannot be transferred for a minimum of five years after the original
delegation.

11.1.2. Conditions on source of the transfer The source entity must be the currently registered holder of the IPv4
address resources, and not be involved in any dispute as to the status of those resources.

11.1.3. Conditions on recipient of the transfer The recipient will be subject to current APNIC policies. Recipients that
do not already hold IPv4 resources must demonstrate a detailed plan for the use of the transferred resource within 24
months. Recipients that already hold IPv4 resources must:
* Demonstrate a detailed plan for the use of the transferred resource within 24 months,
* Show past usage rate, and
* Provide evidence of compliance with APNIC policies with respect to past delegations.

11.2. Inter-RIR IPv4 address transfers APNIC will process and record inter-RIR IPv4 address transfers only when the
counterpart RIR has an inter-RIR transfer policy that permits the transfer of address space between APNIC and its own
region. APNIC will process and record IPv4 address transfer requests between current APNIC account holders and
organizations in other RIR regions subject to the following conditions.

11.2.1. Conditions on the space to be transferred The minimum transfer size is a /24. The IPv4 address space to be
transferred should be under the management of the RIR at which the transfer source holds an account and the authentic
holder of the space should match with the source without any disputes. Some RIRs, including APNIC, have restrictions
against the transfer of certain address blocks. APNIC policy does not allow the transfer of addresses delegated from
the 103/8 free pool to be transferred for a minimum of five years after the original delegation.

11.2.2. Conditions on the source of the transfer The conditions on the source of the transfer will be defined by the RIR
where the source holds an account. This means:
* For transfers from an APNIC source, the source entity must be the currently registered holder of the IPv4 address
resources, and not be involved in any dispute as to the status of those resources.
* Where the source is in another region, the conditions on the source as defined in the counterpart RIR's transfer
policy at the time of the transfer will apply.

11.2.3. Conditions on the recipient of the transfer The conditions on the recipient of the transfer will be defined by
the RIR where the recipient holds an account. This means:
* For transfers to an APNIC recipient, the conditions defined in Section 11.1.3. will apply.
* Where the recipient is in another region, the conditions on the recipient as defined in the counterpart RIR's transfer
policy at the time of the transfer will apply.

11.3. Transfer of Historical Internet resources APNIC will process and record the transfer of Historical IPv4 resources
as defined in Section 2.5.2. If Historical resources are transferred to an APNIC account holder, there is the option to
make the transfer under the conditions described in this policy. Transfers of Internet resources to current APNIC
account holders are purely optional.

11.3.1. Transfer procedure All transfers of Historical Internet resources to current APNIC account holders made under
this policy are recognized and registered by APNIC. APNIC does not require any technical review or approval of the
resource's current use to approve the transfer. In addition, APNIC does not review any agreements between the parties
to a transfer and does not exert any control over the type of agreement between the parties. If the historical Internet
resources are not held under a current APNIC account, the recipient must verify they are the legitimate holder of the
Internet resources. For more information on transferring historical Internet resources, please see the transfer page of
the APNIC website. https://www.apnic.net/transfer

11.3.2. Policies applicable to transferred Historical resources All resources transferred under this policy are subject
to the provisions of all normal address management policies. In particular, future address requests from the account
holder must document the use of transferred resources as a part of their current resource holdings. If the historical
Internet resources are not held under a current APNIC account, the recipient entity must verify they are the legitimate
holder of the Internet resources.

12.0. ASN Transfers Autonomous System Numbers may be transferred in accordance with the following policies. APNIC does
not recognize transfers outside this policy and requires account holders holding such transfers to return them. APNIC
recognizes there will be situations where ASNs may be transferred between:
* Current APNIC account holders
* Current APNIC account holders and organizations in other RIR regions
* Organizations through a merger, acquisition, or takeover

12.1. Transfers of ASNs between APNIC resource holders APNIC will process and record ASN transfer requests between
current APNIC account holders subject to the following conditions.

12.1.1. Conditions on resource The ASN must be:
* In the range administered by APNIC
* Assigned to a current APNIC account holder
* The ASN will be subject to all current APNIC policies from the time of transfer

12.1.2. Conditions on source of the transfer The source entity must be the currently registered holder of the ASN, and
not be involved in any dispute as to the status of the resource.

12.1.3. Conditions on recipient of the transfer The recipient entity will be subject to current APNIC policies and must
meet the criteria for the assignment of an ASN.

12.2. Inter-RIR ASN transfers APNIC will recognize inter-RIR ASN transfers only when the counterpart RIR has an
inter-RIR transfer policy that permits the transfer of ASNs between APNIC and its own region. APNIC will process and
record ASN transfer requests between current APNIC account holders and organizations in other RIR regions subject to
the following conditions.

12.2.1. Conditions on the space to be transferred The ASN to be transferred should be under the management of the RIR at
which the transfer source holds an account and the authentic holder of the space should match with the source without
any disputes.

12.2.2. Conditions on the source of the transfer The conditions on the source of the transfer will be defined by the RIR
where the source organization holds an account. This means:
* For transfers from an APNIC source, the source entity must be the currently registered resource holder of the
resource, and not be involved in any dispute as to the status of those resources.
* Where the source is in another region, the conditions on the source as defined in the counterpart RIR's transfer
policy at the time of the transfer will apply.

12.2.3. Conditions on the recipient of the transfer The conditions on the recipient of the transfer will be defined by
the RIR where the recipient holds an account. This means:
* For transfers to an APNIC recipient, the recipient entity must be an APNIC account holder and must meet the criteria
for the assignment of an ASN. Following the transfer, the resources will be subject to current APNIC policies.
* Where the recipient is in another region, the conditions on the recipient as defined in the counterpart RIR's transfer
policy at the time of the transfer will apply.

13.0. IPv6 Transfers APNIC will only recognize the transfer of IPv6 addresses as the result of Merger & Acquisition
activity.

13.1 Provider Independent (PI) IPv6 assignment The IPv6 PI address space delegated under Section 9.1.4 will be
non-transferable. If this PI address space is not used or is no longer needed, it must be returned to APNIC.

14.0. Mergers & Acquisitions APNIC will process and record the transfer of ASNs, IPv6, and IPv4 resources as the result
of merger or acquisition. Addresses delegated from the 103/8 IPv4 free pool cannot be transferred for a minimum of five
years after the original delegation.

The following conditions and consequences apply: 14.1. Updating registration details If an LIR changes ownership (due to
a merger, sale, or takeover), then the new entity must register any changes to its network usage and contact personnel.
If the effect of the ownership change is that the LIR changes name, then the LIR must provide to APNIC relevant legal
documentation supporting the name change.

14.2. Effect on membership agreement If an LIR change ownership, then the new entity should advise APNIC of the change.
APNIC membership is not transferable from one entity to another; however, if the effect of the ownership change is that
the LIR becomes a subsidiary of another entity, and the infrastructures of the respective entities remain fully
independent, then the membership agreement may continue.

14.3. Consequences for allocations Following ownership change of an LIR, APNIC will review the status of any allocations
that are held by the new entity or entities, with regard to the practical effect on their infrastructures. If the
practical effect of ownership change is that the infrastructures are merged, then APNIC will not continue to make
separate allocations to both. This situation will invalidate the membership agreement of the LIR that is effectively
subsumed. When assessing the status of allocations, APNIC requires full disclosure of all address space held by all of
the entities in question. If full disclosure is not made, then APNIC will consider any allocations to be invalid and
will require that they be returned.

15.

Part 6: Temporary Assignment Policy

15.1 Introduction

Across the Asia-Pacific region, there are a large number of conferences that take place for the benefit of the wider
internet community, such as Network Operator Group meetings and other operational events. There may also be
requirements where a temporary assignment may be necessary where a long-term assignment exceeding 6 months may not be
feasible.

15.1.1 Scope and Goal

This section describes the policies for the temporary assignment of IPv4 address space, IPv6 address space, as well as
Autonomous System numbers for temporary short-term use periods not exceeding 6 months.

The goal of this policy is to provide a way for organisations to access resources on a temporary basis, for the benefit
of an organisation's members and the wider internet community as a whole.

15.2 Assignments for Temporary Purposes

APNIC will reserve a /21 IPv4 prefix as well as a /29 IPv6 prefix and 8 Autonomous System Numbers to allow for
assignments to be made under this policy. APNIC will then delegate IP resources to an organisation or body for
temporary purposes from this reserved pool. These purposes may include a conference, workshop, special interest group
meetings and other purposes as APNIC deems appropriate where a long-term assignment may not be feasible. An assignment
may be made if it is for one of the stated purposes below, or otherwise deemed a suitable purpose by APNIC. A temporary
assignment can be made if one of the criteria set out in 15.2.1 to 15.2.3 is met, or if APNIC makes a determination
under 15.2.4 in favour of the applicant.

Resources delegated under this policy are exempt from standard quarantine practices (see 15.7). The account holder
accepts that resources delegated under this policy may not be fully routable.

15.2.1 Conferences

Conferences that are held for the purposes of policy development, education, sharing of information and research as well
as professional networking. The applicant must provide a draft program no later than 6 weeks from the commencement of
the conference as well as justification for the assignment.

15.2.2 Workshops

Workshops which are held to discuss certain topics or key issues within the internet community. Under this criterion,
the applicant must demonstrate why a temporary assignment is required, by providing information on how the temporary
assignment will assist the discussion, such as technical demonstrations of certain issues being discussed.

15.2.3 Special Interest Group (SIG) meetings

SIG meetings that are held to discuss certain areas of interest within the internet community. If applying for a
temporary assignment for a SIG meeting, the applicant must demonstrate why an assignment is needed, by providing an
agenda and explaining how the assignment will assist in a technical capacity with the meeting's agenda.

15.2.4 Other Special Purposes

If the applicant is applying for a temporary assignment with justification that does not fall under one of the above
purposes, they may make a "Special Purpose" application to APNIC for such an assignment. APNIC will review all material
presented in support of the application and make a determination as to what size assignments are required, and the
timeframe for which they are to be assigned.

15.3 Temporary Assignments

15.3.1 Assignment Sizes

In most cases, no greater than a /24 IPv4 prefix, a /32 IPv6 prefix and a single AS Number will be provided unless the
applicant can demonstrate a need for greater assignments.

15.3.2 Credit for Assignment

When an assignment is made under this policy, the applicant must credit APNIC for the assignment.

15.3.3 Assignment Time Period

APNIC in its sole discretion based on justification provided and taking into consideration the amount of time required
to establish infrastructure for the event, will make a determination as to the time period for which an assignment will
be made. If the applicant deems this time period to not be sufficient, they may make a request to APNIC to extend the
assignment time period with justification as to why a longer period is required.

15.4 Registration

Any assignments made will be registered in the APNIC Whois Database. The details pertaining to the assignment will be
made available in the database.

15.5 The applicant must not use the assignment for any purpose which is commercial in nature. If a determination is made
that the usage is for a commercial purpose, then APNIC will have grounds to recover the assigned resources.

Examples of what is considered a commercial purpose or commercial in nature:
- Using the resources for a service which is intended to be sold for financial gain.
- A for-profit entity charging a fee to attend a conference, where the intent of the conference is to promote and/or
advertise proprietary services and systems.
- A private education provider requiring students to pay tuition fees which result in a financial benefit for the
provider.

Examples of what is not a commercial purpose or not regarded as commercial in nature:
- Training programs provided by a not-for-profit organisation whose purpose is to educate participants on networking
systems and protocols.
- Conferences held by Network Operator Groups where the overall purpose of the event is non-profit in nature.
- Special Interest Groups which hold meetings and technical workshops to discuss functions, systems and protocols that
are designed to benefit the community as a whole.

15.6 Temporary assignments can only be made to APNIC account holders. If an applicant is not an APNIC account holder,
they are permitted to nominate an existing account holder who can act on their behalf for the technical requirements
related to the temporary assignment otherwise they are able to become an account holder themself by becoming an
Associate member. Assignments made under this policy do not count towards a member's membership tier.

15.7 Return of Resources

Resources must be returned to APNIC before the end date of the temporary assignment. Once returned, they are exempt from
the normal quarantine processes for returned resources and are immediately available for further assignments.

15.8 Unavailability of IP Resources

If a member submits a request for resources however it is not possible to fulfill the request due to the unavailability
of resources for the requested period, the Secretariat may decline the request.

Part 7: Appendix A:

16.0. HD-Ratio The utilization threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6
prefix P, can be calculated as: T=2((56-P)*HD) Thus, the utilization threshold for an account holder requesting
subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD-Ratio. This
utilization refers to the allocation of /56s to end sites, and not the utilization of those /56s within those end
sites. It is an address allocation utilization ratio and not an address assignment utilization ratio. This document
adopts an HD-Ratio of 0.94 as the utilization threshold for IPv6 address space allocations. The following table
provides equivalent absolute and percentage address utilization figures for IPv6 prefixes, corresponding to an HD-Ratio
of 0.94.

P 56-P Total /56s Threshold Util %

56 0 1 1 100.0
55 1 2 2 95.9
54 2 4 4 92.0
53 3 8 7 88.3
52 4 16 14 84.7
51 5 32 26 81.2
50 6 64 50 77.9
49 7 128 96 74.7
48 8 256 184 71.7
47 9 512 352 68.8
46 10 1,024 676 66.0
45 11 2,048 1,296 63.3
44 12 4,096 2,487 60.7
43 13 8,192 4,771 58.2
42 14 16,384 9,153 55.9
41 15 32,768 17,560 53.6
40 16 65,536 33,689 51.4
39 17 131,072 64,634 49.3
38 18 262,144 124,002 47.3
37 19 524,288 237,901 45.4
36 20 1,048,576 456,419 43.5
35 21 2,097,152 875,653 41.8
34 22 4,194,304 1,679,965 40.1
33 23 8,388,608 3,223,061 38.4
32 24 16,777,216 6,183,533 36.9
31 25 33,554,432 11,863,283 35.4
30 26 67,108,864 22,760,044 33.9
29 27 134,217,728 43,665,787 32.5
28 28 268,435,456 83,774,045 31.2
27 29 536,870,912 160,722,871 29.9
26 30 1,073,741,824 308,351,367 28.7
25 31 2,147,483,648 591,580,804 27.5
24 32 4,294,967,296 1,134,964,479 26.4
23 33 8,589,934,592 2,177,461,403 25.3
22 34 17,179,869,184 4,177,521,189 24.3
21 35 34,359,738,368 8,014,692,369 23.3
20 36 68,719,476,736 15,376,413,635 22.4
19 37 137,438,953,472 29,500,083,768 21.5
18 38 274,877,906,944 56,596,743,751 20.6
17 39 549,755,813,888 108,582,451,102 19.8
16 40 1,099,511,627,776 208,318,498,661 18.9
15 41 2,199,023,255,552 399,664,922,315 18.2
14 42 4,398,046,511,104 766,768,439,460 17.4
13 43 8,796,093,022,208 1,471,066,903,609 16.7
12 44 17,592,186,044,416 2,822,283,395,519 16.0
11 45 35,184,372,088,832 5,414,630,391,777 15.4
10 46 70,368,744,177,664 10,388,121,308,479 14.8
9 47 140,737,488,355,328 19,929,904,076,845 14.2
8 48 281,474,976,710,656 38,236,083,765,023 13.6
7 49 562,949,953,421,312 73,357,006,438,603 13.0
6 50 1,125,899,906,842,620 140,737,488,355,328 12.5
5 51 2,251,799,813,685,250 270,008,845,646,446 12.0
4 52 4,503,599,627,370,500 518,019,595,058,136 11.5