> On Aug 17, 2017, at 13:49 , Paul McNary <pmcn...@cameron.net> wrote: > > Sorry I typed the numbers backwards, yes, that is what I meant. :-) > > A /48 is smaller than a /47 and would not be required to be registered? > A /47 would need to be >
That is correct as the current state of the proposal stands. Owen > > On 8/17/2017 1:30 PM, Chris Woodfield wrote: >> The opposite - a /47 is 2 /48s aggregated. >> >> -C >> >>> On Aug 17, 2017, at 11:26 AM, Paul McNary <pmcn...@cameron.net> wrote: >>> >>> A /47 is smaller than a /48 and would not be required to be registered? >>> >>> >>> On 8/17/2017 12:50 PM, hostmas...@uneedus.com wrote: >>>> I note that any ISP size reassignment, with the recommended /48 for each >>>> end user site, will be /47 or larger, which must always be registered. >>>> >>>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment >>>> will be large enough to already trigger registration. >>>> >>>> Under the current policy, LIR's and ISP's are equal, so usually both terms >>>> are stated in any policy that mentions them. >>>> >>>> May I also suggest that if we are going to require registration upon >>>> downstream request for IPv6, that we consider placing the same language >>>> and requirements for IPv4 customers as well? And if we do, where do we >>>> draw the minimum line? Maybe a /32.... >>>> >>>> Also, good catch on the cut and paste error..... >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> On Thu, 17 Aug 2017, Leif Sawyer wrote: >>>> >>>>> Thanks for the feedback, David. >>>>> >>>>> I've added the fix for 6.5.5.2, since we're already in the section. >>>>> >>>>> I've also modified the text for 6.5.5.4 as well, because I think your >>>>> suggesting is a little cleaner. >>>>> >>>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating >>>>> 6.5.5.1. >>>>> That said, we could potentially clean up 6.5.5.1 by extending "static >>>>> IPv6 assignment" >>>>> to "static IPv6 assignment, or allocation," - or something similar. >>>>> >>>>> >>>>> Which also brings to mind the question: LIR or ISP? Both are in use in >>>>> 6.5.... >>>>> >>>>> ________________________________ >>>>> From: ARIN-PPML [arin-ppml-boun...@arin.net] on behalf of David Farmer >>>>> [far...@umn.edu] >>>>> Sent: Thursday, August 17, 2017 8:53 AM >>>>> To: hostmas...@uneedus.com >>>>> Cc: arin-ppml@arin.net >>>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization >>>>> of Assignment Registration requirements between IPv4 and IPv6 >>>>> >>>>> [External Email] >>>>> >>>>> Here is a slightly different formulation to consider. I refactored the >>>>> title a little, and based the phrasing on other parts of section 6.5.5 >>>>> >>>>> 6.5.5.4 Registration Requested by Recipient >>>>> >>>>> If requested by the downstream recipient of a block, each static IPv6 >>>>> assignment containing a /64 or more addresses, shall be registered, as >>>>> described in section 6.5.5.1. >>>>> >>>>> I'd like us to think about adding an additional section, based on >>>>> previous discussions. >>>>> >>>>> 6.5.5.5 Re-allocation to ISPs >>>>> >>>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended >>>>> for further assignment by the downstream ISP's to it's customers, shall >>>>> be registered, as described in section 6.5.5.1 >>>>> >>>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I >>>>> think this is a cut and past error, I think the reference should be to >>>>> 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections >>>>> 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >>>>> >>>>> Thanks. >>>>> >>>>> On Wed, Aug 16, 2017 at 6:10 AM, >>>>> <hostmas...@uneedus.com<mailto:hostmas...@uneedus.com>> wrote: >>>>> I am in favor of the draft, with or without the changes to make it >>>>> clearer. >>>>> >>>>> I suggest the following language for clarity: >>>>> >>>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM >>>>> that reads "If the downstream recipient of a static assignment of /64 or >>>>> more addresses requests publishing of that static assignment in ARIN's >>>>> registration database, the ISP must register that static assignment." >>>>> >>>>> Since "static assignment" is the term in this section, not netblock, I >>>>> suggest using this term instead of "netblock". "Of any size" is not >>>>> needed, as the language would require the ISP to register in total >>>>> whatever size the ISP has assigned to the downstream in the ARIN database >>>>> if requested by the downstream recipient, as long as it was /64 or more. >>>>> >>>>> This language would also prevent requests to register only part of an >>>>> assignment. I think this language works in making the intent of the new >>>>> section more clear. >>>>> >>>>> Albert Erdmann >>>>> Network Administrator >>>>> Paradise On Line Inc. >>>>> >>>>> >>>>> >>>>> On Tue, 15 Aug 2017, John Santos wrote: >>>>> >>>>> I think that the "/64 or more addresses" and the "regardless of size" are >>>>> meant to convey that any netblock between a /64 and a /48 can and should >>>>> be registered if the recipient requests it, even if the block is smaller >>>>> than the /47 which would make it mandatory. Perhaps there is better >>>>> wording that would make this clearer. >>>>> >>>>> Three ranges: >>>>> >>>>> 1. smaller than /64: shouldn't be issued, can't be registered. >>>>> 2. /64 through /48: register at recipient's request >>>>> 3. /47 or larger: must be registered >>>>> >>>>> I agree on dynamic assignments >>>>> >>>>> Otherwise, I think this is a much clearer and better update to the >>>>> proposed policy, and can't find any other reason not to support it. >>>>> (I.E. this is a tentative vote FOR, if there is such a thing.) >>>>> >>>>> >>>>> >>>>> On 8/15/2017 3:59 PM, David Farmer wrote: >>>>> I support what I think is the intent, but I have language/editorial nits; >>>>> >>>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of >>>>> size" that requires registration? I think logically we need one or the >>>>> other, or some qualification on "regardless of size" statement. I think >>>>> it is a good idea to not require registration of less than a /64. But >>>>> the current language seems contradictory, and therefore confusing, my >>>>> recommendation is delete "regardless of size", from the sentence and >>>>> leaving "a /64 or more addresses". I pretty sure we don't want people >>>>> having an expectation that they can request the registration of "their" >>>>> /128 address. >>>>> >>>>> 2. Also in 3) below; It would seem to require even dynamic assignments be >>>>> registered if requested, I don't think that is our intent either, section >>>>> 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs >>>>> a similar qualification. >>>>> >>>>> Also, I'm fine with the deltas in the policy statement but it would be >>>>> helpful to see the final resulting policy block, maybe in a separate >>>>> email so we can all see how the result reads. >>>>> >>>>> Thanks, I think we are getting close, maybe one or two more turns of the >>>>> crank. >>>>> >>>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >>>>> <i...@arin.net<mailto:i...@arin.net> >>>>> <mailto:i...@arin.net<mailto:i...@arin.net>>> wrote: >>>>> >>>>> The following has been revised: >>>>> >>>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>>>> Registration requirements between IPv4 and IPv6 >>>>> >>>>> Revised text is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2017_5.html<https://www.arin.net/policy/proposals/2017_5.html> >>>>> <https://www.arin.net/policy/proposals/2017_5.html<https://www.arin.net/policy/proposals/2017_5.html>> >>>>> >>>>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). >>>>> Specifically, these principles are: >>>>> >>>>> * Enabling Fair and Impartial Number Resource Administration >>>>> * Technically Sound >>>>> * Supported by the Community >>>>> >>>>> The PDP can be found at: >>>>> https://www.arin.net/policy/pdp.html<https://www.arin.net/policy/pdp.html> >>>>> <https://www.arin.net/policy/pdp.html<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<https://www.arin.net/policy/proposals/index.html> >>>>> <https://www.arin.net/policy/proposals/index.html<https://www.arin.net/policy/proposals/index.html>> >>>>> >>>>> Regards, >>>>> >>>>> Sean Hopkins >>>>> Policy Analyst >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> >>>>> >>>>> Problem Statement: >>>>> >>>>> Current ARIN policy has different WHOIS directory registration >>>>> requirements for IPv4 vs IPv6 address assignments. IPv4 >>>>> registration is triggered for an assignment of any address block >>>>> equal to or greater than a /29 (i.e., eight IPv4 addresses). In >>>>> the case of IPv6, registration occurs for an assignment of any >>>>> block equal to or greater than a /64, which constitutes one entire >>>>> IPv6 subnet and is the minimum block size for an allocation. >>>>> Accordingly, there is a significant disparity between IPv4 and >>>>> IPv6 WHOIS registration thresholds in the case of assignments, >>>>> resulting in more work in the case of IPv6 than is the case for >>>>> IPv4. There is no technical or policy rationale for the disparity, >>>>> which could serve as a deterrent to more rapid IPv6 adoption. The >>>>> purpose of this proposal is to eliminate the disparity and >>>>> corresponding adverse consequences. >>>>> >>>>> Policy statement: >>>>> >>>>> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to >>>>> strike "/64 or more addresses" and change to "/47 or more >>>>> addresses, or subdelegation of any size that will be individually >>>>> announced," >>>>> >>>>> and >>>>> >>>>> 2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the >>>>> NRPM by deleting the phrase "holding /64 and larger blocks" >>>>> >>>>> and >>>>> >>>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>>>> the NRPM that reads "If the downstream recipient of a netblock ( a >>>>> /64 or more addresses) requests publishing in ARIN's registration >>>>> database, the ISP must register the netblock, regardless of size." >>>>> >>>>> Comments: >>>>> >>>>> a. Timetable for implementation: Policy should be adopted as >>>>> soon as possible. >>>>> >>>>> b. Anything else: >>>>> >>>>> Author Comments: >>>>> >>>>> IPv6 should not be more burdensome than the equivalent IPv4 >>>>> network size. Currently, assignments of /29 or more of IPv4 space >>>>> (8 addresses) require registration. The greatest majority of ISP >>>>> customers who have assignments of IPv4 space are of a single IPv4 >>>>> address which do not trigger any ARIN registration requirement >>>>> when using IPv4. This is NOT true when these same exact customers >>>>> use IPv6, as assignments of /64 or more of IPv6 space require >>>>> registration. Beginning with RFC 3177, it has been standard >>>>> practice to assign a minimum assignment of /64 to every customer >>>>> end user site, and less is never used. This means that ALL IPv6 >>>>> assignments, including those customers that only use a single IPv4 >>>>> address must be registered with ARIN if they are given the minimum >>>>> assignment of /64 of IPv6 space. This additional effort may >>>>> prevent ISP's from giving IPv6 addresses because of the additional >>>>> expense of registering those addresses with ARIN, which is not >>>>> required for IPv4. The administrative burden of 100% customer >>>>> registration of IPv6 customers is unreasonable, when such is not >>>>> required for those customers receiving only IPv4 connections. >>>>> >>>>> -- >>>>> John Santos >>>>> Evans Griffiths & Hart, Inc. >>>>> 781-861-0670 ext 539<tel:781-861-0670%20ext%20539> >>>>> >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List >>>>> (ARIN-PPML@arin.net<mailto:ARIN-PPML@arin.net>). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml<http://lists.arin.net/mailman/listinfo/arin-ppml> >>>>> Please contact i...@arin.net<mailto:i...@arin.net> if you experience any >>>>> issues. >>>>> >>>>> >>>>> >>>>> -- >>>>> =============================================== >>>>> David Farmer Email:far...@umn.edu<mailto:email%3afar...@umn.edu> >>>>> Networking & Telecommunication Services >>>>> Office of Information Technology >>>>> University of Minnesota >>>>> 2218 University Ave SE Phone: 612-626-0815 >>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>>> =============================================== >>>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact i...@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@arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
