[arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments

Thu Oct 8 20:02:07 EDT 2015

On Thu, Oct 8, 2015 at 2:59 PM, Owen DeLong <owen at delong.com> wrote:
>
>> On Oct 8, 2015, at 9:43 AM, Jason Schiller <jschiller at 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 <owen at delong.com> wrote:
>>>
>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller <jschiller at 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 <springer at 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 <info at 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 at arin.net).
>>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>> Please contact info at 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 at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at 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 at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>>
>>>
>>> --
>>> _______________________________________________________
>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

I oppose this as written, specifically 2.15.  If an ISP is going to
assign a /60 to a customer site, be it a dwelling or small business
then they have chosen to justify utilization for all customers at a
/60.

Isn't it time we finished the allocation/assignment size argument.
Pick the size you want to give to customers. Live with the fallout of
your choice.

James