Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Thu, 11 Apr 2019 13:26:59 +0200,
Alexandre Petrescu <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.

--
JINMEI, Tatuya

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux