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:01:36 +0200,
Alexandre Petrescu <[e-mail]> wrote:

> > OLD: A subnet is formed by the external 802.11-OCB interfaces of
> > vehicles that are in close range (not by their in-vehicle
> > interfaces).  This subnet MUST use at least the link-local prefix
> > fe80::/10 and the interfaces MUST be assigned IPv6 addresses of type
> > link-local.
> >
> > NEW: A subnet is formed by the external 802.11-OCB interfaces of
> > vehicles that are in close range (not by their in-vehicle
> > interfaces). A node MUST form a link-local address on this link.
>
> Makes sense, I will add it.
>
> Then somebody will ask what is the prefix length of the LL prefix on
> OCB?  What reference should I give to the person asking?

I don't see how that matters, unless the intent is to use a non-0
value in the intermediate 54 bits.  If you're willing to follow the
standard on this point and still want some reference for that
"somebody", I'd suggest referring to Section 2.5.6 of RFC 4291, like:

  NEW: A subnet is formed by the external 802.11-OCB interfaces of
  vehicles that are in close range (not by their in-vehicle
  interfaces). A node MUST form a link-local address on this link,
  as formatted in Section 2.5.6 of [RFC4291].

then, the question of fe80::/10 vs fe80::/64 becomes moot to me, since
both mean effectively the same thing: fe80::/10 with the following 54
bits being all 0 covers exactly the same addresses as fe80::/64.

(As I already argued) on the other hand, if the intent is to
deliberately use a non-0 value in the intermediate 54 bits (or for
that matter non-64-bit interface IDs), the specification should
explicitly say so, rather than alluding to it hidden in the question
of "what's the length of LL prefix", and should explicitly state that
the spec updates Section 2.5.6 of [RFC4291] in that sense.

--
JINMEI, Tatuya