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

[Alexandre Petrescu <[e-mail]>]

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

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.

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