Re: encoding link ID in link-local addrs (Re: about violation of standards)

[Alexandre Petrescu <[e-mail]>]

Le 24/04/2019 à 23:00, 神明達哉 a écrit :
> At Wed, 24 Apr 2019 17:04:59 +0200,
> Ole Troan <[e-mail] <mailto:[e-mail]>> wrote:
> 
>  > > I will add in the draft that Cisco also supports fe80:1::1.  I 
> think I forgot that, but now that you say it I trust it too.
>  > >
>  > >> I don’t see any justification to allowing the 54 bits in the 
> network 64 bit portion of the link local address to be changed from all 0s.
>  > >
>  > > I dont understand you.
>  > >
>  > > You say fe80:1::1 works on Cisco, but then you say you seee no 
> justification to allow the 54bits to change from 0.  The first 1 in 
> fe80:1::1 means a change from 0.
>  > >
>  > > So, do you mean Cisco is wrong?
>  > >
>  > > Or do you mean such things are wrong and the RFC is right?
>  >
>  > That an implementation allows you to do something does not mean that 
> it is supported (in the product sense) nor that the RFC is wrong.
> 
> Right, but I actually don't understand why we still have to have this
> kind of conversation.  Almost all real-world implementations have some
> glitch;

The problem here would be to ask which of the OSs have the glitch: the 
ones that support fe80:1:: or the ones that dont?

We dont want the loved OS to correct a non-existent bug and the 
non-loved OS to continue with the bug.

> sometimes the bug is fixed quickly, sometimes it's considered
> too minor to be prioritized and can stay longer.  It happens all the
> time.  

I agree.

> I simply don't understand why such a corner case behavior is
> discussed in the context of whether an RFC is "right".
> 
> If my previous example of broken router behavior wasn't enough,
> there's another one for the loved OS: Linux allows you to send a
> packet with the source address being ::1 outside of the sending node
> by running this script:
> 
> import socket
> s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
> s.bind(('::1', 0))
> s.sendto(b'', ('2001:db8::1', 4200))
> 
> I hope no one seriously asks whether this text of RFC4291, Section
> 2.5.3 is "right" because of that bug:
> 
>     The loopback address must not be used as the source address in IPv6
>     packets that are sent outside of a single node.
> 
> Then, can we now really stop talking about whether the RFC is right or
> wrong about the intermediate 54 bits by referring to an implementation
> that allows a user to violate it?
> 
> A bug is a bug.  If someone wants to legitimize that buggy behavior,
> make a proposal with a valid justification to update the relevant
> standard (sometimes it can actually succeed).  An attempt to make it
> valid because of the existence of the buggy behavior itself is just
> time wasting.

達哉-san,

Bugs should be corrected.  Time should not be wasted.

Alex

> 
> --
> JINMEI, Tatuya