[ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear all

In the interest of non-blocking please find a rereview based on the current draft (45)

Abstract

   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes how IPv6 (including addressing and
   basic ND) can be used to communicate among nodes in range of one
   another over IEEE 802.11-OCB.  Optimizations and usage of IPv6 over
   more complex scenarios is not covered and is subject of future work.



?  This does not reflect the draft as its stands; a real world summary would be that the draft

?  "provides methods and settings, and describes limitations, for using IPv6 over OCB with minimal change to existing stacks"

?  Which is what the draft does, and that's OK with me

?  Any attempts to say that this is *the* way to do IPv6 over OCB is doomed; it would simply mean the WG is over when it just started.

1.  Introduction

<snip>

   The IPv6 network layer operates on 802.11-OCB in the same manner as
   operating on Ethernet, but there are two kinds of exceptions:

   o  Exceptions due to different operation of IPv6 network layer on
      802.11 than on Ethernet.  To satisfy these exceptions, this
      document describes an Ethernet Adaptation Layer between Ethernet
      headers and 802.11 headers.  The Ethernet Adaptation Layer is
      described Section 4.2.1.  The operation of IP on Ethernet is
      described in [RFC1042], [RFC2464] .


?  This should be out of scope and inherited from IPv6 over WiFi. If the draft does not exist then let us do one, at 6MAN.

?  The introduction should clatify the scope, which appears to be do with what existing stacks can do and (sometimes) see what's missing.

<snap>


3.  Communication Scenarios where IEEE 802.11-OCB Links are Used

   The IEEE 802.11-OCB Networks are used for vehicular communications,
   as 'Wireless Access in Vehicular Environments'.  The IP communication
   scenarios for these environments have been described in several
   documents;


?  Do not point on docs that you do not refer.

?  Pls rephrase to use the below and be done.


in particular, we refer the reader to
   [I-D.ietf-ipwave-vehicular-networking], that lists some scenarios and
   requirements for IP in Intelligent Transportation Systems.

   The link model is the following: STA --- 802.11-OCB --- STA.  In
   vehicular networks, STAs can be IP-RSUs and/or IP-OBUs.  While
   802.11-OCB is clearly specified, and the use of IPv6 over such link
   is not radically new, the operating environment (vehicular networks)
   brings in new perspectives.


?  This text fails to indicate is the link model is P2P though is seems implied. The draft does not have the means to use OCB as transit so the best is to indicate that all links are assumed to be P2P and that there can be multiple links on one radio interface.

4.  IPv6 over 802.11-OCB

4.1.  Maximum Transmission Unit (MTU)

   The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.  It
   is the same value as IPv6 packets on Ethernet links, as specified in
   [RFC2464].




?  The draft already says that it inherits from Ethernet.

?  The 1500 is just one parameter in a number of parameters and behaviors.

?  Maybe just say that the default MTU is inherited from RFC2464 and is 1500.


<snip>

4.2.  Frame Format

   IP packets MUST be transmitted over 802.11-OCB media as QoS Data
   frames whose format is specified in IEEE 802.11(TM) -2016
   [IEEE-802.11-2016].

?  Useless. Why force a version (2016)? We should refer to IEEE dateless specs if we can.

?  By default it will mean current, which is OK here.

?  Better say that this spec deals with IPv6 packets transmitted over OCB, and that OCB is defined in IEEE std 802.11 spec.

   The IPv6 packet transmitted on 802.11-OCB MUST be immediately
   preceded by a Logical Link Control (LLC) header and an 802.11 header.


?  Not an IETF problem. You may indicate this informationally, saying

?  "IPv6 packet transmitted on 802.11-OCB are immediately preceded by a Logical Link Control (LLC) header and an 802.11 header."



   In the LLC header, and in accordance with the EtherType Protocol
   Discrimination (EPD, see Appendix E), the value of the Type field
   MUST be set to 0x86DD (IPv6).  In the 802.11 header, the value of the
   Subtype sub-field in the Frame Control field MUST be set to 8 (i.e.
   'QoS Data'); the value of the Traffic Identifier (TID) sub-field of
   the QoS Control field of the 802.11 header MUST be set to binary 001
   (i.e.  User Priority 'Background', QoS Access Category 'AC_BK').


?  Are we sure of that, don't we map QoS from ToS bits as usual with 11e?

   To simplify the Application Programming Interface (API) between the
   operating system and the 802.11-OCB media, device drivers MAY
   implement an Ethernet Adaptation Layer that translates Ethernet II
   frames to the 802.11 format and vice versa.  An Ethernet Adaptation
   Layer is described in Section 4.2.1.


?  Do not call that an adaptation layer. The may refers to using an Ethernet stack and then a translation from Ethernet Frames to 802.11 frames as specified by IEEE.

4.2.1.  Ethernet Adaptation Layer


?  The whole section should go. This is IEEE world.

4.3.  Link-Local Addresses

   There are several types of IPv6 addresses [RFC4291], [RFC4193], that
   MAY be assigned to an 802.11-OCB interface.  Among these types of
   addresses only the IPv6 link-local addresses MAY be formed using an
   EUI-64 identifier, in particular during transition time.

   If the IPv6 link-local address is formed using an EUI-64 identifier,
   then the mechanism of forming that address is the same mechanism as
   used to form an IPv6 link-local address on Ethernet links.  This
   mechanism is described in section 5 of [RFC2464].


?  Not really useful since it just repeats inheritance from Ethernet but appears correct

4.4.  Stateless Autoconfiguration

   There are several types of IPv6 addresses [RFC4291], [RFC4193], that
   MAY be assigned to an 802.11-OCB interface.  This section describes
   the formation of Interface Identifiers for IPv6 addresses of type
   'Global' or 'Unique Local'.  For Interface Identifiers for IPv6
   address of type 'Link-Local' see Section 4.3.


?  Not really interesting. More important is to say that autoconf is defined in RFC 4862 and that is missing.

   The Interface Identifier for an 802.11-OCB interface is formed using
   the same rules as the Interface Identifier for an Ethernet interface;


?  Again repeated inheritance. I'd remove it.

?  The rest of the section seems useful as a rephrasing of our best practices for use by WAVE people.

   <snip>



4.5.  Address Mapping


?  Again repeated inheritance. I'd remove it.

4.5.1.  Address Mapping -- Unicast

   The procedure for mapping IPv6 unicast addresses into Ethernet link-
   layer addresses is described in [RFC4861].


?  This is repeating RFC 2464 but not at its best. Better says that this draft is scoped for AR and DAD per RFC 4861.

4.5.2.  Address Mapping -- Multicast

<Snap>
                                             These issues may be
   exacerbated in OCB mode.  Solutions for these problems SHOULD
   consider the OCB mode of operation.


?  Wrong. It is the other way around. IPv6 over OCB SHOULD consider the solutions that have been brought to this problem, which is RFC 8505.

?  Since this spec does not do it I'd suggest rephrasing like
                                                                            "These issues may be
   exacerbated in OCB mode.  Future improvement to this specification
   SHOULD consider solutions for these problems."

?

4.6.  Subnet Structure

   A subnet is formed by the external 802.11-OCB interfaces of vehicles
   that are in close range (not by their in-vehicle interfaces).  A
   Prefix List conceptual data structure ([RFC4861] section 5.1) is
   maintained for each 802.11-OCB interface.


?  This is about physical properties and this is describing a link.

?  A subnet is a logical structure that we build as we like and that can be multihop if we like

?  Actually we do in a number of deployed cases

   The subnet structure on which the Neighbor Discovery protocol (ND) on
   OCB works ok is a single-link subnet; the status of ND operation on a
   subnet that covers multiple OCB links that repeat the signal at PHY
   layer, or the messages at MAC layer, is unknown.


?  Not just single link: either P2p or transit. And transit is achieved when everyone is within every one else's range. Which is a very special arrangement.

?  I'd rephrase to

?     An IPv6 subnet on which Neighbor Discovery protocol (ND) can be used

?     can be mapped on an OCB network iff all nodes share a single broadcast

?     Domain, which is generally the case for P2P OCB links;

?     the status of ND operation on a subnet that covers multiple OCB links

?     That are not fully overlapping (NBMA) is not in scope.

?


  <snip>


   The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used
   over 802.11-OCB links.


?  MUST +> MAY. Say the scope of this doc only considers ND but neither RFC 8505 nor IPWAVE drafts.

Transmitting ND packets may prove to have
   some performance issues.  These issues may be exacerbated in OCB
   mode.  Solutions for these problems SHOULD consider the OCB mode of
   operation.  The best of current knowledge indicates the kinds of
   issues that may arise with ND in OCB mode; they are described in
   Appendix J.



?  Remove or turn it the other way around like future solutions to OCB should consider solutions for avoiding broadcast.

?  Again solutions exist, it is this spec that does not consider them.

   Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which
   depend on timely movement detection, might need additional tuning
   work to handle the lack of link-layer notifications during handover.
   This is for further study.



?  I can agree with that but is all should be in the problem statement draft not this.



5.  Security Considerations

   <snip>

   The potential attack vectors are: MAC address spoofing, IP address
   and session hijacking, and privacy violation Section 5.1.


?  Refer to SAVI and draft 6lo ap ND

?

   Within the IPsec Security Architecture [RFC4301], the IPsec AH and
   ESP headers [RFC4302] and [RFC4303] respectively, its multicast
   extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols
   can be used to protect communications.  Further, the assistance of
   proper Public Key Infrastructure (PKI) protocols [RFC4210] is
   necessary to establish credentials.  $



?  Remove, all well known in the art and not specific to OCB

   <snip>

5.1.  Privacy Considerations

   <snap>

5.3.  Pseudonym Handling

   <snip>


All the best,

Pascal