<div class="gmail_quote"><div>I support this draft policy</div><div>RD</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
ARIN-2011-3: Better IPv6 Allocations for ISPs<br>
<br>
Changes include:<br>
1. Does not delete section 2.9 (request from staff, no impact on policy<br>
meaning)<br>
2. Limits LIR recursion to a single level and limit subordinate LIRs to<br>
/32. (community concern)<br>
3. Restores PAU to the calculation in 6.5.2.1(c) (from errata slide<br>
presented in meeting)<br>
4. Preserves 2010-12 language in new 6.5.3.1 (from errata slide<br>
presented in meeting)<br>
5. Preserves verbiage allowing ISPs to allocate to their own internal<br>
infrastructure in 6.5.4.1 (from errata slide presented in meeting)<br>
6. Adds a statement to delete current NRPM 6.9 (from errata slide<br>
presented in meeting)<br>
7. Adds language to limit initial allocations to no more than a /16<br>
(6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12<br>
(an organization may apply for additional /12s, but, no single<br>
allocation larger than a /12 can be made at one time) (6.5.2.1(e))<br>
(community concern)<br>
<br>
Feedback is encouraged during the last call period. All comments should<br>
be provided to the Public Policy Mailing List. Last call for 2011-3 will<br>
expire on 2 May 2011. After last call the AC will conduct their last<br>
call review.<br>
<br>
The draft policy text is below and available at:<br>
<a href="https://www.arin.net/policy/proposals/" target="_blank">https://www.arin.net/policy/proposals/</a><br>
<br>
The ARIN Policy Development Process is available at:<br>
<a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
<br>
Regards,<br>
<br>
Communications and Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
<br>
Draft Policy ARIN-2011-3<br>
Better IPv6 Allocations for ISPs<br>
<br>
Version/Date: 18 April 2011<br>
<br>
Policy Statement:<br>
<br>
Amend section 2 as follows:<br>
<br>
Replace section 2.10 with the following:<br>
<br>
2.10 The term End Site shall mean a single structure or service delivery<br>
address, or, in the case of a multi-tenant structure, a single tenant<br>
within said structure (a single customer location).<br>
<br>
Add the following:<br>
<br>
2.12 When applied to IPv6 policies, the term serving site shall<br>
mean a location where an ISP terminates<br>
or aggregates customer connections, including, but, not limited to<br>
Points of Presence (POPs), Datacenters, Central or Local switching<br>
office or regional or local combinations thereof.<br>
<br>
2.13 When applied to IPv6 policies, the term<br>
"provider assignment unit" shall mean the prefix of the<br>
smallest block a given ISP assigns to end sites (recommended /48).<br>
<br>
2.14 The term utilized shall have the following definitions when applied<br>
to IPv6<br>
policies:<br>
<br>
(i) A provider assignment unit shall be considered fully utilized when<br>
it is assigned to an end-site.<br>
<br>
(ii) Larger blocks shall have their utilization defined by dividing the<br>
number of provider assignment units assigned from the<br>
containing block by the total number of provider assignment<br>
units. This ratio will often be expressed as a percentage<br>
(e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)<br>
<br>
Replace sections 6.5.1 through 6.5.3 with the following:<br>
6.5.1 Terminology<br>
<br>
(a) The terms ISP and LIR are used interchangeably in this document and<br>
any use of either term shall be construed to include both meanings.<br>
<br>
(b) The term nibble boundary shall mean a network mask which aligns<br>
on a 4-bit boundary (in slash notation, /n, where n is evenly divisible<br>
by 4, allowing unit quantities of X such that 2^n=X where n is<br>
evenly divisible by 4, such as 16, 256, 4096, etc.)<br>
<br>
6.5.2 Initial Allocations to LIRs<br>
6.5.2.1 Size<br>
<br>
(a) All allocations shall be made on nibble boundaries.<br>
<br>
(b) In no case shall an LIR receive smaller than a /32<br>
unless they specifically request a /36. In no case shall<br>
an ISP receive more than a /16 initial allocation.<br>
<br>
(c) The maximum allowable allocation shall be the smallest<br>
nibble-boundary aligned block that can provide an equally<br>
sized nibble-boundary aligned block to each of the<br>
requesters serving sites large enough to satisfy the needs<br>
of the requesters largest single serving site using no more<br>
than 75% of the available addresses.<br>
<br>
This calculation can be summarized as /N where<br>
N = P-(X+Y) and P is the organization's<br>
Provider Allocation Unit X is a multiple of 4 greater<br>
than 4/3*serving sites and Y is a multiple of 4<br>
greater than 4/3*end sites served by largest serving site.<br>
<br>
(d) For purposes of the calculation in (c), an end site which<br>
can justify more than a /48 under the end-user assignment<br>
criteria in 6.5.8 shall count as the appropriate number of /48s<br>
that would be assigned under that policy.<br>
<br>
(e) For purposes of the calculation in (c), an LIR which has<br>
subordinate LIRs shall make such allocations according<br>
to the same policies and criteria as ARIN. In such a case,<br>
the prefixes necessary for such an allocation should be treated<br>
as fully utilized in determining the block sizing for the parent LIR.<br>
LIRs which do not receive resources directly from ARIN will<br>
not be able to make such allocations to subordinate LIRs and<br>
subordinate LIRs which need more than a /32 shall apply<br>
directly to ARIN.<br>
<br>
(f) An LIR is not required to design or deploy their network<br>
according to this structure. It is strictly a mechanism to<br>
determine the largest IP address block to which the LIR<br>
is entitled.<br>
<br>
6.5.2.2 Qualifications<br>
An organization qualifies for an allocation under this policy if<br>
they meet any of the following criteria:<br>
<br>
(a) Have a previously justified IPv4 ISP allocation from ARIN<br>
or one of its predecessor registries or can qualify for<br>
an IPv4 ISP allocation under current criteria.<br>
<br>
(b) Are currently multihomed for IPv6 or will immediately<br>
become multihomed for IPv6 using a valid assigned<br>
global AS number.<br>
<br>
In either case, they will be making reassignments<br>
from allocation(s) under this policy to other organizations.<br>
<br>
(c) Provide ARIN a reasonable technical justification<br>
indicating why an allocation is necessary. Justification<br>
must include the intended purposes for the allocation and<br>
describe the network infrastructure the allocation will be used to<br>
support. Justification must also include a plan detailing anticipated<br>
assignments to other organizations or customers for one,<br>
two and five year periods, with a minimum of 50 assignments<br>
within 5 years.<br>
<br>
6.5.3 Subsequent Allocations to LIRs<br>
<br>
(a) Where possible ARIN will make subsequent allocations by<br>
expanding the existing allocation.<br>
<br>
(b) An LIR which can show utilization of 75% or more of their<br>
total address space, or more than 90% of any serving site<br>
shall be entitled to a subsequent allocation.<br>
<br>
(c) If ARIN can not expand one or more existing allocations,<br>
ARIN shall make a new allocation based on the initial<br>
allocation criteria above. The LIR is encouraged, but not<br>
required to renumber into the new allocation over time<br>
and return any allocations no longer in use.<br>
<br>
(d) If an LIR has already reached a /12 or more, ARIN will<br>
allocate a single additional /12 rather than continue<br>
expanding nibble boundaries.<br>
<br>
Renumber/move the second paragraph of existing section 6.5.2.1 to 6.5.3.1.<br>
<br>
For reference, this would become:<br>
6.5.3.1 Subsequent Allocations for Transition<br>
Subsequent allocations will also be considered for deployments<br>
that cannot be accommodated by, nor were accounted for, under<br>
the initial allocation. Justification for the subsequent subnet size<br>
will be based on the plan and technology provided with a /24<br>
being the maximum allowed for a transition technology.<br>
Justification for transitional allocations will be reviewed every 3<br>
years and reclaimed if they are no longer in use for transitional<br>
purposes. All such allocations for transitional technology will be<br>
made from a block designated for this purpose.<br>
<br>
(This paragraph comes from 2010-12 which was adopted after this draft<br>
policy was written).<br>
<br>
Replace section 6.5.4 with the following<br>
<br>
6.5.4 Assignments to end users shall be governed by the same<br>
practices adopted by the community in section 6.5.8 except<br>
that the requirements in 6.5.8.1 do not apply.<br>
<br>
6.5.4.1 An LIR may assign up to a /48 per PoP as well as up to an<br>
additional /48 globally for its own infrastructure.<br>
<br>
Add the following to 6.5.7<br>
<br>
LIRs which received an allocation under previous policies which is<br>
smaller than what they are entitled to under this policy may receive<br>
a new initial allocation under this policy provided that they agree to<br>
renumber into that new allocation and return their prior allocation(s)<br>
within 5 years. If possible, ARIN will simply expand their existing<br>
allocation rather than requiring renumber and return.<br>
<br>
Delete section 6.9<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
***************************************************************************************<br>
The information contained in this message, including attachments, may contain<br>
privileged or confidential information that is intended to be delivered only to the<br>
person identified above. If you are not the intended recipient, or the person<br>
responsible for delivering this message to the intended recipient, Windstream requests<br>
that you immediately notify the sender and asks that you do not read the message or its<br>
attachments, and that you delete them without copying or sending them to anyone else.<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 71, Issue 8<br>
****************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br><img src="http://api.ning.com/files/60Dc*7fMSnOD5inYWvnElhieb2y*e2O798iHVa48vgYOJUmz33g1MSmWAGQs0M2C7g4LXqAu0KvJ0c99k3kSouZfig33AnNo/emaillogo.jpg" height="61" width="58"><br>
<div>Rudi Daniel<div><i><a href="http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774" target="_blank">danielcharles consulting</a><br></i><b><span style="font-size:large"><font color="#006600"><a href="http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774" target="_blank">1-784 498 8277</a></font></span></b></div>
<div><font color="#006600"><span style="font-size:large"><b><br></b></span></font><div><span style="font-size:large"><br></span></div></div></div><br>