I suspect that is the intent, but as I read the policy, I believe the actual effect would be to cause the PAU to be counted as a /56 no matter how small a block you stuck your downstreams with.
The current language already makes the PAU the smallest block you issue and requires you to justify all space issued to customers in units of that smallest size. The changes to 2.16.1 do seem to create a situation where allocations smaller than /56 cannot be counted for utilization at all. It also opens the flood gates for assigning multiple PAUs to a site without requiring any justification for the multiple PAUs vs. a single one. As such, I believe the text as written is actually contrary to solving the stated problem description is it allows (for example) an ISP to decide that their PAU is /56, issue /56s to customers that they want to treat as second-class citizens, and issue /48s to their higher paying customers without any additional justification for the larger blocks (or even something larger than a /48), thus eliminating the incentives codified into the original policy that require an ISP to treat all end-sites roughly the same or provide strong justification for the allocations and assignments that are larger than the smallest ones. I remain opposed to the policy on that basis. I would not be opposed to a policy which met the stated intent of this policy, but as currently written, I do not believe this proposal does so. Owen > On Sep 25, 2015, at 20:48 , Mike Hammett <[email protected]> wrote: > > Is this policy codifying that a /56 is the minimum acceptable assignment to > an end-user and that if I assign less, I'm not allowed to come back to the > IPv6 tough until I've filled up my space with whatever smaller than /56 > allocations I decide to make? Not saying right or wrong, just seeking > clarification. > > Maybe it's more appropriate under a different group than policy, but I'm new > here, so this is the best spot I've seen so far (other than maybe > ARIN-2015-1). Anything about X-Small ISPs and initial IPv6 allocations for > them in the works? I know of many ISPs (personally, I know of dozens, though > I'm sure several hundred of them exist in NA) that are X-small under IPv4 and > don't have any IPv6 due to the added expense of moving up to small. yeah, > it's not a large sum of money, but with increasing regulatory and network > burdens, "bonus" areas like IPv6 are cast aside. Smaller blocks, smaller > fees, I dunno, I'll let someone else figure out what's best there. Just > trying to find ways of getting the little guys represented and brought into > IPv6. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com <http://www.ics-il.com/> > > <https://www.facebook.com/ICSIL> > <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> > <https://www.linkedin.com/company/intelligent-computing-solutions> > <https://twitter.com/ICSIL> > > Midwest Internet Exchange > http://www.midwest-ix.com <http://www.midwest-ix.com/> > > <https://www.facebook.com/mdwestix> > <https://www.linkedin.com/company/midwest-internet-exchange> > <https://twitter.com/mdwestix> > From: "ARIN" <[email protected]> > To: [email protected] > Sent: Wednesday, September 23, 2015 3:54:13 PM > Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments > > 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 ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected] > <mailto:[email protected]>). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > <http://lists.arin.net/mailman/listinfo/arin-ppml> > Please contact [email protected] <mailto:[email protected]> if you experience any > issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
