Re: about violation of standards

[Gyan Mishra <[e-mail]>]

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