Re: [ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

[Alexandre Petrescu <[e-mail]>]

Le 09/07/2019 à 22:03, Roman Danyliw via Datatracker a écrit :
[...]
> (3) Section 5.2.  Per “An Interface ID SHOULD be of length specified in other
> documents”, what other documents?

The idea was to get tract for a variable length IID document in 6MAN WG. 
  One indiviual submission is draft-petrescu-6man-ll-prefix-len-21.

However, the 6MAN WG tells that topic is closed and I am indicated to 
refrain from new discussions on that topic in that WG.

As such, there is presumably no other document to refer to.

I will not say anything related to 64.  It is not up to me to say 
something I do not believe in, and which is a barrier to deployment.

[...]

> (5) Section 1.  Per “The resulting stack inherits from IPv6 over Ethernet
> [RFC2462], but operates over …”, what exactly is being inherited?  What does
> “inherited” mean in this case?

For example, the resulting stack uses Ethernet II headers.  The use of 
Ethernet II headers on 802.11 media is inherited from RFC2464 (not RFC2462).

It is not the 'inheritance' of OO programming.  It is inheritance like 
in legacy.

> (6) Section 4.3.  Per “Among these types of addresses only the IPv6 link-local
> addresses can be formed using an EUI-64 identifier, in particular during
> transition time”, the meaning of the “in particular during transition time
> isn’t clear to me.

The implemenntations of IPv6-over-OCB run on linux only, in particular 
in earlier versions of kernel because they are embedded platforms; 
embedded platforms are not up to date with kernel versions, like desktop 
linuces are.

The more privacy respecting IIDs RFCs are present and implemented in 
more recent linux dekstop versions, and in BSD.  BSD does not implemenet 
IP-over-OCB.

I suspect gradually these privacy IIDs will move to linux and embedded, 
but it will take time.  That transition time I estimate at 5 years 
before we see privacy IIDs in common embedded systems in cars.  Until 
then they use oui.txt MAC-based LL addresses with the usual privacy 
issues. (I am saying oui.txt because that's the public registry which 
makes them vulnerable; there are also MAC addresses that are less 
vulnerable because more randomized, like in Windows).

> 
> (7) Section 5.  Per “The OCB operation is stripped off of …”, is this sentence
> saying that OCB operations doesn’t use 802.11 link layer security mechanisms,
> or does the OCB operation actively remove (i.e., strips) 802.11 link layer
> security mechanisms?  I’m getting caught up in the use of “stripped off”.

The 802.11 security features are absent in OCB mode.  Maybe 'stripped' 
and 'off' combination is not the right term.

Alex

[...]