[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
Chris Woodfield
chris at semihuman.com
Thu May 25 11:25:00 EDT 2017
I’d support the relaxation of SWIP requirements for IPv6 allocations, but relaxing SWIP requirements for IPv4 does not, in my view, line up with the problem statement as the proposal is written; if the goal is equal treatment, then one should align IPv6 policy to existing v4, not change both. I’d recommend that we limit this proposal to only the 6.5.5.1 change.
Thanks,
-Chris
> On May 23, 2017, at 7:04 PM, hostmaster at uneedus.com wrote:
>
> Hello,
>
> The line has to be drawn somewhere, and the idea when I drafted this proposal was that it was wrong to treat IPv6 less favored than IPv6 as is the current case. It also bothered me that the average residential and small business account would have to go thru the SWIP process, just because they want to have a minimum or so assignment of IPv6 space for their network, when this was never a requirement for IPv4. As discussed, a /60 of v6 is much the same as a /32 of v4.
>
> I chose 16 addresses/networks as the only reasonable number to make the two protocols equal. As already discussed, 1 network is too small. If the community thinks it is wrong to relax the current IPv4 requirements, I am not opposed to removing 4.2.3.7.1 from the proposal, as long as the community is willing to do something about the "Register every network" problem that is the current policy in v6, and the changes to 6.5.5.1 that I propose.
>
> While I suggest that a /60 should not trigger registration, if the community would rather kick that up to a /56, I have no problem with this. This would seem to be the more future proof option. Of course such a change calls for a new title, maybe "New policy for IPv6 Assignment Registration", and cite it as allowing even the small networks with a /32 of IPv4 to obtain a reasonable assignment of IPv6 without registration requirements, as is the current case with IPv4.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Tue, 23 May 2017, William Herrin wrote:
>
>> On Tue, May 23, 2017 at 2:35 PM, ARIN <info at arin.net> wrote:
>>
>>> Draft Policy ARIN-2017-5: Equalization of Assignment Registration
>>> requirements between IPv4 and IPv6
>>>
>>> Policy statement:
>>>
>>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to
>>> "more than a /28".
>>>
>>
>> Hello,
>>
>> In my opinion...
>>
>> Leave /29 alone or change it to "more than a single IP address." In these
>> days of IPv4 shortage, substantial networks sit behind small blocks of
>> public addresses. These networks should be documented with reachable POCs
>> lest the anti-spam/virus/malware folks slam down /24 filters for lack of
>> information about how misbehaving networks are partitioned.
>>
>>
>>> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to
>>> "more than a /60".
>>>
>>
>> Change this to "more than a /56." Service providers should NOT be assigning
>> /64's to end users. If you're doing that, you're doing it wrong. An IPv6
>> customer should be able to have more than one /64 subnet without resorting
>> to NAT so /60 should be the absolute minimum end-user assignment,
>> equivalent for all intents and purposes to an IPv4 /32. If we then want
>> "equivalence" to the /29 policy so that individuals with the minimum and
>> near-minimum assignment do not need to be SWIPed, it makes sense to move
>> the next subnetting level up. In IPv6, assignment is strongly recommended
>> on nibble boundaries, so that means /56.
>>
>> Regards,
>> Bill Herrin
>>
>> --
>> William Herrin ................ herrin at dirtside.com bill at herrin.us
>> Dirtside Systems ......... Web: <http://www.dirtside.com/>
>>
> _______________________________________________
> 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.
>
More information about the ARIN-PPML
mailing list