Re: [ipwave] Intdir early review ofdraft-ietf-ipwave-ipv6-over-80211ocb-34

[<[e-mail]>]

Alexandre,

It has been a long time; how are you.  While I am no longer dealing with ITS, is still interesting and sometime perplexing to see what is going on with IPWAVE.  Just a few comments….

When this group started to work it was fairly simple the PHY and MAC was based on IEEE 802.11-2012 or 16.  The task was to use IPv6 above the MAC, though I never got an answer why.  A few month ago I believe a saw applications related to video, voice, and perhaps something else as well. Well, now I understand the IPv6 for applications (other than security).  

IEEE 802.11-2016 (or 802.11p) is, at least in the US, called DSRC (not WAVE).  From the US Government view point, back in the late 90’s was to enabled vehicle Safety applications using RF.  75 MHz in the 5.9 GHz band was allocated by the FCC for this purpose. The vehicle safety applications then was V2V and V2I.

The main protocol above the LLC/MAC was until 2 years ago WAVE’s WSMP.  I thought that PHY/MAC/LLC/WSMP stack was doing a very good job in terms simplicity, latency, and handling most vehicular safety warning situation.  Apart for the need of IPv6 for security, I have yet to see IPWAVE addressing vehicle safety better than WSMP.  Perhaps I missed it (I do not read all e-mails).

 From what I see in advertisements, 5G claims they can do it all faster and better than IEEE 802.11.  If I did have any say, let 5G worry about all the voice, video, IoT, IIoT, and what ever and WAVE/DSRC for vehicular safety applications.

Interesting note: Since 5G has a mini-foot print service area, the antennae are is larger number and lower height.  Since all major carrier announce 5G, the local governments, neighborhood associations, and individuals are already questioning the neighborhood antennae appearances and zoning.  I have been to county meetings about 5G antennae discussions: high attendance, heated discussion and basically “5G YES, but NOT in my backyard”

BTW: The LLC for IEEE 802.11 OCB is defined in IEEE-802.11.

Was just a few thought, do whatever you wish with those.  

Sent from Mail for Windows 10

From: Alexandre Petrescu
Sent: Thursday, March 28, 2019 1:49 PM
To: Pascal Thubert (pthubert)
Cc: [e-mail]
Subject: Re: [ipwave] Intdir early review ofdraft-ietf-ipwave-ipv6-over-80211ocb-34

We consider the offer to help, thank you.  What would be most attractive 
for you to do for this draft?

Alex

Le 28/03/2019 à 11:28, Pascal Thubert (pthubert) a écrit :
> Yes Alex. Also as an offer to help...
> 
> 
> Regards,
> 
> Pascal
> 
> Le 28 mars 2019 à 11:08, Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> a 
> écrit :
> 
>> Pascal,
>>
>> Should we treat these two reviews (iotdir and intdir reviews) as just one?
>>
>> The contents appear to me to be the same.
>>
>> Alex
>>
>> Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
>>> Reviewer: Pascal Thubert
>>> Review result: Not Ready
>>>
>>> Reviewer: Pascal Thubert
>>> Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO
>>> defines the use of L2 fields, what this spec enforces vs. recognizes as being
>>> used that way based on IEEE work. The use of IPv6 ND requires a lot more
>>> thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is
>>> unclear. It seems that RSUs would have prefixes but that is not discussed.
>>>
>>> I am an assigned INT and IOT directorates reviewer for <
>>> draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written
>>> primarily for the benefit of the Internet Area Directors. Document editors and
>>> shepherd(s) should treat these comments just like they would treat comments
>>> from any other IETF contributors and resolve them along with any other Last
>>> Call comments that have been received. For more details on the INT Directorate,
>>> seehttps://datatracker.ietf.org/group/intdir/about/
>>>
>>> Majors issues
>>> -----------------
>>>
>>> “
>>>
>>> o  Exceptions due to different operation of IPv6 network layer on
>>>        802.11 than on Ethernet.
>>>
>>> “
>>> Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an
>>> implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems
>>> that you are defining the LLC. Figure 1 shows the proposed adaptation layer as
>>> IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines
>>> their use? If this spec defines a new LLC header (vs. how to use an IEEE field)
>>>   then it should be very clear, and the newly defined fields should be isolated
>>> from IEEE fields.
>>>
>>> "
>>>     The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>>>     preceded by a Logical Link Control (LLC) header and an 802.11 header.
>>>
>>> "
>>> Is there anything new or specific to OCB vs. classical 802.11 operations?
>>> If/when this is echoing the IEEE specs then this text should not use uppercase
>>> but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on
>>> 802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and
>>> an 802.11 header ...'
>>>
>>> different things? Why define both?
>>>
>>> "   An 'adaptation' layer is inserted between a MAC layer and the
>>>     Networking layer.  This is used to transform some parameters between
>>>     their form expected by the IP stack and the form provided by the MAC
>>>     layer.
>>> "
>>> Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is
>>> this IETF business?
>>>
>>> "
>>>     The Receiver and Transmitter Address fields in the 802.11 header MUST
>>>     contain the same values as the Destination and the Source Address
>>>     fields in the Ethernet II Header, respectively.
>>> "
>>> Same,  this is IEEE game isn't it?
>>>
>>> "
>>>
>>> Solutions for these problems SHOULD
>>>     consider the OCB mode of operation.
>>> "
>>> This is not specific enough to be actionable. I suggest to remove this sentence.
>>> It would be of interest for the people defining those solutions to understand
>>> the specific needs of OCB vs. Wi Fi, but I do not see text about that.
>>>
>>> "
>>>
>>> The method of forming IIDs
>>>     described in section 4 of [RFC2464] MAY be used during transition
>>>     time.
>>> "
>>> Contradicts section 4.3 that says
>>> "
>>> Among these types of
>>>     addresses only the IPv6 link-local addresses MAY be formed using an
>>>     EUI-64 identifier.
>>> "
>>>
>>> "
>>>
>>> This
>>>     subnet MUST use at least the link-local prefix fe80::/10 and the
>>>     interfaces MUST be assigned IPv6 addresses of type link-local.
>>> "
>>> If this is conforming IPv6 then the MUST is not needed.
>>>
>>> "
>>>     A subnet is formed by the external 802.11-OCB interfaces of vehicles
>>>     that are in close range (not by their in-vehicle interfaces).
>>> "
>>> Is the definition transitive? Do we really get a subnet?
>>>   A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you
>>>   talking about a link, rather?
>>>
>>> "
>>>     The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over
>>>     802.11-OCB links.
>>> "
>>>
>>> IPv6 ND is not suited for a non-broadcast network. How does DAD work?
>>> Maybe you could consider RFC 6775 / RFC 8505 instead.
>>>
>>> "
>>> In the moment the MAC address is changed
>>>     on an 802.11-OCB interface all the Interface Identifiers of IPv6
>>>     addresses assigned to that interface MUST change.
>>> "
>>> Why is that? This is unexpected, and hopefully wrong.
>>>
>>> Minor issues
>>> ---------------
>>>
>>> "   OCB (outside the context of a basic service set - BSS): A mode of
>>>     operation in which a STA is not a member of a BSS and does not
>>>     utilize IEEE Std 802.11 authentication, association, or data
>>>     confidentiality.
>>>
>>>     802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
>>>     attribute dot11OCBActivited is true.  Note: compliance with standards
>>>     and regulations set in different countries when using the 5.9GHz
>>>     frequency band is required.
>>> "
>>>
>>> Are these 2 different things?
>>>
>>> "
>>> Among these types of
>>>   addresses only the IPv6 link-local addresses MAY be formed using an
>>>    EUI-64 identifier.
>>> "
>>> This text should not be in a LL specific section since it deals with the other
>>> addresses. Maybe rename the section to "addressing" or something?
>>>
>>> "
>>>     For privacy, the link-local address MAY be formed according to the
>>>     mechanisms described in Section 5.2.
>>> "
>>> The MAY is not helpful. I suggest to remove the sentence that does not bring
>>> value vs. 5.2
>>>
>>> Could you make sections 4.3 and 4.5 contiguous?
>>>
>>> "
>>> If semantically
>>>     opaque Interface Identifiers are needed, a potential method for
>>>     generating semantically opaque Interface Identifiers with IPv6
>>>     Stateless Address Autoconfiguration is given in [RFC7217].
>>>
>>>     Semantically opaque Interface Identifiers, instead of meaningful
>>>     Interface Identifiers derived from a valid and meaningful MAC address
>>>     ([RFC2464], section 4), MAY be needed in order to avoid certain
>>>     privacy risks.
>>>
>>> ...
>>>
>>>     In order to avoid these risks, opaque Interface Identifiers MAY be
>>>     formed according to rules described in [RFC7217].  These opaque
>>>     Interface Identifiers are formed starting from identifiers different
>>>     than the MAC addresses, and from cryptographically strong material.
>>>     Thus, privacy sensitive information is absent from Interface IDs, and
>>>     it is impossible to calculate the initial value from which the
>>>     Interface ID was calculated.
>>>
>>> "
>>> Duplicate and mis ordered text, isn't it?
>>>
>>> " For this reason, an attacker may realize many
>>>     attacks on privacy.
>>> "
>>> Do we attack privacy? Maybe say that privacy is a real concern, and maybe move
>>> that text to security section?
>>>
>>> "
>>>     The way Interface Identifiers are used MAY involve risks to privacy,
>>>     as described in Section 5.1.
>>> "
>>> Also duplicate
>>>
>>> Nits
>>> ------
>>>
>>> "
>>>     IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>>>     frames whose format is specified in IEEE Std 802.11.
>>> "
>>> Please add link to the reference
>>>
>>> " the 802.11 hidden node"
>>> Do not use 802.11 standalone (multiple occurrences).
>>> => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".
>>>
>>> BCP 14 text:
>>>
>>> Suggest to use this text:
>>> “
>>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>>     "OPTIONAL" in this document are to be interpreted as described in
>>>     https://tools.ietf.org/html/bcp14  https://tools.ietf.org/html/bcp14
>>>     [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they
>>>     appear in all capitals, as shown here.
>>>
>>> “
>>>
>>> All the best
>>>
>>> Pascal
>>>
>>>
>>>

_______________________________________________
its mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/its