Here is my take on the options below:
[...]
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 the option of being silent about the prefix length of
IPv6 LLs in the IPv6-over-OCB document.
- other recent docs are also silent about the LL prefix length; by this
silence some understand it as being variable. For example RFC7217
"Stable and Opaque IIDs for SLAAC".
- being silent about fe80::/10 (dont say "fe80::/10") does not remove
the current text reference to RFC4291 (see at the end of the email).
A reader is thus led into reading rfc4291 about LLs. That text can be
understood either as "fe80::/64" or as "fe80::/10" with 54 0 bits. It
can not be understood as fe80:1::1/32 that I use.
Should we remove the reference to RFC4291 too?
Shoulwd we replace it with a reference to IANA page that says
"fe80::/10".
There is the option of mentioning "fe80::/10", but with "Updates 4291
section X" in the header of the 1st page.
I prefer this option.
Be silent about "fe80::/10" in the running text but modify 1st page of
IPv6-over-OCB document such that:
- tell "Updates RFC4291 [*]" on the header of the 1st page,
- and "[*]: RFC4291 section 2.5.6 figure has variable-value 54bits
(instead of 0 value)" on the bottom of 1st page. There is some place
there.
If you think that this looks more like an Errata, think that an Errata
on this topic has already been filed to RFC4291. It is Errata ID 4406
available at https://www.rfc-editor.org/errata/eid4406.
The conclusion of that Errata is: "[...] The re-definition of the
link-local address would need to be driven by a draft updating RFC
4291." There is already an Internet Draft to try to update this. The
Internet Draft is draft-petrescu-6man-ll-prefix-len.
There is the option of proving by implementation that fe80:1::1/32 on
OCB is not harmful to others.
I agree with this option too. I would invite the practice inclined to
test it further. There is a small easy thing to do: try 'ifconfig eth0
add fe80:1::1/32 on a command line on Android wifi interface', and
report here whether it works or not. It would be a small step forward.
Alex
Alex
