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

Thu May 25 23:33:10 EDT 2017

I don't believe a /64 is recommended for a p2p anymore. Rfc 6164

On Thursday, May 25, 2017, Jason Schiller <jschiller at google.com> wrote:

> I don't support a relaxation of SWIP requirements for IPv4.
>
> I do support updating the language for IPv4 for clarity (if that is
> useful).
> current IPv4 language:  /29 or more
>
> possibly re-write for clarity: more than a /30.
>
>
> As far as IPv6 goes, there are some who recommend a /64 for point-to-point.
> One might argue that in the context of p-t-p an IPv4 /30 maps to a /64.
>
> I could certainly get behind SWIP requirements for "more than a /64" on
> these grounds.
>
> Please make the requirement to SWIP be on a nibble boundary.
>
>
> Nibbles being nice things, one could argue that end users are likely to
> get a /64
> or the next size up which is a /60.  If you want to catch all customers in
> the
> smallest size, you might make the boundary at "more than a /61"
>
> The next size up on the nibble boundary is a /56 putting the boundary at
> "more than a /57"
>
>
> Generally speaking any network that is sufficiently large to require
> subnetting,
> should have sufficient clue to support SWIP.  Based on this reasoning
> "more than
> a /64" seems like an equable place to draw the line.  Even "more than a
> /61"
> seems reasonable, as blocks are likely going to be assigned on nibbles.
> My next preferred choice would be "more than a /57"
>
> Also don't forget that residential users can opt out of publicly providing
> information.
>
> ___Jason
>
>
>
>
>
>
>
> On Tue, May 23, 2017 at 10:04 PM, <hostmaster at uneedus.com
> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','herrin at dirtside.com');>  bill at herrin.us
>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','info at arin.net');> if you experience any
>> issues.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com
> <javascript:_e(%7B%7D,'cvml','jschiller at google.com');>|571-266-0006
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170525/2d394bc3/attachment.htm>