I support this Draft Policy as re-written. I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, but was not reassured when the discussion veered to consider prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to apply for their allocations based on the idea of assigning a /48 to each 'customer' to provide room for unknown technologies, among other things. I did not wish to endanger that premise, but current language appears to moot that concern.
To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. John Springer On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer <lsaw...@gci.com> wrote: > Happy Friday, everybody. > > > > As promised, here is the latest rewrite of the draft policy below, and it > will soon be updated at: > > https://www.arin.net/policy/proposals/2017_5.html > > > > There are two changes noted in the policy statement: the first of which > reflects what seems to be the current > > consensus of the PPML regarding netblock sizing; the second is to strike > language that may be read as either restrictive > > or non-operational. > > > > ---- > > > > 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 > sub-delegation 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" > > > > 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. > > > > > > --- > > > > Leif Sawyer > > Advisory Council > > > > _______________________________________________ > 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.