Re: about violation of standards

[Alexandre Petrescu <[e-mail]>]

I am happy you are open if suggestions of modification RFC4291 are made.

If ever a question should be raised on this topic here is probably about 
one being open or not open to modifications of RFC4291.

Le 18/04/2019 à 23:01, 神明達哉 a écrit :
> On Thu, Apr 18, 2019 at 11:59 AM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>  >    In private conversation this debate happened:
> 
>  >    is an implementation that uses fe80:1::2 address on an interface a
>  >    violation of standards? (RFC 4291 does not allow for '1' to be there).
> 
>  >    My point of view is that as long as that mplementation is widely used,
>  >    that is not a violation of standards.  Rather, the situation makes it
>  >    that that standard is not in agreement with implementations.
> 
> This logic doesn't make sense to me at all.  There was a very widely used
> implementation of commercial router (I don't name it as it's not my
> purpose to pick a particular vendor) that forwarded an IPv6 packet
> whose source address is link-local from one link to another link,
> instead of returning an ICMPv6 destination unreachable error, code 2,
> as specified in RFC4443.  According to that logic, this implementation
> would be considered not violating the RFC "because it's widely used";
> most people call it an implementation bug.
> 
> Regarding Linux, I'd note that link-local addresses are automatically
> generated by the system, and the generated address conforms to the
> format specified in Section 2.5.6 of RFC4291.  More specifically, its
> intermediate 54 bits are all set to 0.  Plus, as far as I know, the
> vast majority of people never bother to change the auto-generated
> link-local addresses.  In that sense the use of addresses like
> "fe80:1::2" are not really widely used, even if the implementation
> that allows its users to manually configure such addresses is widely
> used.
> 
> Almost any implementation has some weapon that allows its user to
> shoot their feet, often violating protocol standards.  An extreme case
> is a tool like bpf, with which you can send out almost any broken
> packets to the wire.  BPF is widely used tools, but as far as I know
> no one uses the existence of that tool to justify the violation of the
> standard.
> 
> 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.

I read, and I am inclined to think like you when I read it.

But that is a manner of making arguments.

A similar argument can be made like this: the Link Local addresses are 
addresses.  Any RFC that puts any particular semantic on any bits are 
violations of the fact that these are addresses.

It is argument against counter argument, ad infinitum.

But the best thing I heard today is that you are open for RFC4291 changes.

Alex
> 
> --
> JINMEI, Tatuya