Le 11/04/2019 à 17:21, 神明達哉 a écrit :
At Thu, 11 Apr 2019 13:26:59 +0200,
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>> wrote:
> Others reported openbsd to work ok with Interface ID of length different
> than 64. Because of that report, I believe openbsd will also work ok
> with fe80:1::1/32.
I guess you mean this thread:
https://mailarchive.ietf.org/arch/msg/ipv6/2dnG1_yJON6zpGKz7YRWgI55iMc
It's a big logical leap to conclude that fe80:1::1(/32) can be used as
a link-local address from that discussion. First, it's quite clear
that it's largely about generating global addresses. In fact, the
implementor actually clarified that "/64" is used for link-local
addresses:
https://mailarchive.ietf.org/arch/msg/ipv6/WetxgYx-kJ1p4xUZbFxf6BikEks
Secondly, even if this could be interpreted as if this implementation
allows 96-bit IIDs for link-local addresses, that doesn't mean it can
use a non-0 bit in the (now 22-bit) intermediate field. At best it
can only mean "fe80:1::1/10" (using a 118-bit interface ID) would be
allowed.
I'd strongly suggest when you say something like this:
> - using fe80::/10 on Cisco, linux and openbsd works ok.
you confirm it literally "works" by running it by yourself, rather
than just deducing a conclusion from someone else's word in a
different topic in your favor. Otherwise your other assertions will
look similarly implausible.
Anyway, as ipv6-over-80211ocb now seems to be removing the possibly
misleading text of "fe80::/10" intending to allow a non-0 value in the
intermediate 54 bits of link-local addresses, I have no more comment
on this in this thread. I'll stop here.
I agree with the comments on your email. NExt time I talk about
implementations I do, not deduced from others' tests.
The text now indeed removes fe80::/10.
Alex
--
JINMEI, Tatuya
