rfc8691xml2.original.xml   rfc8691.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- [rfced] updated by Chris /09/05/19 -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<rfc submissionType="IETF" category="std" consensus="yes" number="XXXX" ipr="tru <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
st200902"> category="std" consensus="true" number="8691" docName="draft-ietf-ipwave-ip
v6-over-80211ocb-52" ipr="trust200902" obsoletes="" updates="" xml:lang="en" toc
Include="true" symRefs="true" sortRefs="true" version="3">
<!-- category values: std, bcp, info, exp, and historic ipr values: <!-- xml2rfc v2v3 conversion 2.31.0 -->
trust200902, noModificationTrust200902,
noDerivativesTrust200902, or pre5378Trust200902 you can add the
attributes updates="NNNN" and obsoletes="NNNN" they will
automatically be output with "(if approved)" -->
<front> <front>
<title abbrev="IPv6 over 802.11-OCB">
<title abbrev="IPv6-over-80211-OCB"> Basic Support for IPv6 Networks Operating Outside the Context of a Basic
Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside the Service Set over IEEE Std 802.11
Context of a Basic Service Set
</title> </title>
<seriesInfo name="RFC" value="8691"/>
<author initials='N.' surname="Benamar" fullname='Nabil Benamar'> <author initials="N." surname="Benamar" fullname="Nabil Benamar">
<organization>Moulay Ismail University of Meknes</organization> <organization>Moulay Ismail University of Meknes</organization>
<address> <address>
<postal> <postal>
<street> <street>
</street> </street>
<city> <city>
</city> </city>
<region> <region>
</region> </region>
<code> <code>
skipping to change at line 54 skipping to change at line 39
</country> </country>
</postal> </postal>
<phone> <phone>
+212670832236 +212670832236
</phone> </phone>
<email> <email>
n.benamar@est.umi.ac.ma n.benamar@est.umi.ac.ma
</email> </email>
</address> </address>
</author> </author>
<author initials="J." surname="Härri" fullname="Jérôme Härri">
<author initials="J." surname="Haerri" fullname="Jerome Haerri"> <organization>EURECOM</organization>
<organization>Eurecom</organization>
<address> <address>
<postal> <postal>
<street> <street>
</street> </street>
<city> Sophia-Antipolis <city>Sophia-Antipolis</city>
</city>
<region> <region>
</region> </region>
<code> 06904 <code>06904</code>
</code>
<country> <country>
France France
</country> </country>
</postal> </postal>
<phone> <phone>
+33493008134 +33493008134
</phone> </phone>
<email> <email>
Jerome.Haerri@eurecom.fr Jerome.Haerri@eurecom.fr
</email> </email>
</address> </address>
</author> </author>
<author fullname="Jong-Hyouk Lee" initials="J." surname="Lee">
<author fullname="Jong-Hyouk Lee" initials="J.-H." surname="Lee"> <organization>Sangmyung University</organization>
<organization>
Sangmyung University
</organization>
<address> <address>
<postal> <postal>
<street> <street>
31, Sangmyeongdae-gil, Dongnam-gu 31, Sangmyeongdae-gil, Dongnam-gu
</street> </street>
<code> <code>
31066 31066
</code> </code>
<city> <city>
Cheonan Cheonan
</city> </city>
<country> <country>
Republic of Korea Republic of Korea
</country> </country>
</postal> </postal>
<email> <email>
jonghyouk@smu.ac.kr jonghyouk@smu.ac.kr
</email> </email>
</address> </address>
</author> </author>
<author initials="T." surname="Ernst" fullname="Thierry ERNST">
<author initials="T." surname="Ernst" fullname="Thierry Ernst">
<organization>YoGoKo</organization> <organization>YoGoKo</organization>
<address> <address>
<postal> <postal>
<street> <street>1137A Avenue des Champs-Blancs</street>
</street> <city>CESON-SEVIGNE</city>
<city> <region></region>
</city> <code>35510</code>
<region>
</region>
<code>
</code>
<country> <country>
France France
</country> </country>
</postal> </postal>
<phone> <phone />
</phone>
<email> <email>
thierry.ernst@yogoko.fr thierry.ernst@yogoko.fr
</email> </email>
</address> </address>
</author> </author>
<date year="2019" month="December"/>
<date year='2019' month="September"/>
<!-- Meta-data Declarations -->
<area>Internet</area> <area>Internet</area>
<workgroup>IPWAVE Working Group</workgroup> <workgroup>IPWAVE Working Group</workgroup>
<keyword>IPv6 over 802.11p</keyword>
<!-- WG name at the upperleft corner of the doc, IETF is fine for <keyword>OCB</keyword>
individual submissions. If this element is not present, the <keyword>IPv6 over 802.11-OCB</keyword>
default is "Network Working Group", which is used by the RFC
Editor as a nod to the history of the IETF. -->
<keyword>
IPv6 over 802.11p, OCB, IPv6 over 802.11-OCB
</keyword>
<!-- Keywords will be incorporated into HTML output files in a
meta tag but they have no effect on text or nroff output. If
you submit your draft to the RFC Editor, the keywords will be
used for the search engine. -->
<abstract> <abstract>
<t> <t>
This document provides methods and settings, This document provides methods and settings
for using IPv6 to communicate among nodes within range of one another 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 over a single IEEE 802.11-OCB link. Support for these methods and
settings require minimal changes to existing stacks. This document settings require minimal changes to existing stacks. This document
also describes limitations associated with using these methods. also describes limitations associated with using these methods.
Optimizations and usage of IPv6 over more complex scenarios Optimizations and usage of IPv6 over more complex scenarios
is not covered in this specification and is subject of future work. are not covered in this specification and are a subject for future work.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
This document provides a baseline for using IPv6 to This document provides a baseline for using IPv6 to
communicate among nodes in range of one another over a single IEEE 802.1 1-OCB link communicate among nodes in range of one another over a single IEEE 802.1 1-OCB link
<xref target="IEEE-802.11-2016"/> (a.k.a., "802.11p" see <xref target='i <xref target="IEEE-802.11-2016" format="default"/> (a.k.a., 802.11p;
802.11p'/>, see Appendices <xref target="i802.11p" format="counter"/>,
<xref target='introduced-by-OCB'/> and <xref target='software-changes'/> <xref target="introduced-by-OCB" format="counter"/>, and <xref target="s
) oftware-changes" format="counter"/>)
with minimal changes to existing stacks. Moreover, the document identifi with minimal changes to existing stacks. Moreover, the document
es limitations identifies the limitations
of such usage. Concretely, the document describes the layering of such usage. Concretely, the document describes the layering
of IPv6 networking on top of the IEEE Std 802.11 MAC layer or an IEEE St d 802.3 of IPv6 networking on top of the IEEE Std 802.11 MAC layer or an IEEE St d 802.3
MAC layer with a frame translation underneath. The resulting stack is de rived from IPv6 MAC layer with a frame translation underneath. The resulting stack is de rived from IPv6
over Ethernet <xref target='RFC2464'/>, but operates over 802.11-OCB to over Ethernet <xref target="RFC2464" format="default"/> but operates ove
provide at least P2P (Point to Point) connectivity r 802.11-OCB to provide at least P2P (point-to-point) connectivity
using IPv6 ND and link-local addresses. using IPv6 Neighbor Discovery (ND) and link-local addresses.
</t> </t>
<t> <t>
The IPv6 network layer operates on 802.11-OCB in the same The IPv6 network layer operates on 802.11-OCB in the same
manner as operating on Ethernet with the following manner as operating on the Ethernet with the following
exceptions: exceptions:
</t> </t>
<t> <ul spacing="normal">
<list style='symbols'> <li>
<t> Exceptions due to the different operation of the IPv6 network
Exceptions due to different operation of IPv6 network layer on 802.11 compared to the Ethernet. The operation of IP
layer on 802.11 than on Ethernet. The operation of IP on Ethernet is described in <xref target="RFC1042" format="default"/> an
on Ethernet is described in <xref target='RFC1042'/> and <xref d <xref target="RFC2464" format="default"/>.
target='RFC2464'/>.
</t> </li>
<t> <li>
Exceptions due to the OCB nature of 802.11-OCB compared to Exceptions due to the OCB nature of 802.11-OCB compared to
802.11. This has impacts on security, privacy, subnet 802.11. This has impacts on security, privacy, subnet
structure and movement detection. Security and structure, and movement detection. Security and
privacy recommendations are discussed in <xref target='Security'/> an privacy recommendations are discussed in Sections <xref
d target="slaac" format="counter"/> and <xref target="Security" format=
<xref target='slaac'/>. The subnet structure is described "counter"/>. The subnet structure is described
in <xref target='subnet-structure'/>. The movement in <xref target="subnet-structure" format="default"/>. The movement
detection on OCB links is not described in this document. detection on OCB links is not described in this document.
Likewise, ND Extensions and IPWAVE optimizations for vehicular communica Likewise, ND extensions and IP Wireless Access in Vehicular
tions are Environments (IPWAVE) optimizations for vehicular communications are
not in scope. The expectation is that further specifications will be ed not in scope of this document. The expectation is that further specific
ited to cover ations will be edited to cover
more complex vehicular networking scenarios. more complex vehicular networking scenarios.
</t> </li>
</list> </ul>
</t>
<t> <t>
The reader may refer to <xref target='IPWAVE-NETWORKING'/> for an overvi The reader may refer to <xref target="I-D.ietf-ipwave-vehicular-networki
ew of ng" format="default"/> for an overview of
problems related to running IPv6 over 802.11-OCB. It is out of scope of problems related to running IPv6 over 802.11-OCB. It is out of scope
this document to reiterate those. of this document to reiterate those problems.
</t> </t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section title="Terminology" <name>Terminology</name>
anchor='terminology'> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
interpreted as described in BCP 14 be interpreted as
<!-- <xref target="BCP14"/> --> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<xref target="RFC2119"/> <xref target="RFC8174" /> when, and when, and only when, they appear in all capitals, as shown here.
only when, they appear in all capitals, as shown here. </t>
</t>
<t> <t>
The document makes uses of the following terms: The document makes uses of the following terms:</t>
IP-OBU (Internet Protocol On-Board Unit): an IP-OBU denotes a <dl newline="true">
<dt>IP-OBU (Internet Protocol On-Board Unit):</dt>
<dd>An IP-OBU denotes a
computer situated in a vehicle such as a car, bicycle, computer situated in a vehicle such as a car, bicycle,
or similar. It has at least one IP interface that runs in or similar. It has at least one IP interface that runs in
mode OCB of 802.11, and that has an "OBU" transceiver. See mode OCB of 802.11 and has an "OBU" transceiver. See
the definition of the term "OBU" in section <xref the definition of the term "OBU" in <xref target="extra-terminology" form
target='extra-terminology'/>. at="default"/>.</dd>
</t> <dt>IP-RSU (IP Roadside Unit):</dt>
<t> <dd>An IP-RSU is situated along the
IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the
road. It has at least two distinct IP-enabled interfaces. The road. It has at least two distinct IP-enabled interfaces. The
wireless PHY/MAC layer of at least one of its IP-enabled wireless PHY/MAC layer of at least one of its IP-enabled
interfaces is configured to operate in 802.11-OCB mode. An interfaces is configured to operate in 802.11-OCB mode. An
IP-RSU communicates with the IP-OBU in the vehicle over 802.11 IP-RSU communicates with the IP-OBU over an 802.11
wireless link operating in OCB mode. An IP-RSU is similar to wireless link operating in OCB mode. An IP-RSU is similar to
an Access Network Router (ANR) defined in <xref an Access Network Router (ANR), defined in <xref target="RFC3753" format
target="RFC3753"/>, and a Wireless Termination Point (WTP) ="default"/>, and a Wireless Termination Point (WTP),
defined in <xref target='RFC5415'/>. defined in <xref target="RFC5415" format="default"/>.</dd>
</t> <dt>OCB (outside the context of a Basic Service Set - BSS):</dt>
<t> <dd>This is a mode
OCB (outside the context of a basic service set - BSS): is a mode of operation in which a station (STA) is not a member of a BSS and does
of operation in which a STA is not a member of a BSS and does
not utilize IEEE Std 802.11 authentication, association, or not utilize IEEE Std 802.11 authentication, association, or
data confidentiality. data confidentiality.</dd>
</t> <dt>802.11-OCB:</dt><dd> This refers to the mode specified in IEEE Std 802.11-20
<t> 16 when the
802.11-OCB: refers to the mode specified in IEEE Std 802.11-2016 when th MIB attribute dot11OCBActivited is 'true'.</dd>
e </dl>
MIB attribute dot11OCBActivited is 'true'.
</t>
</section>
<section </section>
title="Communication Scenarios where IEEE 802.11-OCB Links are Used" <section numbered="true" toc="default">
> <name>Communication Scenarios Where IEEE 802.11-OCB Links Are Used</name>
<t> <t>
The IEEE 802.11-OCB networks are used for vehicular IEEE 802.11-OCB networks are used for vehicular
communications, as 'Wireless Access in Vehicular communications as 'Wireless Access in Vehicular
Environments'. In particular, we refer the reader to <xref Environments'. In particular, we refer the reader to <xref target="I-D.i
target='IPWAVE-NETWORKING'/>, that lists etf-ipwave-vehicular-networking" format="default"/>, which lists
some scenarios and requirements for IP in Intelligent some scenarios and requirements for IP in Intelligent
Transportation Systems (ITS). Transportation Systems (ITS).
</t> </t>
<t> <t>
The link model is the following: STA --- 802.11-OCB --- STA. The link model is the following: STA --- 802.11-OCB --- STA.
In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. 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 All links are assumed to be P2P, and multiple links can be on one radio
interface. While 802.11-OCB is clearly specified, and a legacy IPv6 interface. While 802.11-OCB is clearly specified and a legacy IPv6
stack can operate on such links, the use of the operating environment stack can operate on such links, the use of the operating environment
(vehicular networks) brings in new perspectives. (vehicular networks) brings in new perspectives.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section <name>IPv6 over 802.11-OCB</name>
title="IPv6 over 802.11-OCB"> <section anchor="MTU" numbered="true" toc="default">
<name>Maximum Transmission Unit (MTU)</name>
<section title="Maximum Transmission Unit (MTU)"
anchor="MTU">
<t> <t>
The default MTU for IP packets on 802.11-OCB is inherited The default MTU for IP packets on 802.11-OCB is inherited
from <xref target='RFC2464'/> and is, as such, 1500 octets. from <xref target="RFC2464" format="default"/> and, as such, is 1500 o
As noted in <xref target="RFC8200"/>, every link on the Internet must ctets.
have a As noted in <xref target="RFC8200" format="default"/>, every link on t
minimum MTU of 1280 octets, as well as follow the other he Internet must have a
minimum MTU of 1280 octets and must follow the other
recommendations, especially with regard to fragmentation. recommendations, especially with regard to fragmentation.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Frame Format"> <name>Frame Format</name>
<t> <t>
IP packets MUST be transmitted over 802.11-OCB media as QoS IP packets <bcp14>MUST</bcp14> be transmitted over 802.11-OCB media as
Data frames whose format is specified in IEEE 802.11 spec QoS
<xref target="IEEE-802.11-2016"></xref>. data frames whose format is specified in an IEEE 802.11 spec
</t> <xref target="IEEE-802.11-2016" format="default"/>.
<t> </t>
The IPv6 packet transmitted on 802.11-OCB are <t>
The IPv6 packet transmitted on 802.11-OCB is
immediately preceded by a Logical Link Control (LLC) header immediately preceded by a Logical Link Control (LLC) header
and an 802.11 header. In the LLC header, and in accordance and an 802.11 header. In the LLC header and in accordance
with the EtherType Protocol Discrimination (EPD, see <xref with EtherType Protocol Discrimination (EPD; see <xref target="epd" for
target='epd'/>), the value of the Type field MUST be set to mat="default"/>), the value of the Type field <bcp14>MUST</bcp14> be set to
0x86DD (IPv6). The mapping to the 802.11 data service SHOULD 0x86DD (IPv6). The mapping to the 802.11 data service <bcp14>SHOULD</b
cp14>
use a 'priority' value of 1 (QoS with a 'Background' user priority), use a 'priority' value of 1 (QoS with a 'Background' user priority),
reserving higher priority values for safety-critical and time-sensitive reserving higher priority values for safety-critical and time-sensitive
traffic, including the ones listed in <xref target="ETSI-sec-archi"></xref >. traffic, including the ones listed in <xref target="ETSI-sec-archi" format ="default"/>.
</t> </t>
<t> <t>
To simplify the Application Programming Interface (API) To simplify the Application Programming Interface (API)
between the operating system and the 802.11-OCB media, between the operating system and the 802.11-OCB media,
device drivers MAY implement IPv6-over-Ethernet as per <xref target='RF C2464'/> device drivers <bcp14>MAY</bcp14> implement IPv6 over Ethernet as per < xref target="RFC2464" format="default"/>
and then a frame translation from 802.3 to 802.11 in order and then a frame translation from 802.3 to 802.11 in order
to minimize the code changes. to minimize the code changes.
</t> </t>
<!-- <t> -->
<!-- <list style='hanging'> -->
<!-- <t hangText="1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1"> -->
<!-- <vspace/> -->
<!-- is the binary representation of the EtherType value -->
<!-- 0x86DD. -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
</section> </section>
<section anchor='ll' title='Link-Local Addresses'> <section anchor="ll" numbered="true" toc="default">
<t> <name>Link-Local Addresses</name>
There are several types of IPv6 addresses <xref <t>
target='RFC4291'/>, <xref target='RFC4193'/>, that may be There are several types of IPv6 addresses <xref target="RFC4291" format
="default"/> <xref target="RFC4193" format="default"/> that may be
assigned to an 802.11-OCB interface. Among these types of assigned to an 802.11-OCB interface. Among these types of
addresses only the IPv6 link-local addresses can be formed addresses, only the IPv6 link-local addresses can be formed
using an EUI-64 identifier, in particular during transition using an EUI-64 identifier, particularly during transition
time, (the time spent before an interface starts using a different addr time (the period of time before an interface starts using an address
ess than the LL one). different from the LL one).
</t> </t>
<t> <t>
If the IPv6 link-local address is formed using an EUI-64 If the IPv6 link-local address is formed using an EUI-64
identifier, then the mechanism of forming that address is identifier, then the mechanism for forming that address is
the same mechanism as used to form an IPv6 link-local the same mechanism as that used to form an IPv6 link-local
address on Ethernet links. Moreover, whether or not the interface address on Ethernet links. Moreover, regardless of whether the interfac
identifier is derived from the EUI-64 identifier, its length is 64 bits as e
is the case for Ethernet <xref target='RFC2464'/>. identifier is derived from the EUI-64 identifier, its length is 64 bits,
</t> as is the case for the Ethernet <xref target="RFC2464" format="default"/>.
</t>
</section> </section>
<section anchor="slaac" numbered="true" toc="default">
<section title='Stateless Autoconfiguration' <name>Stateless Autoconfiguration</name>
anchor='slaac'> <t>
<t>
The steps a host takes in deciding how to The steps a host takes in deciding how to
autoconfigure its interfaces in IPv6 are described autoconfigure its interfaces in IPv6 are described
in <xref target='RFC4862'/>. This section describes in <xref target="RFC4862" format="default"/>. This section describes
the formation of Interface Identifiers for IPv6 addresses of the formation of Interface Identifiers for 'Global' or 'Unique Local' I
type 'Global' or 'Unique Local'. Interface Identifiers Pv6 addresses. Interface Identifiers
for IPv6 address of type 'Link-Local' are discussed in <xref target='ll for 'link-local' IPv6 addresses are discussed in <xref target="ll" form
'/>. at="default"/>.
</t> </t>
<t> <t>
The RECOMMENDED method for forming The <bcp14>RECOMMENDED</bcp14> method for forming
stable Interface Identifiers (IIDs) is described in <xref stable Interface Identifiers (IIDs) is described in <xref target="RFC8
target='RFC8064'/>. The method of forming IIDs described in 064" format="default"/>. The method of forming IIDs described in
Section 4 of <xref target='RFC2464'/> MAY be used during <xref target="RFC2464" sectionFormat="of" section="4"/> <bcp14>MAY</bc
transition time, in particular for IPv6 link-local p14> be used during
addresses. Regardless of how to form the IID, transition time, particularly for IPv6 link-local
its length is 64 bits, similarely to IPv6 over Ethernet <xref target=' addresses. Regardless of the method used to form the IID,
RFC2464'/>. its length is 64 bits, similarly to IPv6 over Ethernet <xref target="R
FC2464" format="default"/>.
</t> </t>
<t> <t>
The bits in the IID have no specific meaning The bits in the IID have no specific meaning,
and the identifier should be treated as an opaque value. and the identifier should be treated as an opaque value.
The bits 'Universal' and 'Group' in the identifier of an The bits 'Universal' and 'Group' in the identifier of an
802.11-OCB interface are significant, as this is an IEEE 802.11-OCB interface, which is an IEEE link-layer address, are
link-layer address. The details of this significance are significant. The details of this significance are
described in <xref target="RFC7136"/>. described in <xref target="RFC7136" format="default"/>.
</t> </t>
<t> <t>
Semantically opaque IIDs, instead of Semantically opaque IIDs, instead of
meaningful IIDs derived from a valid and meaningful IIDs derived from a valid and
meaningful MAC address (<xref target='RFC2464'/>, Section meaningful MAC address (<xref target="RFC2464" sectionFormat="comma" se
4), help avoid certain privacy risks (see the risks ction="4"/>), help avoid certain privacy risks (see the risks
mentioned in <xref target='privacy-opaque-iid'/>). If mentioned in <xref target="privacy-opaque-iid" format="default"/>). If
semantically opaque IIDs are needed, they semantically opaque IIDs are needed, they
may be generated using the method for generating may be generated using the method for generating
semantically opaque IIDs with IPv6 semantically opaque IIDs with IPv6
Stateless Address Autoconfiguration given in <xref Stateless Address Autoconfiguration given in <xref target="RFC7217" for
target="RFC7217"/>. Typically, an opaque IID is formed starting from i mat="default"/>. Typically, an opaque IID is formed starting from identifiers d
dentifiers different ifferent
than the MAC addresses, and from cryptographically strong from the MAC addresses and from cryptographically strong
material. Thus, privacy sensitive information is absent material. Thus, privacy-sensitive information is absent
from Interface IDs, because it is impossible to calculate from Interface IDs because it is impossible to calculate
back the initial value from which the Interface ID was first back the initial value from which the Interface ID was first
generated. generated.
</t> </t>
<t>
<!-- A valid MAC address includes a unique identifier pointing to -->
<!-- a company together with its postal address, and a unique -->
<!-- number within that company MAC space (see the oui.txt file). -->
<!-- The calculation operation of the MAC address back from a -->
<!-- given meaningful Interface Identifier is straightforward -->
<!-- (<xref target='RFC2464'/>, section 4). The Interface -->
<!-- Identifier is part of an IPv6 address that is stored in IPv6 -->
<!-- packets. -->
</t>
<t> <t>
Some applications that use IPv6 packets on 802.11-OCB links Some applications that use IPv6 packets on 802.11-OCB links
(among other link types) may benefit from IPv6 addresses (among other link types) may benefit from IPv6 addresses
whose IIDs don't change too often. It is whose IIDs don't change too often. It is
RECOMMENDED to use the mechanisms described in RFC 7217 to <bcp14>RECOMMENDED</bcp14> to use the mechanisms described in <xref tar
permit the use of Stable IIDs that do not get="RFC7217"/> to
permit the use of stable IIDs that do not
change within one subnet prefix. A possible source for the change within one subnet prefix. A possible source for the
Net-Iface Parameter is a virtual interface name, or logical Net_Iface parameter is a virtual interface name or logical
interface name, that is decided by a local administrator. interface name that is decided by a local administrator.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title='Address Mapping'> <name>Address Mapping</name>
<t> <t>
Unicast and multicast address mapping MUST follow the Unicast and multicast address mapping <bcp14>MUST</bcp14> follow the
procedures specified for Ethernet interfaces specified in Sections 6 procedures specified for Ethernet interfaces described in in Sections <
and 7 of <xref target='RFC2464'/>. xref
target="RFC2464" sectionFormat="bare" section="6"/> and <xref
target="RFC2464" sectionFormat="bare" section="7"/> of <xref target="RF
C2464"/>.
</t> </t>
<section numbered="true" toc="default">
<section title='Address Mapping -- Unicast'> <name>Address Mapping -- Unicast</name>
<t> <t>
This document is scoped for Address Resolution (AR) and Duplicate Add This document is scoped for Address Resolution (AR) and Duplicate Add
ress Detection (DAD) per <xref ress Detection (DAD) per <xref target="RFC4862" format="default"/>.
target="RFC4862"/>. </t>
</t>
</section> </section>
<section anchor="address-mapping-multicast" numbered="true" toc="default
">
<name>Address Mapping -- Multicast</name>
<section anchor="address-mapping-multicast" title="Address Mapping -- Mu <t>
lticast">
<t>
The multicast address mapping is performed according to The multicast address mapping is performed according to
the method specified in section 7 of <xref the method specified in <xref section="7" target="RFC2464" sectionFor
target='RFC2464'/>. The meaning of the value "3333" mat="of"/>. The meaning of the value "33-33"
mentioned there is mentioned there is
defined in section 2.3.1 of <xref target='RFC7042'/>. defined in <xref target="RFC7042"
</t> sectionFormat="of" section="2.3.1"/>.
</t>
<t> <t>
Transmitting IPv6 packets to multicast destinations over Transmitting IPv6 packets to multicast destinations over
802.11 links proved to have some performance issues <xref 802.11 links proved to have some performance issues <xref target="I-
target='ieee802-MCAST'/>. These D.ietf-mboned-ieee802-mcast-problems" format="default"/>. These
issues may be exacerbated in OCB mode. issues may be exacerbated in OCB mode.
A future improvement to this specification should consider solutions for these problems. Future improvement to this specification should consider solutions f or these problems.
</t> </t>
</section> </section>
</section> </section>
<section anchor="subnet-structure" numbered="true" toc="default">
<section title='Subnet Structure' anchor='subnet-structure'> <name>Subnet Structure</name>
<t> <t>
When vehicles are in close range, a subnet may be formed over When vehicles are in close range, a subnet may be formed over
802.11-OCB interfaces (not by their in-vehicle interfaces). 802.11-OCB interfaces (not by their in-vehicle interfaces).
A Prefix List conceptual data structure (<xref A Prefix List conceptual data structure (<xref target="RFC4861"
target='RFC4861'/> Section 5.1) is maintained for each sectionFormat="comma" section="5.1"/>) is maintained for each
802.11-OCB interface. 802.11-OCB interface.
</t> </t>
<t>
<t> The IPv6 Neighbor Discovery protocol (ND) requires reflexive properties
IPv6 Neighbor Discovery protocol (ND) requires reflexive properties (bidirectional connectivity), which is generally, though not always, the c
(bidirectional connectivity) which is generally, though not always, the ca ase for P2P OCB links.
se for P2P OCB links.
IPv6 ND also requires transitive properties for DAD and AR, so an IPv6 sub net can be mapped IPv6 ND also requires transitive properties for DAD and AR, so an IPv6 sub net can be mapped
on an OCB network only if all nodes in the network share a single physical on an OCB network only if all nodes in the network share a single
broadcast domain. physical broadcast domain. The extension to IPv6 ND operating on a
The extension to IPv6 ND operating on a subnet that covers multiple OCB li subnet that covers multiple OCB links and does not fully overlap
nks (i.e., non-broadcast multi-access (NBMA)) is not in scope of this document
and not fully overlapping (NBMA) is not in scope. .
Finally, IPv6 ND requires a permanent connectivity of all nodes in the sub Finally, IPv6 ND requires permanent connectivity of all nodes in the subne
net t
to defend their addresses, in other words very stable network conditions. to defend their addresses -- in other words, very stable network condition
s.
</t>
<t> </t>
The structure of this subnet is ephemeral, in that it is <t>
The structure of this subnet is ephemeral in that it is
strongly influenced by the mobility of vehicles: the hidden strongly influenced by the mobility of vehicles: the hidden
terminal effects appear; the 802.11 networks in OCB mode may terminal effects appear, and the 802.11 networks in OCB mode may
be considered as 'ad-hoc' networks with an addressing model be considered ad hoc networks with an addressing model,
as described in <xref target='RFC5889'/>. On another hand, as described in <xref target="RFC5889" format="default"/>. On the othe
r hand,
the structure of the internal subnets in each vehicle is the structure of the internal subnets in each vehicle is
relatively stable. relatively stable.
</t> </t>
<t>
<t> As recommended in <xref target="RFC5889" format="default"/>, when the t
As recommended in <xref target='RFC5889'/>, when the timing iming
requirements are very strict (e.g., fast-drive-through IP-RSU requirements are very strict (e.g., fast-drive-through IP-RSU
coverage), no on-link subnet prefix should be configured on coverage), no on-link subnet prefix should be configured on
an 802.11-OCB interface. In such cases, the exclusive use an 802.11-OCB interface. In such cases, the exclusive use
of IPv6 link-local addresses is RECOMMENDED. of IPv6 link-local addresses is <bcp14>RECOMMENDED</bcp14>.
</t> </t>
<t>
<t>
Additionally, even if the timing requirements are not very Additionally, even if the timing requirements are not very
strict (e.g., the moving subnet formed by two following strict (e.g., the moving subnet formed by two following
vehicles is stable, a fixed IP-RSU is absent), the subnet is vehicles is stable, a fixed IP-RSU is absent), the subnet is
disconnected from the Internet (i.e., a default route is absent), disconnected from the Internet (i.e., a default route is absent),
and the addressing peers are equally qualified (that is, it is impossib le and the addressing peers are equally qualified (that is, it is impossib le
to determine that some vehicle owns and distributes to determine whether some vehicle owns and distributes
addresses to others) the use of link-local addresses is addresses to others), the use of link-local addresses is
RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
</t> </t>
<t>
<t> The baseline ND protocol <xref target="RFC4861" format="default"/> <bc
The baseline ND protocol <xref p14>MUST</bcp14> be supported over 802.11-OCB links.
target='RFC4861'/> MUST be supported over 802.11-OCB links.
Transmitting ND packets may prove to have some performance Transmitting ND packets may prove to have some performance
issues as mentioned in <xref target='address-mapping-multicast'/>, and issues, as mentioned in <xref target="address-mapping-multicast" forma
<xref target='nd-wireless'/>. t="default"/> and
<xref target="nd-wireless" format="default"/>.
These issues may be exacerbated in OCB mode. These issues may be exacerbated in OCB mode.
Solutions for these problems should consider the OCB mode Solutions for these problems should consider the OCB mode
of operation. Future solutions to OCB should consider solutions of operation. Future solutions to OCB should consider solutions
for avoiding broadcast. The best of current knowledge for avoiding broadcast. The best of current knowledge
indicates the kinds of issues that may arise with ND in indicates the kinds of issues that may arise with ND in
OCB mode; they are described in <xref target="nd-wireless"/>. OCB mode; they are described in <xref target="nd-wireless" format="defaul
</t> t"/>.
</t>
<!-- <t> --> <t>
<!-- The Neighbor Discovery protocol (ND) <xref --> Protocols like Mobile IPv6 <xref target="RFC6275" format="default"/>
<!-- target='RFC4861'/> is used over 802.11-OCB links. The --> <xref target="RFC3963" format="default"/> and
<!-- reliability of the ND protocol over 802.11-OCB is the --> DNAv6 <xref target="RFC6059" format="default"/>, which depend on timely
<!-- reliability of the delivery of ND multicast messages. This -->
<!-- reliability is the same as the reliability of delivery of ND -->
<!-- multicast messages over 802.11 links operated with a BSS ID. -->
<!-- </t> -->
<t>
Protocols like Mobile IPv6 <xref target='RFC6275'/> , <xref target='RFC
3963'/> and
DNAv6 <xref target='RFC6059'/>, which depend on a timely
movement detection, might need additional tuning work to movement detection, might need additional tuning work to
handle the lack of link-layer notifications during handover. handle the lack of link-layer notifications during handover.
This is for further study. This topic is left for further study.
</t> </t>
<!-- <t> -->
<!-- The operation of the Mobile IPv6 protocol over 802.11-OCB -->
<!-- links is different than on other links. The Movement -->
<!-- Detection operation (section 11.5.1 of <xref -->
<!-- target='RFC6275'/>) can not rely on Neighbor Unreachability -->
<!-- Detection operation of the Neighbor Discovery protocol, for -->
<!-- the reason mentioned in the previous paragraph. Also, the -->
<!-- 802.11-OCB link layer is not a lower layer that can provide -->
<!-- an indication that a link layer handover has occured. The -->
<!-- operation of the Mobile IPv6 protocol over 802.11-OCB is not -->
<!-- specified in this document. -->
<!-- </t> -->
</section> </section>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t> <t>
Any security mechanism at the IP layer or above that may be Any security mechanism at the IP layer or above that may be
carried out for the general case of IPv6 may also be carried implemented for the general case of IPv6 may also be implemented
out for IPv6 operating over 802.11-OCB. for IPv6 operating over 802.11-OCB.
</t> </t>
<t> <t>
The OCB operation does not use existing 802.11 The OCB operation does not use existing 802.11
link-layer security mechanisms. There is no encryption link-layer security mechanisms. There is no encryption
applied below the network layer running on 802.11-OCB. At applied below the network layer running on 802.11-OCB. At
the application layer, the IEEE 1609.2 document <xref the application layer, the IEEE 1609.2 document <xref target="IEEE-1609.2
target="IEEE-1609.2"/> provides security services for " format="default"/> provides security services for
certain applications to use; application-layer mechanisms are certain applications to use; application-layer mechanisms are
out of scope of this document. On another hand, a security out of scope of this document. On the other hand, a security
mechanism provided at networking layer, such as IPsec <xref mechanism provided at the networking layer, such as IPsec <xref target="R
target="RFC4301"/>, may provide data security protection to a FC4301" format="default"/>, may provide data security protection to a
wider range of applications. wider range of applications.
</t> </t>
<t> <t>
802.11-OCB does not provide any cryptographic protection, 802.11-OCB does not provide any cryptographic protection because it oper
because it operates outside the context of a BSS (no ates outside the context of a BSS (no
Association Request/Response, no Challenge messages). Association Request/Response or Challenge messages).
Therefore, an attacker can sniff or inject traffic while within Therefore, an attacker can sniff or inject traffic while within
range of a vehicle or IP-RSU (by setting an interface card's frequency t o the proper range). range of a vehicle or IP-RSU (by setting an interface card's frequency t o the proper range).
Also, an attacker may not heed to legal limits Also, an attacker may not adhere to the legal limits
for radio power and can use a very sensitive directional antenna; for radio power and can use a very sensitive directional antenna;
if attackers wishe to attack a given exchange they do not necessarily if attackers wish to attack a given exchange, they do not necessarily
need to be in close physical proximity. Hence, such a link is less prote cted than need to be in close physical proximity. Hence, such a link is less prote cted than
commonly used links (wired link or aforementioned 802.11 links with link -layer security). commonly used links (a wired link or the aforementioned 802.11 links wit h link-layer security).
</t> </t>
<t>Therefore, any node can join a subnet and directly communicate with any
<t> nodes on the subset, including potentially impersonating another node. This
Therefore, any node can join a subnet, directly communicate with any node design allows for a number of threats outlined in <xref
s target="RFC6959" sectionFormat="of" section="3"/>.
on the subset to include potentially impersonating another node. This While not widely deployed, SEND <xref target="RFC3971" format="default"/> <x
design allows for a number of threats outlined in Section 3 of <xref target= ref target="RFC3972" format="default"/> is a solution
"RFC6959"/>. that can address spoof-based attack vectors.
While not widely deployed, SeND <xref target="RFC3971"/>, <xref target="RFC3
972"/> is a solution
that can address Spoof-Based Attack Vectors.
</t> </t>
<section anchor="Privacy" numbered="true" toc="default">
<name>Privacy Considerations</name>
<section anchor="Privacy" title="Privacy Considerations">
<t> <t>
As with all Ethernet and 802.11 interface identifiers (<xref As with all Ethernet and 802.11 interface identifiers <xref target="RF
target='RFC7721'/>), the identifier of an 802.11-OCB C7721" format="default"/>, the identifier of an 802.11-OCB
interface may involve privacy, MAC address spoofing and IP interface may involve privacy, MAC address spoofing, and IP
hijacking risks. A vehicle embarking an IP-OBU hijacking risks. A vehicle embarking an IP-OBU
whose egress interface is 802.11-OCB may expose itself to whose egress interface is 802.11-OCB may expose itself to
eavesdropping and subsequent correlation of data. This may eavesdropping and subsequent correlation of data. This may
reveal data considered private by the vehicle owner; there reveal data considered private by the vehicle owner; there
is a risk of being tracked. In outdoors public is a risk of being tracked. In outdoor public
environments, where vehicles typically circulate, the environments, where vehicles typically circulate, the
privacy risks are more important than in indoors settings. privacy risks are greater than in indoor settings.
It is highly likely that attacker sniffers are deployed It is highly likely that attacker sniffers are deployed
along routes which listen for IEEE frames, including IP along routes that listen for IEEE frames, including IP
packets, of vehicles passing by. For this reason, in the packets, of vehicles passing by. For this reason, in 802.11-OCB deplo
802.11-OCB deployments, there is a strong necessity to use yments, there is a strong necessity to use
protection tools such as dynamically changing MAC addresses protection tools such as dynamically changing MAC addresses
<xref target="mac-change"/>, semantically opaque Interface (<xref target="mac-change" format="default"/>), semantically opaque In
Identifiers and stable Interface Identifiers <xref terface
target="slaac"/>. An example of change policy is to change the MAC Identifiers, and stable Interface Identifiers (<xref target="slaac"
format="default"/>). An example of a change policy is to change the MA
C
address of the OCB interface each time the system boots up. address of the OCB interface each time the system boots up.
This may help mitigate privacy risks to a This may help mitigate privacy risks to a
certain level. certain level. Furthermore, for privacy concerns, <xref target="RFC80
Furthermore, for privacy concerns, (<xref target='RFC8065'/>) recomme 65"
nds using an address format="default"/> recommends using an address-generation scheme
generation scheme rather than addresses generated from a fixed link-la rather than generating addresses from a fixed link-layer address.
yer address.
However, there are some specificities related to vehicles. Since roami ng is an important However, there are some specificities related to vehicles. Since roami ng is an important
characteristic of moving vehicles, the use of the same Link-Local Addr ess over time characteristic of moving vehicles, the use of the same Link-Local Addr ess over time
can indicate the presence of the same vehicle in different places and can indicate the presence of the same vehicle in different places and
thus leads to location tracking. thus lead to location tracking.
Hence, a vehicle should get hints about a change of environment (e.g. Hence, a vehicle should get hints about a change of environment (e.g.,
, engine running, GPS, etc..) engine running, GPS, etc.)
and renew the IID in its LLAs. and renew the IID in its LLAs.
</t> </t>
<section anchor="privacy-opaque-iid" <section anchor="privacy-opaque-iid" numbered="true" toc="default">
title="Privacy Risks of Meaningful info in Interface IDs"> <name>Privacy Risks of Meaningful Information in Interface IDs</name>
<t> <t>
The privacy risks of using MAC addresses displayed in The privacy risks of using MAC addresses displayed in
Interface Identifiers are important. The IPv6 packets can Interface Identifiers are important. IPv6 packets can
be captured easily in the Internet and on-link in public be captured easily on the Internet and on-link on public
roads. For this reason, an attacker may realize many roads. For this reason, an attacker may realize many
attacks on privacy. One such attack on 802.11-OCB is to attacks on privacy. One such attack on 802.11-OCB is to
capture, store and correlate Company ID information capture, store, and correlate company ID information
present in MAC addresses of many cars (e.g. listen for present in the MAC addresses of a large number of cars (e.g., listeni
Router Advertisements, or other IPv6 application data ng for
packets, and record the value of the source address in Router Advertisements or other IPv6 application data
packets, and recording the value of the source address in
these packets). Further correlation of this information these packets). Further correlation of this information
with other data captured by other means, or other visual with other data captured by other means or other visual
information (car color, others) may constitute privacy information (e.g., car color) may constitute privacy
risks. risks.
</t> </t>
</section> </section>
</section> </section>
<section anchor="mac-change" numbered="true" toc="default">
<section title="MAC Address and Interface ID Generation" <name>MAC Address and Interface ID Generation</name>
anchor="mac-change">
<t> <t>
In 802.11-OCB networks, the MAC addresses may change during In 802.11-OCB networks, the MAC addresses may change during
well defined renumbering events. In the moment the MAC well-defined renumbering events. At the moment the MAC
address is changed on an 802.11-OCB interface all the address is changed on an 802.11-OCB interface, all the
Interface Identifiers of IPv6 addresses assigned to that Interface Identifiers of IPv6 addresses assigned to that
interface MUST change. interface <bcp14>MUST</bcp14> change.
</t> </t>
<t>
<t>
Implementations should use a policy dictating when the MAC address is c hanged on the 802.11-OCB interface. Implementations should use a policy dictating when the MAC address is c hanged on the 802.11-OCB interface.
For more information on the motivation of this policy please refer to For more information on the motivation of this policy, please refer to
the privacy discussion in <xref the privacy discussion in <xref target="introduced-by-OCB" format="defa
target='introduced-by-OCB'/>. ult"/>.
</t> </t>
<t>
<t>
A 'randomized' MAC address has the following A 'randomized' MAC address has the following
characteristics: characteristics:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols" > <li>
<t> The "Local/Global" bit is set to "locally administered".
Bit "Local/Global" set to "locally administered". </li>
</t> <li>
<t> The "Unicast/Multicast" bit is set to "Unicast".
Bit "Unicast/Multicast" set to "Unicast". </li>
</t> <li>
<t> The 46 remaining bits are set to a random value using a
The 46 remaining bits are set to a random value, using a
random number generator that meets the requirements of random number generator that meets the requirements of
<xref target="RFC4086" />. <xref target="RFC4086" format="default"/>.
</t> </li>
</list> </ul>
</t>
<t> <t>
To meet the randomization requirements for the 46 remaining To meet the randomization requirements for the 46 remaining
bits, a hash function may be used. For example, the <xref target="SHA2 bits, a hash function may be used. For example, the hash function
56"></xref> defined in <xref target="SHA256" format="default"/>
hash function may be used with input a 256 bit local secret, may be used with the input of a 256-bit local secret, the 'nominal'
the 'nominal' MAC Address of the interface, and a MAC address of the interface, and a representation of the date and
representation of the date and time of the renumbering time of the renumbering event.
event.
</t> </t>
<t> <t>
A randomized Interface ID has the same characteristics of a A randomized Interface ID has the same characteristics of a
randomized MAC address, except the length in bits. randomized MAC address except for the length in bits.
</t> </t>
</section> </section>
<section anchor='pseudonym' <section anchor="pseudonym" numbered="true" toc="default">
title= 'Pseudonymization impact on confidentiality and trust'> <name>Pseudonymization Impact on Confidentiality and Trust</name>
<t> <t>
Vehicle and drivers privacy relies on pseudonymization mechanisms
Vehicles 'and drivers' privacy relies on pseudonymization mechanisms such as the ones described in <xref target="mac-change" format="default"/
such as the ones described in <xref target='mac-change'/>. >.
This pseudonymization means that upper-layer protocols and applications This pseudonymization means that upper-layer protocols and applications
SHOULD NOT rely on layer-2 or layer-3 addresses to assume that the other participant can be trusted. <bcp14>SHOULD NOT</bcp14> rely on layer-2 or layer-3 addresses to assume that the other participant can be trusted.
</t> </t>
</section> </section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
No request to IANA.
</t>
</section>
<section anchor="Contributors"
title="Contributors">
<t>
Christian Huitema, Tony Li.
</t>
<t>
Romain Kuntz contributed extensively about IPv6 handovers
between links running outside the context of a BSS (802.11-OCB
links).
</t>
<t>
Tim Leinmueller contributed the idea of the use of IPv6 over
802.11-OCB for distribution of certificates.
</t>
<t>
Marios Makassikis, Jose Santa Lozano, Albin Severinson and
Alexey Voronov provided significant feedback on the experience
of using IP messages over 802.11-OCB in initial trials.
</t>
<t>
Michelle Wetterwald contributed extensively the MTU
discussion, offered the ETSI ITS perspective, and reviewed
other parts of the document.
</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="Acknowledgements" <name>IANA Considerations</name>
title="Acknowledgements">
<t>
The authors would like to thank Alexandre Petrescu for
initiating this work and for being the lead author until
the version 43 of this draft.
</t>
<t>
The authors would like to thank Pascal Thubert for reviewing,
proofreading and suggesting modifications of this document.
</t>
<t>
The authors would like to thank Mohamed Boucadair for
proofreading and suggesting modifications of this document.
</t>
<t>
The authors would like to thank Eric Vyncke for
reviewing suggesting modifications of this document.
</t>
<t>
The authors would like to thank Witold Klaudel, Ryuji
Wakikawa, Emmanuel Baccelli, John Kenney, John Moring,
Francois Simon, Dan Romascanu, Konstantin Khait, Ralph Droms,
Richard 'Dick' Roy, Ray Hunter, Tom Kurihara, Michal Sojka,
Jan de Jongh, Suresh Krishnan, Dino Farinacci, Vincent Park,
Jaehoon Paul Jeong, Gloria Gwynne, Hans-Joachim Fischer, Russ
Housley, Rex Buddenberg, Erik Nordmark, Bob Moskowitz, Andrew
Dryden, Georg Mayer, Dorothy Stanley, Sandra Cespedes, Mariano
Falcitelli, Sri Gundavelli, Abdussalam Baryun, Margaret
Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in 't
Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith,
Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von
Hugo, Lorenzo Colitti, Pascal Thubert, Ole Troan, Jinmei
Tatuya, Joel Halpern, Eric Gray and William Whyte. Their
valuable comments clarified particular issues and generally
helped to improve the document.
</t>
<t>
Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB
drivers for linux and described how.
</t>
<t>
For the multicast discussion, the authors would like to thank
Owen DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian
Haberman and participants to discussions in network working
groups.
</t>
<t>
The authors would like to thank participants to the
Birds-of-a-Feather "Intelligent Transportation Systems"
meetings held at IETF in 2016.
</t>
<t> <t>
Human Rights Protocol Considerations review by Amelia This document has no IANA actions.
Andersdotter.
</t> </t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** --> <!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-mboned-ieee802-mcast-problems" to="IEEE802-MC
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.104 AST"/>
2" ?> <displayreference target="I-D.ietf-ipwave-vehicular-networking" to="IPWAVE"/>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.211
9" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.246
4" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.408
6" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.419
1" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.419
3" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.429
1" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.430
1" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.486
1" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.486
2" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.541
5" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.605
9" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.627
5" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.704
2" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.713
6" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.721
7" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.806
4" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.817
4" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.820
0" ?>
<!-- [rfced] [IEEE-802.11-2016] This URL is correct --> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1042.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2464.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4191.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4193.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4291.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4301.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4861.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4862.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5415.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6059.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6275.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7042.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7136.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7217.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8064.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8200.xml"/>
<reference anchor="IEEE-802.11-2016" > <reference anchor="IEEE-802.11-2016" target="https://standards.ieee.org/
<front> findstds/standard/802.11-2016.html">
<title> <front>
IEEE Standard 802.11-2016 - IEEE Standard for Information <title>
Technology - Telecommunications and information exchange IEEE Standard for Information
between systems Local and metropolitan area networks - technology - Telecommunications and information exchange
Specific requirements - Part 11: Wireless LAN Medium between systems Local and metropolitan area networks--Specific
requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Access Control (MAC) and Physical Layer (PHY)
Specifications. Status - Active Standard. Description Specifications
retrieved freely; the document itself is also freely </title>
available, but with some difficulty (requires <seriesInfo name="IEEE Standard" value="802.11-2016"/>
registration); description and document retrieved on April <author>
8th, 2019, starting from URL <organization>IEEE</organization>
https://standards.ieee.org/findstds/standard/802.11-2016.html </author>
</title> <date month="December" year="2016"/>
<author/> </front>
<date/> </reference>
</front> </references>
</reference>
<!-- <?rfc -->
<!-- include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.BCP.14
" -->
<!-- ?> -->
</references>
<references title="Informative References">
<!-- [rfced] [IEEE-802.11p-2010] The URL listed below is no longer valid. Found
URL: https://standards.ieee.org/standard/802_11p-2010.html but must pay for down
load. Also found https://ieeexplore.ieee.org/document/5514475 DOI: 10.1109/IEEE
STD.2010.5514475 -->
<reference anchor="IEEE-802.11p-2010" >
<front>
<title>
IEEE Std 802.11p (TM)-2010, 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,
Amendment 6: Wireless Access in Vehicular Environments;
document freely available at URL
http://standards.ieee.org/getieee802/download/802.11p-2010.pdf
retrieved on September 20th, 2013.
</title>
<author/>
<date/>
</front>
</reference>
<!-- [rfced] [SHA256] URL below is to version published in 2002. Newer version p <references>
ublished in 2015 can be found at https://csrc.nist.gov/publications/detail/fips/ <name>Informative References</name>
180/4/final -->
<reference anchor="SHA256" > <reference anchor="IEEE-802.11-2007" target="https://ieeexplore.ieee.org
<front> /document/4248378">
<title> <front>
Secure Hash Standard (SHS), National Institute of Standards and Tec <title>
hnology. IEEE Standard for Information Technology -
https://csrc.nist.gov/CSRC/media/Publications/fips/180/2/archive/20 Telecommunications and Information Exchange Between Systems -
02-08-01/documents/fips180-2.pdf Local and Metropolitan Area Networks - Specific Requirements -
</title> Part 11: Wireless LAN Medium Access Control (MAC) and Physical
<author/> Layer (PHY) Specifications
<date/> </title>
</front> <seriesInfo name="IEEE Standard" value="802.11-2007"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2007.373646"/>
<author><organization>IEEE</organization></author>
<date month="June" year="2007"/>
</front>
</reference>
<!-- [rfced] [IEEE-1609.2] URL is correct DOI: 10.1109/IEEESTD.2016.7426684 --> <reference anchor="IEEE-802.11-2012" target="https://ieeexplore.ieee.org
/document/6419735">
<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>
<seriesInfo name="IEEE Standard" value="802.11-2012"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6178212"/>
<author><organization>IEEE</organization></author>
<date month="March" year="2012"/>
</front>
</reference>
<reference anchor="IEEE-1609.2"> <reference anchor="IEEE-802.3-2012" target="https://ieeexplore.ieee.org/
<front> document/6419735">
<title> <front>
IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access <title>
in Vehicular Environments (WAVE) -- Security Services for IEEE Standard for Ethernet
Applications and Management Messages. Example URL </title>
http://ieeexplore.ieee.org/document/7426684/ accessed on <seriesInfo name="IEEE Standard" value="802.3-2012"/>
August 17th, 2017. <seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6419735"/>
</title> <author><organization>IEEE</organization></author>
<author/> <date month="December" year="2012"/>
<date/> </front>
</front> </reference>
</reference>
<!-- <reference anchor="IEEE-1609.3"> --> <reference anchor="IEEE-802.11p-2010" target="https://standards.ieee.org
<!-- <front> --> /standard/802_11p-2010.html">
<!-- <title> --> <front>
<!-- IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access --> <title>
<!-- in Vehicular Environments (WAVE) - Networking Services. --> IEEE Standard for Information technology - Telecommunications and
<!-- Example URL http://ieeexplore.ieee.org/document/7458115/ --> information exchange between systems - Local and metropolitan area
<!-- accessed on August 17th, 2017. --> networks - Specific requirements, Part 11: Wireless LAN Medium
<!-- </title> --> Access Control (MAC) and Physical Layer (PHY) Specifications,
<!-- <author/> --> Amendment 6: Wireless Access in Vehicular Environments
<!-- <date/> --> </title>
<!-- </front> --> <seriesInfo name="IEEE Standard" value="802.11p-2010"/>
<!-- </reference> --> <seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5514475"/>
<author><organization>IEEE</organization></author>
<date month="July" year="2010"/>
</front>
</reference>
<!-- <reference anchor="IEEE-1609.4"> --> <reference anchor="SHA256" target="https://csrc.nist.gov/publications/detail/fi
<!-- <front> --> ps/180/4/final">
<!-- <title> --> <front>
<!-- IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access --> <title>Secure Hash Standard (SHS)</title>
<!-- in Vehicular Environments (WAVE) - Multi-Channel --> <seriesInfo name="FIPS" value="180-4" />
<!-- Operation. Example URL --> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4" />
<!-- http://ieeexplore.ieee.org/document/7435228/ accessed on --> <author><organization>National Institute of Standards and
<!-- August 17th, 2017. --> Technology</organization></author>
<!-- </title> -->
<!-- <author/> -->
<!-- <date/> -->
<!-- </front> -->
<!-- </reference> -->
<!-- [rfced] [IEEE-1609.3] URL below is correct DOI: 10.1109/IEEESTD.2016.74581 <date month="August" year="2015"/>
15 --> </front>
</reference>
<reference anchor="IEEE-1609.3"> <reference anchor="IEEE-1609.2" target="http://ieeexplore.ieee.org/docum
<front> ent/7426684">
<title> <front>
IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access <title>
in Vehicular Environments (WAVE) -- Networking Services. IEEE Standard for Wireless Access
Example URL http://ieeexplore.ieee.org/document/7458115/ in Vehicular Environments--Security Services for
accessed on August 17th, 2017. Applications and Management Messages
</title> </title>
<author/> <seriesInfo name="IEEE Standard" value="1609.2-2016"/>
<date/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7426684"/>
</front> <author><organization>IEEE</organization></author>
</reference> <date month="March" year="2016"/>
</front>
</reference>
<!-- [rfced] [IEEE-1609.4] URL below is correct DOI: 10.1109/IEEESTD.2016.74352 <reference anchor="IEEE-1609.3" target="http://ieeexplore.ieee.org/docum
28 --> ent/7458115">
<front>
<title>
IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Networking Services
</title>
<seriesInfo name="IEEE Standard" value="1609.3-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7458115"/>
<author><organization>IEEE</organization></author>
<date month="April" year="2016"/>
</front>
</reference>
<reference anchor="IEEE-1609.4"> <reference anchor="IEEE-1609.4"
<front> target="http://ieeexplore.ieee.org/document/7435228">
<title> <front>
IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access <title>
IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Multi-Channel in Vehicular Environments (WAVE) -- Multi-Channel
Operation. Example URL Operation
http://ieeexplore.ieee.org/document/7435228/ accessed on </title>
August 17th, 2017. <seriesInfo name="IEEE Standard" value="1609.4-2016"/>
</title> <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7435228"/>
<author/> <author><organization>IEEE</organization></author>
<date/> <date month="March" year="2016"/>
</front> </front>
</reference> </reference>
<!-- [rfced] [ETSI-sec-archi] This URL is correct -->
<reference anchor="ETSI-sec-archi"> <reference anchor="ETSI-sec-archi" target="http://www.etsi.org/deliver/e
<front> tsi_ts/102900_102999/102940/01.02.01_60/ts_102940v010201p.pdf">
<title> <front>
ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical <title>
Specification, Intelligent Transport Systems (ITS); Intelligent Transport Systems (ITS);
Security; ITS communications security architecture and Security; ITS communications security architecture and
security management, November 2016. Downloaded on security management
September 9th, 2017, freely available from ETSI website at </title>
URL <seriesInfo name="ETSI" value="TS 102 940 V1.2.1"/>
http://www.etsi.org/deliver/etsi_ts/102900_102999/102940/01.02.01_60/ <author/>
ts_102940v010201p.pdf <date month="November" year="2016"/>
</title> </front>
<author/> </reference>
<date/>
</front>
</reference>
<!-- <reference anchor="fcc-cc" > -->
<!-- <front> -->
<!-- <title> -->
<!-- 'Report and Order, Before the Federal Communications -->
<!-- Commission Washington, D.C. 20554', FCC 03-324, Released -->
<!-- on February 10, 2004, document FCC-03-324A1.pdf, -->
<!-- document freely available at URL -->
<!-- http://www.its.dot.gov/exit/fcc_edocs.htm downloaded on -->
<!-- October 17th, 2013. -->
<!-- </title> -->
<!-- <author/> -->
<!-- <date/> -->
<!-- </front> -->
<!-- </reference> -->
<!-- <reference anchor="fcc-cc-172-184" > -->
<!-- <front> -->
<!-- <title> -->
<!-- 'Memorandum Opinion and Order, Before the Federal -->
<!-- Communications Commission Washington, D.C. 20554', FCC -->
<!-- 06-10, Released on July 26, 2006, document -->
<!-- FCC-06-110A1.pdf, document freely available at URL -->
<!-- http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-110A1.
pdf -->
<!-- downloaded on June 5th, 2014. -->
<!-- </title> -->
<!-- <author/> -->
<!-- <date/> -->
<!-- </front> -->
<!-- </reference> -->
<!-- <reference anchor="etsi-302663-v1.2.1p-2013" > -->
<!-- <front> -->
<!-- <title> -->
<!-- Intelligent Transport Systems (ITS); Access layer -->
<!-- specification for Intelligent Transport Systems -->
<!-- operating in the 5 GHz frequency band, 2013-07, document -->
<!-- en_302663v010201p.pdf, document freely available at URL -->
<!-- http://www.etsi.org/deliver/etsi_en/302600_302699/302663/ -->
<!-- 01.02.01_60/en_302663v010201p.pdf downloaded on October -->
<!-- 17th, 2013. -->
<!-- </title> -->
<!-- <author/> -->
<!-- <date/> -->
<!-- </front> -->
<!-- </reference> -->
<!-- <reference anchor="etsi-draft-102492-2-v1.1.1-2006" > -->
<!-- <front> -->
<!-- <title> -->
<!-- Electromagnetic compatibility and Radio spectrum Matters -->
<!-- (ERM); Intelligent Transport Systems (ITS); Part 2: -->
<!-- Technical characteristics for pan European harmonized -->
<!-- communications equipment operating in the 5 GHz -->
<!-- frequency range intended for road safety and traffic -->
<!-- management, and for non-safety related ITS applications; -->
<!-- System Reference Document, Draft ETSI TR 102 492-2 -->
<!-- V1.1.1, 2006-07, document tr_10249202v010101p.pdf freely -->
<!-- available at URL -->
<!-- http://www.etsi.org/deliver/etsi_tr/102400_102499/ -->
<!-- 10249202/01.01.01_60/tr_10249202v010101p.pdf downloaded -->
<!-- on October 18th, 2013. -->
<!-- </title> -->
<!-- <author/> -->
<!-- <date/> -->
<!-- </front> -->
<!-- </reference> -->
<!-- <reference anchor="TS103097" > -->
<!-- <front> -->
<!-- <title> -->
<!-- Intelligent Transport Systems (ITS); Security; Security -->
<!-- header and certificate formats; document freely -->
<!-- available at URL -->
<!-- http://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.01.
01_60/ts_103097v010101p.pdf -->
<!-- retrieved on July 08th, 2016. -->
<!-- </title> -->
<!-- <author/> -->
<!-- <date/> -->
<!-- </front> -->
<!-- </reference> -->
<!-- <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.iet
f-ipwave-vehicular-networking" ?>; I-D Exists -->
<reference anchor='IPWAVE-NETWORKING'>
<front>
<title>IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement
and Use Cases</title>
<author initials='J' surname='Jeong' fullname='Jaehoon Jeong'>
<organization />
</author>
<date month='July' day='20' year='2019' />
<abstract><t>This document discusses the problem statement and use cases of IP-
based vehicular networking for Intelligent Transportation Systems (ITS). The ma
in scenarios of vehicular communications are vehicle- to-vehicle (V2V), vehicle-
to-infrastructure (V2I), and vehicle-to- everything (V2X) communications. First
, this document explains use cases using V2V, V2I, and V2X networking. Next, it
makes a problem statement about key aspects in IP-based vehicular networking, s
uch as IPv6 Neighbor Discovery, Mobility Management, and Security &amp; Privacy.
For each key aspect, this document specifies requirements in IP-based vehicular
networking, and suggests the direction of solutions satisfying those requiremen
ts.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-ipwave-vehicular-networki
ng-11' />
</reference>
<!-- <?rfc -->
<!-- include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-tsvwg-ieee-802-11" -->
<!-- ?> -->
<!-- <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I
-D.hinden-6man-rfc2464bis" ?> -->
<!-- <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.iet
f-mboned-ieee802-mcast-problems" ?>; Publication Requested -->
<reference anchor='ieee802-MCAST'>
<front>
<title>Multicast Considerations over IEEE 802 Wireless Media</title>
<author initials='C' surname='Perkins' fullname='Charles Perkins'>
<organization />
</author>
<author initials='M' surname='McBride' fullname='Mike McBride'>
<organization />
</author>
<author initials='D' surname='Stanley' fullname='Dorothy Stanley'>
<organization />
</author>
<author initials='W' surname='Kumari' fullname='Warren Kumari'>
<organization />
</author>
<author initials='J' surname='Zuniga' fullname='Juan Zuniga'>
<organization />
</author>
<date month='August' day='13' year='2019' /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-ipwave-vehicular-networking.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-mboned-ieee802-mcast-problems.xml"/>
<abstract><t>Well-known issues with multicast have prevented the deployment of m <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ulticast in 802.11 and other local-area wireless environments. This document of ence.RFC.3753.xml"/>
fers guidance on known limitations and problems with wireless multicast. Also d <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
escribed are certain multicast enhancement features that have been specified by ence.RFC.3963.xml"/>
the IETF and by IEEE 802 for wireless media, as well as some operational choices <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
that can be taken to improve the performace of the network. Finally, some reco ence.RFC.3971.xml"/>
mmendations are provided about the usage and combination of these features and o <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
perational choices.</t></abstract> ence.RFC.3972.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5889.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6959.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7721.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8065.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8505.xml"/>
</front> <reference anchor="CFR-90.7"
target="https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.90&a
mp;rgn=div5#se47.5.90_17">
<front>
<title>Electronic Code of Federal Regulations</title>
<author><organization>e-CFR</organization></author>
</front>
<refcontent>Title 47, CFR 90.7 - Definitions</refcontent>
</reference>
<seriesInfo name='Work in Progress,' value='draft-ietf-mboned-ieee802-mcast-prob <reference anchor="CFR-95"
lems-08' /> target="https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.95&
</reference> amp;rgn=div5">
<front>
<title>Electronic Code of Federal Regulations</title>
<author><organization>e-CFR</organization></author>
</front>
<refcontent>Title 47, CFR 95 - PERSONAL RADIO SERVICES</refcontent>
</reference>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.375 <reference anchor="CFR-90"
3" ?> target="https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.90&
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.396 amp;rgn=div5">
3" ?> <front>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.397 <title>Electronic Code of Federal Regulations</title>
1" ?> <author><organization>e-CFR</organization></author>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.397 </front>
2" ?> <refcontent>Title 47, Part 90 - PRIVATE LAND MOBILE RADIO SERVICES</refcontent>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.588 </reference>
9" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.695
9" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.772
1" ?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.806
5" ?>
</references>
</references> </references>
<section anchor="i802.11p" numbered="true" toc="default">
<section title= "802.11p" <name>802.11p</name>
anchor='i802.11p'>
<t> <t>
The term "802.11p" is an earlier definition. The behaviour of The term "802.11p" is an earlier definition. The behavior of
"802.11p" networks is rolled in the document IEEE Std "802.11p" networks is rolled in <xref target="IEEE-802.11-2016" format="
802.11-2016. In that document the term 802.11p disappears. default"/>. In that document, the term "802.11p" disappears.
Instead, each 802.11p feature is conditioned by the IEEE Instead, each 802.11p feature is conditioned by the IEEE
Management Information Base (MIB) attribute "OCBActivated" Management Information Base (MIB) attribute "OCBActivated"
<xref target="IEEE-802.11-2016"/>. Whenever OCBActivated is <xref target="IEEE-802.11-2016" format="default"/>. Whenever OCBActivat
set to true the IEEE Std 802.11-OCB state is activated. For ed is
set to "true", the IEEE Std 802.11-OCB state is activated. For
example, an 802.11 STAtion operating outside the context of a example, an 802.11 STAtion operating outside the context of a
basic service set has the OCBActivated flag set. Such a BSS has the OCBActivated flag set. Such a
station, when it has the flag set, uses a BSS identifier equal station, when it has the flag set, uses a BSS identifier equal
to ff:ff:ff:ff:ff:ff. to ff:ff:ff:ff:ff:ff.
</t> </t>
</section> </section>
<section anchor="introduced-by-OCB" numbered="true" toc="default">
<section title="Aspects introduced by the OCB mode to 802.11" <name>Aspects Introduced by OCB Mode to 802.11</name>
anchor='introduced-by-OCB'>
<t> <t>
In the IEEE 802.11-OCB mode, all nodes in the wireless range In IEEE 802.11-OCB mode, all nodes in the wireless range
can directly communicate with each other without involving can directly communicate with each other without involving
authentication or association procedures. In OCB mode, the authentication or association procedures. In OCB mode, the
manner in which channels are selected and used is simplified manner in which channels are selected and used is simplified
compared to when in BSS mode. Contrary to BSS mode, at link compared to when in BSS mode. Contrary to BSS mode, at the link
layer, it is necessary to set statically the same channel layer, it is necessary to statically set the same channel
number (or frequency) on two stations that need to communicate number (or frequency) on two stations that need to communicate
with each other (in BSS mode this channel set operation is with each other (in BSS mode, this channel set operation is
performed automatically during 'scanning'). The manner in performed automatically during 'scanning'). The manner in
which stations set their channel number in OCB mode is not which stations set their channel number in OCB mode is not
specified in this document. Stations STA1 and STA2 can specified in this document. Stations STA1 and STA2 can
exchange IP packets only if they are set on the same channel. exchange IP packets only if they are set to the same channel.
At IP layer, they then discover each other by using the IPv6 At the IP layer, they then discover each other by using the IPv6
Neighbor Discovery protocol. The allocation of a particular Neighbor Discovery protocol. The allocation of a particular
channel for a particular use is defined statically in channel for a particular use is defined statically in
standards authored by ETSI (in Europe), FCC in America, and standards authored by ETSI in Europe, the FCC in the United States of Am
similar organisations in South Korea, Japan and other parts of erica, and
similar organizations in South Korea, Japan, and other parts of
the world. the world.
</t> </t>
<t> <t>
Briefly, the IEEE 802.11-OCB mode has the following Briefly, the IEEE 802.11-OCB mode has the following
properties: properties:
<list style="symbols"> </t>
<t> <ul spacing="normal">
The use by each node of a 'wildcard' BSSID (i.e., each bit <li>
of the BSSID is set to 1) The use by each node of a 'wildcard' BSS identifier (BSSID) (i.e., e
</t> ach bit
<t> No IEEE 802.11 Beacon frames are transmitted </t> of the BSSID is set to 1).
<t> No authentication is required in order to be able to communicate</ </li>
t> <li> No IEEE 802.11 beacon frames are transmitted. </li>
<t> No association is needed in order to be able to communicate</t> <li> No authentication is required in order to be able to communicate.</
<t> No encryption is provided in order to be able to communicate</t> li>
<t> Flag dot11OCBActivated is set to true </t> <li> No association is needed in order to be able to communicate.</li>
</list> <li> No encryption is provided in order to be able to communicate.</li>
<li> Flag dot11OCBActivated is set to "true". </li>
</ul>
<t>
All the nodes in the radio communication range (IP-OBU and IP-RSU) All the nodes in the radio communication range (IP-OBU and IP-RSU)
receive all the messages transmitted (IP-OBU and IP-RSU) within the receive all the messages transmitted (IP-OBU and IP-RSU) within the
radio communications range. The eventual conflict(s) are radio communication range. The MAC CDMA function resolves any
resolved by the MAC CDMA function. eventual conflict(s).
</t> </t>
<t> <t>
The message exchange diagram in <xref target='fig:mess-exch'/> The message exchange diagram in <xref target="fig_mess-exch" format="def ault"/>
illustrates a comparison between traditional 802.11 and 802.11 illustrates a comparison between traditional 802.11 and 802.11
in OCB mode. The 'Data' messages can be IP packets such as in OCB mode. The 'Data' messages can be IP packets such as
HTTP or others. Other 802.11 management and control frames HTTP or others. Other 802.11 management and control frames
(non IP) may be transmitted, as specified in the 802.11 (non-IP) may be transmitted, as specified in the 802.11
standard. For information, the names of these messages as standard. The names of these messages as
currently specified by the 802.11 standard are listed in <xref currently specified by the 802.11 standard are listed in <xref target="O
target="OCB-messages"/>. CB-messages" format="default"/>.
</t> </t>
<t> <figure anchor="fig_mess-exch">
<name>Difference between Messages Exchanged on 8
<figure title='Difference between messages exchanged 02.11 (Left) and 802.11-OCB (Right)</name>
on 802.11 (left) and 802.11-OCB (right)' <artwork align="center" name="" type="" alt=""><![CDATA[
anchor='fig:mess-exch'
align="center">
<artwork align="center">
<![CDATA[
STA AP STA1 STA2 STA AP STA1 STA2
| | | | | | | |
|<------ Beacon -------| |<------ Data -------->| |<------ Beacon -------| |<------ Data -------->|
| | | | | | | |
|---- Probe Req. ----->| |<------ Data -------->| |---- Probe Req. ----->| |<------ Data -------->|
|<--- Probe Res. ------| | | |<--- Probe Res. ------| | |
| | |<------ Data -------->| | | |<------ Data -------->|
|---- Auth Req. ------>| | | |---- Auth Req. ------>| | |
|<--- Auth Res. -------| |<------ Data -------->| |<--- Auth Res. -------| |<------ Data -------->|
| | | | | | | |
|---- Asso Req. ------>| |<------ Data -------->| |---- Asso Req. ------>| |<------ Data -------->|
|<--- Asso Res. -------| | | |<--- Asso Res. -------| | |
| | |<------ Data -------->| | | |<------ Data -------->|
|<------ Data -------->| | | |<------ Data -------->| | |
|<------ Data -------->| |<------ Data -------->| |<------ Data -------->| |<------ Data -------->|
(i) 802.11 Infrastructure mode (ii) 802.11-OCB mode (i) 802.11 Infrastructure mode (ii) 802.11-OCB mode ]]></artwork>
]]> </figure>
</artwork>
</figure>
</t>
<t> <t>
The interface 802.11-OCB was specified in IEEE Std 802.11p The 802.11-OCB interface was specified in <xref target="IEEE-802.11p-2010
(TM) -2010 <xref target="IEEE-802.11p-2010"/> as an amendment " format="default"/>, Amendment 6: Wireless
to IEEE Std 802.11 (TM) -2007, titled "Amendment 6: Wireless Access in Vehicular Environments, as an amendment
Access in Vehicular Environments". Since then, this amendment to <xref target="IEEE-802.11-2007"/>. Since then, this amendment
has been integrated in IEEE 802.11(TM) -2012 and -2016 <xref has been integrated into <xref target="IEEE-802.11-2012"/> and <xref targ
target="IEEE-802.11-2016"/>. et="IEEE-802.11-2016" format="default"/>.
</t> </t>
<t> <t>
In document 802.11-2016, anything qualified specifically as In <xref target="IEEE-802.11p-2010" format="default"/>, anything qualifie
"OCBActivated", or "outside the context of a basic service" d specifically as
set to be true, then it is actually referring to OCB aspects "OCBActivated" or "outside the context of a basic service"
that is set to be "true" actually refers to OCB aspects
introduced to 802.11. introduced to 802.11.
</t> </t>
<t> <t>
In order to delineate the aspects introduced by 802.11-OCB to In order to delineate the aspects introduced by 802.11-OCB to
802.11, we refer to the earlier <xref 802.11, we refer to the earlier <xref target="IEEE-802.11p-2010" format=
target="IEEE-802.11p-2010"/>. The amendment is concerned with "default"/>. The amendment is concerned with
vehicular communications, where the wireless link is similar vehicular communications, where the wireless link is similar
to that of Wireless LAN (using a PHY layer specified by to that of Wireless LAN (using a PHY layer specified by
802.11a/b/g/n), but which needs to cope with the high mobility 802.11a/b/g/n) but needs to cope with the high mobility
factor inherent in scenarios of communications between moving factor inherent in scenarios of communications between moving
vehicles, and between vehicles and fixed infrastructure vehicles and between vehicles and fixed infrastructure
deployed along roads. While 'p' is a letter identifying the deployed along roads. While 'p' is a letter identifying the
Amendment, just like 'a, b, g' and 'n' are, 'p' is concerned Amendment, just like 'a', 'b', 'g', and 'n' are, 'p' is concerned
more with MAC modifications, and a little with PHY more with MAC modifications and is slightly concerned with PHY
modifications; the others are mainly about PHY modifications. modifications; the others are mainly about PHY modifications.
It is possible in practice to combine a 'p' MAC with an 'a' It is possible in practice to combine a 'p' MAC with an 'a'
PHY by operating outside the context of a BSS with OFDM at PHY by operating outside the context of a BSS with Orthogonal
5.4GHz and 5.9GHz. Frequency Division
Multiplexing (OFDM) at
5.4 GHz and 5.9 GHz.
</t> </t>
<t> <t>
The 802.11-OCB links are specified to be compatible as much as The 802.11-OCB links are specified to be as compatible as
possible with the behaviour of 802.11a/b/g/n and future possible with the behavior of 802.11a/b/g/n and future
generation IEEE WLAN links. From the IP perspective, an generation IEEE WLAN links. From the IP perspective, an
802.11-OCB MAC layer offers practically the same interface to 802.11-OCB MAC layer offers practically the same interface to
IP as the 802.11a/b/g/n and 802.3. A packet sent by an IP-OBU IP as 802.11a/b/g/n and 802.3. A packet sent by an IP-OBU
may be received by one or multiple IP-RSUs. The link-layer may be received by one or multiple IP-RSUs. The link-layer
resolution is performed by using the IPv6 Neighbor Discovery resolution is performed by using the IPv6 Neighbor Discovery
protocol. protocol.
</t> </t>
<t> <t>
To support this similarity statement (IPv6 is layered on top To support this similarity statement (IPv6 is layered on top
of LLC on top of 802.11-OCB, in the same way that IPv6 is of LLC on top of 802.11-OCB in the same way that IPv6 is
layered on top of LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on top of 802.11a/b/g/n (for WLAN) or
layered on top of LLC on top of 802.3 (for Ethernet)) it is on top of LLC on top of 802.3 (for Ethernet)), it is
useful to analyze the differences between 802.11-OCB and useful to analyze the differences between the 802.11-OCB and
802.11 specifications. During this analysis, we note that 802.11 specifications. During this analysis, we note that
whereas 802.11-OCB lists relatively complex and numerous whereas 802.11-OCB lists relatively complex and numerous
changes to the MAC layer (and very little to the PHY layer), changes to the MAC layer (and very few to the PHY layer),
there are only a few characteristics which may be important there are only a few characteristics that may be important
for an implementation transmitting IPv6 packets on 802.11-OCB for an implementation transmitting IPv6 packets on 802.11-OCB
links. links.
</t> </t>
<t> <t>
The most important 802.11-OCB point which influences the IPv6 The most important 802.11-OCB aspect that influences the IPv6
functioning is the OCB characteristic; an additional, less functioning is the OCB characteristic; an additional, less
direct influence, is the maximum bandwidth afforded by the PHY direct influence is the maximum bandwidth afforded by the PHY
modulation/demodulation methods and channel access specified modulation/demodulation methods and channel access specified
by 802.11-OCB. The maximum bandwidth theoretically possible by 802.11-OCB. The maximum bandwidth theoretically possible
in 802.11-OCB is 54 Mbit/s (when using, for example, the in 802.11-OCB is 54 Mbit/s (when using, for example, the
following parameters: 20 MHz channel; modulation 64-QAM; following parameters: a 20 MHz channel; modulation of 64-QAM;
coding rate R is 3/4); in practice of IP-over-802.11-OCB a a coding rate R of 3/4). With regard to IP over 802.11-OCB, in
commonly observed figure is 12Mbit/s; this bandwidth allows practice, a commonly observed figure is 12 Mbit/s; this bandwidth allows
the operation of a wide range of protocols relying on IPv6. the operation of a wide range of protocols relying on IPv6.
</t> </t>
<ul spacing="normal">
<t> <li>
<list style='symbols'> Operation outside the context of a BSS (OCB): The 802.11-OCB links
<t> (previously 802.11p) are operated without a BSS. This means that IEE
Operation Outside the Context of a BSS (OCB): the (earlier E 802.11
802.11p) 802.11-OCB links are operated without a Basic beacon, Association Request/Response, Authentication
Service Set (BSS). This means that the frames IEEE 802.11 Request/Response, and similar frames are not used. The used
Beacon, Association Request/Response, Authentication identifier of BSS (BSSID) always has a hexadecimal value of
Request/Response, and similar, are not used. The used
identifier of BSS (BSSID) has a hexadecimal value always
0xffffffffffff (48 '1' bits, represented as MAC address 0xffffffffffff (48 '1' bits, represented as MAC address
ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as ff:ff:ff:ff:ff:ff; otherwise, the 'wildcard' BSSID), as
opposed to an arbitrary BSSID value set by administrator opposed to an arbitrary BSSID value set by an administrator
(e.g. 'My-Home-AccessPoint'). The OCB operation - namely (e.g., 'My-Home-AccessPoint'). The OCB operation -- namely,
the lack of beacon-based scanning and lack of the lack of beacon-based scanning and lack of
authentication - should be taken into account when the authentication -- should be taken into account when the
Mobile IPv6 protocol <xref target='RFC6275'/> and the Mobile IPv6 protocol <xref target="RFC6275" format="default"/> and t
protocols for IP layer security <xref target='RFC4301'/> he
protocols for IP layer security <xref target="RFC4301" format="defau
lt"/>
are used. The way these protocols adapt to OCB is not are used. The way these protocols adapt to OCB is not
described in this document. described in this document.
</t> </li>
<t>
Timing Advertisement: is a new message defined in <li>
802.11-OCB, which does not exist in 802.11a/b/g/n. This Timing Advertisement: This is a new message defined in
802.11-OCB that does not exist in 802.11a/b/g/n. This
message is used by stations to inform other stations about message is used by stations to inform other stations about
the value of time. It is similar to the time as delivered the value of time. It is similar to the time delivered
by a GNSS system (Galileo, GPS, ...) or by a cellular by a Global Navigation Satellite System (GNSS) (e.g., Galileo, GPS,
etc.) or by a cellular
system. This message is optional for implementation. system. This message is optional for implementation.
</t> </li>
<t>
Frequency range: this is a characteristic of the PHY <li>
layer, with almost no impact on the interface between MAC Frequency range: This is a characteristic of the PHY layer; it has
and IP. However, it is worth considering that the almost no impact on the interface between MAC and IP. However, it is
worth considering that the
frequency range is regulated by a regional authority frequency range is regulated by a regional authority
(ARCEP, ECC/CEPT based on ENs from ETSI, FCC, etc.); as (ARCEP, ECC/CEPT based on ENs from ETSI, FCC, etc.); as
part of the regulation process, specific applications are part of the regulation process, specific applications are
associated with specific frequency ranges. In the case of associated with specific frequency ranges.
802.11-OCB, the regulator associates a set of frequency In the case of 802.11-OCB, the regulator associates a set of frequency
ranges, or slots within a band, to the use of applications ranges or slots within a band to the use of applications of vehicular
of vehicular communications, in a band known as "5.9GHz". communications in a band known as "5.9 GHz".
The 5.9GHz band is different from the 2.4GHz and 5GHz The 5.9 GHz band is different from the 2.4 GHz and 5 GHz
bands used by Wireless LAN. However, as with Wireless bands used by Wireless LAN. However, as with Wireless LAN, the
LAN, the operation of 802.11-OCB in "5.9GHz" bands is operation of 802.11-OCB in 5.9 GHz bands does not require a
exempt from owning a license in EU (in US the 5.9GHz is a license in the EU (in the US, the 5.9 GHz is a licensed band of
licensed band of spectrum; for the fixed infrastructure an spectrum; for the fixed infrastructure, explicit FCC authorization
explicit FCC authorization is required; for an on-board is required; for an on-board device, a 'licensed-by-rule' concept
device a 'licensed-by-rule' concept applies: rule applies, where rule certification conformity is required). Technical
certification conformity is required.) Technical conditions are different from those of the "2.4 GHz"
conditions are different than those of the bands "2.4GHz" or "5 GHz" bands. The allowed power levels and, implicitly, the
or "5GHz". The allowed power levels, and implicitly the maximum allowed distance between vehicles is 33 dBm for
maximum allowed distance between vehicles, is of 33dBm for 802.11-OCB (in Europe) compared to 20 dBm for Wireless
802.11-OCB (in Europe), compared to 20 dBm for Wireless
LAN 802.11a/b/g/n; this leads to a maximum distance of LAN 802.11a/b/g/n; this leads to a maximum distance of
approximately 1km, compared to approximately 50m. approximately 1 km compared to approximately 50 m.
Additionally, specific conditions related to congestion Additionally, specific conditions related to congestion
avoidance, jamming avoidance, and radar detection are avoidance, jamming avoidance, and radar detection are
imposed on the use of DSRC (in US) and on the use of imposed on the use of DSRC (in the US) and on the use of
frequencies for Intelligent Transportation Systems (in frequencies for Intelligent Transportation Systems (in
EU), compared to Wireless LAN (802.11a/b/g/n). the EU) compared to Wireless LAN (802.11a/b/g/n).
</t> </li>
<t> <li>
'Half-rate' encoding: as the frequency range, this 'Half-rate' encoding: As the frequency range, this
parameter is related to PHY, and thus has not much parameter is related to PHY and thus does not have much
impact on the interface between the IP layer and the impact on the interface between the IP layer and the
MAC layer. MAC layer.
</t> </li>
<t> <li>
In vehicular communications using 802.11-OCB links, there In vehicular communications using 802.11-OCB links, there
are strong privacy requirements with respect to are strong privacy requirements with respect to
addressing. While the 802.11-OCB standard does not addressing. While the 802.11-OCB standard does not
specify anything in particular with respect to MAC specify anything in particular with respect to MAC
addresses, in these settings there exists a strong need addresses, in these settings, there is a strong need
for dynamic change of these addresses (as opposed to the for a dynamic change of these addresses (as opposed to the
non-vehicular settings - real wall protection - where non-vehicular settings -- real wall protection -- where
fixed MAC addresses do not currently pose some privacy fixed MAC addresses do not currently pose privacy
risks). This is further described in <xref risks). This is further described in <xref target="Security" format
target="Security"/>. A relevant function is described in ="default"/>. A relevant function is described in
documents IEEE 1609.3-2016 <xref target="IEEE-1609.3"/> <xref target="IEEE-1609.3" format="default"/>
and IEEE 1609.4-2016 <xref target="IEEE-1609.4"/>. and <xref target="IEEE-1609.4" format="default"/>.
</t> </li>
</list> </ul>
</t>
</section> </section>
<section title="Changes Needed on a software driver 802.11a to become a 802. <section anchor="software-changes" numbered="true" toc="default">
11-OCB driver" <name>Changes Needed on an 802.11a Software Driver to Become an 802.11-OCB
anchor="software-changes"> Driver</name>
<t> <t>
The 802.11p amendment modifies both the 802.11 stack's The 802.11p amendment modifies both the 802.11 stack's
physical and MAC layers but all the induced modifications physical and MAC layers, but all the induced modifications
can be quite easily obtained by modifying an existing can be quite easily obtained by modifying an existing
802.11a ad-hoc stack. 802.11a ad hoc stack.
</t> </t>
<t> <t>
Conditions for a 802.11a hardware to be 802.11-OCB compliant: The conditions for 802.11a hardware to be compliant with 802.11-OCB are
<list style='symbols'> as
<t> follows:
The PHY entity shall be an orthogonal frequency division </t>
multiplexing (OFDM) system. It must support the frequency <ul spacing="normal">
<li>
The PHY entity shall be an OFDM system. It must support the frequenc
y
bands on which the regulator recommends the use of ITS bands on which the regulator recommends the use of ITS
communications, for example using IEEE 802.11-OCB layer, communications -- for example, using an IEEE 802.11-OCB layer of
in France: 5875MHz to 5925MHz. 5875 MHz to 5925 MHz in France.
</t> </li>
<t> <li>
The OFDM system must provide a "half-clocked" operation The OFDM system must provide a "half-clocked" operation
using 10 MHz channel spacings. using 10 MHz channel spacings.
</t> </li>
<t>
The chip transmit spectrum mask must be compliant to the <li>
The chip transmit spectrum mask must be compliant with the
"Transmit spectrum mask" from the IEEE 802.11p amendment "Transmit spectrum mask" from the IEEE 802.11p amendment
(but experimental environments tolerate otherwise). (but experimental environments do not require compliance).
</t> </li>
<t>
<li>
The chip should be able to transmit up to 44.8 dBm when The chip should be able to transmit up to 44.8 dBm when
used by the US government in the United States, and up to used in the United States and up to
33 dBm in Europe; other regional conditions apply. 33 dBm in Europe; other regional conditions apply.
</t> </li>
</list> </ul>
</t>
<t> <t>
Changes needed on the network stack in OCB mode: Changes needed on the network stack in OCB mode are as follows:
<list style='symbols'> </t>
<t> <ul spacing="normal">
<li>
<t>
Physical layer: Physical layer:
<list style='symbols'> </t>
<t> <ul spacing="normal">
The chip must use the Orthogonal Frequency Multiple <li>
Access (OFDM) encoding mode. Orthogonal frequency-division multiple access
</t> The chip must use the Orthogonal Frequency Division Multiple
<t> Access (OFDMA) encoding mode.
The chip must be set in half-mode rate mode (the </li>
<li>
The chip must be set to half-mode rate mode (the
internal clock frequency is divided by two). internal clock frequency is divided by two).
</t> </li>
<t> <li>
The chip must use dedicated channels and should allow The chip must use dedicated channels and should allow
the use of higher emission powers. This may require the use of higher emission powers. This may require
modifications to the local computer file that modifications to the local computer file that
describes regulatory domains rules, if used by the describes regulatory domains rules if used by the
kernel to enforce local specific restrictions. Such kernel to enforce local specific restrictions. Such
modifications to the local computer file must respect modifications to the local computer file must respect
the location-specific regulatory rules. the location-specific regulatory rules.
</t> </li>
</list> </ul></li>
MAC layer: <li><t>
<list style='symbols'> MAC layer:
<t> </t>
<ul spacing="normal">
<li>
All management frames (beacons, join, leave, and All management frames (beacons, join, leave, and
others) emission and reception must be disabled others) emission and reception must be disabled,
except for frames of subtype Action and Timing except for frames of subtype Action and Timing
Advertisement (defined below). Advertisement (defined below).
</t> </li>
<t> <li>
No encryption key or method must be used. No encryption key or method must be used.
</t> </li>
<t> <li>
Packet emission and reception must be performed as in Packet emission and reception must be performed as in
ad-hoc mode, using the wildcard BSSID ad hoc mode using the wildcard BSSID
(ff:ff:ff:ff:ff:ff). (ff:ff:ff:ff:ff:ff).
</t> </li>
<t> <li>
The functions related to joining a BSS (Association The functions related to joining a BSS (Association
Request/Response) and for authentication Request/Response) and authentication
(Authentication Request/Reply, Challenge) are not (Authentication Request/Reply, Challenge) are not
called. called.
</t> </li>
<t> <li>
The beacon interval is always set to 0 (zero). The beacon interval is always set to 0 (zero).
</t> </li>
<t> <li>
Timing Advertisement frames, defined in the Timing Advertisement frames, defined in the
amendment, should be supported. The upper layer amendment, should be supported. The upper layer
should be able to trigger such frames emission and to should be able to trigger such frames emission and retrieve
retrieve information contained in received Timing information contained in the received Timing
Advertisements. Advertisements.
</t> </li>
</list> </ul>
</t> </li>
</list> </ul>
</t>
</section> </section>
<section title='Protocol Layering' <section anchor="epd" numbered="true" toc="default">
anchor='epd'> <name>Protocol Layering</name>
<t> <t>
A more theoretical and detailed view of layer stacking, and A more theoretical and detailed view of layer stacking and
interfaces between the IP layer and 802.11-OCB layers, is interfaces between the IP layer and 802.11-OCB layers is
illustrated in <xref target='fig:epd'/>. The IP layer illustrated in <xref target="fig_epd" format="default"/>. The IP layer
operates on top of the EtherType Protocol Discrimination operates on top of EtherType Protocol Discrimination
(EPD); this Discrimination layer is described in IEEE Std (EPD). This discrimination layer is described in <xref target="IEEE-802.
802.3-2012; the interface between IPv6 and EPD is the LLC_SAP 3-2012"/>. The interface between IPv6 and EPD is the LLC_SAP
(Link Layer Control Service Access Point). (Link Layer Control Service Access Point).
</t> </t>
<figure anchor="fig_epd">
<t> <name>EtherType Protocol Discrimination</name>
<figure align="center" <artwork align="center" name="" type="" alt=""><![CDATA[
title='EtherType Protocol Discrimination'
anchor='fig:epd'>
<artwork align="center">
<![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 | | IPv6 |
+-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+
{ LLC_SAP } 802.11-OCB { LLC_SAP } 802.11-OCB
+-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary
| EPD | | | | EPD | | |
| | MLME | | | | MLME | |
+-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP |
| MAC Sublayer | | | 802.11-OCB | MAC Sublayer | | | 802.11-OCB
| and ch. coord. | | SME | Services | and ch. coord. | | SME | Services
+-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| |
| | PLME | | | | PLME | |
| PHY Layer | PLME_SAP | | PHY Layer | PLME_SAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
]]> </figure>
</artwork>
</figure>
</t>
</section> </section>
<section title="Design Considerations" <section anchor="design-considerations" numbered="true" toc="default">
anchor="design-considerations"> <name>Design Considerations</name>
<t> <t>
The networks defined by 802.11-OCB are in many ways similar to The networks defined by 802.11-OCB are in many ways similar to
other networks of the 802.11 family. In theory, the other networks of the 802.11 family. In theory, the
transportation of IPv6 over 802.11-OCB could be very similar to transportation of IPv6 over 802.11-OCB could be very similar to
the operation of IPv6 over other networks of the 802.11 the operation of IPv6 over other networks of the 802.11
family. However, the high mobility, strong link asymmetry and family. However, the high mobility, strong link asymmetry, and
very short connection makes the 802.11-OCB link significantly very short connection makes the 802.11-OCB link significantly
different from other 802.11 networks. Also, the automotive different from other 802.11 networks. Also, automotive
applications have specific requirements for reliability, applications have specific requirements for reliability,
security and privacy, which further add to the particularity security, and privacy, which further add to the particularity
of the 802.11-OCB link. of the 802.11-OCB link.
</t> </t>
</section> </section>
<section anchor="OCB-messages" numbered="true" toc="default">
<name>IEEE 802.11 Messages Transmitted in OCB Mode</name>
<section title='IEEE 802.11 Messages Transmitted in OCB mode'
anchor="OCB-messages">
<t> <t>
For information, at the time of writing, this is the list of At the time of writing, this is the list of
IEEE 802.11 messages that may be transmitted in OCB mode, IEEE 802.11 messages that may be transmitted in OCB mode,
i.e. when dot11OCBActivated is true in a STA: i.e., when dot11OCBActivated is true in a STA:
<list style='symbols'> </t>
<t> <ul spacing="normal">
<li>
The STA may send management frames of subtype Action and, The STA may send management frames of subtype Action and,
if the STA maintains a TSF Timer, subtype Timing if the STA maintains a TSF Timer, subtype Timing
Advertisement; Advertisement.
</t> </li>
<t> <li>
The STA may send control frames, except those of subtype The STA may send control frames except those of subtype
PS-Poll, CF-End, and CF-End plus CFAck; PS-Poll, CF-End, and CF-End plus CFAck.
</t> </li>
<t> <li>
The STA MUST send data frames of subtype QoS The STA <bcp14>MUST</bcp14> send data frames of subtype QoS
Data. Data.
</t> </li>
</list> </ul>
</t>
</section> </section>
<section title='Examples of Packet Formats' <section anchor="example-packets" numbered="true" toc="default">
anchor="example-packets"> <name>Examples of Packet Formats</name>
<t> <t>
This section describes an example of an IPv6 Packet captured This section describes an example of an IPv6 packet captured
over a IEEE 802.11-OCB link. over an IEEE 802.11-OCB link.
</t> </t>
<t> <t>
By way of example we show that there is no modification in the By way of example, we show that there is no modification in the
headers when transmitted over 802.11-OCB networks - they are headers when transmitted over 802.11-OCB networks -- they are
transmitted like any other 802.11 and Ethernet packets. transmitted like any other 802.11 and Ethernet packets.
</t> </t>
<t> <t>
We describe an experiment of capturing an IPv6 packet on an We describe an experiment for capturing an IPv6 packet on an
802.11-OCB link. In topology depicted in <xref 802.11-OCB link. In the topology depicted in <xref target="topo" format
target='topo'/>, the packet is an IPv6 Router Advertisement. ="default"/>, the packet is an IPv6 Router Advertisement.
This packet is emitted by a Router on its 802.11-OCB This packet is emitted by a router on its 802.11-OCB
interface. The packet is captured on the Host, using a interface. The packet is captured on the host using a
network protocol analyzer (e.g. Wireshark); the capture is network protocol analyzer (e.g., Wireshark). The capture is
performed in two different modes: direct mode and 'monitor' performed in two different modes: direct mode and monitor
mode. The topology used during the capture is depicted below. mode. The topology used during the capture is depicted below.
</t> </t>
<t> <t>
The packet is captured on the Host. The Host is an IP-OBU The packet is captured on the host. The host is an IP-OBU
containing an 802.11 interface in format PCI express (an ITRI containing an 802.11 interface in Peripheral Component Interconnect
product). The kernel runs the ath5k software driver with (PCI) Express format (an Industrial Technology Research Institute
(ITRI) product). The kernel runs the ath5k software driver with
modifications for OCB mode. The capture tool is Wireshark. modifications for OCB mode. The capture tool is Wireshark.
The file format for save and analyze is 'pcap'. The packet is The file format for saving and analyzing is .pcap. The packet is
generated by the Router. The Router is an IP-RSU (ITRI generated by the router, which is an IP-RSU (an ITRI
product). product).
</t> </t>
<figure anchor="topo">
<t> <name>Topology for Capturing IP Packets on 802.11-OCB</name>
<figure align="center" <artwork align="center" name="" type="" alt=""><![CDATA[
title='Topology for capturing IP packets on 802.11-OCB' +--------+ +-------+
anchor='topo'> | | 802.11-OCB Link | |
<artwork align="center"> ---| Router |--------------------------------| Host |
<![CDATA[ | | | |
+--------+ +-------+ +--------+ +-------+ ]]></artwork>
| | 802.11-OCB Link | | </figure>
---| Router |--------------------------------| Host |
| | | |
+--------+ +-------+
]]>
</artwork>
</figure>
</t>
<t> <t>
During several capture operations running from a few moments During several capture operations running from a few moments
to several hours, no message relevant to the BSSID contexts to several hours, no messages relevant to the BSSID contexts
were captured (no Association Request/Response, Authentication were captured (Association Request/Response, Authentication
Req/Resp, Beacon). This shows that the operation of Req/Resp, or beacon). This shows that the operation of
802.11-OCB is outside the context of a BSSID. 802.11-OCB is outside the context of a BSSID.
</t> </t>
<t> <t>
Overall, the captured message is identical with a capture of Overall, the captured message is identical to a capture of
an IPv6 packet emitted on a 802.11b interface. The contents an IPv6 packet emitted on an 802.11b interface. The contents
are precisely similar. are exactly the same.
</t> </t>
<section numbered="true" toc="default">
<section title="Capture in Monitor Mode"> <name>Capture in Monitor Mode</name>
<t> <t>
The IPv6 RA packet captured in monitor mode is illustrated The IPv6 RA packet captured in monitor mode is illustrated
below. The radio tap header provides more flexibility for below. The Radiotap header provides more flexibility for
reporting the characteristics of frames. The Radiotap Header reporting the characteristics of frames. The Radiotap header
is prepended by this particular stack and operating system on is prepended by this particular stack and operating system on
the Host machine to the RA packet received from the network the host machine to the RA packet received from the network
(the Radiotap Header is not present on the air). The (the Radiotap header is not present on the air). The
implementation-dependent Radiotap Header is useful for implementation-dependent Radiotap header is useful for
piggybacking PHY information from the chip's registers as data piggybacking PHY information from the chip's registers as data
in a packet understandable by userland applications using in a packet that is understandable by userland applications using
Socket interfaces (the PHY interface can be, for example: socket interfaces (the PHY interface can be, for example,
power levels, data rate, ratio of signal to noise). power levels, data rate, or the ratio of signal to noise).
</t> </t>
<t> <t>
The packet present on the air is formed by IEEE 802.11 Data The packet present on the air is formed by the IEEE 802.11 Data
Header, Logical Link Control Header, IPv6 Base Header and header, Logical Link Control header, IPv6 Base header, and
ICMPv6 Header. ICMPv6 header.
</t> </t>
<t> <figure anchor="figA">
<figure align="center"> <name>Radiotap Header v0</name>
<artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
Radiotap Header v0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Revision| Header Pad | Header length | |Header Revision| Header Pad | Header Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Present flags | | Present Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Rate | Pad | | Data Rate | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
IEEE 802.11 Data Header <figure anchor="figB">
<name>IEEE 802.11 Data Header</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type/Subtype and Frame Ctrl | Duration | | Type/Subtype and Frame Ctrl | Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address... | Receiver Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Receiver Address | Transmitter Address... ... Receiver Address | Transmitter Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Transmitter Address | ... Transmitter Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSS Id... | BSS ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... BSS Id | Frag Number and Seq Number | ... BSS ID | Frag Number and Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
Logical-Link Control Header <figure anchor="figC">
<name>Logical Link Control Header</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP |I| SSAP |C| Control field | Org. code... | DSAP |I| SSAP |C| Control Field | Org. Code...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Organizational Code | Type | ... Organizational Code | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
IPv6 Base Header <figure anchor="figD">
<name>IPv6 Base Header</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label | |Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit | | Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
skipping to change at line 1699 skipping to change at line 1353
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
Router Advertisement <figure anchor="figE">
<name>Router Advertisement</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime | | Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- ]]></artwork></figure>
]]>
</artwork>
</figure>
</t>
<t> <t>
-+-+-+-+-+-+-+-+-+-+-+- <span class="insert">]]&gt;&lt;/artwork&gt;&lt;/figure& gt;</span>
The value of the Data Rate field in the Radiotap header is set The value of the Data Rate field in the Radiotap header is set
to 6 Mb/s. This indicates the rate at which this RA was to 6 Mb/s. This indicates the rate at which this RA was
received. received.
</t> </t>
<t> <t>
The value of the Transmitter address in the IEEE 802.11 Data The value of the Transmitter Address in the IEEE 802.11 Data
Header is set to a 48bit value. The value of the destination header is set to a 48-bit value. The value of the destination
address is 33:33:00:00:00:1 (all-nodes multicast address). address is 33:33:00:00:00:1 (all-nodes multicast address).
The value of the BSS Id field is ff:ff:ff:ff:ff:ff, which is The value of the BSS ID field is ff:ff:ff:ff:ff:ff, which is
recognized by the network protocol analyzer as being recognized by the network protocol analyzer as being
"broadcast". The Fragment number and sequence number fields "broadcast". The Fragment number and Sequence number fields
are together set to 0x90C6. together are set to 0x90C6.
</t> </t>
<t> <t>
The value of the Organization Code field in the The value of the Organization Code field in the
Logical-Link Control Header is set to 0x0, recognized as Logical Link Control header is set to 0x0, recognized as
"Encapsulated Ethernet". The value of the Type field is "Encapsulated Ethernet". The value of the Type field is
0x86DD (hexadecimal 86DD, or otherwise #86DD), recognized 0x86DD (hexadecimal 86DD; otherwise, #86DD), recognized
as "IPv6". as "IPv6".
</t> </t>
<t> <t>
A Router Advertisement is periodically sent by the router to A Router Advertisement is periodically sent by the router to
multicast group address ff02::1. It is an icmp packet type multicast group address ff02::1. It is ICMP packet type
134. The IPv6 Neighbor Discovery's Router Advertisement 134. The IPv6 Neighbor Discovery's Router Advertisement
message contains an 8-bit field reserved for single-bit flags, message contains an 8-bit field reserved for single-bit flags,
as described in <xref target="RFC4861"/>. as described in <xref target="RFC4861" format="default"/>.
</t> </t>
<t> <t>
The IPv6 header contains the link local address of the router The IPv6 header contains the link-local address of the router
(source) configured via EUI-64 algorithm, and destination (source) configured via the EUI-64 algorithm, and the destination
address set to ff02::1. address is set to ff02::1.
</t> </t>
<t> <t>
The Ethernet Type field in the logical-link control header The Ethernet Type field in the Logical Link Cntrol header
is set to 0x86dd which indicates that the frame transports is set to 0x86dd, which indicates that the frame transports
an IPv6 packet. In the IEEE 802.11 data, the destination an IPv6 packet. In the IEEE 802.11 data, the destination
address is 33:33:00:00:00:01 which is the corresponding address is 33:33:00:00:00:01, which is the corresponding
multicast MAC address. The BSS id is a broadcast address of multicast MAC address. The BSS ID is a broadcast address of
ff:ff:ff:ff:ff:ff. Due to the short link duration between ff:ff:ff:ff:ff:ff. Due to the short link duration between
vehicles and the roadside infrastructure, there is no need vehicles and the roadside infrastructure, there is no need in IEEE 802
in IEEE 802.11-OCB to wait for the completion of association .11-OCB
to wait for the completion of association
and authentication procedures before exchanging data. IEEE and authentication procedures before exchanging data. IEEE
802.11-OCB enabled nodes use the wildcard BSSID (a value of 802.11-OCB enabled nodes use the wildcard BSSID (a value of
all 1s) and may start communicating as soon as they arrive all 1s) and may start communicating as soon as they arrive
on the communication channel. on the communication channel.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Capture in Normal Mode"> <name>Capture in Normal Mode</name>
<t> <t>
The same IPv6 Router Advertisement packet described above The same IPv6 Router Advertisement packet described above
(monitor mode) is captured on the Host, in the Normal mode, (monitor mode) is captured on the host in normal mode and is
and depicted below. depicted below.
</t> </t>
<t> <figure anchor="figF">
<figure align="center"> <name>Ethernet II Header</name>
<artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
Ethernet II Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination... | Destination...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Destination | Source... ...Destination | Source...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Source | ...Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
IPv6 Base Header <figure anchor="figG">
<name>IPv6 Base Header</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label | |Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit | | Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
skipping to change at line 1817 skipping to change at line 1463
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
Router Advertisement <figure anchor="figH">
<name>Router Advertisement</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime | | Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- ]]></artwork></figure>
]]>
</artwork>
</figure>
</t>
<t> <t>
One notices that the Radiotap Header, the IEEE 802.11 Data -+-+-+-+-+-+-+-+-+-+-+- <span class="insert">]]&gt;&lt;/artwork&gt;&lt;/figure&
Header and the Logical-Link Control Headers are not present. gt;</span>
On the other hand, a new header named Ethernet II Header is One notices that the Radiotap header, the IEEE 802.11 Data
header, and the Logical Link Control headers are not present.
On the other hand, a new header named the Ethernet II header is
present. present.
</t> </t>
<t> <t>
The Destination and Source addresses in the Ethernet II header The Destination and Source addresses in the Ethernet II header
contain the same values as the fields Receiver Address and contain the same values as the Receiver Address and
Transmitter Address present in the IEEE 802.11 Data Header in Transmitter Address fields present in the IEEE 802.11 Data header in
the "monitor" mode capture. the monitor mode capture.
</t> </t>
<t> <t>
The value of the Type field in the Ethernet II header is The value of the Type field in the Ethernet II header is
0x86DD (recognized as "IPv6"); this value is the same value as 0x86DD (recognized as "IPv6"); this value is the same as
the value of the field Type in the Logical-Link Control Header the value of the Type field in the Logical Link Control header
in the "monitor" mode capture. in the monitor mode capture.
</t> </t>
<t> <t>
The knowledgeable experimenter will no doubt notice the The knowledgeable experimenter will no doubt notice the
similarity of this Ethernet II Header with a capture in normal similarity of this Ethernet II header with a capture in normal
mode on a pure Ethernet cable interface. mode on a pure Ethernet cable interface.
</t> </t>
<t> <t>
A frame translation is inserted on top of a pure IEEE 802.11 A frame translation is inserted on top of a pure IEEE 802.11
MAC layer, in order to adapt packets, before delivering the MAC layer in order to adapt packets before delivering the
payload data to the applications. It adapts 802.11 LLC/MAC payload data to the applications. It adapts 802.11 LLC/MAC
headers to Ethernet II headers. In further detail, this headers to Ethernet II headers. Specifically, this
adaptation consists in the elimination of the Radiotap, adaptation consists of the elimination of the Radiotap,
802.11 and LLC headers, and in the insertion of the Ethernet 802.11, and LLC headers and the insertion of the Ethernet
II header. In this way, IPv6 runs straight over LLC over II header. In this way, IPv6 runs straight over LLC over
the 802.11-OCB MAC layer; this is further confirmed by the the 802.11-OCB MAC layer; this is further confirmed by the
use of the unique Type 0x86DD. use of the unique Type 0x86DD.
</t> </t>
</section> </section>
</section> </section>
<section title='Extra Terminology' <section anchor="extra-terminology" numbered="true" toc="default">
anchor='extra-terminology'> <name>Extra Terminology</name>
<t> <t>
The following terms are defined outside the IETF. They are The following terms are defined outside the IETF. They are
used to define the main terms in the main terminology used to define the main terms in the terminology section (<xref target="t
<xref target='terminology'/>. erminology" format="default"/>).
</t> </t>
<t>
DSRC (Dedicated Short Range Communication): a term defined <dl newline="true">
outside the IETF. The US Federal Communications Commission <dt>DSRC (Dedicated Short Range Communication):</dt> <dd>The US Federal Communic
ations Commission
(FCC) Dedicated Short Range Communication (DSRC) is defined in (FCC) Dedicated Short Range Communication (DSRC) is defined in
the Code of Federal Regulations (CFR) 47, Parts 90 and 95. the Code of Federal Regulations (CFR) 47, Parts 90 <xref
This Code is referred in the definitions below. At the time target="CFR-90"/> and 95 <xref target="CFR-95"/>.
of the writing of this Internet Draft, the last update of this This Code is referenced in the definitions below. At the time
Code was dated October 1st, 2010. of the writing of this document, the last update of this
</t> Code was dated December 6, 2019.</dd>
<t>
DSRCS (Dedicated Short-Range Communications Services): a term <dt>DSRCS (Dedicated Short-Range Communications Services):</dt><dd>
defined outside the IETF. The use of radio techniques to Radio techniques are used to transfer data over short distances between
transfer data over short distances between roadside and mobile roadside and mobile units, between mobile units, and between portable and
units, between mobile units, and between portable and mobile mobile units to perform operations related to the improvement of traffic
units to perform operations related to the improvement of flow, traffic safety, and other intelligent transportation service
traffic flow, traffic safety, and other intelligent applications in a variety of environments. DSRCS systems may also transmit st
transportation service applications in a variety of atus and
environments. DSRCS systems may also transmit status and instructional messages related to the units involved. <xref
instructional messages related to the units involve. [Ref. 47 target="CFR-90.7"/></dd>
CFR 90.7 - Definitions]
</t> <dt>OBU (On-Board Unit):</dt><dd>An
<t>
OBU (On-Board Unit): a term defined outside the IETF. An
On-Board Unit is a DSRCS transceiver that is normally mounted On-Board Unit is a DSRCS transceiver that is normally mounted
in or on a vehicle, or which in some instances may be a in or on a vehicle or may be a portable unit in some instances. An OBU c
portable unit. An OBU can be operational while a vehicle or an be operational while a vehicle or
person is either mobile or stationary. The OBUs receive and person is either mobile or stationary. The OBUs receive and
contend for time to transmit on one or more radio frequency contend for time to transmit on one or more radio frequency
(RF) channels. Except where specifically excluded, OBU (RF) channels. Except where specifically excluded, OBU
operation is permitted wherever vehicle operation or human operation is permitted wherever vehicle operation or human
passage is permitted. The OBUs mounted in vehicles are passage is permitted. The OBUs mounted in vehicles are
licensed by rule under part 95 of the respective chapter and licensed by rule under part 95 of <xref target="CFR-95"/> and
communicate with Roadside Units (RSUs) and other OBUs. communicate with Roadside Units (RSUs) and other OBUs.
Portable OBUs are also licensed by rule under part 95 of the Portable OBUs are also licensed by rule under part 95 of <xref
respective chapter. OBU operations in the Unlicensed National target="CFR-95"/>. OBU operations in the Unlicensed National
Information Infrastructure (UNII) Bands follow the rules in Information Infrastructure (U-NII) Bands follow the rules in
those bands. - [CFR 90.7 - Definitions]. those bands. <xref target="CFR-90.7"/>
</t> </dd>
<t>
RSU (Road-Side Unit): a term defined outside of IETF. A <dt>RSU (Roadside Unit):</dt><dd>A
Roadside Unit is a DSRC transceiver that is mounted along a Roadside Unit is a DSRC transceiver that is mounted along a
road or pedestrian passageway. An RSU may also be mounted on road or pedestrian passageway. An RSU may also be mounted on
a vehicle or is hand carried, but it may only operate when the a vehicle or may be hand carried, but it may only operate when the
vehicle or hand- carried unit is stationary. Furthermore, an vehicle or hand-carried unit is stationary. Perhaps
RSU operating under the respectgive part is restricted to the Furthermore, an RSU is restricted to the location where it is licensed
location where it is licensed to operate. However, portable to operate. However, portable
or hand-held RSUs are permitted to operate where they do not or handheld RSUs are permitted to operate where they do not
interfere with a site-licensed operation. A RSU broadcasts interfere with a site-licensed operation. An RSU broadcasts
data to OBUs or exchanges data with OBUs in its communications data to OBUs or exchanges data with OBUs in its communications
zone. An RSU also provides channel assignments and operating zone. An RSU also provides channel assignments and operating
instructions to OBUs in its communications zone, when instructions to OBUs in its communications zone when
required. - [CFR 90.7 - Definitions]. required. <xref target="CFR-90.7"/>
</t> </dd>
</dl>
</section> </section>
<section anchor="nd-wireless" numbered="true" toc="default">
<section title='Neighbor Discovery (ND) Potential Issues in Wireless Links' <name>Neighbor Discovery (ND) Potential Issues in Wireless Links</name>
anchor='nd-wireless'>
<t> <t>
IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was IPv6 Neighbor Discovery (IPv6 ND) <xref target="RFC4861"/> <xref target="
designed for point-to-point and transit links such as RFC4862"/> was
Ethernet, with the expectation of a cheap and reliable support designed for point-to-point and transit links, such as
for multicast from the lower layer. Section 3.2 of RFC 4861 Ethernet, with the expectation of cheap and reliable support
indicates that the operation on Shared Media and on for multicast from the lower layer. <xref target="RFC4861"
non-broadcast multi-access (NBMA) networks require additional section="3.2" sectionFormat="of"/> indicates that the operation on shared
support, e.g., for Address Resolution (AR) and duplicate media and on
address detection (DAD), which depend on multicast. An NBMA networks require additional
support, e.g., for AR and DAD, which depend on multicast. An
infrastructureless radio network such as OCB shares properties infrastructureless radio network such as OCB shares properties
with both Shared Media and NBMA networks, and then adds its with both shared media and NBMA networks and then adds its
own complexity, e.g., from movement and interference that own complexity, e.g., from movement and interference that
allow only transient and non-transitive reachability between allow only transient and non-transitive reachability between
any set of peers. any set of peers.
</t> </t>
<t> <t>
The uniqueness of an address within a scoped domain is a key The uniqueness of an address within a scoped domain is a key
pillar of IPv6 and the base for unicast IP communication. RFC pillar of IPv6 and is the basis for unicast IP communication. <xref
4861 details the DAD method to avoid that an address is target="RFC4861"/> details the DAD method to prevent an address from
duplicated. For a link local address, the scope is the link, being duplicated. For a link-local address, the scope is the link,
whereas for a Globally Reachable address the scope is much whereas for a globally reachable address, the scope is much
larger. The underlying assumption for DAD to operate larger. The underlying assumption for DAD to operate
correctly is that the node that owns an IPv6 address can reach correctly is that the node that owns an IPv6 address can reach
any other node within the scope at the time it claims its any other node within the scope at the time it claims its
address, which is done by sending a NS multicast message, and address, which is done by sending a Neighbor Solicitation (NS) multicast message, and
can hear any future claim for that address by another party can hear any future claim for that address by another party
within the scope for the duration of the address ownership. within the scope for the duration of the address ownership.
</t> </t>
<t> <t>
In the case of OCB, there is a potentially a need to define a In the case of OCB, there is a potentially a need to define a scope that is
scope that is compatible with DAD, and that cannot be the set compatible with DAD. The scope cannot be the set of nodes that a transmitter
of nodes that a transmitter can reach at a particular time, can reach at a particular time because that set varies all the time and
because that set varies all the time and does not meet the DAD does not meet the DAD requirements for a link-local address that can be
requirements for a link local address that could possibly be used anytime and anywhere. The generic expectation of a reliable
used anytime, anywhere. The generic expectation of a reliable
multicast is not ensured, and the operation of DAD and AR multicast is not ensured, and the operation of DAD and AR
(Address Resolution) as specified by RFC 4861 cannot be as specified by <xref target="RFC4861"/> cannot be
guaranteed. Moreover, multicast transmissions that rely on guaranteed. Moreover, multicast transmissions that rely on
broadcast are not only unreliable but are also often broadcast are not only unreliable but are also often
detrimental to unicast traffic (see detrimental to unicast traffic (see <xref
[draft-ietf-mboned-ieee802-mcast-problems]). target="I-D.ietf-mboned-ieee802-mcast-problems" format="default"/>).
</t> </t>
<t> <t>
Early experience indicates that it should be possible to Early experience indicates that it should be possible to
exchange IPv6 packets over OCB while relying on IPv6 ND alone exchange IPv6 packets over OCB while relying on IPv6 ND alone
for DAD and AR (Address Resolution) in good conditions. In the absence for DAD and AR (Address Resolution) in good conditions. In the absence
of a correct DAD operation, a node that relies only on IPv6 ND of a correct DAD operation, a node that relies only on IPv6 ND
for AR and DAD over OCB should ensure that the addresses that for AR and DAD over OCB should ensure that the addresses that
it uses are unique by means others than DAD. It must be noted it uses are unique by means other than DAD. It must be noted
that deriving an IPv6 address from a globally unique MAC that deriving an IPv6 address from a globally unique MAC
address has this property but may yield privacy issues. address has this property but may yield privacy issues.
</t> </t>
<t> <t>
RFC 8505 provides a more recent approach to IPv6 ND and in <xref target="RFC8505"/> provides a more recent approach to IPv6 ND, in
particular DAD. RFC 8505 is designed to fit wireless and particular DAD. <xref target="RFC8505"/> is designed to fit wireless and
otherwise constrained networks whereby multicast and/or otherwise constrained networks whereby multicast and/or
continuous access to the medium may not be guaranteed. RFC continuous access to the medium may not be guaranteed. <xref
8505 Section 5.6 "Link-Local Addresses and Registration" target="RFC8505" sectionFormat="comma" section="5.6"/> ("Link-Local Addre
indicates that the scope of uniqueness for a link local sses and Registration")
address is restricted to a pair of nodes that use it to indicates that the scope of uniqueness for a link-local
communicate, and provides a method to assert the uniqueness address is restricted to a pair of nodes that uses it to
and resolve the link-Layer address using a unicast exchange. communicate and provides a method to assert the uniqueness
and resolve the link-layer address using a unicast exchange.
</t> </t>
<t> <t>
RFC 8505 also enables a router (acting as a 6LR) to own a <xref target="RFC8505"/> also enables a router (acting as a 6LR) to own a
prefix and act as a registrar (acting as a 6LBR) for addresses prefix and act as a registrar (acting as a 6LBR) for addresses
within the associated subnet. A peer host (acting as a 6LN) within the associated subnet. A peer host (acting as a 6LN)
registers an address derived from that prefix and can use it registers an address derived from that prefix and can use it
for the lifetime of the registration. The prefix is advertised for the lifetime of the registration. The prefix is advertised
as not onlink, which means that the 6LN uses the 6LR to relay as not on-link, which means that the 6LN uses the 6LR to relay
its packets within the subnet, and participation to the subnet its packets within the subnet, and participation to the subnet
is constrained to the time of reachability to the 6LR. Note is constrained to the time of reachability to the 6LR. Note
that RSU that provides internet connectivity MAY announce a that an RSU that provides internet connectivity <bcp14>MAY</bcp14> announ
default router preference <xref target='RFC4191'/>, whereas a car that do ce a
es default router preference <xref target="RFC4191" format="default"/>, wher
not provide that connectivity MUST NOT do so. This operation eas a car that does
presents similarities with that of an access point, but at not provide that connectivity <bcp14>MUST NOT</bcp14> do so. This operati
Layer-3. This is why RFC 8505 well-suited for wireless in on
presents similarities to that of an access point, but at
Layer 3. This is why <xref target="RFC8505"/> is well suited for wireless
in
general. general.
</t> </t>
<t> <t>
Support of RFC 8505 may be implemented on OCB. OCB nodes Support of <xref target="RFC8505"/> may be implemented on OCB. OCB nodes
that support RFC 8505 SHOULD support the 6LN operation in order that support <xref target="RFC8505"/> <bcp14>SHOULD</bcp14> support the 6
to act as a host, and may support the 6LR and 6LBR operations LN operation in order
in order to act as a router and in particular own a prefix to act as a host and may support the 6LR and 6LBR operations
that can be used by RFC 8505-compliant hosts for address in order to act as a router and in particular to own a prefix
that can be used by hosts that are compliant with <xref target="RFC8505"/
> for address
autoconfiguration and registration. autoconfiguration and registration.
</t> </t>
</section> </section>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The authors would like to thank <contact fullname="Alexandre Petrescu"/>
for
initiating this work and for being the lead author up to draft version 4
3 of
this document.
</t>
<t>
The authors would like to thank <contact fullname="Pascal Thubert"/> for
reviewing,
proofreading, and suggesting modifications for this document.
</t>
<t>
The authors would like to thank <contact fullname="Mohamed Boucadair"/>
for
proofreading and suggesting modifications for this document.
</t>
<t>
The authors would like to thank <contact fullname="Eric Vyncke"/> for
reviewing the suggesting modifications of this document.
</t>
<t>
The authors would like to thank <contact fullname="Witold Klaudel"/>, <c
ontact fullname="Ryuji Wakikawa"/>, <contact fullname="Emmanuel
Baccelli"/>, <contact fullname="John Kenney"/>, <contact fullname="John Moring"/
>,
<contact fullname="Francois Simon"/>, <contact fullname="Dan Romascanu"/
>, <contact fullname="Konstantin Khait"/>, <contact fullname="Ralph Droms"/>,
<contact fullname="Richard 'Dick' Roy"/>, <contact fullname="Ray Hunter"
/>, <contact fullname="Tom Kurihara"/>, <contact fullname="Michal Sojka"/>,
<contact fullname="Jan de Jongh"/>, <contact fullname="Suresh Krishnan"/
>, <contact fullname="Dino Farinacci"/>, <contact fullname="Vincent Park"/>,
<contact fullname="Jaehoon Paul Jeong"/>, <contact fullname="Gloria Gwyn
ne"/>, <contact fullname="Hans-Joachim Fischer"/>, <contact fullname="Russ
Housley"/>, <contact fullname="Rex Buddenberg"/>, <contact fullname="Eri
k Nordmark"/>, <contact fullname="Bob Moskowitz"/>, <contact fullname="Andrew
Dryden"/>, <contact fullname="Georg Mayer"/>, <contact fullname="Dorothy
Stanley"/>, <contact fullname="Sandra Cespedes"/>, <contact fullname="Mariano
Falcitelli"/>, <contact fullname="Sri Gundavelli"/>, <contact fullname="
Abdussalam Baryun"/>, <contact fullname="Margaret Cullen"/>, <contact
fullname="Erik Kline"/>, <contact fullname="Carlos Jesus Bernardos Cano"/>,
<contact fullname="Ronald in 't
Velt"/>, <contact fullname="Katrin Sjoberg"/>, <contact fullname="Roland
Bless"/>, <contact fullname="Tijink Jasja"/>, <contact fullname="Kevin Smith"/>
,
<contact fullname="Brian Carpenter"/>, <contact fullname="Julian Reschke
"/>, <contact fullname="Mikael Abrahamsson"/>, <contact fullname="Dirk von
Hugo"/>, <contact fullname="Lorenzo Colitti"/>, <contact
fullname="Pascal Thubert"/>, <contact fullname="Ole Troan"/>, <contact
fullname="Jinmei Tatuya"/>, <contact fullname="Joel Halpern"/>, <contact fullnam
e="Eric
Gray"/>, and <contact fullname="William Whyte"/>. Their
valuable comments clarified particular issues and generally
helped to improve the document.
</t>
<t>
<contact fullname="Pierre Pfister"/>, <contact fullname="Rostislav Lisov
y"/>, and others wrote 802.11-OCB
drivers for Linux.
</t>
<t>
For the multicast discussion, the authors would like to thank
<contact fullname="Owen DeLong"/>, <contact fullname="Joe Touch"/>,
<contact fullname="Jen Linkova"/>, <contact fullname="Erik Kline"/>, <contact fu
llname="Brian
Haberman"/>, and participants to discussions in network working
groups.
</t>
<t>
The authors would like to thank the participants of the
Birds-of-a-Feather "Intelligent Transportation Systems"
meetings held at IETF in 2016.
</t>
<t>
The human rights protocol considerations review was done by <contact full
name="Amelia Andersdotter"/>.
</t>
<t>The work of <contact fullname="Jong-Hyouk Lee"/> was supported by the Nationa
l Research Foundation
of Korea (NRF) grant funded by the Korea government (MSIT) (NRF-2018R1A4A1025632
).</t>
<t>The work of <contact fullname="Jérôme Härri"/> was supported by EURECOM indus
trial members,
namely BMW Group, IABG, Monaco Telecom, Orange, SAP and Symantec. This RFC
reflects the view of the IPWAVE WG and does not necessarily reflect the
official policy or position of EURECOM industrial members.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>
<contact fullname="Christian Huitema"/> and <contact fullname="Tony Li"/
> contributed to this document.
</t>
<t>
<contact fullname="Romain Kuntz"/> contributed extensively regarding IPv
6 handovers
between links running outside the context of a BSS (802.11-OCB
links).
</t>
<t>
<contact fullname="Tim Leinmueller"/> contributed the idea of the use of
IPv6 over
802.11-OCB for the distribution of certificates.
</t>
<t>
<contact fullname="Marios Makassikis"/>, <contact fullname="Jose Santa L
ozano"/>, <contact fullname="Albin Severinson"/>, and
<contact fullname="Alexey Voronov"/> provided significant feedback on th
e experience
of using IP messages over 802.11-OCB in initial trials.
</t>
<t>
<contact fullname="Michelle Wetterwald"/> contributed extensively to the
MTU
discussion, offered the ETSI ITS perspective, and reviewed
other parts of the document.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 331 change blocks. 
1415 lines changed or deleted 1223 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/