Re: about violation of standards

[Alexandre Petrescu <[e-mail]>]

Le 24/04/2019 à 22:53, Erik Kline a écrit :
> What prevents you from adding a directly connected route to fe80:Y::/64 
> dev <ifname_with_ifindexY>?
> 
> On my Linux workstation eno1 has ifindex 2, and I tried the following:
> 
>      ip -6 route add fe80:2::/64 dev eno1
>      ip -6 route
> 
> shows: [...]

There is no error there, so it seems fe80:2::/64 works on your linux 
workstation.

For comparing to other OSs (I maintain a list: some do, some dont), can 
I dare to ask you to check on Android.  I dont have an Android at hand. 
It would be sufficient to ifconfig eth0 add fe80:2::1/64 and re-type 
ifconfig to see whether the address appears on the interface.

> 
>      fe80::/64 dev eno1 proto kernel metric 100 pref medium
>      fe80:2::/64 dev eno1 metric 1024 pref medium
> 
> I then continued with:
> 
>      ip -6 addr add fe80:2::345/64 dev eno1 noprefixroute
>      ip -6 addr
> 
> shows:
> 
>      inet6 fe80:2::345/64 scope link noprefixroute
>         valid_lft forever preferred_lft forever
>      inet6 fe80::5bcb:c30c:c5e0:d3cf/64 scope link noprefixroute
>         valid_lft forever preferred_lft forever
> 
> and finally:
> 
>      ip -6 route get fe80:2::123
> 
> shows:
> 
>      fe80:2::123 from :: dev eno1 proto kernel src fe80:2::345 metric 
> 100 pref medium
> 
> so source address selection seems to be working as I would want it to in 
> this situation.
> 
> I'm not sure what other tests to run, but it seems like you can 
> certainly add fe80:ifindex::/64 routes to each separate device and 
> manually add your IP addresses as you wish...as least with recent Linux.

YEs, I agree.  In that way maybe some kind of waste may be avoided. (the 
waste of the 54 0 bits, if I can say so).

Alex

> 
> 
> On Wed, 24 Apr 2019 at 12:05, Yucel Guven <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>       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] <mailto:[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]>
>          > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>          >
>          >     On Thu, Apr 18, 2019 at 11:59 AM Alexandre Petrescu
>          >     <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[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]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>          >     Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>          >   
>           --------------------------------------------------------------------
>          >
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>