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

[Lorenzo Colitti <[e-mail]>]

On Wed, Jun 14, 2017 at 5:28 AM, Brian E Carpenter <
[e-mail]> wrote:

> > Er, what? It's perfectly fine to say that the address is 128 bits long,
> and
> > that half of it is assigned to the network and half to the link.
>
> But it doesn't. It first states that the boundary between prefix
> and IID is floating, and then states that it isn't.
>

There is no contradiction here. The value is floating, but *in the current
standards*, it is set to 64 for all unicast addresses except those in ::/3.
Should we change this? No, I don't think so. Can we change this? Yes,
absolutely - all we need to do is update 4291.

> I don't see why we need new text for that. Any document that wants to use
> a
> > different value can simply update 4291.
>
> Agreed, theoretically. But simply s/required/recommended/ in 4291bis
> would be a much more elegant way of handling this.
>

In the ivory tower, maybe. In the real world, simply changing from "is" to
"should" would be a result in immediate pressure to switch to longer
interface IIDs on currently-defined link types of interest (specifically,
Ethernet and wifi).

Remember that implementations are not built based on what the standard
recommends, but on a balance between what the standard requires and what
the operator desires. (If you doubt this view, I suggest reading your
co-authors' comments.) Also remember that most implementations already
support longer-than-64 bit prefixes today.


> > We have a popular implementation that only accepts 64-bit IID lengths in
> > certain cases. Are you proposing that our implementation change or not?
>
> No. But if some new link technology comes along for which there is a good
> technical argument for, say, 60 bit interface identifiers, wouldn't you
> want to accommodate it? (I have no idea what that argument might be.)
>

It's pretty clear that if an IPv6-over-foo document comes along that says
the IID length is 60 (and correspondingly updates 4291), then in order to
to support IPv6 over foo, either our implementation would need to change,
or the parts that rely on the 64-bit IID lengths would be disabled.

As you say, we don't know whether something like this will come along, and
I don't think we should preemptively update 4291 to accommodate this. It's
hard for me to think of something you can do with 60 bits but can't do with
64 bits.