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 <[email protected]> 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 <[email protected]> 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 <[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. > _______________________________________________ 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.
