Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

[Christopher Morrow <[e-mail]>]

On Fri, Feb 24, 2017 at 4:04 AM, Erik Kline <[e-mail]> wrote:

> On 24 February 2017 at 12:41, Christopher Morrow <[e-mail]>
> wrote:
>
>> gosh people are being literal today :)
>>
>>
>> On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti <[e-mail]>
>> wrote:
>>
>>> On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow <
>>> [e-mail]> wrote:
>>>
>>>> > The IESG plans to make a decision in the next few weeks, and solicits
>>>> > final comments on this action. Please send substantive comments to the
>>>> > [e-mail] mailing lists by 2017-03-01. Exceptionally, comments
>>>> may be
>>>> > sent to [e-mail] instead. In either case, please retain the
>>>> > beginning of the Subject line to allow automated sorting."
>>>>
>>>> Nothing in the past really matters here, what matters is: "Is the bis
>>>> draft all set, did we fix all the things which must be fixed before this
>>>> draft becomes a real 'standard'?"
>>>>
>>>
>>> I don't think you can say nothing in the past matters here. We know that
>>> there have been host implementations that relied on this guarantee, and we
>>> have to consider that if we change the standard, those implementations will
>>> become non-compliant.
>>>
>>
>> I don't think the proposed (now 160+ messages back) text really says:
>> "FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64
>> because the application you are being placed into requires it (slac, blah
>> and blah and ilnp and blah - see rfc7k) then do that, else any other prefix
>> length works"
>>
>> how's that not 'ok' for host folks? "Hi, my host is going to be in a
>> slaac world.. so /64 it is!"
>>
>
> For manual assignment among consenting adults: as you like it.  (For all
> prefixes longer than /64, the trailing 64bits would still end up being
> unique; there is no real issue here.)
>
>
I agree.


> And I gather everyone agrees that at a minimum the /127 RFC and other
> working-group-graduated documents should be suitably incorporated and
> referenced.
>
>
I think that's in the proposed text, yes... or easily is a list of
[this][that][theother]


> Otherwise, this feels like another round of "why isn't IPv6 just 128bit
> IPv4?"  IMHO having /64 as the logical unit of allocation to network leaves
> is a very good thing.
>

For enduser deployment picking 'something' (/64 is perfectly fine) is
totally sane, and already in the proposed text. The sticking point isn't so
much: "ipv6 is ipv4 with  more bits" (which the network treats it as) but:
"hey, we know we allocate longer prefixes all the time for 'reasons' on
things that have bespoke config, let's not make that harder by letting
vendors/etc take shortcuts... acknowledge the fact that we really do have
interfaces with >/64 deployed.

I don't see how that damages network-ops folks, nor host-ops, nor
developers.

There is certainly a discussion for 'not this list' about networking
providers doing 'short sighted' things on their network with respect to
attached customers, but... that's not this document and not this discussion
and not this list (except as an opionion/editorial piece).