apnic-127-v006-draft

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) 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 organizations requesting resources will generally be expected to adopt; and
other information that may assist organizations 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 organizations to request address space, 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 RFC720 and represented simply in fig.1.

Distribution Hierarchy

[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 also 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 Members and customers under the guidance of APNIC and in accordance with the relevant policies and principals described in this document.

Top

2.0. Definitions

The following terms and definitions are used in APNIC documents.

2.1. Internet Registry (IR)

An Internet Registry (IR) is an organization that is responsible for distributing IP address space to its Members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.

Internet Registries include:

APNIC and other Regional Internet Registries (RIRs)
National Internet Registries (NIRs)
Local Internet Registries (LIRs).

2.1.1. Regional Internet Registry (RIR)

Regional Internet Registries (RIRs) are established and authorized by their respective regional communities, and recognized by the IANA to serve and represent large geographical regions. Their primary role is to manage, distribute, and register public Internet address space within their respective region. There are five RIRs: AFRINIC, APNIC, ARIN, LACNIC, and the RIPE NCC.

2.1.2. National Internet Registry (NIR)

National Internet Registries (NIRs) are established and authorized by their respective regional communities, and recognized by RIRs to delegate address space to their Members or constituents, which are generally LIRs organized at a national level. NIRs are expected to apply their policies and procedures fairly and equitably to all Members of their constituency.

The policies in this document apply to NIRs; however, this document does not describe the entire roles and responsibilities of NIRs with respect to their formal relationship with APNIC. Such roles and responsibilities may be described in other documents and agreements including;

2.1.3. Local Internet Registry (LIR)

A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides.

LIRs are generally Internet Service Providers (ISPs), and may assign address space to their own network infrastructure and to users of their network services. An LIR’s customers may be other “downstream” ISPs, which further assign address space to their own customers.

2.2. Address space

In this document, address space means public unicast IP address ranges, which include IP version 4 (IPv4) and IP version 6 (IPv6).

2.2.1. Delegated address space

APNIC “delegates” addresses to its account holders. These delegations can be for use on the organization’s own infrastructure (an “assignment”) or for subsequent delegation by the organization to its customers (an “allocation”).

2.2.2. Allocated address space

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

2.2.3. Assigned address space

Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned.

2.3. 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.3.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.4. Multihomed

Multihoming is a way of connecting an organization’s network to the public Internet through more than one AS.

2.5. Internet resources

Internet resources are public IPv4 and IPv6 address numbers, Autonomous System Numbers, and reverse DNS delegations.

2.5.1. Current resources

Current resources are Internet resources registered by APNIC under explicit policies and agreements.

2.5.2. Historical resources

Historical resources are Internet resources registered under early registry policies without formal agreements and include:

Registrations transferred to APNIC as part of the AUNIC to APNIC migration
- Some historical resource registrations have been inherited by APNIC from the former AUNIC address registry.
- A list of resources transferred to APNIC as part of the migration is available on the APNIC website at:
  http://www.apnic.net/aunic
Registrations transferred as part of the Early Registration Transfer (ERX) project
- Most historical registrations were initially made by the global registries that predated ARIN, such as DDN-NIC, SRI-NIC, and InterNIC. ARIN inherited these registrations automatically when it was established. Historical registrations made to organizations in the APNIC region were transferred to APNIC during 2003 and 2004 as part of the RIRs’ Early Registration Transfer (ERX) project.
- A list of resources transferred to APNIC as part of the ERX project is available at: http://www.apnic.net/erx
Historical APNIC resources
- Historical APNIC resources were delegated to organizations by APNIC prior to the introduction of a Membership structure. These resources have always been registered in the APNIC Whois Database, but if the resource holder did not become an APNIC Member at any time after the introduction of the Membership structure, the resources were not made subject to current APNIC policies.

2.6. Internet Exchange Point (IXP)

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.7. Usage rate

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

2.8. 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.8.1. HD-Ratio

The HD-Ratio is a way of measuring the efficiency of address assignment [RFC3194]. 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.9. End site

An end site is defined as an end-user (subscriber) who has a business relationship with a service provider that involves:

that service provider assigning address space to the end-user
that service provider providing transit service for the end-user to other sites
that service provider carrying the end-user’s traffic
that service provider advertising an aggregate prefix route that contains the end-user’s assignment

2.10. 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.11. 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.12. 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.

2.12.1. Counterpart RIR

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

2.12.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.12.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.

Top

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.

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 is able to 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 Members and customers 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. Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available.

If the organization does not indicate a choice, or it 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 route 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. No guarantee of 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.1.8. Conflict of goals

The goals described above will often conflict with each other, or with the needs of individual IRs or end-users. All IRs evaluating requests for address space must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.

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.

In IPv6 address policy, the goal of aggregation is considered to be the most important.

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 Members, must monitor any changes and communicate any policy implications.

This section describes the factors in the current operating environment that have 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 organization. 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 Members 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 Members and the broader Internet community as a whole, in the common interest of those communities.

In implementing policies, APNIC and its Members rely on an implicit trust that delegated responsibilities are carried out in good faith. Specifically, APNIC must trust that the information gathered from Members 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 organization’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 organizations and individuals 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 Members 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. Organizations seeking address space from multiple IRs

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

In certain circumstances (for example, where an organization is multihomed), strong technical reasons may justify an organization 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.

Top

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. Organizations 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 requesting organizations are making a good-faith effort at meeting the criteria under which they qualified for, or were granted an allocation or assignment.

Licenses to organizations 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 a requesting organization 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 Member’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.2.1. Recovery of unused historical resources

A significant amount of historical resources registered in the APNIC Whois Database are not announced to the global routing table.

To recover these globally un-routed resources and place them back in the free pool for re-delegation, APNIC will contact networks responsible for historical address space in the APNIC region that has not been globally routed since 1 January 1998. To recover un-routed historical AS numbers, APNIC will contact networks responsible for resources not globally used for a reasonable period of time.

Top

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, assignment window, and second opinion policies to their own members 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.2. LIR address space management

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

5.2.1. Assignment window for LIRs

APNIC and NIRs shall apply an assignment window mechanism to help LIRs understand and comply with APNIC policies and the address management goals.

The assignment window indicates the maximum number of addresses an LIR may delegate to an end-user without first seeking a “second opinion”. If an LIR wishes to make a delegation that exceeds its delegation window, the LIR must first submit a second opinion request.

LIRs start with a delegation window of zero, meaning all proposed delegations must first be approved.

APNIC, or the relevant NIR, will regularly assess the proficiency of LIR staff in making delegations and seeking second opinions and will review the size of the assignment window accordingly. As the LIR staff become more proficient, the size of their assignment window may be raised.

The maximum IPv4 assignment window given to any LIR will be a /19 (8,192 addresses).

If an LIR’s staff appears to become less proficient (for example, due to the training of new staff or other relevant circumstances) then that LIR’s assignment window may be temporarily reduced.

5.2.2. 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, organizations 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.3. 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.
Delegations are subject to the LIR’s assignment window. Requests for delegations, which exceed the LIR’s assignment window, must first be referred to APNIC for second opinion approval.
The downstream customer is not permitted to further allocate the address space.

5.2.3.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.4. Policies for LIR IPv6 allocation and assignment

5.2.4.1. LIR-to-ISP allocation

There is no specific policy for an organization (LIR) to allocate address space to subordinate ISPs. Each LIR organization 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.4.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 exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified.

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 9.2.1 and for the purposes of measuring utilization as defined in this document.

5.2.4.3. Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level.

Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.

5.2.4.4. Assignment to operator’s infrastructure

An organization (ISP/LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.

5.3. Registration requirements

5.3.1. Requirements for IPv4 addresses

IRs are responsible for promptly and accurately registering their address space use with APNIC as follows:

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 must be registered.
Delegations made to networks of a /30 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.1.1. Updating registration details

IRs must update their registration records 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.

5.3.2. Registration requirements for IPv6 addresses

When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future).

Information is registered in units of assigned /48 networks. When more than a /48 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an RIR/NIR database.

RIR/NIRs will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time.

IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.

Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organization does not indicate a choice, or it 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.

5.3.3. Registration requirements for AS Numbers

All ASNs assigned must be publicly registered in the APNIC, or relevant NIR, Whois database. APNIC, or the relevant NIR, will create the aut-num object.

All attributes of the aut-num object must be properly registered in accordance with the APNIC or NIR whois database documentation. Without limiting these general requirements, Section 5.3.3.1 and Section 5.3.3.2. describe particular requirements for ASN registration.

5.3.3.1. Registering routing policy

APNIC recommends that the routing policy of the AS is registered for each ASN assigned.

5.3.3.2. Updating registration details

Organizations responsible for ASNs should update the aut-num object in the appropriate database if any of the registration information changes.

5.3.4. 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. Members 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 Member 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 organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, 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 taken into account when any organization holding Historical IPv4 addresses requests more IPv4 from APNIC.

5.5.2. Protecting Historical 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 or Non-Member account holder.

5.5.3. Updating Historical 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 APNIC Member or Non-Member account.

Historical resource holders with a current APNIC account have access to MyAPNIC, which allows organizations 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

All requests for address space must be supported by documentation describing:

The network infrastructure of the organization making the request,
Any address space currently held by that organization (including Historical address space),
Previous assignments made by that organization (including assignments made from Historical address allocations), and
The intended use for the address space requested.

In addition to this general requirement, more specific documentation may also be requested, as outlined below.

5.6.1. Documentation

To properly evaluate requests, IRs must carefully examine all relevant documentation relating to the networks in question. This documentation may include:

Network engineering plans
Subnetting plans
Descriptions of network topology
Descriptions of network routing plans
Equipment invoices and purchase orders
Other relevant documents

All documentation should conform to a consistent standard and any estimates and predictions that are documented must be realistic and justifiable.

5.6.2. 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 Members 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 Members 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.3. 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 5.7.2.1 or Section 5.2.7.2 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 Members only.

New Members wishing to receive experimental allocations may join at the Associate Member level. Their request for an experimental allocation will not be subject to the “IP resource application fee”.

Top

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, 27 May 2014, each APNIC account holder became eligible to receive additional delegations up to a maximum of /22 address space from the APNIC non-103/8 Recovered IPv4 address pool.

Note: Resources may not always be available from the recovered (non-103/8) address pool. APNIC has created a waiting list for those IPv4 requests that cannot be fulfilled. These requests are fulfilled in order of request, as space becomes available.

To receive delegations from either of these pools, they must demonstrate their eligibility by meeting the criteria specified below.

6.1.1. Additional allocation rounds

Recovered 103/8 address space returned to APNIC will be added to the 103/8 IPv4 address pool. Recovered non-103/8 address space or addresses allocated to APNIC from the ‘IANA Recovered IPv4 Pool’ will be added to the non-103/8 IPv4 address pool.

If address space in this pool becomes sufficient to delegate a further /22 to each APNIC account holder, additional delegation rounds will be announced.

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, and
Have complied with applicable policies in managing all address space previously delegated to it (including Historical delegations).

6.2.2. IPv4 for multihoming

An organization is eligible to receive an IPv4 delegation if:

it is currently multihomed, or
it is currently using at least a /24 from its upstream provider and intends to be multihomed, or
it intends to be multihomed, and advertise the prefixes within 6 months

Organizations 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) are eligible to receive a delegation from APNIC to be used exclusively to connect the IXP participant devices to the Exchange Point.

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

Top

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 space it has remaining.

Top

8.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 organizations 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 Members
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 transfers made under this policy.

8.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.

8.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.

8.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.

8.1.3. Conditions on recipient of the transfer

The recipient entity 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.

8.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.

8.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.

8.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 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.

8.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 organization holds an account. This means:

For transfers to an APNIC recipient, the conditions defined in Section 8.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.

8.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 Member, 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.

8.3.1. Transfer procedure

All transfers of Historical Internet resources to current APNIC Member 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 entity 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

8.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.

8.4. Mergers & acquisitions

APNIC will process and record the transfer of IPv4 resources as the result of merger or acquisition.

Addresses delegated from the 103/8 free pool cannot be transferred for a minimum of five years after the original delegation.

8.4.1. Updating registration details

If an organization 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 name changes, then the organization must provide relevant legal documentation supporting the name change.

8.4.2. Effect on membership agreement

If an organization changes 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 organization becomes a subsidiary of another entity, and the infrastructures of the respective entities remain fully independent, then the membership agreement may continue.

8.4.3. Consequences for allocations

Following a change in ownership, 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 organization that is effectively subsumed.

When assessing the status of IPv4 delegations, 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 delegations to be invalid and will require that they be returned.

Top

Part 3: IPv6 Policy

9.0. IPv6 allocations

9.1. Minimum IPv6 allocation

The minimum allocation size for IPv6 address space is /32.

Organizations that meet the initial allocation criteria are eligible to receive the minimum allocation. Larger initial allocations may be justified if:

The organization provides comprehensive documentation of planned IPv6 infrastructure which would require a larger allocation; or
The organization provides comprehensive documentation of all of the following:
- its existing IPv4 infrastructure and customer base,
- its intention to provide its existing IPv4 services via IPv6, and
- 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.

9.2. Initial IPv6 allocations

9.2.1. Account holders with existing IPv4 space

Subject to Section 9.1., existing IPv4 networks may be considered in determining the initial IPv6 allocation size. APNIC applies a minimum size for IPv6 allocations to facilitate prefix-based filtering.

APNIC Members 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, a Member that has received an IPv4 IXP assignment will be eligible to receive an IPv6 IXP assignment.

The size of the IPv6 delegation for Members that meet this criteria will be based on the following:

A Member that has an IPv4 allocation is eligible for a /32 IPv6 address block.
A Member that has an IPv4 assignment is eligible for a /48 IPv6 address block.

If an APNIC Member wishes to receive an initial allocation or assignment larger than the sizes described above, the Member will need to apply under the alternative criteria described in Section 9.2.2. and Section 10.1. below.

9.2.2. Account holders without existing IPv4 space

To qualify for an initial allocation of IPv6 address space, an organization must:

Be an LIR
Not be an end site
Plan, within two years, to provide IPv6 connectivity to other organizations/end-users to which it will make assignments.

The allocation size, in case an address block bigger than the default one (as indicated in 9.2.1.) is requested, will be based on the umber of users, the extent of the organization’s infrastructure, the hierarchical and geographical structuring of the organization, 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.

9.3. Subsequent IPv6 allocations

Organizations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.

9.3.1. Existing IPv6 address space holders

Organizations 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 inSection 9.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 organization. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in this document.

9.3.2. Applied HD-Ratio

Subsequent allocation will be provided when an organization (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.

9.3.3. Alternative allocation criteria

Alternatively, a subsequent allocation may be provided where an organization (ISP/LIR) can demonstrate a valid reason for requiring the subsequent allocation. For guidelines on what will be considered a valid technical or other reason, see “APNIC guidelines for IPv6 allocation and assignment requests“.

9.3.4. Size of subsequent allocation

When an organization 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 organization 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 organization’s infrastructure, the hierarchical and geographical structuring of the organization, the segmentation of infrastructure for security and the planned longevity of the allocation).

Top

10.0. IPv6 assignments

10.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

10.1.1. IPv6 for multihoming

An organization 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.

10.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 operator.

10.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.

10.1.4. Provider Independent IPv6 assignment

Requests for Provider Independent assignments must include a detailed plan of intended usage of the proposed address block over at least the 12 months following the allocation.

10.1.4.1. Initial assignment

Organizations are eligible for an IPv6 Provider Independent delegation if they are able to demonstrate a valid reason that an assignment from their ISP, or LIR, is not suitable.

For guidelines on what will be considered a valid technical or other reason, see “APNIC guidelines for IPv6 allocation and assignment requests“.

The minimum assignment made under this policy is a /48. Larger blocks may be delegated in circumstances outlined in “APNIC guidelines for IPv6 allocation and assignment requests“.

10.1.4.2. Subsequent assignment

Subsequent Provider Independent assignments may be delegated to organizations that are able to demonstrate

why an additional portable assignment is required and why an assignment from an ISP or other LIR cannot be used for this purpose;
that the use of the initial provider independent delegation generated the minimum possible number of global routing announcements and the maximum aggregation of that block; and,
how the subsequent assignment will be managed to minimize the growth of the global IPv6 routing table.

Top

11.0. Transfer of IPv6 resources

APNIC will only recognize the transfer or IPv6 addresses as the result of Merger & Acquisition activity. The following conditions and consequences apply.

11.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.

11.2. Effect on membership agreement

If an LIR changes 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.

11.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.

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.

Top

Part 4: ASN Policy

12.0. ASN assignments

12.1. Evaluation of eligibility

An organization is eligible for an ASN assignment if:

it is currently multihomed, or
it holds previously-allocated provider independent address space and intends to multihome in the future.

An organization will also be eligible if it can demonstrate that it 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).

12.2. Requesting an ASN

Organizations may request an ASN from either APNIC or their relevant NIR.

The requesting organization may request an ASN for use in its own network, or for the purposes of providing the ASN to one of its customers, subject to the terms of Sections 12.3. and 12.4. below.

12.3. Using ASN for own network

Assignments to organizations that will use the ASN in their own network are subject to the following additional terms:

The requesting organization is responsible for maintaining the registration described in Section 5.3.3.
The requesting organization is entitled to continue using the ASN, even if they change network peers or service providers.

12.4. Providing ASN to customer

Assignments to organizations that will provide the ASN to one of its customers are subject to the following additional terms:

The customer that will actually use the ASN must meet the criteria in Section 12.0.
The requesting organization is responsible for maintaining the registration described in Section 5.3.3. on behalf of the customer.
If the customer ceases to receive connectivity from the requesting organization it must return the ASN. The requesting organization is expected to enter into an agreement with the customer to this effect.
Any ASNs returned to the requesting organization must then be returned to APNIC or the relevant NIR.

12.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.

Top

13.0. ASN Transfers

Autonomous System Numbers 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.

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

13.1. Transfers of ASNs between APNIC account holders

APNIC will process and record ASN transfer requests between current APNIC account holders subject to the following conditions.

13.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

13.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.

13.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.

13.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.

13.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.

13.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 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.

13.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 organization 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.3. Mergers & acquisitions

APNIC will recognize the transfer of ASNs as the result of merger or acquisition.

13.3.1. Updating registration details

13.3.2. Effect on membership agreement

13.3.3. Consequences for allocations

Following a change in ownership, 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.

When assessing the status of ASN assignments, APNIC requires full disclosure of all resources held by all of the entities in question. If full disclosure is not made, then APNIC will consider any delegations to be invalid and will require that they be returned.

Top

Appendix A: 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 organization 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

APNIC Document identity

Table of Contents

Part 1: Policy Environment

1.0. Introduction

1.1. Scope

1.1.1. Additional guidelines and policies

1.1.2. Private address space

1.2. Hierarchy of resource distribution

2.0. Definitions

2.1. Internet Registry (IR)

2.1.1. Regional Internet Registry (RIR)

2.1.2. National Internet Registry (NIR)

2.1.3. Local Internet Registry (LIR)

2.2. Address space

2.2.1. Delegated address space

2.2.2. Allocated address space

2.2.3. Assigned address space

2.3. Autonomous System (AS)

2.3.1. Autonomous System Number (ASN)

2.4. Multihomed

2.5. Internet resources

2.5.1. Current resources

2.5.2. Historical resources

2.6. Internet Exchange Point (IXP)

2.7. Usage rate

2.8. Utilization

2.8.1. HD-Ratio

2.9. End site

2.10. aut-num object

2.11. Routing policy

2.12. Transfers

2.12.1. Counterpart RIR

2.12.2. Source

2.12.3. Recipient

3.0. Policy framework

3.1. Goals of resource management

3.1.1. Uniqueness

3.1.2. Registration

3.1.3. Aggregation

3.1.4. No guarantee of contiguous delegations

3.1.5. Conservation

3.1.6. Fairness

3.1.7. Minimized Overhead

3.1.8. Conflict of goals

3.2. Policy Environment

3.2.1. Routability

3.2.2. Internet growth rates

3.2.3. Collective responsibility

3.2.4. Impartiality

3.2.5. Varying levels of expertise

3.2.6. Address ownership

3.2.7. Address stockpiling

3.2.8. Reservations not supported

3.2.9. Evaluations to be based on best practice

3.2.10. Minimum practical delegation

3.2.11. Slow start mechanism

3.2.11.1. Exceptions to slow start

3.3. Organizations seeking address space from multiple IRs

4.0. Resource License

4.1. License Renewal

4.1.1. Review

4.1.2. Validity of delegations

4.2. Closure and recovery

4.2.1. Recovery of unused historical resources

5.0. Resource Management

5.1. How APNIC manages address space

5.1.1. Reservation for future uses

5.1.2. Sparse allocation framework

5.1.3. IPv4 addresses returned to APNIC

5.2. LIR address space management

5.2.1. Assignment window for LIRs

5.2.2. IPv4 address usage estimates

5.2.3. IPv4 Delegations to downstream IRs

5.2.3.1. Effect of delegation to downstream IRs on upstream LIR’s usage rate

5.2.4. Policies for LIR IPv6 allocation and assignment

5.2.4.1. LIR-to-ISP allocation

5.2.4.2. Assignment address space size

5.2.4.3. Assignment of multiple /48s to a single end site

5.2.4.4. Assignment to operator’s infrastructure

5.3. Registration requirements