[arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments
Owen DeLong
owen at delong.com
Fri Oct 9 16:11:24 EDT 2015
Sure it is… There is nothing in ARIN policy ever that has made a distinction about legacy holders
or somehow excluded them from participating in or receiving any benefit of any ARIN policy if
they sign an RSA for their new resources.
Owen
> On Oct 9, 2015, at 3:43 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>
> That is not necessarily true of the hypothetical automatic assignment discussed below
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
>> On Oct 9, 2015, at 3:38 PM, Owen DeLong <owen at delong.com> wrote:
>>
>> Every thing is already available to legacy holders if it is available to the rest of the community.
>>
>> However, for any new resources, they will have to sign an RSA and their new resources will not be legacy.
>>
>> Owen
>>
>>> On Oct 9, 2015, at 3:14 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>>>
>>> I'd support such an automatic allocation.
>>>
>>> I'd support it even more if it was made available to legacy holders.
>>>
>>> Matthew Kaufman
>>>
>>> (Sent from my iPhone)
>>>
>>>> On Oct 9, 2015, at 1:19 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>>>>
>>>>
>>>> This is all getting complex, confusing, and is still encouraging ISPs to give out less than the recommended /48 to end users.
>>>>
>>>> Why don't we just change policy so that every ISP gets an automatic IPv6 that approximates /32 IPv4 ~= /48 IPv6
>>>>
>>>> Make it automatic, and at no additional cost. Also, make it the minimum, so that all ISPs have no reason not to hand out /48s.
>>>>
>>>> If you have less than a /20, you get a /32
>>>> If you have a /20, you get a /28
>>>> If you have a /16, you get a /24
>>>> If you have a /8, you get a /16
>>>>
>>>> Basically, aggregate all of the IPv4 resources, round up to the nearest single block, add 8 bits, then round to the nearest nibble.
>>>>
>>>> If you need more, then it needs to be justified.
>>>>
>>>> I've seen several cases of ISP with 100,000s or even millions of customers that have a /32 or similar. That doesn't do anyone any good. If and when they come to their senses, the result will be even more routes in the routing table, because they will have to go back and get more.
>>>>
>>>> You could also just define the PAU as /48. The important part is that we make sure that there is no additional cost. IPv6 is plentiful enough that it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of /32, there should not be any financial impact. It is the same number of blocks.
>>>>
>>>> thanks,
>>>> -Randy
>>>>
>>>>
>>>> ----- On Oct 9, 2015, at 12:04 PM, Jason Schiller jschiller at google.com wrote:
>>>>
>>>>> 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 <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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> _______________________________________________________
>>>>> 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.
>>>> _______________________________________________
>>>> 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.
>>
More information about the ARIN-PPML
mailing list