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

[Alexandre Petrescu <[e-mail]>]

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
>