APNIC Home

diff-apnic-127-v009

 apnic-127-v009.txt   apnic-127-v010.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: 009 Version: 010
Date of original publication: 5 March 2015 Date of original publication: 5 March 2015
Date of this version: 28 May 2021 Date of this version: xx December 2021
Review scheduled: n/a Review scheduled: n/a
Obsoletes: apnic-127-v008 Obsoletes: apnic-127-v009
Status: Active Status: Draft
Comments: Implements prop-133 Comments: Implements prop-135, 136, 139, 140
———————————————————————- ———————————————————————-
Table of Contents Table of Contents
—————– —————–
Part 1: Policy Environment Part 1: Policy Environment
————————– ————————–
1.0. Introduction 1.0. Introduction
skipping to change at line 49 skipping to change at line 49
2.3. Autonomous System (AS) 2.3. Autonomous System (AS)
2.3.1. Autonomous System Number (ASN) 2.3.1. Autonomous System Number (ASN)
2.4. Multihomed 2.4. Multihomed
2.5. Internet resources 2.5. Internet resources
2.5.1. Current resources 2.5.1. Current resources
2.5.2. Historical resources 2.5.2. Historical resources
2.6. Internet Exchange Point (IXP) 2.6. Internet Exchange Point (IXP)
2.7. Usage rate 2.7. Usage rate
2.8. Utilization 2.8. Utilization
2.8.1. HD-Ratio 2.8.1. HD-Ratio
2.9. End site 2.9. End-site
2.10. aut-num object 2.10. End-user
2.11. Routing policy 2.11. aut-num object
2.12. Transfers 2.12 Routing policy
2.12.1. Counterpart RIR 2.13. Transfers
2.12.2. Source 2.13.1. Counterpart RIR
2.12.3. Recipient 2.13.2. Source
2.13.3. Recipient
3.0. Policy framework 3.0. Policy framework
3.1. Goals of resource management 3.1. Goals of resource management
3.1.1. Uniqueness 3.1.1. Uniqueness
3.1.2. Registration 3.1.2. Registration
3.1.3. Aggregation 3.1.3. Aggregation
3.1.4. No guarantee of contiguous delegations 3.1.4. No guarantee of contiguous delegations
3.1.5. Conservation 3.1.5. Conservation
3.1.6. Fairness 3.1.6. Fairness
3.1.7. Minimized Overhead 3.1.7. Minimized Overhead
skipping to change at line 96 skipping to change at line 97
4.2. Closure and recovery 4.2. Closure and recovery
4.2.1. Recovery of unused historical resources 4.2.1. Recovery of unused historical resources
5.0. Resource Management 5.0. Resource Management
5.1. How APNIC manages address space 5.1. How APNIC manages address space
5.1.1. Reservation for future uses 5.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.1.4. Preventing the Use of Undelegated APNIC Address Space 5.1.4. Preventing the Use of Undelegated APNIC Address Space
5.2. LIR address space management 5.2. LIR address space management
5.2.1. Assignment window for LIRs 5.2.1. IPv4 address usage estimates
5.2.2. IPv4 address usage estimates 5.2.2. IPv4 Delegations to downstream IRs
5.2.3. IPv4 Delegations to downstream IRs 5.2.2.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.3. Policies for LIR IPv6 allocation and assignment
5.2.4.1. LIR-to-ISP allocation 5.2.3.1. LIR-to-ISP allocation
5.2.4.2. Assignment address space size 5.2.3.2. Assignment address space size
5.2.4.3. Assignment of multiple /48s to a single end site 5.2.3.3. Assignment of multiple /48s to a single end site
5.3. Registration requirements 5.3. Registration requirements
5.3.1. Requirements for IPv4 addresses 5.3.1. Requirements for Autonomous System Numbers (ASNs) and Addresses
5.3.1.1. Updating registration details 5.3.2. Updating registration details
5.3.2. Registration requirements for IPv6 addresses 5.3.3. Registering contact persons
5.3.3. Registration requirements for AS Numbers
5.3.3.1. Registering routing policy
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. Security and confidentiality
5.6.2. Security and confidentiality 5.6.2. Equitable processing of requests
5.6.3. Equitable processing of requests
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 537 skipping to change at line 532
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)
where (in the case of this document) the objects are IPv6 site where (in the case of this document) the objects are IPv6 site
addresses (/56s) assigned from an IPv6 prefix of a given size. addresses (/56s) assigned from an IPv6 prefix of a given size.
2.9. End site 2.9. End–site
————- ————-
An end site is defined as an end-user (subscriber) who has a An end site is defined as the location of an end-user who has a
business relationship with a service provider that involves: business or legal relationship (same or associated entities) with
– that service provider assigning address space to the end-user a service provider that involves:
– that service provider assigning address space to the end-user location
– that service provider providing transit service for the end-user – that service provider providing transit service for the end-user
to other sites location to other sites
– that service provider carrying the end-user’s traffic – that service provider carrying the end-user’s location traffic
– that service provider advertising an aggregate prefix route that – that service provider advertising an aggregate prefix route that
contains the end-user’s assignment contains the end-user’s location assignment
2.10. aut-num object 2.10. End-user
——————–
Service subscriber or customer of an LIR.
2.11. aut-num object
——————– ——————–
An aut-num object is an object in the Whois database used to An aut-num object is an object in the Whois database used to
register ASN assignment details. For the purposes of this document, register ASN assignment details. For the purposes of this document,
aut-num object also refers to the ASN registration objects in NIR aut-num object also refers to the ASN registration objects in NIR
databases. databases.
2.11. Routing policy 2.12. Routing policy
——————– ——————–
The routing policy of an AS is a description of how network prefixes The routing policy of an AS is a description of how network prefixes
are exchanged between that AS and other Autonomous Systems. are exchanged between that AS and other Autonomous Systems.
2.12. Transfers 2.13. Transfers
————— —————
Resource transfers involve the re-allocation of current address Resource transfers involve the re-allocation of current address
blocks (or ASNs), or the re-allocation of historical resources blocks (or ASNs), or the re-allocation of historical resources
claimed and transferred to an APNIC account. claimed and transferred to an APNIC account.
2.12.1. Counterpart RIR 2.13.1. Counterpart RIR
———————– ———————–
A counterpart RIR is the Regional Internet Registry that APNIC A counterpart RIR is the Regional Internet Registry that APNIC
transfers resources to, or from, in an inter-RIR transfer. transfers resources to, or from, in an inter-RIR transfer.
2.12.2. Source 2.13.2. Source
————– ————–
The source in a resource transfer is the organization which, The source in a resource transfer is the organization which,
prior to the transfer, is the legitimate holder of the resources prior to the transfer, is the legitimate holder of the resources
to be transferred. Where the source is in the APNIC region, the to be transferred. Where the source is in the APNIC region, the
source must be a current APNIC account holder, except in the source must be a current APNIC account holder, except in the
case of an Historical resource transfer. Where the source is case of an Historical resource transfer. Where the source is
from another RIR region, it must be that RIR’s equivalent to the from another RIR region, it must be that RIR’s equivalent to the
“Source” as defined here. “Source” as defined here.
2.12.3. Recipient 2.13.3. Recipient
—————– —————–
The recipient in a resource transfer is the organization which, The recipient in a resource transfer is the organization which,
after the transfer is completed, will be the legitimate holder after the transfer is completed, will be the legitimate holder
of the resources to be transferred. Where the recipient is in of the resources to be transferred. Where the recipient is in
the APNIC region, the recipient must be a current APNIC account the APNIC region, the recipient must be a current APNIC account
holder. Where the recipient is from another RIR region, it must holder. Where the recipient is from another RIR region, it must
be that RIR’s equivalent to the “Recipient” as defined here. be that RIR’s equivalent to the “Recipient” as defined here.
3.0. Policy framework 3.0. Policy framework
——————— ———————
skipping to change at line 1002 skipping to change at line 1002
reasonable period of time. 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.
must, wherever possible, apply slow start, assignment window, and second
opinion policies to their own members in a manner consistent with the Also, NIRs must, wherever possible, apply slow start policies to their own
way APNIC applies such policies. members in a manner consistent with the way APNIC applies such policies.
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
———————————- ———————————-
A /16 of IPv4 address space will be held in reserve for future A /16 of IPv4 address space will be held in reserve for future
uses, as yet unforeseen. uses, as yet unforeseen.
If the reserved /16 remains unused by the time the remaining If the reserved /16 remains unused by the time the remaining
skipping to change at line 1057 skipping to change at line 1057
they have under their account administration, only APNIC has the they have under their account administration, only APNIC has the
authority to create AS0 ROAs for APNIC address space not yet delegated authority to create AS0 ROAs for APNIC address space not yet delegated
to an organization. When APNIC delegates address space to an organization, to an organization. When APNIC delegates address space to an organization,
APNIC will remove the prefix from the AS0 ROA. APNIC will remove the prefix from the AS0 ROA.
5.2. LIR address space management 5.2. LIR address space management
——————————— ———————————
LIRs may delegate address space to their customers subject to the LIRs may delegate address space to their customers subject to the
following provisions. following provisions.
5.2.1. Assignment window for LIRs 5.2.1. IPv4 address usage estimates
———————————
APNIC and NIRs shall apply an assignment window mechanism to
help LIRs understand and comply with APNIC policies and the
address management goals.
The assignment window indicates the maximum number of addresses
an LIR may delegate to an end-user without first seeking a
“second opinion”. If an LIR wishes to make a delegation that
exceeds its delegation window, the LIR must first submit a
second opinion request.
LIRs start with a delegation window of zero, meaning all
proposed delegations must first be approved.
APNIC, or the relevant NIR, will regularly assess the
proficiency of LIR staff in making delegations and seeking
second opinions and will review the size of the assignment
window accordingly. As the LIR staff become more proficient, the
size of their assignment window may be raised.
The maximum IPv4 assignment window given to any LIR will be a
/19 (8,192 addresses).
If an LIR’s staff appears to become less proficient (for
example, due to the training of new staff or other relevant
circumstances) then that LIR’s assignment window may be
temporarily reduced.
5.2.2. IPv4 address usage estimates
———————————– ———————————–
Requests for delegations must be supported by usage estimates 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 must be accompanied by documentation that supports the
estimates. 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
skipping to change at line 1110 skipping to change at line 1081
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
used within one year. used within one year.
The end-user must provide documentation that supports its The end-user must provide documentation that supports its
one-year usage estimate. If it is not possible for the end-user one-year usage estimate. If it is not possible for the end-user
to estimate confidently what the two-year usage rate will be, to estimate confidently what the two-year usage rate will be,
then APNIC or the NIR may make a delegation that will be then APNIC or the NIR may make a delegation that will be
sufficient for the one-year needs only. sufficient for the one-year needs only.
5.2.3. IPv4 Delegations to downstream IRs 5.2.2. IPv4 Delegations to downstream IRs
—————————————– —————————————–
LIRs may delegate address space to their downstream customers, LIRs may delegate address space to their downstream customers,
which are operating networks, such as ISPs, subject to the which are operating networks, such as ISPs, subject to the
following conditions: following conditions:
– Delegations are non-portable and must be returned to the LIR – Delegations are non-portable and must be returned to the LIR
if the downstream customer ceases to receive connectivity from if the downstream customer ceases to receive connectivity from
the LIR. the LIR.
– Delegations are subject to the LIR’s assignment window.
Requests for delegations, which exceed the LIR’s assignment
window, must first be referred to APNIC for second opinion
approval.
– The downstream customer is not permitted to further allocate – The downstream customer is not permitted to further allocate
the address space. the address space.
5.2.3.1. Effect of delegation to downstream IRs on upstream 5.2.2.1. Effect of delegation to downstream IRs on upstream
LIR’s usage rate LIR’s usage rate
———————————————————— ————————————————————
For the purposes of evaluating the LIR’s usage rate, address For the purposes of evaluating the LIR’s usage rate, address
space delegated to downstream LIRs will be considered as space delegated to downstream LIRs will be considered as
“used”. However, APNIC will give careful consideration to “used”. However, APNIC will give careful consideration to
the registration of delegations made by the downstream LIR the registration of delegations made by the downstream LIR
to their customers and may request supporting documentation to their customers and may request supporting documentation
as necessary. as necessary.
5.2.4. Policies for LIR IPv6 allocation and assignment 5.2.3. Policies for LIR IPv6 allocation and assignment
—————————————————— ——————————————————
5.2.4.1. LIR-to-ISP allocation 5.2.3.1. LIR-to-ISP allocation
—————————— ——————————
There is no specific policy for an organization (LIR) to There is no specific policy for an organization (LIR) to
allocate address space to subordinate ISPs. Each LIR allocate address space to subordinate ISPs. Each LIR
organization may develop its own policy for subordinate ISPs organization may develop its own policy for subordinate ISPs
to encourage optimum utilization of the total address block to encourage optimum utilization of the total address block
allocated to the LIR. However, all /48 assignments to end allocated to the LIR. However, all /48 assignments to end
sites are required to be registered either by the LIR or its sites are required to be registered either by the LIR or its
subordinate ISPs in such a way that the RIR/NIR can properly subordinate ISPs in such a way that the RIR/NIR can properly
evaluate the HD-Ratio when a subsequent allocation becomes evaluate the HD-Ratio when a subsequent allocation becomes
necessary. necessary.
5.2.4.2. Assignment address space size 5.2.3.2. Assignment address space size
————————————– ————————————–
LIRs must make IPv6 assignments in accordance with the LIRs must make IPv6 assignments in accordance with the
following provisions. following provisions.
End-users are assigned an end site assignment from their LIR or ISP. End-users are assigned an end site assignment from their LIR or ISP.
The size of the assignment is a local decision for the LIR or ISP to The size of the assignment is a local decision for the LIR or ISP to
make, using a value of “n” x /64. make, using a value of “n” x /64.
RIRs/NIRs are not concerned about which address size an RIRs/NIRs are not concerned about which address size an
LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not
request the detailed information on IPv6 user networks as request the detailed information on IPv6 user networks as
they do in IPv4, except for the cases described in Section they do in IPv4, except for the cases described in Section
9.2.1. and for the purposes of measuring utilization as 9.2.1. and for the purposes of measuring utilization as
defined in this document. defined in this document.
5.2.4.3. Assignment of multiple /48s to a single end site 5.2.3.3. Assignment of multiple /48s to a single end site
——————————————————— ———————————————————
Assignment larger than /48 (shorter prefix) or additional assignments Assignment larger than /48 (shorter prefix) or additional assignments
exceeding a total of /48 must be made based on address usage, or because exceeding a total of /48 must be made based on address usage, or because
of different routing requirements exist for additional assignments. of different routing requirements exist for additional assignments.
In case of a review or when making a request for a subsequent allocation, the In case of a review or when making a request for a subsequent allocation, the
LIR must be able to present documentation justifying the need for assignments LIR must be able to present documentation justifying the need for assignments
shorter than a /48 to a single end site. shorter than a /48 to a single end site.
5.3. Registration requirements 5.3. Registration requirements
—————————— ——————————
5.3.1. Registration requirements for IPv4 addresses 5.3.1. Requirements for Autonomous System Numbers (ASNs) and Addresses
————————————————— —————————————————
IRs are responsible for promptly and accurately registering IRs are responsible for promptly and accurately registering their ASN and
their address space use with APNIC as follows: address space use with APNIC as follows:
– All ASNs assigned must be publicly registered in the APNIC, or relevant NIR,
Whois database, for which APNIC or NIR will create the aut-num object.
– All the attributes of the aut-num object, must be registered in accordance
with APNIC or NIR whois database documentation.
– All delegations from APNIC to the IR must be registered. – All delegations 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 for IPv4 and /48 for IPv6 must
registered. be registered.
– Delegations made to networks of a /30 or less may be – Delegations made to networks of a /30 for IPv4 and /48 for IPv6 or less may be
registered, at the discretion of the IR and the network registered, at the discretion of the IR and the network administrator.
administrator. – Delegations to hosts may be registered, at the discretion of the IR and the end-user.
– Delegations to hosts may be registered, at the discretion of
the IR and the end-user.
IRs can choose whether or not to designate this information
“public”. Customer registration details that are not designated
“public” will not be generally available via the APNIC Whois
Database. The database record will instead direct specific whois
enquiries to the IR concerned.
5.3.1.1. Updating registration details
————————————–
IRs must update their registration records when any of the
registration information changes. This is the responsibility
of the IR concerned. However, this responsibility may be
formally assigned to the end-user as a condition of the
original delegation.
5.3.2. Registration requirements for IPv6 addresses
—————————————————
When an organization holding an IPv6 address allocation makes
IPv6 address assignments, it must register assignment
information in a database, accessible by RIRs as appropriate
(information registered by an RIR/NIR may be replaced by a
distributed database for registering address management
information in future).
Information is registered in units of assigned /48 networks.
When more than a /48 is assigned to an organization, the
assigning organization is responsible for ensuring that the
address space is registered in an RIR/NIR database.
RIR/NIRs will use registered data to calculate the HD-Ratio at
the time of application for subsequent allocation and to check
for changes in assignments over time.
IRs shall maintain systems and practices that protect the
security of personal and commercial information that is used in
request evaluation, but which is not required for public
registration.
Organizations that receive an allocation from APNIC can choose
whether or not their customer assignment registrations should be
publicly available. If the organization does not indicate a
choice, or it chooses to hide its customer assignment
registrations, then those records will not be visible in the
public whois database. Whois queries on these records will
return details of the allocation.
5.3.3. Registration requirements for AS Numbers
———————————————–
All ASNs assigned must be publicly registered in the APNIC, or
relevant NIR, Whois database. APNIC, or the relevant NIR, will
create the aut-num object.
All attributes of the aut-num object must be properly registered IRs can choose whether or not to designate this information “public”. Customer registration
in accordance with the APNIC or NIR whois database details that are not designated “public” will not be generally available via the APNIC Whois
documentation. Without limiting these general requirements, database. The database record will instead direct specific whois enquiries to the IR concerned.
Section 5.3.3.1 and Section 5.3.3.2. describe particular
requirements for ASN registration.
5.3.3.1. Registering routing policy 5.3.2. Updating registration details
———————————– ————————————–
APNIC recommends that the routing policy of the AS is IRs must update their registration records and relevant objects when any of the
registered for each ASN assigned. registration information changes. This is the responsibility of the IR concerned.
However, this responsibility may be formally assigned to the end-user as a condition
of the original delegation.
5.3.3.2. Updating registration details Further, APNIC recommends that the routing policy of the AS is registered for each ASN
————————————– assigned.
Organizations responsible for ASNs should update the aut-num
object in the appropriate database if any of the
registration information changes.
5.3.4. Registering Contact Persons 5.3.3. Registering Contact Persons
———————————- ———————————-
Administrative and technical contact persons must be registered. Administrative and technical contact persons must be registered.
The registered administrative contact (“admin-c”) must be The registered administrative contact (“admin-c”) must be
someone who is physically located at the site of the network, someone who is physically located at the site of the network,
subject to the following exceptions: subject to the following exceptions:
– For residential networks or users, the IR’s technical contact – For residential networks or users, the IR’s technical contact
may be registered as the admin-c. may be registered as the admin-c.
– For networks in exceptional circumstances that make it – For networks in exceptional circumstances that make it
skipping to change at line 1364 skipping to change at line 1280
access to MyAPNIC, which allows organizations to manage their access to MyAPNIC, which allows organizations to manage their
resources and account information via a secure website. resources and account information via a secure website.
5.5.4. Policies applicable to updated Historical resources 5.5.4. Policies applicable to updated Historical resources
———————————————————- ———————————————————-
Historical Internet resources that are updated under this policy Historical Internet resources that are updated under this policy
are subject to the registration requirements as specified above. are subject to the registration requirements as specified above.
5.6. General requirements for requests 5.6. General requirements for requests
————————————— —————————————
All requests for address space must be supported by documentation In order to properly evaluate requests, APNIC must carefully examine
describing: all relevant documentation relating to the networks in question. Such
– The network infrastructure of the organization making the request, documentation may include network engineering plans, sub-netting plans,
– Any address space currently held by that organization (including descriptions of network topology, and descriptions of the network routing
Historical address space), plans.
– Previous assignments made by that organization (including
assignments made from Historical address allocations), and
– The intended use for the address space requested.
In addition to this general requirement, more specific documentation Further, based on request the following information may be requested such
may also be requested, as outlined below. as equipment invoices and purchase orders, any address space currently held
by that organization (including Historical address space), previous assignments
made by that organization (including assignments made from Historical address
allocations), and the intended use for the address space requested.
5.6.1. Documentation All documentation should conform to a consistent standard and any estimates and
——————– predictions that are documented must be realistic and justifiable.
To properly evaluate requests, IRs must carefully examine all
relevant documentation relating to the networks in question.
This documentation may include:
– Network engineering plans
– Subnetting plans
– Descriptions of network topology
– Descriptions of network routing plans
– Equipment invoices and purchase orders
– Other relevant documents
5.6.2. Security and confidentiality 5.6.1. Security and confidentiality
———————————– ———————————–
The documentation, which supports address space requests, The documentation, which supports address space requests,
involves information that may be highly confidential to the involves information that may be highly confidential to the
commercial and infrastructure operations of all Members and commercial and infrastructure operations of all Members and
their customers. their customers.
Therefore, APNIC will reflect the trust implicit in its position Therefore, APNIC will reflect the trust implicit in its position
by: by:
– applying and enforcing systems, practices, and procedures that – applying and enforcing systems, practices, and procedures that
skipping to change at line 1410 skipping to change at line 1317
customers, and customers, and
– ensuring the employment of all staff, or agents, is based upon – ensuring the employment of all staff, or agents, is based upon
an explicit condition of confidentiality regarding such an explicit condition of confidentiality regarding such
information. 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.2. Equitable processing of requests
————————————— —————————————
APNIC will only process requests that have been completely and APNIC will only process requests that have been completely and
properly documented. If the documentation contains errors or properly documented. If the documentation contains errors or
omissions, APNIC will advise the applicant as soon as possible. omissions, APNIC will advise the applicant as soon as possible.
APNIC may also request the applicant to provide further APNIC may also request the applicant to provide further
information, or clarify relevant issues that are not clear in information, or clarify relevant issues that are not clear in
the initial request. the initial request.
Once the errors and omissions are rectified, or the additional Once the errors and omissions are rectified, or the additional
skipping to change at line 2131 skipping to change at line 2038
—————————- —————————-
Organizations are eligible for an IPv6 Provider Independent Organizations are eligible for an IPv6 Provider Independent
delegation if they are able to demonstrate a valid reason that delegation if they are able to demonstrate a valid reason that
an assignment from their ISP, or LIR, is not suitable. an assignment from their ISP, or LIR, is not suitable.
For guidelines on what will be considered a valid technical or For guidelines on what will be considered a valid technical or
other reason, see “APNIC guidelines for IPv6 allocation and other reason, see “APNIC guidelines for IPv6 allocation and
assignment requests”. assignment requests”.
http://www.apnic.net/ipv6-guidelines http://www.apnic.net/ipv6-guidelines
The minimum size of the assignment is a /48. The considerations of The minimum size of the assignment is a /48 per end-site. The considerations of
Section 5.2.4.3 Assignment of multiple /48s to a single end site, must be Section 5.2.4.3 Assignment of multiple /48s to a single end-site, must be
followed if multiple /48s are requested. followed if multiple /48s are requested.
http://www.apnic.net/ipv6-guidelines http://www.apnic.net/ipv6-guidelines
10.1.4.2. Subsequent assignment 10.1.4.2. Subsequent assignment
——————————- ——————————-
Subsequent Provider Independent assignments may be delegated Subsequent Provider Independent assignments may be delegated
to organizations that are able to demonstrate to organizations that are able to demonstrate
– why an additional portable assignment is required and why – why an additional portable assignment is required and why
an assignment from an ISP or other LIR cannot be used for an assignment from an ISP or other LIR cannot be used for
 End of changes. 40 change blocks. 
188 lines changed or deleted 95 lines changed or added

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