ARIN Number Resource Policy Manual
Version 2015.1 - 24 February 2015
This is ARIN's Number Resource Policy Manual (NRPM). It is available at:
https://www.arin.net/policy/. This version supersedes all previous versions.
Number resource policies in the ARIN region are created in accordance
with the "Policy Development Process"
(https://www.arin.net/policy/pdp.html ). The status of
current and historical policy proposals can be found on the "Draft
Policies and Proposals" page (https://www.arin.net/policy/proposals/
).
Each policy consists of a number of component parts separated by dots.
The first figure to the far left and preceding the first dot (.), refers
to the chapter number. The figure following the first dot indicates a
policy section. Any subsequent figures are for the purpose of
identifying specific parts of a given policy.
Contents
* 1. Principles and Goals of the American Registry for Internet
Numbers (ARIN)
o 1.1. Registration
o 1.2. Conservation
o 1.3. Routability
o 1.4. Stewardship
2. Definitions
o 2.1. Internet Registry (IR)
o 2.2. Regional Internet Registry (RIR)
o 2.3. [Section Number Retired]
o 2.4. Local Internet Registry (LIR)
o 2.5. Allocate and Assign
o 2.6. End-user
o 2.7. Multihomed
o 2.8. Utilization (IPv6)
o 2.9. HD-Ratio
o 2.10. End site
o 2.11. Community Network
o 2.12 Organizational Information
o 2.13. Residential Customer
o 2.14. Serving Site (IPv6)
o 2.15. Provider Assignment Unit (IPv6)
o 2.16. Utilized (IPv6)
* 3. Directory Services
o 3.1. Bulk Copies of ARIN's Whois
o 3.2. Distributed Information Server Use Requirements
o 3.3. Privatizing POC Information
o 3.4. Routing Registry
+ 3.4.1. Acceptable use policy
o 3.5 Autonomous System Originations
+ 3.5.1 Collection
+ 3.5.2 Publication
# 3.5.2.1 Description of data
# 3.5.2.2 Bulk publication of data
# 3.5.2.3 Other formats
o 3.6 Annual Whois POC Validation
+ 3.6.1 Method of Annual Verification
* 4. IPv4
o 4.1. General Principles
+ 4.1.1., 4.1.2., 4.1.3., 4.1.4. [Section Number Retired]
+ 4.1.5. Resource request size
+ 4.1.6. Aggregation
+ 4.1.7. [Section Number Retired]
+ 4.1.8. Unmet Requests
# 4.1.8.1. Waiting list
# 4.1.8.2. Fulfilling unmet needs
+ 4.1.9. [Section Number Retired]
+
o 4.2. Allocations to ISPs
+ 4.2.1. Principles
# 4.2.1.1. Purpose
# 4.2.1.2. Annual Renewal
# 4.2.1.3. Utilization rate
# 4.2.1.4. Slow start
# 4.2.1.5. Minimum allocation
# 4.2.1.6. Immediate need
+ 4.2.2. Initial allocation to ISPs
# 4.2.2.1. ISP Requirements
* 4.2.2.1.1. Use of /24
* 4.2.2.1.2. Efficient utilization
* 4.2.2.1.3. Three months
* 4.2.2.1.4. Renumber and return
# 4.2.2.2. [Section Number Retired]
+ 4.2.3. Reassigning Address Space to Customers
# 4.2.3.1. Efficient utilization
# 4.2.3.2. VLSM
# 4.2.3.3. Contiguous blocks
# 4.2.3.4. Downstream customer adherence
* 4.2.3.4.1. Utilization
* 4.2.3.4.2. Downstream ISPs
# 4.2.3.5. ARIN pre-approval of
reassignments/reallocations
* 4.2.3.5.1. /18
* 4.2.3.5.2. /19
* 4.2.3.5.3. Required documentation for pre-approval
requests
# 4.2.3.6. Reassignments to multihomed downstream
customers
# 4.2.3.7. Registration
* 4.2.3.7.1. Reassignment Information
* 4.2.3.7.2. Assignments visible within 7 days
* 4.2.3.7.3. Residential Subscribers
o 4.2.3.7.3.1. Residential Market Area
o 4.2.3.7.3.2. Residential Customer Privacy
# 4.2.3.8. Reassignments for Third Party Internet Access
(TPIA) over Cable
o 4.2.4. ISP Additional Requests
+ 4.2.4.1. Utilization percentage (80%)
+ 4.2.4.2. Return address space as agreed
+ 4.2.4.3. Request size
+ 4.2.4.4. [Section Number Retired]
o 4.2.5. [Section Number Retired]
o 4.2.6. [Section Number Retired]
* 4.3. End-users - Assignments to end-users
o 4.3.1. End-user
o 4.3.2. Minimum Assignment
+ 4.3.2.1 Single Connection
+ 4.3.2.2 [Section Number Retired]
o 4.3.3. Utilization Rate
o 4.3.4. Additional considerations
o 4.3.5. Non-connected Networks
o 4.3.6 Additional Assignments
+ 4.3.6.1 Utilization Requirements for Additional Assignment
* 4.4. Micro-allocation
* 4.5. Multiple Discrete Networks
* 4.6., 4.7., 4.8., 4.9. [Section Number Retired]
* 4.10. Dedicated IPv4 block to facilitate IPv6 Deployment
5. AS Numbers
* 5.1 [Section Number Retired]
6. IPv6
* 6.1. Introduction
o 6.1.1. Overview
* 6.2. [Section Number Retired]
* 6.3. Goals of IPv6 address space management
o 6.3.1. Goals
o 6.3.2. Uniqueness
o 6.3.3. Registration
o 6.3.4. Aggregation
o 6.3.5. Conservation
o 6.3.6. Fairness
o 6.3.7. Minimized overhead
o 6.3.8. Conflict of goals
* 6.4. IPv6 Policy Principles
o 6.4.1. Address Space not to be considered to be property
o 6.4.2. Routability not guaranteed
o 6.4.3. [Section Number Retired]
o 6.4.4. Consideration of IPv4 Infrastructure
* 6.5. Policies for allocations and assignments
o 6.5.1. Terminology
o 6.5.2. Initial Allocations to LIRs
+ 6.5.2.1. Size
+ 6.5.2.2. Qualifications
o 6.5.3. Subsequent Allocations to LIRs
+ 6.5.3.1. Subsequent Allocations for Transition
o 6.5.4. Assignments from LIRs/ISPs
+ 6.5.4.1. Assignment to operator's infrastructure
o 6.5.5. Registration
+ 6.5.5.1. Reassignment information
+ 6.5.5.2. Assignments visible within 7 days
+ 6.5.5.3. Residential Subscribers
# 6.5.5.3.1. Residential Customer Privacy
o 6.5.6. Reverse lookup
o 6.5.7. Existing IPv6 address space holders
o 6.5.8 Direct assignments from ARIN to end user organizations
+ 6.5.8.1 Initial Assignment Criteria
+ 6.5.8.2 Initial assignment size
# 6.5.8.2.1 Standard sites
# 6.5.8.2.2 Extra-large sites
+ 6.5.8.3 Subsequent assignments
+ 6.5.8.4 Consolidation and return of separate assignments
o 6.5.9 Community Network Assignments
+ 6.5.9.1 Qualification Criteria
+ 6.5.9.2 Initial assignment size
+ 6.5.9.3 Subsequent assignment size
* 6.6. [Section Number Retired]
* 6.7. Appendix A - HD-Ratio
* 6.8. [Section Number Retired]
* 6.9. [Section Number Retired]
* 6.10. Micro-allocations
o 6.10.1 Micro-allocations for Critical Infrastructure
o 6.10.2 Micro-allocations for Internal Infrastructure
* 6.11. IPv6 Multiple Discrete Networks
7. Reverse Mapping
* 7.1. Maintaining IN-ADDRs
* 7.2. [Section Number Retired]
8. Transfers
* 8.1. Principles
* 8.2. Mergers and Acquisitions
* 8.3. Transfers between Specified Recipients within the ARIN Region
* 8.4. Inter-RIR Transfers to Specified Recipients
9. [Reserved]
10. Global Number Resource Policy
* 10.1. IANA to RIR Allocation of IPv4 Address Space
* 10.2. Allocation of IPv6 Address Space by the Internet Assigned
Numbers Authority (IANA) Policy to Regional Internet Registries
* 10.3 IANA Policy for Allocation of ASN Blocks to RIRs
* 10.4. Global Policy for the Allocation of the Remaining IPv4 Address
Space
* 10.5. Global Policy for Post Exhaustion IPv4 Allocation Mechanisms
by the IANA
11. Experimental Internet Resource Allocations
* 11.1 Documentation of recognized experimental activity
* 11.2 Technical Coordination
* 11.3 Coordination over Resource use
* 11.4 Resource Allocation Term and Renewal
* 11.5 Single Resource Allocation per Experiment
* 11.6 Resource Allocation Fees
* 11.7 Resource Allocation Guidelines
* 11.8 Commercial Use Prohibited
* 11.9 Resource Request Appeal or Arbitration
12. Resource Review
Appendix A - Change Log
1. Principles and Goals of the American Registry for Internet
Numbers (ARIN)
1.1. Registration
The principle of registration guarantees the uniqueness of Internet
number resources. Provision of this public registry documenting Internet
number resource allocation, reallocation, assignment, and reassignment
is necessary:
1. to ensure uniqueness,
2. to provide a contact in case of operational/security problems,
3. to provide the transparency required to ensure that Internet number
resources are efficiently utilized, and
4. to assist in IP allocation studies.
1.2. Conservation
The principle of conservation guarantees sustainability of the Internet
through efficient utilization of unique number resources.
Due to the requirement for uniqueness, Internet number resources of each
type are drawn from a common number space. Conservation of these common
number spaces requires that Internet number resources be efficiently
distributed to those organizations who have a technical need for them in
support of operational networks.
1.3. Routability
The principle of routability guarantees that Internet number resources
are managed in such a manner that they may be routed on the Internet in
a scalable manner.
While routing scalability is necessary to ensure proper operation of
Internet routing, allocation or assignment of Internet number resources
by ARIN in no way guarantees that those addresses will be routed by any
particular network operator.
1.4. Stewardship
The principle of stewardship guarantees the application of these
principles when managing Internet number resources.
The fundamental purpose of Internet number stewardship is to distribute
unique number resources to entities building and operating networks
thereby facilitating the growth and sustainability of the Internet for
the benefit of all.
It should be noted that the above goals may sometimes be in conflict
with each other and with the interests of individual end-users or
network operators. Care must be taken to ensure balance with these
conflicting goals given the resource availability, relative size of the
resource, and number resource specific technical dynamics, for each type
of number resource.
2. Definitions
Responsibility for management of address spaces is distributed globally
in accordance with the hierarchical structure shown below.
Chart showing hierarchical structure of Internet number resource
distribution.
2.1. Internet Registry (IR)
An Internet Registry (IR) is an organization that is responsible for
distributing IP address space to its members or customers and for
registering those distributions.
2.2. Regional Internet Registry (RIR)
Regional Internet Registries (RIRs) are established and authorized by
respective regional communities, and recognized by the IANA to serve and
represent large geographical regions. The primary role of RIRs is to
manage and distribute public Internet address space within their
respective regions.
2.3. [Section Number Retired]
2.4. Local Internet Registry (LIR)
A Local Internet Registry (LIR) is an IR that primarily assigns address
space to the users of the network services that it provides. LIRs are
generally Internet Service Providers (ISPs), whose customers are
primarily end users and possibly other ISPs.
2.5. Allocate and Assign
A distinction is made between address allocation and address assignment,
i.e., ISPs are "allocated" address space as described herein, while
end-users are "assigned" address space.
* Allocate - To allocate means to distribute address space to IRs for
the purpose of subsequent distribution by them.
* Assign - To assign means to delegate address space to an ISP or
end-user, for specific use within the Internet infrastructure they
operate. Assignments must only be made for specific purposes
documented by specific organizations and are not to be sub-assigned
to other parties.
2.6. End-user
An end-user is an organization receiving assignments of IP addresses
exclusively for use in its operational networks.
2.7. Multihomed
An organization is multihomed if it receives full-time connectivity from
more than one ISP and has one or more routing prefixes announced by at
least two of its upstream ISPs.
2.8. Utilization (IPv6)
In IPv6, "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 to end sites, and not the number of addresses
assigned within individual /56s at those end sites.
2.9. HD-Ratio
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 RFC
1715 and is expressed as follows:
Log (number of allocated objects)
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.10. End site
The term End Site shall mean a single structure or service delivery
address, or, in the case of a multi-tenant structure, a single tenant
within said structure (a single customer location).
2.11. Community Network
A community network is any network organized and operated by a volunteer
group operating as or under the fiscal support of a nonprofit
organization or university for the purpose of providing free or low-cost
connectivity to the residents of their local service area. To be treated
as a community network under ARIN policy, the applicant must certify to
ARIN that the community network staff is 100% volunteers.
2.12. Organizational Information
When required, organization Information must include at a minimum: Legal
name, street address, city, state, zip code equivalent and at least one
valid technical and one valid abuse POC. Each POC shall be designated by
the organization and must include at least a verifiable email address
and phone number.
2.13. Residential Customer
End-users who are individual persons and not organizations and who
receive service at a place of residence for personal use only are
considered residential customers.
2.14. Serving Site (IPv6)
When applied to IPv6 policies, the term serving site shall mean a
location where an ISP terminates or aggregates customer connections,
including, but, not limited to Points of Presence (POPs), Datacenters,
Central or Local switching office or regional or local combinations thereof.
2.15. Provider Assignment Unit (IPv6)
When applied to IPv6 policies, the term "provider assignment unit" shall
mean the prefix of the smallest block a given ISP assigns to end sites
(recommended /48).
2.16. Utilized (IPv6)
The term utilized shall have the following definitions when applied to
IPv6 policies:
1. A provider assignment unit shall be considered fully utilized when
it is assigned to an end-site.
2. Larger blocks shall have their utilization defined by dividing the
number of provider assignment units assigned from the containing
block by the total number of provider assignment units. This ratio
will often be expressed as a percentage (e.g. a/t*100, for a /36
3072/4096 * 100 = 75% utilization)
3. Directory Services
3.1. Bulk Copies of ARIN's Whois
ARIN will provide a bulk copy of Whois output, including point of
contact information, on the ARIN site for download by any organization
that wishes to obtain the data providing they agree to ARIN's acceptable
use policy. This point of contact information will not include data
marked as private.
[The Request Form for ARIN Bulk Whois Data, which contains the
Acceptable Use Policy (AUP) for Bulk Copies of ARIN Whois Data, can be
found at:
https://www.arin.net/resources/agreements/bulkwhois.pdf
]
3.2. Distributed Information Server Use Requirements
The minimal requirements for an organization to setup a distributed
information service to advertise reassignment information are:
* The distributed information service must be operational 24 hours a
day, 7 days a week to both the general public and ARIN staff. The
service is allowed reasonable downtime for server maintenance
according to generally accepted community standards.
* The distributed information service must allow public access to
reassignment information. The service may restrict the number of
queries allowed per time interval from a host or subnet to defend
against DDOS attacks, remote mirroring attempts, and other nefarious
acts.
* The distributed information service must return reassignment
information for the IP address queried. The service may allow for
privacy protections for customers. For residential users, the
service may follow ARIN's residential privacy policy that includes
displaying only the city, state, zip code, and country. For all
other reassignments, the service shall follow ARIN's privacy policy
for publishing data in a public forum.
* The distributed information service may return results for non-IP
queries.
* The distributed information service must respond to a query with the
minimal set of attributes per object as defined by ARIN staff.
* The distributed information service may include optional attributes
per object that are defined locally.
* The distributed information service must return results that are
up-to-date on reassignment information.
3.3. Privatizing POC Information
Organizations may designate certain points of contact as private from
ARIN Whois, with the exception that, at the minimum, one point of
contact must be viewable.
3.4. Routing Registry
3.4.1. Acceptable use policy
* The ARIN Routing Registry data is for Internet operational purposes
only. Mirroring is only allowed by other routing registries.
* The user may only distribute this data using a Whois service unless
prior, written permission from ARIN has been obtained.
* To protect those registered in the ARIN routing registry, ARIN may
need to specify additional conditions on access permissions for this
data in the future. The permission to access the data is based on
agreement to the conditions stipulated in this document in addition
to any others that may be added in the future.
* Please see the http://www.irr.net/docs/list.html URL for information
about the replicated Routing Registry data.
3.5 Autonomous System Originations
3.5.1 Collection
ARIN will collect an optional field in all IPv4 and IPv6 address block
transactions (allocation and assignment requests, reallocation and
reassignment actions, transfer and experimental requests). This
additional field will be used to record a list of the ASes that the user
permits to originate address prefixes within the address block.
3.5.2 Publication
3.5.2.1 Description of data
ARIN will produce a collection of the mappings from address blocks to
ASes permitted to originate that address block. The collection will
consist of a list where each entry will consist, at a minimum, of an
address block, a list of AS numbers, and a tag indicating the type of
delegation of the address block. This collection will be produced at
least daily.
3.5.2.2 Bulk publication of data
ARIN will make the collected mappings from address blocks to AS numbers
available for bulk transfer in one or more formats chosen at its own
discretion, informed by the community's current needs. This data will
not be subject to any redistribution restrictions -- it may be
republished or repackaged it any form. Should ARIN choose to use Whois
bulk transfer as the bulk form of data access required by this
paragraph, the address block to AS mappings will not be subject to any
redistribution restrictions, but the remainder of the Whois data will
remain subject to the terms of the then-current AUP regarding bulk
access to Whois data.
3.5.2.3 Other formats
ARIN may also make the collected or individual mappings from address
blocks to AS numbers available in other forms, possibly query services,
chosen at its own discretion, informed by the community's current needs.
ARIN may require agreement to an acceptable use policy for access to the
data in these forms.
3.6 Annual Whois POC Validation
3.6.1 Method of Annual Verification
During ARIN's annual Whois POC validation, an email will be sent to
every POC in the Whois database. Each POC will have a maximum of 60 days
to respond with an affirmative that their Whois contact information is
correct and complete. Unresponsive POC email addresses shall be marked
as such in the database. If ARIN staff deems a POC to be completely and
permanently abandoned or otherwise illegitimate, the POC record shall be
marked invalid. ARIN will maintain, and make readily available to the
community, a current list of number resources with no valid POC; this
data will be subject to the current bulk Whois policy.
4. IPv4
4.1. General Principles
4.1.1, 4.1.2., 4.1.3., 4.1.4. [Section Number Retired]
4.1.5. Resource request size
Determining the validity of the amount of requested IP address resources
is the responsibility of ARIN.
4.1.6. Aggregation
In order to preserve aggregation, ARIN attempts to issue blocks of
addresses on appropriate "CIDR-supported" bit boundaries. ARIN may
reserve space to maximize aggregation possibilities until the
implementation of section 10.4.2.2, at which time ARIN will make each
allocation and assignment as a single continuous range of addresses.
4.1.7. [Section Number Retired]
4.1.8. Unmet requests
In the event that ARIN does not have a contiguous block of addresses of
sufficient size to fulfill a qualified request, ARIN will provide the
requesting organization with the option to specify the smallest block
size they'd be willing to accept, equal to or larger than the applicable
minimum size specified elsewhere in ARIN policy. If such a smaller block
is available, ARIN will fulfill the request with the largest single
block available that fulfills the request. If no such block is
available, the organization will be provided the option to be placed on
a waiting list of pre-qualified recipients, listing both the block size
qualified for and the smallest block size acceptable.
Repeated requests, in a manner that would circumvent 4.1.6, are not
allowed: an organization may only receive one allocation, assignment, or
transfer every 3 months, but ARIN, at its sole discretion, may waive
this requirement if the requester can document a change in circumstances
since their last request that could not have been reasonably foreseen at
the time of the original request, and which now justifies additional
space. Qualified requesters whose request cannot be immediately met will
also be advised of the availability of the transfer mechanism in section
8.3 as an alternative mechanism to obtain IPv4 addresses.
4.1.8.1. Waiting list
The position of each qualified request on the waiting list will be
determined by the date it was approved. Each organization may have one
approved request on the waiting list at a time.
4.1.8.2. Fulfilling unmet needs
As address blocks become available for allocation, ARIN will fulfill
requests on a first-approved basis, subject to the size of each
available address block and a timely re-validation of the original
request. Requests will not be partially filled. Any requests met through
a transfer will be considered fulfilled and removed from the waiting list.
4.1.9. [Section Number Retired]
4.2. Allocations to ISPs (Requirements for Requesting Initial
Address Space)
4.2.1. Principles
4.2.1.1. Purpose
ARIN allocates blocks of IP addresses to ISPs for the purpose of
reassigning that space to their customers.
4.2.1.2. Annual Renewal
An annual fee for registered space is due by the anniversary date of the
ISP's first allocation from ARIN. ISPs should take care to ensure that
their annual renewal payment is made by their anniversary due date in
accordance with the Registration Services Agreement. If not paid by the
anniversary date, the address space may be revoked. Please review the
Annual Renewal/Maintenance Fees Page for more details.
4.2.1.3. Utilization rate
Utilization rate of address space is a key factor, among others, in
determining address allocation.
4.2.1.4. Slow start
Because the number of available IP addresses on the Internet is limited,
many factors must be considered in the determination of address space
allocations. Therefore, IP address space is allocated to ISPs using a
slow-start model. Allocations are based on justified need, not solely on
a predicted customer base.
4.2.1.5. Minimum allocation
In general, ARIN allocates /24 and larger IP address prefixes to ISPs.
If allocations smaller than /24 are needed, ISPs should request address
space from their upstream provider.
4.2.1.6. Immediate need
If an ISP has an immediate need for address space, and can provide
justification to show that the address space will be utilized within 30
days of the request, ARIN may issue a block of address space, not larger
than a /16 nor smaller than ARIN's customary minimum allocation, to that
organization. These cases are exceptional.
4.2.2. Initial allocation to ISPs
4.2.2.1. ISP Requirements
All ISP organizations must satisfy the following requirements:
4.2.2.1.1. Use of /24
The efficient utilization of an entire previously allocated /24 from
their upstream ISP. This allocation may have been provided by an ISP’s
upstream provider(s), and does not have to be contiguous address space.
4.2.2.1.2. Efficient utilization
Demonstrate efficient use of IP address space allocations by providing
appropriate documentation, including assignment histories, showing their
efficient use. ISPs must provide reassignment information on the entire
previously allocated block(s) via SWIP or RWhois server for /29 or
larger blocks. For blocks smaller than /29 and for internal space, ISPs
should provide utilization data either via SWIP or RWhois server or by
providing detailed utilization information.
4.2.2.1.3. Three months
Provide detailed information showing specifically how the requested
allocation will be utilized within three months.
4.2.2.1.4. Renumber and return
ISPs receiving a new allocation may wish to renumber out of their
previously allocated space. In this case, an ISP must use the new
allocation to renumber out of that previously allocated block of address
space and must return the space to its upstream provider.
4.2.2.2. [Section Number Retired]
4.2.3. Reassigning Address Space to Customers
4.2.3.1. Efficient utilization
ISPs are required to apply a utilization efficiency criterion in
providing address space to their customers. To this end, ISPs should
have documented justification available for each reassignment. ARIN may
request this justification at any time. If justification is not
provided, future receipt of allocations may be impacted.
4.2.3.2. VLSM
To increase utilization efficiency of IPv4 address space, ISPs
reassigning IP address space to their customers should require their
customers to use variable length subnet mask (VLSM) and classless
technologies (CIDR) within their networks. ISPs should issue blocks
smaller than /24 wherever feasible.
4.2.3.3. Contiguous blocks
IP addresses are allocated to ISPs in contiguous blocks, which should
remain intact. Fragmentation of blocks is discouraged. To avoid
fragmentation, ISPs are encouraged to require their customers to return
address space if they change ISPs. Therefore, if a customer moves to
another service provider or otherwise terminates a contract with an ISP,
it is recommended that the customer return the network addresses to the
ISP and renumber into the new provider's address space. The original ISP
should allow sufficient time for the renumbering process to be completed
before requiring the address space to be returned.
4.2.3.4. Downstream customer adherence
ISPs must require their downstream customers to adhere to the following
criteria:
4.2.3.4.1. Utilization
Reassignment information for prior allocations must show that each
customer meets the 80% utilization criteria and must be available via
SWIP / RWhois prior to your issuing them additional space.
4.2.3.4.2. Downstream ISPs
Customers must follow ARIN policy for ISPs.
4.2.3.5. ARIN approval of reassignments/reallocations
4.2.3.5.1. /18
All extra-large ISPs making reassignments of a /18 or larger to a
customer must first have these reassignments reviewed and approved by ARIN.
4.2.3.5.2. /19
Small to large ISPs making customer reassignments of a /19 or larger
must first seek ARIN's approval.
4.2.3.5.3. Required documentation for pre-approval requests
* Network engineering plans - Network engineering plans including
subnets, host counts, and hosts per subnet, with projected
utilization rates and associated confidence levels of those
projections for one and two years,
* Deployment schedule - Deployment schedule for the network, including
major milestones for each subnet,
* Network topology diagrams.
4.2.3.6. Reassignments to multihomed downstream customers
Under normal circumstances an ISP is required to determine the prefix
size of their reassignment to a downstream customer according to the
guidelines set forth in RFC 2050. Specifically, a downstream customer
justifies their reassignment by demonstrating they have an immediate
requirement for 25% of the IP addresses being assigned, and that they
have a plan to utilize 50% of their assignment within one year of its
receipt. This policy allows a downstream customer's multihoming
requirement to serve as justification for a /24 reassignment from their
upstream ISP, regardless of host requirements. Downstream customers must
provide contact information for all of their upstream providers to the
ISP from whom they are requesting a /24. The ISP will then verify the
customer's multihoming requirement and may assign the customer a /24,
based on this policy. Customers may receive a /24 from only one of their
upstream providers under this policy without providing additional
justification. ISPs may demonstrate they have made an assignment to a
downstream customer under this policy by supplying ARIN with the
information they collected from the customer, as described above, or by
identifying the AS number of the customer. This information may be
requested by ARIN staff when reviewing an ISP's utilization during their
request for additional IP addresses space.
4.2.3.7. Registration
ISPs are required to demonstrate efficient use of IP address space
allocations by providing appropriate documentation, including but not
limited to assignment histories, showing their efficient use.
4.2.3.7.1. Reassignment Information
Each IPv4 assignment containing a /29 or more addresses shall be
registered in the WHOIS directory via SWIP or a distributed service
which meets the standards set forth in section 3.2. Reassignment
registrations shall include each client's organizational information,
except where specifically exempted by this policy.
4.2.3.7.2.Assignments visible within 7 days
All assignments shall be made visible as required in section 4.2.3.7.1
within seven calendar days of assignment.
4.2.3.7.3. Residential Subscribers
4.2.3.7.3.1. Residential Market Area
In most cases, ISPs that have residential subscribers assign address
space to their access infrastructure to which their customers connect
rather than to individual subscribers. This assignment information
regarding each market area holding an address block should be entered
via SWIP (or by using RWhois) with the network name used to identify
each market area. Initial allocations are based on total number of homes
that could purchase the service in a given market area.
Using SWIP or RWhois, residential access ISPs must show that they have
reassigned at least 80% of their current address space, with a 50 to 80%
utilization rate, in order to request additional addresses.
Each assignment to a specific end-user (if holding /29 and larger
blocks) requires the submission of a SWIP or use of an RWhois server.
Requesters will also be asked to provide detailed plans for use of the
newly requested space.
4.2.3.7.3.2. Residential Customer Privacy
To maintain the privacy of their residential customers, an organization
with downstream residential customers holding /29 and larger blocks may
substitute that organization's name for the customer's name, e.g.
'Private Customer - XYZ Network', and the customer's street address may
read 'Private Residence'. Each private downstream residential
reassignment must have accurate upstream Abuse and Technical POCs
visible on the WHOIS directory record for that block.
4.2.3.8. Reassignments for Third Party Internet Access
(TPIA) over Cable
IP addresses reassigned by an ISP to an incumbent cable operator for use
with Third Party Internet Access (TPIA) will be counted as fully used
once they are assigned to equipment by the underlying cable carrier
provided they meet the following requirements:
* initial assignments to each piece of hardware represent the smallest
subnet reasonably required to deploy service to the customer base
served by the hardware
* additional assignments to each piece of hardware are made only when
all previous assignments to that specific piece of hardware are at
least 80% used and represent a three month supply
* IP allocations issued through 4.2.3.8 are non-transferable via
section 8.3 and section 8.4 for a period of 36 months. In the case
of a section 8.2 transfer the IP assignment must be utilized for the
same purpose or needs based justification at a rate consistent with
intended use.
4.2.4. ISP Additional Requests
4.2.4.1. Utilization percentage (80%)
ISPs must have efficiently utilized all previous allocations and at
least 80% of their most recent allocation in order to receive additional
space. This includes all space reassigned to their customers. Please
note that until your prior utilization is verified to meet the 80%
requirement, ARIN can neither process nor approve a request for
additional addresses.
4.2.4.2. Return address space as agreed
Return prior address space designated for return as agreed.
4.2.4.3. Request size
ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or
a 24-month supply via 8.3 or 8.4 transfer. Determination of the
appropriate allocation to be issued is based on efficient utilization of
space within this time frame, consistent with the principles in 4.2.1.
4.2.4.4. [Section Number Retired]
4.2.5. [Section Number Retired]
4.2.6. [Section Number Retired]
4.3. End-users - Assignments to end-users
4.3.1. End-users
ARIN assigns blocks of IP addresses to end-users who request address
space for their internal use in running their own networks, but not for
sub-delegation of those addresses outside their organization. End-users
must meet the requirements described in these guidelines for justifying
the assignment of an address block.
4.3.2. Minimum assignment
4.3.2.1 Single Connection
The minimum block of IP address space assigned by ARIN to end-users is a
/24. If assignments smaller than /24 are needed, end-users should
contact their upstream provider.
4.3.2.2 [Section Number Retired]
4.3.3. Utilization rate
Utilization rate of address space is a key factor in justifying a new
assignment of IP address space. Requesters must show exactly how
previous address assignments have been utilized and must provide
appropriate details to verify their one-year growth projection. The
basic criteria that must be met are:
* A 25% immediate utilization rate, and
* A 50% utilization rate within one year.
A greater utilization rate may be required based on individual network
requirements. Please refer to RFC 2050 for more information on
utilization guidelines.
4.3.4. Additional considerations
End-users may qualify for address space under other policies such as
Immediate need [4.2.1.6 ] or Micro-allocation [4.4 ].
4.3.5. Non-connected Networks
End-users not currently connected to an ISP and/or not planning to be
connected to the Internet are encouraged to use private IP address
numbers reserved for non-connected networks (see RFC 1918
). When private, non-connected networks
require interconnectivity and the private IP address numbers are
ineffective, globally unique addresses may be requested and used to
provide this interconnectivity.
4.3.6 Additional Assignments
4.3.6.1 Utilization Requirements for Additional Assignment
In order to justify an additional assignment, end-users must have
efficiently utilized at least 80% of all previous assignments, and must
provide ARIN with utilization details. The prefix size for an additional
assignment is determined by applying the policies found in Section 4.3
of the NRPM.
4.4. Micro-allocation
ARIN will make IPv4 micro-allocations to critical infrastructure
providers of the Internet, including public exchange points, core DNS
service providers (e.g. ICANN-sanctioned root and ccTLD operators) as
well as the RIRs and IANA. These allocations will be no smaller than a
/24. Multiple allocations may be granted in certain situations.
Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.
Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
three total), ASN, and contact information. ISPs and other organizations
receiving these micro-allocations will be charged under the ISP fee
schedule, while end-users will be charged under the fee schedule for
end-users. This policy does not preclude exchange point operators from
requesting address space under other policies.
ARIN will place an equivalent of a /16 of IPv4 address space in a
reserve for Critical Infrastructure, as defined in section 4.4. If at
the end of the policy term there is unused address space remaining in
this pool, ARIN staff is authorized to utilize this space in a manner
consistent with community expectations.
ICANN-sanctioned gTLD operators may justify up to the equivalent of an
IPv4 /23 block for each authorized new gTLD, allocated from the free
pool or received via transfer, but not from the above reservation. This
limit of a /23 equivalent per gTLD does not apply to gTLD allocations
made under previous policy.
4.5. Multiple Discrete Networks
Organizations with multiple discrete networks desiring to request new or
additional address space under a single Organization ID must meet the
following criteria:
1. The organization shall be a single entity and not a consortium of
smaller independent entities.
2. The organization must have compelling criteria for creating discrete
networks. Examples of a discrete network might include:
1. Regulatory restrictions for data transmission,
2. Geographic distance and diversity between networks,
3. Autonomous multihomed discrete networks.
3. The organization must keep detailed records on how it has allocated
space to each location, including the date of each allocation.
4. When applying for additional internet address registrations from
ARIN, the organization must demonstrate utilization greater than 50%
of both the last block allocated and the aggregate sum of all blocks
allocated from ARIN to that organization. If an organization is
unable to satisfy this 50% minimum utilization criteria, the
organization may alternatively qualify for additional internet
address registrations by having all unallocated blocks of addresses
smaller than ARIN's current minimum allocation size.
5. The organization may not allocate additional address space to a
location until each of that location's address blocks are 80% utilized.
6. The organization should notify ARIN at the time of the request their
desire to apply this policy to their account.
7. Upon verification that the organization has shown evidence of
deployment of the new discrete network site, the new network(s)
shall be allocated the minimum allocation size under section 4.2.1.5
unless the organization can demonstrate additional need using the
immediate need criteria (4.2.1.6).
4.6., 4.7., 4.8., 4.9. [Section Number Retired]
4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.
This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block.
In order to receive an allocation or assignment under this policy:
1. the applicant may not have received resources under this policy in
the preceding six months;
2. previous allocations/assignments under this policy must continue to
meet the justification requirements of this policy;
3. previous allocations/assignments under this policy must meet the
utilization requirements of end user assignments;
4. the applicant must demonstrate that no other allocations or
assignments will meet this need;
5. on subsequent allocation under this policy, ARIN staff may require
applicants to renumber out of previously allocated / assigned space
under this policy in order to minimize non-contiguous allocations.
5. AS Numbers
There are a limited number of available Autonomous System Numbers (AS
Numbers), therefore, it is important to determine which sites require
unique AS Numbers and which do not. Sites that do not require a unique
AS Number should use one or more of the AS Numbers reserved for private
use. Those numbers are: 64512 through 65535.
In order to be assigned an AS Number, each requesting organization must
provide ARIN with verification that it has one of the following:
1. A unique routing policy (its policy differs from its border gateway
peers)
2. A multihomed site.
AS Numbers are issued based on current need. An organization should
request an AS Number only when it is already multihomed or will
immediately become multihomed.
5.1 [Section Number Retired]
6. IPv6
6.1. Introduction
6.1.1. Overview
This document describes policies for the allocation and assignment of
globally-unique Internet Protocol Version 6 (IPv6) address space. It
updates and obsoletes the existing Provisional IPv6 Policies in effect
since 1999. Policies described in this document are intended to be
adopted by each registry. However, adoption of this document does not
preclude local variations in each region or area.
RFC 2373, RFC 2373bis designate 2000::/3 to be global unicast address
space that IANA may allocate to the RIRs. In accordance with RFC 2928,
RFC 2373bis, 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.
6.2. [Section Number Retired]
6.3. Goals of IPv6 address space management
6.3.1. Goals
IPv6 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 IPv6
address policy.
6.3.2. Uniqueness
Every assignment and/or allocation of address space must guarantee
uniqueness worldwide. This is an absolute requirement for ensuring that
every public host on the Internet can be uniquely identified.
6.3.3. Registration
Internet address space must be registered in a registry database
accessible to appropriate members of the Internet community. This is
necessary to ensure the uniqueness of each Internet address and to
provide reference information for Internet troubleshooting at all
levels, ranging from all RIRs and IRs to end users.
The goal of registration should be applied within the context of
reasonable privacy considerations and applicable laws.
6.3.4. Aggregation
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 ISPs, and
to limit the expansion of Internet 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.
IPv6 address policies should seek to avoid fragmentation of address ranges.
Further, 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.
6.3.5. Conservation
Although IPv6 provides an extremely large pool of address space, address
policies should avoid unnecessarily wasteful practices. Requests for
address space should be supported by appropriate documentation and
stockpiling of unused addresses should be avoided.
6.3.6. Fairness
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.
6.3.7. Minimized Overhead
It is desirable to minimize the overhead associated with obtaining
address space. Overhead includes the need to go back to RIRs for
additional space too frequently, the overhead associated with managing
address space that grows through a number of small successive
incremental expansions rather than through fewer, but larger, expansions.
6.3.8. Conflict of goals
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 allocations and assignments must make judgments, seeking to balance
the needs of the applicant with the needs of the Internet community as a
whole.
In IPv6 address policy, the goal of aggregation is considered to be the
most important.
6.4. IPv6 Policy Principles
To address the goals described in the previous section, the policies in
this document discuss and follow the basic principles described below.
6.4.1. Address space not to be considered property
It is contrary to the goals of this document and is not in the interests
of the Internet community as a whole for address space to be considered
freehold property.
The policies in this document are based upon the understanding that
globally-unique IPv6 unicast address space is allocated/assigned for use
rather than owned.
6.4.2. Routability not guaranteed
There is no guarantee that any address allocation or assignment will be
globally routable.
However, RIRs must apply procedures that reduce the possibility of
fragmented address space which may lead to a loss of routability.
6.4.3. [Section Number Retired]
6.4.4. Consideration of IPv4 Infrastructure
Where an existing IPv4 service provider requests IPv6 space for eventual
transition of existing services to IPv6, the number of present IPv4
customers may be used to justify a larger request than would be
justified if based solely on the IPv6 infrastructure.
6.5. Policies for allocations and assignments
6.5.1. Terminology
1. The terms ISP and LIR are used interchangeably in this document and
any use of either term shall be construed to include both meanings.
2. The term nibble boundary shall mean a network mask which aligns on a
4-bit boundary (in slash notation, /n, where n is evenly divisible
by 4, allowing unit quantities of X such that 2^n=X where n is
evenly divisible by 4, such as 16, 256, 4096, etc.)
6.5.2. Initial allocation to LIRs
6.5.2.1. Size
1. All allocations shall be made on nibble boundaries.
2. In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36. In no case shall an ISP receive more
than a /16 initial allocation.
3. The maximum allowable allocation shall be the smallest
nibble-boundary aligned block that can provide an equally sized
nibble-boundary aligned block to each of the requesters serving
sites large enough to satisfy the needs of the requesters largest
single serving site using no more than 75% of the available addresses.
This calculation can be summarized as /N where N = P-(X+Y) and P is
the organization's Provider Allocation Unit X is a multiple of 4
greater than 4/3*serving sites and Y is a multiple of 4 greater than
4/3*end sites served by largest serving site.
4. For purposes of the calculation in (c), an end site which can
justify more than a /48 under the end-user assignment criteria in
6.5.8 shall count as the appropriate number of /48s that would be
assigned under that policy.
5. For purposes of the calculation in (c), an LIR which has subordinate
LIRs shall make such allocations according to the same policies and
criteria as ARIN. In such a case, the prefixes necessary for such an
allocation should be treated as fully utilized in determining the
block sizing for the parent LIR. LIRs which do not receive resources
directly from ARIN will not be able to make such allocations to
subordinate LIRs and subordinate LIRs which need more than a /32
shall apply directly to ARIN.
6. An LIR is not required to design or deploy their network according
to this structure. It is strictly a mechanism to determine the
largest IP address block to which the LIR is entitled.
6.5.2.2. Qualifications
An organization qualifies for an allocation under this policy if they
meet any of the following criteria:
1. Have a previously justified IPv4 ISP allocation from ARIN or one of
its predecessor registries or can qualify for an IPv4 ISP allocation
under current criteria.
2. Are currently multihomed for IPv6 or will immediately become
multihomed for IPv6 using a valid assigned global AS number.
In either case, they will be making reassignments from allocation(s)
under this policy to other organizations.
3. Provide ARIN a reasonable technical justification indicating why an
allocation is necessary. Justification must include the intended
purposes for the allocation and describe the network infrastructure
the allocation will be used to support. Justification must also
include a plan detailing anticipated assignments to other
organizations or customers for one, two and five year periods, with
a minimum of 50 assignments within 5 years.
6.5.3. Subsequent Allocations to LIRs
1. Where possible ARIN will make subsequent allocations by expanding
the existing allocation.
2. An LIR qualifies for a subsequent allocation if they meet any of the
following criteria:
* Shows utilization of 75% or more of their total address space
* Shows utilization of more than 90% of any serving site
* Has allocated more than 90% of their total address space to
serving sites, with the block size allocated to each serving
site being justified based on the criteria specified in section
6.5.2
3. If ARIN can not expand one or more existing allocations, ARIN shall
make a new allocation based on the initial allocation criteria
above. The LIR is encouraged, but not required to renumber into the
new allocation over time and return any allocations no longer in use.
4. If an LIR has already reached a /12 or more, ARIN will allocate a
single additional /12 rather than continue expanding nibble boundaries.
6.5.3.1. Subsequent Allocations for Transition
Subsequent allocations will also be considered for deployments that
cannot be accommodated by, nor were accounted for, under the initial
allocation. Justification for the subsequent subnet size will be based
on the plan and technology provided with a /24 being the maximum allowed
for a transition technology. Justification for transitional allocations
will be reviewed every 3 years and reclaimed if they are no longer in
use for transitional purposes. All such allocations for transitional
technology will be made from a block designated for this purpose.
6.5.4. Assignments from LIRs/ISPs
Assignments to end users shall be governed by the same practices adopted
by the community in section 6.5.8 except that the requirements in
6.5.8.1 do not apply.
6.5.4.1. Assignment to operator's infrastructure
An LIR may assign up to a /48 per PoP as well as up to an additional /48
globally for its own infrastructure.
6.5.5. Registration
ISPs are required to demonstrate efficient use of IP address space
allocations by providing appropriate documentation, including but not
limited to assignment histories, showing their efficient use.
6.5.5.1. Reassignment information
Each static IPv6 assignment containing a /64 or more addresses shall be
registered in the WHOIS directory via SWIP or a distributed service
which meets the standards set forth in section 3.2. Reassignment
registrations shall include each client's organizational information,
except where specifically exempted by this policy.
6.5.5.2. Assignments visible within 7 days
All assignments shall be made visible as required in section 4.2.3.7.1
within seven calendar days of assignment.
6.5.5.3. Residential Subscribers
6.5.5.3.1. Residential Customer Privacy
To maintain the privacy of their residential customers, an organization
with downstream residential customers holding /64 and larger blocks may
substitute that organization's name for the customer's name, e.g.
'Private Customer - XYZ Network', and the customer's street address may
read 'Private Residence'. Each private downstream residential
reassignment must have accurate upstream Abuse and Technical POCs
visible on the WHOIS record for that block.
6.5.6. Reverse lookup
When an RIR delegates IPv6 address space to an organization, it also
delegates 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 assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.
6.5.7. Existing IPv6 address space holders
LIRs which received an allocation under previous policies which is
smaller than what they are entitled to under this policy may receive a
new initial allocation under this policy. If possible, ARIN will expand
their existing allocation.
6.5.8. Direct assignments from ARIN to end-user organizations
6.5.8.1. Initial Assignment Criteria
Organizations may justify an initial assignment for addressing devices
directly attached to their own network infrastructure, with an intent
for the addresses to begin operational use within 12 months, by meeting
one of the following criteria:
1. Having a previously justified IPv4 end-user assignment from ARIN or
one of its predecessor registries, or;
2. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;
3. By having a network that makes active use of a minimum of 2000 IPv6
addresses within 12 months, or;
4. By having a network that makes active use of a minimum of 200 /64
subnets within 12 months, or;
5. By providing a reasonable technical justification indicating why
IPv6 addresses from an ISP or other LIR are unsuitable.
Examples of justifications for why addresses from an ISP or other LIR
may be unsuitable include, but are not limited to:
* An organization that operates infrastructure critical to life safety
or the functioning of society can justify the need for an assignment
based on the fact that renumbering would have a broader than
expected impact than simply the number of hosts directly involved.
These would include: hospitals, fire fighting, police, emergency
response, power or energy distribution, water or waste treatment,
traffic management and control, etc.
* Regardless of the number of hosts directly involved, an organization
can justify the need for an assignment if renumbering would affect
2000 or more individuals either internal or external to the
organization.
* An organization with a network not connected to the Internet can
justify the need for an assignment by documenting a need for
guaranteed uniqueness, beyond the statistical uniqueness provided by
ULA (see RFC 4193).
* An organization with a network not connected to the Internet, such
as a VPN overlay network, can justify the need for an assignment if
they require authoritative delegation of reverse DNS.
6.5.8.2. Initial assignment size
Organizations that meet at least one of the initial assignment criteria
above are eligible to receive an initial assignment of /48. Requests for
larger initial assignments, reasonably justified with supporting
documentation, will be evaluated based on the number of sites in an
organization’s network and the number of subnets needed to support any
extra-large sites defined below.
The initial assignment size will be determined by the number of sites
justified below. An organization qualifies for an assignment on the next
larger nibble boundary when their sites exceed 75% of the /48s available
in a prefix. For example:
More than 1 but less than or equal to 12 sites justified, receives a /44
assignment;
More than 12 but less than or equal to 192 sites justified, receives a
/40 assignment;
More than 192 but less than or equal to 3,072 sites justified, receives
a /36 assignment;
More than 3,072 but less than or equal to 49,152 sites justified,
receives a /32 assignment; etc...
6.5.8.2.1. Standard sites
A site is a discrete location that is part of an organization’s network.
A campus with multiple buildings may be considered as one or multiple
sites, based on the implementation of its network infrastructure. For a
campus to be considered as multiple sites, reasonable technical
documentation must be submitted describing how the network
infrastructure is implemented in a manner equivalent to multiple sites.
An organization may request up to a /48 for each site in its network,
and any sites that will be operational within 12 months.
6.5.8.2.2. Extra-large sites
In rare cases, an organization may request more than a /48 for an
extra-large site which requires more than 16,384 /64 subnets. In such a
case, a detailed subnet plan must be submitted for each extra-large site
in an organization’s network. An extra-large site qualifies for the next
larger prefix when the total subnet utilization exceeds 25%. Each
extra-large site will be counted as an equivalent number of /48 standard
sites.
6.5.8.3. Subsequent assignments
Requests for subsequent assignments with supporting documentation will
be evaluated based on the same criteria as an initial assignment under
6.5.8.2 with the following modifications:
1. A subsequent assignment is justified when the total utilization
based on the number of sites justified exceeds 75% across all of an
organization’s assignments. If the organization received an
assignment per section 6.11 IPv6 Multiple Discrete Networks, such
assignments will be evaluated as if they were to a separate
organization.
2. When possible subsequent assignments will result it the expansion of
an existing assignment by one or more nibble boundaries as justified.
3. If it is not possible to expand an existing assignment, or to expand
it adequately to meet the justified need, then a separate new
assignment will be made of the size justified.
6.5.8.4. Consolidation and return of separate assignments
Organizations with multiple separate assignments should consolidate into
a single aggregate, if feasible. If an organization stops using one or
more of its separate assignments, any unused assignments must be
returned to ARIN.
6.5.9. Community Network Assignments
6.5.9.1. Qualification Criteria
To qualify for a direct assignment, a community network must demonstrate
it will immediately provide sustained service to at least 100
simultaneous users and must demonstrate a plan to provide sustained
service to at least 200 simultaneous users within one year. For
community networks located in rural regions (population less than 2,500)
or in the Caribbean and North Atlantic Islands Sector, the numbers in
these qualification criteria may be relaxed at ARIN's discretion.
6.5.9.2. Initial assignment size
The minimum size of the assignment is /48. Organizations requesting a
larger assignment must provide documentation of the characteristics of
the Community Network's size and architecture that require the use of
additional subnets. An HD-Ratio of .94 with respect to subnet
utilization within the network must be met for all assignments larger
than a /48. These assignments shall be made from a distinctly identified
prefix and shall be made with a reservation for growth of at least a
/44. This reservation may be assigned to other organizations later, at
ARIN's discretion.
6.5.9.3. Subsequent assignment size
Additional assignments may be made when the need for additional subnets
is justified. Justification will be determined based on a detailed plan
of the network's architecture and the .94 HD-Ratio metric. When
possible, assignments will be made from an aggregatable adjacent address
block.
6.6. [Section Number Retired]
6.7. Appendix A: HD-Ratio
The HD-Ratio is not intended to replace the traditional utilization
measurement that ISPs perform with IPv4 today. Indeed, the HD-Ratio
still requires counting the number of assigned objects. The primary
value of the HD-Ratio is its usefulness at determining reasonable target
utilization threshold values for an address space of a given size. This
document uses the HD-Ratio to determine the thresholds at which a given
allocation has achieved an acceptable level of utilization and the
assignment of additional address space becomes justified.
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 ratio. 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.
The following table provides equivalent absolute and percentage address
utilization figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94
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%
6.8. [Section Number Retired]
6.9. [Section Number Retired]
6.10. Micro-allocations
6.10.1 Micro-allocations for Critical Infrastructure
ARIN will make micro-allocations to critical infrastructure providers of
the Internet, including public exchange points, core DNS service
providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as
well as the RIRs and IANA. These allocations will be no smaller than a
/24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted
in certain situations. - Exchange point allocations MUST be allocated
from specific blocks reserved only for this purpose. All other
micro-allocations WILL be allocated out of other blocks reserved for
micro-allocation purposes. ARIN will make a list of these blocks
publicly available. - Exchange point operators must provide
justification for the allocation, including: connection policy,
location, other participants (minimum of two total), ASN, and contact
information. ISPs and other organizations receiving these
micro-allocations will be charged under the ISP fee schedule, while
end-users will be charged under the fee schedule for end-users. This
policy does not preclude exchange point operators from requesting
address space under other policies.
6.10.2 Micro-allocations for Internal Infrastructure
Organizations that currently hold IPv6 allocations may apply for a
micro-allocation for internal infrastructure. Applicant must provide
technical justification indicating why a separate non-routed block is
required. Justification must include why a sub-allocation of currently
held IP space cannot be utilized. Internal infrastructure allocations
must be allocated from specific blocks reserved only for this purpose.
6.11. IPv6 Multiple Discrete Networks
Organizations with multiple discrete IPv6 networks desiring to request
new or additional address space under a single Organization ID must meet
the following criteria:
1. The organization shall be a single entity and not a consortium of
smaller independent entities.
2. The organization must have compelling criteria for creating discrete
networks. Examples of a discrete network might include:
* Regulatory restrictions for data transmission,
* Geographic distance and diversity between networks,
* Autonomous multihomed discrete networks.
3. The organization must keep detailed records on how it has allocated
space to each location, including the date of each allocation.
4. The organization should notify ARIN at the time of the request their
desire to apply this policy to their account.
5. Requests for additional space:
1. Organization must specify on the application which discrete
network(s) the request applies to
2. Each network will be judged against the existing utilization
criteria specified in 6.5.2 and 6.5.3 as if it were a separate
organization, rather than collectively as would be done for
requests outside of this policy.
7. Reverse Mapping
7.1. Maintaining IN-ADDRs
All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain
records for their respective customers. For blocks smaller than /16, and
for the segment of larger blocks smaller than /16, ARIN can maintain
IN-ADDRs.
7.2. [Section Number Retired]
8. Transfers
8.1. Principles
Number resources are nontransferable and are not assignable to any other
organization unless ARIN has expressly and in writing approved a request
for transfer. ARIN is tasked with making prudent decisions on whether to
approve the transfer of number resources.
It should be understood that number resources are not 'sold' under ARIN
administration. Rather, number resources are assigned to an organization
for its exclusive use for the purpose stated in the request, provided
the terms of the Registration Services Agreement continue to be met and
the stated purpose for the number resources remains the same. Number
resources are administered and assigned according to ARIN's published
policies.
Number resources are issued, based on justified need, to organizations,
not to individuals representing those organizations. Thus, if a company
goes out of business, regardless of the reason, the point of contact
(POC) listed for the number resource does not have the authority to
sell, transfer, assign, or give the number resource to any other person
or organization. The POC must notify ARIN if a business fails so the
assigned number resources can be returned to the available pool of
number resources if a transfer is not requested and justified.
8.2. Mergers and Acquisitions
ARIN will consider requests for the transfer of number resources in the
case of mergers, acquisitions, and reorganizations under the following
conditions:
* The new entity must provide evidence that they have acquired assets
that use the resources to be transferred from the current
registrant. ARIN will maintain an up-to-date list of acceptable
types of documentation.
* The current registrant must not be involved in any dispute as to the
status of the resources to be transferred.
* The new entity must sign an RSA covering all resources to be
transferred.
* The resources to be transferred will be subject to ARIN policies.
* The minimum transfer size is the smaller of the original allocation
size or the applicable minimum allocation size in current policy.
In the event that number resources of the combined organizations are no
longer justified under ARIN policy at the time ARIN becomes aware of the
transaction, through a transfer request or otherwise, ARIN will work
with the resource holder(s) to return or transfer resources as needed to
restore compliance via the processes outlined in current ARIN policy.
8.3. Transfers between Specified Recipients within the ARIN Region
In addition to transfers under section 8.2, IPv4 numbers resources and
ASNs may be transferred according to the following conditions.
Conditions on source of the transfer:
* The source entity must be the current registered holder of the IPv4
address resources, and not be involved in any dispute as to the
status of those resources.
* The source entity will be ineligible to receive any further IPv4
address allocations or assignments from ARIN for a period of 12
months after a transfer approval, or until the exhaustion of ARIN's
IPv4 space, whichever occurs first.
* The source entity must not have received a transfer, allocation, or
assignment of IPv4 number resources from ARIN for the 12 months
prior to the approval of a transfer request. This restriction does
not include M&A transfers.
* The minimum transfer size is a /24
Conditions on recipient of the transfer:
* The recipient must demonstrate the need for up to a 24-month supply
of IP address resources under current ARIN policies and sign an RSA.
* The resources transferred will be subject to current ARIN policies.
8.4. Inter-RIR Transfers to Specified Recipients
Inter-regional transfers may take place only via RIRs who agree to the
transfer and share reciprocal, compatible, needs-based policies.
Conditions on source of the transfer:
* The source entity must be the current rights holder of the IPv4
address resources recognized by the RIR responsible for the
resources, and not be involved in any dispute as to the status of
those resources.
* Source entities outside of the ARIN region must meet any
requirements defined by the RIR where the source entity holds the
registration.
* Source entities within the ARIN region will not be eligible to
receive any further IPv4 address allocations or assignments from
ARIN for a period of 12 months after a transfer approval, or until
the exhaustion of ARIN's IPv4 space, whichever occurs first.
* Source entities within the ARIN region must not have received a
transfer, allocation, or assignment of IPv4 number resources from
ARIN for the 12 months prior to the approval of a transfer request.
This restriction does not include M&A transfers.
* The minimum transfer size is a /24.
Conditions on recipient of the transfer:
* The conditions on a recipient outside of the ARIN region will be
defined by the policies of the receiving RIR.
* Recipients within the ARIN region will be subject to current ARIN
policies and sign an RSA for the resources being received.
* Recipients within the ARIN region must demonstrate the need for up
to a 24-month supply of IPv4 address space.
* The minimum transfer size is a /24.
9. [reserved]
10. Global Number Resource Policy
10.1. IANA to RIR Allocation of IPv4 Address Space
This document describes the policies governing the allocation of IPv4
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with these
policies. Such requirements should be specified by appropriate
agreements among the RIRs and ICANN.
1. Allocation Principles
* The IANA will allocate IPv4 address space to the RIRs in /8 units.
* The IANA will allocate sufficient IPv4 address space to the RIRs to
support their registration needs for at least an 18 month period.
* The IANA will allow for the RIRs to apply their own respective
chosen allocation and reservation strategies in order to ensure the
efficiency and efficacy of their work.
2. Initial Allocations
Each new RIR shall, at the moment of recognition, be allocated a new /8
by the IANA. This allocation will be made regardless of the newly formed
RIR's projected utilization figures and shall be independent of the IPv4
address space that may have been transferred to the new RIR by the
already existing RIRs as part of the formal transition process.
3. Additional Allocations
A RIR is eligible to receive additional IPv4 address space from the IANA
when either of the following conditions are met.
* The RIR's AVAILABLE SPACE of IPv4 addresses is less than 50% of a /8
block.
* The RIR's AVAILABLE SPACE of IPv4 addresses is less than its
established NECESSARY SPACE for the following 9 months.
In either case, IANA shall make a single allocation of a whole number of
/8 blocks, sufficient to satisfy the established NECESSARY SPACE of the
RIR for an 18 month period.
3.1 Calculation of AVAILABLE SPACE
The AVAILABLE SPACE of IPv4 addresses of a RIR shall be determined as
follows:
AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING
DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE
FRAGMENTED SPACE is determined as the total amount of available blocks
smaller than the RIR's minimum allocation size within the RIR's
currently available stock.
3.2 Calculation of NECESSARY SPACE
If the applying Regional Internet Registry does not establish any
special needs for the period concerned, NECESSARY SPACE shall be
determined as follows:
NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING
THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS
If the applying RIR anticipates that due to certain special needs the
rate of allocation for the period concerned will be greater than the
previous 6 months, it may determine its NECESSARY SPACE as follows:
A) Calculate NECESSARY SPACE as its total needs for that period
according to its projection and based on the special facts that justify
these needs.
B) Submit a clear and detailed justification of the above mentioned
projection (Item A).
If the justification is based on the allocation tendency prepared by the
Regional Internet Registry, data explaining said tendency must be enclosed.
If the justification is based on the application of one or more of the
Regional Internet Registry's new allocation policies, an impact analysis
of the new policy/policies must be enclosed.
If the justification is based on external factors such as new
infrastructure, new services within the region, technological advances
or legal issues, the corresponding analysis must be enclosed together
with references to information sources that will allow verification of
the data.
If IANA does not have elements that clearly question the Regional
Internet Registry's projection, the special needs projected for the
following 18 months, indicated in Item A above, shall be considered valid.
4. Announcement of IANA Allocations
When address space is allocated to a RIR, the IANA will send a detailed
announcement to the receiving RIR. The IANA will also make announcements
to all other RIRs, informing them of the recent allocation. The RIRs
will coordinate announcements to their respective membership lists and
any other lists they deem necessary.
The IANA will make appropriate modifications to the "Internet Protocol
V4 Address Space" page of the IANA website and may make announcements to
its own appropriate announcement lists. The IANA announcements will be
limited to which address ranges, the time of allocation and to which
Registry they have been allocated.
10.2 Allocation of IPv6 Address Space by the Internet Assigned
Numbers Authority (IANA) Policy to Regional Internet Registries
This document describes the policy governing the allocation of IPv6
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with this policy.
Such requirements will be specified by appropriate agreements between
ICANN and the NRO.
1. Allocation Principles
* The unit of IPv6 allocation (and therefore the minimum IPv6
allocation) from IANA to an RIR is a /12
* The IANA will allocate sufficient IPv6 address space to the RIRs to
support their registration needs for at least an 18 month period.
* The IANA will allow for the RIRs to apply their own respective
chosen allocation and reservation strategies in order to ensure the
efficiency and efficacy of their work.
2. Initial Allocations
* On inception of this policy, each current RIR with less than a /12
unallocated address space, shall receive an IPv6 allocation from IANA
* Any new RIR shall, on recognition by ICANN receive an IPv6
allocation from the IANA
3. Additional Allocations
A RIR is eligible to receive additional IPv6 address space from the
IANA when either of the following conditions are met.
* The RIR's AVAILABLE SPACE of IPv6 addresses is less than 50% of
a /12.
* The RIR's AVAILABLE SPACE of IPv6 addresses is less than its
established NECESSARY SPACE for the following 9 months.
In either case, IANA shall make a single IPv6 allocation, sufficient
to satisfy the established NECESSARY SPACE of the RIR for an 18
month period.
3.1 Calculation of AVAILABLE SPACE
The AVAILABLE SPACE of IPv6 addresses of a RIR shall be determined
as follows:
AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING
DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE
FRAGMENTED SPACE is determined as the total amount of available
blocks smaller than the RIR's minimum allocation size within the
RIR's currently available stock.
3.2 Calculation of NECESSARY SPACE
If the applying Regional Internet Registry does not establish any
special needs for the period concerned, NECESSARY SPACE shall be
determined as follows:
NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY
DURING THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS
If the applying RIR anticipates that due to certain special needs
the rate of allocation for the period concerned will be different
from the previous 6 months, it may determine its NECESSARY SPACE as
follows:
Calculate NECESSARY SPACE as its total needs for that period
according to its projection and based on the special facts that
justify these needs.
Submit a clear and detailed justification of the above mentioned
projection (Item A).
If the justification is based on the allocation tendency prepared by
the Regional Internet Registry, data explaining said tendency must
be enclosed.
If the justification is based on the application of one or more of
the Regional Internet Registry's new allocation policies, an impact
analysis of the new policy/policies must be enclosed.
If the justification is based on external factors such as new
infrastructure, new services within the region, technological
advances or legal issues, the corresponding analysis must be
enclosed together with references to information sources that will
allow verification of the data.
If IANA does not have elements that clearly question the Regional
Internet Registry's projection, the special needs projected for the
following 18 months, indicated in Item A above, shall be considered
valid.
4. Announcement of IANA Allocations
The IANA, the NRO, and the RIRs will make announcements and update their
respective web sites regarding an allocation made by the IANA to an RIR.
ICANN and the NRO will establish administrative procedures to manage
this process.
10.3 IANA Policy for Allocation of ASN Blocks to RIRs
Abstract
This document describes the policy governing the allocation of
Autonomous System Numbers (ASNs) from the IANA to the Regional Internet
Registries (RIRs).
This policy document does not stipulate performance requirements in the
provision of services by the IANA to an RIR. Such requirements will be
specified by appropriate agreements between ICANN and the Number
Resource Organization (NRO).
1. Allocation Principles
IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the
term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010,
allocations of 2-byte only and 4-byte only ASN blocks will be made
separately and independent of each other.
This means until 31 December 2010, RIRs can receive two separate ASN
blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the
IANA under this policy. After this date, IANA and the RIRs will cease to
make any distinction between 2-byte only and 4-byte only ASNs, and will
operate ASN allocations from an undifferentiated 4-byte ASN allocation pool.
2. Initial Allocations
Each new RIR will be allocated a new ASN block.
3. Additional Allocations
An RIR is eligible to receive (an) additional ASN block(s) from the IANA
if one of the following conditions is met:
1. The RIR has assigned/allocated 80% of the previously received ASN
block, or
2. The number of free ASNs currently held by the RIR is less than two
months need. This projection is based on the monthly average number
of ASNs assigned/allocated by the RIR over the previous six months.
An RIR will be allocated as many ASN blocks as are needed to support
their registration needs for the next 12 months, based on their average
assignment/allocation rate over the previous six months, unless the RIR
specifically requests fewer blocks than it qualifies for.
4. Announcement of IANA Allocations
The IANA, the NRO and the RIRs will make announcements and update their
respective websites/databases when an allocation is made by the IANA to
an RIR. ICANN and the NRO will establish administrative procedures to
manage this process.
10.4. Global Policy for the Allocation of the Remaining IPv4
Address Space
This policy describes the process for the allocation of the remaining
IPv4 space from IANA to the RIRs. When a minimum amount of available
space is reached, one /8 will be allocated from IANA to each RIR,
replacing the current IPv4 allocation policy.
In order to fulfill the requirements of this policy, at the time it is
adopted, one /8 will be reserved by IANA for each RIR. The reserved
allocation units will no longer be part of the available space at the
IANA pool. IANA will also reserve one /8 to any new RIR at the time it
is recognized.
The process for the allocation of the remaining IPv4 space is divided in
two consecutive phases:
10.4.1 Existing Policy Phase
During this phase IANA will continue allocating IPv4 addresses to the
RIRs using the existing allocation policy. This phase will continue
until a request for IPv4 address space from any RIR to IANA either
cannot be fulfilled with the remaining IPv4 space available at the IANA
pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty.
This will be the last IPv4 address space request that IANA will accept
from any RIR. At this point the next phase of the process (Exhaustion
Phase) will be initiated.
10.4.2 Exhaustion Phase
During this phase IANA will automatically allocate the reserved IPv4
allocation units to each RIR (one /8 to each one) and respond to the
last request with the remaining available allocation units at the IANA
pool (M units).
10.4.2.1 Size of the final IPv4 allocations
In this phase IANA will automatically allocate one /8 to each RIR from
the reserved space as defined in this policy. IANA will also allocate M
allocation units to the RIR that submitted the last request for IPv4
addresses.
10.4.2.2 Allocation of the remaining IPv4 Address space
After the completion of the evaluation of the final request for IPv4
addresses, IANA MUST:
1. Immediately notify the NRO about the activation of the second phase
(Exhaustion Phase) of this policy.
2. Proceed to allocate M allocation units to the RIR that submitted the
last request for IPv4 address space.
3. Proceed to allocate one /8 to each RIR from the reserved space.
10.5. Global Policy for Post Exhaustion IPv4 Allocation
Mechanisms by the IANA
The IANA shall establish a Recovered IPv4 Pool to be utilized post RIR
IPv4 exhaustion. The Recovered IPv4 Pool will initially contain any
fragments that may be left over in the IANA. It will also hold
any space returned to the IANA by any other means.
The Recovered IPv4 Pool will be administered by the IANA. It will contain:
a. Any fragments left over in the IANA inventory after the last /8s of
IPv4 space are delegated to the RIRs
* The IANA inventory excludes "Special use IPv4 addresses" as defined
in BCP 153 and any addresses allocated by the IANA for experimental use.
b. Any IPv4 space returned to the IANA by any means.
The Recovered IPv4 Pool will stay inactive until the first RIR has less
than a total of a /9 in its inventory of IPv4 address space. When one of
the RIRs declares it has less than a total of a /9 in its inventory, the
Recovered IPv4 pool will be declared active, and IP addresses from the
Recovered IPv4 Pool will be allocated as follows:
a. Allocations from the IANA may begin once the pool is declared active.
b. In each "IPv4 allocation period", each RIR will receive a single
"IPv4 allocation unit" from the IANA.
c. An "IPv4 allocation period" is defined as a 6-month period following
1 March or 1 September in each year.
d. The IANA will calculate the size of the "IPv4 allocation unit" at the
following times:
* When the Recovered IPv4 Pool is first activated
* At the beginning of each IPv4 allocation period
To calculate the "IPv4 allocation unit" at these times, the IANA will
use the following formula:
IPv4 allocation unit = 1/5 of Recovered IPv4 pool, rounded down to the
next CIDR
(power-of-2) boundary.
No RIR may get more than this calculation used to determine the IPv4
allocation unit even when they can justify a need for it.
The minimum "IPv4 allocation unit" size will be a /24. If the
calculation used to determine the IPv4 allocation unit results in a
block smaller than a /24, the IANA will not distribute any addresses in
that IPv4 allocation period.
The IANA may make public announcements of IPv4 address transactions that
occur under this policy. The IANA will make appropriate modifications to
the "Internet Protocol V4 Address Space" page of the IANA website and
may make announcements to its own appropriate announcement lists. The
IANA announcements will be limited to which address ranges, the time of
allocation, and to which Registry they have been allocated.
11. Experimental Internet Resource Allocations
ARIN will allocate Numbering Resources to entities requiring temporary
Numbering Resources for a fixed period of time under the terms of
recognized experimental activity.
"Numbering Resources" refers to unicast IPv4 or IPv6 address space and
Autonomous System numbers.
The following are the criteria for this policy:
11.1 Documentation of recognized experimental activity
A Recognized Experimental Activity is one where the experiment's
objectives and practices are described in a publicly accessible
document. It is a normal requirement that a Recognized Experimental
Activity also includes the undertaking that the experiment's outcomes be
published in a publicly accessible document at the end of the
experiment. The conditions for determining the end of the experiment are
to be included in the document. Applicants for an experimental
allocation are expected to demonstrate an understanding that when the
experiment ends, the allocation will be returned; a successful
experiment may need a new allocation under normal policies in order to
continue in production or commercial use, but will not retain the
experimental allocation.
A "publicly accessible document" is a document that is publicly and
openly available free of charges and free of any constraints of disclosure.
ARIN will not recognize an experimental activity under this policy if
the entire research experiment cannot be publicly disclosed.
ARIN has a strong preference for the recognition of experimental
activity documentation in the form of a document which has been approved
for publication by the IESG or by a similar mechanism as implemented by
the IETF.
11.2 Technical Coordination
ARIN requires that a recognized experimental activity is able to
demonstrate that the activity is technically coordinated.
Technical coordination specifically includes consideration of any
potential negative impact of the proposed experiment on the operation of
the Internet and its deployed services, and consideration of any related
experimental activity.
ARIN will review planned experimental activities to ensure that they are
technically coordinated. This review will be conducted with ARIN and/or
third-party expertise and will include liaison with the IETF.
11.3 Coordination over Resource Use
When the IETF's standards development process proposes a change in the
use of Numbering Resources on an experimental basis the IETF should use
a liaison mechanism with the Regional Internet Registries (RIRs) of this
proposal. The RIRs will jointly or severally respond to the IETF using
the same liaison mechanism.
11.4 Resource Allocation Term and Renewal
The Numbering Resources are allocated for a period of one year. The
allocation can be renewed on application to ARIN providing information
as per Detail One. The identity and details of the applicant and the
allocated Numbering Resources will be published under the conditions of
ARIN's normal publication policy. At the end of the experiment,
resources allocated under this policy will be returned to the available
pool.
11.5 Single Resource Allocation per Experiment
ARIN will make one-off allocations only, on an annual basis to any
applicant. Additional allocations to an organization already holding
experimental activity resources relating to the specified activity
outside the annual cycle will not be made unless justified by a
subsequent complete application.
It's important for the requesting organization to ensure they have
sufficient resources requested as part of their initial application for
the proposed experimental use.
11.6 Resource Allocation Fees
ARIN may charge an administration fee to cover each allocation made of
these experimental resources. This fee simply covers registration and
maintenance, rather than the full allocation process for standard ARIN
members. This administration fee should be as low as possible as these
requests do not have to undergo the same evaluation process as those
requested in the normal policy environment.
11.7 Resource Allocation Guidelines
The Numbering Resources requested come from the global Internet Resource
space, do not overlap currently assigned space, and are not from private
or other non-routable Internet Resource space. The allocation size shall
be consistent with the existing ARIN minimum allocation sizes, unless
smaller allocations are intended to be explicitly part of the
experiment. If an organization requires more resources than stipulated
by the minimum allocation size in force at the time of its request, the
request must clearly describe and justify why a larger allocation is
required. All research allocations must be registered publicly in whois.
Each research allocation will be designated as a research allocation
with a comment indicating when the allocation will end.
11.8 Commercial Use Prohibited
If there is any evidence that the temporary resource is being used for
commercial purposes, or is being used for any activities not documented
in the original experiment description provided to ARIN, ARIN reserves
the right to immediately withdraw the resource and reassign it to the
free pool.
11.9 Resource Request Appeal or Arbitration
ARIN reserves the ability to assess and comment on the objectives of the
experiment with regard to the requested amount of Numbering Resources
and its technical coordination. ARIN reserves the ability to modify the
requested allocation as appropriate, and in agreement with the proposer.
In the event that the proposed modifications are not acceptable, the
requesting organization may request an appeal or arbitration using the
normal ARIN procedures. In this case, the original proposer of the
experimental activity may be requested to provide additional information
regarding the experiment, its objectives and the manner of technical
coordination, to assist in the resolution of the appeal.
12. Resource Review
1. ARIN may review the current usage of any resources maintained in the
ARIN database. The organization shall cooperate with any request
from ARIN for reasonable related documentation.
2. ARIN may conduct such reviews:
1. when any new resource is requested,
2. whenever ARIN has reason to believe that the resources were
originally obtained fraudulently or in contravention of existing
policy, or
3. whenever ARIN has reason to believe that an organization is not
complying with reassignment policies, or
4. at any other time without having to establish cause unless a
full review has been completed in the preceding 24 months.
3. At the conclusion of a review in which ARIN has solicited
information from the resource holder, ARIN shall communicate to the
resource holder that the review has been concluded and what, if any,
further actions are required.
4. Organizations found by ARIN to be materially out of compliance with
current ARIN policy shall be requested or required to return
resources as needed to bring them into (or reasonably close to)
compliance.
1. The degree to which an organization may remain out of compliance
shall be based on the reasonable judgment of the ARIN staff and
shall balance all facts known, including the organization's
utilization rate, available address pool, and other factors as
appropriate so as to avoid forcing returns which will result in
near-term additional requests or unnecessary route de-aggregation.
2. To the extent possible, entire blocks should be returned.
Partial address blocks shall be returned in such a way that the
portion retained will comprise a single aggregate block.
5. If the organization does not voluntarily return resources as
requested, ARIN may revoke any resources issued by ARIN as required
to bring the organization into overall compliance. ARIN shall follow
the same guidelines for revocation that are required for voluntary
return in the previous paragraph.
6. Except in cases of fraud, or violations of policy, an organization
shall be given a minimum of six months to effect a return. ARIN
shall negotiate a longer term with the organization if ARIN believes
the organization is working in good faith to substantially restore
compliance and has a valid need for additional time to renumber out
of the affected blocks.
7. In case of a return under paragraphs 12.4 through 12.6, ARIN shall
continue to provide services for the resource(s) while their return
or revocation is pending, except any maintenance fees assessed
during that period shall be calculated as if the return or
revocation was complete.
8. This policy does not create any additional authority for ARIN to
revoke legacy address space. However, the utilization of legacy
resources shall be considered during a review to assess overall
compliance.
9. In considering compliance with policies which allow a timeframe
(such as a requirement to assign some number of prefixes within 5
years), failure to comply cannot be measured until after the
timeframe specified in the applicable policy has elapsed. Blocks
subject to such a policy shall be assumed in compliance with that
policy until such time as the specified time since issuance has elapsed.