On 15-Apr-19 04:59, Alexandre Petrescu wrote: > > > Le 12/04/2019 à 20:36, 神明達哉 a écrit : >> On Thu, Apr 11, 2019 at 6:59 AM 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 It does not use RFC 2119 keywords at all, so "must" means "must". In fact, RFC 2119 "MUST" means "must"; there is really no semantic distinction. RFC 8174 does not affect this statement. Brian > and (2) it does not require the link-local prefix to be on the > interface. > > 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). > >> According to a previous conversation, perhaps >> it tries to re-emphasize the already-existing requirement? > > Yes - continue to require LL addresses like 4291 does, but also the LL > prefix, which 4291 does not do. > >> In that >> case, I think it better belongs to Section 4.3, since the requirement >> of having a link-local address is not a requirement on a subnet, but >> on an interface. > > It is a requirement to put a prefix (also known as a subnet) . > >> I'd suggest revising the first paragraph of Section >> 4.3 as follows: >> >> There are several types of IPv6 addresses [RFC4291], [RFC4193], that >> MAY be assigned to an 802.11-OCB interface. Among these types of >> addresses, the interface MUST at least have one link-local IPv6 >> unicast address as specified in [RFC4291]. Only those link-local >> addresses MAY be formed using an EUI-64 identifier, in particular >> during transition time. > > Thanks for the suggestion. But it does not say 'link-local prefix'. > >> >> And, beyond this obvious requirement, it's not clear to me what this >> means: "This subnet MUST use at least the link-local prefix". Perhaps >> it also tries to say this must be a single-link subnet (so all nodes >> in the subnet can communicate each either directly using their >> link-local addresses)? If so, it's better to say so explicitly, e.g: >> >> 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? > > I could put the text as you suggest, but I am afraid to write about > single-link subnets: they are all like that, I think. > > (multilink subnets: I have never seen them in vehicular networks). > > Alex > >> >> If there's no such special intention, I'd suggest just removing the >> second sentence (with moving the requirement of having a LL address to >> Section 4.3). >> >> -- >> JINMEI, Tatuya > >
