<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>
<div><font face="Calibri,sans-serif">Hello Jason,</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">Thank you for your inquiry regarding ARIN staff review of IPv6 customer reassignments as utilization. </font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">To begin, we have not reviewed many requests for additional IPv6 address space from ISPs, to date. Most 2nd requests from ISPs to ARIN involve a declaration that their previous block (usually a /32 or /36) had not been utilized
yet, but now that they are actively involved in their deployment they realize the /32 or /36 was not large enough. This results in a new review from ARIN staff for a larger allocation size for the organization.</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">More specific to your questions, we do have some limited experience with reviewing requests for additional IPv6 address space from ISPs. In those cases we always consider a /48 assignment to a customer as 100% utilized.
In the case an ISP mixes /48s and /56s to customers, they typically state they issue the /56s from specific /48s (either in general, or per market area). In those cases we consider the /48s from which they issue the /56s to be 100% utilized. In cases that
the ISP chooses to only assign /56s to customers, we consider any /56 they assign to a customer 100% utilized.</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">Warm regards,</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">Richard Jimmerson</font></div>
</div>
<div><font face="Calibri,sans-serif">CIO & Interim Director of Registration Services</font></div>
<div><font face="Calibri,sans-serif">American Registry for Internet Numbers</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>><br>
<span style="font-weight:bold">Date: </span>Friday, October 9, 2015 at 12:04 PM<br>
<span style="font-weight:bold">To: </span>Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>Can ARIN staff please comment?</div>
<div><br>
</div>
<div>If an ISP give out a mix of /48 and /56 which of the following is true:</div>
<div><br>
</div>
<div>A. each unique customer end site given a /56 counts as a single /56 at</div>
<div>100% utilized</div>
<div> and each unique customer end site given a /48 counts as 256 /56s</div>
<div>at 100% utilized</div>
<div><br>
</div>
<div>B. each unique customer end site given a /56 counts as a single /56 at</div>
<div>100% utilized</div>
<div> and each unique customer end site given a /48 counts as one /56</div>
<div>at 100% utilization</div>
<div> unless there is specific justification why each /48 customer</div>
<div>needs more than 256 /64s</div>
<div><br>
</div>
<div>If B, then how strong does said justification have to be for example</div>
<div>do any of the following work:</div>
<div><br>
</div>
<div>1. We give all customers of type X a /56 and of type Y a /48.</div>
<div>2. all customers with a /48 said a /56 wasn't enough</div>
<div>3. we give /56 or /48 based on which box they check on the install survey</div>
<div>4. customer xyz said they plan to have 300 subnets in the next 10 years,</div>
<div> customer abc said they have 16 sub-nets per building,</div>
<div> each build is 4 geographical zones, and each zone has 4</div>
<div>subnets, student, staff, guest, wifi</div>
<div> They have 20 buildings</div>
<div> customer def said ...</div>
<div><br>
</div>
<div>___Jason</div>
<div><br>
</div>
<div><br>
</div>
<div>On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>On Oct 8, 2015, at 9:43 AM, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>> wrote:</div>
<div><br>
</div>
<div>Owen,</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>You left out the part where you have to justify issuing that many /56s to each of those large customers.</div>
</blockquote>
</blockquote>
<div><br>
</div>
<div>I believe if an ISP gives N number of /64s to a single end-site</div>
<div>transit customer, so long a N < 65537 it is justified under ARIN</div>
<div>policy.</div>
</blockquote>
<div><br>
</div>
<div>I don’t think that is true under the policy as written.</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>So for an ISP that assigns a mix of /48 and /56 no additional</div>
<div>justification is required to count all of the /56s given to a /48</div>
<div>sized customer.</div>
</blockquote>
<div><br>
</div>
<div>That is not the way the policy is written. Staff may be misinterpreting it that</div>
<div>way (wouldn’t be the first time), but that is not the way it is written.</div>
<div><br>
</div>
<div>The PAU is the unit of measure for ALL of your utilization. You get a blanket</div>
<div>justification for up to a /48 as your PAU, but if you choose a smaller PAU, then</div>
<div>you have to justify any site issued more than one PAU based on its need for</div>
<div>more than one PAU.</div>
<div><br>
</div>
<div>Owen</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div><br>
</div>
<div>6.5.4. Assignments from LIRs/ISPs</div>
<div><br>
</div>
<div>Assignments to end users shall be governed by the same practices</div>
<div>adopted by the community in section 6.5.8 except that the requirements</div>
<div>in 6.5.8.1 do not apply.</div>
<div><br>
</div>
<div>6.5.8.2. Initial assignment size</div>
<div><br>
</div>
<div>Organizations that meet at least one of the initial assignment</div>
<div>criteria above are eligible to receive an initial assignment of /48.</div>
<div><br>
</div>
<div><br>
</div>
<div>I think the final point that you agree with is the meet of the</div>
<div>proposal... you don't get to count any utilization by customers if</div>
<div>they take smaller than a /56.</div>
<div><br>
</div>
<div>__Jason</div>
<div><br>
</div>
<div>__Jason</div>
<div><br>
</div>
<div>On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>On Oct 7, 2015, at 10:00 PM, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>> wrote:</div>
<div><br>
</div>
<div>I'm not sure I follow the impact of the change here.</div>
<div><br>
</div>
<div>Under current policy if an ISP assigns only /48s to each customer, then I</div>
<div>count the number of customer and consider than many /48s as fully utilized.</div>
<div><br>
</div>
<div>Under current policy if an ISP assigns only /56s to each customer, then I</div>
<div>count the number of customer and consider than many /56s as fully utilized.</div>
<div><br>
</div>
<div>Under current policy if an ISP assigns a mix of /48s to each large customer,</div>
<div>and /56s to each small customer</div>
<div>then I count the number of small customer and consider than many /56s as</div>
<div>fully utilized and,</div>
<div>I count the number of large customers time 256 and count that many /56s as</div>
<div>fully used.</div>
<div>(this means unused /56s out of a /48 are counted against you thus</div>
<div>discouraging mixed sizes).</div>
<div><br>
</div>
<div><br>
</div>
<div>You left out the part where you have to justify issuing that many /56s to</div>
<div>each of those large customers.</div>
<div><br>
</div>
<div>Under current policy if an ISP assigns only /60s to each customer, then I</div>
<div>count the number of customer and consider that number divided by 16 as the</div>
<div>number of /56s as fully utilized.</div>
<div><br>
</div>
<div><br>
</div>
<div>Well, actually, you just count everything as /60s in this case under current</div>
<div>policy.</div>
<div><br>
</div>
<div>Under the proposed policy only the last case changes.</div>
<div><br>
</div>
<div>Under the proposed policy if an ISP assigns only /60s to each customer, then</div>
<div>those customers having a /60 (smaller than a /56) are not counted as</div>
<div>utilized by the ISP.</div>
<div><br>
</div>
<div><br>
</div>
<div>Correct.</div>
<div><br>
</div>
<div>Owen</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Is that correct?</div>
<div><br>
</div>
<div>In general I am not opposed to discouraging ISPs from giving out smaller</div>
<div>than a /56, unless the customer specifically requests a small block.</div>
<div><br>
</div>
<div><br>
</div>
<div>___Jason</div>
<div><br>
</div>
<div><br>
</div>
<div>On Mon, Sep 28, 2015 at 11:35 AM, John Springer <<a href="mailto:springer@inlandnet.com">springer@inlandnet.com</a>></div>
<div>wrote:</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>Thanks, Matt</div>
<div><br>
</div>
<div>This is precisely the subject on which I hoped to get community feedback.</div>
<div><br>
</div>
<div>John Springer</div>
<div><br>
</div>
<div><br>
</div>
<div>On Sat, 26 Sep 2015, Matthew Petach wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>OPPOSED</div>
<div><br>
</div>
<div>How I subdivide and allocate addresses</div>
<div>internally and downstream is not a matter</div>
<div>for the community to vote on; that's between</div>
<div>me and my customers.</div>
<div><br>
</div>
<div>Matt</div>
<div><br>
</div>
<div><br>
</div>
<div>On Wed, Sep 23, 2015 at 1:54 PM, ARIN <<a href="mailto:info@arin.net">info@arin.net</a>> wrote:</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>Draft Policy ARIN-2015-10</div>
<div>Minimum IPv6 Assignments</div>
<div><br>
</div>
<div>On 17 September 2015 the ARIN Advisory Council (AC) accepted</div>
<div>"ARIN-prop-224</div>
<div>Minimum IPv6 Assignments" as a Draft Policy.</div>
<div><br>
</div>
<div>Draft Policy ARIN-2015-10 is below and can be found at:</div>
<div><a href="https://www.arin.net/policy/proposals/2015_10.html">https://www.arin.net/policy/proposals/2015_10.html</a></div>
<div><br>
</div>
<div>You are encouraged to discuss the merits and your concerns of Draft</div>
<div>Policy 2015-10 on the Public Policy Mailing List.</div>
<div><br>
</div>
<div>The AC will evaluate the discussion in order to assess the conformance</div>
<div>of this draft policy with ARIN's Principles of Internet Number Resource</div>
<div>Policy as stated in the PDP. Specifically, these principles are:</div>
<div><br>
</div>
<div> * Enabling Fair and Impartial Number Resource Administration</div>
<div> * Technically Sound</div>
<div> * Supported by the Community</div>
<div><br>
</div>
<div>The ARIN Policy Development Process (PDP) can be found at:</div>
<div><a href="https://www.arin.net/policy/pdp.html">https://www.arin.net/policy/pdp.html</a></div>
<div><br>
</div>
<div>Draft Policies and Proposals under discussion can be found at:</div>
<div><a href="https://www.arin.net/policy/proposals/index.html">https://www.arin.net/policy/proposals/index.html</a></div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Communications and Member Services</div>
<div>American Registry for Internet Numbers (ARIN)</div>
<div><br>
</div>
<div><br>
</div>
<div>## * ##</div>
<div><br>
</div>
<div><br>
</div>
<div>Draft Policy ARIN-2015-10</div>
<div>Minimum IPv6 Assignments</div>
<div><br>
</div>
<div>Date: 23 September 2015</div>
<div><br>
</div>
<div>Problem Statement:</div>
<div><br>
</div>
<div>ISPs may believe that they have an incentive to obtain smaller blocks</div>
<div>than</div>
<div>they really need, and once they receive their allocation may</div>
<div>subsequently</div>
<div>issue blocks smaller than their customers may need in the future. This</div>
<div>policy seeks to encourage the correct behavior by reiterating the</div>
<div>smallest</div>
<div>reasonable sub-allocation size and by discounting any space which has</div>
<div>been</div>
<div>subdivided more finely from any future utilization analysis.</div>
<div><br>
</div>
<div>Policy statement:</div>
<div><br>
</div>
<div>Modify section 2.15 from "When applied to IPv6 policies, the term</div>
<div>"provider</div>
<div>assignment unit" shall mean the prefix of the smallest block a given ISP</div>
<div>assigns to end sites (recommended /48)." to "When applied to IPv6</div>
<div>policies,</div>
<div>the term "provider assignment unit" shall mean the prefix of the</div>
<div>smallest</div>
<div>block a given ISP assigns to end sites. A /48 is recommended as this</div>
<div>smallest block size. In no case shall a provider assignment unit for the</div>
<div>purpose of this policy be smaller than /56."</div>
<div><br>
</div>
<div>Modify section 2.16.1 from "A provider assignment unit shall be</div>
<div>considered</div>
<div>fully utilized when it is assigned to an end-site" to "A provider</div>
<div>assignment</div>
<div>unit shall be considered fully utilized when it is assigned in full (or</div>
<div>as</div>
<div>part of a larger aggregate) to a single end-site. If a provider</div>
<div>assignment</div>
<div>unit (which shall be no smaller than /56) is split and assigned to</div>
<div>multiple</div>
<div>end-sites that entire provider assignment unit shall be considered NOT</div>
<div>utilized."</div>
<div><br>
</div>
<div>Comments:</div>
<div>Timetable for implementation: IMMEDIATE</div>
<div>_______________________________________________</div>
<div>PPML</div>
<div>You are receiving this message because you are subscribed to</div>
<div>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</div>
<div>Unsubscribe or manage your mailing list subscription at:</div>
<div><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></div>
<div>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div>
<div><br>
</div>
</blockquote>
<div>_______________________________________________</div>
<div>PPML</div>
<div>You are receiving this message because you are subscribed to</div>
<div>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</div>
<div>Unsubscribe or manage your mailing list subscription at:</div>
<div><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></div>
<div>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
<div>_______________________________________________</div>
<div>PPML</div>
<div>You are receiving this message because you are subscribed to</div>
<div>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</div>
<div>Unsubscribe or manage your mailing list subscription at:</div>
<div><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></div>
<div>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>--</div>
<div>_______________________________________________________</div>
<div>Jason <a href="mailto:Schiller|NetOps|jschiller@google.com|571-266-0006">Schiller|NetOps|jschiller@google.com|571-266-0006</a></div>
<div><br>
</div>
<div>_______________________________________________</div>
<div>PPML</div>
<div>You are receiving this message because you are subscribed to</div>
<div>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</div>
<div>Unsubscribe or manage your mailing list subscription at:</div>
<div><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></div>
<div>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>--</div>
<div>_______________________________________________________</div>
<div>Jason <a href="mailto:Schiller|NetOps|jschiller@google.com|571-266-0006">Schiller|NetOps|jschiller@google.com|571-266-0006</a></div>
</blockquote>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-- </div>
<div>_______________________________________________________</div>
<div>Jason <a href="mailto:Schiller|NetOps|jschiller@google.com|571-266-0006">Schiller|NetOps|jschiller@google.com|571-266-0006</a></div>
<div>_______________________________________________</div>
<div>PPML</div>
<div>You are receiving this message because you are subscribed to</div>
<div>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</div>
<div>Unsubscribe or manage your mailing list subscription at:</div>
<div><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></div>
<div>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>