[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Ken Mix]

Hello,

I'd like to register another vote in support of relaxing IPv6 SWIP requirements in 6.5.5.1 to /60, but eliminating the 4.2.3.7.1 IPv4 changes from this proposal.

Regards,

Ken Mix

-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Tuesday, May 23, 2017 12:36
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

On 18 May 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-240: 
Equalization of Assignment Registration requirements between IPv4 and 
IPv6" as a Draft Policy.

Draft Policy ARIN-2017-5 is below and can be found at:
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

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: Equalization of Assignment Registration 
requirements between IPv4 and IPv6

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. 
The policy should treat both protocols the same. 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 6.5.5.1 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 IPv4 addresses 
or 16 IPv6 /64 networks. This would treat IPv6 the same as IPv4.

Policy statement:

Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change 
to "more than a /28".

Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to 
"more than a /60".

Comments:

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.

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 
networks (IPv6 /60) or addresses (IPv4 /28) 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 currently the case, and thus, this policy needs to be changed.
_______________________________________________
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.