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

[Fernando Gont <[e-mail]>]

On 06/14/2017 10:49 AM, Lorenzo Colitti wrote:
> On Wed, Jun 14, 2017 at 5:28 AM, Brian E Carpenter
> <[e-mail] <mailto:[e-mail]>> wrote:
[....]
>     > 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.

Even if one were to keep the "MUST be /64" for SLAAC, RFC4291 should be
clear that for non-slaac you should be free to use whatever you please
(whether manual or DHCPv6).



>     > 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.

Why should the IID depend on ipv6-over-foo dcuments? We don't recommend
to embed MAC addresses in IIDs anymore.


> 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.

Then.. why do you want to force 64? :-)

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492