Re: about violation of standards

Hi Jinmei Tatuya,

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

That is very interesting point indeed.
Do you mean that billions of people's data, information, etc...etc... from
their Link-locals
can easily be routed to somewhere that no one knows? Just because of
"that vendor" (or vendors?)
If that's the case, I really wonder about what can be done with "127.0.0.1".

Anyways, my concern is about huge amount of addresses of the fe80::/10.
There are 281,474,976,710,655 =  281 Trillion 474 Billion 976 million 710
Thousand 655 addresses
in between  fe80:0:0:0::/64  and fe80:ffff:ffff:ffff::/64.
If we just take  fe80:1::/32 or /64, then it breaks RFC4291 due to 54 zeros.

Is it right time to modify RFC4291?

On Thu, Apr 18, 2019 at 11:03 PM 神明達哉 <jinmei@wide.ad.jp> wrote:

> On Thu, Apr 18, 2019 at 11:59 AM Alexandre Petrescu <
> alexandre.petrescu@gmail.com> 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.
>
> --
> JINMEI, Tatuya
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>