Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11
draft-ietf-ipwave-ipv6-over-80211ocb-52

Received changes through RFC Editor sync (created alias RFC 8691, changed title to 'Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11', changed abstract to 'This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link.  Support for these methods and settings require minimal changes to existing stacks.  This document also describes limitations associated with using these methods.  Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work.', changed pages to 29, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-12-27, changed IESG state to RFC Published)

[Ballot comment]
Thanks for addressing my discuss!

One editorial high level comment: I seams like all text that was somehow deemed as out fo scope for the main body of this document got stuffed into the appendix. Please consider removing what is really not needed in this document as these pages also take review and RFC Editor time, especially as they seem to have received less review and therefore have more nits.

nit: sec 4.5.2 s/in OCB mode.A  A future improvement/in OCB mode. A future improvement/

[Ballot comment]
Thank you for addressing my DISCUSS and some of the COMMENTs.

(Resolved comments removed)

(5) Section 1.  Per “The resulting stack inherits from IPv6 over Ethernet [RFC2462], but operates over …”, what exactly is being inherited?  What does “inherited” mean in this case?

(6) Section 4.3.  Per “Among these types of addresses only the IPv6 link-local addresses can be formed using an EUI-64 identifier, in particular during transition time”, the meaning of the “in particular during transition time isn’t clear in the text.  Should it say "in particular as all clients are upgraded to this specification?"

(9) Section 5.  What is “protected 802.11” mentioned in “Such a link is less protected …”?

(10) Section 5.2.  SHA256 needs a reference.

(11) Editorial Nits
** Section 4.5.  Typo.  s/.A  A future/.  A future/

** Section 5.1.  Typo.  s/Futhermore/Furthermore/

** Section 5.1.  Typo.  s/pricavy/privacy/

** Section 5.2. Typo.  s/admninistered/ administered/

** Appendix H.  Duplicate word. s/section Section 2/Section 2/

[Ballot comment]
Remaining at No Record since I am balloting late, but:

It may be worth noting in the privacy/security considerations that an attacker may not heed to legal limits for radio power and can use a very sensitive directional antenna; if the attacker wishes to attack a given exchange they do not necessarily need to be in close physical proximity.

[Ballot comment]
A very simple point to fix, and Nabil has already queued it up for the next revision:
IEEE-802.11-2016 should be normative because it is the reference for 802.11-OCB and is the subject of a MUST in Section 4.2.

These are all editorial comments:

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

  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?

  If
  semantically opaque IIDs are needed, they MAY be generated using the
  method for generating semantically opaque IIDs

This isn’t wrong with the “MAY”, but I think it really is just a non-keyword “may”.

— 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

  An IPv6 subnet on which Neighbor Discovery protocol (ND) can be
  mapped on an OCB network if all nodes share a single broadcast
  Domain, which is generally the case for P2P OCB links;

This isn’t a complete sentence: it has a subject, but no verb.  What is it trying to say?  Also, the semicolon should be a period, as it’s not useful to chain it onto the following sentence.

  strict (e.g. fast drive through IP-RSU coverage)

The “e.g.” needs a comma after it (or change it to “such as with”), and “fast-drive-through” needs to be hyphenated, as a compound modifier.

— Section 5 —

  application-layer mechanisms are out-of-
  scope of this document.

Here, “out of scope” should not be hyphenated (it’s not a modifier).

  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?

  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]” ?

— Section 5.1 —

  A vehicle embarking an IP-
  OBU whose egress interface is 802.11-OCB may expose itself to
  eavesdropping and subsequent correlation of data; this may reveal
  data considered private by the vehicle owner; there is a risk of
  being tracked.

It’s awkward to chain three sentences with semicolons.  I would separate the first one: change the first semicolon into a period.

  as dynamically changing MAC addresses Section 5.2, semantically
  opaque Interface Identifiers and stable Interface Identifiers
  Section 4.4.

The two section references should be bracketed, as “[Section 5.2]”.

  Futhermore, for
  pricavy concerns ([RFC8065]) recommends

Make it, “Futhermore, for privacy concerns, [RFC8065] recommends“.

— Section 5.1.1 —

  means, or other visual information (car color, others) MAY constitute
  privacy risks.

This “MAY” should definitely be “may”: it’s just a statement of fact.

— Section 5.2 —

  In 802.11-OCB networks, the MAC addresses MAY change during well
  defined renumbering events.

Also a statement of fact, so “may”.

[Ballot discuss]
A very simple point to fix:

I think that IEEE-802.11-2016 should be normative because it is the reference for 802.11-OCB and is the subject of a MUST in Section 4.2.

[Ballot comment]
These are all editorial comments:

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

  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?

  If
  semantically opaque IIDs are needed, they MAY be generated using the
  method for generating semantically opaque IIDs

This isn’t wrong with the “MAY”, but I think it really is just a non-keyword “may”.

— 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

  An IPv6 subnet on which Neighbor Discovery protocol (ND) can be
  mapped on an OCB network if all nodes share a single broadcast
  Domain, which is generally the case for P2P OCB links;

This isn’t a complete sentence: it has a subject, but no verb.  What is it trying to say?  Also, the semicolon should be a period, as it’s not useful to chain it onto the following sentence.

  strict (e.g. fast drive through IP-RSU coverage)

The “e.g.” needs a comma after it (or change it to “such as with”), and “fast-drive-through” needs to be hyphenated, as a compound modifier.

— Section 5 —

  application-layer mechanisms are out-of-
  scope of this document.

Here, “out of scope” should not be hyphenated (it’s not a modifier).

  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?

  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]” ?

— Section 5.1 —

  A vehicle embarking an IP-
  OBU whose egress interface is 802.11-OCB may expose itself to
  eavesdropping and subsequent correlation of data; this may reveal
  data considered private by the vehicle owner; there is a risk of
  being tracked.

It’s awkward to chain three sentences with semicolons.  I would separate the first one: change the first semicolon into a period.

  as dynamically changing MAC addresses Section 5.2, semantically
  opaque Interface Identifiers and stable Interface Identifiers
  Section 4.4.

The two section references should be bracketed, as “[Section 5.2]”.

  Futhermore, for
  pricavy concerns ([RFC8065]) recommends

Make it, “Futhermore, for privacy concerns, [RFC8065] recommends“.

— Section 5.1.1 —

  means, or other visual information (car color, others) MAY constitute
  privacy risks.

This “MAY” should definitely be “may”: it’s just a statement of fact.

— Section 5.2 —

  In 802.11-OCB networks, the MAC addresses MAY change during well
  defined renumbering events.

Also a statement of fact, so “may”.

[Ballot discuss]
I support Roman's DISCUSS.

Overall I am unclear on the privacy properties of what this document specifies. I think it would help to have a clear statement about the circumstances under which each kind of address generation scheme is recommended. Were RFC 4941 addresses not considered because addresses generated according to RFC 8064 have functionally equivalent properties given how often moving vehicle change subnets? For link-local addresses, is it possible to give recommendations for when IIDs should be re-generated?

= Section 5.2 =

"An Interface ID SHOULD be of length specified in other documents."

Isn't the length specified for each of the two IID generation mechanisms discussed in Section 4.3 and 4.4?

= Section 5.3 =

"The demand for privacy protection of vehicles' and drivers'
  identities, which could be granted by using a pseudonym or alias
  identity at the same time, may hamper the required confidentiality of
  messages and trust between participants"

Pseudonymity and confidentiality are not mutually exclusive, so I think this is incorrect.

[Ballot comment]
Please expand OCB and STA on first use.

= Section 2 =

"Note: compliance with
  standards and regulations set in different countries when using the
  5.9GHz frequency band is required."

I'm not familiar with the standards and regulations being referenced here, but is there any specific reason why this needs to be said here? Presumably users of regulated spectrum bands the world over must comply with associated regulations governing their use. It's not clear to me that it makes sense to note this here.

= Section 5.1.1 =

"Further
  correlation of this information with other data captured by other
  means, or other visual information (car color, others) MAY constitute
  privacy risks."

The normative MAY is not appropriate here.

= Section 5.2 =

"In 802.11-OCB networks, the MAC addresses MAY change during well
  defined renumbering events."

The normative MAY is not appropriate here (since this is not the 802.11-OCB spec).

[Ballot discuss]
A few items per the text in the Security Considerations (Section 5):

(1) Section 5.  Per “A previous work at SAVI WG identifies some threats [RFC6959], while SeND presented in [RFC3971] and [RFC3972] is a solution against address theft but it is complex and not deployed.”, a few questions:

** What specific threats from RFC6959 are of concern?  Which mitigations for them are being proposed?

** Why mention SeND if it is “complex and not deployed”?

(2) Section 5.  Per “More IETF protocols are available in the toolbox of the IP security protocol designer.  Some ETSI protocols related to security protocols in ITS are described in [ETSI-sec-archi].”:

** Are there specific protocols to mention here?  Would they be different/OCB-specific than what was already noted in the beginning of the section -- “Any security mechanism as the IP layer or above that may be carried out …”?

** What specific ETSI protocols are being recommended from [ETSI-sec-archi]? 

(3) Section 5.2.  Per “An Interface ID SHOULD be of length specified in other documents”, what other documents?

(4) Section 5.3  I’m having trouble following this section – is this a discussion of a threat or mitigation?  The references to Section 4.4 and 5.0 didn’t clarity this for me.

** What is meant by the drivers’ identity in this case?  What is the pseudonym scheme is being used to protect it or what requirements are being set for it?

** What are the specific challenges of concern around pseudo-anonymization approaches to which an allusion is made?

** Who is the trusted third parted needed?

[Ballot discuss]
A few items per the text in the Security Considerations (Section 5):

(1) Section 5.  Per “A previous work at SAVI WG identifies some threats [RFC6959], while SeND presented in [RFC3971] and [RFC3972] is a solution against address theft but it is complex and not deployed.”, a few questions:

** What specific threats from RFC6959 are of concern?  Which mitigations for them are being proposed?

** Why mention SeND if it is “complex and not deployed”?

(2) Section 5.  Per “More IETF protocols are available in the toolbox of the IP security protocol designer.  Some ETSI protocols related to security protocols in ITS are described in [ETSI-sec-archi].”:

** Are there specific protocols to mention here?  Would they be different/OCB-specific than what was already noted in the beginning of the section -- “Any security mechanism as the IP layer or above that may be carried out …”?

** What specific ETSI protocols are being recommended from [ETSI-sec-archi]? 

(3) Section 5.2.  Per “An Interface ID SHOULD be of length specified in other documents”, what other documents?

(4) Section 5.3  I’m having trouble following this section – is this a discussion of a threat or mitigation?  The references to Section 4.4 and 5.0 didn’t clarity this for me.
** What is meant by the drivers’ identity in this case?  What is the pseudonym scheme is being used to protect it or what requirements are being set for it?

** What are the specific challenges of concern around pseudo-anonymization approaches to which an allusion is made?

** Who is the trusted third parted needed?

[Ballot discuss]
A few items per the text in the Security Considerations (Section 5):

(1) Section 5.  Per “A previous work at SAVI WG identifies some threats [RFC6959], while SeND presented in [RFC3971] and [RFC3972] is a solution against address theft but it is complex and not deployed.”, a few questions:

** What specific threats from RFC6959 are of concern?  Which mitigations for them are being proposed?
** Why mention SeND if it is “complex and not deployed”?

(2) Section 5.  Per “More IETF protocols are available in the toolbox of the IP security protocol designer.  Some ETSI protocols related to security protocols in ITS are described in [ETSI-sec-archi].”:

** Are there specific protocols to mention here?  Would they be different/OCB-specific than what was already noted in the beginning of the section -- “Any security mechanism as the IP layer or above that may be carried out …”?
** What specific ETSI protocols are being recommended from [ETSI-sec-archi]? 

(3) Section 5.2.  Per “An Interface ID SHOULD be of length specified in other documents”, what other documents?

(4) Section 5.3  I’m having trouble following this section – is this a discussion of a threat or mitigation?  The references to Section 4.4 and 5.0 didn’t clarity this for me.
** What is meant by the drivers’ identity in this case?  What is the pseudonym scheme is being used to protect it or what requirements are being set for it?
** What are the specific challenges of concern around pseudo-anonymization approaches to which an allusion is made?
** Who is the trusted third parted needed?

[Ballot comment]
(5) Section 1.  Per “The resulting stack inherits from IPv6 over Ethernet [RFC2462], but operates over …”, what exactly is being inherited?  What does “inherited” mean in this case?

(6) Section 4.3.  Per “Among these types of addresses only the IPv6 link-local addresses can be formed using an EUI-64 identifier, in particular during transition time”, the meaning of the “in particular during transition time isn’t clear to me.

(7) Section 5.  Per “The OCB operation is stripped off of …”, is this sentence saying that OCB operations doesn’t use 802.11 link layer security mechanisms, or does the OCB operation actively remove (i.e., strips) 802.11 link layer security mechanisms?  I’m getting caught up in the use of “stripped off”.

(8) Section 5, Per “Any attacker can therefore just sit in the near range of vehicles ... and performs attacks without needing to physically break any wall”, I’d recommend revising this sentence to reflect that it isn’t just vehicles and that active attacks are possible:

NEW:
Therefore, an attacker can sniff or inject traffic while within range of a vehicle or IP-RSU (by setting an interface card’s frequency to the proper range).

(9) Section 5.  What is “protected 802.11” mentioned in “Such a link is less protected …”?

(10) Section 5.2.  SHA256 needs a reference.

(11) Editorial Nits
** Table of Contents.  There is odd spacing in the title of Appendix C

** Section 1.  Typo.  s/Appendicies/Appendices/

** Section 1.  Typo.  s/Concretly/Concretely/

** Section 1.  Editorial.  s/[RFC1042], [RFC2464] ./[RFC1042 and [RFC2464]./

** Multiple sections. Editorial, to make an RFC citation a reference.  s/RFC2464/[RFC2464]/ and s/RFC 7217/[RFC7217]/

** Section 4.5.  Typo.  s/.A  A future/.  A future/

** Section 4.6. Typo.  s/links; The/links.  The/

** Section 5.1.  Typo.  s/Futhermore/Furthermore/

** Section 5.1.  Typo.  s/pricavy/privacy/

** Section 5.2. Typo.  s/admninistered/ administered/

** Appendix B.  s/Ammendment/Amendment/

** Appendix H.  Duplicate word. s/section Section 2/Section 2/

** Appendix I.  Typo.  s/specificed/specified/

** Appendix I. Typo.  s/Moreoever/Moreover/

[Ballot discuss]
One point on this sentence, which I believe was also commented in the TSV-ART review (Thanks Jörg!):

sec 4.2: "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."
I don't think this should be a MUST requirement. I assume the assumption here is that IP traffic is always some "random" data that is less important than other V2V communication. However, this is a generic mapping document and should therefore probably not make such an assumption (or at least it would need to be spelled out).

[Ballot comment]
One editorial high level comment: I seams like all text that was somehow deemed as out fo scope for the main body of this document got stuffed into the appendix. Please consider removing what is really not needed in this document as these pages also take review and RFC Editor time, especially as they seem to have received less review and therefore have more nits.

nit: sec 4.5.2 s/in OCB mode.A  A future improvement/in OCB mode. A future improvement/

[Ballot comment]
Thank you  for the work put into this document. Interesting use case ;-)

Beside the 3 COMMENTs below, I have a question: my understanding is that this is a P2P link, so, layer-3 multicast packets could easily be sent over unicast layer-2 IF the other peer is known with its layer-2 address which is possibly known when forming a OCB "association" (but I am not a WiFi person at all). Just curious here ;-)

Regards,

-éric

== COMMENTS ==

-- Section 3 --

It is unclear whether a IP-OBU <-> IP-OBU is a use case of this document (it is mentionned in 4.6 though but it would help the reader to have it mentioned in section 3).

-- Section 4.4 --

In the discussion of SLAAC, there should be a mention on the presence or absence of Router Advertisement and if RA are used:
- which entity sends this RA (probably IP-RSU),
- does RA contain PIO ?
- what are the recommendation for router lifetime (and PIO timers) ?

-- Missing --

Duplicate Address Detection is only mentioned in Appendix I and it is unclear whether optimistic DAD (even for LLA) should/must be used.

[Ballot comment]
§4.3: I think that the MAYs used in this section are out of place as they only state facts and not Normative behavior.  s/MAY/may

§4.5.2: "Future improvement to this specification SHOULD consider solutions for these problems."  I understand the interest to consider the problems...but I don't think there's any Normative action that results from using SHOULD.  s/SHOULD/should

1. Summary
The document shepherd is Carlos J. Bernardos. The responsible Area Director is
Suresh Krishnan.

This document specifies the mechanisms for transmission of IPv6 datagrams over
IEEE 802.11-OCB mode. It is based on existing IPv6 over Ethernet documents and
focuses on the aspects specific to IEEE 802.11-OCB mode. This document is the
main charter item of the IPWAVE working group, and the WG is quite sure that
this will be a useful Standards Track document.

2. Review and Consensus
The document has been reviewed several times within the WG. It also has been
reviewed by 6man (as specified in the IPWAVE WG charter). Authors have addressed
the comments received and 6man has not raised additional issues.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points
There are the following normative downrefs (according to the idnits tool):

** Downref: Normative reference to an Informational RFC: RFC 2818
** Downref: Normative reference to an Informational RFC: RFC 3753
** Downref: Normative reference to an Informational RFC: RFC 5889
** Downref: Normative reference to an Informational RFC: RFC 7721

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ipwave-ipv6-over-80211ocb-46, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-06-26):

From: The IESG
To: IETF-Announce
CC: its@ietf.org, Carlos Bernardos , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, cjbc@it.uc3m.es, suresh@kaloom.com, ipwave-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)) to Proposed Standard


The IESG has received a request from the IP Wireless Access in Vehicular
Environments WG (ipwave) to consider the following document: - 'Basic support
for IPv6 over IEEE Std 802.11 Networks operating Outside
  the Context of a Basic Service Set (IPv6-over-80211-OCB)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-06-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3753: Mobility Related Terminology (Informational - IETF stream)
    rfc7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms (Informational - IETF stream)
    rfc5889: IP Addressing Model in Ad Hoc Networks (Informational - IETF stream)
    rfc6959: Source Address Validation Improvement (SAVI) Threat Scope (Informational - IETF stream)

1. Summary
The document shepherd is Carlos J. Bernardos. The responsible Area Director is
Suresh Suresh Krishnan.

This document specifies the mechanisms for transmission of IPv6 datagrams over
IEEE 802.11-OCB mode. It is based on existing IPv6 over Ethernet documents and
focuses on the aspects specific to IEEE 802.11-OCB mode. This document is the
main charter item of the IPWAVE working group, and the WG is quite sure that
this will be a useful Standards Track document.

2. Review and Consensus
The document has been reviewed several times within the WG. It also has been
reviewed by 6man (as specified in the IPWAVE WG charter). Authors have addressed
the comments received and 6man has not raised additional issues.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points
There are the following normative downrefs (according to the idnits tool):

** Downref: Normative reference to an Informational RFC: RFC 2818
** Downref: Normative reference to an Informational RFC: RFC 3753
** Downref: Normative reference to an Informational RFC: RFC 5889
** Downref: Normative reference to an Informational RFC: RFC 7721

1. Summary
The document shepherd is Carlos J. Bernardos. The responsible Area Director is
Suresh Suresh Krishnan.

This document specifies the mechanisms for transmission of IPv6 datagrams over
IEEE 802.11-OCB mode. It is based on existing IPv6 over Ethernet documents and
focuses on the aspects specific to IEEE 802.11-OCB mode. This document is the
main charter item of the IPWAVE working group, and the WG is quite sure that
this will be a useful Standards Track document.

2. Review and Consensus
The document has been reviewed several times within the WG. It also has been
reviewed by 6man (as specified in the IPWAVE WG charter). Authors have addressed
the comments received and 6man has not raised additional issues.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points
There are the following normative downrefs (according to the idnits tool):

** Downref: Normative reference to an Informational RFC: RFC 2818
** Downref: Normative reference to an Informational RFC: RFC 3753
** Downref: Normative reference to an Informational RFC: RFC 5889
** Downref: Normative reference to an Informational RFC: RFC 7721

Request for posting confirmation emailed to previous authors: Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Alexandre Petrescu , Tony Li , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Alexandre Petrescu , Tony Li , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Alexandre Petrescu , Tony Li , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Alexandre Petrescu , Tony Li , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Alexandre Petrescu , Tony Li , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Alexandre Petrescu , Tony Li , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Nabil Benamar , Christian Huitema , Jong-Hyouk Lee , Alexandre Petrescu , Tony Li , Jerome Haerri , Thierry Ernst , ipwave-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Jerome Haerri" , "Tony Li" , "Thierry Ernst" , "Nabil Benamar" , "Christian Huitema" , "Jong-Hyouk Lee" , "Alexandre Petrescu" , ipwave-chairs@ietf.org