|
apnic-127-v001.txt |
|
apnic-127-v002.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: 001 |
|
Version: 002 |
|
|
Date of original publication: 5 March 2015 |
|
Date of original publication: 5 March 2015 |
|
|
|
Date of this version: 5 March 215 |
|
Date of this version: 10 November 2015 |
|
|
Review scheduled: n/a |
|
Review scheduled: n/a |
|
|
|
Obsoletes: apnic-089, apnic-094 apnic-109, |
|
Obsoletes: apnic-127-v001 |
|
|
apnic-116, apnic-123, apnic-124, |
|
|
|
|
apnic-125 |
|
|
|
|
Status: Active |
|
Status: Active |
|
|
|
Comments: Combines all APNIC resource policies |
|
Comments: Reduces duplication and contradictions |
|
|
into a single document. |
|
in combined resource policies. |
|
|
|
|
Corrects typographical errors. |
|
|
———————————————————————- |
|
———————————————————————- |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
skipping to change at line 89 |
|
skipping to change at line 88 |
|
|
3.2.10. Minimum practical delegation |
|
3.2.10. Minimum practical delegation |
|
|
3.2.11. Slow start mechanism |
|
3.2.11. Slow start mechanism |
|
|
3.2.11.1. Exceptions to slow start |
|
3.2.11.1. Exceptions to slow start |
|
|
3.3. Organizations seeking address space from multiple IRs |
|
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.1.1. Review |
|
|
4.1.2. Validity of delegations |
|
4.1.2. Validity of delegations |
|
|
4.2. Closure and recovery |
|
4.2. Closure and recovery |
|
|
|
4.2.1. Recovery of unused historical address space |
|
4.2.1. Recovery of unused historical resources |
|
|
4.2.2. Recovery of unused historical ASNs |
|
|
|
|
|
|
|
|
|
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.1.1. Reservation for future uses |
|
|
5.1.2. Sparse allocation framework |
|
5.1.2. Sparse allocation framework |
|
|
5.1.3. IPv4 addresses returned to APNIC |
|
5.1.3. IPv4 addresses returned to APNIC |
|
|
5.2. LIR address space management |
|
5.2. LIR address space management |
|
|
5.2.1. Assignment window for LIRs |
|
5.2.1. Assignment window for LIRs |
|
|
5.2.2. IPv4 address usage estimates |
|
5.2.2. IPv4 address usage estimates |
|
|
5.2.3. IPv4 Delegations to downstream IRs |
|
5.2.3. IPv4 Delegations to downstream IRs |
|
|
5.2.3.1. Effect of delegation to downstream IRs on upstream LIR’s |
|
5.2.3.1. Effect of delegation to downstream IRs on upstream LIR’s |
|
|
usage rate |
|
usage rate |
|
|
5.2.4. Policies for LIR IPv6 allocation and assignment |
|
5.2.4. Policies for LIR IPv6 allocation and assignment |
|
|
5.2.4.1. LIR-to-ISP allocation |
|
5.2.4.1. LIR-to-ISP allocation |
|
|
5.2.4.2. Assignment address space size |
|
5.2.4.2. Assignment address space size |
|
|
5.2.4.3. Assignment of multiple /48s to a single end site |
|
5.2.4.3. Assignment of multiple /48s to a single end site |
|
|
5.2.4.4. Assignment to operator’s infrastructure |
|
5.2.4.4. Assignment to operator’s infrastructure |
|
|
5.3. Registration requirements |
|
5.3. Registration requirements |
|
|
5.3.1. Requirements for IPv4 addresses |
|
5.3.1. Requirements for IPv4 addresses |
|
|
5.3.1.1. Updating registration details |
|
5.3.1.1. Updating registration details |
|
|
|
5.3.1.2. Registering contact persons |
|
|
|
|
5.3.2. Registration requirements for IPv6 addresses |
|
5.3.2. Registration requirements for IPv6 addresses |
|
|
5.3.3. Registration requirements for AS Numbers |
|
5.3.3. Registration requirements for AS Numbers |
|
|
5.3.3.1. Registering routing policy |
|
5.3.3.1. Registering routing policy |
|
|
5.3.3.2. Updating registration details |
|
5.3.3.2. Updating registration details |
|
|
|
|
|
5.3.4. Registering contact persons |
|
|
5.4. Reverse lookup |
|
5.4. Reverse lookup |
|
|
5.4.1. Responsibility to maintain IPv4 in-addr.arpa records |
|
5.4.1. Responsibility to maintain IPv4 in-addr.arpa records |
|
|
5.4.2. IPv6 reverse lookup |
|
5.4.2. IPv6 reverse lookup |
|
|
5.5. Managing Historical resources |
|
5.5. Managing Historical resources |
|
|
5.5.1. Utilization of Historical IPv4 address space |
|
5.5.1. Utilization of Historical IPv4 address space |
|
|
5.5.2. Protecting Historical records in the APNIC Whois Database |
|
5.5.2. Protecting Historical records in the APNIC Whois Database |
|
|
5.5.3. Procedure for updating Historical registrations |
|
5.5.3. Procedure for updating Historical registrations |
|
|
5.5.4. Policies applicable to updated Historical resources |
|
5.5.4. Policies applicable to updated Historical resources |
|
|
5.6. General requirements for requests |
|
5.6. General requirements for requests |
|
|
5.6.1. Documentation |
|
5.6.1. Documentation |
|
|
5.6.2. Security and confidentiality |
|
5.6.2. Security and confidentiality |
|
|
5.6.3. Equitable processing of requests |
|
5.6.3. Equitable processing of requests |
|
|
|
5.6.3.1. Processing dependent on correct documentation |
|
|
|
|
5.7. Experimental allocations policy |
|
5.7. Experimental allocations policy |
|
|
5.7.1. Introduction |
|
5.7.1. Introduction |
|
|
5.7.1.1. Scope and goal |
|
5.7.1.1. Scope and goal |
|
|
5.7.2. Allocations for experimental purposes |
|
5.7.2. Allocations for experimental purposes |
|
|
5.7.2.1. Publication of an experimental RFC |
|
5.7.2.1. Publication of an experimental RFC |
|
|
5.7.2.2. Alternative publication approved by APNIC |
|
5.7.2.2. Alternative publication approved by APNIC |
|
|
5.7.3. Experimental allocations |
|
5.7.3. Experimental allocations |
|
|
5.7.3.1. Public disclosure of experiment |
|
5.7.3.1. Public disclosure of experiment |
|
|
5.7.3.2. Size of IP allocations |
|
5.7.3.2. Size of IP allocations |
|
|
5.7.3.3. APNIC input on proposed experiment |
|
5.7.3.3. APNIC input on proposed experiment |
|
|
|
|
|
|
|
skipping to change at line 193 |
|
skipping to change at line 190 |
|
|
9.2. Initial IPv6 allocations |
|
9.2. Initial IPv6 allocations |
|
|
9.2.1. Account holders with existing IPv4 space |
|
9.2.1. Account holders with existing IPv4 space |
|
|
9.2.2. Account holders without existing IPv4 space |
|
9.2.2. Account holders without existing IPv4 space |
|
|
9.3. Subsequent IPv6 allocations |
|
9.3. Subsequent IPv6 allocations |
|
|
9.3.1. Existing IPv6 address space holders |
|
9.3.1. Existing IPv6 address space holders |
|
|
9.3.2. Applied HD-Ratio |
|
9.3.2. Applied HD-Ratio |
|
|
9.3.3. Alternative allocation criteria |
|
9.3.3. Alternative allocation criteria |
|
|
9.3.4. Size of subsequent allocation |
|
9.3.4. Size of subsequent allocation |
|
|
|
|
|
|
|
10.0. IPv6 assignments |
|
10.0. IPv6 assignments |
|
|
|
10.1. Criteria for IPv6 Assignments |
|
10.1. Criteria for IPv6 Assignments |
|
|
10.1.1. IPv6 for multihoming |
|
10.1.1. IPv6 for multihoming |
|
|
10.1.2. IPv6 critical infrastructure |
|
10.1.2. IPv6 critical infrastructure |
|
|
10.1.3. IPv6 for Internet Exchange Points |
|
10.1.3. IPv6 for Internet Exchange Points |
|
|
10.1.4. Provider Independent IPv6 assignment |
|
10.1.4. Provider Independent IPv6 assignment |
|
|
10.1.4.1. Initial assignment |
|
10.1.4.1. Initial assignment |
|
|
10.1.4.2. Subsequent assignment |
|
10.1.4.2. Subsequent assignment |
|
|
|
|
|
|
|
11.0. Transfer of IPv6 resources |
|
11.0. Transfer of IPv6 resources |
|
|
|
11.1. Updating registration details |
|
11.1. Updating registration details |
|
|
11.2. Effect on membership agreement |
|
11.2. Effect on membership agreement |
|
|
11.3. Consequences for allocations |
|
11.3. Consequences for allocations |
|
|
|
|
|
|
|
Part 4: ASN Policy |
|
Part 4: ASN Policy |
|
|
—————— |
|
—————— |
|
|
|
|
|
|
|
12.0. ASN assignments |
|
12.0. ASN assignments |
|
|
|
12.1. Evaluation of eligibility |
|
12.1. Evaluation of eligibility |
|
|
12.2. Requesting an ASN |
|
12.2. Requesting an ASN |
|
|
12.3. Using ASN for own network |
|
12.3. Using ASN for own network |
|
|
12.4. Providing ASN to customer |
|
12.4. Providing ASN to customer |
|
|
12.5. Two-byte only and four-byte AS Numbers |
|
12.5. Two-byte only and four-byte AS Numbers |
|
|
|
|
|
|
|
13.0. ASN Transfers |
|
13.0. ASN Transfers |
|
|
|
13.1. Transfers of IPv4 addresses between APNIC account holders |
|
13.1. Transfers of ASNs between APNIC account holders |
|
|
13.1.1. Conditions on resource |
|
13.1.1. Conditions on resource |
|
|
13.1.2. Conditions on source of the transfer |
|
13.1.2. Conditions on source of the transfer |
|
|
13.1.3. Conditions on recipient of the transfer |
|
13.1.3. Conditions on recipient of the transfer |
|
|
13.2. Inter-RIR ASN transfers |
|
13.2. Inter-RIR ASN transfers |
|
|
13.2.1. Conditions on the space to be transferred |
|
13.2.1. Conditions on the space to be transferred |
|
|
13.2.2. Conditions on the source of the transfer |
|
13.2.2. Conditions on the source of the transfer |
|
|
13.2.3. Conditions on the recipient of the transfer |
|
13.2.3. Conditions on the recipient of the transfer |
|
|
13.3. Mergers & acquisitions |
|
13.3. Mergers & acquisitions |
|
|
13.3.1. Updating registration details |
|
13.3.1. Updating registration details |
|
|
13.3.2. Effect on membership agreement |
|
13.3.2. Effect on membership agreement |
|
|
13.3.3. Consequences for allocations |
|
13.3.3. Consequences for allocations |
|
|
|
|
|
|
|
|
Appendix A : HD-Ratio |
|
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) for the Asia Pacific. It is responsible for the |
|
Internet Registry (RIR) for the Asia Pacific. It is responsible for the |
|
|
regional distribution of public Internet address space and related |
|
regional distribution of public Internet address space and related |
|
|
resources, including Internet Protocol version 4 (IPv4) address space, |
|
resources, including Internet Protocol version 4 (IPv4) address space, |
|
|
|
|
|
|
|
skipping to change at line 262 |
|
skipping to change at line 259 |
|
|
process facilitated by APNIC. The policies are to be implemented by |
|
process facilitated by APNIC. The policies are to be implemented by |
|
|
APNIC, by National Internet Registries (NIRs), and by Local Internet |
|
APNIC, by National Internet Registries (NIRs), and by Local Internet |
|
|
Registries (LIRs) throughout the region. |
|
Registries (LIRs) throughout the region. |
|
|
|
|
|
|
|
1.1. Scope |
|
1.1. Scope |
|
|
———- |
|
———- |
|
|
This document describes policies for the responsible management of |
|
This document describes policies for the responsible management of |
|
|
global Internet number resources in the Asia Pacific region. |
|
global Internet number resources in the Asia Pacific region. |
|
|
|
|
|
|
|
Specifically, this document focuses on policies relating to: |
|
Specifically, this document focuses on policies relating to: |
|
|
|
– The delegation of Internet Protocol version 4 (IPv4) address space. |
|
– The delegation of Internet Protocol version 4 (IPv4) address |
|
|
|
|
space. |
|
|
– The allocation and assignment of Internet Protocol version 6 |
|
– The allocation and assignment of Internet Protocol version 6 |
|
|
(IPv6) address space. |
|
(IPv6) address space. |
|
|
– The assignment of Autonomous System Numbers (ASNs). |
|
– The assignment of Autonomous System Numbers (ASNs). |
|
|
|
|
|
|
|
1.1.1. Additional guidelines and policies |
|
1.1.1. Additional guidelines and policies |
|
|
—————————————– |
|
—————————————– |
|
|
This document should be read in conjunction with other APNIC |
|
This document should be read in conjunction with other APNIC |
|
|
documents, policies, and guidelines; including those dealing |
|
documents, policies, and guidelines; including those dealing |
|
|
|
with membership and fees as these documents may provide |
|
with membership and fees, as these documents may provide |
|
|
additional operational guidance, or may impose additional |
|
additional operational guidance, or may impose additional |
|
|
requirements on resource holders. |
|
requirements on resource holders. |
|
|
|
|
|
|
|
In addition to the eligibility criteria described in this |
|
In addition to the eligibility criteria described in this |
|
|
document, APNIC may publish other information relating to |
|
document, APNIC may publish other information relating to |
|
|
|
|
|
|
|
Internet number resources, including: |
|
Internet number resources, including: |
|
|
– further descriptions of evaluation procedures; |
|
– further descriptions of evaluation procedures; |
|
|
– summaries of the best current practices that organizations |
|
– summaries of the best current practices that organizations |
|
|
requesting resources will generally be expected to adopt; and |
|
requesting resources will generally be expected to adopt; and |
|
|
|
|
|
|
|
skipping to change at line 451 |
|
skipping to change at line 449 |
|
|
————————— |
|
————————— |
|
|
An Autonomous System (AS) is a connected group of one or more IP |
|
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 |
|
prefixes run by one or more network operators under a single and |
|
|
clearly-defined routing policy. |
|
clearly-defined routing policy. |
|
|
|
|
|
|
|
2.3.1. Autonomous System Number (ASN) |
|
2.3.1. Autonomous System Number (ASN) |
|
|
————————————- |
|
————————————- |
|
|
An Autonomous System Number (ASN) is a unique two- or four-byte |
|
An Autonomous System Number (ASN) is a unique two- or four-byte |
|
|
number associated with an AS. The ASN is used as an identifier |
|
number associated with an AS. The ASN is used as an identifier |
|
|
to allow the AS to exchange dynamic routing information with |
|
to allow the AS to exchange dynamic routing information with |
|
|
|
other Autonomous Systems. Exterior routing protocols, such as |
|
other Autonomous Systems. |
|
|
the Border Gateway Protocol (BGP), require ASNs to exchange |
|
|
|
|
information between networks. |
|
|
|
|
|
|
|
|
|
2.4. Multihomed |
|
2.4. Multihomed |
|
|
————— |
|
————— |
|
|
|
Multihoming is the practice of maintaining more than one connection |
|
Multihoming is a way of connecting an organization’s network to the |
|
|
to the public Internet. |
|
public Internet through more than one AS. |
|
|
– A multihomed AS is one which is connected to more than one other |
|
|
|
|
AS. An AS also qualifies as multihomed if it is connected to a |
|
|
|
|
public Internet Exchange Point. |
|
|
|
|
– An organization is considered to be multihomed if its network |
|
|
|
|
receives fulltime connectivity from more than one ISP and has one |
|
|
|
|
or more routing prefixes announced by at least two of its ISPs. |
|
|
|
|
|
|
|
|
|
2.5. Internet resources |
|
2.5. Internet resources |
|
|
———————– |
|
———————– |
|
|
Internet resources are public IPv4 and IPv6 address numbers, |
|
Internet resources are public IPv4 and IPv6 address numbers, |
|
|
Autonomous System Numbers, and reverse DNS delegations. |
|
Autonomous System Numbers, and reverse DNS delegations. |
|
|
|
|
|
|
|
2.5.1. Current resources |
|
2.5.1. Current resources |
|
|
———————— |
|
———————— |
|
|
Current resources are Internet resources registered by APNIC |
|
Current resources are Internet resources registered by APNIC |
|
|
under explicit policies and agreements. |
|
under explicit policies and agreements. |
|
|
|
|
|
|
|
2.5.2. Historical resources |
|
2.5.2. Historical resources |
|
|
————————— |
|
————————— |
|
|
Historical resources are Internet resources registered under |
|
Historical resources are Internet resources registered under |
|
|
early registry policies without formal agreements and include: |
|
early registry policies without formal agreements and include: |
|
|
|
|
|
|
|
– Registrations transferred to APNIC as part of the AUNIC to |
|
– Registrations transferred to APNIC as part of the AUNIC to |
|
|
APNIC migration |
|
APNIC migration |
|
|
|
-Some historical resource registrations have been inherited |
|
– Some historical resource registrations have been |
|
|
by APNIC from the former AUNIC address registry. |
|
inherited by APNIC from the former AUNIC address |
|
|
|
|
registry. |
|
|
|
|
|
|
|
– A list of resources transferred to APNIC as part of the |
|
– A list of resources transferred to APNIC as part of the |
|
|
migration is available on the APNIC website at: |
|
migration is available on the APNIC website at: |
|
|
|
|
|
|
|
http://www.apnic.net/aunic |
|
http://www.apnic.net/aunic |
|
|
|
|
|
|
|
– Registrations transferred as part of the Early Registration |
|
– Registrations transferred as part of the Early Registration |
|
|
Transfer (ERX) project |
|
Transfer (ERX) project |
|
|
– Most historical registrations were initially made by the |
|
– Most historical registrations were initially made by the |
|
|
global registries that predated ARIN, such as DDN-NIC, |
|
global registries that predated ARIN, such as DDN-NIC, |
|
|
|
|
|
|
|
skipping to change at line 524 |
|
skipping to change at line 515 |
|
|
policies. |
|
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 |
|
An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 |
|
|
network structure that interconnects three or more Autonomous |
|
network structure that interconnects three or more Autonomous |
|
|
Systems (AS) for the purpose of Internet traffic interchange. |
|
Systems (AS) for the purpose of Internet traffic interchange. |
|
|
|
|
|
|
|
2.7. Usage rate |
|
2.7. Usage rate |
|
|
————— |
|
————— |
|
|
|
In IPv4 policy, usage rate is the rate at which the LIR made |
|
Usage rate is the rate at which the LIR made delegations from |
|
|
delegations from relevant past address space, including Historical |
|
relevant past address space, including Historical delegations. |
|
|
delegations. |
|
|
|
|
|
|
|
|
|
2.8. Utilization |
|
2.8. Utilization |
|
|
—————- |
|
—————- |
|
|
|
Similar to usage rate in IPv4 policy, utilization is a measure of |
|
Utilization is a measure of IPv6 address usage where “utilization” |
|
|
address usage in IPv6 policy. The actual usage within each |
|
is only measured in terms of the bits to the left of the /56 |
|
|
assignment will be quite low, when compared to IPv4 assignments, |
|
boundary. In other words, utilization refers to the delegation of |
|
|
because in IPv6 policy “utilization” is only measured in terms of |
|
/56s to end sites, and not the number of addresses assigned within |
|
|
the bits to the left of the /56 boundary. In other words, |
|
individual /56s at those end sites. |
|
|
utilization refers to the assignment of /56s to end sites, and not |
|
|
|
|
the number of addresses assigned within individual /56s at those end |
|
|
|
|
sites. |
|
|
|
|
|
|
|
|
|
Throughout this document, the term utilization refers to the |
|
|
|
|
allocation of /56s to end sites, and not the number of addresses |
|
|
|
|
assigned within individual /56s within 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 |
|
The HD-Ratio is a way of measuring the efficiency of address |
|
|
assignment [RFC 3194]. It is an adaptation of the H-Ratio |
|
assignment [RFC 3194]. It is an adaptation of the H-Ratio |
|
|
originally defined in [RFC1715] and is expressed as follows: |
|
originally defined in [RFC1715] and is expressed as follows: |
|
|
|
|
|
|
|
Log (number of allocated objects) |
|
Log (number of allocated objects) |
|
|
HD = ————————————- |
|
HD = ————————————- |
|
|
Log (maximum number of allocatable objects) |
|
Log (maximum number of allocatable objects) |
|
|
|
|
|
|
|
skipping to change at line 916 |
|
skipping to change at line 899 |
|
|
– Are separate legal entities, |
|
– Are separate legal entities, |
|
|
– Maintain fully independent network infrastructures and are routed |
|
– Maintain fully independent network infrastructures and are routed |
|
|
under different ASNs, or |
|
under different ASNs, or |
|
|
– Can otherwise demonstrate a justified need to obtain address space |
|
– Can otherwise demonstrate a justified need to obtain address space |
|
|
from more than one IR. |
|
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, for Internet number resources to |
|
of the Internet community as a whole, for Internet number resources to |
|
|
|
be considered freehold property. Internet resources are regarded as |
|
be considered freehold property. |
|
|
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 |
|
|
globally-unique unicast address space is licensed for use rather than |
|
|
|
|
owned. Neither delegation nor registration confers ownership of |
|
|
|
|
resources. Organizations that use them are considered “custodians” |
|
resources. Organizations that use them are considered “custodians” |
|
|
rather than “owners” of the resource, and are not entitled to sell or |
|
rather than “owners” of the resource, and are not entitled to sell or |
|
|
otherwise transfer that resource to other parties outside the provisions |
|
otherwise transfer that resource to other parties outside the provisions |
|
|
in this document. |
|
in this document. |
|
|
|
|
|
|
|
|
Specifically, IP addresses and AS numbers will be allocated and assigned |
|
Internet resources are regarded as public resources that should only be |
|
|
on a license basis, with licenses subject to renewal on a periodic |
|
distributed according to demonstrated need. |
|
|
basis. |
|
|
|
|
|
|
|
|
|
|
The conditions of all licenses are described in the APNIC membership |
|
The policies in this document are based upon the understanding that |
|
|
agreements, service agreements, and other relevant APNIC documents. |
|
globally-unique unicast address space is licensed for use rather than |
|
|
|
|
owned. |
|
|
|
|
|
|
|
4.1. License Renewal |
|
4.1. License Renewal |
|
|
——————— |
|
——————— |
|
|
|
APNIC will delegate Internet resources on a ‘license’ basis, with |
|
Specifically, APNIC will delegate Internet resources on a ‘license’ |
|
|
such licenses to be of specific limited duration (normally one |
|
basis, with licenses subject to renewal on a periodic basis |
|
|
year). The granting of a license is subject to specific conditions |
|
(normally one year). |
|
|
applied at the start or renewal of the license. |
|
|
|
|
|
|
|
|
|
|
IRs will generally renew licenses automatically, provided requesting |
|
The granting of a license is subject to specific conditions as |
|
|
organizations are making a good-faith effort at meeting the criteria |
|
described in the APNIC membership agreements, service agreements, |
|
|
under which they qualified for or were granted an allocation or |
|
and other relevant APNIC documents, at the start or renewal of the |
|
|
assignment. |
|
license. |
|
|
|
|
|
|
|
|
|
IRs will generally renew licenses automatically, provided |
|
|
|
|
requesting organizations are making a good-faith effort at meeting |
|
|
|
|
the criteria under which they qualified for, or were granted an |
|
|
|
|
allocation or assignment. |
|
|
|
|
|
|
|
Licenses to organizations shall be renewable on the following |
|
Licenses to organizations shall be renewable on the following |
|
|
conditions: |
|
conditions: |
|
|
– The original basis of the delegation remains valid, and |
|
– The original basis of the delegation remains valid, and |
|
|
– That address space is properly registered at the time of renewal. |
|
– That address space is properly registered at the time of renewal. |
|
|
|
|
|
|
|
4.1.1. Review |
|
4.1.1. Review |
|
|
————- |
|
————- |
|
|
In those cases where a requesting organization is not using the |
|
In those cases where a requesting organization is not using the |
|
|
address space as intended, or is showing bad faith in following |
|
address space as intended, or is showing bad faith in following |
|
|
through on the associated obligation, IRs reserve the right to |
|
through on the associated obligation, IRs reserve the right to |
|
|
not renew the license. However, individual licenses shall only |
|
not renew the license. However, individual licenses shall only |
|
|
be subject to review if the relevant IR has reason to believe |
|
be subject to review if the relevant IR has reason to believe |
|
|
that the existing license terms are no longer being complied |
|
that the existing license terms are no longer being complied |
|
|
with. IRs may implement their own procedures for the review of |
|
with. IRs may implement their own procedures for the review of |
|
|
existing licenses as they see fit. |
|
existing licenses as they see fit. |
|
|
|
|
|
|
|
|
Note that when a license is renewed, the new license will be |
|
When a license is renewed, the new license will be evaluated and |
|
|
evaluated under and governed by the applicable policies in place |
|
governed subject to all policies and license conditions |
|
|
at the time of renewal, which may differ from the policy in |
|
effective at the time of renewal. |
|
|
place at the time of the original allocation or assignment. When |
|
|
|
|
a license is renewed, the new license will be subject to all |
|
|
|
|
policies and license conditions effective at the time of |
|
|
|
|
renewal, provided that a minimum notice period of one year is |
|
|
|
|
given of any substantial changes to the conditions of the |
|
|
|
|
current license. |
|
|
|
|
|
|
|
|
|
|
All substantial changes to license conditions are subject to the |
|
These may differ from those in place at the time of the original |
|
|
consensus of APNIC Members, in accordance with the APNIC |
|
delegation, provided that a minimum notice period of one year is |
|
|
Document Editorial Policy. |
|
given of any substantial changes. Substantial changes to license |
|
|
|
|
conditions are subject to the consensus of APNIC Members, in |
|
|
|
|
accordance with the APNIC Document Editorial Policy. |
|
|
|
|
|
|
|
4.1.2. Validity of delegations |
|
4.1.2. Validity of delegations |
|
|
—————————— |
|
—————————— |
|
|
|
An allocation or assignment of address space is valid only while |
|
A resource delegation is valid only while the original criteria |
|
|
the original criteria on which the allocation or assignment was |
|
on which it was made remains valid. If a delegation becomes |
|
|
based continue to be valid. |
|
invalid then the resource must be returned to the appropriate |
|
|
|
|
IR. |
|
|
|
|
|
|
|
An allocation or assignment becomes invalid if it is: |
|
An allocation or assignment becomes invalid if it is: |
|
|
|
|
|
|
|
|
– Made for a specific purpose that no longer exists, or |
|
– Made for a specific purpose that no longer exists, or |
|
|
– Based on information that is later found to be false or |
|
– Based on information that is later found to be false or |
|
|
incomplete. |
|
incomplete. |
|
|
|
|
|
|
|
|
If an allocation or assignment becomes invalid then the address |
|
|
|
|
space must be returned to the appropriate IR. |
|
|
|
|
|
|
|
|
|
It is a condition of ASN assignment that if an ASN is not being |
|
|
|
|
used by the organization that originally received it, then the |
|
|
|
|
ASN should be returned, or transferred under the terms described |
|
|
|
|
in this document. |
|
|
|
|
|
|
|
|
|
4.2. Closure and recovery |
|
4.2. Closure and recovery |
|
|
————————- |
|
————————- |
|
|
If an LIR holding APNIC address space ceases to provide Internet |
|
If an LIR holding APNIC address space ceases to provide Internet |
|
|
connectivity services, all of its address space must be returned to |
|
connectivity services, all of its address space must be returned to |
|
|
APNIC. It is the responsibility of the LIR (or any liquidator or |
|
APNIC. It is the responsibility of the LIR (or any liquidator or |
|
|
administrator appointed to wind up the Member’s business) to advise |
|
administrator appointed to wind up the Member’s business) to advise |
|
|
all of its customers that address space will be returned to APNIC, |
|
all of its customers that address space will be returned to APNIC, |
|
|
and that renumbering into new address space will be necessary. |
|
and that renumbering into new address space will be necessary. |
|
|
|
|
|
|
|
In the case that a new LIR takes over the business or infrastructure |
|
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 |
|
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 |
|
the new LIR, however such a transfer is subject to re-examination by |
|
|
APNIC and may be treated as a new address request process. |
|
APNIC and may be treated as a new address request process. |
|
|
|
|
|
|
|
|
4.2.1. Recovery of unused historical address space |
|
4.2.1. Recovery of unused historical resources |
|
|
————————————————– |
|
————————————————– |
|
|
|
A significant amount of historical address space registered in |
|
A significant amount of historical resources registered in the |
|
|
the APNIC Whois Database is not announced to the global routing |
|
APNIC Whois Database are not announced to the global routing |
|
|
table. To recover these globally unrouted resources and place |
|
table. |
|
|
them back in the free pool for reallocation to other networks, |
|
|
|
|
APNIC will contact networks responsible for Historical address |
|
|
|
|
space in the APNIC region that has not been globally routed |
|
|
|
|
since 1 January 1998. |
|
|
|
|
|
|
|
|
|
|
4.2.2. Recovery of unused historical ASNs |
|
To recover these globally un-routed resources and place them |
|
|
—————————————– |
|
back in the free pool for re-delegation, APNIC will contact |
|
|
A significant amount of historical Autonomous System (AS) |
|
networks responsible for historical address space in the APNIC |
|
|
numbers registered in the APNIC Whois Database are not announced |
|
region that has not been globally routed since 1 January 1998. |
|
|
to the global routing table. To recover these globally unrouted |
|
To recover un-routed historical AS numbers, APNIC will contact |
|
|
resources and place them back in the free pool for reassignment |
|
networks responsible for resources not globally used for a |
|
|
to other networks, APNIC will contact networks responsible for |
|
reasonable period of time. |
|
|
historical address space in the APNIC region that has not been |
|
|
|
|
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 policies that are consistent with |
|
or indirectly) must adopt delegation 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 |
|
NIRs and LIRs must ensure that address space for which they are |
|
|
responsible is only allocated or assigned subject to agreements |
|
responsible is only allocated or assigned subject to agreements |
|
|
consistent with the license provisions in this document. Also, NIRs |
|
consistent with the license provisions in this document. Also, NIRs |
|
|
|
|
|
|
|
skipping to change at line 1112 |
|
skipping to change at line 1077 |
|
|
|
|
|
|
|
If an LIR’s staff appears to become less proficient (for |
|
If an LIR’s staff appears to become less proficient (for |
|
|
example, due to the training of new staff or other relevant |
|
example, due to the training of new staff or other relevant |
|
|
circumstances) then that LIR’s assignment window may be |
|
circumstances) then that LIR’s assignment window may be |
|
|
temporarily reduced. |
|
temporarily reduced. |
|
|
|
|
|
|
|
5.2.2. IPv4 address usage estimates |
|
5.2.2. IPv4 address usage estimates |
|
|
———————————– |
|
———————————– |
|
|
Requests for delegations must be supported by usage estimates |
|
Requests for delegations must be supported by usage estimates |
|
|
based on immediate and projected future need. These requests |
|
based on immediate and projected future need. These requests |
|
|
|
must be accompanied by documentation that supports the estimates. |
|
must be accompanied by documentation that supports the |
|
|
|
|
estimates. |
|
|
|
|
|
|
|
The estimates should be made for the following periods: |
|
The estimates should be made for the following periods: |
|
|
|
|
|
|
|
– Immediately, |
|
– Immediately, |
|
|
– Within one year, and |
|
– Within one year, and |
|
|
– Within two years |
|
– Within two years |
|
|
|
|
|
|
|
APNIC recommends that, as a general guideline, organizations |
|
APNIC recommends that, as a general guideline, organizations |
|
|
should base their resource requests on the assumption that 25% |
|
should base their resource requests on the assumption that 25% |
|
|
of the address space will be used immediately and 50% will be |
|
of the address space will be used immediately and 50% will be |
|
|
|
|
|
|
|
skipping to change at line 1216 |
|
skipping to change at line 1182 |
|
|
5.2.4.4. Assignment to operator’s infrastructure |
|
5.2.4.4. Assignment to operator’s infrastructure |
|
|
———————————————— |
|
———————————————— |
|
|
An organization (ISP/LIR) may assign a /48 per PoP as the |
|
An organization (ISP/LIR) may assign a /48 per PoP as the |
|
|
service infrastructure of an IPv6 service operator. Each |
|
service infrastructure of an IPv6 service operator. Each |
|
|
assignment to a PoP is regarded as one assignment regardless |
|
assignment to a PoP is regarded as one assignment regardless |
|
|
of the number of users using the PoP. A separate assignment |
|
of the number of users using the PoP. A separate assignment |
|
|
can be obtained for the in-house operations of the operator. |
|
can be obtained for the in-house operations of the operator. |
|
|
|
|
|
|
|
5.3. Registration requirements |
|
5.3. Registration requirements |
|
|
—————————— |
|
—————————— |
|
|
|
|
|
|
|
|
5.3.1. Registration requirements for IPv4 addresses |
|
5.3.1. Registration requirements for IPv4 addresses |
|
|
————————————————— |
|
————————————————— |
|
|
IRs are responsible for promptly and accurately registering |
|
IRs are responsible for promptly and accurately registering |
|
|
|
their address space use with APNIC as follows: <ul |
|
their address space use with APNIC as follows: |
|
|
class=”h3bullet”> |
|
|
|
|
– All delegations from APNIC to the IR must be registered. |
|
– All delegations from APNIC to the IR must be registered. |
|
|
– All delegations to downstream IRs must be registered. |
|
– All delegations to downstream IRs must be registered. |
|
|
– Delegations made to networks greater than a /30 must be |
|
– Delegations made to networks greater than a /30 must be |
|
|
registered. |
|
registered. |
|
|
– Delegations made to networks of a /30 or less may be |
|
– Delegations made to networks of a /30 or less may be |
|
|
registered, at the discretion of the IR and the network |
|
registered, at the discretion of the IR and the network |
|
|
administrator. |
|
administrator. |
|
|
– Delegations to hosts may be registered, at the discretion of |
|
– Delegations to hosts may be registered, at the discretion of |
|
|
the IR and the end-user. |
|
the IR and the end-user. |
|
|
|
|
|
|
|
IRs can choose whether or not to designate this information |
|
IRs can choose whether or not to designate this information |
|
|
“public”. Customer registration details that are not designated |
|
“public”. Customer registration details that are not designated |
|
|
“public” will not be generally available via the APNIC Whois |
|
“public” will not be generally available via the APNIC Whois |
|
|
Database. The database record will instead direct specific whois |
|
Database. The database record will instead direct specific whois |
|
|
enquiries to the IR concerned. |
|
enquiries to the IR concerned. |
|
|
|
|
|
|
|
|
In addition, it is mandatory to register an Incident Response |
|
|
|
|
Team (IRT) object for each address block record in the APNIC |
|
|
|
|
Whois Database. |
|
|
|
|
|
|
|
|
|
5.3.1.1. Updating registration details |
|
5.3.1.1. Updating registration details |
|
|
————————————– |
|
————————————– |
|
|
IRs must update their registration records when any of the |
|
IRs must update their registration records when any of the |
|
|
registration information changes. This is the responsibility |
|
registration information changes. This is the responsibility |
|
|
of the IR concerned. However, this responsibility may be |
|
of the IR concerned. However, this responsibility may be |
|
|
formally assigned to the end-user as a condition of the |
|
formally assigned to the end-user as a condition of the |
|
|
original delegation. |
|
original delegation. |
|
|
|
|
|
|
|
|
5.3.1.2. 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.3.2. Registration requirements for IPv6 addresses |
|
5.3.2. Registration requirements for IPv6 addresses |
|
|
————————————————— |
|
————————————————— |
|
|
When an organization holding an IPv6 address allocation makes |
|
When an organization holding an IPv6 address allocation makes |
|
|
IPv6 address assignments, it must register assignment |
|
IPv6 address assignments, it must register assignment |
|
|
information in a database, accessible by RIRs as appropriate |
|
information in a database, accessible by RIRs as appropriate |
|
|
(information registered by an RIR/NIR may be replaced by a |
|
(information registered by an RIR/NIR may be replaced by a |
|
|
distributed database for registering address management |
|
distributed database for registering address management |
|
|
information in future). |
|
information in future). |
|
|
|
|
|
|
|
Information is registered in units of assigned /48 networks. |
|
Information is registered in units of assigned /48 networks. |
|
|
|
|
|
|
|
skipping to change at line 1300 |
|
skipping to change at line 1241 |
|
|
registration. |
|
registration. |
|
|
|
|
|
|
|
Organizations that receive an allocation from APNIC can choose |
|
Organizations that receive an allocation from APNIC can choose |
|
|
whether or not their customer assignment registrations should be |
|
whether or not their customer assignment registrations should be |
|
|
publicly available. If the organization does not indicate a |
|
publicly available. If the organization does not indicate a |
|
|
choice, or it chooses to hide its customer assignment |
|
choice, or it chooses to hide its customer assignment |
|
|
registrations, then those records will not be visible in the |
|
registrations, then those records will not be visible in the |
|
|
public whois database. Whois queries on these records will |
|
public whois database. Whois queries on these records will |
|
|
return details of the allocation. |
|
return details of the allocation. |
|
|
|
|
|
|
|
|
In addition, it is mandatory to register an Incident Response |
|
|
|
|
Team (IRT) object for each allocation and assignment record in |
|
|
|
|
the APNIC Whois Database. |
|
|
|
|
|
|
|
|
|
5.3.3. Registration requirements for AS Numbers |
|
5.3.3. Registration requirements for AS Numbers |
|
|
———————————————– |
|
———————————————– |
|
|
All ASNs assigned must be publicly registered in the APNIC, or |
|
All ASNs assigned must be publicly registered in the APNIC, or |
|
|
relevant NIR, Whois database. APNIC, or the relevant NIR, will |
|
relevant NIR, Whois database. APNIC, or the relevant NIR, will |
|
|
create the aut-num object. |
|
create the aut-num object. |
|
|
|
|
|
|
|
All attributes of the aut-num object must be properly registered |
|
All attributes of the aut-num object must be properly registered |
|
|
in accordance with the APNIC or NIR whois database |
|
in accordance with the APNIC or NIR whois database |
|
|
documentation. Without limiting these general requirements, |
|
documentation. Without limiting these general requirements, |
|
|
Section 5.3.3.1 and Section 5.3.3.2. describe particular |
|
Section 5.3.3.1 and Section 5.3.3.2. describe particular |
|
|
requirements for ASN registration. |
|
requirements for ASN registration. |
|
|
|
|
|
|
|
|
Administrative and technical contact persons must be registered |
|
|
|
|
for each ASN assigned. |
|
|
|
|
|
|
|
|
|
The registered administrative contact (‘admin-c’) is the person |
|
|
|
|
responsible for the ASN and should generally be someone who is |
|
|
|
|
physically located at the site of the AS. |
|
|
|
|
|
|
|
|
|
The technical contact (‘tech-c’) need not be physically located |
|
|
|
|
at the site of the AS, but must be a person who is responsible |
|
|
|
|
for the day-to-day operation of that AS. |
|
|
|
|
|
|
|
|
|
In addition, it is mandatory to register an Incident Response |
|
|
|
|
Team (IRT) object for each AS Number record in the APNIC Whois |
|
|
|
|
Database. |
|
|
|
|
|
|
|
|
|
5.3.3.1. Registering routing policy |
|
5.3.3.1. Registering routing policy |
|
|
———————————– |
|
———————————– |
|
|
APNIC recommends that the routing policy of the AS is |
|
APNIC recommends that the routing policy of the AS is |
|
|
registered for each ASN assigned. |
|
registered for each ASN assigned. |
|
|
|
|
|
|
|
5.3.3.2. Updating registration details |
|
5.3.3.2. Updating registration details |
|
|
————————————– |
|
————————————– |
|
|
Organizations responsible for ASNs should update the aut-num |
|
Organizations responsible for ASNs should update the aut-num |
|
|
object in the appropriate database if any of the |
|
object in the appropriate database if any of the |
|
|
registration information changes. |
|
registration information changes. |
|
|
|
|
|
|
|
|
|
|
5.3.4. Registering Contact Persons |
|
|
|
|
———————————- |
|
|
|
|
Administrative and technical contact persons must be registered. |
|
|
|
|
|
|
|
|
|
The registered administrative contact (“admin-c”) must be |
|
|
|
|
someone who is physically located at the site of the network, |
|
|
|
|
subject to the following exceptions: |
|
|
|
|
|
|
|
|
|
– For residential networks or users, the IR’s technical contact |
|
|
|
|
may be registered as the admin-c. |
|
|
|
|
– For networks in exceptional circumstances that make it |
|
|
|
|
impractical to maintain an on-site administrative contact, an |
|
|
|
|
off-site person may be registered as the admin-c. |
|
|
|
|
|
|
|
|
|
The technical contact (“tech-c”) need not be physically |
|
|
|
|
located at the site of the network, but must be a person who |
|
|
|
|
is responsible for the day-to-day operation of the network. |
|
|
|
|
|
|
|
|
|
In addition, it is mandatory to register an Incident Response |
|
|
|
|
Team (IRT) object for each resource record in the APNIC Whois |
|
|
|
|
Database. |
|
|
|
|
|
|
|
5.4. Reverse lookup |
|
5.4. Reverse lookup |
|
|
——————- |
|
——————- |
|
|
|
|
|
|
|
5.4.1. Responsibility to maintain IPv4 in-addr.arpa records |
|
5.4.1. Responsibility to maintain IPv4 in-addr.arpa records |
|
|
———————————————————– |
|
———————————————————– |
|
|
LIRs should maintain in-addr.arpa resource records for their |
|
LIRs should maintain in-addr.arpa resource records for their |
|
|
customers’ networks. If a network is not specifically associated |
|
customers’ networks. If a network is not specifically associated |
|
|
with an LIR then the in-addra.arpa records should be maintained |
|
with an LIR then the in-addra.arpa records should be maintained |
|
|
by either the appropriate NIR or APNIC. |
|
by either the appropriate NIR or APNIC. |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 1392 |
|
skipping to change at line 1336 |
|
|
with the management of current resources. |
|
with the management of current resources. |
|
|
|
|
|
|
|
To ensure integrity of information, APNIC will not update |
|
To ensure integrity of information, APNIC will not update |
|
|
historical information in the APNIC Whois Database until the |
|
historical information in the APNIC Whois Database until the |
|
|
resource holder demonstrates the organization’s right to the |
|
resource holder demonstrates the organization’s right to the |
|
|
resources and enters a formal agreement with APNIC either as a |
|
resources and enters a formal agreement with APNIC either as a |
|
|
Member or Non-Member account holder. |
|
Member or Non-Member account holder. |
|
|
|
|
|
|
|
5.5.3. Updating Historical registrations |
|
5.5.3. Updating Historical registrations |
|
|
—————————————- |
|
—————————————- |
|
|
|
Detailed information on to request an update to a historical |
|
Detailed information on how to request an update to a historical |
|
|
Internet resource registration is available on the historical |
|
Internet resource registration is available on the historical |
|
|
resource page of the APNIC website. |
|
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 |
|
Please note that resource holders will not be able to update |
|
|
registration information if they fail to pay the fees associated |
|
registration information if they fail to pay the fees associated |
|
|
with their APNIC Member or Non-Member account. |
|
with their APNIC Member or Non-Member account. |
|
|
|
|
|
|
|
Historical resource holders with a current APNIC account have |
|
Historical resource holders with a current APNIC account have |
|
|
|
|
|
|
|
skipping to change at line 1439 |
|
skipping to change at line 1383 |
|
|
This documentation may include: |
|
This documentation may include: |
|
|
– Network engineering plans |
|
– Network engineering plans |
|
|
– Subnetting plans |
|
– Subnetting plans |
|
|
– Descriptions of network topology |
|
– Descriptions of network topology |
|
|
– Descriptions of network routing plans |
|
– Descriptions of network routing plans |
|
|
– Equipment invoices and purchase orders |
|
– Equipment invoices and purchase orders |
|
|
– Other relevant documents |
|
– Other relevant documents |
|
|
|
|
|
|
|
5.6.2. Security and confidentiality |
|
5.6.2. Security and confidentiality |
|
|
———————————– |
|
———————————– |
|
|
|
The documentation which supports address space requests involves |
|
The documentation, which supports address space requests, |
|
|
information that may be highly confidential to the organizations |
|
involves information that may be highly confidential to the |
|
|
and individuals involved. Therefore, APNIC will operate in ways |
|
commercial and infrastructure operations of all Members and |
|
|
that reflect the trust implicit in its position by applying and |
|
their customers. |
|
|
enforcing procedures that protect the confidential information |
|
|
|
|
of its Members and their customers. |
|
|
|
|
|
|
|
|
|
|
APNIC will maintain systems and practices that protect the |
|
Therefore, APNIC will reflect the trust implicit in its position |
|
|
confidentiality of all information relating to the commercial |
|
by: |
|
|
and infrastructure operations of all Members and their |
|
|
|
|
customers. APNIC will ensure that the employment of all of its |
|
– applying and enforcing systems, practices, and procedures that |
|
|
staff or agents is based upon an explicit condition of |
|
protect the confidential information of its Members and their |
|
|
confidentiality regarding such information. |
|
customers, and |
|
|
|
|
|
|
|
|
|
– ensuring the employment of all staff, or agents, is based upon |
|
|
|
|
an explicit condition of confidentiality regarding such |
|
|
|
|
information. |
|
|
|
|
|
|
|
APNIC provides for authorization and verification mechanisms |
|
APNIC provides for authorization and verification mechanisms |
|
|
within the APNIC Whois Database. It is the responsibility of |
|
within the APNIC Whois Database. It is the responsibility of |
|
|
|
each IR or end-user to apply these mechanisms. |
|
each IR, or end-user, to apply these mechanisms. |
|
|
|
|
|
|
|
5.6.3. Equitable processing of requests |
|
5.6.3. Equitable processing of requests |
|
|
————————————— |
|
————————————— |
|
|
|
APNIC will deal with all requests strictly in the order in which |
|
APNIC will only process requests that have been completely and |
|
|
it receives the proper documentation. To provide fair treatment |
|
properly documented. If the documentation contains errors or |
|
|
for all applicants, APNIC will not, under any circumstance, |
|
omissions, APNIC will advise the applicant as soon as possible. |
|
|
provide any special treatment or make exceptions to the standard |
|
|
|
|
order of request processing. |
|
|
|
|
|
|
|
|
|
|
APNIC will seek to process all requests within a consistent time |
|
APNIC may also request the applicant to provide further |
|
|
and will maintain a request tracking system for efficient |
|
information, or clarify relevant issues that are not clear in |
|
|
request management. |
|
the initial request. |
|
|
|
|
|
|
|
|
5.6.3.1. Processing dependent on correct documentation |
|
Once the errors and omissions are rectified, or the additional |
|
|
—————————————————— |
|
questions answered, APNIC will deal with the request in the |
|
|
APNIC will only process requests that have been completely |
|
strict order in which it receives proper documentation. |
|
|
and properly documented. If the documentation contains |
|
|
|
|
errors or omissions, APNIC will advise the applicant as soon |
|
|
|
|
as possible. APNIC may also request the applicant to provide |
|
|
|
|
further information or clarify relevant issues that are not |
|
|
|
|
clear in the initial request. |
|
|
|
|
|
|
|
|
|
|
APNIC will process the request as soon as the errors and |
|
APNIC will make all reasonable efforts to maintain a consistent |
|
|
omissions have been rectified or the additional questions |
|
and reliable level of service with respect to processing of |
|
|
have been answered. |
|
requests and will maintain a request tracking system for |
|
|
|
|
efficient request management. |
|
|
|
|
|
|
|
|
APNIC will make all reasonable efforts to maintain a |
|
To provide fair treatment for all applicants, APNIC will not, |
|
|
consistent and reliable level of service with respect to |
|
under any circumstance, provide any special treatment or make |
|
|
processing of requests. |
|
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 |
|
This Section describes the APNIC policies which apply to requests |
|
|
for Internet resource allocations that are to be used for |
|
for Internet resource allocations that are to be used for |
|
|
experimental purposes. |
|
experimental purposes. |
|
|
|
|
|
|
|
5.7.1. Introduction |
|
5.7.1. Introduction |
|
|
——————- |
|
——————- |
|
|
As the Internet continues to expand and evolve, there is an |
|
As the Internet continues to expand and evolve, there is an |
|
|
|
|
|
|
|
skipping to change at line 1643 |
|
skipping to change at line 1583 |
|
|
|
|
|
|
|
6.0. Initial IPv4 delegations |
|
6.0. Initial IPv4 delegations |
|
|
—————————– |
|
—————————– |
|
|
|
|
|
|
|
6.1. Minimum and maximum IPv4 delegations |
|
6.1. Minimum and maximum IPv4 delegations |
|
|
—————————————– |
|
—————————————– |
|
|
The current minimum delegation size for IPv4 is a /24 (256 |
|
The current minimum delegation size for IPv4 is a /24 (256 |
|
|
addresses). |
|
addresses). |
|
|
|
|
|
|
|
Since Friday, 15 April 2011, each APNIC account holder is only |
|
Since Friday, 15 April 2011, each APNIC account holder is only |
|
|
|
eligible to receive IPv4 address delegations totaling a maximum /22 |
|
eligible to receive IPv4 address delegations totalling a maximum /22 |
|
|
from the APNIC 103/8 IPv4 address pool. |
|
from the APNIC 103/8 IPv4 address pool. |
|
|
|
|
|
|
|
On Tuesday, 27 May 2014, each APNIC account holder became eligible |
|
On Tuesday, 27 May 2014, each APNIC account holder became eligible |
|
|
to receive additional delegations up to a maximum of /22 address |
|
to receive additional delegations up to a maximum of /22 address |
|
|
space from the APNIC non-103/8 IPv4 address pool. |
|
space from the APNIC non-103/8 IPv4 address pool. |
|
|
|
|
|
|
|
To receive delegations from either of these pools, they must |
|
To receive delegations from either of these pools, they must |
|
|
demonstrate their eligibility by meeting the criteria specified |
|
demonstrate their eligibility by meeting the criteria specified |
|
|
below. |
|
below. |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 1963 |
|
skipping to change at line 1903 |
|
|
1. The organization provides comprehensive documentation of planned |
|
1. The organization provides comprehensive documentation of planned |
|
|
IPv6 infrastructure which would require a larger allocation; or |
|
IPv6 infrastructure which would require a larger allocation; or |
|
|
2. The organization provides comprehensive documentation of all of |
|
2. The organization provides comprehensive documentation of all of |
|
|
the following: |
|
the following: |
|
|
– its existing IPv4 infrastructure and customer base, |
|
– its existing IPv4 infrastructure and customer base, |
|
|
– its intention to provide its existing IPv4 services via IPv6, |
|
– its intention to provide its existing IPv4 services via IPv6, |
|
|
and |
|
and |
|
|
– its intention to move some of its existing IPv4 customers to |
|
– its intention to move some of its existing IPv4 customers to |
|
|
IPv6 within two years. |
|
IPv6 within two years. |
|
|
|
|
|
|
|
|
In either case, an allocation will be made which fulfills the |
|
In either case, an allocation will be made which fulfils the |
|
|
calculated address requirement, in accordance with the HD-Ratio |
|
calculated address requirement, in accordance with the HD-Ratio |
|
|
based utilization policy. |
|
based utilization policy. |
|
|
|
|
|
|
|
9.2. Initial IPv6 allocations |
|
9.2. Initial IPv6 allocations |
|
|
—————————– |
|
—————————– |
|
|
|
|
|
|
|
9.2.1. Account holders with existing IPv4 space |
|
9.2.1. Account holders with existing IPv4 space |
|
|
———————————————— |
|
———————————————— |
|
|
Subject to Section 9.1., existing IPv4 networks may be |
|
Subject to Section 9.1., existing IPv4 networks may be |
|
|
considered in determining the initial IPv6 allocation size. |
|
considered in determining the initial IPv6 allocation size. |
|
|
APNIC applies a minimum size for IPv6 allocations to facilitate |
|
APNIC applies a minimum size for IPv6 allocations to facilitate |
|
|
prefix-based filtering. |
|
prefix-based filtering. |
|
|
|
|
|
|
|
APNIC Members that have been delegated an IPv4 address block |
|
APNIC Members that have been delegated an IPv4 address block |
|
|
from APNIC, but have no IPv6 space, can qualify for an |
|
from APNIC, but have no IPv6 space, can qualify for an |
|
|
appropriately sized IPv6 block under the matching IPv6 policy. |
|
appropriately sized IPv6 block under the matching IPv6 policy. |
|
|
For example, a Member that has received an IPv4 IXP assignment |
|
For example, a Member that has received an IPv4 IXP assignment |
|
|
will be eligible to receive an IPv6 IXP assignment. |
|
will be eligible to receive an IPv6 IXP assignment. |
|
|
|
|
|
|
|
The size of the IPv6 delegation for Members that meet this |
|
The size of the IPv6 delegation for Members that meet this |
|
|
|
criteria will be based on the following: <ul class=”h3bullet”> |
|
criteria will be based on the following: |
|
|
|
|
|
|
|
– A Member that has an IPv4 allocation is eligible for a |
|
– A Member that has an IPv4 allocation is eligible for a |
|
|
/32 IPv6 address block. |
|
/32 IPv6 address block. |
|
|
– A Member that has an IPv4 assignment is eligible for a |
|
– A Member that has an IPv4 assignment is eligible for a |
|
|
/48 IPv6 address block. |
|
/48 IPv6 address block. |
|
|
|
|
|
|
|
If an APNIC Member wishes to receive an initial allocation or |
|
If an APNIC Member wishes to receive an initial allocation or |
|
|
assignment larger than the sizes described above, the Member |
|
assignment larger than the sizes described above, the Member |
|
|
will need to apply under the alternative criteria described |
|
will need to apply under the alternative criteria described |
|
|
in Section 9.2.2. and Section 10.1 below. |
|
in Section 9.2.2. and Section 10.1 below. |
|
|
|
|
|
|
|
skipping to change at line 2102 |
|
skipping to change at line 2042 |
|
|
– IPv6 for multihoming |
|
– IPv6 for multihoming |
|
|
– IPv6 for critical infrastructure |
|
– IPv6 for critical infrastructure |
|
|
– IPv6 for Internet Exchange Points |
|
– IPv6 for Internet Exchange Points |
|
|
– Provider Independent IPv6 assignment |
|
– Provider Independent IPv6 assignment |
|
|
|
|
|
|
|
10.1.1. IPv6 for multihoming |
|
10.1.1. IPv6 for multihoming |
|
|
—————————- |
|
—————————- |
|
|
An organization is eligible to receive a portable assignment |
|
An organization is eligible to receive a portable assignment |
|
|
from APNIC if it is currently, or plans to be, multihomed. |
|
from APNIC if it is currently, or plans to be, multihomed. |
|
|
|
|
|
|
|
|
An organization is considered to be multihomed if its network |
|
|
|
|
receives full-time connectivity from more than one ISP and has |
|
|
|
|
one or more routing prefixes announced by at least two of its |
|
|
|
|
ISPs. |
|
|
|
|
|
|
|
|
|
The minimum assignment made under these terms is /48. |
|
The minimum assignment made under these terms is /48. |
|
|
|
|
|
|
|
10.1.2. IPv6 critical infrastructure |
|
10.1.2. IPv6 critical infrastructure |
|
|
———————————— |
|
———————————— |
|
|
The following critical infrastructure networks, if operating in |
|
The following critical infrastructure networks, if operating in |
|
|
the Asia Pacific region, are eligible to receive a portable |
|
the Asia Pacific region, are eligible to receive a portable |
|
|
assignment: |
|
assignment: |
|
|
– Root domain name system (DNS) server; |
|
– Root domain name system (DNS) server; |
|
|
– Global top level domain (gTLD) nameservers; |
|
– Global top level domain (gTLD) nameservers; |
|
|
– Country code TLD (ccTLDs) nameservers; |
|
– Country code TLD (ccTLDs) nameservers; |
|
|
|
|
|
|
|
skipping to change at line 2223 |
|
skipping to change at line 2158 |
|
|
disclosure of all address space held by all of the entities in |
|
disclosure of all address space held by all of the entities in |
|
|
question. If full disclosure is not made, then APNIC will consider |
|
question. If full disclosure is not made, then APNIC will consider |
|
|
any allocations to be invalid and will require that they be |
|
any allocations to be invalid and will require that they be |
|
|
returned. |
|
returned. |
|
|
|
|
|
|
|
Part 4: ASN Policy |
|
Part 4: ASN Policy |
|
|
—————— |
|
—————— |
|
|
|
|
|
|
|
12.0. ASN assignments |
|
12.0. ASN assignments |
|
|
——————— |
|
——————— |
|
|
|
An organization is eligible for an ASN assignment if it: |
|
|
|
|
1. is multihomed; and |
|
|
|
|
2. has a single, clearly defined routing policy that is different from |
|
|
|
|
its providers’ routing policies. |
|
|
|
|
|
|
|
|
|
An organization will also be eligible if it can demonstrate that it will |
|
|
|
|
meet the above criteria upon receiving an ASN (or within a reasonably |
|
|
|
|
short time thereafter). |
|
|
|
|
|
|
|
|
|
12.1. Evaluation of eligibility |
|
12.1. Evaluation of eligibility |
|
|
——————————- |
|
——————————- |
|
|
|
|
|
An organization is eligible for an ASN assignment if it: |
|
|
|
|
1. is multihomed; and |
|
|
|
|
2. has a single, clearly defined routing policy that is different |
|
|
|
|
from its providers’ routing policies. |
|
|
|
|
|
|
|
|
|
An organization will also be eligible if it can demonstrate that it |
|
|
|
|
will meet the above criteria upon receiving an ASN (or within a |
|
|
|
|
reasonably short time thereafter). |
|
|
|
|
|
|
|
Requests for ASNs under these criteria will be evaluated using the |
|
Requests for ASNs under these criteria will be evaluated using the |
|
|
guidelines described in RFC1930 ‘Guidelines for the creation, |
|
guidelines described in RFC1930 ‘Guidelines for the creation, |
|
|
selection and registration of an Autonomous System’ (AS). |
|
selection and registration of an Autonomous System’ (AS). |
|
|
|
|
|
|
|
12.2. Requesting an ASN |
|
12.2. Requesting an ASN |
|
|
———————– |
|
———————– |
|
|
Organizations may request an ASN from either APNIC or their relevant |
|
Organizations may request an ASN from either APNIC or their relevant |
|
|
NIR. |
|
NIR. |
|
|
|
|
|
|
|
The requesting organization may request an ASN for use in its own |
|
The requesting organization may request an ASN for use in its own |
|
|
network, or for the purposes of providing the ASN to one of its |
|
network, or for the purposes of providing the ASN to one of its |
|
|
|
customers, subject to the terms of<span style=”color:red”>Sections |
|
customers, subject to the terms of Sections 12.3. and 12.4. below. |
|
|
12.3. and 12.4. below. |
|
|
|
|
|
|
|
|
|
12.3. Using ASN for own network |
|
12.3. Using ASN for own network |
|
|
——————————- |
|
——————————- |
|
|
Assignments to organizations that will use the ASN in their own |
|
Assignments to organizations that will use the ASN in their own |
|
|
network are subject to the following additional terms: |
|
network are subject to the following additional terms: |
|
|
1. The requesting organization is responsible for maintaining the |
|
1. The requesting organization is responsible for maintaining the |
|
|
registration described in Section 5.3.3. |
|
registration described in Section 5.3.3. |
|
|
2. The requesting organization is entitled to continue using the |
|
2. The requesting organization is entitled to continue using the |
|
|
ASN, even if they change network peers or service providers. |
|
ASN, even if they change network peers or service providers. |
|
|
|
|
|
|
|
|
|
|
|
|
skipping to change at line 2292 |
|
skipping to change at line 2226 |
|
|
Autonomous System Numbers may be transferred in accordance with the |
|
Autonomous System Numbers may be transferred in accordance with the |
|
|
following policies. APNIC does not recognize transfers outside this |
|
following policies. APNIC does not recognize transfers outside this |
|
|
policy and require organizations holding such transfers to return them. |
|
policy and require organizations holding such transfers to return them. |
|
|
|
|
|
|
|
APNIC recognizes there will be situations where ASNs may be transferred |
|
APNIC recognizes there will be situations where ASNs may be transferred |
|
|
between: |
|
between: |
|
|
– Current APNIC account holders |
|
– Current APNIC account holders |
|
|
– Current APNIC account holders and organizations in other RIR regions |
|
– Current APNIC account holders and organizations in other RIR regions |
|
|
– Organizations through a merger, acquisition, or takeover |
|
– Organizations through a merger, acquisition, or takeover |
|
|
|
|
|
|
|
|
13.1. Transfers of IPv4 addresses between APNIC account holders |
|
13.1. Transfers of ASNs between APNIC account holders |
|
|
————————————————————— |
|
————————————————————— |
|
|
APNIC will process and record ASN transfer requests between current |
|
APNIC will process and record ASN transfer requests between current |
|
|
APNIC account holders subject to the following conditions. |
|
APNIC account holders subject to the following conditions. |
|
|
|
|
|
|
|
13.1.1. Conditions on resource |
|
13.1.1. Conditions on resource |
|
|
—————————— |
|
—————————— |
|
|
The ASN must be: |
|
The ASN must be: |
|
|
– In the range administered by APNIC |
|
– In the range administered by APNIC |
|
|
– Assigned to a current APNIC account holder |
|
– Assigned to a current APNIC account holder |
|
|
– The ASN will be subject to all current APNIC policies from the |
|
– The ASN will be subject to all current APNIC policies from the |
|
|
|
|
|
|
End of changes. 59 change blocks. |
|
231 lines changed or deleted |
|
165 lines changed or added |
|
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |