Re: about violation of standards

[Erik Kline <[e-mail]>]

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:

    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.


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