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

[Scott Leibrand]

On Tue, May 23, 2017 at 12:02 PM, William Herrin <bill at herrin.us> 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.
>
> +1

I believe this policy, as written, is misleadingly titled.  I support the
intent expressed in the title, and support either the "more than a /60"
language or (preferentially) Bill's "more than a /56" language below for
equalizing assignment registration requirements between IPv4 and IPv6.

However, I definitely do not support also relaxing the "/29 or more"
requirement for IPv4 without a significant revision of the problem
statement to indicate why such a change is justified, and a retitling of
the proposal.  And even with those changes, I likely would not support
relaxing the "/29 or more" requirement.  For context, my employer currently
has a large number of /29 networks reassigned from our upstream transit
providers (one for each link for unique routing purposes).  Those currently
are not reassigned to us in whois (in contravention of ARIN policy), but it
would be better for us (for geolocation purposes, for example) if they were
properly reassigned.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170523/75ce5c0c/attachment.htm>