[arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call
The ARIN Advisory Council (AC) met on 13 April 2011 and decided to
send a revised version of the following draft policy to last call:
ARIN-2011-3: Better IPv6 Allocations for ISPs
1. Does not delete section 2.9 (request from staff, no impact on policy
2. Limits LIR recursion to a single level and limit subordinate LIRs to
/32. (community concern)
3. Restores PAU to the calculation in 220.127.116.11(c) (from errata slide
presented in meeting)
4. Preserves 2010-12 language in new 18.104.22.168 (from errata slide
presented in meeting)
5. Preserves verbiage allowing ISPs to allocate to their own internal
infrastructure in 22.214.171.124 (from errata slide presented in meeting)
6. Adds a statement to delete current NRPM 6.9 (from errata slide
presented in meeting)
7. Adds language to limit initial allocations to no more than a /16
(126.96.36.199(b)) and to limit subsequent allocations to no larger than a /12
(an organization may apply for additional /12s, but, no single
allocation larger than a /12 can be made at one time) (188.8.131.52(e))
Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-3 will
expire on 2 May 2011. After last call the AC will conduct their last
The draft policy text is below and available at:
The ARIN Policy Development Process is available at:
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Draft Policy ARIN-2011-3
Better IPv6 Allocations for ISPs
Version/Date: 18 April 2011
Amend section 2 as follows:
Replace section 2.10 with the following:
2.10 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).
Add the following:
2.12 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.13 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.14 The term utilized shall have the following definitions when applied
(i) A provider assignment unit shall be considered fully utilized when
it is assigned to an end-site.
(ii) 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)
Replace sections 6.5.1 through 6.5.3 with the following:
(a) The terms ISP and LIR are used interchangeably in this document and
any use of either term shall be construed to include both meanings.
(b) 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 Allocations to LIRs
(a) All allocations shall be made on nibble boundaries.
(b) 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.
(c) 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.
(d) 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.
(e) 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.
(f) 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
An organization qualifies for an allocation under this policy if
they meet any of the following criteria:
(a) 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.
(b) 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.
(c) 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
(a) Where possible ARIN will make subsequent allocations by
expanding the existing allocation.
(b) An LIR which can show utilization of 75% or more of their
total address space, or more than 90% of any serving site
shall be entitled to a subsequent allocation.
(c) 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.
(d) If an LIR has already reached a /12 or more, ARIN will
allocate a single additional /12 rather than continue
expanding nibble boundaries.
Renumber/move the second paragraph of existing section 184.108.40.206 to 220.127.116.11.
For reference, this would become:
18.104.22.168 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.
(This paragraph comes from 2010-12 which was adopted after this draft
policy was written).
Replace section 6.5.4 with the following
6.5.4 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 22.214.171.124 do not apply.
126.96.36.199 An LIR may assign up to a /48 per PoP as well as up to an
additional /48 globally for its own infrastructure.
Add the following to 6.5.7
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 provided that they agree to
renumber into that new allocation and return their prior allocation(s)
within 5 years. If possible, ARIN will simply expand their existing
allocation rather than requiring renumber and return.
Delete section 6.9