[arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
Paul McNary
pmcnary at cameron.net
Thu Aug 17 14:26:44 EDT 2017
A /47 is smaller than a /48 and would not be required to be registered?
On 8/17/2017 12:50 PM, hostmaster at 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-bounces at arin.net] on behalf of David
>> Farmer [farmer at umn.edu]
>> Sent: Thursday, August 17, 2017 8:53 AM
>> To: hostmaster at uneedus.com
>> Cc: arin-ppml at 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,
>> <hostmaster at uneedus.com<mailto:hostmaster at 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
>> <info at arin.net<mailto:info at arin.net>
>> <mailto:info at arin.net<mailto:info at 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 at arin.net<mailto:ARIN-PPML at 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 info at arin.net<mailto:info at arin.net> if you experience
>> any issues.
>>
>>
>>
>> --
>> ===============================================
>> David Farmer Email:farmer at umn.edu<mailto:Email%3Afarmer at 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 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