On 15-Apr-19 23:22, Alexandre Petrescu wrote: > > > Le 14/04/2019 à 22:24, Brian E Carpenter a écrit : >> 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. > > So, if RFC4291 does not use MUST to require the use of a link-local > address, Huh? It uses English "must" which, excuse me for repetition, means *exactly* the same as RFC2119 "MUST". There is no difference. > and if the IP-over-OCB draft says that link-local addresses MAY > be formed on OCB interfaces (as the current draft does) - we are fine. Not quite, because it also says " An Interface ID SHOULD be of length 64 decimal for all types of IPv6 addresses. In the particular case of IPv6 link-local addresses, the length of the Interface ID MAY be 118 decimal." which conflicts with RFC4291. > Also it means one can not say that RFC4291 specifies enough about the > link local addresses because it uses no RFC2119 keyword with respect to > link local addresses. I can't parse that sentence, because I cannot tell which clause "because" applies to. Brian > > Alex > >> >> 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 >>> >>> >> >> > . >
