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