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