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

Hi Pascal,

Thank you for your comments.

Please see my answers below:

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Mon, May 27, 2019 at 11:58 AM Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> 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”
>
Ok.

> Ø  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.
>
Agree.

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

Pascal, I have just received a detailed review from some IEEE-802.11
members, thanks to Dorothy! One of the recommendation is to remove section
4.2.1 completely.

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

> OK.
>

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

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

I agree. It seems that by describing specific values, the text is redundant
with what’s already in IEEE Std 802.11-2016

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

> Ø  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.”
>
>  Ok. Good point!
>
>
>
>
>
>    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?
>

Here is the new text to replace that paragraph:

" “The IPv6 packet transmitted on 802.11-OCB MUST be 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
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-E>),
the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to
the 802.11 data service MUST use a ‘priority’ value of 1, which specifies
the use of QoS with a “Background” user priority."

>
>
>    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.
>
What do you suggest instead?

>
>
> 4.2.1.  Ethernet Adaptation Layer
>
>
>
> Ø  The whole section should go. This is IEEE world.
>
Done. It will be seen in -46 !

>
>
> 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
>
I will keep it as it is then.

>
>
> 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.
>
Didn't get your point! What 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.
>
Ok.

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

Ok.

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

Ok.

> Ø
>
>
>
> 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.
>
> Ø
>
>  I agree.
>
>
>
>   <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.
>

Here is the new text as agreed last time with Brian:

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

>
>
> 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.
>
I will reformulate in the following manner:

Transmitting ND packets may prove to have some performance issues.  These
issues may be exacerbated in OCB

   mode.  Future solutions to OCB should consider solutions for avoiding
broadcast.  The best of current knowledge indicates the kinds of issues
that may arise with ND in OCB mode; they are described in Appendix J.

> Ø  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
>
> OK.
>
>
>
>    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
>
> I agree.
>

>
>
>    <snip>
>
>
>
> 5.1.  Privacy Considerations
>
>
>
>    <snap>
>
>
>
> 5.3.  Pseudonym Handling
>
>
>
>    <snip>
>
>
>
>
>
> All the best,
>
>
>
> Pascal
>

Thank you once again.

I will publish version 46 soon.

>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>