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

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

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.

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