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 <[email protected]> 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 [email protected] 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 <[email protected]> wrote: >>> >>>> On Oct 8, 2015, at 9:43 AM, Jason Schiller <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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 ([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]). >>>>>>> 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]). >>>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> _______________________________________________________ >>>>> Jason Schiller|NetOps|[email protected]|571-266-0006 >>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>>> >>>> >>>> -- >>>> _______________________________________________________ >>>> Jason Schiller|NetOps|[email protected]|571-266-0006 >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|[email protected]|571-266-0006 >> _______________________________________________ >> 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]). > 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]). 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.
