APNIC Numeric Internet Resource Policies

divisionimpossibleNetworking and Communications

Oct 24, 2013 (3 years and 7 months ago)

163 views

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
1

of
36

APNIC
Numeric Internet
Resource Pol
i
cies

Document Version

a
pnic
-
xxx
-
v001


APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
2

of
36

APNIC Document identity

Title:

APNIC Numeric
Internet
Resource Policies

Short title:

apnic
-
resource
-
policies

Document ref:

APNIC
-
XXX

Version
:

0
01

Date of
original publication:

TBC

Date of this version:

TBC

Review scheduled:

n/a

Obsoletes
:

APNIC
-
125

APNIC
-
124

APNIC
-
123

APNIC
-
109

APNIC
-
094

APNIC
-
089

Status:

Draft

Comments
:

Initial draft

Table of Contents

1. Introduction

................................
................................
................................
................................
....

7

1.1. Scope

7


Additional guidelines and policies

7

1.1.1.

Private address space

7

1.1.2.
1.2. Hierarchy of resource distribution

8

2. Definitions
................................
................................
................................
................................
.......

9

2.1. Internet Registry (IR)

9


Regional Internet Registry (RIR)

9

2.1.1.

National Internet Registry (NIR)

9

2.1.2.

Local Internet Registry (LIR)

9

2.1.3.
2.2. Address space

9


Delegated address space

9

2.2.1.

Allocated address space

10

2.2.2.

Assigned address space

10

2.2.3.
2.3. Autonomous System (AS)

10


Autonomous System Number (ASN)

10

2.3.1.
2.4. Multihomed

10

2.5. Internet resources

10


Current resources

10

2.5.1.

Historical resources

10

2.5.2.
2.6. Internet Exchange Point (IXP)

11

2.7.

Usage rate

11

2.8. Utilization

11


HD
-
Ratio

11

2.8.1.
2.9. End site

11

2.10. aut
-
num object

11

2.11. Routing policy

11

2.12. Transfers

12

APNIC Numeric Internet Re
source Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
3

of
36


Counterpart RIR

12

2.12.1.

Source

12

2.12.2.

Recipient

12

2.12.3.
3. Policy framework

................................
................................
................................
.........................

13

3.1. Goals of address space management

13


Uniqueness

13

3.1.1.

Registration

13

3.1.2.

Aggregation

13

3.1.3.

No guarantee of contiguous delegations

14

3.1.4.

Conservation

14

3.1.5.

Fairness

14

3.1.6.

Minimized Overhead

14

3.1.7.

Conflict of goals

14

3.1.8.
3.2. Policy Environment

14


Routability

14

3.2.1.

Internet growth rates

15

3.2.2.

Collective responsibility

15

3.2.3.

Impartiality

15

3.2.4.

Varying levels of expertise

15

3.2.5.

Address ownership

15

3.2.6.

Address stockpiling

15

3.2.7.

Reservations not supported

15

3.2.8.

Evaluations to be based on best practice

15

3.2.9.

Minimum practical delegation

16

3.2.10.

Slow start mechanism

16

3.2.11.

Exceptions to slow start

16

3.2.11.1.
3.3. Organizations seeking address space from multiple IRs

16

4. Resource License

................................
................................
................................
........................

17

4.1. License Renewal

17


Review

17

4.1.1.

Validity of IP address delegations

17

4.1.2.
4.2. Closure and recovery

18


Recovery of unused historical address space

18

4.2.1.

Recovery of unused historical ASNs

18

4.2.2.
5. Resource Management

................................
................................
................................
...............

19

5.1. How APNIC manages address space

19


Reservation for future uses

19

5.1.1.

Sparse allocation framework

19

5.1.2.

IPv4 addresses returned to APNIC

19

5.1.3.
5.2. LIR address space management

19


Assignment window for LIRs

19

5.2.1.
APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
4

of
36


IPv4 Delegations to do
wnstream IRs

19

5.2.2.

Effect of delegation to downstream IRs on upstream LIR's usage rate

20

5.2.2.1.

Policies for LIR IPv6 allocation and assignment

20

5.2.3.

LIR
-
to
-
ISP allocation

20

5.2.3.1.

Assignment address space size

20

5.2.3.2.

Assignment of multiple /48s to a single end site

20

5.2.3.3.

Assignment to operator's infrastructure

20

5.2.3.4.
5.3. Registration requirements

20


Requirements for IPv4 addresses

20

5.3.1.

Updating registration details

21

5.3.1.1.

Registering contact persons

21

5.3.1.2.

Registration requirements for IPv6 addresses

21

5.3.2.

Registration r
equirements for AS Numbers

21

5.3.3.

Registering routing policy

22

5.3.3.1.

Updating registration details

22

5.3.3.2.
5.4. Reverse lookup

22


Responsibility to maintain IPv4 in
-
addr.arpa records

22

5.4.1.

IPv6 reverse lookup

22

5.4.2.
5.5. Managing Historical resources

22


Utilization of Histo
rical IPv4 address space

22

5.5.1.

Protecting Historical records in the APNIC Whois Database

22

5.5.2.

Procedure for updating Historical registrations

22

5.5.3.

Policies applicable to updated Historical resources

23

5.5.4.
6. Resource requests
................................
................................
................................
.......................

24

6.1. General requirements for requests

24


Documentation

24

6.1.1.

Security and confidentiality

24

6.1.2.

Equitable processing of requests

24

6.1.3.

Processing dependent on correct documentation

24

6.1.3.1.
6.2. Cr
iteria for initial delegations

25


Criteria for initial IPv4 delegations

25

6.2.1.

Minimum IPv4 delegation

25

6.2.1.1.

IPv4 address usage estimates

25

6.2.1.2.

Initial LIR delegation

25

6.2.1.3.

IPv4 for multihoming

25

6.2.1.4.

IPv4 for critical infrastructure

25

6.2.1.5.

IPv4 for Internet Exchange Points

26

6.2.1.6.

Criteria for initial IPv6 delegations

26

6.2.2.

Minimum IPv6 allocation

26

6.2.2.1.

Consideration of IPv4 infr
astructure

26

6.2.2.2.

Initial IPv6 block for APNIC Members with existing IPv4 space

26

6.2.2.3.

Criteria for initial IPv6 allocation for those without IPv4 space

26

6.2.2.4.
APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
5

of
36

6.3. Criteria for subsequent delegations

27


Subsequent IPv4 delegations

27

6.3.1.

Prior delegations
to be used first

27

6.3.1.1.

Special circumstances
-

large delegations

27

6.3.1.2.

Subsequent IPv6 allocations

27

6.3.2.

Existing IPv6 address space holders

27

6.3.2.1.

Applied HD
-
Ratio

27

6.3.2.2.

Alternative allocation criteria

27

6.3.2.3.

Subsequent allocation size

28

6.3.2.4.

Criteria for IPv6 assignments

28

6.3.3.

Criteria for small multihoming delegations

28

6.3.3.1.

IPv6 critical infrastructure

28

6.3.3.2.

IPv6 Internet Exchange

Points

28

6.3.3.3.

Provider Independent assignment

28

6.3.3.4.
6.4. ASN assi
gnments

29


Evaluation of eligibility

29

6.4.1.

Requesting an ASN

29

6.4.2.

Using ASN for own network

29

6.4.3.

Providing ASN to customer

29

6.4.4.

Two
-
byte only and four
-
byte AS Numbers

30

6.4.5.
6.5. Experimental allocations policy

30


Introduction

30

6.5.1.

Scope and goal

30

6.5.1.1.

Allocations for experimental purposes

30

6.5.2.

Publication of an experimental RFC

30

6.5.2.1.

Alternativ
e publication approved by APNIC

30

6.5.2.2.

Experimental allocations

31

6.5.3.

Public disclosure of experiment

31

6.5.3.1.

Size of IP allocations

31

6.5.3.2.

APNIC input on proposed experiment

31

6.5.3.3.

Duration of allocation licenses

31

6.5.3.4.

Extension of license

31

6.5.3.5.

Registration

31

6.5.4.

Restriction on commercial or undocumented uses

31

6.5.4.1.

Fees for experimental allocation
s

31

6.5.5.
7. Resource Transfers

................................
................................
................................
.....................

32

7.1. Transfers of IPv4 addresses betwee
n APNIC account holders

32


Conditions on the space to be transferred

32

7.1.1.

Conditions on source of the transfer

32

7.1.2.

Conditions on recipient of the transfer

32

7.1.3.
7.2. Inter
-
RIR IPv4 address transfers

32


Conditions on the spac
e to be transferred

32

7.2.1.
APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
6

of
36


Conditions on the source of the transfer

33

7.2.2.

Conditions on the recipient of the transfer

33

7.2.3.
7.3. Transfer of Historical Internet resources

33


Transfer procedure

33

7.3.1.

Policies applicable to transferred resources

33

7.3.2.
7.4. Mergers, acquisitions, and takeovers o
f LIRs

34


Updating registration details

34

7.4.1.

Effect on me
mbership agreement

34

7.4.2.

Consequences for allocations

34

7.4.3.
Appendices

Appendix A

: HD
-
Ratio

................................
................................
................................
....................

35

Table of Figures

Figure 1.1 Diagram of distribution hierarchy

8

Table of Tables

Table 7.1

IPv6 HD
-
Ratio of 0.94 equivalents

36



APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
7

of
36

1.

Introduction

The Asia Pacific Network Information Centre (APNIC) is the Regional Internet Registry (RIR) for the Asia
Pacific
. It is
responsible for
the regional
distributi
o
n

of

public Internet address space and related resources,
including
Internet Protocol version 4 (IPv4) address space, Internet Protocol version 6 (IPv6) address space,
and
Autonomous System Numbers (ASNs)
. APNIC
also
coordinates

the development and implementat
ion of
policies to manage those resources.

This document outlines the overall principals and goals of Internet number resource distribution
it also

details
specific policies for the distribution and management of these resources
in the Asia Pacific region.

The policies and definitions described in this document were developed by the Internet community of the
Asia Pacific region through a consensus process facilitated by APNIC. The

policies

are to be implemented
by APNIC, by National Internet Registries (NIR
s)
,

and by Local Internet Registries (LIRs) throughout the
region.

1.1.

Scope

This

document

describes policies for the responsible management of global
numeric Internet resources in
the Asia Pacific region.

Specifically, this document focuses on policies relati
ng to:



T
he delegation of
Internet Protocol

version 4 (IPv4) address space.



T
he
allocation and assignment of
Internet Protocol version 6 (IPv6) address space,
specifically



IETF RFCs
[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast address space

that
IANA may allocate to the RIRs. In accordance with [RFC2928, RFC2373bis, IAB
-
Request], IANA
has allocated initial ranges of global unicast IPv6 address space from the 2001::/16 address block to
the existing RIRs. This document concerns the initial and

subsequent allocations of the 2000::/3
unicast address space, for which RIRs formulate allocation and assignment policies.



T
he assignment of Autonomous System Numbers (ASNs)
.


Additional guidelines

and policies

1.1.1.
This document
should

be read in conjunction
with other APNIC documents, policies, and guidelines;
including those dealing with membership and fees.

In addition to the eligibility
criteria

described in
this document
, APNIC may publish other
information

relating to
Internet number resources
, including
:



further

descriptions

of evaluation procedures;



summaries of the best current practices that organizations requesting
resources
will generally be
expected to adopt; and



other information that may assist organizations to request
resources
.

This document
does not provide specific details of request evaluation by APNIC, or of expectations
relating to specific technologies. Such details are dependent on technological advances, and may
change frequently. Therefore, to assist organizations to request address s
pace, APNIC will publish
separate guideline documents relating to specific technologies or techniques as required.

Any guidelines published will be developed within the APNIC community, and will be consistent with
the goals and policies described in this d
ocument.


Private address space

1.1.2.
This document does not describe specific addressing policies related to
m
ulticast

or
p
rivate
a
ddress
sp
ace. The use of private address space may be appropriate for addressing networks that are
connected to the Internet via a
firewall, and where there are not technical requirements for the use of
public address space. In general, private address space should be used for networks not connected to
the Internet.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
8

of
36

1.2.

Hierarchy of
resource
distribution

IP addresses
and ASNs
are
distributed in accordance with the hierarchical structure described in
RFC2050, represented simply in fig.1.


Figure 1.1

Diagram of distribution hierarchy

In this hierarchy, IANA allocates address space to APNIC, to be redistributed throughout the Asia Pacific
regio
n. APNIC allocates address space to Internet Registries (IRs) and also delegates to them
,

the
authority to make assignments and allocations. In some cases APNIC assigns address space to end
users. National and Local IRs allocate and assign address space to

their
M
embers and customers under
the guidance of APNIC and in accordance with the relevant policies and principals described in this
document.

APNIC

Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
9

of
36

2.

Definitions

The following terms and definitions are used in APNIC documents.

2.1.

Internet Registry (IR)

An Internet

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

I
nternet
R
egistrie
s include:



APNIC and other
Regional

Internet Registries (RIRs)



National Internet Registries (NIRs)



Local Internet Registries (LIRs
).


Regional Internet Registry (RIR)

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


National Internet Registry (NIR)

2.1.2.
National Internet Registr
ies

(NIR
s
)

are established and authorized by
their
respective regional
communi
ties, and recognized by

RIRs to delegate
address space to
their

M
embers or constituents,
which are generally LIRs organized at a national level.

NIRs are expected to apply their policies and
procedur
es fairly and equitably to all M
embers of their constitue
ncy.

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

including;



Criteria for the recognit
ion of NIRs in the APNIC region



http://www.apnic.net/policy/nir
-
criteria



Operational policies for NIRs in the APNIC region



http://www.apnic.net/policy/operational
-
policies
-
ni rs



APNIC and
NIR
Membership
Relationship
Agreement



http://www.apnic.net/nir
-
agreement


Local Internet Registry (LIR)

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

LIRs are

generally Internet Service Provider
s

(ISP
s
), and may assign address space to
their
own
network infrastructure and to users of
their

network services.
An
LIR
'
s

customers may be other
"
downstream
"

ISPs, which further assign address space to their own custom
ers.

2.2.

Address space

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


Delegated address space

2.2.1.
APNIC
"
delegates
"

addresses to its account holders. These delegations can be for u
se on the
organization
'
s own infrastructure (an
"
assignment
"
) or for subsequent delegation by the organization to
its customers (an
"
allocation
"
).

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
10

of
36


Allocated

address space

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


Assigned

address space

2.2.3.
Assigned address space is address space that is delegated to an
LIR

or end
-
user, for specific use
within the Internet infrastructure they operate. Assignments must only be mad
e for specific,
documented purposes and may not be sub
-
assigned.

2.3.

Autonomous System (AS)

An Autonomous System (AS) is a connected group of one or more IP prefixes run by one or more network
operators under a single and clearly
-
defined routing policy.


Autono
mous System Number (ASN)

2.3.1.
An Autonomous System Number (ASN) is a unique two
-

or four
-
byte number associated with an AS.
The ASN is used a
s a
n identifier to allow the AS to exchange dynamic routing information with other
Autonomous Systems. Exterior routing
protocols
,

such as the Border Gateway Protocol (BGP)
, require

ASNs to exchange information between networks.

2.4.

Multihomed

Multihoming is the practice of maintaining more than one connection to the public Internet.



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 rou
ting prefixes announced by at least two of its ISPs.

2.5.

Internet

resources

Internet resources are public IPv4 and IPv6 address numbers,

Autonomous System
N
umbers, and reverse
DNS delegations.


Current resources

2.5.1.
Current resources are Internet resources register
ed by APNIC under explicit policies and agreements
.


Historical resources

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



Registrations transferred to APNIC as part of the AUNIC to
APNIC migration



Some historical resource registrations have been inherited by APNIC from the

former AUNIC
address registry.



A list of resources transferred to APNIC as part of the migration is available
on the APNIC
website at
http://www.apnic.net/aunic
.



R
egistrations transferred as part of the Early Registration Transfer (ERX) project



Most historical registrations were initially made by the global registries that predated ARIN, such
as DDN
-
NIC, SRI
-
NIC, and InterNIC. ARIN inherited these registrations auto
matically when it
was established. Historical registrations made to organizations in the APNIC region were
transferred to APNIC during 2003 and 2004 as part of the RIRs
'

Early Regis
tration Transfer
(ERX) project.



A list of resources transferred to APNIC as

part of the ERX project

is available at
http://www.apnic.net/erx
.



Historical APNIC resources

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
11

of
36



Historical APNIC resources were delegated to organizations by APNIC prior to the introduction
of a membership structure. These resources have always been register
ed in the APNIC Whois
Database, but if the resource holder did not become an APNIC
M
ember at any time after the
introduction of the membership structure, the resources were not made subject to current APNIC
policies.

2.6.

Internet Exchange Point (IXP)

An Inter
net Exchange Point (IX or IXP) is a layer 1 and layer 2 network structure that interconnects three or
more Autonomous Systems (AS) for the purpose of Internet traffic interchange.

2.7.

Usage rate

In IPv4 policy usage rate is the rate at which the LIR made delegations from relevant past address space,
including
H
istorical delegations.

2.8.

Utilization

Similar to usage rate in IPv4 policy, utilization is a measure of
address

usage

in IPv6 policy. The actu
al
usage
within each assignment will be quite low, when compared to IPv4 assignments
, because in IPv6
policy

"
utilization
"

is only measured in terms of the bits to the left of the /56 boundary. In other words,
utilization refers to the assignment of /56s t
o 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 w
ithin those end sites.


HD
-
Ratio

2.8.1.
The HD
-
Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an
adaptation of the H
-
Ratio originally defined in [RFC1715] and is expressed as follows:


Log (number of allocated object
s)

HD =
------------------------------------------------



Log (maximum number of allocatable objects)

where (in the case of this document) the objects are IPv6 site addresses (/56s) assigned from an IPv6
prefix of a given size.

2.9.

End site

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



that service provider assigning address space to the end user



that service provider providing transit service for the end user to other sites



that service provider carrying the end user
'
s traffic



that service provider advertising an aggregate prefix route that contains the end user
'
s assignment

2.10.

aut
-
num object

An aut
-
num object is an object in the Whois database used to register ASN assignment de
tails. For the
purposes of this document, aut
-
num object also refers to the ASN registration objects in NIR databases.

2.11.

Routing policy

The routing policy of an AS is a description of how network prefixes are exchanged between that AS and
other Autonomous Sy
stems.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
12

of
36

2.12.

Transfer
s

Resource transfers
involve

the re
-
allocation of current address blocks, or the re
-
allocation of historical
resources claimed and transferred to an APNIC account.


Counterpart RIR

2.12.1.
A counterpart RIR is the Regional Internet Registry that APNI
C transfers the IPv4 address space to, or
from, in an inter
-
RIR IPv4 transfer.


Source

2.12.2.
The source in a resource transfer is the organization which, prior to the transfer, is the legitimate
holder of the resources to be transferred. Where the source is in th
e APNIC region, the source must
be a current APNIC account holder
,

except in the case of an Historical resource transfer
. Where the
source is from another RIR region, it must be that RIR
'
s equivalent to the
"
source
"

as defined here.


Recipient

2.12.3.
The recipient

in a resource transfer is the organization which, after the transfer is completed, will be
the legitimate holder of the resources to be transferred. Where the recipient is in the APNIC region,
the recipient must be a current APNIC account holder. Where th
e recipient is from another RIR region,
it must be that RIR
'
s equivalent to the
"
recipient
"

as defined here.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
13

of
36

3.

Policy
framework

IP address space is a public resource that must be managed in a prudent manner with regards to the long
-
term interests of the
internet. Responsible address space management involves balancing a set of
sometimes competing goals. The following are the goals relevant to address policy.

3.1.

Goals of address space management

The goals described here were formulated by the Internet communi
ty and reflect the mutual interest of all
members of that community in ensuring that the Internet is able to function and grow to the maximum
extent possible.

It is APNIC
'
s primary duty, as a custodian of a public resource, to ensure that these goals are m
et within
the Asia Pacific region. APNIC does this by providing guidance and leadership in developing and
implementing responsible policies and practices.

It is the responsibility of every NIR and LIR to also ensure that these goals are met within their re
spective
regions and communities.


Uniqueness

3.1.1.
Every assignment and allocation of address space must be guaranteed as globally unique. This is an
absolute requirement for ensuring that every public host on the Internet can be uniquely identified.


Registratio
n

3.1.2.
All assignments and allocations made directly by APNIC to its Members and customers must be
registered in a publicly accessible database. This is necessary to ensure uniqueness and to provide
information for Internet troubleshooting at all levels
,
ranging from all RIRs and IRs to end users
.

It also reflects the expectation of the Internet community that custodians of these public resources
should be identifiable.

The goal of registration should be applied within the context of reasonable
privacy con
siderations and applicable laws.

Organizations that receive an allocation from APNIC can
choose whether or not their customer assignment registration
s should be publicly available.

If the organization does not indicate a choice, or it chooses to hide its c
ustomer 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.


Aggregation

3.1.3.
A
ddress policies should seek to avoid fragmentation of address ranges.

Wherever possible, address space should be distributed in a hierarchical manner, according to the
topology of network infrastructure. This is necessary to permit the aggregation of routing information
by network operators, and to limit the expansion of Int
ernet routing tables.

This goal is particularly important in IPv6 addressing, where the size of the total address pool creates
significant implications for both internal and external routing.

It is a condition of all delegations made under initial or subse
quent LIR delegation criteria, that the
address space is aggregated by the LIR within a minimum number of route announcements
(preferably one).

LIRs must only delegate addresses to customers who will be using those addresses in relation to
network connecti
vity services provided by the LIR.

LIRs are expected to enter into agreements with their customers specifying that the end
-
user will hold
the addresses only for so long as the end
-
user remains a customer of that LIR. Such agreements
should also be consiste
nt with the license under which the address
space is being used by the LIR.

APNIC Numeric Internet
Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
14

of
36


No guarantee of contiguous delegations

3.1.4.
RIRs should apply practices that maximize the potential for subsequent allocations to be made
contiguous with past allocations currently held
. However, there can be no guarantee of contiguous
allocation.

APNIC will attempt to make any subsequent delegations contiguous with previous delegations, but
cannot guarantee that this will be possible.


Conservation

3.1.5.
To maximize the lifetime of the availab
le resource, address space must be distributed according to
actual need and for immediate use. Stockpiling address space and maintaining reservations are
contrary to this goal. Conservation also implies efficiency. Therefore, all users of address space
sho
uld adopt techniques such as Variable Length Subnet Masking (VLSM) and appropriate
technologies that ensure the address space is not used wastefully.

Although IPv6 provides an extremely large pool of address space, address policies should avoid
unnecessari
ly wasteful practices. Requests for address space should be supported by appropriate
documentation and stockpiling of unused
IPv6
addresses should
also
be avoided.


Fairness

3.1.6.
All policies and practices relating to the use of
public
address space should apply

fairly and equitably
to all existing and potential members of the Internet community, regardless of their location,
nationality, size, or any other factor.



Minimized Overhead

3.1.7.
It is desirable to minimize the overhead associated with obtaining address spac
e. Overhead includes
the need to go back to RIRs for
additional space too frequently. There is

overhead associated with
managing address space that grows through a number of small successive incremental expansions
rather than through fewer, but larger, exp
ansions.


Conflict of goals

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

This document is intended to help IRs perform their role in consistent and equitable ways. IRs must
maintain full documentation of and
transparency within the decision
-
making process.

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

3.2.

Policy Environment

Apart from the goals described
above
, other factors influence the APNIC policy environment. These ot
her
factors include the expectations of the Internet community, current administrative structures, and
technological constraints.

The policy environment may change quickly or in unpredictable ways, so APNIC, on behalf of its Members,
must monitor any
changes and communicate any policy implications.

This s
ection describes the factors in the current operating environment that have been most important in
determining current APNIC policies.


Rout
ability

3.2.1.
There is no guarantee that any address allocation or a
ssignment will be globally routable.

The routability of address space throughout the Internet can never be guaranteed by any single
organization.
However,
IRs must apply procedures that reduce the possibility of fragmented address
space which may lead to a

loss of routability.


APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
15

of
36

To reduce the number of globally advertised routes, network operators may implement route filtering
policies based on prefix length. As a result, small portable assignments are the most likely to suffer
routability problems. Therefor
e, APNIC policies encourage those seeking address space to request
from upstream providers rather than from APNIC directly.

The r
esponsible

management

of ASNs is
also
necessary to help limit the expansion of global routing
tables. Aggregating contiguous IP

address prefixes within single Autonomous Systems helps to
minimize the number of routes announced to the global Internet.


Internet growth rates

3.2.2.
Early strategies for distributing address space did not anticipate the rapid growth of the Internet and
the sc
aling problems that followed, affecting both the amount of address space available and routing.
Therefore, APNIC policies take account of past experience and seek to manage address space in a
way that will maximize future scaling of the Internet.


Collectiv
e responsibility

3.2.3.
APNIC shares with its Members and their customers a collective responsibility to ensure manageable
and scalable Internet growth and to make decisions consi
stent with the goals described
here
.
Therefore, APNIC policies and procedures are de
veloped by APNIC Members and the broader
Internet community as a whole, in the common interest of those communities.

In implementing policies, APNIC and its Members rely on an implicit trust that delegated
responsibilities are carried out in good faith. S
pecifically, APNIC must trust that the information
gathered from Members during the request process is genuine and accurate.


Impartiality

3.2.4.
APNIC represents the interests of the Internet community in general and the Internet community of the
Asia Pacific reg
ion in particular. Therefore, APNIC must apply its policies fairly and equitably, without
regard to an organization
'
s size, geographic location, or any other factor.


Varying levels of expertise

3.2.5.
Different IRs and end
-
users have varying levels of experience
and expertise. APNIC policies allow for
varying levels of assistance and monitoring, appropriate to ensure a consistent approach to address
space management throughout the Asia Pacific Internet community.


Address ownership

3.2.6.
The Internet community regards ad
dress space as a scarce, public resource that should only be
distributed according to demonstrated need. ISPs and other organizations and individuals that use
address space are considered
"
custodians
"

rather than
"
owners
"

of the resource. As address space
becomes more scarce, address space management policies may be adjusted by the community.


Address stockpiling

3.2.7.
Stockpiling addresses is harmful to the goals of conservation and fairness. APNIC policies must
prevent stockpiling and ensure efficient deployment

of address space on the basis of immediate
demonstrated need.


Reservations not supported

3.2.8.
When an LIR wants to delegate address space for customers, it must use any address space it
currently holds.

When evaluating address requests, reserved address space
is not considered to be delegated.


Evaluations to be based on best practice

3.2.9.
APNIC should ensure that address space holders adopt current best practice in the management of
the resources they use. If appropriate technologies exist for improved management of

address space
APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
16

of
36

in particular situations, the community expects that those technologies should be used. APNIC
consults with its Members and the broader Internet community to define and develop current best
practice recommendations relating to Internet addre
ssing technologies and techniques.


Minimum practical delegation

3.2.10.
Because the goals of aggregation and conservation conflict, it is necessary to apply a minimum
practical size for address space delegation. This minimum size may be reviewed from time to time,

as
technologies and administrative conditions evolve.


Slow start mechanism

3.2.11.
APNIC and NIRs apply a slow start mechanism to all new LIRs. The slow start is applied to prevent
delegations of large blocks of address space that may then remain substantially
unused.


Exceptions to slow start

3.2.11.1.
In exceptional circumstances, an LIR may receive a greater initial delegation if it can demonstrate
that its immediate need for address space exceeds the standard slow start delegation.

The documentation required to justify

an exception to the slow start may include (but is not limited
to):



Receipts for the purchase of equipment, Purchase
O
rders, or



Signed project contracts indicating the immediate network requirements to be met by the LIR.

3.3.

Organizations seeking address
space from multiple IRs

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

In certain circumstances (for example, where an organization is multihomed), strong technical reasons
may justify an organization receiving address space from more than
one source.

For the purposes of this section, a parent organization and its subsidiaries are considered to be a single
organization. Exceptions may arise in cases where the parts of the organization:



Are separate legal entities,



Maintain fully independent
network infrastructures and are routed under different ASNs, or



Can otherwise demonstrate a justified need to obtain address space from more than one IR.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
17

of
36

4.

Resource License

It is contrary to the goals of this document and is not in the interests of the Inter
net community as a whole for
address space to be considered freehold property.

Internet
resources are
regard
ed

as public resource
s

that
should only be distributed according to demonstrated need.

The policies in this document are based upon the understandin
g that 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
"

rather than
"
owners
"

of the resource, and are no
t
entitled to sell or otherwise transfer that resource to other parties

outside the provisions in this document
.

Specifically, IP addresses
and AS numbers
will be allocated and assigned on a license basis, with licenses
subject to renewal on a periodic bas
is.

The conditions of all licenses are described in the APNIC membership agreements, service agreements, and
other relevant APNIC documents.


4.1.

L
icense

Renewal

APNIC
will

delegate Internet resources on a
'
license
'

basis, with such licenses to be of specific limited
duration (normally one year).

The granting of a license is subject to specific conditions applied at the start
or renewal of the license.

IRs

will generally renew licenses automatically, provided request
ing organizations are making a good
-
faith
effort at meeting the criteria under which they qualified for or were granted an allocation or assignment.

Licenses to organizations shall be renewable on the following conditions:



The original basis
of

the delegation remains valid, and



That address space is properly registered at the time of renewal.


Review

4.1.1.
I
n those cases where a requesting organization is not using the address space as intended, or is
showing bad faith in following through on the assoc
iated obligation,
IRs

reserve the right to not renew
the license.

However, i
ndividual licenses shall only be subject to review if the relevant IR has reason
to believe that the existing license terms are no longer being complied with. IRs may implement the
ir
own procedures for the review of existing licenses as they see fit.

Note that when a license is renewed, the new license will be evaluated under and governed by the
applicable address policies in place at the time of renewal, which may differ from the p
olicy in place at
the time of the original allocation or assignment.
When a license is renewed, the new license will be
subject to address space 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 consensus of APNIC Members, in
accordance with the APNIC Document
Editorial
Polic
y
.


Validity of IP address d
elegations

4.1.2.
An allocation or assignment of address space is valid only while the original criteria on which the
allocation or assignment was based continue to be valid.

An allocation or assignment becomes invalid if it is:



Made for a specific purpose that n
o longer exists, or



Based on information that is later found to be false or 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.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
18

of
36

4.2.

Closure
and recovery

If an LIR holding APNIC address space ceases to provide Internet connectivity services, all of its address
space must be returned to APNIC. I
t is the responsibility of the LIR (or any liquidator or administrator
appointed to wind up the Member
'
s business) to advise all of its customers that address space will be
returned to APNIC, and that renumbering into new address space will be necessary.

I
n the case that a new LIR takes over the business or infrastructure of the closed LIR, the existing address
space may be transferred to the new LIR, however such a transfer is subject to re
-
examination by APNIC
and may be treated as a new address request p
rocess.


Recovery

of unused
h
istorical address space

4.2.1.
A significant amount of historical address space registered in the APNIC Whois Database is not
announced to the global
routing

table. To recover these globally unrouted resources and place them
back in th
e free pool for reallocation to other networks, APNIC will contact networks responsible for
H
istorical address space in the APNIC region that has not been globally routed since 1 January 1998.


Recovery of unused historical
ASN
s

4.2.2.
A significant amount of hist
orical Autonomous System (AS) numbers registered in the APNIC Whois
Database
are
not announced to the global routing table. To recover these globally unrouted resources
and place them back in the free pool for reassignment to other networks, APNIC will con
tact networks
responsible for historical address space in the APNIC region that has not been globally used for a
reasonable period of time.

APNIC Numeric Internet Resource Policie
s

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
19

of
36

5.

Resource

Management

All NIRs and LIRs that receive address space from APNIC (either directly or indirectly) must
adopt delegation
policies that are consistent with the policies described in this document.

NIRs and LIRs must ensure that address space for which they are responsible is only allocated or assigned
subject to agreements consistent with th
e license provisio
ns in

this document.

Also, NIRs must, wherever
possible, apply slow start, assignment window, and second opinion policies to their own members in a
manner consistent with the way APNIC applies such policies.

5.1.

How APNIC manages address space


Reservation for
future uses

5.1.1.
A /16

of IPv4 address space
will be held in reserve for future uses, as yet unforeseen.

If the reserved /16 remains unused by the time the remaining available space has been delegated, the
/16 will be returned to the APNIC pool for distribution

under the policies described in

this document
.


Sparse allocation framework

5.1.2.
APNIC will document the sparse allocation algorithm framework used to select IPv6 address blocks for
delegation, in document apnic
-
114: APNIC guidelines for IPv6 allocation and ass
ignment requests.
This document is available at the following URL:

http://www.apnic.net/ipv6
-
guideli nes


IPv4 addresses returned to APNIC

5.1.3.
Any IPv4 resources received by APNIC will be placed into the APNIC IPv4 pool for delegation under
the policies describe
d in
this document
. This placement applies to any IPv4 addresses APNIC
receives from IANA and/or holders of addresses in the APNIC Whois Database, subject to any future
global policy for the redistribution of addresses received by IANA from the RIRs.

5.2.

LIR a
ddress space management

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


Assignment window for LIRs

5.2.1.
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 mus
t 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.


IPv4
Delegations to downstream IRs

5.2.2.
LIRs may delegate address s
pace to their downstream customers, which are operating networks, such
as ISPs, subject to the following conditions:

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
20

of
36



Delegations

are non
-
portable and must be returned to the LIR if the downstream customer ceases to
receive connectivity from the LIR.



Delega
tions 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 delegate the address spac
e.


Effect of delegation to downstream IRs on upstream LIR's usage
rate

5.2.2.1.
For the purposes of evaluating

the LIR
'
s usage
rate,
address space delegated to downstream LIRs
will be considered as
"
used
"
. However, APNIC will give careful consideration to the
registration of
delegations made by the downstream LIR to their customers and may request supporting
documentation as necessary.


Policies for LIR IPv6 allocation and assignment

5.2.3.

LIR
-
to
-
ISP allocation

5.2.3.1.
There is no specific policy for an organization (LIR) to
allocate address space to subordinate ISPs.
Each LIR organization may develop its own policy for subordinate ISPs to encourage optimum
utilization of the total address block allocated to the LIR. However, all /48 assignments to end sites
are required to be

registered either by the LIR or its subordinate ISPs in such a way that the
RIR/NIR can properly evaluate the HD
-
Ratio when a subsequent allocation becomes necessary.


Assignment address space size

5.2.3.2.
LIRs must make IPv6 assignments in accordance with the fol
lowing

provisions.

End
-
users are assigned an end site assignment from their LIR or ISP. The exact size of the
assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when
only one subnet is anticipated for the end site) u
p to the normal maximum of /48, except in cases
of extra large end sites where a larger assignment can be justified.

RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly,
RIRs/NIRs will not request the detailed info
rmation on IPv6 user networks as they d
o

in IPv4,
except for the cases described in Section
6.2.2.2
.

and for the purposes of measuring utilization as
defined in this document.


Assignment of multiple /48s to a single end site

5.2.3.3.
When a single end site requires

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

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


Assignment to operator
'
s infrastructure

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

5.3.

Registration requirements


R
equirements

for IPv4 addr
esses

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



All delegations from APNIC to the IR must be registered.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
21

of
36



All delegations to downstream IRs must be registered.



Delegations made to networks gre
ater than a /30 must be registered.



Delegations made to networks of a /30 or less may be registered, at t
he discretion of the IR and the
network administrator.



Delegations to hosts may be registered, at the discretion of the IR and the end
-
user.

IRs can ch
oose 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.

In addition, it is mandatory to register an Incident Report Team (IRT) object for each address block
record in the APNIC Whois Database.


Updating registration details

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


Registering contact persons

5.3.1.2.
Administrative and technical contact persons m
ust 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 si
te of the network, but must
be a person who is responsible for the day
-
to
-
day operation of the network.



Registration requirements for
IPv6
addresses

5.3.2.
When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must
register a
ssignment 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
man
agement 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 requi
red 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 cust
omer 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.

In addition, it is mandatory to register an Incident Report Team (IRT) object for each

allocation and
assignment record in the APNIC Whois Database.


Registration requirements

for AS Numbers

5.3.3.
All ASNs assigned must be publicly registered in the APNIC, or relevant NIR, Whois database.
APNIC, or the relevant NIR, will create the

aut
-
num object
.

All attributes of the aut
-
num object must be properly registered in accordance with the APNIC or NIR
w
hois database documentation. Without limiting these general requirements,
Section
5.3
.
3.
1 and
Section 5.
3.3
.2.

describe particular requirements for ASN
registration.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
22

of
36

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 si
te 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 Report Team (IRT) obj
ect for each AS
N
umber
record in the APNIC Whois Database.


Registering routing policy

5.3.3.1.
APNIC recommends that
the routing

policy of the AS is registered for each ASN assigned.


Updating registration details

5.3.3.2.
Organizations responsible for ASNs should update the

aut
-
num object in the appropriate database
if any of the registration information changes.

5.4.

Reverse lookup


Responsibility to maintain

IPv4

in
-
addr.arpa records

5.4.1.
LIRs should maintain in
-
addr.arpa resource records for their customers
'

networks. If a network is not
specifically associated with an LIR then the in
-
addra.arpa records should be maintained by either the
appropriate NIR or APNIC.


IPv6
r
everse lookup

5.4.2.
When an RIR/NIR delegates IPv6 address space to an organization, it also dele
gates the
responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address
space. Each organization should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assig
nee organization, upon request, the
responsibility to manage the reverse lookup zone that corresponds to the assigned address.


5.5.

Managing
Historical
r
esources

Historical resources were often delegated to organizations in a policy environment quite different

to
those in use today. Historical resource holders should be aware of the current goals of Internet
resource management

as outlined in this document
.

Th
e following policies
specifically apply to
H
istorical resources.


Utilization of
H
istorical IPv4 address

space

5.5.1.
Utilization of
H
istorical IPv4 address space is taken into account when any organization holding
H
istorical IPv4 addresses requests more IPv4 from APNIC.


Protecting
H
istorical records in the APNIC Whois Database

5.5.2.
APNIC will protect all registrations
of
H
istorical resources with the APNIC
-
HM maintainer, a practice
consistent with the management of current resources.

To ensure integrity of information, APNIC will not update historical information in the APNIC Whois
Database until the resource holder dem
onstrates the organization
'
s right to the resources and enters a
formal agreement with APNIC either as a
M
ember or
N
on
-
M
ember account holder.


Procedure for updating
Historical
registrations

5.5.3.
To request an update to a
H
istorical resource registration, the fo
llowing steps take place:

1.

The
resource

holder contacts APNIC.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
23

of
36

2.

APNIC verifies the organization is the legitimate holder of the resources.

3.

APNIC updates

the
H
istorical resource registration in the APNIC Whois Database.

Detailed information on these steps is
available on the Maintenance of historical Internet resources
page at:

http://www.apnic.net/services/manage
-
historical
-
resources

Please note that resource holders will not be able to update registration information if they fail to pay
the fees associated w
ith their APNIC
Member

or
N
on
-
M
ember account.

Historical resource holders with a current APNIC account have access to MyAPNIC, which allows
organizations to manage their resources and account information via a secure website.


Policies applicable to updated

H
istorical resources

5.5.4.
Historical resources that are updated under this policy are subject to the registration requirements as
specified
above.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
24

of
36

6.

Resource

requests

6.1.

General requirements for requests

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



The network infrastructure of the organization making the request,



Any address space currently held by that organization (including
H
istorical address space),



Previous assignments made by that organization (including assignments m
ade from
H
istorical address
allocations), and



The intended use for the address space requested.

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


Documentation

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



Network engineering plans



Subnetting plans



Descriptions of network topology



Descriptions of network routing plans



Equipment invoices and

purchase orders



Other relevant documents

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


Security and confidentiality

6.1.2.
The documentation which supports addre
ss space requests involves information that may be highly
confidential to the organizations and individuals involved. Therefore, APNIC will operate in ways that
reflect the trust implicit in its position by applying and enforcing procedures that protect th
e confidential
information of its Members and their customers.

APNIC will maintain systems and practices that protect the confidentiality of all information relating to
the commercial and infrastructure operations of all Members and their customers. APNIC
will ensure
that the employment of all of its staff or agents is based upon an explicit condition of confidentiality
regarding such information.

APNIC provides for authorization and verification mechanisms within the APNIC Whois Database. It is
the respons
ibility of each IR or end
-
user to apply these mechanisms.


Equitable processing of requests

6.1.3.
APNIC will deal with all requests strictly in the order in which it receives the proper documentation. To
provide fair treatment for all applicants, APNIC will not,
under any circumstance, provide any special
treatment or make exceptions to the standard order of request processing.

APNIC will seek to process all requests within a consistent time and will maintain a request tracking
system for efficient request managem
ent.


Processing dependent on correct documentation

6.1.3.1.
APNIC will only process requests that have been completely and properly documented. If the
documentation contains errors or omissions, APNIC will advise the applicant as soon as possible.
APNIC may also re
quest 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 omissions have been rectified or the
additional questions have been answered.

APNIC N
umeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
25

of
36

APNIC will make all reasonable efforts to maintain a consistent and reliable level of service with
respect to processing of requests.

6.2.

Criteria for
i
nitial

d
elegations


Criteria for
i
nitial IPv4
d
elegations

6.2.1.

Minimum IPv4 delegation

6.2.1.1.
The current minimum delegat
ion size
for IPv4
is a /24 (256 addresses).

As of Friday, 15 April 2011, each new or existing APNIC account holder is only eligible to request
and receive delegations totaling a maximum /22 worth of address space from the APNIC IPv4
address pool.


IPv4
a
dd
ress usage estimates

6.2.1.2.
Requests for delegations must be supported by usage estimates based on immediate and
projected future need. These requests must be accompanied by documentation that supports the
estimates.

The estimates should be made for the following

periods:



Immediately,



Within one year, and



Within two years

APNIC recommends that, as a general guideline, organizations should base their resource
requests on the assumption that 25% of the address space will be used immediately and 50% will
be used with
in one year.

The end
-
user must provide documentation that supports its one
-
year usage estimate. If it is not
possible for the end
-
user to estimate confidently what the two
-
year usage rate will be, then APNIC
or the NIR may make a delegation that will be su
fficient for the one
-
year needs only.


Initial LIR delegation

6.2.1.3.
To be eligible

for an initial IPv4 delegation
, an LIR must:



Have used a /24 from their upstream provider or demonstrate an immediate need for a /24,



Have complied with applicable policies in mana
ging all address space previously delegated to it
(including
H
istorical delegations), and



Demonstrate a detailed plan for use of a /23 within a year


IPv4
for m
ultihoming

6.2.1.4.
An organization is eligible if it is currently multihomed with provider
-
based addresse
s, or
demonstrates a plan to multihome within one month.

Organizations requesting a delegation under these terms must demonstrate that they are able to
use 25% of the requested addresses immediately and 50% within one year.


IPv4 for critical infrastructure

6.2.1.5.
The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to
receive a delegation:



Root domain name system (DNS) server



Global top level domain (gTLD) nameservers



Country code TLD (ccTLDs) nameservers



IANA



Regional Internet Registry (RIRs), and



National Internet Registry (NIRs)

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
26

of
36

Delegations to critical infrastructure are available only to the actual operators of the network
infrastructure performing such functions. Registrar organizations that do not actually

host the
network housing the registry infrastructure will not be eligible under this policy.


IPv4 for
Internet Exchange Points

6.2.1.6.
Internet Exchange Points (IXP) are eligible to receive a delegation from APNIC to be used
exclusively to connect the IXP partici
pant devices to the Exchange Point.

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


Criteria for
i
nitial IPv6
d
elegations

6.2.2.

Minimum IPv6
a
llocation

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

Organizations that meet the initial allocation criteria are eligible to receive
the

minimum allocation.

Larger i
nitial allocations may be justified if:

1.

The organization provides comprehensive documentation of planned IPv6 infrastructure which
would require

a larger allocation; or

2.

The organization provides comprehensive documentation of all of the following:



its existing
IPv4 infrastructure and customer base,



its intention to provide its existing IPv4 services via IPv6, and



its intention to

move some of its
existing IPv4 customers to IPv6 within two years.

In either case, an allocation will be made which fulfills the calculated address requirement, in
accordance with the HD
-
Ratio based utilization policy.


Consideration of IPv4 infrastructure

6.2.2.2.
Subject to
S
ectio
n
6.2.
2
.
1
,

existing IPv4 networks may be considered in determining the initial
IPv6 allocation size. RIRs will apply a minimum size for IPv6 allocations, to facilitate prefix
-
based
filtering.


Initial IPv6 block for APNIC
M
embers with existing IPv4 space

6.2.2.3.
APNIC
M
embers that have
been delegated

an IPv4 address block from APNIC
,

but have no IPv6
space
,

can qualify for an appropriately sized IPv6 block under the matching IPv6 policy. For
example, a
M
ember that has received an IPv4 IXP assignment will be eligib
le to receive an IPv6
IXP assignment.

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



A
M
ember that has an IPv4 allocation is eligible for a /32 IPv6 address block.



A
M
ember that has an IPv4 assignment is

eligible for a /48 IPv6 address block.

If an APNIC
M
ember wishes to receive an initial allocation or assignment larger than the sizes
described above, the
Member
will need to apply under the alternative criteria described in
S
ection

6.2.
2
.
4
.

and
Section
6.3.3

below.


Criteria for i
nitial
IPv6
allocation

for those without IPv4 space


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

1.

Be an LIR

2.

Not be an end site

3.

Plan to provide IPv6 connectivity to organizations to which it wi
ll make assignments.

4.

Meet one of the two following criteria:



Have a plan for making at least 200 assignments to other organizations within two years
,

or



Be an existing LIR with IPv4 allocations from APNIC or an NIR, which will make IPv6
assignments or sub
-
allocations to other organizations and announce the allocation in the inter
-

domain routing system within two years
.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
27

of
36

Private networks (those not connected to the public Internet) may also be eligible for an IPv6
address space allocation provided they meet
equivalent criteria to those listed above.

6.3.

Criteria for
s
ubsequent
d
elegations


Subsequent

IPv4
d
elegations

6.3.1.
After receiving an initial LIR delegation, all subsequent delegations will depend on the following:



The LIR
'
s verified usage rate (which is the rate
at which the LIR made delegations from relevant past
address space, including
H
istorical delegations)



Their documented plans for address space, and



Their degree of compliance with APNIC policies with respect to relevant past delegations.

Based on these fac
tors, APNIC and NIRs will delegate address space to meet the LIR
'
s estimated
needs for a period up to one year up to the maximum allowed delegation under
Section
6.2.1.1
. If
APNIC or the NIR make a delegation based on a period of less than one year, then t
hey must inform
the LIR of the length of the period and the reasons for selecting it.


Prior delegations to be used first

6.3.1.1.
An LIR is not eligible to receive subsequent delegations until its current delegations account for at
least eighty percent of the total address space it holds. This is referred to as the
"
eighty percent
rule
"
.


Special circumstances
-

large delegations

6.3.1.2.
An L
IR may request an exception to the eighty percent rule if it needs to make a single delegation
that is larger than the amount of space it has remaining.


Subsequent IPv6
a
llocations

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


Existing IPv6 address space holders

6.3.2.1.
Organizations th
at received /35 IPv6 allocation

under the previous IPv6 address policy [RIRv6
-
Policies] are immediately entitled to have their allocation expanded to a /32 address block, without
providing justification, so long as they satisfy the criteria in Section
6.2.2
.3
.

The /32 address block will

contain the already allocated smaller address block (one or multiple /35
address blocks in many cases) that was already reserved by the RIR for a subsequent allocation
to the organization. Requests for additional space beyond the minimum /32 size will be
evaluated
as discussed elsewhere in th
is

document.


Applied HD
-
Ratio

6.3.2.2.
Subsequent allocation will be provided when an organization (ISP/LIR) satisfies the evaluation
threshold of past address utilization in terms of the number of sites in units of /56 assignm
ents.

The HD
-
Ratio [RFC 3194] is used to determine the utilization thresholds that justify the allocation
of additional address as described below.

The HD
-
Ratio value of 0.94 is adopted as indicating an acceptable address utilization for justifying
the all
ocation of additional address space. Appendix A provides a table showing the number of
assignments that are necessary to achieve an acceptable utilization value for a given address
block size.


Alternative allocation criteria

6.3.2.3.
Alternatively, a subsequent all
ocation may be provided where an organization (ISP/LIR) can
demonstrate a valid reason for requiring the subsequent allocation. For guidelines on what will be
APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
28

of
36

considered a valid technical or other reason, see
"
APNIC guidelines for IPv6 allocation and
assig
nment requests
"
.

http://www.apnic.net/criteria/ipv6
-
guidelines


Subsequent
a
llocation
s
ize

6.3.2.4.
When an organization has achieved an acceptable utilization for its allocated address space, it is
immediately eligible to obtain an additional allocation that result
s in a doubling of the address
space allocated to it. Where possible, except where separate disaggregated ranges are requested
for multiple discreet networks, the allocation will be made from an adjacent address block,
meaning that its existing allocation
is extended by one bit to the left.

If an organization needs more address space, it must provide documentation justifying its
requirements for a two
-
year period. The allocation made will be based on this requirement.


Criteria for
IPv6
a
ssignments

6.3.3.
Organizat
ions with a previously delegated IPv4 assignment from APNIC are eligible for an
appropriately sized IPv6 block under
Section
6.2.2
.
3
.

above.


Criteria for small multihoming delegations

6.3.3.1.
An organization is eligible to receive a portable assignment 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.


IPv6
c
ritical infrastructure

6.3.3.2.
The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to
receive a portable assignment:



R
oot domain name system (DNS) server;



G
lobal top
level domain (gTLD) nameservers;



C
ountry code TLD (ccTLDs) nameservers;



IANA;



Regional Internet Registry (RIRs); and



National Internet Registry (NIRs).

Assignments to critical infrastructure are available only to the actual operators of the network
infrast
ructure performing such functions. Registrar organizations which do not actually host the
network housing the registry infrastructure, will not be eligible for an assignment under this policy.

The maximum assignment made under these terms is /32 per operat
or.


IPv6
Internet Exchange Points

6.3.3.3.
Internet Exchange Points are eligible to receive a portable assignment from APNIC to be used
exclusively to connect the IXP participant devices to the Exchange Point.

The minimum assignment made under these terms is /48.

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


Provider Independent assignment

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

1.

Initial assignment

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

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
29

of
36

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

http://www.apnic.net/ipv6
-
guidelines

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

http://www.apnic.net/ipv6
-
guidelines

2.

Subsequent assignment

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



why an additional portable assignment is required and why an assignment from an ISP or
other LIR cannot be used for this purpose;



that the use of the initial provider independent delegation generated the minimum possible
number of global rou
ting announcements and the maximum aggregation of that block; and,



how the subsequent assignment will be managed to
minimize

the growth of the global IPv6
routing table.

6.4.

ASN
a
ssignment
s

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.

3.

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


Evaluation

of eligibility

6.4.1.
Requests for ASNs under these criteria will be evaluated using the guidelines described in RFC1930
'
Guidelines for the creation, selection and registration of an Autonomous System
'

(AS).


Requesting an ASN

6.4.2.
Organiz
ations may request an ASN from either APNIC or their relevant NIR.

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

and 6.
4
.4.

below.


Using ASN for own network

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

1.

The requesting organization is responsible for maintaining the registration described in Section
5.4
.

2.

The requesting organization is entitled to continue using the ASN, even if they change network
peers or service providers.


Providing ASN to customer

6.4.4.
Assignments to organizations that will provide the ASN to one of its customers are subject to the
followi
ng additional terms:

1.

The customer that will actually use the ASN must meet the criteria in Section

6.4.

2.

The requesting organization is responsible for maintaining the registration described in Section
5.4.

on behalf of the customer.

3.

If the customer ceases
to receive connectivity from the requesting organization it must return the
ASN. The requesting organization is expected to enter into an agreement with the customer to this
effect.

APNIC Numeric Internet
Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
30

of
36

4.

Any ASNs returned to the requesting organization must then be returned to
APNIC or the relevant
NIR.


T
wo
-
byte only
and

four
-
byte AS
N
umbers

6.4.5.
On
1 January 2010:
APNIC cease
d

to make any distinction between two
-
byte only AS
N
umbers and
four
-
byte only AS numbers, and operate
s the

AS
N
umber assignments from an undifferentiated four
-
byte AS
N
umber pool.

6.5.

Experimental allocations policy

This
Section

describes the APNIC policies which apply to requests for Internet resource allocations that
are to be used for experimental purposes.


Introduc
tion

6.5.1.
As the Internet continues to expand and evolve, there is an increased need for technologies and
practices to be refined and
standardized
.

To achieve this, it is often necessary to experiment with proposed technologies to evaluate their
interaction wit
h the installed base of the Internet. For a small proportion of these experimental
activities, it may be necessary to allocate or assign Internet resources on a temporary basis.


Scope

and goal

6.5.1.1.
This
s
ection

describes policies for the responsible management
of global Internet resources in the
Asia Pacific region, specifically relating to the temporary allocation and assignment of Internet
resources for experimental purposes.

The goal of this policy is to provide fair access to Internet resources for genuine r
esearchers, to
encourage development of new technologies and refinement of standards.


Allocations for experimental purposes

6.5.2.
APNIC will allocate public Internet resources to be used for experimental purposes. These
experimental allocations are subject to th
e eligibility criteria, conditio
ns, and restrictions described
below
.

An experiment is eligible for an allocation if it meets the criteria described in either

S
ection
6.
5.2.
1 or
S
ection 6.
5.2.
2.


Publication of an e
xperimental RFC

6.5.2.1.
Experiments are eligible f
or allocations if they are described in an RFC designated by the IETF as
"
Experimental
"
.

The requestors must specifically refer to this RFC, describe their participation in
the experiment, and provide a summary of the experiment which details their require
ment for
Internet resources.


Alternative publication approved by APNIC

6.5.2.2.
Experiments may be eligible for an allocation if they are described in a document that is available
free of charge and publicly accessible in a forum approved by APNIC.

Under this crite
rion, APNIC has the sole discretion to determine whether such an experiment is
eligible. To do so, APNIC may liaise with IETF working groups, other standards bodies, RIRs, or
Internet experts to evaluate the status of the document, the validity of the expe
riment it describes,
and the Internet resource requirements of the experiment.

The requestors must specifically refer to the published document, describe their participation in the
experiment, and provide a summary of the experiment which details their
requirement for Internet
resources.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
31

of
36


Experimental
a
llocation
s

6.5.3.

Public disclosure of experiment

6.5.3.1.
It is a condition for experimental allocations that all material details of the experiments are
published free of charge and without any constraints on their discl
osure or use. The details to be
published include the objectives of the experiment, the practices, and any other relevant details. At
the completion of the experiment, the results must be published under the same terms.

To this extent, the terms of APNIC
'
s

regular non
-
disclosure provisions are specifically excluded
from these requests. Although APNIC may consider requests for certain aspects of a project to be
subject to a non
-
disclosure agreement, it will not agree to any restrictions on the public benefit

to
be gained from any experiments.

APNIC may publish and maintain public archives of all experiments which receive allocations
under this policy.


Size of IP allocations

6.5.3.2.
In the case of experimental allocations of IP addresses, the allocation size will be
consistent with
APNIC
'
s standard minimum allocation size, unless the nature of the experiment specifically
requires an allocation of a different size.


APNIC input on proposed experiment

6.5.3.3.
During the request process, APNIC may comment on the objectives of the

experiment with
regards to the requested amount of numbering resources. APNIC may also propose changes to
the size of the requested allocation.

If the requestor does not agree with the proposed changes, then APNIC will seek advice from the
IETF or another

relevant standards body involved in publishing the experiment.


Duration of allocation licenses

6.5.3.4.
APNIC will make experimental allocations on a temporary license basis. Licenses to use the
resources will be valid for one year.


Extension

of license

6.5.3.5.
At the end

of the initial license period, the holder of the resources may apply to have the

license
extended, to meet the
objectives of the expe
riment, as publicly documented.

It is intended that the majority of the experiments to be considered under this policy wil
l be
concluded without extension of the original license.


Registration

6.5.4.
All experimental allocations will be registered in the APNIC Whois Database. The registration details
will indicate the temporary nature of these allocations.


Restriction on commercial
or undocumented uses

6.5.4.1.
APNIC may revoke an experimental allocation if the resources are being used for commercial
purposes, or are being used for any activities not documented in the original request.


Fees

for experimental allocations

6.5.5.
Experimental allocation
s are available to APNIC
M
embers only.

New
M
embers wishing to receive experimental allocations may join at the Associate
M
ember level.
The
ir request for an experimental
allocation will not be subject to the
"
IP resource application fee
"
.

Experimental
allocations are not considered when calculating membership tier.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
32

of
36

7.

Resource
Transfers

IPv4 addresses may be transferred in accordance with the
following policies
. APNIC does not recognize
transfers outside this policy and require organizations holding such t
ransfers to ret
urn them to the
appropriate IR.

APNIC recognizes there will be situations where IPv4 resources may be transferred between:



Current APNIC account holders



Current APNIC account holders and org
anizations in other RIR regions



Holders of
H
istoric
al IPv4 addresses without an APNIC account to current APNIC Members



Organizations through a merger, acquisition, or takeover.

The policies in this document ensure that all transfers of IPv4 address space are accurately reflected in the
APNIC Whois Database
. This ensures the integrity of the network and an accurate description of the current

state of address distribution.

APNIC will maintain a public log of all transfers made under this policy.

7.1.

Transfers of IPv4 addresses between APNIC account holders

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


Conditions on the space to be transferred

7.1.1.
The minimum transfer size is a /24.

The address block must be:



In the range of addre
sses administered by APNIC



Allocated or assigned to a current APNIC account holder



The address block will be subject to all current APNIC policies from the time of transfer.


Conditions on source of the transfer

7.1.2.
The source entity must be the currently regis
tered holder of the IPv4 address resources, and not be
involved in any dispute as to the status of those resources.


Conditions on recipient of the transfer

7.1.3.
The recipient entity will be subject to current APNIC policies.

Recipients that do not already hold
IPv4 resource
s

must demonstrate a detailed plan for the use of the
transferred resource within 24 months.

Recipients that already hold IPv4 resources must:



Demonstrate a detailed plan for the use of the transferred resource

within 24 months
,



Show past
usage rate, and



Provide evidence of compliance with APNIC policies with respect to past delegations.

7.2.

Inter
-
RIR IPv4 address transfers

APNIC will recognize inter
-
RIR IPv4 address transfers only when the counterpart RIR has an inter
-
RIR
transfer policy that
permits the transfer of address space between APNIC and its own region.

APNIC will process and record IPv4 address transfer requests between current APNIC account holders
and organizations in other RIR regions subject to the following conditions.


Condition
s on the space to be transferred

7.2.1.
The minimum transfer size is stipulated in Section
7.1
.1 of this policy.

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
33

of
36

The IPv4 address space should be under the management of the RIR at which the transfer source
holds an account and the authentic holder of the space s
hould match with the source without any
disputes.


Conditions on the source of the transfer

7.2.2.
The conditions on the source of the transfer will be defined by the RIR where the source organization
holds an account. This means:



For transfers from an APNIC sourc
e, the conditions defined in Section
7.1.
2 will apply.



Where the source is in another region, the conditions on the source as defined in the counterpart
RIR
'
s transfer policy at the time of the transfer will apply.


Conditions on the recipient of the transf
er

7.2.3.
The conditions on the recipient of the transfer will be defined by the RIR where the recipient
organization holds an account. This means:



For transfers to an APNIC recipient, the conditions defined in Section
7.1
.3 will apply.



Where the recipient is in
another region, the conditions on the recipient as defined in the counterpart
RIR
'
s transfer policy at the time of the transfer will apply.

7.3.

Transfer of
H
istorical Internet resources

If H
istorical resources are transferred to

an APNIC M
ember, there is the o
ption to make the transfer under
the conditions described in this policy. Transfers of Internet resources to current APNIC account holders
are purely optional. For information on the different types of transfers available, please see
"
Guide to the
transfer

of historical Internet resources
"
.

http://www.apnic.net/publications/guidelines/historical
-
transfer



Transfer procedure

7.3.1.
All transfers of
H
istorical resources to current APNIC account holders made under this policy are
recognized and registered by APNIC. A
PNIC does not require any technical review or approval of the
resource
'
s current use to approve the transfer. In addition, APNIC does not review any agreements
between the parties to a transfer and does not exert any control over the type of agreement betw
een
the parties.

To transfer historical resources, the following steps take place:

1.

The APNIC Member submits the Historical transfer application form

2.

APNIC verifies the existing holder of the resources

3.

The existing holder of the resources provides documents confirming the transfer to the APNIC
M
ember

4.

APNIC transfers the resources to the APNIC
M
ember
'
s account.

You can find more about the transfer of historical resources in the
"
Manage Resources
"

section
of the
APNIC website.


Policies applicable to transferred resources

7.3.2.
All resources transferred under this policy are subject to the provisions of all normal address
management policies. In particular, future address requests from the
M
ember must document the

use
of transferred resources as a part of the
M
ember
'
s current resource holdings.

For more information on transferring historical resources, please see
the document,
Guide to the
transfer of historical Internet resources.

http://www.apnic.net/publications
/guidelines/historical
-
transfer


APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
34

of
36

7.4.

Mergers, acquisitions, and takeovers of LIRs


Updating registration details

7.4.1.
If an LIR changes ownership (due to a merger, sale, or takeover), then the new entity must register
any changes to its network usage and contact per
sonnel. If the effect of the ownership change is that
the LIR changes name, then the LIR must provide to APNIC relevant legal documentation supporting
the name change.


Effect on membership agreement

7.4.2.
If an LIR changes ownership then the new entity should ad
vise APNIC of the change. APNIC
membership is not transferable from one entity to another; however, if the effect of the ownership
change is that the LIR becomes a subsidiary of another entity, and the infrastructures of the respective
entities remain full
y independent, then the membership agreement may continue.


Consequences for allocations

7.4.3.
Following ownership change of an LIR, APNIC will review the status of any allocations that are held by
the new entity or entities, with regard to the practical effect o
n their infrastructures.

If the practical effect of ownership change is that the infrastructures are merged, then APNIC will not
continue to make separate allocations to both. This situation will invalidate the membership agreement
of the LIR that is effec
tively subsumed.

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

For more information on transferring resources in these ways, see
"
Transfer resources
"

on the APNIC
website
.

http://www.apnic.net/transfer



APNIC Numeric Internet Resource Policie
s

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
35

of
36

Appendix A
:

HD
-
Ratio

The utilization threshold T, expressed as a number of individual /56 prefixes to
be allocated from IPv6 prefix
P, can be calculated as:

T=2
((56
-
P)*HD)

Thus, the utilization threshold for an organization requesting subsequent allocation of IPv6 address block is
specified as a function of the prefix size and target HD
-
R
atio. This
utilization refers to the allocation of /56s to
end sites, and not the utilization of those /56s within those end sites. It is an address allocation utilization
ratio and not an address assignment utilization ratio.

This document adopts an HD
-
Ratio of 0.94

as the utilization threshold for IPv6 address space allocations.

The following table provides equivalent absolute and percentage address utilization figures for IPv6 prefixes,
corresponding to an HD
-
Ratio of 0.94

APNIC Numeric Internet Resource Policies

divisionimpossib
le_efe34b6c
-
84c6
-
474d
-
ad3e
-
090501cde370.docx

Page
36

of
36

IPv6
HD
-
Ratio of 0.94

equivalents

P

56
-
P

Total /56s

Threshold

Util%

56

0

1

1

100.0

55

1

2

2

95.9

54

2

4

4

92.0

53

3

8

7

88.3

52

4

16

14

84.7

51

5

32

26

81.2

50

6

64

50

77.9

49

7

128

96

74.7

48

8

256

184

71.7

47

9

512

352

68.8

46

10

1,024

676

66.0

45

11

2,048

1,296

63.3

44

12

4,096

2,487

60.7

43

13

8,192

4,771

58.2

42

14

16,384

9,153

55.9

41

15

32,768

17,560

53.6

40

16

65,536

33,689

51.4

39

17

131,072

64,634

49.3

38

18

262,144

124,002

47.3

37

19

524,288

237,901

45.4

36

20

1,048,576

456,419

43.5

35

21

2,097,152

875,653

41.8

34

22

4,194,304

1,679,965

40.1

33

23

8,388,608

3,223,061

38.4

32

24

16,777,216

6,183,533

36.9

31

25

33,554,432

11,863,283

35.4

30

26

67,108,864

22,760,044

33.9

29

27

134,217,728

43,665,787

32.5

28

28

268,435,456

83,774,045

31.2

27

29

536,870,912

160,722,871

29.9

26

30

1,073,741,824

308,351,367

28.7

25

31

2,147,483,648

591,580,804

27.5

24

32

4,294,967,296

1,134,964,479

26.4

23

33

8,589,934,592

2,177,461,403

25.3

22

34

17,179,869,184

4,177,521,189

24.3

21

35

34,359,738,368

8,014,692,369

23.3

20

36

68,719,476,736

15,376,413,635

22.4

19

37

137,438,953,472

29,500,083,768

21.5

18

38

274,877,906,944

56,596,743,751

20.6

17

39

549,755,813,888

108,582,451,102

19.8

16

40

1,099,511,627,776

208,318,498,661

18.9

15

41

2,199,023,255,552

399,664,922,315

18.2

14

42

4,398,046,511,104

766,768,439,460

17.4

13

43

8,796,093,022,208

1,471,066,903,609

16.7

12

44

17,592,186,044,416

2,822,283,395,519

16.0

11

45

35,184,372,088,832

5,414,630,391,777

15.4

10

46

70,368,744,177,664

10,388,121,308,479

14.8

9

47

140,737,488,355,328

19,929,904,076,845

14.2

8

48

281,474,976,710,656

38,236,083,765,023

13.6

7

49

562,949,953,421,312

73,357,006,438,603

13.0

6

50

1,125,899,906,842,620

140,737,488,355,328

12.5

5

51

2,251,799,813,685,250

270,008,845,646,446

12.0

4

52

4,503,599,627,370,500

518,019,595,058,136

11.5