[arin-ppml] ARIN-PPML 2017-6 draft policy

Rudolph Daniel rudi.daniel at gmail.com
Fri Aug 18 15:36:56 EDT 2017


" Recipient RIR policy must not permit transfers to other RIRs or NIRs
whose policies do not support bi-directional transfers."

Whereas I am in support of closing this loophole, I cannot be sure that
this is actually achievable...
rd

On Aug 17, 2017 6:01 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Re: Revised: Draft Policy ARIN-2017-5: Equalization of
>       Assignment Registration requirements between IPv4 and IPv6
>       (Paul McNary)
>    2. Draft Policy 2017-6: Improve Reciprocity Requirements for
>       Inter RIR Transfers (WOOD Alison * DAS)
>    3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of
>       Assignment Registration requirements between IPv4 and IPv6
>       (hostmaster at uneedus.com)
>    4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of
>       Assignment Registration requirements between IPv4 and IPv6
>       (David Farmer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 17 Aug 2017 15:49:47 -0500
> From: Paul McNary <pmcnary at cameron.net>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5:
>         Equalization of Assignment Registration requirements between IPv4
> and
>         IPv6
> Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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
>
>
> 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 <pmcnary at 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, 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@
> 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:ARI
> N-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.
> >>>
> >>>
> >> _______________________________________________
> >> 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.
> >>
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 17 Aug 2017 20:54:23 +0000
> From: WOOD Alison * DAS <Alison.WOOD at oregon.gov>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity
>         Requirements for Inter RIR Transfers
> Message-ID:
>         <B0CA7478A1F03F4CA96A93288751A91A01A47CF968 at WPORGEXCL10.
> ENTSS.OR.GOV>
> Content-Type: text/plain; charset="us-ascii"
>
> Thank you for the feedback on this draft policy to date.  I would
> appreciate any other thoughts or comments on this draft policy.
>
> For review, Draft Policy 2017-6 is intended to add the following
> conditions on Inter RIR transfers to section 8.4:
>
> Recipient RIR policy must not permit transfers to other RIRs or NIRs whose
> policies do not support bi-directional transfers.
>
> And the problem statement on this draft policy is:
>
> Currently ARIN's requirement that inter-RIR transfer policies be
> reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a
> two-hop RIR transfer process can be used to circumvent the intent of the
> requirement. Rather than eliminate the requirement, a better approach would
> be to close the loophole.
>
> All feedback is appreciated.
>
> Thank you
>
> -Alison Wood
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/
> attachments/20170817/22d7858b/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT)
> From: hostmaster at uneedus.com
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5:
>         Equalization of Assignment Registration requirements between IPv4
> and
>         IPv6
> Message-ID: <Pine.LNX.4.64.1708171744310.28692 at localhost.localdomain>
> Content-Type: text/plain; charset="x-unknown"; Format="flowed"
>
> While the most recent drafts have not dealt with IPv4, in the last round
> there was a proposal to require registration upon request of the
> downstream customer of their IPv6 assignment.
>
> If we intend to provide that power to require registration for IPv6
> customer assignments upon request, in fairness we should also use the same
> language in a new 4.2.3.7.4 to allow static IPv4 customers that same
> power.  I suggest /32 as the limit, as /29 or more already has required
> registration.  The same problems identfied in not being able to register
> assignments with ARIN for v6 are also true for v4 assignments between
> those limits.
>
> Since both protocols are still being addressed and attempts are being
> made by the draft to make v6 equal or better than v4, the title should
> remain.  The only thing we have done is not shift the v4 limit of /29.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> > While we???re turning the crank, can we please fix the title since IPv4
> > is no longer relevant to the proposal and there???s really no
> > equalization happening?
> >
> > Perhaps ???Improved Registration Requirements for IPv6???
> >
> > Owen
>
> ------------------------------
>
> Message: 4
> Date: Thu, 17 Aug 2017 17:01:09 -0500
> From: David Farmer <farmer at umn.edu>
> To: Leif Sawyer <lsawyer at gci.com>
> Cc: "hostmaster at uneedus.com" <hostmaster at uneedus.com>,
>         "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5:
>         Equalization of Assignment Registration requirements between IPv4
> and
>         IPv6
> Message-ID:
>         <CAN-Dau0+4ms_7V-=Y89ZavKp+DuWVHK932FBkFbURTB_rYybGQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Aug 17, 2017 at 1:43 PM, David Farmer <farmer at umn.edu> wrote:
>
> > Inline.
> >
> > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer <lsawyer at gci.com> wrote:
> >
> >> Thanks for the feedback, David.
> >>
> > ...
>
> > 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.
> >>
> >
> > ISP re-allocations need to be registered regardless of size or if it is
> > being advertised or not. For example, if for some stupid reason a /56 was
> > re-allocated to downsterm ISP so they could assign /64s to customers that
> > has to be registered, by 6.5.5.1 that wouldn't have to be registered.
> > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be
> > registered.  This is so LEA and other legal requests get directly to the
> > correct ISP the first time.  I think this is important enough issue that
> it
> > should have it's own section, and not get blended in to 6.5.5.1.
> >
> > Now should that be part of this policy maybe not, maybe this belongs in
> > ARIN-2017-3 or whole new separate policy proposal instead.
> >
>
> Thinking about this for the last couple hours I'm thinking 6.5.5.5 this
> should not be part of this policy.  As similar text should be added in the
> IPv4 section, and this should have a somewhat different problem statement
> as well.
>
> --
> ===============================================
> David Farmer               Email:farmer 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
> ===============================================
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/
> attachments/20170817/7e7a2fcd/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> ------------------------------
>
> End of ARIN-PPML Digest, Vol 146, Issue 10
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170818/4a9314b4/attachment.html>


More information about the ARIN-PPML mailing list