Le 10/04/2019 à 20:19, 神明達哉 a écrit :
At Wed, 10 Apr 2019 16:19:40 +0200, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>>
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
