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

[Alexandre Petrescu <[e-mail]>]

Le 15/04/2019 à 20:40, 神明達哉 a écrit :
> At Sun, 14 Apr 2019 18:59:09 +0200,
> Alexandre Petrescu <[e-mail] 
> <mailto:[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.

A commonly adopted interpretation?  I did not  know it, but I am happy 
to hear it existed.

I must share that much text in earlier versions of this IP-over-OCB 
document did not have any capitalized keyword.  I was told we must use 
capitalized keywords otherwise it wont do.  Why RFC4291 is not told to 
use capitalized keywords?

> If you're in doubt about
> it, I suggest you confirm it at, e.g. the 6man ML.

Yes, I would like to try that.

> 
>  > 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.

Your argumentation sounds reasonable.

I thus propose in the IP-over-OCB document:

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 and the interfaces MUST be assigned IPv6 address(es)
> 	  of type link-local.  All nodes in the subnet MUST be able to
> 	  communicate directly using their link-local unicast
> 	  addresses.

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
>    Prefix List conceptual data structure ([RFC4861] section 5.1) is
>    maintained for each OCB interface.
> 
>    All nodes in the subnet MUST be able to communicate directly using
>    their link-local unicast addresses.



> 
>  > >     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.

I propose this:

NEW:
> 	  The subnet is not a multi-link subnet.

Alex

> 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