[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
hostmaster at uneedus.com
hostmaster at uneedus.com
Wed Jul 5 04:48:18 EDT 2017
It has now been about 4 weeks since ARIN-2017-5 was last revised.
Based on the comments received, "more than a /56" is the consensus.
I ask that the AC revise the proposal to this value, so it can be further
This is the tally so far:
/56 9 votes
Any of these levels are OK - 2 votes
/60 2 votes
/61 1 vote
/57 1 vote
/53 1 vote
/49 1 vote
Paradise On Line Inc.
On Wed, 7 Jun 2017, Leif Sawyer wrote:
> That was not changed yet, as I'm still waiting for more folks to respond.
> The update was only for the removal of the IPv4 portion, as I mentioned in my previous email.
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Wednesday, June 07, 2017 11:13 AM
> To: ARIN
> 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]
> It looks like /60 still needs to be changed to /56 to reflect the consensus on PPML. Or was there some reason not to do that (yet)?
>> On Jun 7, 2017, at 11:58 AM, ARIN <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:
>> 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:
>> Draft Policies and Proposals under discussion can be found at:
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> Problem Statement:
>> 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 or less (CGnat), which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6.
>> Currently, 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.
>> IPv6 assignments are therefore treated stricter than IPv4 assignments. Policy should either treat both protocols the same, or provide incentive for the IPv6 future. A typical ISP serving residential and small business customers with both IPv4 and IPv6 would typically provide the following assignments to each customer site: /32 (one IP) of IPv4 and a /64 (one network) of IPv6. Under the current policy, that small network customer is exempt from registration for their IPv4 assignment, but the ISP would be required to register ALL IPv6 customers, even those of this smallest network size.
>> In actual fact, most ISP's that are providing their customers with a /64 or more of IPv6 space are not in fact registering this fact with ARIN, even though 18.104.22.168 clearly requires this.
>> It is my belief that these residential and small business customers should not require registration if they did not require registration for the same size IPv4 network, including routers with Vlan and other security support. and thus I propose to make the standard for registration only those customers that have more than 16 IPv6 /64 networks. This would treat IPv6 slightly better than IPv4, and provide additional encouragement for adoption.
>> Policy statement:
>> Amend 22.214.171.124 of the policy manual to strike "/64 or more" and change to "more than a /60".
>> a. Timetable for implementation:
>> Policy should be adopted as soon as possible, as the new administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. IPv6 should not be more burdensome than the equivalent IPv4 network size.
>> b. Anything else:
>> The specific sizes chosen set the point of registration for each site to more than 16 networks or addresses, so that those with 16 or less IPv6 networks (/60) have no registration requirement. This change will result in both protocols being treated exactly the same, and removes residential and small business accounts from any registration requirement with ARIN, and the burden that will create for all ISP's.
>> There are those that might argue that a residental customer will never have a need for more than a /64 of IPv6. Clearly this is false in an IOT and/or wireless world, as many routers already provide a separate address range for wired vs wireless to prevent wired hacking via the wireless space, and also may provide a guest wireless SSID apart from the one provided to the regular users of that same network. Such separation in the IPv4 world is currently done in RFC1918 space using NAT. In IPv6, the equivalent must be done with different /64 blocks. Since good security practices require use at least 2 /64 blocks for wireless and/or IOT isolation, this would require a minimum of a /60 of IPv6 space or up to 16 networks or vlans, an amount that is consistent with a residential or small business network. This type network does not trigger registration under the current IPv4 policy, and its equal should not trigger registration with ARIN based on the current IPv6 policy as is cu!
> ently the case, and thus, this policy needs to be changed.
>> 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:
>> Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
> 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:
> Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
More information about the ARIN-PPML