<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19046"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>Team,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>While IPv6 is not IPv4 we should never the less take into
consideration everything we have learned</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>and develop Best Practices from Lessons
Learned.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>I support this Policy.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>John Kuhn</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>Break Through Technologies</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>ESC MGS</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial>Government of Ontario</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=511252118-02052011><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV class=gmail_quote>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote> 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"
width=58 height=61 NOSEND="1"><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></BODY></HTML>