Re: about violation of standards

[Yucel Guven <[e-mail]>]

 Yes, it is:  64 - 10 = 54, and 2^54= 18,014,398,509,481,984 prefixes, not
even 2^48.

 Too much space is allocated/reserved. That's what I think.

 Wasted or not is a different seperate subject, time will show the answer.

 I can not know what the writers of RFC4291 thought or design or plan.
 I'm sure they made much more detailed calculations.

 What I clearly understand is that first 10 bits are fixed, and 54 bits are
0,
 and using fe80:1::2 on an interface does not comply with it.

 We should be open to the discussion of updating 4291, that's why we have
draft docs.

On Wed, Apr 24, 2019 at 4:42 PM Alexandre Petrescu <
[e-mail]> wrote:

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