Re: about violation of standards

[Alexandre Petrescu <[e-mail]>]

Le 22/04/2019 à 18:37, Yucel Guven a écrit :
> 
> 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.

I do not understand the concern.

Is the concern that too much space is allocated by fe80::/10?

Or is the concern that too much space is wasted between fe80::/10 and 
fe80::/64?

I know that talking about numbers, and about waste, is a doubly-edged 
sword: one can claim either fe80::/10 or fe80::/64 is a waste.

Alex

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