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

[Alexandre Petrescu <[e-mail]>]

I would like to reply to a few points.

Le 11/07/2019 à 15:36, Barry Leiba a écrit :
[...]
>>> — Section 4.4 —
>>>
>>>     For Interface Identifiers for
>>>     IPv6 address of type 'Link-Local' are discussed in Section 4.3.
>>> There’s something wrong with that sentence.  Maybe it’s just that the first
>>>   word needs to be struck?

You suggest to remove 'IPv6' from 'IPv6 address' and so become 'address 
of type LL ...'.

I tend to agree with you, because all there is to be is IP.  IPv4 is 
dying out and so we are left only with IPv6, which so becomes IP, and so 
becomes the only assumed kind of 'address'.

But this is a matter of stance.  Such a stance could have been taken 
throughout the document.  It was however difficult to write it so 
everywhere.  For example, as much as LL addresses can be both IPv4 and 
IPv6, ULA addresses are only IPv6.  The approximate equivalent of ULA in 
IPv4 is publicly unroutable addresses (also called 'private', or 'NAT') 
and the 'shared address space' (also called CGN NAT, like 
100.64.0.0/10).  Neither NAT nor shared address space are the equivalent 
of ULA.  And so it is difficult to think that an address type is present 
in both versions of IP, and so just say 'IP', and so just assume that 
'address' is an 'IPv6 address'.

As such it was difficult to take this stance throughout the document.

The title contents was even a more difficult situation: 'IPv6 over OCB' 
vs 'IP over OCB' was considered, but there is much IPv4 over OCB try, so 
it would be difficult to assume only IPv6 is there.

But, of course, if there is another direction that needs to be taken 
about striking out this IP word (make it disappear from that place), 
then I agree.

>>>     Regardless of how
>>>     to form the IID, its length is 64 bits, as is the case of the IPv6
>>>     over Ethernet [RFC2464].
>>>
>>> There’s something wrong with this sentence too, but I don’t know what the fix
>>> is: I don’t know what the “as is the case...” part is meant to say.  Can you
>>> try rephrasing?

It is meant to say that RFC2464 defines the prefix length on Ethernet to 
be 64, and as such one would assume the IID length on Ethernet to be 64.

But a reformulation would help, I agree.

[...]
>>>
>>> — Section 4.5.2 —
>>>
>>>     The meaning of the value "3333"
>>>     mentioned in that section 7 of [RFC2464]
>>>
>>> As you’ve just given the section reference in the previous sentence, I think it
>>> reads better to use the context and just say, “The meaning of the value "3333"
>>> mentioned there”.
>>>
>>> — Section 4.6 —
>>>
>>>     A subnet may be formed over 802.11-OCB interfaces of vehicles that
>>>     are in close range (not by their in-vehicle interfaces).
>>>
>>> At first I tried to understand what the in-vehicle interfaces had to do with
>>> the close range.  I think it’s clearer with this word order:
>>>
>>> NEW
>>>     When vehicles are in close range, a subnet may be formed over
>>>     802.11-OCB interfaces (not by their in-vehicle interfaces).
>>> END

I agree.

[...]
>>>     and performs attacks
>>>     without needing to physically break any wall.
>>>
>>> “and performs attacks” shoud be “and perform attacks”.
>>> The “physically break any wall” part seems kind of odd, as there are clearly no
>>> physical walls involved at all.  What are you really trying to say?

This is an old view first appearing with Hiperlan and WiFi.  At the 
time, it was often said that WiFi and Internet is a big risk, because 
one could attack without needing to force and come in server rooms; a 
brick-and-mortar enterprise is more difficult to attack than an 
enterprise on the web, because attacker would need to break walls made 
of brick and mortar, which is a difficult operation.

>>>
>>>     The potential attack vectors are: MAC address spoofing, IP address
>>>     and session hijacking, and privacy violation Section 5.1.
>>>
>>> What is “Section 5.1” about?  Is that meant to be a citation, like “[Section
>>> 5.1]” ?

Or rather between parenthesis, like this:

NEW:
>>>>     The potential attack vectors are: MAC address spoofing, IP address
>>>>     and session hijacking, and privacy violation (see Section 5.1.)

[...]

Alex