APNIC Home

diff-apnic-127-v010

 apnic-resource-policies.txt   apnic-127-v011-draft.txt 
—————————————————————————————–
APNIC Document identity APNIC Document identity
Title: APNIC Internet Number Resource Policies Title: APNIC Internet Number Resource Policies
Short title: apnic-resource-policies
Short title: apnic-resource-policies Document ref: APNIC-127
Document ref: APNIC-127 Version: 011
Version: 010 Date of original publication: 05 March 2015
Date of original publication: 5 March 2015 Date of this version: XX August 2022
Date of this version: 6 December 2021 Review scheduled: n/a
Review scheduled: n/a Obsoletes: apnic-127-v010
Obsoletes: apnic-127-v009 Status: Draft
Status: Active Comments: Implements prop-142, 143, 144 and minor editorial changes
Comments: Implements prop-135, 136, 139, 140 ——————————————————————————————-
Table of Contents Table of Contents
Part 1: Policy Environment Part 1: Policy Environment
1.0. Introduction 1.0. Introduction
1.1. Scope 1.1. Scope
1.1.1. Additional guidelines and policies 1.2. Hierarchy of resource distribution
1.1.2. Private address space
1.2. Hierarchy of resource distribution
2.0. Definitions 2.0. Definitions
2.1. Internet Registry (IR) 2.1. Internet Registry (IR)
2.1.1. Regional Internet Registry (RIR) 2.2. Address space
2.1.2. National Internet Registry (NIR) 2.3. Autonomous System (AS)
2.1.3. Local Internet Registry (LIR) 2.4. Multihomed
2.2. Address space 2.5. Internet resources
2.2.1. Delegated address space 2.6. Internet Exchange Point (IXP)
2.2.2. Allocated address space 2.7. Usage rate
2.2.3. Assigned address space 2.8. Utilization
2.3. Autonomous System (AS) 2.9. End-site
2.3.1. Autonomous System Number (ASN) 2.10. End-user
2.4. Multihomed 2.11. aut-num object
2.5. Internet resources 2.12. Routing policy
2.5.1. Current resources 2.13. Transfers
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. End-user
2.11. aut-num object
2.12 Routing policy
2.13. Transfers
2.13.1. Counterpart RIR
2.13.2. Source
2.13.3. Recipient
3.0. Policy framework 3.0. Policy framework
3.1. Goals of resource management 3.1. Goals of resource management
3.1.1. Uniqueness 3.2. Policy Environment
3.1.2. Registration 3.3. Applicants seeking address space from multiple IRs
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.0. Resource License
4.1. License Renewal 4.1. License Renewal
4.1.1. Review 4.2. Closure and recovery
4.1.2. Validity of delegations
4.2. Closure and recovery
4.2.1. Recovery of unused historical resources
5.0. Resource Management 5.0. Resource Management
5.1. How APNIC manages address space 5.1. How APNIC manages address space
5.1.1. Reservation for future uses 5.2. LIR address space management
5.1.2. Sparse allocation framework 5.3. Registration requirements
5.1.3. IPv4 addresses returned to APNIC 5.4. Reverse lookup
5.1.4. Preventing the Use of Undelegated APNIC Address Space 5.5. Managing Historical resources
5.2. LIR address space management 5.6. General requirements for requests
5.2.1. IPv4 address usage estimates 5.7. Experimental allocations policy
5.2.2. IPv4 Delegations to downstream IRs
5.2.2.1. Effect of delegation to downstream IRs on upstream LIR’s
usage rate
5.2.3. Policies for LIR IPv6 allocation and assignment
5.2.3.1. LIR-to-ISP allocation
5.2.3.2. Assignment address space size
5.2.3.3. Assignment of multiple /48s to a single end site
5.3. Registration requirements
5.3.1. Requirements for Autonomous System Numbers (ASNs) and Addresses
5.3.2. Updating registration details
5.3.3. Registering contact persons
5.4. Reverse lookup
5.4.1. Responsibility to maintain IPv4 in-addr.arpa records
5.4.2. IPv6 reverse lookup
5.5. Managing Historical resources
5.5.1. Utilization of Historical IPv4 address space
5.5.2. Protecting Historical records in the APNIC Whois Database
5.5.3. Procedure for updating Historical registrations
5.5.4. Policies applicable to updated Historical resources
5.6. General requirements for requests
5.6.1. Security and confidentiality
5.6.2. Equitable processing of requests
5.7. Experimental allocations policy
5.7.1. Introduction
5.7.1.1. Scope and goal
5.7.2. Allocations for experimental purposes
5.7.2.1. Publication of an experimental RFC
5.7.2.2. Alternative publication approved by APNIC
5.7.3. Experimental allocations
5.7.3.1. Public disclosure of experiment
5.7.3.2. Size of IP allocations
5.7.3.3. APNIC input on proposed experiment
5.7.3.4. Duration of allocation licenses
5.7.3.5. Extension of license
5.7.4. Registration
5.7.4.1. Restriction on commercial or undocumented uses
5.7.5. Fees for experimental allocations
Part 2: IPv4 Policy Part 2: IPv4 Policy
6.0. Initial IPv4 delegations 6.0. Initial IPv4 delegations
6.1. Minimum and maximum IPv4 delegations 6.1. Minimum and maximum IPv4 delegations
6.1.1. Additional allocation rounds 6.2. IPv4 request criteria
6.2. IPv4 request criteria 6.2.1. IPv4 for LIRs
6.2.1. IPv4 for LIRs 6.2.2. IPv4 for multihoming
6.2.2. IPv4 for multihoming 6.2.3. IPv4 for critical infrastructure
6.2.3. IPv4 for critical infrastructure 6.2.4. IPv4 for Internet Exchange Points
6.2.4. IPv4 for Internet Exchange Points
7.0. Subsequent IPv4 delegations 7.0. Subsequent IPv4 delegations
7.1. Prior delegations to be used first 7.1. Prior delegations to be used first
7.2. Special circumstances – large delegations 7.2. Special circumstances – large delegations
8.0. IPv4 Transfers
8.1. IPv4 transfers within the APNIC region
8.1.1. Conditions on the space to be transferred
8.1.2. Conditions on source of the transfer
8.1.3. Conditions on recipient of the transfer
8.2. Inter-RIR IPv4 address transfers
8.2.1. Conditions on the space to be transferred
8.2.2. Conditions on the source of the transfer
8.2.3. Conditions on the recipient of the transfer
8.3. Transfer of Historical Internet resources
8.3.1. Transfer procedure
8.3.2. Policies applicable to transferred Historical resources
8.4. Mergers & acquisitions
8.4.1. Updating registration details
8.4.2. Effect on membership agreement
8.4.3. Consequences for allocations
Part 3: IPv6 Policy Part 3: IPv6 Policy
8.0. IPv6 allocations
9.0. IPv6 allocations 8.1. Minimum IPv6 allocation
9.1. Minimum IPv6 allocation 8.2. Initial IPv6 allocations
9.2. Initial IPv6 allocations 8.2.1. Account holders with existing IPv4 space
9.2.1. Account holders with existing IPv4 space 8.2.2. Account holders without existing IPv4 space
9.2.2. Account holders without existing IPv4 space 8.3. Subsequent IPv6 allocations
9.3. Subsequent IPv6 allocations 8.3.1. Existing IPv6 address resource holders
9.3.1. Existing IPv6 address space holders 8.3.2. Applied HD-Ratio
9.3.2. Applied HD-Ratio 8.3.3. Alternative allocation criteria
9.3.3. Alternative allocation criteria 8.3.4. Size of subsequent allocation
9.3.4. Size of subsequent allocation 9.0. IPv6 assignments
9.1. Criteria for IPv6 Assignments
10.0. IPv6 assignments 9.1.1. IPv6 for multihoming
10.1. Criteria for IPv6 Assignments 9.1.2. IPv6 critical infrastructure
10.1.1. IPv6 for multihoming 9.1.3. IPv6 for Internet Exchange Points
10.1.2. IPv6 critical infrastructure 9.1.4. Provider Independent IPv6 assignment
10.1.3. IPv6 for Internet Exchange Points
10.1.4. Provider Independent IPv6 assignment
10.1.4.1. Initial assignment
10.1.4.2. Subsequent assignment
11.0. Transfer of IPv6 resources
11.1. Updating registration details
11.2. Effect on membership agreement
11.3. Consequences for allocations
Part 4: ASN Policy Part 4: ASN Policy
10.0. ASN assignments
12.0. ASN assignments 10.1. Evaluation of eligibility
12.1. Evaluation of eligibility 10.2. Requesting an ASN
12.2. Requesting an ASN 10.3. Using ASN for own network
12.3. Using ASN for own network 10.4. Providing ASN to customer
12.4. Providing ASN to customer 10.5. Two-byte only and four-byte AS Numbers
12.5. Two-byte only and four-byte AS Numbers
13.0. ASN Transfers Part 5: Transfer Policy
13.1. Transfers of ASNs between APNIC account holders 11.0. IPv4 Transfers
13.1.1. Conditions on resource 11.1. IPv4 transfers within the APNIC region
13.1.2. Conditions on source of the transfer 11.1.1. Conditions on the space to be transferred
13.1.3. Conditions on recipient of the transfer 11.1.2. Conditions on source of the transfer
13.2. Inter-RIR ASN transfers 11.1.3. Conditions on recipient of the transfer
13.2.1. Conditions on the space to be transferred 11.2. Inter-RIR IPv4 address transfers
13.2.2. Conditions on the source of the transfer 11.2.1. Conditions on the space to be transferred
13.2.3. Conditions on the recipient of the transfer 11.2.2. Conditions on the source of the transfer
13.3. Mergers & acquisitions 11.2.3. Conditions on the recipient of the transfer
13.3.1. Updating registration details 11.3. Transfer of Historical Internet resources
13.3.2. Effect on membership agreement 11.3.1. Transfer procedure
13.3.3. Consequences for allocations 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
14.0. Mergers & Acquisitions
14.1. Updating registration details
14.2. Effect on membership agreement
14.3. Consequences for allocations
Appendix A: HD-Ratio 15. Appendix A: HD-Ratio
Part 1: Policy Environment Part 1: Policy Environment
1.0. Introduction 1.0. Introduction
The Asia Pacific Network Information Centre (APNIC) is the Regional The Asia Pacific Network Information Centre (APNIC) is the Regional Internet Registry (RIR)
Internet Registry (RIR) for the Asia Pacific. It is responsible for the for the Asia Pacific. It is responsible for the regional distribution of public Internet
regional distribution of public Internet address space and related address space and related resources, including Internet Protocol version 4 (IPv4) address
resources, including Internet Protocol version 4 (IPv4) address space, space, Internet Protocol version 6 (IPv6) address space, and Autonomous System Numbers (ASNs).
Internet Protocol version 6 (IPv6) address space, and Autonomous System APNIC also coordinates the development and implementation of policies to manage those resources.
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: This document outlines the overall principals and goals of Internet number resource distribution.
– The delegation of Internet Protocol version 4 (IPv4) address It also details specific policies for the distribution and management of these resources in the
space. Asia Pacific region.
– 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 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
This document should be read in conjunction with other APNIC be implemented by APNIC, by National Internet Registries (NIRs), and by Local Internet Registries
documents, policies, and guidelines; including those dealing (LIRs) throughout the region.
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 1.1. Scope
document, APNIC may publish other information relating to 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).
Internet number resources, including: 1.1.1. Additional guidelines and policies
– further descriptions of evaluation procedures; This document should be read in conjunction with other APNIC documents, policies, and guidelines;
– summaries of the best current practices that organizations including those dealing with membership and fees, as these documents may provide additional
requesting resources will generally be expected to adopt; and operational guidance, or may impose additional requirements on resource holders.
– other information that may assist organizations to request
resources.
This document does not provide specific details of request In addition to the eligibility criteria described in this document, APNIC may publish other
evaluation by APNIC, or of expectations relating to specific information relating to Internet number resources, including:
technologies. Such details are dependent on technological * further descriptions of evaluation procedures.
advances, and may change frequently. Therefore, to assist * summaries of the best current practices that account holders requesting resources will
organizations to request address space, APNIC publishes separate generally be expected to adopt; and
guideline documents relating to specific technologies or * other information that may assist account holders to request resources.
techniques as required. 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 These guidelines are developed within the APNIC community and will be consistent with the goals
will be consistent with the goals and policies described in this and policies described in this document.
document.
1.1.2. Private address space 1.1.2. Private address space
—————————- This document does not describe specific addressing policies related to multicast or private
This document does not describe specific addressing policies address space. The use of private address space may be appropriate for addressing networks
related to multicast or private address space. The use of where there are no technical requirements for the use of public address space. In general,
private address space may be appropriate for addressing networks private address space should be used for networks not directly connected to the Internet.
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 1.2. Hierarchy of resource distribution
————————————— IP addresses and ASNs are distributed in accordance with the hierarchical structure initially
IP addresses and ASNs are distributed in accordance with the described in RFC7020 and represented simply as this diagram.
hierarchical structure initially described in RFC7020 and
represented simply in fig.1.
+——–+ +——–+
| IANA | | IANA |
+——–+ +——–+
| |
+———–+———–+———–+———–+ +———–+———–+———–+———–+
| | | | | | | | | |
+——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+
| ARIN | |RIPE NCC| | APNIC | | LACNIC | | AfriNIC| | ARIN | |RIPE NCC| | APNIC | | LACNIC | | AfriNIC|
+——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+ +——–+
skipping to change at line 338 skipping to change at line 207
+——+ | +——+ | +——+ | Internet Service +——+ | +——+ | +——+ | Internet Service
| ISP | | | ISP | | | ISP | | Providers | ISP | | | ISP | | | ISP | | Providers
+——+ | +——+ | +——+ | +——+ | +——+ | +——+ |
| | | | | | | | | | | |
+—-+ +—-+ +—-+ +—-+ +—-+ +—-+ End-users +—-+ +—-+ +—-+ +—-+ +—-+ +—-+ End-users
| EU | | EU | | EU | | EU | | EU | | EU | | EU | | EU | | EU | | EU | | EU | | EU |
+—-+ +—-+ +—-+ +—-+ +—-+ +—-+ +—-+ +—-+ +—-+ +—-+ +—-+ +—-+
[Figure 1: Diagram of distribution hierarchy] [Figure 1: Diagram of distribution hierarchy]
In this hierarchy, IANA allocates address space to APNIC, to be In this hierarchy, IANA allocates address space to APNIC, to be redistributed throughout the
redistributed throughout the Asia Pacific region. APNIC allocates Asia Pacific region. APNIC allocates address space to Internet Registries (IRs) and delegates
address space to Internet Registries (IRs) and also delegates to to them the authority to make assignments and allocations. In some cases, APNIC assigns
them the authority to make assignments and allocations. In some address space to end users. National and Local IRs allocate and assign address space to
cases APNIC assigns address space to end users. National and Local their account holders under the guidance of APNIC and in accordance with the relevant policies
IRs allocate and assign address space to their members and customers and principals described in this document.
under the guidance of APNIC and in accordance with the relevant
policies and principals described in this document.
2.0. Definitions 2.0. Definitions
The following terms and definitions are used in APNIC documents. The following terms and definitions are used in APNIC documents.
2.1. Internet Registry (IR) 2.1. Internet Registry (IR)
————————— An Internet Registry (IR) is an organization that is responsible for distributing IP address
An Internet Registry (IR) is an organization that is responsible for space to its account holders and for registering those distributions. IRs are classified
distributing IP address space to its Members or customers and for according to their primary function and territorial scope within the hierarchical structure
registering those distributions. IRs are classified according to depicted in the figure above.
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;
– Criteria for the recognition of NIRs in the APNIC region
– http://www.apnic.net/policy/nir-criteria
– Operational policies for NIRs in the APNIC region
– http://www.apnic.net/policy/operational-policies-nirs
– APNIC and NIR Membership Relationship Agreement
– http://www.apnic.net/nir-agreement
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 Internet Registries include:
—————————— * APNIC and other Regional Internet Registries (RIRs)
APNIC “delegates” addresses to its account holders. These * National Internet Registries (NIRs)
delegations can be for use on the organization’s own * Local Internet Registries (LIRs).
infrastructure (an “assignment”) or for subsequent delegation by
the organization to its customers (an “allocation”).
2.2.2. Allocated address space 2.1.1. Regional Internet Registry (RIR)
—————————— Regional Internet Registries (RIRs) are established and authorized by their respective regional
Allocated address space is address space that is distributed to communities and recognized by the IANA to serve and represent large geographical regions. Their
IRs or other organizations for the purpose of subsequent primary role is to manage, distribute, and register public Internet address space within their
distribution by them. respective region. There are five RIRs: AFRINIC, APNIC, ARIN, LACNIC, and the RIPE NCC.
2.2.3. Assigned address space 2.1.2. National Internet Registry (NIR)
—————————– National Internet Registries (NIRs) are established and authorized by their respective regional
Assigned address space is address space that is delegated to an communities and recognized by RIRs to delegate address space to their account holders, which are
LIR, or end-user, for exclusive use within the Internet generally LIRs organized at a national level. NIRs are expected to apply their policies and
infrastructure they operate. procedures fairly and equitably to all account holders of their constituency.
2.3. Autonomous System (AS) 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
An Autonomous System (AS) is a connected group of one or more IP roles and responsibilities may be described in other documents and agreements including:
prefixes run by one or more network operators under a single and * Criteria for the recognition of NIRs in the APNIC region
clearly-defined routing policy. http://www.apnic.net/policy/nir-criteria
* Operational policies for NIRs in the APNIC region
http://www.apnic.net/policy/operational-policies-nirs
* APNIC and NIR Membership Relationship Agreement
http://www.apnic.net/nir-agreement
2.3.1. Autonomous System Number (ASN) 2.1.3. Local Internet Registry (LIR)
————————————- A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of
An Autonomous System Number (ASN) is a unique two- or four-byte the network services that it provides.
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 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
Multihoming is a way of connecting an organization’s network to the “downstream” ISPs, which further assign address space to their own customers.
public Internet through more than one AS.
2.5. Internet resources 2.2. Address space
———————– In this document, address space means public unicast IP address ranges, which include IP
Internet resources are public IPv4 and IPv6 address numbers, version 4 (IPv4) and IP version 6 (IPv6).
Autonomous System Numbers, and reverse DNS delegations.
2.5.1. Current resources 2.2.1. Delegated address space
———————— APNIC “delegates” addresses to its account holders. These delegations can be for use on their
Current resources are Internet resources registered by APNIC own infrastructure (an “assignment”) or for subsequent delegation by the requestors to its
under explicit policies and agreements. customers (an “allocation”).
2.5.2. Historical resources 2.2.2. Allocated address space
————————— Allocated address space is address space that is distributed to IRs or other account holders
Historical resources are Internet resources registered under for the purpose of subsequent distribution by them.
early registry policies without formal agreements and include:
– Registrations transferred to APNIC as part of the AUNIC to 2.2.3. Assigned address space
APNIC migration Assigned address space is address space that is delegated to an LIR, or end-user, for exclusive
– Some historical resource registrations have been use within the Internet infrastructure they operate.
inherited by APNIC from the former AUNIC address
registry.
– A list of resources transferred to APNIC as part of the 2.3. Autonomous System (AS)
migration is available on the APNIC website at: 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.
http://www.apnic.net/aunic 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.
– Registrations transferred as part of the Early Registration 2.4. Multihomed
Transfer (ERX) project Multihoming is a way of connecting an autonomous network to the public Internet through more
– Most historical registrations were initially made by the than one AS.
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 2.5. Internet resources
ERX project is available at: Internet resources are public IPv4 and IPv6 address numbers, Autonomous System Numbers, and
reverse DNS delegations.
http://www.apnic.net/erx 2.5.1. Current resources
Current resources are Internet resources registered by APNIC under explicit policies and
agreements.
– Historical APNIC resources 2.5.2. Historical resources
– Historical APNIC resources were delegated to Historical resources are Internet resources registered under early registry policies without
organizations by APNIC prior to the introduction of a formal agreements and include:
Membership structure. These resources have always been * Registrations transferred to APNIC as part of the AUNIC to APNIC migration
registered in the APNIC Whois Database, but if the o Some historical resource registrations have been inherited by APNIC from the former AUNIC
resource holder did not become an APNIC Member at any address registry.
time after the introduction of the Membership structure, o A list of resources transferred to APNIC as part of the migration is available on the APNIC
the resources were not made subject to current APNIC website at: http://www.apnic.net/aunic
policies. * Registrations transferred as part of the Early Registration Transfer (ERX) project
o 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.
o A list of resources transferred to APNIC as part of the ERX project is available at:
http://www.apnic.net/erx
* Historical APNIC resources
o 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) 2.6. Internet Exchange Point (IXP)
———————————- An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 network structure that
An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 interconnects three or more Autonomous Systems (AS) for the purpose of Internet traffic
network structure that interconnects three or more Autonomous interchange.
Systems (AS) for the purpose of Internet traffic interchange.
2.7. Usage rate 2.7. Usage rate
————— Usage rate is the rate at which the LIR made delegations from relevant past address space,
Usage rate is the rate at which the LIR made delegations from including Historical delegations.
relevant past address space, including Historical delegations.
2.8. Utilization 2.8. Utilization
—————- Utilization is a measure of IPv6 address usage where “utilization” is only measured in terms
Utilization is a measure of IPv6 address usage where “utilization” of the bits to the left of the /56 boundary. In other words, utilization refers to the
is only measured in terms of the bits to the left of the /56 delegation of /56s to end sites, and not the number of addresses assigned within individual /56s
boundary. In other words, utilization refers to the delegation of at those end sites.
/56s to end sites, and not the number of addresses assigned within
individual /56s at those end sites.
2.8.1. HD-Ratio 2.8.1. HD-Ratio
————— The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an
The HD-Ratio is a way of measuring the efficiency of address adaptation of the H-Ratio originally defined in [RFC1715] and is expressed as follows:
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) Log (number of allocated objects)
HD = ————————————- HD = ————————————————————-
Log (maximum number of allocatable objects) Log (maximum number of allocatable objects)
where (in the case of this document) the objects are IPv6 site where (in the case of this document) the objects are IPv6 site addresses (/56s) assigned from
addresses (/56s) assigned from an IPv6 prefix of a given size. an IPv6 prefix of a given size.
2.9. End-site 2.9. End-site
————- An end site is defined as the location of an end-user who has a business or legal relationship
An end site is defined as the location of an end-user who has a (same or associated entities) with a service provider that involves:
business or legal relationship (same or associated entities) with * that service provider assigning address space to the end-user location
a service provider that involves: * that service provider providing transit service for the end-user location to other sites
– that service provider assigning address space to the end-user location * that service provider carrying the end-user’s location traffic
– that service provider providing transit service for the end-user * that service provider advertising an aggregate prefix route that contains the end-user’s
location to other sites location assignment
– 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.10. End-user 2.10. End-user
——————– Service subscriber or customer of an LIR.
Service subscriber or customer of an LIR.
2.11. aut-num object 2.11. aut-num object
——————– An aut-num object is an object in the Whois database used to register ASN assignment details.
An aut-num object is an object in the Whois database used to For the purposes of this document, aut-num object also refers to the ASN registration objects
register ASN assignment details. For the purposes of this document, in NIR databases.
aut-num object also refers to the ASN registration objects in NIR
databases.
2.12. Routing policy 2.12. Routing policy
——————– The routing policy of an AS is a description of how network prefixes are exchanged between that
The routing policy of an AS is a description of how network prefixes AS and other Autonomous Systems.
are exchanged between that AS and other Autonomous Systems.
2.13. Transfers 2.13. Transfers
————— Resource transfers involve the re-allocation of current address blocks (or ASNs), or the
Resource transfers involve the re-allocation of current address re-allocation of historical resources claimed and transferred to an APNIC account holder.
blocks (or ASNs), or the re-allocation of historical resources
claimed and transferred to an APNIC account.
2.13.1. Counterpart RIR 2.13.1. Counterpart RIR
———————– A counterpart RIR is the Regional Internet Registry that APNIC transfers resources to, or from,
A counterpart RIR is the Regional Internet Registry that APNIC in an inter-RIR transfer.
transfers resources to, or from, in an inter-RIR transfer.
2.13.2. Source 2.13.2. Source
————– The source in a resource transfer is the organization which, prior to the transfer, is the
The source in a resource transfer is the organization which, legitimate holder of the resources to be transferred. Where the source is in the APNIC region,
prior to the transfer, is the legitimate holder of the resources the source must be a current APNIC account holder, except in the case of an Historical resource
to be transferred. Where the source is in the APNIC region, the transfer. Where the source is from another RIR region, it must be that RIR’s equivalent to
source must be a current APNIC account holder, except in the the “Source” as defined here.
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.13.3. Recipient 2.13.3. Recipient
—————– The recipient in a resource transfer is the organization which, after the transfer is completed,
The recipient in a resource transfer is the organization which, will be the legitimate holder of the resources to be transferred. Where the recipient is in the
after the transfer is completed, will be the legitimate holder APNIC region, the recipient must be a current APNIC account holder. Where the recipient is from
of the resources to be transferred. Where the recipient is in another RIR region, it must be that RIR’s equivalent to the “Recipient” as defined here.
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.
3.0. Policy framework 3.0. Policy framework
IP address space and other number resources, are public resources which IP address space and other number resources are public resources which must be managed in a prudent
must be managed in a prudent manner with regards to the long-term manner with regards to the long-term interests of the Internet. Responsible management involves
interests of the Internet. Responsible management involves balancing a balancing a set of sometimes competing goals. The following are the goals relevant to Internet
set of sometimes competing goals. The following are the goals relevant number policy.
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 3.1. Goals of resource management
—————– The goals described here were formulated by the Internet community and reflect the mutual interest
Every assignment and allocation of address space must be of all members of that community in ensuring that the Internet can function and grow to the maximum
guaranteed as globally unique. This is an absolute requirement extent possible.
for ensuring that every public host on the Internet can be
uniquely identified.
3.1.2. Registration 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
All assignments and allocations made directly by APNIC to its implementing responsible policies and practices.
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 It is the responsibility of every NIR and LIR to also ensure these goals are met within their
custodians of these public resources should be identifiable. The respective regions and communities.
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 3.1.1. Uniqueness
hide its customer assignment registrations, then those records Every assignment and allocation of address space must be guaranteed as globally unique. This is an
will not be visible in the public whois database. Whois queries absolute requirement for ensuring that every public host on the Internet can be uniquely identified.
on these records will return details of the allocation.
3.1.3. Aggregation 3.1.2. Registration
—————— All assignments and allocations made directly by APNIC to its account holders must be registered in
Address policies should seek to avoid fragmentation of address a publicly accessible database. This is necessary to ensure uniqueness and to provide information
ranges. for Internet troubleshooting at all levels, ranging from all RIRs and IRs to end-users.
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 It also reflects the expectation of the Internet community that custodians of these public resources
the size of the total address pool creates significant should be identifiable. The goal of registration should be applied within the context of reasonable
implications for both internal and external routing. 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.
It is a condition of all delegations made under initial or If the account holder does not indicate a choice, or chooses to hide its customer assignment
subsequent LIR delegation criteria, that the address space is registrations, then those records will not be visible in the public Whois database. Whois queries on
aggregated by the LIR within a minimum number of route these records will return details of the allocation.
announcements (preferably one).
LIRs must only delegate addresses to customers who will be using 3.1.3. Aggregation
those addresses in relation to network connectivity services Address policies should seek to avoid fragmentation of address ranges. Wherever possible, address
provided by the LIR. 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.
LIRs are expected to enter into agreements with their customers This goal is particularly important in IPv6 addressing, where the size of the total address pool
specifying that the end-user will hold the addresses only for so creates significant implications for both internal and external routing.
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 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
RIRs should apply practices that maximize the potential for (preferably one).
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 LIRs must only delegate addresses to customers who will be using those addresses in relation to
with previous delegations, but cannot guarantee that this will network connectivity services provided by the LIR.
be possible.
3.1.5. Conservation 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
To maximize the lifetime of the available resource, address should also be consistent with the license under which the address space is being used by the LIR.
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, 3.1.4. No guarantee of contiguous delegations
address policies should avoid unnecessarily wasteful practices. RIRs should apply practices that maximize the potential for subsequent allocations to be made
Requests for address space should be supported by appropriate contiguous with past allocations currently held. However, there can be no guarantee of contiguous
documentation and stockpiling of unused IPv6 addresses should allocation.
also be avoided.
3.1.6. Fairness APNIC will attempt to make any subsequent delegations contiguous with previous delegations but
————— cannot guarantee that this will be possible.
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 3.1.5. Conservation
————————- To maximize the lifetime of the available resource, address space must be distributed according to
It is desirable to minimize the overhead associated with actual need and for immediate use. Stockpiling address space and maintaining reservations are contrary
obtaining address space. Overhead includes the need to go back to this goal. Conservation also implies efficiency. Therefore, all users of address space should adopt
to RIRs for additional space too frequently. There is overhead techniques such as Variable Length Subnet Masking (VLSM) and appropriate technologies that ensure the
associated with managing address space that grows through a address space is not used wastefully.
number of small successive incremental expansions rather than
through fewer, but larger, expansions.
3.1.8. Conflict of goals Although IPv6 provides an extremely large pool of address space, address policies should avoid
———————— unnecessarily wasteful practices.
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 Requests for address space should be supported by appropriate documentation and stockpiling of
consistent and equitable ways. IRs must maintain full unused IPv6 addresses should also be avoided.
documentation of and transparency within the decision-making
process.
In IPv6 address policy, the goal of aggregation is considered to 3.1.6. Fairness
be the most important. 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.2. Policy Environment 3.1.7. Minimized Overhead
———————– It is desirable to minimize the overhead associated with obtaining address space. Overhead includes the
Apart from the goals described above, other factors influence the need to go back to RIRs for additional space too frequently. There is overhead associated with managing
APNIC policy environment. These other factors include the address space that grows through a number of small successive incremental expansions rather than through
expectations of the Internet community, current administrative fewer, but larger, expansions.
structures, and technological constraints.
The policy environment may change quickly or in unpredictable ways, 3.1.8. Conflict of goals
so APNIC, on behalf of its Members, must monitor any changes and The goals described above will often conflict with each other, or with the needs of individual IRs or
communicate any policy implications. 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.
This section describes the factors in the current operating This document is intended to help IRs perform their role in consistent and equitable ways. IRs must
environment that have been most important in determining current maintain full documentation of and transparency within the decision-making process.
APNIC policies.
3.2.1. Routability In IPv6 address policy, the goal of aggregation is considered to be the most important.
——————
There is no guarantee that any address allocation or assignment
will be globally routable.
The routability of address space throughout the Internet can 3.2. Policy Environment
never be guaranteed by any single organization. However, IRs Apart from the goals described above, other factors influence the APNIC policy environment. These other
must apply procedures that reduce the possibility of fragmented factors include the expectations of the Internet community, current administrative structures, and
address space which may lead to a loss of routability. technological constraints.
To reduce the number of globally advertised routes, network The policy environment may change quickly or in unpredictable ways, so APNIC, on behalf of its account
operators may implement route filtering policies based on prefix holders, must monitor any changes and communicate any policy implications.
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 This section describes the factors in the current operating environment that has been most important in
limit the expansion of global routing tables. Aggregating determining current APNIC policies.
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 3.2.1. Routability
—————————- There is no guarantee that any address allocation or assignment will be globally routable.
Early strategies for distributing address space did not The routability of address space throughout the Internet can never be guaranteed by any single account
anticipate the rapid growth of the Internet and the scaling holder. However, IRs must apply procedures that reduce the possibility of fragmented address space
problems that followed, affecting both the amount of address which may lead to a loss of routability.
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 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
APNIC shares with its Members and their customers a collective routability problems. Therefore, APNIC policies encourage those seeking address space to request from
responsibility to ensure manageable and scalable Internet growth upstream providers rather than from APNIC directly.
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 The responsible management of ASNs is also necessary to help limit the expansion of global routing
implicit trust that delegated responsibilities are carried out tables. Aggregating contiguous IP address prefixes within single Autonomous Systems helps to minimize
in good faith. Specifically, APNIC must trust that the the number of routes announced to the global Internet.
information gathered from Members during the request process is
genuine and accurate.
3.2.4. Impartiality 3.2.2. Internet growth rates
——————- Early strategies for distributing address space did not anticipate the rapid growth of the Internet
APNIC represents the interests of the Internet community in and the scaling problems that followed, affecting both the amount of address space available and
general and the Internet community of the Asia Pacific region in routing. Therefore, APNIC policies take account of past experience and seek to manage address space
particular. Therefore, APNIC must apply its policies fairly and in a way that will maximize future scaling of the Internet.
equitably, without regard to an organization’s size, geographic
location, or any other factor.
3.2.5. Varying levels of expertise 3.2.3. Collective responsibility
———————————- APNIC shares with its account holders and their customers a collective responsibility to ensure
Different IRs and end-users have varying levels of experience manageable and scalable Internet growth and to make decisions consistent with the goals described
and expertise. APNIC policies allow for varying levels of here. Therefore, APNIC policies and procedures are developed by APNIC account holders and the
assistance and monitoring, appropriate to ensure a consistent broader Internet community as a whole, in the common interest of those communities.
approach to address space management throughout the Asia Pacific
Internet community.
3.2.6. Address ownership 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
The Internet community regards address space as a scarce, public gathered from account holders during the request process is genuine and accurate.
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 3.2.4. Impartiality
————————– APNIC represents the interests of the Internet community in general and the Internet community of
Stockpiling addresses is harmful to the goals of conservation the Asia Pacific region in particular. Therefore, APNIC must apply its policies fairly and equitably,
and fairness. APNIC policies must prevent stockpiling and ensure without regard to an account holder�s size, geographic location, or any other factor.
efficient deployment of address space on the basis of immediate
demonstrated need.
3.2.8. Reservations not supported 3.2.5. Varying levels of expertise
——————————— Different IRs and end-users have varying levels of experience and expertise. APNIC policies allow for
When an LIR wants to delegate address space for customers, it varying levels of assistance and monitoring, appropriate to ensure a consistent approach to address
must use any address space it currently holds. space management throughout the Asia Pacific Internet community.
When evaluating address requests, reserved address space is not 3.2.6. Address ownership
considered to be delegated. 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.9. Evaluations to be based on best practice 3.2.7. Address stockpiling
———————————————– Stockpiling addresses is harmful to the goals of conservation and fairness. APNIC policies must
APNIC should ensure that address space holders adopt current prevent stockpiling and ensure efficient deployment of address space on the basis of immediate
best practice in the management of the resources they use. If demonstrated need.
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 3.2.8. Reservations not supported
———————————— When an LIR wants to delegate address space for customers, it must use any address space it currently
Because the goals of aggregation and conservation conflict, it holds. When evaluating address requests, reserved address space is not considered to be delegated.
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 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
APNIC and NIRs apply a slow start mechanism to all new LIRs. The resources they use. If appropriate technologies exist for improved management of address space in
slow start is applied to prevent delegations of large blocks of particular situations, the community expects that those technologies should be used. APNIC consults
address space that may then remain substantially unused. 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.11.1. Exceptions to slow start 3.2.10. Minimum practical delegation
———————————- Because the goals of aggregation and conservation conflict, it is necessary to apply a minimum practical
In exceptional circumstances, an LIR may receive a greater size for address space delegation. This minimum size may be reviewed from time to time, as technologies
initial delegation if it can demonstrate that its immediate and administrative conditions evolve.
need for address space exceeds the standard slow start
delegation.
The documentation required to justify an exception to the 3.2.11. Slow start mechanism
slow start may include (but is not limited to): 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.
– Receipts for the purchase of equipment, Purchase Orders, 3.2.11.1. Exceptions to slow start
or In exceptional circumstances, an LIR may receive a greater initial delegation if it can demonstrate that its
– Signed project contracts indicating the immediate network immediate need for address space exceeds the standard slow start delegation.
requirements to be met by the LIR. 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 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
Organizations must obtain their address space from only one IR at a any IR must declare all the address space they currently hold, regardless of the source. Applicants making
time. Organizations requesting address space from any IR must concurrent requests to more than one IR must declare the details of all of those requests.
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 In certain circumstances (for example, where an applicant network is multihomed), strong technical reasons may
multihomed), strong technical reasons may justify an organization justify an applicant receiving address space from more than one source.
receiving address space from more than one source.
For the purposes of this section, a parent organization and its For the purposes of this section, a parent organization and its subsidiaries are considered to be a single
subsidiaries are considered to be a single organization. Exceptions organization. Exceptions may arise in cases where the parts of the organization:
may arise in cases where the parts of the organization: * Are separate legal entities,
– Are separate legal entities, * Maintain fully independent network infrastructures and are routed under different ASNs, or
– Maintain fully independent network infrastructures and are routed * Can otherwise demonstrate a justified need to obtain address space from more than one IR.
under different ASNs, or
– Can otherwise demonstrate a justified need to obtain address space
from more than one IR.
4.0. Resource License 4.0. Resource License
It is contrary to the goals of this document and is not in the interests It is contrary to the goals of this document and is not in the interests of the Internet community as a whole,
of the Internet community as a whole, for Internet number resources to for Internet number resources to be considered freehold property.
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 Neither delegation nor registration confers ownership of resources. Account holders that use them are considered
globally-unique unicast address space is licensed for use rather than “custodians” rather than “owners” of the resource and are not entitled to sell or otherwise transfer that resource
owned. to other parties outside the provisions in this document.
4.1. License Renewal 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
Specifically, APNIC will delegate Internet resources on a ‘license’ for use rather than owned.
basis, with licenses subject to renewal on a periodic basis
(normally one year).
The granting of a license is subject to specific conditions as 4.1. License Renewal
described in the APNIC membership agreements, service agreements, Specifically, APNIC will delegate Internet resources on a ‘license’ basis, with licenses subject to renewal on a
and other relevant APNIC documents, at the start or renewal of the periodic basis (normally one year).
license.
IRs will generally renew licenses automatically, provided The granting of a license is subject to specific conditions as described in the APNIC membership agreements,
requesting organizations are making a good-faith effort at meeting service agreements, and other relevant APNIC documents, at the start or renewal of the license.
the criteria under which they qualified for, or were granted an
allocation or assignment.
Licenses to organizations shall be renewable on the following IRs will generally renew licenses automatically, provided account holders are making a good-faith effort at
conditions: meeting the criteria under which they qualified for, or were granted an allocation or assignment.
– The original basis of the delegation remains valid, and Licenses to account holders shall be renewable on the following conditions:
– That address space is properly registered at the time of renewal. * The original basis of the delegation remains valid, and
* That address space is properly registered at the time of renewal.
4.1.1. Review 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
In those cases where a requesting organization is not using the through on the associated obligation, IRs reserve the right to not renew the license. However, individual licenses
address space as intended, or is showing bad faith in following shall only be subject to review if the relevant IR has reason to believe that the existing license terms are no
through on the associated obligation, IRs reserve the right to longer being complied with. IRs may implement their own procedures for the review of existing licenses as they see fit.
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 When a license is renewed, the new license will be evaluated and governed subject to all policies and license
governed subject to all policies and license conditions conditions effective at the time of renewal. These may differ from those in place at the time of the original
effective at the time of renewal. 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.
These may differ from those in place at the time of the original 4.1.2. Validity of delegations
delegation, provided that a minimum notice period of one year is A resource delegation is valid only while the original criteria on which it was made remains valid. If a delegation
given of any substantial changes. Substantial changes to license becomes invalid, then the resource must be returned to the appropriate IR.
conditions are subject to the consensus of APNIC Members, in
accordance with the APNIC Document Editorial Policy.
4.1.2. Validity of delegations An allocation or assignment becomes invalid if it is:
—————————— * Made for a specific purpose that no longer exists, or
A resource delegation is valid only while the original criteria * Based on information that is later found to be false or incomplete.
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: 4.2. Closure and recovery
– Made for a specific purpose that no longer exists, or If an LIR holding APNIC address space ceases to provide Internet connectivity services, all of its address space
– Based on information that is later found to be false or must be returned to APNIC. It is the responsibility of the LIR (or any liquidator or administrator appointed
incomplete. 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.
4.2. Closure and recovery 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
If an LIR holding APNIC address space ceases to provide Internet as a new address request process.
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 4.2.1. Recovery of unused historical resources
of the closed LIR, the existing address space may be transferred to A significant number of historical resources registered in the APNIC Whois Database are not announced to the global
the new LIR, however such a transfer is subject to re-examination by routing table.
APNIC and may be treated as a new address request process.
4.2.1. Recovery of unused historical resources 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
A significant amount of historical resources registered in the routed since 1 January 1998.
APNIC Whois Database are not announced to the global routing
table.
To recover these globally un-routed resources and place them To recover un-routed historical AS numbers, APNIC will contact networks responsible for resources not globally
back in the free pool for re-delegation, APNIC will contact used for a reasonable period of time.
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.
5.0. Resource Management 5.0. Resource Management
All NIRs and LIRs that receive address space from APNIC (either directly All NIRs and LIRs that receive address space from APNIC (either directly or indirectly) must adopt delegation
or indirectly) must adopt delegation policies that are consistent with policies that are consistent with the policies described in this document.
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 NIRs and LIRs must ensure that address space for which they are responsible is only allocated or assigned
members in a manner consistent with the way APNIC applies such policies. subject to agreements consistent with the license provisions in this document.
5.1. How APNIC manages address space 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.1. Reservation for future uses 5.1. How APNIC manages address space
———————————-
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 5.1.1. Reservation for future uses
available space has been delegated, the /16 will be returned to A /16 of IPv4 address space will be held in reserve for future uses, as yet unforeseen. If the reserved /16 remains
the APNIC pool for distribution under the policies described in unused by the time the remaining available space has been delegated, the /16 will be returned to the APNIC pool
this document. for distribution under the policies described in this document.
5.1.2. Sparse allocation framework 5.1.2. Sparse allocation framework
———————————- APNIC will document the sparse allocation algorithm framework used to select IPv6 address blocks for delegation,
APNIC will document the sparse allocation algorithm framework in document apnic-114: APNIC guidelines for IPv6 allocation and assignment requests. This document is available
used to select IPv6 address blocks for delegation, in document at the following URL:
apnic-114: APNIC guidelines for IPv6 allocation and assignment
requests. This document is available at the following URL:
http://www.apnic.net/ipv6-guidelines http://www.apnic.net/ipv6-guidelines
5.1.3. IPv4 addresses returned to APNIC 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
Any IPv4 resources received by APNIC will be placed into the described in this document. This placement applies to any IPv4 addresses APNIC receives from IANA and/or holders
APNIC IPv4 pool for delegation under the policies described in of addresses in the APNIC Whois Database, subject to any future global policy for the redistribution of addresses
this document. This placement applies to any IPv4 addresses received by IANA from the RIRs.
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 resource 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 organization. When APNIC delegates address space to an organization,
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, 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.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 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.3.2. Assignment address space size 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
LIRs must make IPv6 assignments in accordance with the prevent its use, APNIC will create RPKI ROAs with origin AS0 (AS zero) for all undelegated address space (marked
following provisions. as �Available� and �Reserved� in the delegated-apnic-extended-latest stats file) for which it is the current
administrator.
End-users are assigned an end site assignment from their LIR or ISP. While any current account holder can create AS0 ROA for the resources they have under their account administration,
The size of the assignment is a local decision for the LIR or ISP to only APNIC has the authority to create AS0 ROAs for APNIC address space not yet delegated to an account holder. When
make, using a value of “n” x /64. APNIC delegates address space to an account holder, APNIC will remove the prefix from the AS0 ROA.
RIRs/NIRs are not concerned about which address size an 5.2. LIR address space management
LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not LIRs may delegate address space to their customers subject to the following provisions.
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.3.3. Assignment of multiple /48s to a single end site 5.2.1. IPv4 address usage estimates
——————————————————— Requests for delegations must be supported by usage estimates based on immediate and projected future need. These
Assignment larger than /48 (shorter prefix) or additional assignments requests must be accompanied by documentation that supports the estimates. The estimates should be made for the
exceeding a total of /48 must be made based on address usage, or because following periods:
of different routing requirements exist for additional assignments. * 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.
In case of a review or when making a request for a subsequent allocation, the The end-user must provide documentation that supports its one-year usage estimate. If it is not possible for the
LIR must be able to present documentation justifying the need for assignments end-user to estimate confidently what the two-year usage rate will be, then APNIC or the NIR may make a delegation
shorter than a /48 to a single end site. that will be sufficient for the one-year needs only.
5.3. Registration requirements 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
5.3.1. Requirements for Autonomous System Numbers (ASNs) and Addresses to the following conditions:
————————————————— * Delegations are non-portable and must be returned to the LIR if the downstream customer ceases to receive
IRs are responsible for promptly and accurately registering their ASN and connectivity from the LIR.
address space use with APNIC as follows: * The downstream customer is not permitted to further allocate the address space.
– All ASNs assigned must be publicly registered in the APNIC, or relevant NIR, 5.2.2.1. Effect of delegation to downstream IRs on upstream LIR’s usage rate
Whois database, for which APNIC or NIR will create the aut-num object. For the purposes of evaluating the LIR’s usage rate, address space delegated to downstream LIRs will be considered
– All the attributes of the aut-num object, must be registered in accordance as “used”. However, APNIC will give careful consideration to the registration of delegations made by the downstream
with APNIC or NIR whois database documentation. LIR to their customers and may request supporting documentation as necessary.
– 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 5.2.3. Policies for LIR IPv6 allocation and assignment
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 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
IRs must update their registration records and relevant objects when any of the policy for subordinate ISPs to encourage optimum utilization of the total address block allocated to the LIR.
registration information changes. This is the responsibility of the IR concerned. However, all /48 assignments to end sites are required to be registered either by the LIR or its subordinate ISPs
However, this responsibility may be formally assigned to the end-user as a condition in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.
of the original delegation.
Further, APNIC recommends that the routing policy of the AS is registered for each ASN 5.2.3.2. Assignment address space size
assigned. 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.
5.3.3. Registering Contact Persons 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
Administrative and technical contact persons must be registered. Section 8.2.1. and for the purposes of measuring utilization as defined in this document.
The registered administrative contact (“admin-c”) must be 5.2.3.3. Assignment of multiple /48s to a single end site
someone who is physically located at the site of the network, Assignment larger than /48 (shorter prefix) or additional assignments exceeding a total of /48 must be made based
subject to the following exceptions: on address usage, or because of different routing requirements exist for additional assignments.
– For residential networks or users, the IR’s technical contact In case of a review or when making a request for a subsequent allocation, the LIR must be able to present documentation
may be registered as the admin-c. justifying the need for assignments shorter than a /48 to a single end site.
– 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 5.3. Registration requirements
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) 5.3.1. Requirements for Autonomous System Numbers (ASNs) and Addresses
object for each resource record in the APNIC Whois Database. Contact IRs are responsible for promptly and accurately registering their ASN and address space use with APNIC as follows:
addresses listed in the IRT object (email, abuse-mailbox attributes) must * All ASNs assigned must be publicly registered in the APNIC, or relevant NIR, Whois database, for which APNIC or NIR
be regularly monitored and any abuse complaints sent to these contacts must will create the aut-num object.
be responded to promptly to resolve the complaints. * 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.
APNIC will validate IRT contacts periodically or every six (6) months to 5.3.2. Updating registration details
ensure they are accurate and contactable. Members are required to complete IRs must update their registration records and relevant objects when any of the registration information changes.
these validation checks within fifteen (15) days of receiving the validation This is the responsibility of the IR concerned. However, this responsibility may be formally assigned to the
check email from APNIC. If the IRT contacts fail the validation, APNIC will end-user as a condition of the original delegation.
mark the IRT object invalid in the APNIC Whois Database and follow up according Further, APNIC recommends that the routing policy of the AS is registered for each ASN assigned.
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.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.
5.4.1. Responsibility to maintain IPv4 in-addr.arpa records 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
LIRs should maintain in-addr.arpa resource records for their monitored and any abuse complaints sent to these contacts must be responded to promptly to resolve the complaints.
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 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
When an RIR/NIR delegates IPv6 address space to an organization, check email from APNIC. If the IRT contacts fail the validation, APNIC will mark the IRT object invalid in the APNIC
it also delegates the responsibility to manage the reverse Whois Database and follow up according to relevant policies and procedures. If validation still fails after thirty
lookup zone that corresponds to the allocated IPv6 address (30) days, the account holder will have limited access to MyAPNIC until their IRT contacts are validated.
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 5.4. Reverse lookup
———————————-
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.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.5.1. Utilization of Historical IPv4 address space 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
Utilization of Historical IPv4 address space is taken into the reverse lookup zone that corresponds to the allocated IPv6 address space. Each account holder should properly
account when any organization holding Historical IPv4 addresses manage its reverse lookup zone. When making an address assignment, the account holder must delegate to an assignee,
requests more IPv4 from APNIC. upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.
5.5.2. Protecting Historical records in the APNIC Whois Database 5.5. Managing Historical resources
—————————————————————- Historical resources were often delegated to organizations in a policy environment quite different to those in use
APNIC will protect all registrations of Historical Internet today. Historical resource holders should be aware of the current goals of Internet resource management as outlined
resources with the APNIC-HM maintainer, a practice consistent in this document.
with the management of current resources. The following policies specifically apply to Historical resources.
To ensure integrity of information, APNIC will not update 5.5.1. Utilization of Historical IPv4 address space
historical information in the APNIC Whois Database until the Utilization of Historical IPv4 address space is considered when any organization holding Historical IPv4 addresses
resource holder demonstrates the organization’s right to the requests more IPv4 from APNIC.
resources and enters a formal agreement with APNIC either as a
Member or Non-Member account holder.
5.5.3. Updating Historical registrations 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
Detailed information on how to request an update to a historical consistent with the management of current resources.
Internet resource registration is available on the historical To ensure integrity of information, APNIC will not update historical information in the APNIC Whois Database until
resource page of the APNIC website. 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 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.
Please note that resource holders will not be able to update Historical resource holders with a current account have access to MyAPNIC, which allows account holders to manage
registration information if they fail to pay the fees associated their resources and account information via a secure website.
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
—————————————
In order to properly evaluate 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 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.
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 Members and
their customers.
Therefore, APNIC will reflect the trust implicit in its position
by:
– applying and enforcing systems, practices, and procedures that 5.5.4. Policies applicable to updated Historical resources
protect the confidential information of its Members and their Historical Internet resources that are updated under this policy are subject to the registration requirements as
customers, and specified above.
– ensuring the employment of all staff, or agents, is based upon 5.6. General requirements for requests
an explicit condition of confidentiality regarding such In order to properly evaluate resource requests, APNIC must carefully examine all relevant documentation relating to
information. 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.
APNIC provides for authorization and verification mechanisms Further, based on request the following information may be requested such as equipment invoices and purchase orders,
within the APNIC Whois Database. It is the responsibility of any address space currently held by that applicant (including Historical address space), previous assignments made by
each IR, or end-user, to apply these mechanisms. that applicant (including assignments made from Historical address allocations), and the intended use for the address
space requested.
5.6.2. Equitable processing of requests All documentation should conform to a consistent standard and any estimates and predictions that are documented must be
————————————— realistic and justifiable.
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 5.6.1. Security and confidentiality
information, or clarify relevant issues that are not clear in The documentation, which supports address space requests, involves information that may be highly confidential to the
the initial request. commercial and infrastructure operations of all applicants and their customers. Therefore, APNIC will reflect
the trust implicit in its position by:
Once the errors and omissions are rectified, or the additional * applying and enforcing systems, practices, and procedures that protect the confidential information of its applicants
questions answered, APNIC will deal with the request in the and their customers, and
strict order in which it receives proper documentation. * ensuring the employment of all staff, or agents, is based upon an explicit condition of confidentiality regarding such
information.
APNIC will make all reasonable efforts to maintain a consistent APNIC provides for authorization and verification mechanisms within the APNIC Whois Database. It is the responsibility
and reliable level of service with respect to processing of of each IR, or end-user, to apply these mechanisms.
requests and will maintain a request tracking system for
efficient request management.
To provide fair treatment for all applicants, APNIC will not, 5.6.2. Equitable processing of requests
under any circumstance, provide any special treatment or make APNIC will only process requests that have been completely and properly documented. If the documentation contains errors
exceptions to the standard order of request processing. 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 5.7. Experimental allocations policy
———————————— This Section describes the APNIC policies which apply to requests for Internet resource allocations that are to be used
This Section describes the APNIC policies which apply to requests for experimental purposes.
for Internet resource allocations that are to be used for
experimental purposes.
5.7.1. Introduction 5.7.1. Introduction
——————- As the Internet continues to expand and evolve, there is an increased need for technologies and practices to be refined
As the Internet continues to expand and evolve, there is an and standardized.
increased need for technologies and practices to be refined and
standardized.
To achieve this, it is often necessary to experiment with To achieve this, it is often necessary to experiment with proposed technologies to evaluate their interaction with the
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
installed base of the Internet. For a small proportion of these or assign Internet resources on a temporary basis.
experimental activities, it may be necessary to allocate or
assign Internet resources on a temporary basis.
5.7.1.1. Scope and goal 5.7.1.1. Scope and goal
———————– This section describes policies for the responsible management of global Internet resources in the Asia Pacific region,
This section describes policies for the responsible specifically relating to the temporary allocation and assignment of Internet resources for experimental purposes.
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 The goal of this policy is to provide fair access to Internet resources for genuine researchers, to encourage development
Internet resources for genuine researchers, to encourage of new technologies and refinement of standards.
development of new technologies and refinement of standards.
5.7.2. Allocations for experimental purposes 5.7.2. Allocations for experimental purposes
——————————————– APNIC will allocate public Internet resources to be used for experimental purposes. These experimental allocations are
APNIC will allocate public Internet resources to be used for subject to the eligibility criteria, conditions, and restrictions described below. An experiment is eligible for an
experimental purposes. These experimental allocations are allocation if it meets the criteria described in either Section 5.7.2.1 or Section 5.2.7.2 below.
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 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
Experiments are eligible for allocations if they are Section 6.0 below.
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 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
Experiments may be eligible for an allocation if they are “Experimental”. The requestors must specifically refer to this RFC, describe their participation in the experiment,
described in a document that is available free of charge and and provide a summary of the experiment which details their requirement for Internet resources.
publicly accessible in a forum approved by APNIC.
Under this criterion, APNIC has the sole discretion to 5.7.2.2. Alternative publication approved by APNIC
determine whether such an experiment is eligible. To do so, Experiments may be eligible for an allocation if they are described in a document that is available free of charge and
APNIC may liaise with IETF working groups, other standards publicly accessible in a forum approved by APNIC.
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 Under this criterion, APNIC has the sole discretion to determine whether such an experiment is eligible. To do so,
document, describe their participation in the experiment, APNIC may liaise with IETF working groups, other standards bodies, RIRs, or Internet experts to evaluate the status
and provide a summary of the experiment which details their of the document, the validity of the experiment it describes, and the Internet resource requirements of the experiment.
requirement for Internet resources.
5.7.3. Experimental allocations 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.1. Public disclosure of experiment 5.7.3. Experimental allocations
—————————————-
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 5.7.3.1. Public disclosure of experiment
provisions are specifically excluded from these requests. It is a condition for experimental allocations that all material details of the experiments are published free of charge
Although APNIC may consider requests for certain aspects of and without any constraints on their disclosure or use. The details to be published include the objectives of the experiment,
a project to be subject to a non-disclosure agreement, it the practices, and any other relevant details. At the completion of the experiment, the results must be published under
will not agree to any restrictions on the public benefit to the same terms.
be gained from any experiments.
APNIC may publish and maintain public archives of all To this extent, the terms of APNIC’s regular non-disclosure provisions are specifically excluded from these requests.
experiments which receive allocations under this policy. 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.
5.7.3.2. Size of IP allocations APNIC may publish and maintain public archives of all experiments which receive allocations under this policy.
——————————-
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 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
During the request process, APNIC may comment on the minimum allocation size, unless the nature of the experiment specifically requires an allocation of a different size.
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, 5.7.3.3. APNIC input on proposed experiment
then APNIC will seek advice from the IETF or another During the request process, APNIC may comment on the objectives of the experiment with regards to the requested amount
relevant standards body involved in publishing the of numbering resources. APNIC may also propose changes to the size of the requested allocation.
experiment.
5.7.3.4. Duration of allocation licenses 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.
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 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
At the end of the initial license period, the holder of the one year.
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 5.7.3.5. Extension of license
considered under this policy will be concluded without At the end of the initial license period, the holder of the resources may apply to have the license extended, to meet
extension of the original license. the objectives of the experiment, as publicly documented.
5.7.4. Registration It is intended that the majority of the experiments to be considered under this policy will be concluded without
——————- extension of the original license.
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 5.7.4. Registration
——————————————————- All experimental allocations will be registered in the APNIC Whois Database. The registration details will indicate
APNIC may revoke an experimental allocation if the resources the temporary nature of these allocations.
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 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
Experimental allocations are available to APNIC Members only. for any activities not documented in the original request.
New Members wishing to receive experimental allocations may join 5.7.5. Fees for experimental allocations
at the Associate Member level. Their request for an experimental Experimental allocations are available to APNIC account holders only.
allocation will not be subject to the “IP resource application New applicants wishing to receive experimental allocation will need to become an APNIC account holder. If you are already
fee”. 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 Part 2: IPv4 Policy
6.0. Initial IPv4 delegations 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, non-103/8 resources waiting list was abolished
and only new APNIC account holders are eligible to receive IPv4 delegation
from the remaining IPv4 pool.
Note: A waiting list will be created once APNIC runs out of all IPv4
addresses. Any requests received from the new APNIC account holders 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 6.1. Minimum and maximum IPv4 delegations
immediate need for a /24, The current minimum delegation size for IPv4 is a /24 (256 addresses).
– Have complied with applicable policies in managing all address Since Thursday, 28 February 2019, each APNIC account holder is only eligible to receive IPv4 address delegations totalling
space previously delegated to it (including Historical a maximum /23 from the APNIC 103/8 IPv4 address pool.
delegations), and
– Demonstrate a detailed plan for use of at least a /23 within
a year
6.2.2. IPv4 for multihoming
—————————
An organization is eligible to receive an IPv4 delegation if:
– it is currently multihomed, or On Tuesday, 2 July 2019, non-103/8 resources waiting list was abolished and only new APNIC account holders are eligible to
– it is currently using at least a /24 from its upstream receive IPv4 delegation from the remaining IPv4 pool.
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 Note: A waiting list will be created once APNIC runs out of all IPv4 addresses. Any requests received from the new applicants
demonstrate that they are able to use 25% of the requested for IPv4 resources will be put on this waiting list on a first come first request. APNIC will maintain one IPv4 pool for
addresses immediately and 50% within one year. all recovered as well as IANA delegated address space and this pool will be used to provide IPv4 resources to the waiting
list requests.
6.2.3. IPv4 for critical infrastructure To receive delegations from this pool, they must demonstrate their eligibility by meeting the criteria specified below.
—————————————
The following critical infrastructure networks, if operating in
the Asia Pacific region, are eligible to receive a delegation:
– Root domain name system (DNS) server 6.2. IPv4 request criteria
– Global top level domain (gTLD) nameservers To qualify for an IPv4 address delegation from APNIC, requestors must demonstrate their eligibility under one of the following
– Country code TLD (ccTLDs) nameservers four criteria.
– IANA * IPv4 for LIRs
– Regional Internet Registry (RIRs), and * IPv4 for multihoming
– National Internet Registry (NIRs) * IPv4 for critical infrastructure
* IPv4 for Internet Exchange Points
Delegations to critical infrastructure are available only to the 6.2.1. IPv4 for LIRs
actual operators of the network infrastructure performing such To be eligible for an initial IPv4 delegation, an LIR must:
functions. Registrar organizations that do not actually host the * Have used a /24 from their upstream provider or demonstrate an immediate need for a /24,
network housing the registry infrastructure will not be eligible * Have complied with applicable policies in managing all address space previously delegated to it (including Historical
under this policy. delegations), and
* Demonstrate a detailed plan for use of at least a /23 within a year
6.2.4. IPv4 for Internet Exchange Points 6.2.2. IPv4 for multihoming
—————————————- An applicant is eligible to receive an IPv4 delegation if:
Internet Exchange Points (IXP) are eligible to receive a * currently multihomed, or
delegation from APNIC to be used exclusively to connect the IXP * currently using at least, a /24 from its upstream provider and intends to be multihomed, or
participant devices to the Exchange Point. * 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.
Global routability of the delegation is left to the discretion 6.2.3. IPv4 for critical infrastructure
of the IXP and its participants. 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.
7.0. Subsequent IPv4 delegations 7.0. Subsequent IPv4 delegations
After receiving an initial LIR delegation, all subsequent delegations After receiving an initial LIR delegation, all subsequent delegations will depend on the following:
will depend on the following: – The LIR’s verified usage rate (which is * The LIR’s verified usage rate (which is the rate at which the LIR made delegations from relevant past address space,
the rate at which the LIR made delegations from relevant past address including Historical delegations)
space, including Historical delegations) * Their documented plans for address space, and
* Their degree of compliance with APNIC policies with respect to relevant past delegations.
– Their documented plans for address space, and Based on these factors, APNIC and NIRs will delegate address space to meet the LIR’s estimated needs for a period up to
– Their degree of compliance with APNIC policies with respect to one year up to the maximum allowed delegation under Section 6.1.
relevant past delegations. 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.
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 east eighty
percent of the total address space it holds. This is referred to as
the “eighty percent rule”.
7.1. 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.
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.
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.
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 7.1. Prior delegations to be used first
infrastructures are merged, then APNIC will not continue to make An LIR is not eligible to receive a subsequent delegation from APNIC until its current customer delegations account for
separate allocations to both. This situation will invalidate the at least eighty percent of the total address space it holds. This is referred to as the “eighty percent rule”.
membership agreement of the organization that is effectively
subsumed.
When assessing the status of IPv4 delegations, APNIC requires 7.2. Special circumstances – large delegations
full disclosure of all address space held by all of the entities An LIR may request an exception to the eighty percent rule if it needs to make a single delegation that is larger than
in question. If full disclosure is not made, then APNIC will the amount of pace it has remaining.
consider any delegations to be invalid and will require that
they be returned.
Part 3: IPv6 Policy Part 3: IPv6 Policy
9.0. IPv6 allocations 8.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:
1. The organization provides comprehensive documentation of planned
IPv6 infrastructure which would require a larger allocation; or
2. The organization provides comprehensive documentation of all of
the following:
– its existing IPv4 infrastructure and customer base,
– its intention to provide its existing IPv4 services via IPv6,
and
– 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 8.1. Minimum IPv6 allocation
from APNIC, but have no IPv6 space, can qualify for an The minimum allocation size for IPv6 address space is /32.
appropriately sized IPv6 block under the matching IPv6 policy. Applicants that meet the initial allocation criteria are eligible to receive the minimum allocation. Larger initial
For example, a Member that has received an IPv4 IXP assignment allocations may be justified if:
will be eligible to receive an IPv6 IXP assignment. 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.
The size of the IPv6 delegation for Members that meet this 8.2. Initial IPv6 allocations
criteria will be based on the following:
– A Member that has an IPv4 allocation is eligible for a 8.2.1. Account holders with existing IPv4 space
/32 IPv6 address block. Subject to Section 8.1., existing IPv4 address space may be considered in determining the initial IPv6 allocation
– A Member that has an IPv4 assignment is eligible for a size. APNIC applies a minimum size for IPv6 allocations to facilitate prefix-based filtering.
/48 IPv6 address block.
If an APNIC Member wishes to receive an initial allocation or APNIC account holders that have been delegated an IPv4 address block from APNIC, but have no IPv6 space, can qualify
assignment larger than the sizes described above, the Member for an appropriately sized IPv6 block under the matching IPv6 policy. For example, an account holder that has received
will need to apply under the alternative criteria described an IPv4 IXP assignment will be eligible to receive an IPv6 IXP assignment.
in Section 9.2.2. and Section 10.1 below. 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.
9.2.2. Account holders without existing IPv4 space 8.2.2. Account holders without existing IPv4 space
————————————————– To qualify for an initial allocation of IPv6 address space, an account holder must:
To qualify for an initial allocation of IPv6 address space, an 1. Be an LIR
organization must: 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.
1. Be an LIR Private networks (those not connected to the public Internet) may also be eligible for an IPv6 address space allocation
2. Not be an end site provided they meet equivalent criteria to those listed above.
3. 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 8.3. Subsequent IPv6 allocations
default one (as indicated in 9.2.1.) is requested, will be based Account holders that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the
on the number of users, the extent of the organization’s following policies.
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) 8.3.1. Existing IPv6 address resource holders
may also be eligible for an IPv6 address space allocation Resource holders that received /35 IPv6 allocation under the previous IPv6 address policy [RIRv6-Policies] are
provided they meet equivalent criteria to those listed above. 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.
9.3. Subsequent IPv6 allocations 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
Organizations that hold an existing IPv6 allocation may receive a for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in this document.
subsequent allocation in accordance with the following policies.
9.3.1. Existing IPv6 address space holders 8.3.2. Applied HD-Ratio
—————————————— Subsequent allocation will be provided when an ISP/LIR satisfies the evaluation threshold of past address utilization
Organizations that received /35 IPv6 allocation under the in terms of the number of sites in units of /56 assignments.
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 9.2.2.
The /32 address block will contain the already allocated smaller The HD-Ratio [RFC 3194] is used to determine the utilization thresholds that justify the allocation of additional address
address block (one or multiple /35 address blocks in many cases) as described below.
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 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
Subsequent allocation will be provided when an organization an acceptable utilization value for a given address block size.
(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 8.3.3. Alternative allocation criteria
thresholds that justify the allocation of additional address as Alternatively, a subsequent allocation may be provided where an ISP/LIR can demonstrate a valid reason for requiring
described below. 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
The HD-Ratio value of 0.94 is adopted as indicating an 8.3.4. Size of subsequent allocation
acceptable address utilization for justifying the allocation of When an account holder has achieved an acceptable utilization for its allocated address space, it is immediately
additional address space. Appendix A provides a table showing eligible to obtain an additional allocation that results in a doubling of the address space allocated to it.
the number of assignments that are necessary to achieve an Where possible, except where separate disaggregated ranges are requested for multiple discrete networks, the
acceptable utilization value for a given address block size. allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit
to the left.
9.3.3. Alternative allocation criteria 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
Alternatively, a subsequent allocation may be provided where an and geographical structuring of the account holder�s operations, the segmentation of infrastructure for security
organization (ISP/LIR) can demonstrate a valid reason for and the planned longevity of the allocation).
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 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.3.4. Size of subsequent allocation 9.1. Criteria for IPv6 Assignments
———————————— To qualify for an IPv6 assignment from APNIC, requestors must demonstrate their eligibility under one of the
When an organization has achieved an acceptable utilization for following four criteria.
its allocated address space, it is immediately eligible to * IPv6 for multihoming
obtain an additional allocation that results in a doubling of * IPv6 for critical infrastructure
the address space allocated to it. * IPv6 for Internet Exchange Points
* Provider Independent IPv6 assignment
Where possible, except where separate disaggregated ranges are 9.1.1. IPv6 for multihoming
requested for multiple discrete networks, the allocation will be An applicant is eligible to receive a portable assignment from APNIC if it is currently, or plans to be, multihomed.
made from an adjacent address block, meaning that its existing The minimum assignment made under these terms is /48.
allocation is extended by one bit to the left.
If an organization needs more address space, it must provide 9.1.2. IPv6 critical infrastructure
documentation justifying its new requirements. The allocation The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to receive a
size, will be based on the new needs (the number of users, the portable assignment:
extent of the organization’s infrastructure, the hierarchical * Root domain name system (DNS) server;
and geographical structuring of the organization, the * Global top-level domain (gTLD) nameservers;
segmentation of infrastructure for security and the planned * Country code TLD (ccTLDs) nameservers;
longevity of the allocation). * 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.
10.0. IPv6 assignments 9.1.3. IPv6 for Internet Exchange Points
APNIC Members that have been delegated an IPv4 address block from APNIC, Internet Exchange Points are eligible to receive a portable assignment from APNIC to be used exclusively to
but have no IPv6 space, can qualify for an appropriately sized IPv6 connect the IXP participant devices to the Exchange Point.
block under the matching IPv6 policy. For example, a Member that has The minimum assignment made under these terms is /48.
received an IPv4 IXP assignment will be eligible to receive an IPv6 IXP Global routability of the portable assignment is left to the discretion of the IXP and its participants.
assignment.
10.1. Criteria for IPv6 Assignments 9.1.4. Provider Independent IPv6 assignment
———————————– Requests for Provider Independent assignments must include a detailed plan of intended usage of the proposed
To qualify for an IPv6 assignment from APNIC, requestors must address block over at least the 12 months following the allocation.
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 9.1.4.1. Initial assignment
—————————- Applicants are eligible for an IPv6 Provider Independent delegation if they are able to demonstrate a valid
An organization is eligible to receive a portable assignment reason that an assignment from their ISP, or LIR, is not suitable. For guidelines on what will be considered
from APNIC if it is currently, or plans to be, multihomed. a valid technical or other reason, see “APNIC guidelines for IPv6 allocation and assignment requests”.
http://www.apnic.net/ipv6-guidelines
The minimum size of the assignment is a /48 per end-site. The considerations of Section 5.2.3.3 Assignment of
multiple /48s to a single end-site, must be followed if multiple /48s are requested.
http://www.apnic.net/ipv6-guidelines
The minimum assignment made under these terms is /48. 9.1.4.2. Subsequent assignment
Subsequent Provider Independent assignments may be delegated to account holders 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.
10.1.2. IPv6 critical infrastructure Part 4: ASN Policy
————————————
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 10.0. ASN assignments
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 10.1. Evaluation of eligibility
operator. 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.1.3. IPv6 for Internet Exchange Points 10.2. Requesting an ASN
—————————————– Applicants may request an ASN from either APNIC or their relevant NIR.
Internet Exchange Points are eligible to receive a portable The applicant may request an ASN for use in its own network, or for the purposes of providing the ASN to one of
assignment from APNIC to be used exclusively to connect the IXP their customers, subject to the terms of Sections 10.3. and Section 10.4. below.
participant devices to the Exchange Point.
The minimum assignment made under these terms is /48. 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.
Global routability of the portable assignment is left to the 10.4. Providing ASN to customer
discretion of the IXP and its participants. 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.1.4. Provider Independent IPv6 assignment 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
Requests for Provider Independent assignments must include a and operates the AS Number assignments from an undifferentiated four-byte AS Number pool.
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 Part 5: Transfer Policy
—————————-
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”.
http://www.apnic.net/ipv6-guidelines 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.
The minimum size of the assignment is a /48 per end-site. The considerations of During that time, if the reason for the original request is no longer valid, the resources must be returned to
Section 5.2.4.3 Assignment of multiple /48s to a single end-site, must be APNIC as required in Section 4.0. Resource License of this document.
followed if multiple /48s are requested.
http://www.apnic.net/ipv6-guidelines 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.
10.1.4.2. Subsequent assignment 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.
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.
11.0. Transfer of IPv6 resources 11.1. IPv4 transfers within the APNIC region
APNIC will only recognize the transfer or IPv6 addresses as the result APNIC will process and record IPv4 address transfer requests between current APNIC account holders subject to the
of Merger & Acquisition activity. The following conditions and following conditions.
consequences apply.
11.1. Updating registration details 11.1.1. Conditions on the space to be transferred
———————————– The minimum transfer size is a /24. The address block must be:
If an LIR changes ownership (due to a merger, sale, or takeover), * In the range of addresses administered by APNIC
then the new entity must register any changes to its network usage * Allocated or assigned to a current APNIC account holder
and contact personnel. If the effect of the ownership change is that * The address block will be subject to all current APNIC policies from the time of transfer.
the LIR changes name, then the LIR must provide to APNIC relevant * Addresses delegated from the 103/8 free pool cannot be transferred for a minimum of five years after the original
legal documentation supporting the name change. delegation.
11.2. Effect on membership agreement 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
If an LIR changes ownership then the new entity should advise APNIC dispute as to the status of those resources.
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 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
Following ownership change of an LIR, APNIC will review the status demonstrate a detailed plan for the use of the transferred resource within 24 months. Recipients that already hold
of any allocations that are held by the new entity or entities, with IPv4 resources must:
regard to the practical effect on their infrastructures. * 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.
If the practical effect of ownership change is that the 11.2. Inter-RIR IPv4 address transfers
infrastructures are merged, then APNIC will not continue to make APNIC will process and record inter-RIR IPv4 address transfers only when the counterpart RIR has an inter-RIR transfer
separate allocations to both. This situation will invalidate the policy that permits the transfer of address space between APNIC and its own region.
membership agreement of the LIR that is effectively subsumed. 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.
When assessing the status of allocations, APNIC requires full 11.2.1. Conditions on the space to be transferred
disclosure of all address space held by all of the entities in The minimum transfer size is a /24.
question. If full disclosure is not made, then APNIC will consider The IPv4 address space to be transferred should be under the management of the RIR at which the transfer source holds
any allocations to be invalid and will require that they be an account and the authentic holder of the space should match with the source without any disputes.
returned. 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.
Part 4: ASN Policy 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.
12.0. ASN assignments 11.2.3. Conditions on the recipient of the transfer
12.1. Evaluation of eligibility The conditions on the recipient of the transfer will be defined by the RIR where the recipient holds an account.
——————————- This means:
An organization is eligible for an ASN assignment if: * For transfers to an APNIC recipient, the conditions defined in Section 11.1.3. will apply.
– it is currently multihomed, or * Where the recipient is in another region, the conditions on the recipient as defined in the counterpart RIR’s
– has the need to interconnect with other AS. transfer policy at the time of the transfer will apply.
An organization will also be eligible if it can demonstrate that it 11.3. Transfer of Historical Internet resources
will meet the above criteria upon receiving an ASN (or within a APNIC will process and record the transfer of Historical IPv4 resources as defined in Section 2.5.2.
reasonably short time thereafter). 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.
Requests for ASNs under these criteria will be evaluated using the 11.3.1. Transfer procedure
guidelines described in RFC1930 ‘Guidelines for the creation, All transfers of Historical Internet resources to current APNIC account holders made under this policy are
selection and registration of an Autonomous System’ (AS). 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.
12.2. Requesting an ASN 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.
Organizations may request an ASN from either APNIC or their relevant For more information on transferring historical Internet resources, please see the transfer page of the APNIC
NIR. website.
https://www.apnic.net/transfer
The requesting organization may request an ASN for use in its own 11.3.2. Policies applicable to transferred Historical resources
network, or for the purposes of providing the ASN to one of its All resources transferred under this policy are subject to the provisions of all normal address management
customers, subject to the terms of Sections 12.3. and 12.4. below. 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.
12.3. Using ASN for own network 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.
Assignments to organizations that will use the ASN in their own
network are subject to the following additional terms:
1. The requesting organization is responsible for maintaining the
registration described in Section 5.3.3.
2. 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 12.0. ASN Transfers
——————————- Autonomous System Numbers may be transferred in accordance with the following policies. APNIC does not recognize
Assignments to organizations that will provide the ASN to one of its transfers outside this policy and requires account holders holding such transfers to return them.
customers are subject to the following additional terms: APNIC recognizes there will be situations where ASNs may be transferred between:
1. The customer that will actually use the ASN must meet the * Current APNIC account holders
criteria in Section 12.0. * Current APNIC account holders and organizations in other RIR regions
2. The requesting organization is responsible for maintaining the * Organizations through a merger, acquisition, or takeover
registration described in Section 5.3.3. on behalf of the
customer.
3. 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.
4. 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 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
On 1 January 2010 APNIC ceased to make any distinction between following conditions.
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.
13.0.ASN Transfers 12.1.1. Conditions on resource
Autonomous System Numbers may be transferred in accordance with the The ASN must be:
following policies. APNIC does not recognize transfers outside this * In the range administered by APNIC
policy and require organizations holding such transfers to return them. * Assigned to a current APNIC account holder
* The ASN will be subject to all current APNIC policies from the time of transfer
APNIC recognizes there will be situations where ASNs may be transferred 12.1.2. Conditions on source of the transfer
between: The source entity must be the currently registered holder of the ASN, and not be involved in any dispute
– Current APNIC account holders as to the status of the resource.
– 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 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
APNIC will process and record ASN transfer requests between current of an ASN.
APNIC account holders subject to the following conditions.
13.1.1. Conditions on resource 12.2. Inter-RIR ASN transfers
—————————— APNIC will recognize inter-RIR ASN transfers only when the counterpart RIR has an inter-RIR transfer policy
The ASN must be: that permits the transfer of ASNs between APNIC and its own region.
– 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 APNIC will process and record ASN transfer requests between current APNIC account holders and organizations
——————————————– in other RIR regions subject to the following conditions.
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 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
The recipient entity will be subject to current APNIC policies account and the authentic holder of the space should match with the source without any disputes.
and must meet the criteria for the assignment of an ASN.
13.2. Inter-RIR ASN transfers 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
APNIC will recognize inter-RIR ASN transfers only when the an account. This means:
counterpart RIR has an inter-RIR transfer policy that permits the * For transfers from an APNIC source, the source entity must be the currently registered resource holder of
transfer of ASNs between APNIC and its own region. 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.
APNIC will process and record ASN transfer requests between current 12.2.3. Conditions on the recipient of the transfer
APNIC account holders and organizations in other RIR regions subject The conditions on the recipient of the transfer will be defined by the RIR where the recipient holds an account.
to the following conditions. 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.2.1. Conditions on the space to be transferred 13.0. IPv6 Transfers
————————————————- APNIC will only recognize the transfer or IPv6 addresses as the result of Merger & Acquisition activity.
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 14.0. Mergers & Acquisitions
———————————————— APNIC will process and record the transfer of ASNs, IPv6, and IPv4 resources as the result of merger or
The conditions on the source of the transfer will be defined by acquisition.
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 Addresses delegated from the 103/8 IPv4 free pool cannot be transferred for a minimum of five years after the
————————————————— original delegation.
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 The following conditions and consequences apply:
—————————-
APNIC will recognize the transfer of ASNs as the result of merger or
acquisition.
13.3.1. Updating registration details 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
If an organization changes ownership (due to a merger, sale, or to its network usage and contact personnel. If the effect of the ownership change is that the LIR changes name,
takeover), then the new entity must register any changes to its then the LIR must provide to APNIC relevant legal documentation supporting the name change.
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.
13.3.2. Effect on membership agreement 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
If an organization changes ownership then the new entity should transferable from one entity to another; however, if the effect of the ownership change is that the LIR becomes
advise APNIC of the change. APNIC membership is not transferable a subsidiary of another entity, and the infrastructures of the respective entities remain fully independent,
from one entity to another; however, if the effect of the then the membership agreement may continue.
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.
13.3.3. Consequences for allocations 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
Following a change in ownership, APNIC will review the status of entity or entities, with regard to the practical effect on their infrastructures.
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 If the practical effect of ownership change is that the infrastructures are merged, then APNIC will not continue
infrastructures are merged, then APNIC will not continue to make to make separate allocations to both. This situation will invalidate the membership agreement of the LIR that
separate allocations to both. This situation will invalidate the is effectively subsumed.
membership agreement of the organization that is effectively
subsumed.
When assessing the status of ASN assignments, APNIC requires When assessing the status of allocations, APNIC requires full disclosure of all address space held by all of the
full disclosure of all resources held by all of the entities in entities in question. If full disclosure is not made, then APNIC will consider any allocations to be invalid and
question. If full disclosure is not made, then APNIC will will require that they be returned.
consider any delegations to be invalid and will require that
they be returned.
Appendix A: HD-Ratio 15. Appendix A: HD-Ratio
The utilization threshold T, expressed as a number of individual /56 The utilization threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6 prefix P,
prefixes to be allocated from IPv6 prefix P, can be calculated as: can be calculated as:
T=2((56-P)*HD) T=2((56-P)*HD)
Thus, the utilization threshold for an organization requesting Thus, the utilization threshold for an account holder requesting subsequent allocation of IPv6 address block is
subsequent allocation of IPv6 address block is specified as a function specified as a function of the prefix size and target HD-Ratio. This utilization refers to the allocation of /56s
of the prefix size and target HD-Ratio. This utilization refers to the to end sites, and not the utilization of those /56s within those end sites. It is an address allocation utilization
allocation of /56s to end sites, and not the utilization of those /56s ratio and not an address assignment utilization ratio.
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 This document adopts an HD-Ratio of 0.94 as the utilization threshold for IPv6 address space allocations.
for IPv6 address space allocations.
The following table provides equivalent absolute and percentage address The following table provides equivalent absolute and percentage address utilization figures for IPv6 prefixes,
utilization figures for IPv6 prefixes, corresponding to an HD-Ratio of corresponding to an HD-Ratio of 0.94.
0.94.
P 56-P Total /56s Threshold Util % P 56-P Total /56s Threshold Util %
56 0 1 1 100.0 56 0 1 1 100.0
55 1 2 2 95.9 55 1 2 2 95.9
54 2 4 4 92.0 54 2 4 4 92.0
53 3 8 7 88.3 53 3 8 7 88.3
52 4 16 14 84.7 52 4 16 14 84.7
51 5 32 26 81.2 51 5 32 26 81.2
50 6 64 50 77.9 50 6 64 50 77.9
 End of changes. 268 change blocks. 
1950 lines changed or deleted 1112 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/