ARIN Number Resource Policy Manual
Version 2008.2 - 27 March 2008
| View change log | PDF version |
Abstract
This is ARIN's Number Resource Policy Manual (NRPM). It is available at: http://www.arin.net/policy/. This version supersedes all previous versions.
Contents
1. Introduction
2. Definitions
2.1. Internet Registry (IR)
2.2. Regional Internet Registry (RIR)
2.3. National Internet Registry (NIR)
2.4. Local Internet Registry (LIR)
2.5. Allocate and Assign
2.6. End-user
2.7. Multihomed
3.1. Bulk Copies of ARIN's WHOIS
3.2. Distributed Information Server Use Requirements
3.3. Privatizing POC Information
3.4. Routing Registry3.5 Autonomous System Originations
3.5.1 Collection
3.5.2 Publication3.5.2.1 Description of data
3.5.2.2 Bulk publication of data
3.5.2.3 Other formats
4.1.1. Routability
4.1.2. Validity
4.1.3. Invalidation
4.1.4. Recall
4.1.5. Determination of IP address allocation size
4.1.6. CIDR bit boundaries
4.1.7. RFC 20504.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 need4.2.2. Initial allocation to ISPs
4.2.2.1. Standard or non-multihomed
4.2.2.1.1. Use of /20
4.2.2.1.2. Efficient utilization
4.2.2.1.3. Three months
4.2.2.1.4. Renumber and return4.2.2.2.1. Efficient utilization
4.2.2.2.2. Three months
4.2.2.2.3. Renumber and return
4.2.2.2.4. Additional requests following the initial allocation4.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 adherence4.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 requests4.2.3.6. Reassignments to multihomed downstream customers
4.2.3.7. Reassignment information
4.2.3.7.1. Customer organization information
4.2.3.7.2. /29s and larger nets
4.2.3.7.3. Submit within 7 days
4.2.3.7.4. Visible via WHOIS
4.2.3.7.5. Accounting for additional utilization
4.2.3.7.6. Residential Customer Privacy4.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. Three months
4.2.4.4. Twelve months4.3. End-users - Assignments to end-users
4.3.1. End-user
4.3.2. Minimum Assignment4.3.3. Utilization Rate
4.3.4. Additional considerations
4.3.5. Non-connected Networks
4.3.6 Additional Assignments4.4. Micro-allocation
4.5. Multiple Discrete Networks
4.6. Amnesty Requests
4.7. Aggregation Requests
4.8. [section number retired]
6.2.1. Internet Registry (IR)
6.2.2. Regional Internet Registry (RIR)
6.2.3. National Internet Registry (NIR)
6.2.4. Local Internet Registry (LIR)
6.2.5. Allocate
6.2.6. Assign
6.2.7. Utilization
6.2.8. HD-Ratio
6.2.9. End site6.3. Goals of IPv6 address space management
6.3.1. Goals
6.3.2. Uniqueness
6.3.3. Registration
6.3.4. Aggregation
6.3.5. Conservation
6.3.6. Fairness
6.3.7. Minimized overhead
6.3.8. Conflict of goals6.4.1. Address Space not to be considered to be property
6.4.2. Routability not guaranteed
6.4.3. Minimum allocation
6.4.4. Consideration of IPv4 Infrastructure6.5. Policies for allocations and assignments
6.5.1.1. Initial allocation criteria
6.5.1.2. Initial allocation size6.5.2.1. Subsequent allocation criteria
6.5.2.2. Applied HD-Ratio
6.5.2.3. Subsequent Allocation Size6.5.3. [section number retired]
6.5.4. Assignments from LIRs/ISPs
6.5.4.1. Assignment address space size
6.5.4.2. Assignment of multiple /48s to single end site
6.5.4.3. Assignment to operator's infrastructure
6.5.4.4. Registration of Assignments6.5.5. Registration (reassignment information)
6.5.7. Existing IPv6 address space holders
6.5.8 Direct assignments from ARIN to end user organizations
6.5.8.1 Criteria
6.5.8.2 Initial assignment size
6.5.8.3 Subsequent assignment size6.6. References
6.7. Appendix A - HD-Ratio
6.8. Appendix B - Background information6.8.1. Background
6.8.2. Why a joint policy
6.8.3. The size of IPv6's address space
6.8.4. Acknowledgment6.9. IPv6 Reassignments policy
6.10. Micro-allocations6.10.1 Micro-allocations for Critical Infrastructure
6.10.2 Micro-allocations for Internal Infrastructure
7.1. Maintaining IN-ADDRs
7.2. Lame Delegations in IN-ADDR.ARPA
8.1. Transfers
8.2. Transfer Requirements
8.3. Documentation Requirements
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
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 Size
11.8 Commercial Use Prohibited
11.9 Resource Request Appeal or Arbitration
1. Introduction
Addressing policies in the ARIN region are created in accordance with the "Internet Resource Policy Evaluation Process" (http://www.arin.net/policy/irpep.html). The status of current and historical policy proposals can be found on the "Policy Proposal Archive" page (http://www.arin.net/policy/proposals/proposal_archive.html).
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.
2. Definitions
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. National Internet Registry (NIR)
A National Internet Registry (NIR) primarily allocates address space to its members or constituents, which are generally LIRs organized at a national level. NIRs exist mostly in the Asia Pacific region.
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 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.
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:
http://www.arin.net/registration/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 CollectionARIN 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.
4. IPv4
4.1. General Principles
4.1.1. Routability
Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. Therefore, ISPs should consider the following order of priority when requesting IP address space:
- Request IP address space from upstream provider
- Request IP address space from provider's provider
- Request IP address space from ARIN (not guaranteed to be globally routable)
4.1.2. Validity
IP address allocations are valid as long as the utilization and other relevant criteria continue to be met, and the yearly fee is submitted.
4.1.3. Invalidation
ARIN may invalidate any IP allocation if it determines that the requirement for the address space no longer exists.
4.1.4. Recall
In the event of address space recall, ARIN will make every reasonable effort to inform the organization that the addresses are being returned to the free pool of IPv4 address space.
4.1.5. Determination of IP address allocation size
Determination of IP address allocation size is the responsibility of ARIN.
4.1.6. CIDR bit boundaries
In an effort to ensure that Classless Inter-Domain Routing (CIDR) is implemented and utilized as efficiently as possible, ARIN issues blocks of addresses on appropriate "CIDR-supported" bit boundaries.
4.1.7. RFC 2050
ARIN takes guidance from allocation and assignment policies and procedures set forth in RFC 2050. These guidelines were developed to meet the needs of the larger Internet community in conserving scarce IPv4 address space and allowing continued use of existing Internet routing technologies.
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 Internet Service Providers (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 IP address prefixes no longer than /20 to ISPs. If allocations smaller than /20 are needed, ISPs should request address space from their upstream provider. For multihomed ISPs, ARIN allocates IP address prefixes no longer than /22. If allocations smaller than /22 are needed, multihomed 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. Standard or non-multihomed
Organizations that do not meet the requirements described in the multihomed section below (Section 4.2.2.2) must satisfy the following requirements:
4.2.2.1.1. Use of /20
The efficient utilization of an entire previously allocated /20 from their upstream ISP. This /20 allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 16 /24s. For example, if an organization holds a smaller allocation, such as 12 /24s, from its upstream provider, the organization would not meet the minimum utilization requirements of a /20.
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 using the table format described in Section 4.2.3.7.5.
4.2.2.1.3. Three months
Provide detailed information showing specifically how a /20 will be utilized within three months.
4.2.2.1.4. Renumber and return
ISPs receiving a new /20 may wish to renumber out of their previously allocated space. In this case, an ISP must use the new /20 to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
4.2.2.2. Multihomed
When prefixes are allocated which are longer than /20, they will be from a block reserved for that purpose. In order to receive an initial allocation from ARIN, organizations applying under the multihomed policy must:
- When requesting a /22, demonstrate the efficient utilization of a minimum contiguous or noncontiguous /23 (two /24s) from an upstream.
- When requesting a /21, demonstrate the efficient utilization of a minimum contiguous or noncontiguous /22 (four /24s) from an upstream.
- When requesting a /20, demonstrate the efficient utilization of a minimum contiguous or noncontiguous /21 (eight /24s) from an upstream.
4.2.2.2.1. Efficient utilization
Provide reassignment information for /29 and shorter prefix lengths using the Shared WHOIS Project (SWIP) or by providing the same information fields in an RWHOIS server. If additional address space is later requested, this information must be available at the time of the request. Utilization for blocks smaller than /29 can be documented using the format described in Section 4.2.3.7.5.
4.2.2.2.2. Three months
Provide information showing that the requested IP address space will be utilized within three months and demonstrating an intent to announce the requested space in a multihomed fashion.
4.2.2.2.3. Renumber and return
Agree that the newly requested IP address space will be used to renumber out of the current addresses which will be returned to their upstream provider(s).
4.2.2.2.4. Additional requests following the initial allocation
To receive additional address space following the initial allocation, multihomed organizations must have returned the original IP address space to its provider in its entirety and must provide justification for a new allocation as described above in the section titled Requirements for Requesting Initial Address Space.
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. In extreme cases, existing allocations may be affected.
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 prefix lengths longer 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 greater 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 greater 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. Reassignment information
4.2.3.7.1. Customer organization information
ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. SWIP and RWHOIS reassignments should show each client's organizational information.
4.2.3.7.2. /29s and larger nets
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 using the format described in Section 4.2.3.7.5.
4.2.3.7.3. Submit within 7 days
Any time an ISP receives a new block of address space, reassignment information should be submitted within 7 days of issuance of the new space. This information is used to demonstrate that the address space received is being efficiently utilized. Also, it will be reviewed to determine an ISP's and its downstream customers' utilization effectiveness if and when additional space is requested in the future.
4.2.3.7.4. Visible via WHOIS
This information must be visible via WHOIS prior to submitting a request for a new allocation. For further information on reassigning IP address space, please see RFC 2050.
4.2.3.7.5. Accounting for additional utilization
The following format should be used to provide the required information for utilization of blocks smaller than /29 and for describing internal networks:
City Which IP Addresses Assigned No. of Ports No. of Dial-up Clients City Which IP Addresses Assigned No. of Internal Machines Purpose Which IP Addresses Assigned List URLs for Websites 4.2.3.7.6. Residential Customer Privacy
To maintain the privacy of their residential customers, an organization with downstream residential customers 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.
4.2.4. ISP Additional Requests
ISPs requesting additional address space from ARIN beyond their initial allocation should follow the guidelines described in the ARIN ISP Guidelines for Requesting Additional IP Address Space.
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. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. 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. Three months
Provide detailed information showing specifically that the address space will be utilized within three months. Determination of the appropriate allocation to be issued is based on efficient utilization of space within this three-month time frame.
4.2.4.4. Twelve months
After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses.
4.2.5. Web Hosting Policy
When an ISP submits a request for IP address space to be used for IP-based web hosting, it will supply (for informational purposes only) its technical justification for this practice. ARIN will analyze this data continuously, evaluating the need for future policy change.
4.2.6. Cable Address Space Policy
- In most cases, ISPs that have residential cable subscribers assign address space to their cable 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 the SWIP template (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, cable 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 template or use of an RWHOIS server. Requesters will also be asked to provide detailed plans for use of the newly requested space.
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 /20. If assignments smaller than /20 are needed, end-users should contact their upstream provider.
4.3.2.2 Multihomed Connection
For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /22. If assignments smaller than a /22 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose.
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
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 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 longer 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.
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:
- The organization shall be a single entity and not a consortium of smaller independent entities.
- 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.
- The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.
- 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.
- The organization may not allocate additional address space to a location until each of that location's address blocks are 80% utilized.
- The organization should notify ARIN at the time of the request their desire to apply this policy to their account.
4.6. Amnesty Requests
If an organization, whether a member or non-member, ISP or end-user, relinquishes a larger block of portable address space to ARIN, they may be allowed to receive a smaller block, /24 or shorter, in exchange. The organization will not be required to justify their use of the new, smaller block. The organization must return the block to be exchanged within 12 months. ARIN shall, at their discretion, determine whether the smaller replacement block shall be a subnet of the returned block, or a block allocated from some different range. If any of the relinquished blocks had associated maintenance fees, then the new block will be subject to the appropriate fees for that block size. Likewise those without maintenance fees shall remain so.
4.7. Aggregation Requests
If an organization, whether a member or non-member, ISP or end-user, relinquishes a group of portable, non-aggregatable address blocks to ARIN, they shall be allowed to receive a block in exchange, /24 or shorter, but no more than the shortest block that could contain all of the returned blocks. Exchanged space shall be returned within 12 months. If the gain in the number of addresses is greater than 4096, the aggregation request must be evaluated by the ARIN in accordance with the current IPv4 allocation policy. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, the replacement space shall be as well, but if any one of the returned blocks had associated maintenance fees, then the replacement block shall also be subject to maintenance fees.
4.8. [section number retired]
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:
- A unique routing policy (its policy differs from its border gateway peers)
- 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. Details regarding requirements, fees, and applying for an AS Number can be found on the Guidelines for AS Numbers page.
5.1 16-bit and 32-bit AS Numbers
- Commencing 1 January 2007, ARIN will process applications that specifically request 32-bit only AS Numbers and assign such AS numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, a 16-bit only AS Number will be assigned.
- Commencing 1 January 2009, ARIN will process applications that specifically request 16-bit only AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit only AS Number, a 32-bit only AS Number will be assigned.
- Commencing 1 January 2010, ARIN will cease to make any distinction between 16-bit only AS Numbers and 32-bit only AS Numbers, and will operate AS number assignments from an undifferentiated 32-bit AS Number pool.
Terminology
"16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535
"32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - 4,294,967,295
"32-bit AS Numbers" refers to AS Numbers in the range 0 - 4,294,967,295
ExpirationSection 5.1 will be removed from the first version of this manual published after 1 January 2010.
6. IPv6
[Editor's note: The IPv6 assignment and allocation policy document was adopted by the ARIN Board of Trustees on July 9, 2002. As part of the ARIN policy cataloging project of 2004, the IPv6 policy document was inserted into the ARIN Number Resource Policy Manual; the fact that it was once a stand alone document explains why the phrase "this document" occurs in this section.]
Status of this Memo
This document was developed through joint discussions among the APNIC, ARIN, and RIPE communities.
Abstract
This document defines registry policies for the assignment and allocation of globally-unique IPv6 addresses to ISPs and other organizations. This document obsoletes the "Provisional IPv6 assignment and allocation policy document."
This document was developed jointly by the communities of APNIC, ARIN, and RIPE.
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 (RIRv6-Policies). 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.
(RFC2373, RFC2373bis) designate 2000::/3 to be global unicast address space that IANA may allocate to the RIRs. In accordance with (RFC2928, RFC2373bis, IAB-Request), IANA has allocated initial ranges of global unicast IPv6 address space from the 2001::/16 address block to the existing RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies.
6.2. Definitions
The following terms and their definitions are of particular importance to the understanding of the goals, environment, and policies described in this document.
Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below.
6.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. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.
6.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.
6.2.3. National Internet Registry (NIR)
A National Internet Registry (NIR) primarily allocates address space to its members or constituents, which are generally LIRs organized at a national level. NIRs exist mostly in the Asia Pacific region.
6.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 ISPs, whose customers are primarily end users and possibly other ISPs.
6.2.5. Allocate
To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them.
6.2.6. 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.
6.2.7. Utilization
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.
Throughout this document, the term utilization refers to the allocation of /56s to end sites, and not the number of addresses assigned within individual /56s within those end sites.
6.2.8. 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 (RFC1715) and is expressed as follows:
HD = Log (number of allocated objects) 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.
6.2.9. End site
An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves:
- that service provider assigning address space to the end user
- that service provider providing transit service for the end user to other sites
- that service provider carrying the end user's traffic.
- that service provider advertising an aggregate prefix route that contains the end user's assignment
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 licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license.
RIRs will generally renew licenses automatically, provided requesting organizations are making a good-faith effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organization is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license.
Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment.
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. Minimum Allocation
RIRs will apply a minimum size for IPv6 allocations, to facilitate prefix-based filtering.
The minimum allocation size for IPv6 address space is /32.
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. Initial allocation
6.5.1.1. Initial allocation criteria
To qualify for an initial allocation of IPv6 address space, an organization must:
- be an LIR;
- not be an end site;
- plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; and
- be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years.
6.5.1.2. Initial allocation size
Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32.
Organizations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure.
6.5.2. Subsequent allocation
Organizations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.
6.5.2.1. Subsequent allocation criteria
Subsequent allocation will be provided when an organization (ISP/LIR) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments. The HD-Ratio (RFC 3194) is used to determine the utilization thresholds that justify the allocation of additional address as described below.
6.5.2.2. Applied HD-Ratio
The HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilization for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilization value for a given address block size.
6.5.2.3. Subsequent Allocation Size
When an organization has achieved an acceptable utilization for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.
If an organization needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.
6.5.3. [section number retired]
6.5.4. Assignments from LIRs/ISPs
LIRs must make IPv6 assignments in accordance with the following provisions.
6.5.4.1. Assignment address space size
End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified.
The following guidelines may be useful (but they are only guidelines):
- /64 when it is known that one and only one subnet is needed
- /56 for small sites, those expected to need only a few subnets over the next 5 years.
- /48 for larger sites
For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation.
RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document.
6.5.4.2. Assignment of multiple /48s to a single end site
When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level.
Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.
6.5.4.3. Assignment to operator's infrastructure
An organization (ISP/LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.
6.5.4.4. Registration of Assignments
All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.
6.5.5. Registration
When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an RIR/NIR database.
RIR/NIRs will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time.
IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.
6.5.5.1. Residential Customer Privacy (2003-3)
To maintain the privacy of their residential customers, an organization with downstream residential customers 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/NIR 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
Organizations that received /35 IPv6 allocations under the previous IPv6 address policy (RIRv6-Policies) are immediately entitled to have their allocation expanded to a /32 address block, without providing justification, so long as they satisfy the criteria in Section 6.5.1.1. The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organization. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document.
6.5.8. Direct assignments from ARIN to end-user organizations
6.5.8.1. Criteria
To qualify for a direct assignment, an organization must:
- not be an IPv6 LIR; and
- qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect.
6.5.8.2. Initial assignment size
Organizations that meet the direct assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. An HD-Ratio of .94 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.8.3. Subsequent assignment size
Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on the .94 HD-Ratio metric. When possible, assignments will be made from an adjacent address block.
6.6. References
(RFC1715) "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, RFC 1715.
(IAB-Request) "E-mail from IAB to IANA", http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt.
(RFC2373) "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. July 1998, RFC 2373.
(RFC2373bis) http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt.
(RFC2928) "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000, RFC 2928.
(RFC3177) "IAB/IESG Recommendations on IPv6 Address". IAB, IESG. September 2001, RFC 3177.
(RFC3194) "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, RFC 3194.
(RIRs-on-48) http://www.arin.net/policy/archive/ipv6reassign.html,
(RIRv6-Policies)
http://www.afrinic.net/policy.htm
http://www.arin.net/policy/nrpm.html#ipv6
http://lacnic.net/en/politicas/index.html
http://www.ripe.net/ripe/docs/ipv6policy.html
http://www.apnic.net/docs/policy/ipv6-address-policy.html6.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. Appendix B: Background information
6.8.1. Background
The impetus for revising the 1999 Provisional IPv6 policy started with the APNIC meeting held in Taiwan in August 2001. Follow-on discussions were held at the October, 2001 RIPE and ARIN meetings. During these meetings, the participants recognized an urgent need for more detailed, complete policies. One result of the meetings was the establishment of a single mailing list to discuss a revised policy together with a desire to develop a general policy that all RIRs could use. This document does not provide details of individual discussions that lead to policies described in this document; detailed information can be found in the individual meeting minutes at the www.apnic.net, www.arin.net, and www.ripe.net web sites.
6.8.2. Why a joint policy
IPv6 addresses are a public resource that must be managed with consideration to the long-term interests of the internet community. Although regional registries adopt allocation policies according to their own internal processes, address policies should largely be uniform across registries. Having significantly varying policies in different regions is undesirable because it can lead to situations where "registry shopping" can occur as requesting organizations request addresses from the registry that has the most favorable policy for their particular desires. This can lead to the policies in one region undermining the efforts of registries in other regions with regards to prudent stewardship of the address space. In cases where regional variations from the policy are deemed necessary, the preferred approach is to raise the issue in the other regional registries in order to develop a consensus approach that all registries can support.
6.8.3. The size of IPv6's address space
Compared to IPv4, IPv6 has a seemingly endless amount of address space. While superficially true, short-sighted and wasteful allocation policies could also result in the adoption of practices that lead to premature exhaustion of the address space.
It should be noted that the 128-bit address space is divided into three logical parts, with the usage of each component managed differently. The rightmost 64 bits, the Interface Identifier (RFC2373), will often be a globally-unique IEEE identifier (e.g., mac address). Although an "inefficient" way to use the Interface Identifier field from the perspective of maximizing the number of addressable nodes, the numbering scheme was explicitly chosen to simplify Stateless Address Autoconfiguration (RFC2462). The middle bits of an address indicate the subnet ID.
6.8.4. Acknowledgment
The initial version of this document was produced by The JPNIC IPv6 policy drafting team consisting of Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this team, who worked over a holiday in order to produce an initial document quickly.
An editing team was then organized by representatives from each of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of RIPE NCC's IPv6 WG).
The editing team would like to acknowledge the contributions to this document of Takashi Arano, John Crain, Steve Deering, Gert Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Wittbrodt and Wilfried Woeber.
The final editing of this document was done by Thomas Narten.
6.9. IPv6 Reassignments policy
The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR.
ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency.
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 longer 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.
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 which start or end with a CIDR prefix longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP (Reallocate and Reassign) templates or the Netmod template for /24 and shorter prefixes.
7.2. Lame Delegations in IN-ADDR.ARPA
ARIN will actively identify lame DNS name server(s) for reverse address delegations associated with address blocks allocated, assigned or administered by ARIN. Upon identification of a lame delegation, ARIN shall attempt to contact the POC for that resource and resolve the issue. If, following due diligence, ARIN is unable to resolve the lame delegation, ARIN will update the WHOIS database records resulting in the removal of lame servers.
8. Transfers
8.1. Transfers
Number resources are non-transferable 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. Transfer Requirements
ARIN will consider requests for the transfer of number resources only upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to:
- Existing customer base
- Qualified hardware inventory
- Specific software requirements.
8.3. Documentation Requirements
In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate:
- An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree
- A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource
- A list of the requesting party's customers using the number resource.
If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable:
- A general listing of the assets or components acquired
- A specific description of acquisitions, including:
- Type and quantity of equipment
- Customer base
- A description of how number resources are being utilized
- Network engineering plans, including:
- Host counts
- Subnet masking
- Network diagrams
- Reassignments to customers
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.
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 on a lease/license basis 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 Size
The Numbering Resources requested come from the global Internet Resource space, and are not from private or other non- routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
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.
Appendix A - Change Log
The Change Log can be found at: