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
considered.
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
Albert Erdmann
Network Administrator
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:[email protected]] On Behalf Of Scott Leibrand
Sent: Wednesday, June 07, 2017 11:13 AM
To: ARIN
Cc: [email protected]
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)?
Scott
On Jun 7, 2017, at 11:58 AM, ARIN <[email protected]<mailto:[email protected]>> 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>
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>
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>
Regards,
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
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 IPv6 /64 networks. This would treat IPv6 slightly better than
IPv4, and provide additional encouragement for adoption.
Policy statement:
Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than
a /60".
Comments:
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!
rr
ently 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
([email protected]<mailto:[email protected]>).
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 [email protected]<mailto:[email protected]> if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List
([email protected]<mailto:[email protected]>).
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 [email protected]<mailto:[email protected]> if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
