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