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

[Brian E Carpenter <[e-mail]>]

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

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