Provider Independent Number Resource Assignment Chart

Your IP address could not be determined at this time.

Version 2018.1 - 18 January 2018

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)

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.

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. [Section Number Retired]

2.9. [Section Number Retired]

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

All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization.

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 24-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 allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers.

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 24-month supply of IPv4 addresses.

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

ARIN's minimum assignment for end-user organizations is a /24.

End-user organizations without direct assignments or allocations from ARIN qualify for an initial assignment of ARIN's minimum assignment size.

4.3.3. Utilization rate

Organizations may qualify for a larger initial allocation by providing appropriate details to verify their 24-month growth projection.

The basic criterion that must be met is a 50% utilization rate within 24 months.

A greater utilization rate may be required based on individual network requirements.

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

End-users must have efficiently utilized all assignments, in aggregate, to at least 80% and at least 50% of every assignment in order to receive additional space, and must provide ARIN with utilization details.

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 /15 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4.

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 65534 and 4200000000 through 4294967294 inclusive.

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 re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced, 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 6.5.5.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 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.5.4. Registration Requested by Recipient

If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP shall register that assignment as described in section 6.5.5.1.

6.5.6. [Section Number Retired]
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 having a contiguous network that has a minimum of 13 active sites within 12 months, or;
  6. 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

While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide policy that is more friendly to those environments by allowing them to use end-user criteria.

6.5.9.1. Qualification Criteria

To qualify under this section, a community network must demonstrate to ARIN's satisfaction that it meets the definition of a community network under section 2.11 of the NRPM.

6.5.9.2. Receiving Resources

Once qualified under this section, a community network shall be treated as an end-user assignment for all ARIN purposes.

Community networks shall be eligible under this section only for IPv6 resources and the application process and use of those resources shall be governed by the existing end-user policy contained in section 6.5.8 et. seq.

Community networks seeking other resources shall remain subject to the policies governing those resources independent of their election to use this policy for IPv6 resources.

6.5.9.3. [Section Number Retired]

6.6. - 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. [Section Number Retired]

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, Acquisitions, and Reorganizations

ARIN will consider requests for the transfer of number resources in the
case of mergers, acquisitions, and reorganizations under the following
conditions:

  • 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.
  • The Internet number resources being transferred as part of an 8.2 transfer will not be subject to a needs-based assessment during the process of the 8.2 transfer.

AND one or more of the following:

  • The recipient must provide evidence that they have acquired the assets that use the resources to be transferred from the current registrant.

OR

  • The recipient must show that they have acquired the entire entity which is the current registrant.

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 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.
  • Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.

Conditions on recipient of the transfer:

  • The recipients must meet the transfer requirements as defined in section 8.5.
  • 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 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, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers.
  • Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.

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 must meet the transfer requirements as defined in section 8.5.
  • Recipients within the ARIN region will be subject to current ARIN policies.

8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement

The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.

8.5.2 Operational Use

ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size

ARIN's minimum IPv4 transfer size is a /24.

8.5.4. Initial block

Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARIN's minimum transfer size.

8.5.5. Block size

Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.

8.5.6. Efficient utilization of previous blocks

Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers.

8.5.7. Alternative Additional IPv4 Address Block Criteria

In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.

An organization may qualify via 8.5.7 for a total of a /16 equivalent in any 6 month period.

9. Out of Region Use

ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows:

  • IPv4: At least a /22 used in region
  • IPv6: At least a /44 used in region
  • ASN: At least one ASN present on one or more peering sessions and/or routers within the region.

A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include:

  • Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose.
  • Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is.
  • Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is.
  • Demonstrating that the entity provides services to and solicits sales from residents of the ARIN region.
  • Demonstrating that the entity holds periodic meetings in the ARIN region.
  • Demonstrating that the entity raises investment capital from investors in the ARIN region.
  • Demonstrating that the entity has a registered corporation in the ARIN region, although this factor on its own shall not be sufficient.
  • Other fact based criterion that the entity considers appropriate and submits for ARIN's review.

The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN.

The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to obtain from the applicant a listing of all the applicant's number holdings in the region(s) of proposed use, when there are factual reasons to support the request.

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

APNIC Document identity

Title:APNIC guidelines for IPv6 allocation and assignment requests
Short title:ipv6-guidelines
Document ref:APNIC-114Version:010
Date of original publication:2 July 2004Date of this version:4 November 2013
Review scheduled:n/aObsoletes:apnic-114-v009
Status:ActiveComments:Re-order document, correct error in previous version, and general improvements.

About this document

These guidelines are intended to complement the document IPv6 address allocation and assignment policy. These guidelines will be updated from time to time, in consultation with the
Asia Pacific and global Internet communities, to ensure they remain appropriate to the current addressing environment.

Table of contents

Section 1: Background
1.   Introduction
2.   Scope
3.   Additional guidance
4.   Goals of address space management
5.   Application of guidelines

Section 2: General guidelines
6.   Definitions
6.1.   End Site
6.2.   Multiple Discrete Networks
7.   Sparse Delegation Framework
7.1.    Avoiding Fragmentation
8.   Allocations to LIRs
8.1.   Initial allocation criteria
8.1.1.    A plan for 200 assignments
8.1.2.    Existing LIRs with IPv4 allocations from APNIC or an NIR
8.1.3.   Initial allocations larger than /32
8.1.4.   Expanding allocations received before August 2004
8.1.5.    Supporting documentation
8.2.   Subsequent allocation criteria
8.2.1.    Prior allocations to be used first
8.2.2.   Special circumstances
9.   Portable assignment criteria
9.1.   Initial assignments
9.1.1.  Multihoming assignment
9.1.2.  Internet Exchange assignment
9.1.3.  Critical Infrastructure assignment
9.1.4.  Provider Independent assignment
9.2.   Subsequent assignments
10.   Delegations by LIRs
10.1.   LIR assignments to end sites
10.1.1.   Second opinion request
10.1.2   Supporting documentation
10.2   Sub-allocations by LIRs
11.    Reverse DNS delegation
11.1.   Reverse DNS delegations in ip6.int and ip6.arpa
12.   Registration requirements
12.1.   Updating registration details
12.2.   Registering contact persons

Section 1: Background

1. Introduction

These guidelines are developed within the APNIC community and are consistent with the goals and policies applicable to IPv6 address space management. They are intended to assist organizations requesting IPv6 address space only. Nothing in these guidelines
should be considered to replace or modify any of the specific policies defined in other APNIC documents.

Top

2. Scope

This document applies to the management of global unicast IPv6 public address space in the Asia Pacific region. This document does not apply to IPv4, multicast, or unique local IPv6 unicast addresses, or Autonomous System Numbers. It should be read in
conjunction with other APNIC documents, particularly  Part 3 of APNIC Internet Number Resource Policies.

Top

3. Additional guidance

These guidelines are not intended to be exhaustive. Additional guidance and examples are available from the help information available for each APNIC request form and in FAQs and other information on the APNIC web site:

Top

4. Goals of address space management

In this document, all reference to the goals of address space management refer to the goals described in the IPv6 address allocation and assignment policy, namely:

  • uniqueness;
  • registration;
  • aggregation;
  • conservation;
  • fairness; and
  • minimized overhead.

Top

5. Application of guidelines

This document is primarily intended to guide ISPs when making assignments to their customers or requesting address space from APNIC. The issues discussed in this document reflect many of the considerations used by APNIC in evaluating requests for initial
allocations and subsequent allocations. It is intended that NIRs will either adopt these, or similar, guidelines for their own members.

Section 2: General guidelines

6. Definitions

6.1. End Site

Section 2.9 of “APNIC Internet Number Resource Policies” defines an end site as “an end user (subscriber) who has a business relationship with a service provider”. That section also lists some
possible business relationships (which would normally be found in the contract between the LIR and their customer) that typically indicate end sites. End sites do not re-assign any of their IP addresses to other organizations. Examples:

Single end site
  • A home or corporate user who has a single contract with a service provider for their own device or network.
  • A home or corporate user who has multiple devices to connect the Internet, but has only one contract with a service provider.
Multiple sites
  • A home or corporate user who has multiple contracts with one or more service providers.
  • A home or corporate user who has multiple separate networks that are not connected to each other because each network has a different management policy, even if they are in the same place (for example, a merged company with independent
    networks).

6.2. Multiple Discrete Networks

Where an organization demonstrates a compelling need, or requirement, to build discrete networks due to regulatory, geographic, or operational reasons and these networks are advertised either internally, or externally, the network may be defined
by APNIC as being composed of discrete networks.

Top

7. Sparse Delegation Framework

APNIC delegates blocks of IPv6 address space to resource holders according to a “sparse delegation” algorithm. This delegation process is designed to maximize the growth potential for each delegation by maximizing the distance between them. The following
illustration shows the order in which a sequence of 16 delegations would be made in an available free pool using APNIC’s sparse delegation algorithm.  

Sparse Delegation Sequence

|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| 1 | | | | | | | 2 | | | | | | | | | | 3 | | | | | | 4 | | | | 5 | | 6 | | 7 | | 8 | 9 10 11 12 13 14 15 16

 

  The sparse delegation algorithm used, selects the starting address for each new delegation by calculating the mid-point between the next two start addresses that are furthest apart in the free pool. The algorithm works from the beginning address
of the free pool to the end address before returning to the first available slot at the beginning of the pool. The effect is to successively sub-divide each remaining free block in two, the addresses after that point being used for the new delegation
and the preceding addresses being left available for subsequent delegation. In accordance with Section 5.1.2. of APNIC Internet Number Resource Policies, where possible,
subsequent delegations to the same resource holder are made from an adjacent address block by growing the delegation into the free space remaining, unless disaggregated ranges are requested for multiple discrete networks.  

7.1. Avoiding Fragmentation

While the free space between sparse delegations is initially very large, the size of available blocks reduces as more sub-divisions occur. To minimize this effect, APNIC manages its central pool by making similar sized delegations from a number of
sub-pools, with large delegations made from one pool, small delegations made from another, and so on. In this way, the high frequency of smaller delegations will not cause sub-divisions of free space available to large address block holders, as they
are taken from different sub-pools. For more information about the resource ranges managed by APNIC see:

http://www.apnic.net/resources

Top

8. Allocations to LIRs

APNIC will allocate IPv6 address space to a network with global or local connectivity, provided the network meets the criteria stated in APNIC Internet Number Resource Policies.

The following networks are examples of the types of organizations that most commonly apply for an IPv6 allocation from APNIC.

This list is not intended to be exhaustive:
  • An organization providing IPv6 connectivity to the global Internet
  • An organization providing IPv6 connectivity to end sites.
  • An organization providing IPv6 access to shared facilities, storage, computing, or other services.
  • A large organization providing IPv6 connectivity to its own group or subsidiaries.

8.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an organization must meet the criteria stated in section 9.2. of APNIC Internet Number Resource Policies. Under 4) in section 9.2.2,
an organization can choose from one of the two alternative criteria:

  1. Have a plan for making at least 200 assignments to other organizations within two years, OR
  2. Be an existing LIR with IPv4 allocations from APNIC, or from an NIR, which will make IPv6 assignments or sub-allocations to other organizations and announce the allocations in the inter-domain routing system within two years

These two alternative criteria are explained in sections 8.1.1. and 8.1.2. below.

8.1.1. A plan for 200 assignments

An organization must provide a plan to make at least 200 assignments within two years. However, APNIC regards the existence of the plan as a demonstration of the LIR’s readiness to commence IPv6 services and does not assess the feasibility of
the plan.

For example:An LIR with at least 200 customers currently using IPv4 address space can meet the initial allocation criteria of 200 assignments if it plans to provide them with IPv6 connectivity service within two years.

IPv4 sub-allocations made by an LIR to downstream ISPs can be used to justify the corresponding amount of /56 assignments.  

For example:If a CATV provider has 4,000 IP static connection customers in IPv4 and 5% of the customers (200 customers) are expected to subscribe to IPv6 services, then this provider will meet the initial allocation criteria of 200 assignments.
(A /56 can be assigned to end sites using either static or dynamic addressing).

If an LIR assigns a single static IP address in IPv4, the ISP can assign up to a /48 in IPv6. The LIR may also assign a smaller prefix in accordance with recommendations in RFC 6177.

8.1.2. LIRs with existing IPv4 allocations from APNIC or an NIR

To qualify under this criterion, an organization must:

  • Document an existing IPv4 allocation made to it by APNIC, or an NIR
  • Commit to making IPv6 assignments and/or sub-allocations
  • Agree to announce the IPv6 allocation in the routing table within two years

Note:Historical IP ranges do not meet the criteria of being “an existing IPv4 allocation from APNIC, or an NIR”. Historical IP ranges are defined in Section 2.5.2 of APNIC Internet Number Resource Policies.

8.1.3. Initial allocations larger than /32

LIRs can use existing IPv4 customers and IPv4 network infrastructure to justify an initial allocation larger than a /32 by providing documentation on the number of their existing IPv4 users as well as the extent of their IPv4 network infrastructure.
The HD ratio is used to determine the appropriate size of the IPv6 allocation based on IPv4 customer and infrastructure assignments. For more information, refer to Section 9.1 of the APNIC Internet Number Resource Policies.
LIRs are likely to be eligible for an initial allocation if they meet both of the following conditions:

  • They have received an IPv4 allocation as an LIR, or meet the criteria to receive an IPv4 allocation; and
  • They plan to transfer the existing IPv4 infrastructure or customers partly, or wholly, to IPv6 in two years.

LIRs are still requested to provide information on how many /56s they expect to assign within the first two years.

8.1.4. Expanding allocations received before August 2004

Organizations that received an initial allocation of IPv6 can take advantage of the August 2004 policy permitting initial allocations larger than /32. To expand the initial allocation size without needing to meet subsequent allocation criteria,
the LIR must have received its initial allocation before 16 August 2004 and must meet the initial allocation criteria described in Section 9.2 of the “APNIC Internet Number Resource Policies“.
For more information, see: prop-021: Expansion of the initial allocation space for existing IPv6 address space holders.

8.1.5. Supporting documentation

The APNIC IPv6 Allocation Request Form gives LIRs the opportunity to include additional documentation to support the request for an initial IPv6 allocation.

Examples of the types of information an LIR can include in the “Additional information” section of the form to support the request are:
  • network diagrams
  • approximate deployment dates
  • a brief description of IPv6 deployment method (use of IPv6 tunneling, dual stack, etc.)
  • service plans (web hosting, access service, etc.)
  • network equipment information to demonstrate that the LIR has a plan to implement IPv6-ready infrastructure; and
  • IPv4 infrastructure and/or customer information if the LIR chooses the option of using existing IPv4 infrastructure to justify the request (see Section 8.1.2.).

  When requesting an initial allocation from APNIC, network equipment information such as the vendor and model name of an LIR’s equipment, is not mandatory; however, if an LIR requests a large pool of address space for CATV or ADSL operations, APNIC
may ask for information on the network’s equipment.

8.2. Subsequent allocation criteria

8.2.1. Prior allocations to be used first

An LIR is not eligible to receive subsequent allocations until its current assignments reach a HD ratio of 0.94 based on /56 assignments.

8.2.2. Special circumstances

An LIR may request an exception to the HD 0.94 rule when:

  • It has a demonstrated need for an assignment that is larger than the amount of remaining space,
  • It is announcing its existing IPv6 allocation and can demonstrate a need or requirement to build discrete networks,
  • It requires the additional allocation for technical reasons such as for IPv4 to IPv6 transitional technologies, or
  • It can demonstrate other reasons accepted by APNIC as valid circumstance, or in accord with applicable policies.

Top

9. Portable assignment criteria

Organizations with a previously delegated IPv4 assignment from APNIC are eligible for an appropriately sized IPv6 block under Section 9.2.1 of the “APNIC Internet Number Resource Policies“. Organizations
are also able to demonstrate a need for direct assignment of IPv6 address blocks under the following conditions.

  • Multihoming assignment
  • Internet Exchange assignment
  • Critical Infrastructure assignment
  • Provider Independent assignment

 

9.1. Initial assignments

APNIC will allocate a minimum of a /48 to organizations that meet the following criteria.

9.1.1.  Multihoming assignment
  1. To be eligible for an IPv6 assignment under this policy, an organization needs to be, or plan to be, receiving fulltime connectivity from more than one ISP, and
  2. have one or more of its routing prefixes announced by at least two ISPs.
9.1.2  Internet Exchange assignment
  1. An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 network structure that interconnects three or more Autonomous Systems (AS) for the purpose of Internet traffic interchange.
  2. Addresses delegated under this policy must be used exclusively to connect participant devices to the Exchange Point.
9.1.3.  Critical Infrastructure assignment
  1. Critical infrastructure assignments are available only to the actual operators of network infrastructure that perform the functions described in the policy.
  2. Examples of Critical Infrastructure networks are listed at 5.9.3 of the IPv6 address allocation and assignment policy.
  3. The maximum assignment made under these terms is /32 per operator.
9.1.4  Provider Independent assignment

Direct assignment of IPv6 addresses is possible where an organization can demonstrate other reasons accepted by APNIC as valid circumstance, or in accord with applicable policies. For example, organizations that can demonstrate;

  1. the network is statically addressed and of a size or complexity that make renumbering operationally impractical, together with evidence that dynamic or multiple addressing options are either not available from the relevant ISP or are unsuitable;
    or
  2. that any future renumbering of the relevant network could potentially interfere with services of a critical medical or civic nature, or
  3. other reasons accepted by APNIC as valid circumstance, or in accord with applicable policies.

Note:A larger address block may be assigned according to demonstrated need. Only one IPv6 address block is to be assigned to an organization upon an initial request; subnets of this block may be assigned by the organization to its different sites if needed.  

9.2. Subsequent assignments

Eligibility for subsequent Provider Independent assignments under Section 10.1.4.2 of the “APNIC Internet Number Resource Policies” is subject to the following conditions:

  • An address block larger than /48 may be assigned if;
    1. the network address plan demonstrates that the need is above a /48 0.94 HD-ratio, or
    2. the network plan is for multiple discrete networks. That is, the organization can demonstrate a need or requirement to build discrete networks, and
    3. the organization can demonstrate its use of the previous assignment generated the minimum possible number of global routing announcements and the maximum aggregation of that block, and
    4. how the subsequent assignment would be managed to minimize the growth of the global IPv6 routing table.

 

Top

10. Delegations by LIRs

10.1. LIR assignments to end sites

An LIR can assign a /64 to /48 to an end site customer network based on their requirements. The following guidelines may be useful:

  • /64 where it is known that only one subnet is required.
  • /56 for small sites where it is expected only a few subnets will be required within the next two years. Subscribers can receive a /56 when connecting through on-demand or always-on connections such as small office and home office enterprises.
  • /48 for larger sites, or if an end site is expected to grow into a large network.

An LIR must submit a second opinion request to APNIC if it plans to assign more than a /48 to a single end site (see Section 10.1.2 below).

10.1.1. Second opinion request

Currently, the global Internet community considers a /48 assignment to be sufficient address space for an end site. Therefore, when an end site requires an assignment larger than /48, or it requires additional /48 assignments after the initial
assignment, the LIR must first submit a second opinion request.

10.1.2. Supporting documentation

The APNIC Second Opinion Request Form gives LIRs the opportunity to include additional documentation to support the request for an assignment to an end site that is larger than a /48. Examples of the types of information an LIR can include in
the Additional information section of the form to support the request are:

  • Network diagram of an end site
  • Network equipment information
  • Full details to justify multiple /48 assignments to an end site (for example, the number of clients (PCs or other network equipment), or other information which justify multiple /48 assignments)

 

10.2. Sub-allocations by LIRs

LIRs do not need to submit a second opinion request before making sub-allocations to downstream ISPs (please see Section 8.2 above). However, APNIC encourages LIRs to contact APNIC hostmasters for advice if LIRs are unsure how much address space
to sub-allocate.

Top

11. Reverse DNS delegation

LIRs should maintain reverse DNS delegations for their customers’ networks. If a network is not specifically associated with an LIR then the reverse DNS delegation should be maintained by APNIC. In both IPv4 and IPv6 networks, it is the LIR’s responsibility
to delegate or to maintain PTR records for its customers’ networks. The size of a reverse DNS delegation by an LIR to an end site will usually be a /48, which is the recommended minimum assignment to an end site specified in RFC 6177. However, it is possible
to delegate a prefix longer than /48. Some organizations may delegate such a prefix in their internal network.  

11.1. Reverse DNS delegations in ip6.int and ip6.arpa

As specified in RFC 3596, reverse DNS delegations in the ip6.int tree have been deprecated, and APNIC has now removed all ip6.int reverse delegations from the APNIC Whois Database. For more information, see: Reverse DNS delegations resource guide

http://www.apnic.net/dns

Top

12. Registration requirements

LIRs are responsible for promptly and accurately registering their allocations, sub-allocations, and assignments in the APNIC Whois Database, as follows:

  • All allocations and sub-allocations must be registered.
  • Assignments for networks equal to or larger than /48 must be registered.
  • Registration of assignments smaller than /48 is optional and may be registered at the discretion of the LIR and the network administrator.

When an LIR makes a sub-allocation to a downstream ISP, the LIR is responsible for ensuring that assignments from the sub-allocated range are registered in the database; however, the LIR may delegate the responsibility to the downstream ISP. If an LIR
registers an assignment smaller than a /48, it will be counted as a utilized /48 when assessing existing address utilization for future IPv6 allocation requests.

Note:Privacy of customer assignments (prop-007-v001) was implemented in 2004. APNIC policy no longer requires the registration of assignments and sub-allocations to be publicly available. The registration of customer assignments is still required, but will be ‘hidden’ by default.

12.1. Updating registration details

LIRs must update the APNIC Whois Database when any of the registration information changes. This is the responsibility of the LIR concerned, but may be formally delegated to the end user as a condition of the original assignment.

12.2. Registering contact persons

Administrative and technical contact persons must be registered. In addition, it is mandatory to register an Incident Report Team (IRT) object for each allocation and assignment record in the APNIC Whois Database. The registered administrative contact
(admin-c) must be someone who is physically located at the site of the network, subject to the following exceptions:

  • For residential networks or users, the network’s technical contact may be registered as admin-c.
  • For networks in exceptional circumstances that make it impractical to maintain an on-site administrative contact, an off-site person may be registered as the admin-c.
  • The technical contact (tech-c) need not be physically located at the site of the network, but must be a person who is responsible for the day-to-day operation of the network.

Top

0 Thoughts to “Provider Independent Number Resource Assignment Chart

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *