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

[Alexandre Petrescu <[e-mail]>]

Le 10/04/2019 à 20:19, 神明達哉 a écrit :
> At Wed, 10 Apr 2019 16:19:40 +0200, Alexandre Petrescu
> <[e-mail] <mailto:[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"?

On command line interface (CLI) of linux it is ok to add an address 
fe80:1::1/32 to an interface, and then ping a neighbor having an address 
fe80:1::2/32 on its own interface.

It works on linux, Cisco, as I tried myself.

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.

That means that any other plen for LLs, down to 10, will work.  I.e. add
an address fe80::1/10 on the interface and then ping a neighbor.

Specifically, why do you question the "fe80::/10 works" statement?  Do
you think it does not work?

(in other report, if I remember correctly, you suggested than in a
certain flavor of BSD it is impossible to assign fe80:1::1 on an interface).

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

I agree with your understanding.

I meant to say that fe80:1::/32 works as I tried it, and, by extension, 
that fe80::/10 would work as well.

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

Is the macro IN6_IS_SCOPE_EMBED bound by a number like 64 or 10?  I cant 
see the macro definition.

My claim about openbsd working with fe80:1::1/32 is a logic extension I 
make from other programmer's claim that the /64 boundary has been 
removed from openbsd.  In that email the person talks about RA with plen 
112, and GUA formed; the email mirrored from 6man, and openbsd commit 
references, are:
https://marc.info/?l=ipng&m=152141046701347&w=2
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/slaacd/engine.c#rev1.22

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

I can agree to the point of view about implementations abiding to RFC4291.

But I would like to ask the implementation whether it prefers to be 
in-line with RFC4291 (rfc4291) or with the IANA allocation (fe80::/10).

There are obviously advantages and inconvenients to both.  Why should we 
decide to be just one?

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

Not all implementations can do fe80::/1.  A situation is follows:
- linux can do fe80:1::1/32, ping ok.
- OpenBSD is debatable whether or not it accepts fe80::/10 or only
   fe80::/64.
- Cisco IOS displays fe80::/10 in its CLI.
- Windows 10 displays fe80::64bitIID%12 or some other number (it does
   not seem to be the prefix len, but the IID is 64bitlength).
- Android: someone can easily check ifcondig add fe80:1::1/32 eth0.  I
   guess, suppose it will work, since it's linux kernel.

The question can also be whether or not some OS stack should be 
corrected?  I.e. should linux be corrected to not violate, or should 
FreeBSD be corrected to agree to IANA.

It can also be whether or not there can be qualifiers such as 
'violation', or 'conformance to IPv6' are appropriate.

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

There is indeed the option of being silent about the prefix length of 
IPv6 LLs in the IPv6-over-OCB document.

There is the option of mentioning "fe80::/10", but with "Updates 4291 
section X" in the header of the 1st page.

There is the option of proving by implementation that fe80:1::1/32 on 
OCB is not harmful to others.

Each of these options has advantages and drawbacks.

Alex


> 
> -- JINMEI, Tatuya