Formal introduction on PPML on 23 February 2010
Origin - Policy Proposal 106
Draft Policy - 23 February 2010 (with staff assessment)
Abandoned by AC - 28 April 2010Public Policy Mailing List
ARIN Public Policy Meeting:ARIN XXV
ARIN Advisory Council:
David Farmer and Scott Leibrand
ARIN Board of Trustees:
Draft Policy 2010-7
Simplified IPv6 policy
Version/Date: 23 February 2010
Delete 6.1 Introduction - This is all historical.
Leave 6.3 as is (renumber to 6.1) - These still accurately reflect the
Goals we want our policy to follow.
Delete 6.4.2 - 6.4.4 - These principles don't seem worthy of elevation
to special status. 6.4.1 is handled in a separate Draft Policy.
Replace 6.5 - Policies for allocations and assignments with text below
(renumber to 6.2). This seems to be where most of the changes and
simplification are needed.
Delete 6.7 Appendix A: HD-Ratio - The numbers from this table were used
to determine the thresholds in 6.2 below, so this section is confusing
and no longer needed.
Delete 6.9 IPv6 Reassignments policy - This is redundant and covered
Move 6.10 into 184.108.40.206 below
2.12. Critical Infrastructure Providers
Critical infrastructure providers of the Internet include public
exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
gTLD, and ccTLD operators) as well as the RIRs and IANA.
ARIN will make IPv4 micro-allocations to Critical Infrastructure
Providers per section 2.8. These allocations will be no longer than a
/24. Multiple allocations may be granted in certain situations.
4.4.1. Allocation and assignment from specific blocks
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.
4.4.2. Exchange point requirements
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.2. Policies for IPv6 allocations and assignments
6.2.1. Allocations and assignments
To meet the goal of Fairness, ARIN makes both allocations and
assignments according to common criteria. Allocations are made to LIRs,
and assignments to certain end users.
6.2.2. Assignments from LIRs/ISPs
End-users are assigned an end site assignment from their LIR or ISP. The
exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (when only one subnet is
anticipated for the end site) up to the normal maximum of /48, except in
cases of extra large end sites where a larger assignment can be justified.
The following guidelines may be useful (but they are only guidelines):
* /64 when it is known that one and only one subnet is needed
* /56 for small sites, those expected to need only a few subnets
over the next 5 years.
* /48 for larger sites
For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.
6.2.3. Allocations and assignments from ARIN
To balance the goals of Aggregation, Conservation, Fairness, and
Minimized Overhead, ARIN normally issues IPv6 addresses only in the
discrete sizes of /48, /40, /32, /28, /24, or larger. Each organization
or discrete network may qualify for one allocation or assignment of each
220.127.116.11.1 Allocation and assignment from specific blocks
Each allocation/assignment size will be made out of separate blocks
reserved for that purpose. Additionally, non-routed assignments for
internal infrastructure, and assignments to Critical Infrastructure
Providers per section 2.8, will each be made out of separate blocks
reserved for those purposes. ARIN will make a list of these blocks
18.104.22.168 X-Small (/48)
To qualify for a /48 allocation or assignment, an organization must:
* Be Multihomed per section 2.7, and qualify for an ASN per section
* Serve at least 1000 hosts; or
* Demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current ARIN RSA; or
* Require a non-routed block for internal infrastructure; or
* Be a Critical Infrastructure Provider per section 2.8.
22.214.171.124 Small (/40)
To qualify for a /40 allocation or assignment, an organization must:
* Have two or more Multihomed sites, each of which would qualify
for a /48; or
* Serve at least 2000 hosts; or
* Be an LIR.
126.96.36.199 Medium (/32)
To qualify for a /32 allocation or assignment, an organization must:
* Have 100 or more sites, each of which would qualify for a /48; or
* Be an existing, known LIR; or
* Have a plan to provide IPv6 connectivity to other organizations
and assign at least 100 end-site assignments to those organizations
within 5 years.
188.8.131.52 Large (/28)
To qualify for a /28, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 25,000 /48s, based on
current network infrastructure and customer base.
184.108.40.206 X-Large (/24)
To qualify for a /24, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 330,000 /48s, based
on current network infrastructure and customer base.
220.127.116.11 XX-Large (larger than /24)
Allocations or assignments larger than /24 may be made only in
exceptional cases, to organizations that demonstrate the need to make
assignments and/or reallocations equal to at least 4,500,000 /48s, based
on current network infrastructure and customer base. If approved, the
allocation prefix length will be based on the number of /24s justified
(at 4,500,000 /48s each), rounded up to the next whole CIDR prefix.
Subsequent XX-Large assignments may be made if justified using the same
6.3. Registration (Copied from NRPM 6.5.5)
When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate (information registered by
ARIN may be replaced by a distributed database for registering address
management information in future). Information is registered in units of
assigned /56 networks. When more than a /56 is assigned to an
organization, the assigning organization is responsible for ensuring
that the address space is registered in an ARIN database.
6.3.1. Residential Customer Privacy (Copied from NRPM 18.104.22.168)
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.3.2. Reverse lookup (Copied from NRPM 6.5.6)
When ARIN delegates IPv6 address space to an organization, it also
delegates the responsibility to manage the reverse lookup zone that
corresponds to the allocated IPv6 address space. Each organization
should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.
This policy proposal attempts to simplify IPv6 policy in a number of ways.
For example, it:
* Deletes a number of historical sections and items that duplicate
text elsewhere in the NRPM.
* Removes the HD-ratio, instead incorporating values calculated
from it as the basis for qualification criteria.
It also replaces & rewrites section 6.5 "Policies for allocations and
assignments" entirely. This rewrite:
* Eliminates the different criteria for allocations (ISPs) vs.
assignments (end users) and replaces them with a single common set of
criteria for both classes of users. The allocation vs. assignment
distinction itself is preserved, as it still forms a useful basis for a
cost-recovery fee structure, and for other parts of the NRPM (such as
* Creates a size-class-based system for allocating IPv6 address
This has a number of advantages over the existing policy:
* Allows for safe filtering of traffic-engineering (TE)
more-specific route announcements.
* In exchange (since PA more-specifics are expected to be
filterable), allows any multihomed organization to get an assignment
from ARIN. The smaller number of such PI assignments (compared to TE
more-specifics) should mean that such assignments will largely be
accepted across the DFZ.
* Expands the use of discrete blocks from which all allocations
will be of identical prefix length and categorization. This will enable
safer and easier TE filtering, as mentioned above.
* Expands the availability of non-routed blocks for internal
infrastructure. Since routable blocks are available to any multihomed
organization, there is no longer a need to restrict the availability of
blocks from the non-routable pool.
* Makes allocations available to any LIR.
Note: In the event of an M&A transfer per section 8.2 that would result
in more than one block of a given size class being held by the combined
organization, the organization should be encouraged to renumber into a
single larger block and return the smaller block(s) when feasible.
However, as long as the organization doesn't require any additional
resources, this policy does not force them to make any changes. OTOH, if
they request a larger block and still hold two or more smaller blocks,
they would be required to return the smaller block as a condition for
receiving the larger one.
Related non-policy suggestion: in order to provide a small incentive for
organizations to renumber and return out of smaller unneeded blocks, the
ARIN fee schedule could be modified such that fees are assessed,
according to the ARIN fee schedule, for each size block issued, rather
than based on the total quantity of space held.
Q1: How did you come up with the thresholds?
A1: /48: Many of the criteria for a /48 were copied from existing
policy. The notable exception is that any Multihomed network that
qualifies for an ASN can also get a /48. /40: Since we don't give out
multiple /48s (except in the case of MDN), anyone outgrowing a /48 needs
a /40. Hence, the /40 requirements are 2x the /48 requirements. In
addition, LIRs who don't qualify for a /32 can get a /40, since they
need to be able to assign /48s. /32: Some of these requirements were
inherited from existing policy. The existing 200 sites requirement was
reduced to 100, and made to apply to assignments as well as allocations.
/28: Since we don't give out multiple /32s (except in the case of MDN),
anyone outgrowing a /32 needs a /28. The /28 requirements are based on
the current HD-ratio-based requirement for a /32 (6,183,533 /56s)
converted to /48s (24154) and rounded up to 25,000. /24+: Similarly, the
requirements for a /24 are based on the HD-ratio requirement for a /28,
and the requirement for more than one /24 are based on the HD-ratio
requirement for a /24.
Q2: What about timeframes for meeting the allocation criteria?
A2: All requests are based on current usage, so no timeframes are
involved. For example, if an ISP has a /32 and is applying for a /28,
they will be required to demonstrate that they have already assigned
25,000 /48s. Since there are 64k /48s in a /32, there is no longer any
need to make predictions about future assignments.
Q3: The proposal says "Each organization or discrete network may qualify
for one allocation or assignment of each size". It is fairly clear how
staff would evaluate whether a network qualifies for a given block size,
if it's the first block, but it is not clear how it would work if the
network already has a block assigned or allocated to it.
For instance, suppose a network has 50 sites. They qualify for a /40. A
year later they come back, have 150 sites, and want a /32. Do they
qualify for a /32, because they have more than 100 sites, or is some
consideration given to how the existing /40 has been used? It seems like
the former would be the logical interpretation, since the policy doesn't
mention anything about consideration of existing blocks, and says you
can have one of each block size.
A3: Correct. If you qualify for a larger block, you also qualify for one
of each smaller size.
Timetable for implementation: Immediate (as soon as practical).