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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 11:58:24 +0000

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

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 27 May 2019 14:12:06 +0000

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) <
[email-masked]> wrote:

>    In order to transmit IPv6 packets on IEEE 802..11 networks running
>
> Ø  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.

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

> Ø  Do not point on docs that you do not refer.
>
> Ø  Pls rephrase to use the below and be done.
>
>
>
>
>

> OK.

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

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

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

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

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

> Ø  Not really useful since it just repeats inheritance from Ethernet but
> appears correct
>
I will keep it as it is then.

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

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

> Ø  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
>
>    SHOULD consider solutions for these problems.”
>

Ok.

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

> Ø  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.
>
>
>
> Ø  I can agree with that but is all should be in the problem statement
> draft not this.
>
>
>
>
>
> Ø  Refer to SAVI and draft 6lo ap ND
>
> OK.
>
>
>
> Ø  Remove, all well known in the art and not specific to OCB
>
> I agree.
>

> 5.1.  Privacy Considerations

Thank you once again.

I will publish version 46 soon.

>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 14:46:56 +0000

Hello Nabil:

I removed the places where we already agree. Please see below for the remaining details

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

Ø    Good, we are converging.

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

  *   In the <reference> tag to the IEEE spec just use <date/> . This actually removes the date. Also please remove -2016 from the spec name, just leave generic 802.11 dateless.
  *   Placing a date is misguided since we do not have a dependency on one particular version of 802.11. Indeed we want your spec to apply to all versions starting current, which is what is implied by dateless.

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

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

Ø    Can’t we use different QoS values like we can on WiFi?

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

Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464 and then a frame translation from 802.3 to 802.11 in order to  minimize the code changes”.

Ø    If minimal impact on the stack is the actual goal of this draft, which I think it is. This is what justifies publish this hastily and then do the real work that implies larger changes.

Ø

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

Ø    IPv6 autoconf is described in RFC 4862. This section does not refer to it, but rather duplicates the previous about address types, which is far from interesting.

Ø    I suggest you remove the text above and add a sentence that roughly introduce RFC 4862. Note that RFC 8505 does not change the autoconfiguration though it changes the way DAD is achieved.

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

Ø   Yes, that works.

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

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.

Ø    Good

All the best,

Pascal

Thank you once again.

Ø    Please ping me when done; do not forget to scope the document so that it is minimizing changes to existing stack and leveraging Ethernet implementation, with IPv6 ND and so on, and a focus on P2P over link local.

All the best,

Pascal

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 27 May 2019 15:11:42 +0000

Hi Pascal,

We are converging :)

See below

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

On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Yes, I support this idea to initiate a new draft in 6MAN. I'm in!

> Here is the new introduction (first paragraph), are we missing something
else?

"This document describes the transmission of IPv6 packets on IEEE Std

802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see

Appendix B, Appendix C and Appendix D). This involves the layering

of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC

layer. Compared to running IPv6 over the Ethernet MAC layer, there

is no modification expected to IEEE Std 802.11 MAC and Logical Link

sublayers: IPv6 works normally over a single IEEE 802.11-OCB link,

with an LLC layer. Multi-link scenarios are out of scope for the

present document."

> I agree. It seems that by describing specific values, the text is
> redundant with what’s already in IEEE Std 802.11-2016
>
>
>    - In the <reference> tag to the IEEE spec just use <date/> . This
>    actually removes the date. Also please remove -2016 from the spec name,
>    just leave generic 802.11 dateless.
>
> Ok.

>
>    -
>    - Placing a date is misguided since we do not have a dependency on one
>    particular version of 802.11. Indeed we want your spec to apply to all
>    versions starting current, which is what is implied by dateless.
>
> That's perfect.

>    -
That was the recommendation of IEEE 802.11 members, and I updated the draft
based on your review and their recommendations. Please feel free to suggest
other text here.

> Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464
> and then a frame translation from 802.3 to 802.11 in order to  minimize the
> code changes”.
>
> Ø    If minimal impact on the stack is the actual goal of this draft,
> which I think it is. This is what justifies publish this hastily and then
> do the real work that implies larger changes.
>
> Ø
>
Sounds good for me!

> Ø    IPv6 autoconf is described in RFC 4862. This section does not refer
> to it, but rather duplicates the previous about address types, which is far
> from interesting.
>
> Ø    I suggest you remove the text above and add a sentence that roughly
> introduce RFC 4862. Note that RFC 8505 does not change the
> autoconfiguration though it changes the way DAD is achieved.
>
>
>
>
>
> Ok. I will include it in -46
>
>
>
>
>
> Ø    Please ping me when done; do not forget to scope the document so
> that it is minimizing changes to existing stack and leveraging Ethernet
> implementation, with IPv6 ND and so on, and a focus on P2P over link local.
>
>
>
> All the best,
>
>
>
> Pascal
>

Thank you, Pascal for your time.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2019 08:48:54 +0000

Hello Nabil:

In the next rev I expect to see text in the intro that states the scope of reusing legacy stacks with minimal changes.

Expressed that way, the discussion on legacy ND only and using the Ethernet distribution system and then a frame translation to 802.11, all makes full sense.
Also, this prepares for the work that the group has already started, which involves new stack elements better suited for OCB.

This should also be in the title. Suggestion for the new title:

Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set

The ‘minimal’ avoids the risk that the reader thinks that this draft has it all and that IPWAVE can close after that.

All the best,

Pascal

From: Nabil Benamar <[email-masked]>
Sent: lundi 27 mai 2019 17:12
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

Hi Pascal,

We are converging :)

See below

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

On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Nabil:

>  The introduction should clatify the scope, which appears to be do with what existing stacks can do and (sometimes) see what’s missing.
Here is the new introduction (first paragraph), are we missing something else?

present document."

>    Good, we are converging.

  *

  *

>    Can’t we use different QoS values like we can on WiFi?
That was the recommendation of IEEE 802.11 members, and I updated the draft based on your review and their recommendations. Please feel free to suggest other text here.

>    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464 and then a frame translation from 802.3 to 802.11 in order to  minimize the code changes”.

>    If minimal impact on the stack is the actual goal of this draft, which I think it is. This is what justifies publish this hastily and then do the real work that implies larger changes.

Sounds good for me!

>    IPv6 autoconf is described in RFC 4862. This section does not refer to it, but rather duplicates the previous about address types, which is far from interesting.

>    I suggest you remove the text above and add a sentence that roughly introduce RFC 4862. Note that RFC 8505 does not change the autoconfiguration though it changes the way DAD is achieved.

>   Yes, that works.

>    Good

All the best,

Pascal

Thank you once again.

>    Please ping me when done; do not forget to scope the document so that it is minimizing changes to existing stack and leveraging Ethernet implementation, with IPv6 ND and so on, and a focus on P2P over link local.

All the best,

Pascal

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 28 May 2019 12:46:46 +0000

Hi Pascal,

Thank you for your comments. Please see ALL the changes that will be
reflected in version -46. Let me know what is missing?

Abstract

OLD:

NEW:

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

        provides methods and settings, and describes limitations,

        for using IPv6 to communicate among nodes in range of one another

        over a single IEEE 802.11-OCB link with minimal change to existing
stacks.

        Optimizations and usage of IPv6 over more complex scenarios

        is not covered and is subject of future work.

Introduction

OLD:

      described Section 4.2.1
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4.2.1>
.  The operation of IP on Ethernet is

      described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [RFC2464
<https://tools.ietf.org/html/rfc2464>] .

NEW:

      802.11 than on Ethernet. The operation of IP on Ethernet is

      described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [RFC2464
<https://tools.ietf.org/html/rfc2464>] .

OLD:

   documents;

NEW:

as 'Wireless Access in Vehicular Environments’. 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.

OLD:

NEW:

The link model is the following: STA --- 802.11-OCB --- STA.

In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs.

    All links are assumed to be P2P and multiple

    links can be on one radio interface. 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.

*4*
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4>*.
IPv6 over 802.11-OCB*

OLD:

   [RFC2464 <https://tools.ietf.org/html/rfc2464>].  This value of the MTU
respects the recommendation that

   every link on the Internet must have a minimum MTU of 1280 octets.

NEW:

The default MTU for IP packets on 802.11-OCB is inherited

          from RFC2464 and is 1500 octets. This value

          of the MTU respects the recommendation that every link on

          the Internet must have a minimum MTU of 1280 octets (stated

          in <xref target="RFC8200"/>, and the recommendations

          therein, especially with respect to fragmentation).

4.2.  Frame Format

OLD:

   [IEEE-802.11-2016].

NEW:

   frames whose format is specified in IEEE 802.11 spec.

OLD:

NEW:

IPv6 packet transmitted on 802.11-OCB are immediately preceded

by a Logical Link Control (LLC) header and an 802.11 header

OLD:

In the 802.11 header, the value of the

NEW:

 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.

OLD:

   Layer is described in

NEW:

To simplify the Application Programming Interface (API)

  between the operating system and the 802.11-OCB media,

  device drivers MAY implement IPv6 over Ethernet per RFC 2464

      and then a frame translation from 802.3 to 802.11 in order

      to  minimize the code changes.

OLD:

NEW:

The steps a host takes in deciding how to

      autoconfigure its interfaces in IP version 6 are described in <xref

  target='RFC4862'/>. 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 <xref

  target='ll'/>.

OLD:

NEW:

The RECOMMENDED method for forming

          stable Interface Identifiers (IIDs) is described in <xref

          target='RFC8064'/>.  The method of forming IIDs described in

          section 4 of <xref target='RFC2464'/> MAY be used during

          transition time, in particular for IPv6 link-local

          addresses.

OLD:

NEW:

   This draft is scoped for AR and DAD per RFC 4861.

OLD:

<Snap>

                                             These issues may be

NEW:

These issues may be exacerbated in OCB mode.  Future improvement to this
specification SHOULD consider solutions for these problems.

OLD:

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.

NEW:

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.

OLD:

The baseline Neighbor Discovery protocol (ND) [RFC4861
<https://tools.ietf.org/html/rfc4861>] MUST be used over 802.11-OCB links.

NEW:

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

 OLD:

   Appendix J.

NEW:

OLD:

NEW:

Removed

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

On Tue, May 28, 2019 at 8:49 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Nabil:
>
>
>
> In the next rev I expect to see text in the intro that states the scope of
> reusing legacy stacks with minimal changes.
>
>
>
> Expressed that way, the discussion on legacy ND only and using the
> Ethernet distribution system and then a frame translation to 802.11, all
> makes full sense.
>
> Also, this prepares for the work that the group has already started, which
> involves new stack elements better suited for OCB.
>
>
>
> The ‘minimal’ avoids the risk that the reader thinks that this draft has
> it all and that IPWAVE can close after that.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* Nabil Benamar <[email-masked]>
> *Sent:* lundi 27 mai 2019 17:12
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [ipwave] rereview of
> draft-ietf-ipwave-ipv6-over-80211ocb-45
>
>
>
> Hi Pascal,
>
>
>
> We are converging :)
>
>
>
> See below
>
>
>
>
>
> Best regards
>
> Nabil Benamar
>
> -------------------
>
> نبيل بنعمرو
>
>
>
>
>
>
>
> That was the recommendation of IEEE 802.11 members, and I updated the
> draft based on your review and their recommendations. Please feel free to
> suggest other text here.
>
>
>
>
>
>
>

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 28 May 2019 13:24:32 +0000

Here is a final point in the security section:

OLD:

The potential attack vectors are: MAC address spoofing, IP address and
session hijacking, and privacy violation Section 5.1
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-5.1>
.

NEW:

The potential attack vectors are: MAC address spoofing, IP address and
session hijacking, and privacy violation Section 5.1
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-5.1>.
A previous work at SAVI WG presents some threats [RFC 6959], and a
beginning of a solution is given in
https://datatracker.ietf.org/doc/draft-bi-savi-wlan/.   Also, SeND
presented in RFC 3971 and RFC 3972 is is a solution against address theft
but it is complex and not deployed. In the context of WiND, the
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd provides a complete
solution

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

On Tue, May 28, 2019 at 12:46 PM Nabil Benamar <[email-masked]> wrote:

>         over a single IEEE 802.11-OCB link with minimal change to
> existing stacks.
>
>       described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [
> RFC2464 <https://tools.ietf.org/html/rfc2464>] .
>
>
>
>
>
> NEW:
>
>
>       described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [
> RFC2464 <https://tools.ietf.org/html/rfc2464>] .
>
>
>
> as 'Wireless Access in Vehicular Environments’. 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.
>
>
>
> OLD:
>
>
>     links can be on one radio interface. While 802.11-OCB is clearly  specified,
>    [RFC2464 <https://tools.ietf.org/html/rfc2464>].  This value of the
> MTU respects the recommendation that
>
>> In the next rev I expect to see text in the intro that states the scope
>> of reusing legacy stacks with minimal changes.
>>
>>
>>
>> Also, this prepares for the work that the group has already started,
>> which involves new stack elements better suited for OCB.
>>
>>
>>
>> Ø  The introduction should clatify the scope, which appears to be do
>> with what existing stacks can do and (sometimes) see what’s missing.
>>
>>    - Placing a date is misguided since we do not have a dependency on
>>    one particular version of 802.11. Indeed we want your spec to apply to all
>> " “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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2019 13:35:22 +0000

Hello Nabil

OLD:

NEW:

        over a single IEEE 802.11-OCB link with minimal change to existing stacks.

  *   Excellent

Introduction

OLD:

      described Section 4.2.1<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4.2.1>.  The operation of IP on Ethernet is

      described in [RFC1042<https://tools.ietf.org/html/rfc1042>], [RFC2464<https://tools.ietf.org/html/rfc2464>] .

NEW:

      described in [RFC1042<https://tools.ietf.org/html/rfc1042>], [RFC2464<https://tools.ietf.org/html/rfc2464>] .

  *   Works for me

OLD:

   documents;

NEW:

as 'Wireless Access in Vehicular Environments’. 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.

  *   Yes

OLD:

NEW:

    links can be on one radio interface. 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.

  *   OK . I’d rather replace “the use of IPv6 over such link is not radically new” with “a legacy IPv6 stack can operate on such links”

4<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4>.  IPv6 over 802.11-OCB

OLD:

   [RFC2464<https://tools.ietf.org/html/rfc2464>].  This value of the MTU respects the recommendation that

NEW:

> OK .

4.2.  Frame Format

OLD:

   [IEEE-802.11-2016].

NEW:

Ø  Leave the reference just use a dateless one, e.g.:

Ø

      <reference anchor="IEEEstd80211">

         <front>

            <title>IEEE Standard for Information technology --

                Telecommunications and information exchange between systems

                Local and metropolitan area networks-- Specific requirements

                Part 11: Wireless LAN Medium Access Control (MAC) and Physical

                Layer (PHY) Specifications

            </title>

            <author>

               <organization>

                      IEEE standard for Information Technology

  </organization>

            </author>

            <date/>

         </front>

      </reference>

OLD:

NEW:

Ø    Good

OLD:

NEW:

Ø    I’ll trust you on that

OLD:

   Layer is described in

NEW:

Ø    Perfect

OLD:

NEW:

            target='ll'/>.

Ø    Works for me

OLD:

NEW:

          addresses.

  *   Yes

OLD:

NEW:

  *   True

OLD:

<Snap>

                                             These issues may be

NEW:

These issues may be exacerbated in OCB mode.  Future improvement to this specification SHOULD consider solutions for these problems.

  *   Excellent

OLD:

NEW:

  *   Yes. Maybe:

”

Domain, which is  generally the case for P2P OCB links (OCB is usually reflexive) but not for multipoint (OCB is generally not transitive);

“

OLD:

The baseline Neighbor Discovery protocol (ND) [RFC4861<https://tools.ietf.org/html/rfc4861>] MUST be used over 802.11-OCB links.

NEW:

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

Ø    Yes

 OLD:

   Appendix J.

NEW:

Ø    Yes

OLD:

NEW:

Removed

Ø    OK

All the best,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2019 13:36:22 +0000

Works for me;

All the best,

Pascal

From: Nabil Benamar <[email-masked]>
Sent: mardi 28 mai 2019 15:25
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

OLD:

The potential attack vectors are: MAC address spoofing, IP address and session hijacking, and privacy violation Section 5.1<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-5.1>.

NEW:

The potential attack vectors are: MAC address spoofing, IP address and session hijacking, and privacy violation Section 5.1<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-5.1>. A previous work at SAVI WG presents some threats [RFC 6959], and a beginning of a solution is given in https://datatracker.ietf.org/doc/draft-bi-savi-wlan/.   Also, SeND presented in RFC 3971 and RFC 3972 is is a solution against address theft but it is complex and not deployed. In the context of WiND, the  https://tools.ietf.org/html/draft-ietf-6lo-ap-nd provides a complete solution

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

On Tue, May 28, 2019 at 12:46 PM Nabil Benamar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal,

Thank you for your comments. Please see ALL the changes that will be reflected in version -46. Let me know what is missing?

Abstract

OLD:

NEW:

Introduction

OLD:

NEW:

OLD:

   documents;

NEW:

OLD:

NEW:

OLD:

NEW:

4.2.  Frame Format

OLD:

   [IEEE-802.11-2016].

NEW:

OLD:

NEW:

OLD:

NEW:

OLD:

   Layer is described in

NEW:

OLD:

NEW:

  target='ll'/>.

OLD:

NEW:

          addresses.

OLD:

NEW:

OLD:

<Snap>

                                             These issues may be

NEW:

OLD:

NEW:

OLD:

NEW:

 OLD:

   Appendix J.

NEW:

OLD:

NEW:

Removed

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

On Tue, May 28, 2019 at 8:49 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Nabil:

All the best,

Pascal

From: Nabil Benamar <[email-masked]<mailto:[email-masked]>>
Sent: lundi 27 mai 2019 17:12
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

Hi Pascal,

We are converging :)

See below

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

Ø  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.
Yes, I support this idea to initiate a new draft in 6MAN. I'm in!

Ø  The introduction should clatify the scope, which appears to be do with what existing stacks can do and (sometimes) see what’s missing.
Here is the new introduction (first paragraph), are we missing something else?

present document."

  *

  *

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

Ø
Sounds good for me!

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

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

Ø   Yes, that works.

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

Ø    Good

All the best,

Pascal

Thank you once again.

All the best,

Pascal