Re: [ipwave] link-local text (Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34)

[神明達哉 <[e-mail]>]

At Sun, 14 Apr 2019 18:59:09 +0200,
Alexandre Petrescu <[e-mail]> wrote:

> >  >    The fe80::/10 word was removed.
> >
> > So I've just checked draft-ietf-ipwave-ipv6-over-80211ocb-38.  It now
> > reads:
> >
> >     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 and the interfaces
> >     MUST be assigned IPv6 address(es) of type link-local.
> >
> > Given that the use of non-0 values in the intermediate 54 bits of
> > link-local addresses is now out of scope of this specification, I
> > don't see the purpose of the second sentence. >
> > "the interfaces MUST be assigned IPv6 address(es) of type link-local"
> > is redundant, since it's already a part of the very basic
> > specification of IPv6 addressing architecture (second paragraph of
> > RFC4291 Section 2.1).
>
> True, RFC4291 sec. 2.1 says that all interfaces must have at least one
> link-local address.  But (1) it does not use CAPITALS to require
> something and (2) it does not require the link-local prefix to be on the
> interface.

As for (1), see Brian's response.   And I'm afraid you misunderstood
his message; I interpret it as if
  "All interfaces are required to have at least one Link-Local unicast
   address"
should read
  "All interfaces are REQUIRED to have at least one Link-Local unicast
  address"
.  I also believe that's the commonly adopted interpretation when an
RFC is written without all CAPITAL keywords.  If you're in doubt about
it, I suggest you confirm it at, e.g. the 6man ML.

> One can assign just an address to an interface, without specifying the
> prefix.  In that case, a plen is assumed to be 128.  If one assigns
> fe80::1 (dont specify plen) on one computer, but assigns fe80::2/64
> (specify the plen) on another computer, then there are risks of
> interoperability.  In some cases, because of that lack of specifying the
> prefix, it wont ping.
>
> Dont you think we should require that the link-local prefix must be
> assigned to each interface? (in addition to requiring the ll address).

Ah, so by stating "This subnet MUST use at least the link-local
prefix" you wanted to make sure, e.g., fe80::1 is always considered
on-link through a specified interface.  That intent originally wasn't
clear from this text to me.  To answer the question now that I
understand it: given that "what's the link-local prefix" (or whether
we should allow a non-0 value in the intermediate 54 bits) is now out
of scope of this doc, I personally don't see the need for explicitly
stating it.  But if you really want to emphasize something here, I'd
personally just refer to RFC4861:

      Prefix List  - A list of the prefixes that define a set of
                     addresses that are on-link.[...]
                     The link-local prefix is considered to be on the
                     prefix list with an infinite invalidation timer
                     regardless of whether routers are advertising a
                     prefix for it.

> >     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
> >     MUST be a single-like subnet.  It means that all nodes in the
>
> single-link?
>
> >     subnet must be able to communicate directly using their link-local
> >     unicast addresses.
>
> Sounds reasonable.  Multi-link subnets were not assumed here, and when
> not assuming them I suspect the subnets are exclusively single-link.
>
> I never heard the term single-link subnet?

Perhaps it's not a well-defined term.  If you're concerned about the
terminology matter you can just say it's not a multi-link subnet.

Anyway, any of these suggestions are completely informational in the
hope that they will help improve the readability of this document
without changing its. intent.  If you don't agree on or like any of
them, you can freely ignore them.

--
JINMEI, Tatuya