Re: about violation of standards

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Jinmei San

Agreed

While I completely object with Alexandre’s argument I tend to agree with the end goal.

Some functions in the router are complex to implement because same value for a link local address appears on multiple interfaces.

It would be useful to be able to encode an abstract interface ID somewhere in the /64. Legacy 00 would mean unspecified...

All the best,

Pascal

Le 19 avr. 2019 à 02:51, 神明達哉 <[e-mail]<mailto:[e-mail]>> a écrit :

At Fri, 19 Apr 2019 02:07:20 +0200,
Fernando Gont <[e-mail]<mailto:[e-mail]>> wrote:

> [....]
> > Now, I'm open to the discussion of possibly updating RFC4291 to allow
> > non-0 value in the intermediate 54-bit field, starting from the fact
> > that it currently violates the standard.  But I don't buy an argument
> > that a behavior against the current standard is not a violation simply
> > because there's a system utility of a widely used OS that allows that
> > particular behavior.
>
> In this particular case, it would be mostly useless: such addresses not
> only violate existing standards, but also don't work with
> widely-deployed implementations. That is, you cannot safely employ them.
> As result, there's no point in trying.

I'm basically on the same page with you, but I guess some background
context helps here.  In my understanding this is a followup on a
recent int-dir review discussion on
draft-ietf-ipwave-ipv6-over-80211ocb.  In that context, (my
understanding of) the author's argument about the incompatibility with
the "widely-deployed implementations", or more specifically, BSD
variants, is that "that doesn't matter, since they only need to
legitimize this violation for a specific Linux implementation of
IPv6-over-OCB, and they don't care about BSDs since BSDs don't support
OCB" (btw I don't know if there's any BSDs that support OCB or not).
I don't buy that argument either; my response to it is this:
https://mailarchive.ietf.org/arch/msg/int-dir/_tk437U1eq6kHDE3O6c-VrUaeXw

That said, I personally wouldn't close the door immediately.  There
might be even stronger argument for the update even if that would break
some existing implementations that are currently standard-compliant.
IMO that bar should be very high, but I wouldn't say it can never be
cleared.  Sometimes even a disruptive update can be justified (like an
extreme case of some security matters).  Now that the author seems to
choose the option to try that bar, I'm now waiting for a stronger
argument than "we don't care about those existing incompatible
implementations".

--
JINMEI, Tatuya
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------