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

[神明達哉 <[e-mail]>]

At Wed, 10 Apr 2019 16:19:40 +0200,
Alexandre Petrescu <[e-mail]> wrote:

> Pascal, fe80::/10 is not wrong, because:
> - using fe80::/10 on OCB works ok.
> - using fe80::/10 on Cisco, linux and openbsd works ok.

Specifically what do you mean by "fe80::/10 works"?  As I noted in a
separate message, unless you use a non-0 value in the intermediate 54
bits, that's effectively the same as fe80::/64.  So I guess "fe80::/10
works" implicitly means you can use a non-0 value in the intermediate
54 bits.  And then I don't see how it (always) works for OpenBSD.  Its
input code drops such packets:

    /* Drop packets if interface ID portion is already filled. */
    if (((IN6_IS_SCOPE_EMBED(&ip6->ip6_src) && ip6->ip6_src.s6_addr16[1]) ||
        (IN6_IS_SCOPE_EMBED(&ip6->ip6_dst) && ip6->ip6_dst.s6_addr16[1])) &&
        (ifp->if_flags & IFF_LOOPBACK) == 0) {
        ip6stat_inc(ip6s_badscope);
        goto bad;
    }
(from https://github.com/openbsd/src/blob/master/sys/netinet6/ip6_input.c)

Besides, even if we we didn't know of an implementation that drops
these packets today, it doesn't guarantee future interoperability as
long as RFC4291 Section 2.5.6 so clearly specifies these bits are all
0; it wouldn't be surprising if a new implementation "abuses" this
fact in a way that is not interoperable with implementations that use
a non-0 value in these bits.  We can't simply blame that new
implementation as "broken" since it just follows the format specified
in the RFC, albeit perhaps too strictly.

So, if this ipv6-over-80211ocb spec needs to rely on the use of a
non-0 value in the intermediate 54 bits, it's not enough to say it
"works" for some existing implementations today (which is actually
already false as I explained above for the OpenBSD case).  It should
explicitly make an exception to this part of RFC4291, rather than
obscurely alluding to it with "fe80::/10", and declare that it
formerly updates RFC4291, so that any future implementation can be
surely interoperable with it.

I actually don't know if "this ipv6-over-80211ocb spec needs to rely
on the use of a non-0 value in the intermediate 54 bits", btw.  If
that's not the case, it's much safer and less controversial to just
not mention it (either in the form of "LL prefix length" or more
explicitly).  I guess that's also what others are suggesting (and I
agree with them in that sense).

--
JINMEI, Tatuya