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

[Aaron Dudek]

We're doing /56 to customers. /60 if they want dynamic. Yes they get less
space if they want to change their ip.

I like Jason's suggestion.

Leave /29 alone.

Aaron


On Wednesday, May 31, 2017, Jason Schiller <jschiller at google.com> wrote:

> WRT IPv6 can we solve this by requiring all fixed IPv6 customers
> (still allowing residential privacy) to SWIP, and allow dynamic
> customers up to (and including) /56 to only SWIP the parent
> block to the residential market?
>
> We would need someone to come up with a usable definition
> of fixed and dynamic...
>
> Any statically routed network is considered fixed.
>
> Any network announced by a customer to a provider
> via a routing protocol is considered fixed.
>
> Any network provided by a provider to a customer
> with the expectation that the address will not change
> is considered fixed (even if dynamic mechanisms are
> used to provide the address)
> [excluding re-terminations and divestitures]
>
> Any network with a customer specified ip6.arpa address
> is considered fixed.
>
> Only networks provided by a dynamic mechanism such as
> DHCPv6 with a sufficiently short lease such as 1 year or less
> and no customer expectation that the address will persist if
> the lease times out may be considered dynamic.
>
> On Tue, May 30, 2017 at 9:41 AM, William Herrin <bill at herrin.us
> <javascript:_e(%7B%7D,'cvml','bill at herrin.us');>> wrote:
>
>> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin <oroberts at bell.ca
>> <javascript:_e(%7B%7D,'cvml','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.
>>
>> 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.
>>
>> 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/20170603/0b04de78/attachment.htm>