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

[Alexandre Petrescu <[e-mail]>]

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