Re: draft-bourbaki-6man-classless-ipv6-00

[Brian E Carpenter <[e-mail]>]

Erik,

> The only thing meaningfully affected by removing 64bit IIDs...

But that is exactly what the draft does *not* do. Nobody would
change a single instruction in existing code as a result of this
draft. (I agree with you that some O/S stacks may need fixing, but
they already need fixing.)

Regards
   Brian

On 06/06/2017 16:26, Erik Kline wrote:
> On 6 June 2017 at 07:25, Brian E Carpenter <[e-mail]>
> wrote:
> 
>> On 05/06/2017 19:45, Lorenzo Colitti wrote:
>>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter <
>>> [e-mail]> wrote:
>>>
>>>> None of that is the point. The point is to establish
>>>> that routing is classless
>>>
>>>
>>> Routing is already classless because BCP 198.
>>>
>>>
>>>> and /64 is a parameter of specific addressing schemes.
>>>>
>>>
>>> It *is* a parameter. The parameter's value is 64 for all unicast
>> addresses
>>> except those starting with 000.
>>
>> The parameter's *current* value, yes. But should we really be fixing
>> the value of the parameter once and for all in the addressing architecture?
>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design
>> assumes?
>>
> 
> Because I doubt there is any good argument about things specific to the Foo
> layer for having something shorter than a 64 when 64 gets you many so nice
> guarantees for randomness, security and non-collision.
> 
> This document does not include a problem statement -- it doesn't say what
> problem exists that need solving.
> 
> If all this is about being able to execute the OS-specific equivalent of
> "ifconfig eth0 add 2001:db8::1/123" then I think that should absolutely
> work fine.  We should file bugs to get OS tools to understand what this
> actually means.
> 
> That, however, is completely orthogonal to 64bit IIDs.  The 64bit boundary
> pretty much only has meaning in a SLAAC context.  Not doing SLAAC?  64bit
> IIDs don't really affect to you then.  If OS's make assumptions that there
> must be some 2001:db8::/64 route when in fact 2001:db8::1/123 was specified
> then that's an obvious error.  IMHO, if /n isn't specified: use n=64 and if
> /n is specified then use /n.  Seems simple enough.  You can put a /123 PIO
> in an RA so why not on a command line.
> 
> This document however burns down the whole house for the sake of lighting a
> candle that was in fact already lit.
> 
> The only thing meaningfully affected by removing 64bit IIDs is removal of
> the last backstop that ensures network operators and users alike share --
> however unequally -- the benefits of IPv6 and it permanently demotes IPv6
> to little more than 128bit IPv4 with quaint, warty rules about fragments
> and extension headers.
>