diff_apnic-127-v002

 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/