Re: about violation of standards

[Gyan Mishra <[e-mail]>]

Here is an abstract thougut ...

So given BAD Unix allows you to write onto the 54 bit all 0s field not
following the standard due inability to provide those checks due to coding
complexity.

So router and switch firewall and load balancer and server can still due to
their inability to check the link local can still code whatever they want
it's just that the inter vendor interoperability may not work is the
disclaimer if not following the RFC 4291 standard.

We can all sing kum bay ah and all finally agree to disagree but all have a
consensus.

Gyan

On Mon, Apr 22, 2019, 8:16 PM Gyan Mishra <[e-mail]> wrote:

> My concern  with all this is that you have to have and show even one use
> case where 2^64  64 bits of station id is not enough bits and you need to
> encroach on the 54 bit all 0's field.
>
> Just give me one example showing me a use case that 1.84467441E+19 is
> just not big big enough.
>
> Gyan
>
> On Mon, Apr 22, 2019, 11:37 AM Yucel Guven <[e-mail]> wrote:
>
>>
>> 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 神明達哉 <[e-mail]> wrote:
>>
>>> On Thu, Apr 18, 2019 at 11:59 AM Alexandre Petrescu <
>>> [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.
>>>
>>> --
>>> JINMEI, Tatuya
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>