[arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

Wed Aug 30 13:27:32 EDT 2017

As I currently ready 6.5.5.1 there are two classes of addresses that are
required to be SWIP'd
A. any re-allocation or re-assignment that is a /47 or less specific (/46,
/45, ...)
B. any sub-deligation that will be individually announced

I recall there being a third class, any re-allocation.

A re-allocation is when I ISP provides addresses to their down stream
ISP customer who then in turn will further sub-delegate address space
to their customer (who may also be an ISP with customers... and so on).

Can I suggest a friendly amendment of:

6.5.5.1. Re-allocation / reassignment information
Each static IPv6 re-allocation, reassignment containing a /47 or more
addresses, or subdelegation
of any size that will be individually announced, ...

___Jason

On Wed, Aug 30, 2017 at 1:15 PM, Jason Schiller <jschiller at google.com>
wrote:

> The new policy (along with pre-existing text) will read as follows:
>
> 6.5.5.1. Reassignment information
> Each static IPv6 assignment containing a /47 or more addresses, or
> subdelegation
> of any size that will be individually announced, shall be registered in
> the WHOIS
> directory via SWIP or a distributed service which meets the standards set
> forth in section 3.2. Reassignment registrations shall include each
> client's
> organizational information, except where specifically exempted by this
> policy.
>
> 6.5.5.2. Assignments visible within 7 days
> All assignments shall be made visible as required in section 6.5.5.1
> within seven
> calendar days of assignment.
>
> 6.5.5.3. Residential Subscribers
> 6.5.5.3.1. Residential Customer Privacy
> To maintain the privacy of their residential customers, an organization
> with downstream
> residential customers may substitute that organization's name for the
> customer's name,
> e.g. 'Private Customer - XYZ Network', and the customer's street address
> may read
> 'Private Residence'. Each private downstream residential reassignment must
> have
> accurate upstream Abuse and Technical POCs visible on the WHOIS record for
> that
> block.
>
> 6.5.5.4  Registration Requested by Recipient
> If the downstream recipient of a static assignment of /64 or more
> addresses requests
> publishing of that assignment in ARIN's registration database, the ISP
> must register
> that assignment as described in section 6.5.5.1.
>
>
>
> On Tue, Aug 29, 2017 at 9:02 PM, <hostmaster at uneedus.com> wrote:
>
>> I think we got it this time.
>>
>> I support.
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>>
>>
>> On Tue, 22 Aug 2017, ARIN wrote:
>>
>> The following has been revised:
>>>
>>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
>>>
>>> Revised text is below and can be found at:
>>> https://www.arin.net/policy/proposals/2017_5.html
>>>
>>> Note that the Draft Policy title has changed from "Equalization of
>>> Assignment Registration requirements between IPv4 and IPv6"
>>>
>>> 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
>>>
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>>
>>> Regards,
>>>
>>> Sean Hopkins
>>> Policy Analyst
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>> Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
>>>
>>> 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.2. "Assignments visible within 7 days" of the
>>> NRPM to strike the text "4.2.3.7.1" and change to "6.5.5.1"
>>>
>>> and
>>>
>>> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM
>>> by deleting the phrase "holding /64 and larger blocks"
>>>
>>> and
>>>
>>> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
>>> NRPM, to read: "If the downstream recipient of a static assignment of /64
>>> or more addresses requests publishing of that assignment in ARIN's
>>> registration database, the ISP must register that assignment as described
>>> in section 6.5.5.1."
>>>
>>> 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.
>>> _______________________________________________
>>> 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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170830/793b15ae/attachment.htm>