RIR Comparative Policy Overview (version 2011-01)
(version 2011-01)
The goal of this document is to provide a comparative overview of policies across the Regional Internet Registry (RIR) system. It is not a policy statement by the RIRs, but serves as a reference for the Internet community. While this document was accurate on the date of publication (30 March 2011) it may be outdated by subsequent policy implementations. The official policy documents can be found at the respective websites of the RIRs. This is a public document that will be reviewed and revised quarterly through the coordinated efforts of the RIRs.
For more information, refer to the AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC websites.
1. General
1.1 Goals of the RIR System
RIR | Policy |
---|---|
|
All allocations and assignments of Internet resources must be consistent with the goals of the Internet Registry system: aggregation, conservation and registration. |
1.2 Membership
RIR | Category | Policy |
---|---|---|
AFRINIC | Qualification | Membership is open to organizations legally present in the AFRINIC region of service. |
Access to registration services | Registration service is accessible by members only. Registered resources are publicly available. | |
Fee model | Not-for profit. Fee established to enable cost recovery of operations. | |
APNIC | Qualification | Only organizations that are located in the APNIC region or have networks located in the APNIC region may apply for resources. |
Access to registration services | Members have full access to all services. Non-member account holders may access resource assignment and allocation services. | |
Fee model | Not-for-profit. Fee schedule established to enable cost recovery of operations. | |
ARIN | Qualification | Organizations that receive direct allocations automatically become members. Membership also open to organizations with direct assignments or ARIN issued Autonomous System Numbers. |
Access to registration services | Do not need to be a member to receive registration services. | |
Fee model | Not-for-profit. Fee schedule established to enable cost recovery of operations. | |
LACNIC | Qualification | Membership is open to LACNIC region only, without conditions. |
Access to registration services | Organizations approved for IP addresses automatically become members. It is not necessary to become a member to obtain some services like ASN assignments. Only organizations based in LACNIC region may apply for resources. | |
Fee model | Not-for-profit. Fee schedule established to enable cost recovery of operations. | |
RIPE NCC | Qualification | Membership is open without conditions. |
Access to registration services | Members only. Direct Assignment Users who have a contract with the RIPE NCC can also access Registration Services. | |
Fee model | Not-for-profit. Fee schedule established to enable cost recovery of operations. |
1.3 Allocation Terms and Conditions
1.3.1 Type of Custodianship
RIR | Policy |
---|---|
AFRINIC | Valid as long as original criteria remain satisfied. |
APNIC | Allocates and assigns on a ‘license” basis, to be of specific limited duration (normally 1 year). Licenses are renewable if: a) the original basis of the allocation or assignment remains valid and b) requirements have been met at time of renewal. |
|
Valid as long as original criteria remain satisfied and registration fees are kept up to date. |
RIPE NCC | Valid as long as original criteria remain satisfied. |
1.3.2 Transfer of Custodianship
RIR | Policy |
---|---|
AFRINIC | Does not allow sale of addresses, but recognises name changes and transfers of tangible assets associated with addresses. Requires submission of legal documents. Utilization is verified. May require new agreement. |
APNIC | APNIC recognizes name changes and transfers due to mergers and acquisitions. Requires documentation and demonstration of need.
In addition, APNIC recognizes transfers of IPv4 number resources under two other conditions: 1) the historical resource transfer policy and 2) transfers between two current APNIC account holders. “Historical” resources can be transferred to APNIC members without the need for the technical justification procedures. For transfers between current APNIC account holders, prior to the exhaustion of APNIC’s IPv4 space (that is, prior to the use of the “final /8” allocation measures) recipients of transfers are required to justify their need for address space. After this time there is no requirement for any form of evaluation of requirements for eligibility. |
ARIN | IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies.
ARIN also recognizes name changes and transfers due to mergers and acquisitions. Requires documentation and demonstration of need. |
LACNIC | Does not allow sale of addresses, but recognizes name changes and transfers of tangible assets associated with addresses. Requires submission of legal documents. Utilization is verified. May require new agreement.
Once LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment because of lack of resources, LIRs and/or End Users within the LACNIC region will be allowed to transfer IPv4 blocks. |
RIPE NCC | Member LIRs can transfer complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA to another LIR. Such address space must not contain any block that is assigned to an End User. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC according to the existing allocation policies. LIRs that receive a transfer from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.
RIPE NCC also recognizes name changes and transfers of tangible assets associated with addresses. Requires submission of legal documents. Utilization is verified. May require new agreement. |
1.3.3 Recovering Unused Resources
RIR | Policy | Comment |
---|---|---|
AFRINIC
RIPE NCC |
Valid as long as original criteria remain satisfied. | Do not actively recover unused resources, but if an organization closes, unused resources are returned to the public pool. |
APNIC
LACNIC |
Valid as long as original criteria remain satisfied. | Has policy to actively recover ‘unused’ networks.
If an organization ceases operation, unused resources are returned to the public pool. |
ARIN | Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance. |
2. IPv4
2.1 Initial Allocation
RIR | Category | Policy |
---|---|---|
AFRINIC | Size | Slow start: /22 (can be exceeded when justified by requester). |
Eligibility | The requesting organization must show an existing efficient utilization of IP addresses from their upstream provider or an immediate need of IP addresses. Justification may be based on a combination of immediate need and existing usage. | |
Period | 1 year. | |
APNIC | Size | Slow start: /22 (can be exceeded when documented immediate infrastructure need exceeds /22). |
Eligibility | a) Membership or pay non-member fee; b) have previously used or can demonstrate immediate need for /24; c) complied with policies in managing all previous address space; d) detailed plan for use of a /23 within a year; e) commit to renumber from previously deployed space. | |
Period | 1 year. | |
ARIN | Size | Slow start: /22 minimum for multihomed, otherwise /20 (can be exceeded when documented immediate need exceeds /20). /22 for Caribbean and North Atlantic Islands sector of the ARIN region. |
Eligibility | For a /22: efficient utilization of a /23 from upstream; intent to multihome; agree to renumber,
or For a /21: efficient utilization of /22 from upstream; intent to multihome; agree to renumber, or For a /20: efficient utilization of /21 from upstream; intent to multihome; agree to renumber, or Efficient utilization of /20 from upstream (no renumbering required). For a /22 in the Caribbean and North Atlantic Islands sector: efficient utilization of a /22 from upstream (no renumbering required). |
|
Period | 3 months. | |
LACNIC | Size | Slow start: /22, otherwise /21 (can be exceeded when documented immediate need exceeds /21). |
Eligibility | For a /22: current use or documented need of a /24; submit a detailed one-year utilization plan for a /23; agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the /22.or
For a /21: Must provide information on assignments with prefixes equal to or shorter than /29 (more than 8 IPv4 addresses) on LACNIC’s WHOIS database; must provide documentation that justifies the initial address space allocation (This must include detailed information showing how this resource will be used within a period of three, six and twelve months); must agree to renumber out of the blocks obtained from their providers within a period no longer than 12 months and return the space to its original provider. If the applicant is a multihomed ISP: Efficient utilization of at least 25% of the requested address space (contiguous or not). Else: Efficient utilization of at least a 50% of the requested address space (contiguous or not). |
|
Period | 12 months. | |
RIPE NCC | Size | Slow start: /21 (can be exceeded when justified). |
Eligibility | a) Membership; b) Demonstration of need. | |
Period | Until 1 July 2010, up to 12 months.
Between 1 July 2010 – 31 December 2010, up to nine months Between 1 January 2011- 31 June 2011, up to six months As of 1 July 2011, up to three months |
2.2 Subsequent Allocations
RIR | Category | Policy |
---|---|---|
AFRINIC | Size | Minimum /22, no maximum. |
Eligibility | Demonstrate 80% efficient utilization of last allocated space or an immediate need that requires more IP addresses than are available in the most recent allocation. | |
Period | Up to 1 year. | |
APNIC | Size | Minimum /21, no maximum. |
Eligibility | Demonstrate 80% efficient utilization of all prior allocated space. | |
Period | Up to 1 year. | |
ARIN | Size | Minimum /22 for multihomed, otherwise /20, no maximum. |
Eligibility | Demonstrate efficient utilization of all previous allocations and at least 80% of the most recent allocation. | |
Period | 3 months. | |
LACNIC | Size | The policy for determining the size of additional allocations is based on the efficient utilization of space within a time frame of 12 months. |
Eligibility | Demonstrate 80% efficient utilization of all prior allocated space. | |
Period | 12 months. | |
RIPE NCC | Size | Minimum /21, no maximum. |
Eligibility | Demonstrate approximately 80% efficient utilization of all prior allocated space. | |
Period | Until 1 July 2010, up to 12 months.
Between 1 July 2010 – 31 December 2010, up to nine months Between 1 January 2011- 31 June 2011, up to six months As of 1 July 2011, up to three months |
2.3 Sub-Allocations
RIR | Policy | Comment |
---|---|---|
AFRINIC | LIRs may sub-allocate addresses to other organizations, which further assign addresses to End Users. LIRs also assign addresses. Sub-allocations are subject to the ‘Sub-Allocation Window’ procedure. | |
APNIC | LIRs may sub-allocate addresses to other organizations, which further assign addresses to end-users. LIRs also assign addresses. Sub-allocations are subject to the ‘Assignment Window’ procedure. | See section 2.5.1 ‘Assignment Window’ below. |
ARIN | ISPs may sub-allocate addresses to other organizations, which further assign addresses to End Users. | |
LACNIC | RIR allocates and assigns IP blocks to organizations that can be ISPs, End Users or National Internet Registries, (NIRs – see section 7). NIRs allocate and assign IP blocks to organizations in their countries. ISPs may sub-allocate IP blocks to other ISPs or assign them to End Users. | |
RIPE NCC | An LIR may sub-allocate up to a /20 (4096 addresses) to a downstream network operator every twelve months, who can then assign addresses to End Users. The minimum size of a sub-allocation is a /24. |
2.4 Assignments by RIRs (Independent/Portable)
2.4.1 General
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Size | /24 minimum, no maximum. | |
Eligibility |
|
||
APNIC | Size | No minimum, no maximum. | Known as ‘small multihoming assignment policy’. Can be applied for under membership or as a ‘non-member account holder’. |
Eligibility |
Requesting organization needs to be multihomed and agree to renumber out of previously assigned address space. Assignments will be made according to the following criteria: 25% immediate utilization rate and 50% utilization rate within one year. |
||
ARIN | Size | /24 minimum for multihomed, otherwise /20, no maximum. | Known as ‘end-user’ assignments. |
Eligibility | Assignments will be made according to the following criteria: 25% immediate utilization rate and 50% utilization rate within one year. /24 and /23 networks must be returned if an organization receives an additional assignment. | ||
LACNIC | Size | /24 minimum, no maximum. | Must agree to renumber out of all the blocks allocated by providers within a period of 3 months and return the space to its original provider. |
Eligibility | Multi-homed End Users may receive a minimum of /24 based on previous assignments of /25 from upstream providers.
Single-home End Users may apply, for at least a /20, based on previous assignments of /21 from upstream providers. |
||
RIPE NCC | Size | No minimum, no maximum. | |
Eligibility | The utilization rate of an assignment must be such that at least 50% of the total space shall have been utilised halfway through the assignment period applied at the time of the assignment.
Assignment period: Until 1 July 2010, up to 12 months. Between 1 July 2010 – 31 December 2010, up to nine months Between 1 January 2011- 31 June 2011, up to six months As of 1 July 2011, up to three months |
2.4.2 Critical Infrastructure
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Definition | Public IXPs and root DNS service providers. | Portable space can be obtained by submitting a request directly to AFRINIC. |
Size | /24 minimum, more if justified. | ||
Eligibility | No specific criteria defined. | ||
APNIC | Definition | Root DNS, ccTLD, gTLD, IANA, RIRs, NIRs. | |
Size | /24 minimum. | ||
Eligibility | Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. | ||
ARIN | Definition | Root DNS, ccTLD, gTLD, IANA, RIRs. | Requested via the ‘micro-allocations’ policy. |
Size | /24 minimum. | ||
Eligibility | Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. | ||
LACNIC | Definition | Root DNS, ccTLD, gTLD, IANA, RIRs. | Requested via the ‘micro-allocations’ policy. |
Size | /24 minimum, /20 maximum. | ||
Eligibility | Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. | ||
RIPE NCC | Definition | Anycasting ccTLD, gTLD, ENUM. | The organizations applicable under this policy are TLD managers, as recorded in the IANA’s Root Zone Database and ENUM administrators, as assigned by the ITU. |
Size | /24. | ||
Eligibility | The organisation may receive up to four /24 prefixes per TLD and four /24 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC4786 (http://www.ietf.org/rfc/rfc4786.txt) |
2.4.3 Internet Exchange Points (IXPs)
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Size | /24. | Portable space can be obtained by submitting a request directly to AFRINIC. |
Eligibility |
|
||
APNIC | Size | /24 minimum assignment. | There is no restriction on routing prefixes assigned under this policy. |
Eligibility | Must be an IXP.
The number of ISPs connected should be at least three and there must be a clear and open policy for others to join. |
||
ARIN | Size | /24 minimum assignment. | Requested via the ‘micro-allocations’ policy. |
Eligibility | Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. | ||
LACNIC | Size | /24 minimum, /20 maximum. | Requested via the ‘micro-allocations’ policy.
Organizations receiving micro-assignments shall not sub-assign these IPv4 addresses. |
Eligibility | Exchange point operators must provide documentation showing that it is an IXP, list of participants, structure diagram and numbering plan. The organization shall have at least three members and an open policy for the association of new members. It must also provide a utilization plan for the following three and six months. | ||
RIPE NCC | Size | No special policy. | Portable address space (Provider Independent (PI) address space) can be requested for this purpose. |
Eligibility | No special policy. |
2.5 Assignments by LIRs
(Aggregatable/Non-Portable)
2.5.1 Assignment Window
RIR | Policy | Comment |
---|---|---|
|
Not applicable. | Assignment practices are audited by RIR staff at time of request for additional resources. |
|
LIRs/ISPs need approval from the RIR when making assignments larger than their Assignment Window. This is the number of addresses an LIR/ISP can assign without prior approval. The RIR sets the assignment window according to the LIR’s/ISP’s level of experience with the policies. |
APNIC does not have assignment windows on infrastructure. In RIPE region a new LIR’s Assignment Window (AW) is automatically set to a /21 (2048 addresses) six months after receiving their first allocation. |
2.5.2 Dynamic Addressing
RIR | Policy |
---|---|
|
In general, dynamic assignment of IP addresses is expected on transient connections such as analogue dialup. |
2.5.3 Mobile Terminals
RIR | Policy |
---|---|
|
There is no special assignment policy with respect to mobile terminals. |
2.5.4 Web Hosting
RIR | Policy |
---|---|
|
Name based web hosting is strongly encouraged where feasible. |
2.5.5 Network Address Translation (NAT)
RIR | Policy |
---|---|
|
The use of NAT is neither encouraged nor discussed during the request process. |
2.5.6 RFC1918 Private Address Space
RIR | Policy |
---|---|
|
For private networks that will never be connected to the Internet, the requestor is made aware of the IPv4 address space reserved for use in RFC1918. |
2.6. Use of Final Unallocated IPv4 Address Space
RIR | Category | Policy |
---|---|---|
AFRINIC | Size | No special policy. |
Eligibility | No special policy. | |
APNIC | Size | /22. |
Eligibility | When an equivalent of a /8 is remaining in the APNIC pool:
1. Each account holder (current and future) will be eligible to request and receive a single allocation from the remaining space, providing the account holder meets the criteria for receiving an initial or subsequent IPv4 allocation. 2. A /16 will be held in reserve for future uses, as yet unforeseen. If the reserved /16 remains unused by the time the rest of the remaining /8 worth of space has been allocated, the /16 will be returned to the APNIC pool for distribution under the policy described in the point above |
|
ARIN | Size | /28 minimum, /24 maximum. |
Eligibility | Policy takes effect upon receipt of ARIN’s last /8 IPv4 allocation from IANA. Allocations and assignments are from a reserved /10 and must be justified by immediate IPv6 requirements. | |
LACNIC | Size | /22 for ISPs, /24 for Critical Infrastructure |
Eligibility | When an equivalent of a /12 is remaining in the LACNIC pool, allocations and assignments will only be done to new members. Allocations to new ISPs will be of size /22 and assignments to critical infrastructure will be of size /24. No further allocations or assignments will be possible after receiving resources under this policy. | |
RIPE NCC | Size | /22 |
Eligibility | When RIPE NCC is required to make allocations from the final /8 it receives from the IANA:
1. LIRs may receive one allocation from this /8 providing they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application. In addition, allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. 2. A /16 will be held in reserve for some future uses, as yet unforeseen. In the event that this /16 remains unused at the time the remaining /8 covered by this policy has been distributed, it returns to the pool to be distributed policy described in the point above. |
3. IPv6
3.1 Initial Allocation
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Size | /32. | |
Eligibility | a) be an LIR;
b) not be an end site; c) show a detailed plan to provide IPv6 connectivity to organizations in the AFRINIC region. d) show a reasonable plan for making /48 IPv6 assignments to end sites in the AFRINIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months. |
||
Period | Up to one year. | ||
APNIC | Size | /32. | Allocations consistent with the globally co-ordinated ‘IPv6 Address Allocation and Assignment Policy’ document. organizations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request.
Considers IPv4 deployment as one of the means of justifying a larger initial allocation. |
Eligibility | APNIC members with IPv4 resources managed by APNIC but with no IPv6 resources automatically qualify for an IPv6 /32.
Organizations with no IPv4, or that wish to request more than a /32 should meet the following requirements: a) Be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will make assignments ; d) meet one of the following two criteria:
|
||
Period | For up to one year. | ||
ARIN | Size | /32. | Organizations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. |
Eligibility | Organizations that intend to assign IPv6 addresses to other organizations or customers for globally reachable IPv6 Internet connectivity within 12 months can qualify by meeting one of the following criteria:
a) have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or; b) demonstrate an intent to immediately multi-home using IPv6 and an assigned valid global AS number, or; c) provide a reasonable plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Organizations that intend to assign IPv6 addresses to other organizations or customers for IPv6-based network connectivity services (not necessarily Internet connected) may also qualify. |
||
Period | For up to five years. | ||
LACNIC | Size | /32. | As a special case, LACNIC has a policy for the “Second Allocation” where An Organization that holds only one IPv6 allocation can return it (within the first 6 months of getting it) in order to receive another shorter prefix allocation from LACNIC. |
Eligibility | 1. Hold an IPv4 allocation from LACNIC and announce the allocated block with the minimum possible level of disaggregation to the one that is publishing the IP blocks.
Or, 2. a) Be a LIR or an ISP; b) Document a detailed plan for the services and IPv6 connectivity to be offered to other organizations; c) Announce the allocated block in the Internet inter-domain routing system, with the minimum possible level of disaggregation to the one that is publishing the IP blocks, within a period no longer than 12 months; d) Offer IPv6 services to clients or entities owned/related (including departments and/or sites) physically located within the region covered by LACNIC within a period not longer than 24 months than 24 months. |
||
Period | For up to one year. | ||
RIPE NCC | Size | /32. | Organizations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request.
Considers IPv4 deployment as one of the means of justifying a larger initial allocation.
|
Eligibility | a) Be an LIR;
b) have a plan for making sub-allocations to other organizations and/or End Site assignments within two years. |
||
Period | For up to two years. |
3.2 Subsequent Allocations
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Size | Minimum size of next allocation will equal the first allocation size. More can be allocated but justification must be supplied. | Contiguous allocation provided if possible.
RFC 3194 defines the HD-Ratio. |
Eligibility | ISP/LIR must satisfy the evaluation threshold of past address utilization in terms of the number of sites in units of /48 assignments. The HD-Ratio of 0.94 is used to determine the utilization thresholds that justify the allocation of additional addresses. | ||
Period | Up to one year. | ||
APNIC
RIPE NCC |
Size | Minimum size of next allocation will equal the first allocation size. More can be allocated but justification must be supplied. | Contiguous allocation provided if possible.
RFC 3194 defines the HD-Ratio. |
Eligibility | ISP/LIR must satisfy the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments. The HD-Ratio of 0.94 is used to determine the utilization thresholds that justify the allocation of additional addresses. | ||
Period | Up to two years. | ||
ARIN | Size | Minimum size of next allocation will equal the first allocation size. More can be allocated but justification must be supplied. |
Contiguous allocation provided if possible. RFC 3194 defines the HD-Ratio. |
Eligibility | ISP/LIR must satisfy the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments. The HD-Ratio of 0.94 is used to determine the utilization thresholds that justify the allocation of additional addresses.
Additional allocations are also available for IPv4 to IPv6 transitional technology:
|
||
Period | Up to two years. | ||
LACNIC | Size | Minimum size of next allocation will equal the first allocation size. More can be allocated but justification must be supplied. | Contiguous allocation provided if possible.
RFC 3194 defines the HD-Ratio. |
Eligibility | ISP/LIR must satisfy the evaluation threshold of past address utilization in terms of the number of sites in units of /48 assignments. The HD-Ratio of 0.94 is used to determine the utilization thresholds that justify the allocation of additional addresses. | ||
Period | Up to two years. |
3.3 Other Allocations
3.3.1 Micro-allocations for Internal Infrastructure
RIR | Category | Policy | Comment |
---|---|---|---|
|
Size | No policy. | |
Eligibility | Not applicable. | ||
ARIN | Size | /48 minimum. | These allocations come from specific blocks reserved only for this purpose. |
Eligibility | 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. |
3.4 Assignments by RIRs (Independent/Portable)
3.4.1 Critical Infrastructure
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Definition | Root DNS operators, IXPs, RIRs | Part of the ‘Provider Independent (PI) Assignment for End-Sites’ policy |
Size | /48 minimum. | ||
Eligibility | Requestor to prove they operate a critical infrastructure network. | ||
APNIC | Definition | Root DNS, ccTLD, gTLD, IANA, RIRs, NIRs. | |
Size | /32 maximum. | ||
Eligibility | APNIC members with IPv4 resources assigned under the IPv4 critical infrastructure policy, but with no IPv6 resources, automatically qualify for an IPv6 /48.Members that do not hold an IPv4 critical infrastructure assignment from APNIC, that have existing IPv6 resources, or that wish to request more than /48 should meet the following requirement: Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. | ||
ARIN | Definition | Root DNS, ccTLD, gTLD, IANA, RIRs. | Known as ‘micro-allocation’ policy. |
Size | /48 minimum. | ||
Eligibility | Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. | ||
LACNIC | Definition | NAPs, Root DNS, ccTLD, gTLD, IANA, RIRs, NIRs. | |
Size | /48 minimum, /32 maximum. | ||
Eligibility | Micro allocation to critical Internet infrastructure operators only. | ||
RIPE NCC | Definition | Root DNS, Anycasting ccTLD, gTLD, ENUM. | For Anycasting assignments for ccTLD, gTLD and ENUM, the organizations are TLD managers, as recorded in the IANA’s Root Zone Database and ENUM administrators, as assigned by the ITU. |
Size | For Root DNS minimum allocation size at time of request. It is up to four /48s per Anycasting ccTLD/gTLD and ENUM | ||
Eligibility | For Root DNS minimum allocation size at time of request. It is up to four /48s per Anycasting ccTLD/gTLD and ENUM
Root DNS: Assignments to critical infrastructure are available only to the actual network infrastructure performing such functions. Anycasting ccTLD, gTLD, ENUM: An organisation may receive up to four /48 prefixes per TLD and four /48 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC4786. |
3.4.2 Internet Exchange Points (IXPs)
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Size | /48 minimum. | Part of the ‘Provider Independent (PI) Assignment for End-Sites’ policy |
Eligibility |
– Minimum number of three peers connected – Open policy for anyone to connect/peer. |
||
APNIC | Size | /48 minimum. | |
Eligibility | APNIC members with IPv4 resources assigned under the IPv4 IXP policy, but with no IPv6 resources, automatically qualify for an IPv6 /48.
Members that do not hold an IPv4 critical infrastructure assignment from APNIC, that have existing IPv6 resources, or that wish to request more than /48 should meet the following requirement: The IXP must have a clear and open policy for others to join and must have at least three members. |
||
LACNIC | Size | /48 minimum, /32 maximum. | |
Eligibility | The IXP must have a clear and open policy for others to join and must have at least three members. It must also provide documentation showing that it is an IXP, list of participants, structure diagram, numbering plan and a utilization plan for the following three and six months. | ||
ARIN | Size | /48 minimum. | |
Eligibility | Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. | ||
RIPE NCC | Size | /64 or /48. | |
Eligibility | The IXP must have a clear and open policy for others to join and must have at least three members. |
3.4.3 End Users
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Size | /48 minimum | |
Eligibility | a) Not be a LIR;
b) Qualify for an IPv4 PI assignment from AFRINIC under the IPv4 policy currently In effect; c) Be or plan to be an AFRINIC Member of the category “EU-PI”; and d) Show a plan to use and announce the IPv6 PI address space within twelve (12) months after approval. |
||
APNIC | Size | /48 minimum. | These assignments come from a distinctly identified prefix. |
Eligibility | APNIC members with IPv4 resources assigned under the IPv4 multihoming policy, but with no IPv6 resources, automatically qualify for an IPv6 /48.
Members that do not hold an IPv4 multihoming assignment from APNIC, that have existing IPv6 resources, or that wish to request more than /48 should meet the following requirement: a) An organization is currently multihomed or plans to be multihomed within three months. |
||
ARIN | Size | /48 minimum. | These assignments come from a distinctly identified prefix and are made with a reservation for growth of at least a /44. |
Eligibility | 1. a) Not be an IPv6 LIR; and b) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect;
or, 2. demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA. or, 3. be a Community Network that will immediately have at least 100 simultaneous users and a demonstrated plan to have at least 200 simultaneous users within one year. An HD-Ratio of .94 must be met for all assignments larger than a /48. |
||
LACNIC | Size | /48 minimum, /32 maximum | In case of announcing the assignment on the Internet inter-domain routing system, the receiving organization shall announce a single block, aggregating the total IPv6 address assignment received. |
Eligibility | Automatic if requestor has IPv4 assignments. Else: 1) Not been an LIR, 2) Announce a single block in the inter-domain routing table, 3) submit information showing address use plan for 3, 6 and 12 months, 4) submit network topology, routing and addressing plan. | ||
RIPE NCC | Size | /48 minimum. | Assignments will be made from a separate ‘designated block’ to facilitate filtering practices |
Eligibility | a) demonstrate that the organisation will be multihomed
b) meet the requirements of the policies described in the document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region“ |
3.5 Assignments by LIRs
(Aggregatable/Non-Portable)
3.5.1 Dynamic Addressing
RIR | Policy | Comment |
---|---|---|
|
There is currently no specific policy related to dynamic addressing. | See RFC3177. |
3.5.2 Mobile Terminals
RIR | Policy |
---|---|
|
There is no special assignment policy with respect to mobile terminals. |
3.5.3 Web Hosting
RIR | Policy |
---|---|
|
There is no recommendation for IPv6 assignments in support of web hosting at this time. |
3.5.4 Network Address Translation (NAT)
RIR | Policy |
---|---|
|
The use of NAT is neither encouraged nor discussed during the request process. |
4. Autonomous System Numbers (ASNs)
4.1 Allocations
RIR | Policy |
---|---|
APNIC | Blocks of ASNs are allocated to NIRs for further distribution to their members. |
|
Not applicable. |
4.2 Assignments
RIR | Category | Policy |
---|---|---|
|
Eligibility | Policies for ASN assignments are aligned with the guidelines contained in RFC1930. Verify that a network will have a unique routing policy or that it will be a multihomed site before assigning an ASN. |
APNIC | Eligibility | ASNs may be obtained directly from APNIC as a member or non-member account holder. The ASN obtained directly is portable. ASNs may also be obtained indirectly, through a LIR who ‘sponsors’ the request. In this event, the ASN is non-portable.
Criteria need to be met in both cases, that is: An organisation is eligible if it a) is multihomed; and b) has a single, defined routing policy that is different from its providers’ routing policies. An organisation will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter).
|
4.2.1 32-bit ASNs
RIR | Policy |
---|---|
|
From 1 January 2007 the RIR will process applications that specifically request 32-bit only AS Numbers (AS numbers that can not be represented with 16 bits) and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, the RIR will assign a 16-bit AS Number.
From 1 January 2009 RIR will process applications that specifically request 16-bit AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit AS Number, the RIR will assign a 32-bit only AS Number. From 1 January 2010 the RIR will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool. |
APNIC | In addition to above, from 1 July 2009, APNIC will process applications that specifically request 16-bit AS Numbers and assign such AS Numbers as requested by the applicant if the application can demonstrate that a 32-bit only AS Number is unsuitable. In the absence of demonstrated need for a 16-bit AS Number, a 32-bit only AS Number will be assigned by APNIC. |
LACNIC | From 1 January 2007 the RIR will process applications that specifically request 32-bit only AS Numbers (AS numbers that can not be represented with 16 bits) and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, the RIR will assign a 16-bit AS Number.
From 1 January 2009 RIR will process applications that specifically request 16-bit AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit AS Number, the RIR will assign a 32-bit only AS Number. From 1 January 2010, LACNIC shall allocate 32-bit AS numbers by default. 16-bit AS numbers shall be allocated, if available, in response to applications specifically requesting said resource and that duly justify the technical reasons why a 32-bit AS number would not be appropriate for its needs. |
5. Database – Registration
RIR | Category | Policy | Comment |
---|---|---|---|
AFRINIC | Modification | LIRs are required to register all assignments and sub-allocations. | |
Entry | Can update all assignment and sub-allocation registrations (protection mechanism available). Org object cannot be created by a LIR. | ||
APNIC | Modification | LIRs required to register all assignments and sub-allocations. Registrations will be stored privately by APNIC unless the custodian wishes them to be made publicly available in the APNIC Whois Database. | Not required to register infrastructure assignments. |
Entry | Can update all assignment and sub-allocation registrations (protection mechanism available). Incident Response Team reference mandatory for all IP address and AS number objects in the APNIC Whois Database to assist in reporting network abuse. | ||
ARIN | Modification | Downstream reassignments and reallocations are reported, showing hierarchy and End User assignments.
Reassignment information for residential customers need not contain the customer’s name nor street address. |
Not required to register infrastructure assignments. |
Entry | Can modify all parent data except “org name” and address range. Can modify all child data. | ||
LACNIC | Modification | Downstream reassignments and reallocations are reported, showing hierarchy and End User assignments. | Not required to register infrastructure assignments. |
Entry | Can modify all parent data except “org name” and address range. Can modify all child data. Users have to authenticate themselves in LACNIC web system. | ||
RIPE NCC | Modification | LIRs are required to register all assignments and sub-allocations. | |
Entry | Can update all assignment and sub-allocation registrations (protection mechanism available). |
6. Reverse DNS
RIR | Policy | Comment |
---|---|---|
AFRINIC | Only make delegations on 8-bit boundaries (/16 or /24). Multiple delegations may be requested to cover CIDR prefixes for blocks bigger than a /24. | |
APNIC | Provides reverse DNS based on domain objects in the APNIC database. If the delegation is /16 or larger then the authority for the reverse zone, it is delegated to the custodian of the address space. | Policy for “lame delegations” checking established and enforced. |
ARIN | Provides reverse DNS for all allocations and assignments in the database with the following exception: For all /16 or larger blocks ARIN delegates reverse DNS authority to the registrant. | Policy for “lame delegations” checking established and enforced. |
LACNIC | Provides reverse DNS for all parent blocks. Does not provide reverse DNS for reassignments on child blocks if the parent is /16 or greater. | Policy for “lame delegations” checking established and enforced |
RIPE NCC | Provides reverse DNS delegation on request. Deploys DNSSEC on all the reverse zones. | RIPE NCC verifies RFC1912 compliance. |
7. National Internet Registries (NIRs)
RIR | Policy |
---|---|
|
Not applicable. |
APNIC | NIRs operate in Korea, China, Japan, Taiwan, Indonesia and Vietnam. They are not ISPs. They allocate to their members within their economy following APNIC policies. organizations within those NIR economies may go to either the relevant NIR or APNIC. |
LACNIC | NIRs operate in Brazil and Mexico. They are not ISPs. They allocate to their members following LACNIC policies. NIRs are responsible for providing services within their country. |
8. Policy Development
RIR | Policy |
---|---|
|
The policy development process is consensus based, open to anyone to participate and is transparent in archiving all decisions and policies so that they are publicly accessible. |
9. Internet Experiments
RIR | Policy |
---|---|
|
Allocations and assignments of Internet resources for Internet experiments are available. Such allocations or assignments are made for one year after which they must be returned. They are intended to support experimental Internet activities. Results of experiments must be made freely available to the public. |
ARIN | ARIN will allocate Numbering Resources to entities requiring temporary Numbering Resources for a fixed period of time under the terms of recognised experimental activity. |
LACNIC | LACNIC shall make experimental allocations with the aim of encouraging research and development within the region of Latin America and the Caribbean. The experimental allocation shall be for a period of one year, renewable for a period of the same duration, with no specified maximum. The results of the experiment must be published on a public website. |
10. Documentation Prefix
RIR | Policy |
---|---|
APNIC | A documentation prefix is available to organizations wishing to use examples of Internet resources in educational materials, case studies and other documentation. |
|
No policy. |
ISP/LIR must satisfy the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments. The HD-Ratio of 0.94 is used to determine the utilization thresholds that justify the allocation of additional addresses. Additional allocations are also available for IPv4 to IPv6 transitional technology: · /32 minimum allocation · /24 maximum allocation |
Last modified on 24/09/2021