Re: about violation of standards

[Yucel Guven <[e-mail]>]

Nothing prevents me, I'm sure it also works with other linux distributions.

But, do you mean that it worked in your linux,
and in fact "RFC is not compatible" with your machine's OS?

Then;
What prevents you from opening your word processor
and from proposing/writing your ideas
into a document that is called a 'draft'?



On Wed, Apr 24, 2019 at 10:54 PM Erik Kline <[e-mail]> wrote:

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