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

[hostmaster at uneedus.com]

First of all, ALL changes to v4 have been withdrawn from this proposal. 
This proposal is ONLY about v6.  Currently ALL v6 requires SWIP (/64 or 
more) and this is unequal with v4 that has an 8 or more address standard 
for SWIP.

I think that drawing the SWIP boundary for IPv6 based upon residential/non 
residential (NRPM 2.13) is wrong, as this is NOT done in IPv4 and would 
treat v6 and v4 differently.  Currently in v4, it is 8 or more addresses. 
Residential or Non Residential does not change the SWIP requirement in 
IPv4 in any way.

Thus, whatever boundary is chosen for v6, I think it should be a fixed 
value, just like in IPv4.  I would like to hear the exact reasons why it 
has been proposed that there should be a residential/non residential 
difference in SWIP policy, and what this difference in policy is meant to 
address.  If it is a valid reason, this should carry over to IPv4.

Some commenters have suggested that routeability should be a factor in 
determining if SWIP is needed.  In IPv4, it is not possible to route 
anything smaller than a /24, but the current SWIP v4 standard is /29 or 
more, much smaller than the routability standard.  In IPv6, nothing 
smaller than a /48 is routable, so I kinda think that IPv4 /29 is very 
close to equal to IPv6 more than a /56, and also not independently 
routable.

The comments I have been watching have strongly supported setting the SWIP 
level for IPv6 at more than a /56.  This is only one nibble away from /60 
in the current proposal. I also note that it seems quite universal that 
most commenters think that a /64 is wrong, and everyone, even dynamic 
residential customers deserve to have at least a /60 so that they can 
route packets in v6.

Albert Erdmann
Network Administrator
Paradise On Line Inc.




On Tue, 11 Jul 2017, Owen DeLong wrote:

>
>> On May 30, 2017, at 06:41 , William Herrin <bill at herrin.us> wrote:
>>
>> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin <oroberts at bell.ca <mailto:oroberts at bell.ca>> wrote:
>> Hello all,
>>
>> I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical.
>>
>> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos.
>>
>> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped.
>>
>> That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage.
>>
>> Howdy,
>>
>> I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO.
>
> This is one of those rare occasions when I absolutely agree with Bill. If we’re going to do this, I would support a requirement as follows:
>
> 	1.	For customers fitting the definition in NRPM 2.13, /47 or shorter.
> 	2.	For customers not fitting the definition in NRPM 2.13 /63 or shorter.
>
>> Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong.
>
> Yes… The only place I can imagine assigning /64s to customers as a legitimate practice is for single-LAN datacenter installations where the customer has no router.
>
> If the customer might have a router, a /48 is the best and safest default choice and shorter should be possible with reasonable justification.
>
> Owen
>
>