<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>

<!-- [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" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="yes" number="XXXX" ipr="trust200902">

  <!-- category values: std, bcp, info, exp, and historic ipr values:
       trust200902, noModificationTrust200902,
       noDerivativesTrust200902, or pre5378Trust200902 you can add the
       attributes updates="NNNN" and obsoletes="NNNN" they will
       automatically be output with "(if approved)" consensus="true" number="8691" docName="draft-ietf-ipwave-ipv6-over-80211ocb-52" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.31.0 -->

  <front>
    <title abbrev="IPv6-over-80211-OCB"> abbrev="IPv6 over 802.11-OCB">
Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside the Context of a Basic
Service Set over IEEE Std 802.11
    </title>
    <seriesInfo name="RFC" value="8691"/>
    <author initials='N.' initials="N." surname="Benamar" fullname='Nabil Benamar'> fullname="Nabil Benamar">
      <organization>Moulay Ismail University of Meknes</organization>
      <address>
        <postal>
          <street>
          </street>
          <city>
          </city>
          <region>
          </region>
          <code>
          </code>
          <country>
            Morocco
          </country>
        </postal>
        <phone>
          +212670832236
        </phone>
        <email>
          n.benamar@est.umi.ac.ma
        </email>
      </address>
    </author>
    <author initials="J." surname="Haerri" fullname="Jerome Haerri">
      <organization>Eurecom</organization> surname="Härri" fullname="Jérôme Härri">
      <organization>EURECOM</organization>
      <address>
        <postal>
          <street>
          </street>
          <city> Sophia-Antipolis
          </city>
          <city>Sophia-Antipolis</city>
          <region>
          </region>
          <code> 06904
          </code>
          <code>06904</code>
          <country>
            France
          </country>
        </postal>
        <phone>
          +33493008134
        </phone>
        <email>
          Jerome.Haerri@eurecom.fr
        </email>
      </address>
    </author>
    <author fullname="Jong-Hyouk Lee" initials="J.-H." initials="J." surname="Lee">
      <organization>
        Sangmyung University
      </organization>
      <organization>Sangmyung University</organization>
      <address>
        <postal>
          <street>
            31, Sangmyeongdae-gil, Dongnam-gu
          </street>
          <code>
            31066
          </code>
          <city>
            Cheonan
          </city>
          <country>
            Republic of Korea
          </country>
        </postal>
        <email>
          jonghyouk@smu.ac.kr
        </email>
      </address>
    </author>
    <author initials="T." surname="Ernst" fullname="Thierry Ernst"> ERNST">
      <organization>YoGoKo</organization>
      <address>
        <postal>
          <street>
          </street>
          <city>
          </city>
          <region>
          </region>
          <code>
          </code>
          <street>1137A Avenue des Champs-Blancs</street>
          <city>CESON-SEVIGNE</city>
          <region></region>
          <code>35510</code>
          <country>
            France
          </country>
        </postal>
        <phone>
        </phone>
        <phone />
        <email>
          thierry.ernst@yogoko.fr
        </email>
      </address>
    </author>
    <date year='2019' month="September"/>

    <!-- Meta-data Declarations --> year="2019" month="December"/>

    <area>Internet</area>
    <workgroup>IPWAVE Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc, IETF is fine for
         individual submissions.  If this element is not present, the
         default is "Network Working Group", which is used by the RFC
         Editor as a nod to the history of the IETF. -->

    <keyword>
      IPv6
    <keyword>IPv6 over 802.11p, OCB, IPv6 802.11p</keyword>
    <keyword>OCB</keyword>
    <keyword>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. --> 802.11-OCB</keyword>
    <abstract>
      <t>
        This document provides methods and settings, settings
        for using IPv6 to communicate among nodes within range of one another
        over a single IEEE 802.11-OCB link. Support for these methods and
        settings require minimal changes to existing stacks. This document
        also describes limitations associated with using these methods.
        Optimizations and usage of IPv6 over more complex scenarios
        is
        are not covered in this specification and is are a subject of for future work.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        This document provides a baseline for using IPv6 to
        communicate among nodes in range of one another over a single IEEE 802.11-OCB link
        <xref target="IEEE-802.11-2016"/> target="IEEE-802.11-2016" format="default"/> (a.k.a., "802.11p" 802.11p;
	see Appendices <xref target='i802.11p'/>, target="i802.11p" format="counter"/>,
        <xref target='introduced-by-OCB'/> target="introduced-by-OCB" format="counter"/>, and <xref target='software-changes'/>) target="software-changes" format="counter"/>)
        with minimal changes to existing stacks. Moreover, the document
	identifies the limitations
        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 Std 802.3
        MAC layer with a frame translation underneath. The resulting stack is derived from IPv6
        over Ethernet <xref target='RFC2464'/>, target="RFC2464" format="default"/> but operates over 802.11-OCB to provide at least P2P (Point to Point) (point-to-point) connectivity
        using IPv6 ND Neighbor Discovery (ND) and link-local addresses.
      </t>
      <t>
	   The IPv6 network layer operates on 802.11-OCB in the same
	   manner as operating on the Ethernet with the following
	   exceptions:
      </t>
      <t>
        <list style='symbols'>
	  <t>
      <ul spacing="normal">
        <li>
	    Exceptions due to the different operation of the IPv6 network
	    layer on 802.11 than on compared to the Ethernet. The operation of IP
        on Ethernet is described in <xref target='RFC1042'/> target="RFC1042" format="default"/> and <xref
	    target='RFC2464'/>.

	  </t>
	  <t> target="RFC2464" format="default"/>.

	  </li>
        <li>
	    Exceptions due to the OCB nature of 802.11-OCB compared to
	    802.11.  This has impacts on security, privacy, subnet
	    structure
	    structure, and movement detection.  Security and
	    privacy recommendations are discussed in Sections <xref target='Security'/>
	    target="slaac" format="counter"/> and <xref target='slaac'/>. target="Security" format="counter"/>.  The subnet structure is described
	    in <xref target='subnet-structure'/>. target="subnet-structure" format="default"/>.  The movement
	    detection on OCB links is not described in this document.
        Likewise, ND Extensions extensions and IPWAVE IP Wireless Access in Vehicular
	Environments (IPWAVE) optimizations for vehicular communications are
        not in scope. scope of this document.  The expectation is that further specifications will be edited to cover
        more complex vehicular networking scenarios.

	    </t>
	  </list>
      </t>

	    </li>
      </ul>
      <t>
        The reader may refer to <xref target='IPWAVE-NETWORKING'/> target="I-D.ietf-ipwave-vehicular-networking" format="default"/> for an overview of
        problems related to running IPv6 over 802.11-OCB. It is out of scope
	of this document to reiterate those. those problems.
      </t>
    </section>
    <section title="Terminology"
	     anchor='terminology'> anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
	RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14
	<!-- <xref target="BCP14"/> --> BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174" /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      <t>
    The document makes uses of the following terms:
	IP-OBU terms:</t>
<dl newline="true">
<dt>IP-OBU (Internet Protocol On-Board Unit): an Unit):</dt>
<dd>An IP-OBU denotes a
	computer situated in a vehicle such as a car, bicycle,
	or similar.  It has at least one IP interface that runs in
	mode OCB of 802.11, 802.11 and that has an "OBU" transceiver.  See
	the definition of the term "OBU" in section <xref
	target='extra-terminology'/>.
      </t>
      <t>
        IP-RSU target="extra-terminology" format="default"/>.</dd>
<dt>IP-RSU (IP Road-Side Unit): an Roadside Unit):</dt>
     <dd>An IP-RSU is situated along the
        road.  It has at least two distinct IP-enabled interfaces. The
        wireless PHY/MAC layer of at least one of its IP-enabled
        interfaces is configured to operate in 802.11-OCB mode.  An
        IP-RSU communicates with the IP-OBU in the vehicle over an 802.11
        wireless link operating in OCB mode.  An IP-RSU is similar to
        an Access Network Router (ANR) (ANR), defined in <xref
        target="RFC3753"/>, target="RFC3753" format="default"/>, and a Wireless Termination Point (WTP) (WTP),
        defined in <xref target='RFC5415'/>.
      </t>
      <t>
        OCB target="RFC5415" format="default"/>.</dd>
<dt>OCB (outside the context of a basic service set Basic Service Set - BSS): BSS):</dt>
<dd>This is a mode
        of operation in which a STA station (STA) is not a member of a BSS and does
        not utilize IEEE Std 802.11 authentication, association, or
        data confidentiality.
      </t>
      <t>
        802.11-OCB: confidentiality.</dd>
<dt>802.11-OCB:</dt><dd> This refers to the mode specified in IEEE Std 802.11-2016 when the
        MIB attribute dot11OCBActivited is 'true'.
      </t> 'true'.</dd>
</dl>

    </section>
    <section
        title="Communication numbered="true" toc="default">
      <name>Communication Scenarios where Where IEEE 802.11-OCB Links are Used"
        > Are Used</name>
      <t>
        The
        IEEE 802.11-OCB networks are used for vehicular
        communications,
        communications as 'Wireless Access in Vehicular
        Environments'. In particular, we refer the reader to <xref
        target='IPWAVE-NETWORKING'/>, that target="I-D.ietf-ipwave-vehicular-networking" format="default"/>, which lists
        some scenarios and requirements for IP in Intelligent
        Transportation Systems (ITS).
      </t>

      <t>
	The link model is the following: STA --- 802.11-OCB --- STA.
	In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs.
    All links are assumed to be P2P P2P, and multiple links can be on one radio
    interface. While 802.11-OCB is clearly specified, specified and a legacy IPv6
    stack can operate on such links, the use of the operating environment
    (vehicular networks) brings in new perspectives.
      </t>
    </section>
    <section
        title="IPv6 numbered="true" toc="default">
      <name>IPv6 over 802.11-OCB"> 802.11-OCB</name>
      <section title="Maximum anchor="MTU" numbered="true" toc="default">
        <name>Maximum Transmission Unit (MTU)"
	       anchor="MTU"> (MTU)</name>
        <t>
          The default MTU for IP packets on 802.11-OCB is inherited
          from <xref target='RFC2464'/> and is, target="RFC2464" format="default"/> and, as such, is 1500 octets.
          As noted in <xref target="RFC8200"/>, target="RFC8200" format="default"/>, every link on the Internet must have a
          minimum MTU of 1280 octets, as well as octets and must follow the other
          recommendations, especially with regard to fragmentation.
        </t>
      </section>
      <section title="Frame Format"> numbered="true" toc="default">
        <name>Frame Format</name>
        <t>
	  IP packets MUST <bcp14>MUST</bcp14> be transmitted over 802.11-OCB media as QoS
	  Data
	  data frames whose format is specified in an IEEE 802.11 spec
      <xref target="IEEE-802.11-2016"></xref>. target="IEEE-802.11-2016" format="default"/>.
        </t>
        <t>
	  The IPv6 packet transmitted on 802.11-OCB are is
	  immediately preceded by a Logical Link Control (LLC) header
	  and an 802.11 header.  In the LLC header, header and in accordance
	  with the EtherType Protocol Discrimination (EPD, (EPD; see <xref
	  target='epd'/>), target="epd" format="default"/>), the value of the Type field MUST <bcp14>MUST</bcp14> be set to
	  0x86DD (IPv6).  The mapping to the 802.11 data service SHOULD <bcp14>SHOULD</bcp14>
      use a 'priority' value of 1  (QoS with a 'Background' user priority),
      reserving higher priority values for safety-critical and time-sensitive
      traffic, including the ones listed in <xref target="ETSI-sec-archi"></xref>. target="ETSI-sec-archi" format="default"/>.

        </t>
        <t>
	  To simplify the Application Programming Interface (API)
	  between the operating system and the 802.11-OCB media,
	  device drivers MAY <bcp14>MAY</bcp14> implement IPv6-over-Ethernet IPv6 over Ethernet as per <xref target='RFC2464'/> target="RFC2464" format="default"/>
      and then a frame translation from 802.3 to 802.11 in order
      to  minimize the code changes.
        </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 anchor='ll' title='Link-Local Addresses'> anchor="ll" numbered="true" toc="default">
        <name>Link-Local Addresses</name>
        <t>
	  There are several types of IPv6 addresses <xref
	  target='RFC4291'/>, target="RFC4291" format="default"/> <xref target='RFC4193'/>, target="RFC4193" format="default"/> that may be
	  assigned to an 802.11-OCB interface.  Among these types of
	  addresses
	  addresses, only the IPv6 link-local addresses can be formed
	  using an EUI-64 identifier, in particular particularly during transition
	  time,
	  time (the period of time spent before an interface starts using a different an address than
	  different from the LL one).
        </t>
        <t>
	  If the IPv6 link-local address is formed using an EUI-64
	  identifier, then the mechanism of for forming that address is
	  the same mechanism as that used to form an IPv6 link-local
	  address on Ethernet links. Moreover, regardless of whether or not the interface
      identifier is derived from the EUI-64 identifier, its length is 64 bits bits,
      as is the case for the Ethernet <xref target='RFC2464'/>. target="RFC2464" format="default"/>.
        </t>
      </section>
      <section title='Stateless Autoconfiguration'
	       anchor='slaac'> anchor="slaac" numbered="true" toc="default">
        <name>Stateless Autoconfiguration</name>
        <t>
	  The steps a host takes in deciding how to
      autoconfigure its interfaces in IPv6 are described
      in <xref target='RFC4862'/>. target="RFC4862" format="default"/>.  This section describes
	  the formation of Interface Identifiers for IPv6 addresses of
	  type 'Global' or 'Unique Local'. Local' IPv6 addresses.  Interface Identifiers
	  for 'link-local' IPv6 address of type 'Link-Local' addresses are discussed in <xref target='ll'/>. target="ll" format="default"/>.
        </t>
        <t>
          The RECOMMENDED <bcp14>RECOMMENDED</bcp14> method for forming
          stable Interface Identifiers (IIDs) is described in <xref
          target='RFC8064'/>. target="RFC8064" format="default"/>.  The method of forming IIDs described in
          Section 4 of
          <xref target='RFC2464'/> MAY target="RFC2464" sectionFormat="of" section="4"/> <bcp14>MAY</bcp14> be used during
          transition time, in particular particularly for IPv6 link-local
          addresses.  Regardless of how the method used to form the IID,
          its length is 64 bits, similarely similarly to IPv6 over Ethernet <xref target='RFC2464'/>. target="RFC2464" format="default"/>.
        </t>

        <t>
          The bits in the IID have no specific meaning meaning,
          and the identifier should be treated as an opaque value.
          The bits 'Universal' and 'Group' in the identifier of an
          802.11-OCB interface are significant, as this interface, which is an IEEE link-layer address. address, are
	  significant.  The details of this significance are
          described in <xref target="RFC7136"/>. target="RFC7136" format="default"/>.
        </t>
        <t>
	  Semantically opaque IIDs, instead of
	  meaningful IIDs derived from a valid and
	  meaningful MAC address (<xref target='RFC2464'/>, Section
	  4), target="RFC2464" sectionFormat="comma" section="4"/>), help avoid certain privacy risks (see the risks
	  mentioned in <xref target='privacy-opaque-iid'/>). target="privacy-opaque-iid" format="default"/>).  If
	  semantically opaque IIDs are needed, they
	  may be generated using the method for generating
	  semantically opaque IIDs with IPv6
	  Stateless Address Autoconfiguration given in <xref
	  target="RFC7217"/>. target="RFC7217" format="default"/>.  Typically, an opaque IID is formed starting from identifiers different
	  than
	  from the MAC addresses, addresses and from cryptographically strong
	  material.  Thus, privacy sensitive privacy-sensitive information is absent
	  from Interface IDs, IDs because it is impossible to calculate
	  back the initial value from which the Interface ID was first
	  generated.
        </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>
	  Some applications that use IPv6 packets on 802.11-OCB links
	  (among other link types) may benefit from IPv6 addresses
	  whose IIDs don't change too often.  It is
	  RECOMMENDED
	  <bcp14>RECOMMENDED</bcp14> to use the mechanisms described in RFC 7217 <xref target="RFC7217"/> to
	  permit the use of Stable stable IIDs that do not
	  change within one subnet prefix.  A possible source for the
	  Net-Iface Parameter
	  Net_Iface parameter is a virtual interface name, name or logical
	  interface name, name that is decided by a local administrator.
        </t>
      </section>
      <section title='Address Mapping'> numbered="true" toc="default">
        <name>Address Mapping</name>
        <t>
	  Unicast and multicast address mapping MUST <bcp14>MUST</bcp14> follow the
	  procedures specified for Ethernet interfaces specified described in in Sections 6 <xref
	  target="RFC2464" sectionFormat="bare" section="6"/> and 7  <xref
	  target="RFC2464" sectionFormat="bare" section="7"/> of <xref target='RFC2464'/>. target="RFC2464"/>.
        </t>
        <section title='Address numbered="true" toc="default">
          <name>Address Mapping -- Unicast'> Unicast</name>
          <t>
	    This document is scoped for Address Resolution (AR) and Duplicate Address Detection (DAD) per <xref
	    target="RFC4862"/>. target="RFC4862" format="default"/>.
          </t>
        </section>
        <section anchor="address-mapping-multicast" title="Address numbered="true" toc="default">
          <name>Address Mapping -- Multicast"> Multicast</name>

          <t>
	    The multicast address mapping is performed according to
	    the method specified in section 7 of <xref
	    target='RFC2464'/>. section="7" target="RFC2464" sectionFormat="of"/>.  The meaning of the value "3333" "33-33"
	    mentioned there is
	    defined in section 2.3.1 of <xref target='RFC7042'/>. target="RFC7042"
	    sectionFormat="of" section="2.3.1"/>.
          </t>
          <t>
            Transmitting IPv6 packets to multicast destinations over
            802.11 links proved to have some performance issues <xref
            target='ieee802-MCAST'/>. target="I-D.ietf-mboned-ieee802-mcast-problems" format="default"/>.  These
            issues may be exacerbated in OCB mode.
            A future
            Future improvement to this specification should consider solutions for these problems.
          </t>
        </section>
      </section>
      <section title='Subnet Structure' anchor='subnet-structure'> anchor="subnet-structure" numbered="true" toc="default">
        <name>Subnet Structure</name>
        <t>
	  When vehicles are in close range, a subnet may be formed over
      802.11-OCB interfaces (not by their in-vehicle interfaces).
      A Prefix List conceptual data structure (<xref
	  target='RFC4861'/> Section 5.1) target="RFC4861"
      sectionFormat="comma" section="5.1"/>) is maintained for each
	  802.11-OCB interface.
        </t>
        <t>
	  The IPv6 Neighbor Discovery protocol (ND) requires reflexive properties
      (bidirectional connectivity) connectivity), which is generally, though not always, the case for P2P OCB links.
      IPv6 ND also requires transitive properties for DAD and AR, so an IPv6 subnet can be mapped
      on an OCB network only if all nodes in the network share a single
      physical broadcast domain. The extension to IPv6 ND operating on a
      subnet that covers multiple OCB links and does not fully overlapping (NBMA) overlap
      (i.e., non-broadcast multi-access (NBMA)) is not in scope. scope of this document.
      Finally, IPv6 ND requires a permanent connectivity of all nodes in the subnet
      to defend their addresses, addresses -- in other words words, very stable network conditions.

        </t>
        <t>
	  The structure of this subnet is ephemeral, ephemeral in that it is
	  strongly influenced by the mobility of vehicles: the hidden
	  terminal effects appear; appear, and the 802.11 networks in OCB mode may
	  be considered as 'ad-hoc' ad hoc networks with an addressing model model,
	  as described in <xref target='RFC5889'/>. target="RFC5889" format="default"/>.  On another the other hand,
	  the structure of the internal subnets in each vehicle is
	  relatively stable.
        </t>
        <t>
	  As recommended in <xref target='RFC5889'/>, target="RFC5889" format="default"/>, when the timing
	  requirements are very strict (e.g., fast-drive-through IP-RSU
	  coverage), no on-link subnet prefix should be configured on
	  an 802.11-OCB interface.  In such cases, the exclusive use
	  of IPv6 link-local addresses is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
        </t>
        <t>
	  Additionally, even if the timing requirements are not very
	  strict (e.g., the moving subnet formed by two following
	  vehicles is stable, a fixed IP-RSU is absent), the subnet is
	  disconnected from the Internet (i.e., a default route is absent),
	  and the addressing peers are equally qualified (that is, it is impossible
	  to determine that whether some vehicle owns and distributes
	  addresses to others) others), the use of link-local addresses is
	  RECOMMENDED.
	  <bcp14>RECOMMENDED</bcp14>.
        </t>
        <t>
	   The baseline ND protocol <xref
	   target='RFC4861'/> MUST target="RFC4861" format="default"/> <bcp14>MUST</bcp14> be supported over 802.11-OCB links.
	   Transmitting ND packets may prove to have some performance
	   issues
	   issues, as mentioned in <xref target='address-mapping-multicast'/>, target="address-mapping-multicast" format="default"/> and
       <xref target='nd-wireless'/>. target="nd-wireless" format="default"/>.
       These issues may be exacerbated in OCB mode.
	   Solutions for these problems should consider the OCB mode
	   of operation. Future solutions to OCB should consider solutions
       for avoiding broadcast. The best of current knowledge
       indicates the kinds of issues that may arise with ND in
       OCB mode; they are described in <xref target="nd-wireless"/>.
	</t>

	<!-- <t> -->
	<!--   The Neighbor Discovery protocol (ND) <xref -->
	<!--   target='RFC4861'/> is used over 802.11-OCB links.  The -->
	<!--   reliability of the ND protocol over 802.11-OCB is the -->
	<!--   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. -->
	<!-- target="nd-wireless" format="default"/>.
        </t> -->
        <t>
	  Protocols like Mobile IPv6 <xref target='RFC6275'/> , target="RFC6275" format="default"/>
	  <xref target='RFC3963'/> target="RFC3963" format="default"/> and
	  DNAv6 <xref target='RFC6059'/>, target="RFC6059" format="default"/>, which depend on a timely
	  movement detection, might need additional tuning work to
	  handle the lack of link-layer notifications during handover.
	  This topic is left for further study.
        </t>

	<!--

      </section>
    </section>

    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <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 anchor="Security" title="Security Considerations">
      <t>
        Any security mechanism at
        Any security mechanism at the IP layer or above that may be
        carried out
        implemented for the general case of IPv6 may also be carried
        out implemented
        for IPv6 operating over 802.11-OCB.
      </t>
      <t>
	The OCB operation does not use existing 802.11
	link-layer security mechanisms.  There is no encryption
	applied below the network layer running on 802.11-OCB.  At
	the application layer, the IEEE 1609.2 document <xref
	target="IEEE-1609.2"/> target="IEEE-1609.2" format="default"/> provides security services for
	certain applications to use; application-layer mechanisms are
	out of scope of this document.  On another the other hand, a security
	mechanism provided at the networking layer, such as IPsec <xref
	target="RFC4301"/>, target="RFC4301" format="default"/>, may provide data security protection to a
	wider range of applications.
      </t>
      <t>
        802.11-OCB does not provide any cryptographic protection, protection because it operates outside the context of a BSS (no
        Association Request/Response, no Request/Response or Challenge messages).
        Therefore, an attacker can sniff or inject traffic while within
        range of a vehicle or IP-RSU (by setting an interface card's frequency to the proper range).
        Also, an attacker may not heed adhere to the legal limits
        for radio power and can use a very sensitive directional antenna;
        if attackers wishe wish to attack a given exchange exchange, they do not necessarily
        need to be in close physical proximity. Hence, such a link is less protected than
        commonly used links (wired (a wired link or the aforementioned 802.11 links with link-layer security).
      </t>

      <t>
	Therefore,
      <t>Therefore, any node can join a subnet, subnet and directly communicate with any
    nodes on the subset to include subset, including potentially impersonating another node. This
    design allows for a number of threats outlined in Section 3 of <xref target="RFC6959"/>.
    target="RFC6959" sectionFormat="of" section="3"/>.
    While not widely deployed, SeND SEND <xref target="RFC3971"/>, target="RFC3971" format="default"/> <xref target="RFC3972"/> target="RFC3972" format="default"/> is a solution
    that can address Spoof-Based Attack Vectors. spoof-based attack vectors.
      </t>
      <section anchor="Privacy" title="Privacy Considerations"> numbered="true" toc="default">
        <name>Privacy Considerations</name>

        <t>
          As with all Ethernet and 802.11 interface identifiers (<xref
          target='RFC7721'/>), <xref target="RFC7721" format="default"/>, the identifier of an 802.11-OCB
          interface may involve privacy, MAC address spoofing spoofing, and IP
          hijacking risks.  A vehicle embarking an IP-OBU
          whose egress interface is 802.11-OCB may expose itself to
          eavesdropping and subsequent correlation of data. This may
          reveal data considered private by the vehicle owner; there
          is a risk of being tracked.  In outdoors outdoor public
          environments, where vehicles typically circulate, the
          privacy risks are more important greater than in indoors indoor settings.
          It is highly likely that attacker sniffers are deployed
          along routes which that listen for IEEE frames, including IP
          packets, of vehicles passing by.  For this reason, in the 802.11-OCB deployments, there is a strong necessity to use
          protection tools such as dynamically changing MAC addresses
          <xref target="mac-change"/>,
          (<xref target="mac-change" format="default"/>), semantically opaque Interface
          Identifiers
          Identifiers, and stable Interface Identifiers <xref
          target="slaac"/>. (<xref target="slaac"
	  format="default"/>).  An example of a change policy is to change the MAC
          address of the OCB interface each time the system boots up.
          This may help mitigate privacy risks to a
          certain level. Furthermore,  for privacy concerns, (<xref target='RFC8065'/>) <xref target="RFC8065"
	  format="default"/> recommends using an address
          generation address-generation scheme
	  rather than generating addresses generated from a fixed link-layer address.
          However, there are some specificities related to vehicles. Since roaming is an important
          characteristic of moving vehicles, the use of the same Link-Local Address over time
          can indicate the presence of the same vehicle in different places and thus leads lead to location tracking.
          Hence, a vehicle should get hints about a change of environment (e.g. , (e.g., engine running, GPS, etc..) etc.)
          and renew the IID in its LLAs.

        </t>
        <section anchor="privacy-opaque-iid"
		 title="Privacy numbered="true" toc="default">
          <name>Privacy Risks of Meaningful info Information in Interface IDs"> IDs</name>
          <t>
	    The privacy risks of using MAC addresses displayed in
	    Interface Identifiers are important.  The  IPv6 packets can
	    be captured easily in on the Internet and on-link in on public
	    roads.  For this reason, an attacker may realize many
	    attacks on privacy.  One such attack on 802.11-OCB is to
	    capture, store store, and correlate Company company ID information
	    present in the MAC addresses of many a large number of cars (e.g. listen (e.g., listening for
	    Router Advertisements, Advertisements or other IPv6 application data
	    packets, and record recording the value of the source address in
	    these packets).  Further correlation of this information
	    with other data captured by other means, means or other visual
	    information (car color, others) (e.g., car color) may constitute privacy
	    risks.
          </t>
        </section>
      </section>
      <section title="MAC anchor="mac-change" numbered="true" toc="default">
        <name>MAC Address and Interface ID Generation"
	       anchor="mac-change"> Generation</name>
        <t>
	  In 802.11-OCB networks, the MAC addresses may change during
	  well defined
	  well-defined renumbering events.  In  At the moment the MAC
	  address is changed on an 802.11-OCB interface interface, all the
	  Interface Identifiers of IPv6 addresses assigned to that
	  interface MUST <bcp14>MUST</bcp14> change.
        </t>
        <t>
	  Implementations should use a policy dictating when the MAC address is changed on the 802.11-OCB interface.
      For more information on the motivation of this policy policy, please refer to
	  the privacy discussion in <xref
	  target='introduced-by-OCB'/>. target="introduced-by-OCB" format="default"/>.
        </t>
        <t>
	  A 'randomized' MAC address has the following
	  characteristics:
        </t>
        <t>
          <list style="symbols" >
            <t>
              Bit
        <ul spacing="normal">
          <li>
              The "Local/Global" bit is set to "locally administered".
            </t>
            <t>
              Bit
            </li>
          <li>
              The "Unicast/Multicast" bit is set to "Unicast".
            </t>
            <t>
            </li>
          <li>
              The 46 remaining bits are set to a random value, value using a
              random number generator that meets the requirements of
              <xref target="RFC4086" />.
            </t>
          </list>
        </t> format="default"/>.
            </li>
        </ul>
        <t>
          To meet the randomization requirements for the 46 remaining
          bits, a hash function may be used. For example, the <xref target="SHA256"></xref> hash function
	  defined in <xref target="SHA256" format="default"/>
          may be used with the input of a 256 bit 256-bit local secret, the 'nominal'
	  MAC Address address of the interface, and a representation of the date and
	  time of the renumbering event.
        </t>
        <t>
	  A randomized Interface ID has the same characteristics of a
	  randomized MAC address, address except for the length in bits.
        </t>
      </section>
      <section anchor='pseudonym'
	       title= 'Pseudonymization impact anchor="pseudonym" numbered="true" toc="default">
        <name>Pseudonymization Impact on confidentiality Confidentiality and trust'> Trust</name>
        <t>

       Vehicles 'and drivers'
       Vehicle and drivers privacy relies on pseudonymization mechanisms
       such as the ones described in <xref target='mac-change'/>. target="mac-change" format="default"/>.
       This pseudonymization means that upper-layer protocols and applications
       SHOULD NOT
       <bcp14>SHOULD NOT</bcp14> rely on layer-2 or layer-3 addresses to assume that the other participant can be trusted.

        </t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	No request to IANA.
	This document has no IANA actions.
      </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
  </middle>
  <!--  *****BACK MATTER ***** -->
  <back>
<displayreference target="I-D.ietf-mboned-ieee802-mcast-problems" to="IEEE802-MCAST"/>
<displayreference target="I-D.ietf-ipwave-vehicular-networking" to="IPWAVE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1042.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2464.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6059.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7042.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7136.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>

        <reference anchor="IEEE-802.11-2016" target="https://standards.ieee.org/findstds/standard/802.11-2016.html">
          <front>
            <title>
            IEEE Standard for distribution of certificates.
      </t>
      <t>
        Marios Makassikis, Jose Santa Lozano, Albin Severinson Information
            technology - Telecommunications 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 anchor="Acknowledgements"
             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 information exchange
            between systems Local 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 metropolitan area networks--Specific
	    requirements - Part 11: Wireless LAN Medium
            Access Control (MAC) 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>
	Human Rights Protocol Considerations review by Amelia
	Andersdotter.
      </t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1042" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2464" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4191" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4193" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5415" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6059" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6275" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7042" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7136" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7217" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8064" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200" ?>

<!-- [rfced] [IEEE-802.11-2016] This URL is correct --> Physical Layer (PHY)
            Specifications
            </title>
<seriesInfo name="IEEE Standard" value="802.11-2016"/>
            <author>
<organization>IEEE</organization>
</author>
            <date month="December" year="2016"/>
</front>
        </reference>
      </references>

      <references>
        <name>Informative References</name>

        <reference anchor="IEEE-802.11-2016" > anchor="IEEE-802.11-2007" target="https://ieeexplore.ieee.org/document/4248378">
          <front>
            <title>
            IEEE Standard 802.11-2016 - IEEE Standard for Information Technology -
	    Telecommunications and information exchange
            between systems Information Exchange Between Systems -
	    Local and metropolitan area networks Metropolitan Area Networks - Specific requirements Requirements -
	    Part 11: Wireless LAN Medium Access Control (MAC) and Physical
	    Layer (PHY)
            Specifications. Status - Active Standard.  Description
            retrieved freely; the document itself is also freely
            available, but with some difficulty (requires
            registration); description and document retrieved on April
            8th, 2019, starting from URL
            https://standards.ieee.org/findstds/standard/802.11-2016.html Specifications
            </title>
          <author/>
          <date/>
<seriesInfo name="IEEE Standard" value="802.11-2007"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2007.373646"/>
<author><organization>IEEE</organization></author>
            <date month="June" year="2007"/>
          </front>
        </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

        <reference anchor="IEEE-802.11-2012" target="https://ieeexplore.ieee.org/document/6419735">
          <front>
            <title>
            IEEE Standard for download.  Also found https://ieeexplore.ieee.org/document/5514475 DOI: 10.1109/IEEESTD.2010.5514475 --> 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-802.11p-2010" > anchor="IEEE-802.3-2012" target="https://ieeexplore.ieee.org/document/6419735">
          <front>
            <title>
            IEEE Std 802.11p (TM)-2010, Standard for Ethernet
            </title>
<seriesInfo name="IEEE Standard" value="802.3-2012"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6419735"/>
<author><organization>IEEE</organization></author>
            <date month="December" year="2012"/>
          </front>
        </reference>

        <reference anchor="IEEE-802.11p-2010" target="https://standards.ieee.org/standard/802_11p-2010.html">
          <front>
            <title>
            IEEE Standard for Information
            Technology 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. Environments
            </title>
          <author/>
          <date/>
<seriesInfo name="IEEE Standard" value="802.11p-2010"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5514475"/>
<author><organization>IEEE</organization></author>
            <date month="July" year="2010"/>
          </front>
        </reference>

<!-- [rfced] [SHA256] URL below is to version published in 2002. Newer version published in 2015 can be found at https://csrc.nist.gov/publications/detail/fips/180/4/final -->

 <reference anchor="SHA256" > target="https://csrc.nist.gov/publications/detail/fips/180/4/final">
          <front>
          <title>
             Secure
            <title>Secure Hash Standard (SHS), National (SHS)</title>
<seriesInfo name="FIPS" value="180-4" />
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4" />
            <author><organization>National Institute of Standards and Technology.
             https://csrc.nist.gov/CSRC/media/Publications/fips/180/2/archive/2002-08-01/documents/fips180-2.pdf
          </title>
          <author/>
          <date/>
	    Technology</organization></author>

            <date month="August" year="2015"/>
          </front>
        </reference>

<!-- [rfced] [IEEE-1609.2] URL is correct  DOI: 10.1109/IEEESTD.2016.7426684 -->

        <reference anchor="IEEE-1609.2"> anchor="IEEE-1609.2" target="http://ieeexplore.ieee.org/document/7426684">
          <front>
            <title>
	    IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access
	    in Vehicular Environments (WAVE) -- Security Environments--Security Services for
	    Applications and Management Messages.  Example URL
	    http://ieeexplore.ieee.org/document/7426684/ accessed on
	    August 17th, 2017.
          </title>
          <author/>
          <date/>
        </front>
      </reference>

      <!-- <reference anchor="IEEE-1609.3"> -->
      <!--   <front> -->
      <!--     <title> -->
      <!-- 	    IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access -->
      <!-- 	    in Vehicular Environments (WAVE) - Networking Services. -->
      <!-- 	    Example URL http://ieeexplore.ieee.org/document/7458115/ -->
      <!-- 	    accessed on August 17th, 2017. -->
      <!--     </title> -->
      <!--     <author/> -->
      <!--     <date/> -->
      <!--   </front> -->
      <!-- </reference> -->

      <!-- <reference anchor="IEEE-1609.4"> -->
      <!--   <front> -->
      <!--     <title> -->
      <!-- 	    IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access -->
      <!-- 	    in Vehicular Environments (WAVE) - Multi-Channel -->
      <!-- 	    Operation.  Example URL -->
      <!-- 	    http://ieeexplore.ieee.org/document/7435228/ accessed on -->
      <!-- 	    August 17th, 2017. -->
      <!-- Messages
            </title> -->
      <!--     <author/> -->
      <!--     <date/> -->
      <!--
<seriesInfo name="IEEE Standard" value="1609.2-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7426684"/>
<author><organization>IEEE</organization></author>
            <date month="March" year="2016"/>
          </front> -->
      <!--
        </reference> -->

<!-- [rfced] [IEEE-1609.3] URL below is correct  DOI: 10.1109/IEEESTD.2016.7458115 -->

        <reference anchor="IEEE-1609.3"> anchor="IEEE-1609.3" target="http://ieeexplore.ieee.org/document/7458115">
          <front>
            <title>
	    IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access
	    in Vehicular Environments (WAVE) -- Networking Services.
	    Example URL http://ieeexplore.ieee.org/document/7458115/
	    accessed on August 17th, 2017. Services
            </title>
          <author/>
          <date/>
<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>

<!-- [rfced] [IEEE-1609.4] URL below is correct  DOI: 10.1109/IEEESTD.2016.7435228  -->

        <reference anchor="IEEE-1609.4"> anchor="IEEE-1609.4"
		   target="http://ieeexplore.ieee.org/document/7435228">
          <front>
            <title>
	    IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access
	    in Vehicular Environments (WAVE) -- Multi-Channel
	    Operation.  Example URL
	    http://ieeexplore.ieee.org/document/7435228/ accessed on
	    August 17th, 2017.
	    Operation
            </title>
          <author/>
          <date/>
<seriesInfo name="IEEE Standard" value="1609.4-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7435228"/>
            <author><organization>IEEE</organization></author>
            <date month="March" year="2016"/>
          </front>
        </reference>

<!-- [rfced] [ETSI-sec-archi] This URL is correct -->

        <reference anchor="ETSI-sec-archi"> anchor="ETSI-sec-archi" target="http://www.etsi.org/deliver/etsi_ts/102900_102999/102940/01.02.01_60/ts_102940v010201p.pdf">
          <front>
            <title>
	    ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical
	    Specification,
	    Intelligent Transport Systems (ITS);
	    Security; ITS communications security architecture and
	    security management, November 2016.  Downloaded on
	    September 9th, 2017, freely available from ETSI website at
	    URL
	    http://www.etsi.org/deliver/etsi_ts/102900_102999/102940/01.02.01_60/ts_102940v010201p.pdf management
            </title>
<seriesInfo name="ETSI" value="TS 102 940 V1.2.1"/>
            <author/>
          <date/>
            <date month="November" year="2016"/>
          </front>
        </reference>

      <!--

<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"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3753.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3963.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3972.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5889.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6959.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8065.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>

        <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.ietf-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 main 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, such 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 requirements.</t></abstract>

</front>

<seriesInfo name='Work in Progress,' value='draft-ietf-ipwave-vehicular-networking-11' />
</reference>

      <!-- <?rfc -->
      <!--   include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-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.ietf-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' />

<abstract><t>Well-known issues with multicast have prevented the deployment of multicast in 802.11 and other local-area wireless environments.  This document offers guidance on known limitations and problems with wireless multicast.  Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be taken to improve the performace anchor="CFR-90.7"
		   target="https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.90&amp;rgn=div5#se47.5.90_17">
          <front>
            <title>Electronic Code of the network.  Finally, some recommendations are provided about the usage and combination Federal Regulations</title>
            <author><organization>e-CFR</organization></author>
          </front>
<refcontent>Title 47, CFR 90.7 - Definitions</refcontent>
        </reference>

        <reference anchor="CFR-95"
                   target="https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.95&amp;rgn=div5">
          <front>
            <title>Electronic Code of these features and operational choices.</t></abstract> Federal Regulations</title>
            <author><organization>e-CFR</organization></author>
          </front>

<seriesInfo name='Work in Progress,' value='draft-ietf-mboned-ieee802-mcast-problems-08' />
<refcontent>Title 47, CFR 95 - PERSONAL RADIO SERVICES</refcontent>
        </reference>

        <reference anchor="CFR-90"
                   target="https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.90&amp;rgn=div5">
          <front>
            <title>Electronic Code of Federal Regulations</title>
            <author><organization>e-CFR</organization></author>
          </front>
<refcontent>Title 47, Part 90 - PRIVATE LAND MOBILE RADIO SERVICES</refcontent>
        </reference>

      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3753" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3963" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3971" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3972" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5889" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6959" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7721" ?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8065" ?>

       </references>
    </references>
    <section title= "802.11p"
	     anchor='i802.11p'> anchor="i802.11p" numbered="true" toc="default">
      <name>802.11p</name>
      <t>
        The term "802.11p" is an earlier definition.  The behaviour behavior of
        "802.11p" networks is rolled in the document IEEE Std
        802.11-2016. <xref target="IEEE-802.11-2016" format="default"/>.  In that document document, the term 802.11p "802.11p" disappears.
        Instead, each 802.11p feature is conditioned by the IEEE
        Management Information Base (MIB) attribute "OCBActivated"
        <xref target="IEEE-802.11-2016"/>. target="IEEE-802.11-2016" format="default"/>.  Whenever OCBActivated is
        set to true "true", the IEEE Std 802.11-OCB state is activated.  For
        example, an 802.11 STAtion operating outside the context of a
        basic service set
        BSS has the OCBActivated flag set.  Such a
        station, when it has the flag set, uses a BSS identifier equal
        to ff:ff:ff:ff:ff:ff.
      </t>
    </section>
    <section title="Aspects introduced anchor="introduced-by-OCB" numbered="true" toc="default">
      <name>Aspects Introduced by the OCB mode Mode to 802.11"
	     anchor='introduced-by-OCB'> 802.11</name>
      <t>
        In the IEEE 802.11-OCB mode, all nodes in the wireless range
        can directly communicate with each other without involving
        authentication or association procedures.  In OCB mode, the
        manner in which channels are selected and used is simplified
        compared to when in BSS mode.  Contrary to BSS mode, at the link
        layer, it is necessary to set statically set the same channel
        number (or frequency) on two stations that need to communicate
        with each other (in BSS mode mode, this channel set operation is
        performed automatically during 'scanning').  The manner in
        which stations set their channel number in OCB mode is not
        specified in this document.  Stations STA1 and STA2 can
        exchange IP packets only if they are set on to the same channel.
        At the IP layer, they then discover each other by using the IPv6
        Neighbor Discovery protocol.  The allocation of a particular
        channel for a particular use is defined statically in
        standards authored by ETSI (in Europe), in Europe, the FCC in the United States of America, and
        similar organisations organizations in South Korea, Japan Japan, and other parts of
        the world.
      </t>
      <t>
	Briefly, the IEEE 802.11-OCB mode has the following
	properties:

        <list style="symbols">
          <t>

      </t>
      <ul spacing="normal">
        <li>
            The use by each node of a 'wildcard' BSSID BSS identifier (BSSID) (i.e., each bit
            of the BSSID is set to 1)
          </t>
          <t> 1).
          </li>
        <li> No IEEE 802.11 Beacon beacon frames are transmitted </t>
          <t> transmitted. </li>
        <li> No authentication is required in order to be able to communicate</t>
          <t> communicate.</li>
        <li> No association is needed in order to be able to communicate</t>
          <t> communicate.</li>
        <li> No encryption is provided in order to be able to communicate</t>
          <t> communicate.</li>
        <li> Flag dot11OCBActivated is set to true </t>
        </list> "true". </li>
      </ul>
      <t>

	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
	radio communications communication range.  The eventual conflict(s) are
	resolved by the MAC CDMA function. function resolves any
	eventual conflict(s).
      </t>
      <t>
        The message exchange diagram in <xref target='fig:mess-exch'/> target="fig_mess-exch" format="default"/>
        illustrates a comparison between traditional 802.11 and 802.11
        in OCB mode.  The 'Data' messages can be IP packets such as
        HTTP or others.  Other 802.11 management and control frames
        (non IP)
        (non-IP) may be transmitted, as specified in the 802.11
        standard.  For information, the  The names of these messages as
        currently specified by the 802.11 standard are listed in <xref
        target="OCB-messages"/>. target="OCB-messages" format="default"/>.
      </t>
      <t>
      <figure title='Difference anchor="fig_mess-exch">
        <name>Difference between messages exchanged Messages Exchanged                         on 802.11 (left) (Left) and 802.11-OCB (right)'
                anchor='fig:mess-exch'
                align="center"> (Right)</name>
        <artwork align="center">
            <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   STA                    AP              STA1                   STA2
   |                      |               |                      |
   |<------ Beacon -------|               |<------ Data -------->|
   |                      |               |                      |
   |---- Probe Req. ----->|               |<------ Data -------->|
   |<--- Probe Res. ------|               |                      |
   |                      |               |<------ Data -------->|
   |---- Auth Req. ------>|               |                      |
   |<--- Auth Res. -------|               |<------ Data -------->|
   |                      |               |                      |
   |---- Asso Req. ------>|               |<------ Data -------->|
   |<--- Asso Res. -------|               |                      |
   |                      |               |<------ Data -------->|
   |<------ Data -------->|               |                      |
   |<------ Data -------->|               |<------ Data -------->|

      (i) 802.11 Infrastructure mode         (ii) 802.11-OCB mode
            ]]>
          </artwork> ]]></artwork>
      </figure>
      </t>

      <t>
	The interface 802.11-OCB interface was specified in IEEE Std 802.11p
	(TM) -2010 <xref target="IEEE-802.11p-2010"/> as an amendment
	to IEEE Std 802.11 (TM) -2007, titled "Amendment target="IEEE-802.11p-2010" format="default"/>, Amendment 6: Wireless
	Access in Vehicular Environments". Environments, as an amendment
	to <xref target="IEEE-802.11-2007"/>.  Since then, this amendment
	has been integrated in IEEE 802.11(TM) -2012 into <xref target="IEEE-802.11-2012"/> and -2016 <xref
	target="IEEE-802.11-2016"/>. target="IEEE-802.11-2016" format="default"/>.
      </t>

      <t>
	In document 802.11-2016, <xref target="IEEE-802.11p-2010" format="default"/>, anything qualified specifically as
	"OCBActivated",
	"OCBActivated" or "outside the context of a basic service"
	that is set to be true, then it is "true" actually referring refers to OCB aspects
	introduced to 802.11.
      </t>
      <t>
        In order to delineate the aspects introduced by 802.11-OCB to
        802.11, we refer to the earlier <xref
        target="IEEE-802.11p-2010"/>. target="IEEE-802.11p-2010" format="default"/>.  The amendment is concerned with
        vehicular communications, where the wireless link is similar
        to that of Wireless LAN (using a PHY layer specified by
        802.11a/b/g/n),
        802.11a/b/g/n) but which needs to cope with the high mobility
        factor inherent in scenarios of communications between moving
        vehicles,
        vehicles and between vehicles and fixed infrastructure
        deployed along roads.  While 'p' is a letter identifying the
        Amendment, just like 'a, b, g' 'a', 'b', 'g', and 'n' are, 'p' is concerned
        more with MAC modifications, modifications and a little is slightly concerned with PHY
        modifications; the others are mainly about PHY modifications.
        It is possible in practice to combine a 'p' MAC with an 'a'
        PHY by operating outside the context of a BSS with OFDM Orthogonal
	Frequency Division
      Multiplexing (OFDM) at
        5.4GHz
        5.4 GHz and 5.9GHz. 5.9 GHz.
      </t>
      <t>
        The 802.11-OCB links are specified to be compatible as much compatible as
        possible with the behaviour behavior of 802.11a/b/g/n and future
        generation IEEE WLAN links.  From the IP perspective, an
        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
        may be received by one or multiple IP-RSUs.  The link-layer
        resolution is performed by using the IPv6 Neighbor Discovery
        protocol.
      </t>
      <t>
        To support this similarity statement (IPv6 is layered on top
        of LLC on top of 802.11-OCB, 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.3 (for Ethernet)) Ethernet)), it is
        useful to analyze the differences between the 802.11-OCB and
        802.11 specifications.  During this analysis, we note that
        whereas 802.11-OCB lists relatively complex and numerous
        changes to the MAC layer (and very little few to the PHY layer),
        there are only a few characteristics which that may be important
        for an implementation transmitting IPv6 packets on 802.11-OCB
        links.
      </t>

      <t>
        The most important 802.11-OCB point which aspect that influences the IPv6
        functioning is the OCB characteristic; an additional, less
        direct influence, influence is the maximum bandwidth afforded by the PHY
        modulation/demodulation methods and channel access specified
        by 802.11-OCB.  The maximum bandwidth theoretically possible
        in 802.11-OCB is 54 Mbit/s (when using, for example, the
        following parameters: a 20 MHz channel; modulation of 64-QAM;
        a coding rate R is 3/4); in practice of IP-over-802.11-OCB 3/4). With regard to IP over 802.11-OCB, in
	practice, a commonly observed figure is 12Mbit/s; 12 Mbit/s; this bandwidth allows
        the operation of a wide range of protocols relying on IPv6.
      </t>

      <t>
        <list style='symbols'>
          <t>
      <ul spacing="normal">
        <li>
            Operation Outside outside the Context context of a BSS (OCB): the (earlier
            802.11p) The 802.11-OCB links
	    (previously 802.11p) are operated without a Basic
            Service Set (BSS). BSS.  This means that the frames IEEE 802.11
            Beacon,
            beacon, Association Request/Response, Authentication
            Request/Response, and similar, similar frames are not used. The used
            identifier of BSS (BSSID) always has a hexadecimal value always of
            0xffffffffffff (48 '1' bits, represented as MAC address
            ff:ff:ff:ff:ff:ff, or otherwise
            ff:ff:ff:ff:ff:ff; otherwise, the 'wildcard' BSSID), as
            opposed to an arbitrary BSSID value set by an administrator
            (e.g.
            (e.g., 'My-Home-AccessPoint').  The OCB operation - namely -- namely,
            the lack of beacon-based scanning and lack of
            authentication - -- should be taken into account when the
            Mobile IPv6 protocol <xref target='RFC6275'/> target="RFC6275" format="default"/> and the
            protocols for IP layer security <xref target='RFC4301'/> target="RFC4301" format="default"/>
            are used.  The way these protocols adapt to OCB is not
            described in this document.
          </t>
          <t>
          </li>

        <li>
            Timing Advertisement: This is a new message defined in
            802.11-OCB, which
            802.11-OCB that does not exist in 802.11a/b/g/n.  This
            message is used by stations to inform other stations about
            the value of time.  It is similar to the time as delivered
            by a GNSS system (Galileo, Global Navigation Satellite System (GNSS) (e.g., Galileo, GPS, ...) etc.) or by a cellular
            system.  This message is optional for implementation.
          </t>
          <t>
          </li>

        <li>
            Frequency range: this This is a characteristic of the PHY
            layer, with layer; it has
	    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
            (ARCEP, ECC/CEPT based on ENs from ETSI, FCC, etc.); as
            part of the regulation process, specific applications are
            associated with specific frequency ranges.
   In the case of 802.11-OCB, the regulator associates a set of frequency
            ranges,
   ranges or slots within a band, band to the use of applications of vehicular communications,
   communications in a band known as "5.9GHz". "5.9 GHz".
            The 5.9GHz 5.9 GHz band is different from the 2.4GHz 2.4 GHz and 5GHz 5 GHz
            bands used by Wireless LAN. However, as with Wireless LAN, the
	    operation of 802.11-OCB in "5.9GHz" 5.9 GHz bands is
            exempt from owning does not require a
	    license in the EU (in US the 5.9GHz US, the 5.9 GHz is a licensed band of
	    spectrum; for the fixed infrastructure an infrastructure, explicit FCC authorization
	    is required; for an on-board
            device device, a 'licensed-by-rule' concept applies:
	    applies, where rule certification conformity is required.) required). Technical
            conditions are different than from those of the bands "2.4GHz" "2.4 GHz"
            or "5GHz". "5 GHz" bands.  The allowed power levels, and implicitly levels and, implicitly, the
            maximum allowed distance between vehicles, vehicles is of 33dBm 33 dBm for
            802.11-OCB (in Europe), Europe) compared to 20 dBm for Wireless
            LAN 802.11a/b/g/n; this leads to a maximum distance of
            approximately 1km, 1 km compared to approximately 50m. 50 m.
            Additionally, specific conditions related to congestion
            avoidance, jamming avoidance, and radar detection are
            imposed on the use of DSRC (in the US) and on the use of
            frequencies for Intelligent Transportation Systems (in
            EU),
            the EU) compared to Wireless LAN (802.11a/b/g/n).
          </t>
          <t>
          </li>
        <li>
            'Half-rate' encoding: as As the frequency range, this
            parameter is related to PHY, PHY and thus has does not have much
            impact on the interface between the IP layer and the
            MAC layer.
          </t>
          <t>
          </li>
        <li>
            In vehicular communications using 802.11-OCB links, there
            are strong privacy requirements with respect to
            addressing.  While the 802.11-OCB standard does not
            specify anything in particular with respect to MAC
            addresses, in these settings settings, there exists is a strong need
            for a dynamic change of these addresses (as opposed to the
            non-vehicular settings - -- real wall protection - -- where
            fixed MAC addresses do not currently pose some privacy
            risks).  This is further described in <xref
            target="Security"/>. target="Security" format="default"/>.  A relevant function is described in
            documents IEEE 1609.3-2016
            <xref target="IEEE-1609.3"/> target="IEEE-1609.3" format="default"/>
            and IEEE 1609.4-2016 <xref target="IEEE-1609.4"/>.
          </t>
        </list>
      </t> target="IEEE-1609.4" format="default"/>.
          </li>
      </ul>
    </section>

    <section title="Changes anchor="software-changes" numbered="true" toc="default">
      <name>Changes Needed on a software driver an 802.11a Software Driver to become a Become an 802.11-OCB driver"
             anchor="software-changes"> Driver</name>
      <t>
        The 802.11p amendment modifies both the 802.11 stack's
        physical and MAC layers layers, but all the induced modifications
        can be quite easily obtained by modifying an existing
        802.11a ad-hoc ad hoc stack.
      </t>
      <t>
        Conditions
        The conditions for a 802.11a hardware to be compliant with 802.11-OCB compliant:
        <list style='symbols'>
          <t> are as
	follows:
      </t>
      <ul spacing="normal">
        <li>
	    The PHY entity shall be an orthogonal frequency division
	    multiplexing (OFDM) OFDM system.  It must support the frequency
	    bands on which the regulator recommends the use of ITS
	    communications,
	    communications -- for example example, using an IEEE 802.11-OCB layer,
	    in France: 5875MHz layer of
	    5875 MHz to 5925MHz.
          </t>
          <t> 5925 MHz in France.
          </li>
        <li>
	    The OFDM system must provide a "half-clocked" operation
	    using 10 MHz channel spacings.
          </t>
          <t>
          </li>

        <li>
            The chip transmit spectrum mask must be compliant to with the
            "Transmit spectrum mask" from the IEEE 802.11p amendment
            (but experimental environments tolerate otherwise).
          </t>
          <t> do not require compliance).
          </li>

        <li>
            The chip should be able to transmit up to 44.8 dBm when
            used by the US government in the United States, States and up to
            33 dBm in Europe; other regional conditions apply.
          </t>
        </list>
      </t>
          </li>
      </ul>
      <t>
        Changes needed on the network stack in OCB mode:
        <list style='symbols'> mode are as follows:
      </t>
      <ul spacing="normal">
        <li>
         <t>
            Physical layer:
            <list style='symbols'>
              <t>
         </t>
          <ul spacing="normal">
            <li>
                Orthogonal frequency-division multiple access
                The chip must use the Orthogonal Frequency Division Multiple
                Access (OFDM) (OFDMA) encoding mode.
              </t>
              <t>
              </li>
            <li>
                The chip must be set in to half-mode rate mode (the
                internal clock frequency is divided by two).
              </t>
              <t>
              </li>
            <li>
                The chip must use dedicated channels and should allow
                the use of higher emission powers.  This may require
                modifications to the local computer file that
                describes regulatory domains rules, rules if used by the
                kernel to enforce local specific restrictions.  Such
                modifications to the local computer file must respect
                the location-specific regulatory rules.
              </t>
            </list>
              </li>
	  </ul></li>
<li><t>
MAC layer:
            <list style='symbols'>
              <t>
</t>
<ul spacing="normal">
            <li>
                All management frames (beacons, join, leave, and
                others) emission and reception must be disabled disabled,
                except for frames of subtype Action and Timing
                Advertisement (defined below).
              </t>
              <t>
              </li>
            <li>
                No encryption key or method must be used.
              </t>
              <t>
              </li>
            <li>
                Packet emission and reception must be performed as in
                ad-hoc mode,
                ad hoc mode using the wildcard BSSID
                (ff:ff:ff:ff:ff:ff).
              </t>
              <t>
              </li>
            <li>
                The functions related to joining a BSS (Association
                Request/Response) and for authentication
                (Authentication Request/Reply, Challenge) are not
                called.
              </t>
              <t>
              </li>
            <li>
                The beacon interval is always set to 0 (zero).
              </t>
              <t>
              </li>
            <li>
                Timing Advertisement frames, defined in the
                amendment, should be supported.  The upper layer
                should be able to trigger such frames emission and to retrieve
		information contained in the received Timing
                Advertisements.
              </t>
            </list>
          </t>
        </list>
      </t>
              </li>
          </ul>
        </li>
      </ul>
    </section>
    <section title='Protocol Layering'
	     anchor='epd'> anchor="epd" numbered="true" toc="default">
      <name>Protocol Layering</name>

      <t>
        A more theoretical and detailed view of layer stacking, stacking and
        interfaces between the IP layer and 802.11-OCB layers, layers is
        illustrated in <xref target='fig:epd'/>. target="fig_epd" format="default"/>.  The IP layer
        operates on top of the EtherType Protocol Discrimination
        (EPD); this Discrimination
        (EPD). This discrimination layer is described in IEEE Std
        802.3-2012; the <xref target="IEEE-802.3-2012"/>. The interface between IPv6 and EPD is the LLC_SAP
        (Link Layer Control Service Access Point).
      </t>

      <t>
      <figure align="center"
		title='EtherType anchor="fig_epd">
        <name>EtherType Protocol Discrimination'
		anchor='fig:epd'> Discrimination</name>
        <artwork align="center">
            <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 IPv6                  |
 +-+-+-+-+-+-{            }+-+-+-+-+-+-+-+
             {   LLC_SAP  }                 802.11-OCB
 +-+-+-+-+-+-{            }+-+-+-+-+-+-+-+  Boundary
 |            EPD          |       |     |
 |                         | MLME  |     |
 +-+-+-{  MAC_SAP   }+-+-+-|  MLME_SAP   |
 |      MAC Sublayer       |       |     |  802.11-OCB
 |     and ch. coord.      |       | SME |  Services
 +-+-+-{   PHY_SAP  }+-+-+-+-+-+-+-|     |
 |                         | PLME  |     |
 |            PHY Layer    |   PLME_SAP  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]>
          </artwork> ]]></artwork>
      </figure>
      </t>
    </section>
    <section title="Design Considerations"
	     anchor="design-considerations"> anchor="design-considerations" numbered="true" toc="default">
      <name>Design Considerations</name>
      <t>
        The networks defined by 802.11-OCB are in many ways similar to
        other networks of the 802.11 family. In theory, the
        transportation of IPv6 over 802.11-OCB could be very similar to
        the operation of IPv6 over other networks of the 802.11
        family.  However, the high mobility, strong link asymmetry asymmetry, and
        very short connection makes the 802.11-OCB link significantly
        different from other 802.11 networks. Also, the automotive
        applications have specific requirements for reliability,
        security
        security, and privacy, which further add to the particularity
        of the 802.11-OCB link.
      </t>
    </section>
    <section title='IEEE anchor="OCB-messages" numbered="true" toc="default">
      <name>IEEE 802.11 Messages Transmitted in OCB mode'
             anchor="OCB-messages"> Mode</name>

      <t>
        For information, at
        At the time of writing, this is the list of
        IEEE 802.11 messages that may be transmitted in OCB mode,
        i.e.
        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,
            if the STA maintains a TSF Timer, subtype Timing
            Advertisement;
          </t>
          <t>
            Advertisement.
          </li>
        <li>
            The STA may send control frames, frames except those of subtype
            PS-Poll, CF-End, and CF-End plus CFAck;
          </t>
          <t> CFAck.
          </li>
        <li>
            The STA MUST <bcp14>MUST</bcp14> send data frames of subtype QoS
            Data.
          </t>
        </list>
      </t>
          </li>
      </ul>
    </section>
    <section title='Examples anchor="example-packets" numbered="true" toc="default">
      <name>Examples of Packet Formats'
             anchor="example-packets"> Formats</name>
      <t>
	This section describes an example of an IPv6 Packet packet captured
	over a an IEEE 802.11-OCB link.
      </t>
      <t>
        By way of example example, we show that there is no modification in the
        headers when transmitted over 802.11-OCB networks - -- they are
        transmitted like any other 802.11 and Ethernet packets.
      </t>
      <t>
        We describe an experiment of for capturing an IPv6 packet on an
        802.11-OCB link.  In the topology depicted in <xref
        target='topo'/>, target="topo" format="default"/>, the packet is an IPv6 Router Advertisement.
        This packet is emitted by a Router router on its 802.11-OCB
        interface.  The packet is captured on the Host, host using a
        network protocol analyzer (e.g. Wireshark); the (e.g., Wireshark). The capture is
        performed in two different modes: direct mode and 'monitor' monitor
        mode.  The topology used during the capture is depicted below.
      </t>
      <t>
	The packet is captured on the Host. host.  The Host host is an IP-OBU
	containing an 802.11 interface in Peripheral Component Interconnect
	(PCI) Express format PCI express (an ITRI Industrial Technology Research Institute
	(ITRI) product).  The kernel runs the ath5k software driver with
	modifications for OCB mode.  The capture tool is Wireshark.
	The file format for save saving and analyze analyzing is 'pcap'. .pcap.  The packet is
	generated by the Router.  The Router router, which is an IP-RSU (ITRI (an ITRI
	product).
      </t>

      <t>
      <figure align="center"
		title='Topology anchor="topo">
        <name>Topology for capturing Capturing IP packets Packets on 802.11-OCB'
		anchor='topo'> 802.11-OCB</name>
        <artwork align="center">
            <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   +--------+                                +-------+
   |        |        802.11-OCB Link         |       |
---| Router |--------------------------------| Host  |
   |        |                                |       |
   +--------+                                +-------+
            ]]>
          </artwork>  ]]></artwork>
      </figure>
      </t>
      <t>
        During several capture operations running from a few moments
        to several hours, no message messages relevant to the BSSID contexts
        were captured (no Association (Association Request/Response, Authentication
        Req/Resp, Beacon). or beacon).  This shows that the operation of
        802.11-OCB is outside the context of a BSSID.
      </t>
      <t>
        Overall, the captured message is identical with to a capture of
        an IPv6 packet emitted on a an 802.11b interface.  The contents
        are precisely similar. exactly the same.
      </t>
      <section title="Capture numbered="true" toc="default">
        <name>Capture in Monitor Mode"> Mode</name>
        <t>
          The IPv6 RA packet captured in monitor mode is illustrated
          below.  The radio tap Radiotap header provides more flexibility for
          reporting the characteristics of frames.  The Radiotap Header header
          is prepended by this particular stack and operating system on
          the Host host machine to the RA packet received from the network
          (the Radiotap Header header is not present on the air).  The
          implementation-dependent Radiotap Header header is useful for
          piggybacking PHY information from the chip's registers as data
          in a packet that is understandable by userland applications using
          Socket
          socket interfaces (the PHY interface can be, for example: example,
          power levels, data rate, or the ratio of signal to noise).
        </t>
        <t>
          The packet present on the air is formed by the IEEE 802.11 Data
          Header,
          header, Logical Link Control Header, header, IPv6 Base Header header, and
          ICMPv6 Header. header.
        </t>
        <t>
      <figure align="center">
            <artwork align="center">
              <![CDATA[

Radiotap anchor="figA">
        <name>Radiotap Header v0 v0</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Revision|  Header Pad   |    Header length Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Present flags Flags                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Rate     |             Pad                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IEEE
]]></artwork>
      </figure>

      <figure anchor="figB">
        <name>IEEE 802.11 Data Header Header</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type/Subtype and Frame Ctrl  |          Duration             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Receiver Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Receiver Address           |      Transmitter Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ... Transmitter Address                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            BSS Id... ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ... BSS Id ID                     |  Frag Number and Seq Number   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Logical-Link
]]></artwork></figure>

      <figure anchor="figC">
        <name>Logical Link Control Header Header</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      DSAP   |I|     SSAP    |C| Control field Field | Org. code... Code...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ... Organizational Code        |             Type              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6
]]></artwork></figure>

      <figure anchor="figD">
        <name>IPv6 Base Header Header</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Router Advertisement
]]></artwork></figure>

      <figure anchor="figE">
        <name>Router Advertisement</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Reachable Time                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Retrans Timer                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
              ]]>
            </artwork>
          </figure>
        </t>  ]]></artwork></figure>
        <t>
          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
          received.
        </t>
        <t>
          The value of the Transmitter address Address in the IEEE 802.11 Data
          Header
          header is set to a 48bit 48-bit value.  The value of the destination
          address is 33:33:00:00:00:1 (all-nodes multicast address).
          The value of the BSS Id ID field is ff:ff:ff:ff:ff:ff, which is
          recognized by the network protocol analyzer as being
          "broadcast".  The Fragment number and sequence Sequence number fields
          are
          together are set to 0x90C6.
        </t>
        <t>
          The value of the Organization Code field in the
          Logical-Link
          Logical Link Control Header header is set to 0x0, recognized as
          "Encapsulated Ethernet".  The value of the Type field is
          0x86DD (hexadecimal 86DD, or otherwise 86DD; otherwise, #86DD), recognized
          as "IPv6".
        </t>
        <t>
          A Router Advertisement is periodically sent by the router to
          multicast group address ff02::1. It is an icmp ICMP packet type
          134. The IPv6 Neighbor Discovery's Router Advertisement
          message contains an 8-bit field reserved for single-bit flags,
          as described in <xref target="RFC4861"/>. target="RFC4861" format="default"/>.
        </t>
        <t>
          The IPv6 header contains the link local link-local address of the router
          (source) configured via the EUI-64 algorithm, and the destination
          address is set to ff02::1.
        </t>

        <t>
          The Ethernet Type field in the logical-link control Logical Link Cntrol header
          is set to 0x86dd 0x86dd, which indicates that the frame transports
          an IPv6 packet. In the IEEE 802.11 data, the destination
          address is 33:33:00:00:00:01 33:33:00:00:00:01, which is the corresponding
          multicast MAC address. The BSS id ID is a broadcast address of
          ff:ff:ff:ff:ff:ff. Due to the short link duration between
          vehicles and the roadside infrastructure, there is no need in IEEE 802.11-OCB
	  to wait for the completion of association
          and authentication procedures before exchanging data. IEEE
          802.11-OCB enabled nodes use the wildcard BSSID (a value of
          all 1s) and may start communicating as soon as they arrive
          on the communication channel.
        </t>
      </section>
      <section title="Capture numbered="true" toc="default">
        <name>Capture in Normal Mode"> Mode</name>
        <t>
          The same IPv6 Router Advertisement packet described above
          (monitor mode) is captured on the Host, host in the Normal mode, normal mode and is
	  depicted below.
        </t>
        <t>
      <figure align="center">
            <artwork align="center">
              <![CDATA[

Ethernet anchor="figF">
        <name>Ethernet II Header Header</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Destination...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Destination                 |           Source...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Source                                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6
]]></artwork></figure>

     <figure anchor="figG">
        <name>IPv6 Base Header Header</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Router Advertisement
]]></artwork></figure>

     <figure anchor="figH">
        <name>Router Advertisement</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Reachable Time                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Retrans Timer                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
              ]]>
            </artwork>
          </figure>
        </t>  ]]></artwork></figure>
        <t>
          One notices that the Radiotap Header, header, the IEEE 802.11 Data
          Header
          header, and the Logical-Link Logical Link Control Headers headers are not present.
          On the other hand, a new header named the Ethernet II Header header is
          present.
        </t>
        <t>
          The Destination and Source addresses in the Ethernet II header
          contain the same values as the fields Receiver Address and
          Transmitter Address fields present in the IEEE 802.11 Data Header header in
          the "monitor" monitor mode capture.
        </t>
        <t>
          The value of the Type field in the Ethernet II header is
          0x86DD (recognized as "IPv6"); this value is the same value as
          the value of the field Type field in the Logical-Link Logical Link Control Header header
          in the "monitor" monitor mode capture.
        </t>
        <t>
          The knowledgeable experimenter will no doubt notice the
          similarity of this Ethernet II Header header with a capture in normal
          mode on a pure Ethernet cable interface.
        </t>
        <t>
          A frame translation is inserted on top of a pure IEEE 802.11
          MAC layer, layer in order to adapt packets, packets before delivering the
          payload data to the applications.  It adapts 802.11 LLC/MAC
          headers to Ethernet II headers.  In further detail,  Specifically, this
          adaptation consists in of the elimination of the Radiotap,
          802.11
          802.11, and LLC headers, headers and in the insertion of the Ethernet
          II header.  In this way, IPv6 runs straight over LLC over
          the 802.11-OCB MAC layer; this is further confirmed by the
          use of the unique Type 0x86DD.
        </t>
      </section>
    </section>
    <section title='Extra Terminology'
	     anchor='extra-terminology'> anchor="extra-terminology" numbered="true" toc="default">
      <name>Extra Terminology</name>
      <t>
	The following terms are defined outside the IETF.  They are
	used to define the main terms in the main terminology
	<xref target='terminology'/>. section (<xref target="terminology" format="default"/>).
      </t>
      <t>
	DSRC

<dl newline="true">
<dt>DSRC (Dedicated Short Range Communication): a term defined
	outside the IETF.  The Communication):</dt> <dd>The US Federal Communications Commission
	(FCC) Dedicated Short Range Communication (DSRC) is defined in
	the Code of Federal Regulations (CFR) 47, Parts 90 <xref
	target="CFR-90"/> and 95. 95 <xref target="CFR-95"/>.
	This Code is referred referenced in the definitions below.  At the time
	of the writing of this Internet Draft, document, the last update of this
	Code was dated October 1st, 2010.
      </t>
      <t>
	DSRCS December 6, 2019.</dd>

<dt>DSRCS (Dedicated Short-Range Communications Services): a term
	defined outside the IETF.  The use of radio Services):</dt><dd>
   Radio techniques are used to transfer data over short distances between
   roadside and mobile units, between mobile units, and between portable and
   mobile units to perform operations related to the improvement of traffic
   flow, traffic safety, and other intelligent transportation service
   applications in a variety of environments. DSRCS systems may also transmit status and
	instructional messages related to the units involve. [Ref. 47
	CFR 90.7 - Definitions]
      </t>
      <t>
	OBU involved. <xref
	target="CFR-90.7"/></dd>

<dt>OBU (On-Board Unit): a term defined outside the IETF.  An Unit):</dt><dd>An
	On-Board Unit is a DSRCS transceiver that is normally mounted
	in or on a vehicle, vehicle or which in some instances may be a portable unit. unit in some instances.  An OBU can be operational while a vehicle or
	person is either mobile or stationary.  The OBUs receive and
	contend for time to transmit on one or more radio frequency
	(RF) channels.  Except where specifically excluded, OBU
	operation is permitted wherever vehicle operation or human
	passage is permitted.  The OBUs mounted in vehicles are
	licensed by rule under part 95 of the respective chapter <xref target="CFR-95"/> and
	communicate with Roadside Units (RSUs) and other OBUs.
	Portable OBUs are also licensed by rule under part 95 of the
	respective chapter. <xref
	target="CFR-95"/>.  OBU operations in the Unlicensed National
	Information Infrastructure (UNII) (U-NII) Bands follow the rules in
	those bands. - [CFR 90.7 - Definitions].
      </t>
      <t>
	RSU (Road-Side Unit): a term defined outside of IETF.  A <xref target="CFR-90.7"/>
      </dd>

<dt>RSU (Roadside Unit):</dt><dd>A
	Roadside Unit is a DSRC transceiver that is mounted along a
	road or pedestrian passageway.  An RSU may also be mounted on
	a vehicle or is may be hand carried, but it may only operate when the
	vehicle or hand- carried hand-carried unit is stationary. Perhaps
        Furthermore, an RSU operating under the respectgive part is restricted to the location where it is licensed
	to operate. However, portable
	or hand-held handheld RSUs are permitted to operate where they do not
	interfere with a site-licensed operation.  A  An RSU broadcasts
	data to OBUs or exchanges data with OBUs in its communications
	zone.  An RSU also provides channel assignments and operating
	instructions to OBUs in its communications zone, zone when
	required. - [CFR 90.7 - Definitions].
      </t> <xref target="CFR-90.7"/>
      </dd>
    </dl>
    </section>
    <section title='Neighbor anchor="nd-wireless" numbered="true" toc="default">
      <name>Neighbor Discovery (ND) Potential Issues in Wireless Links'
	     anchor='nd-wireless'> Links</name>
      <t>
	IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] <xref target="RFC4861"/> <xref target="RFC4862"/> was
	designed for point-to-point and transit links links, such as
	Ethernet, with the expectation of a cheap and reliable support
	for multicast from the lower layer. Section 3.2 of RFC 4861 <xref target="RFC4861"
	section="3.2" sectionFormat="of"/> indicates that the operation on Shared Media shared media and on
	non-broadcast multi-access (NBMA)
	NBMA networks require additional
	support, e.g., for Address Resolution (AR) AR and duplicate
	address detection (DAD), DAD, which depend on multicast. An
	infrastructureless radio network such as OCB shares properties
	with both Shared Media shared media and NBMA networks, networks and then adds its
	own complexity, e.g., from movement and interference that
	allow only transient and non-transitive reachability between
	any set of peers.
      </t>

      <t>
	The uniqueness of an address within a scoped domain is a key
	pillar of IPv6 and is the base basis for unicast IP communication. RFC
	4861 <xref
	target="RFC4861"/> details the DAD method to avoid that prevent an address is from
	being duplicated. For a link local link-local address, the scope is the link,
	whereas for a Globally Reachable address globally reachable address, the scope is much
	larger.  The underlying assumption for DAD to operate
	correctly is that the node that owns an IPv6 address can reach
	any other node within the scope at the time it claims its
	address, which is done by sending a NS Neighbor Solicitation (NS) multicast message, and
	can hear any future claim for that address by another party
	within the scope for the duration of the address ownership.
      </t>

      <t>
   In the case of OCB, there is a potentially a need to define a scope that is
   compatible with DAD, and that DAD. The scope cannot be the set of nodes that a transmitter
   can reach at a particular time, time because that set varies all the time and
   does not meet the DAD requirements for a link local link-local address that could possibly can be
   used anytime, anytime and anywhere. The generic expectation of a reliable
	multicast is not ensured, and the operation of DAD and AR
	(Address Resolution)
	as specified by RFC 4861 <xref target="RFC4861"/> cannot be
	guaranteed.  Moreover, multicast transmissions that rely on
	broadcast are not only unreliable but are also often
	detrimental to unicast traffic (see
	[draft-ietf-mboned-ieee802-mcast-problems]). <xref
	target="I-D.ietf-mboned-ieee802-mcast-problems" format="default"/>).
      </t>
      <t>
	Early experience indicates that it should be possible to
	exchange IPv6 packets over OCB while relying on IPv6 ND alone
	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
	for AR and DAD over OCB should ensure that the addresses that
	it uses are unique by means others other than DAD. It must be noted
	that deriving an IPv6 address from a globally unique MAC
	address has this property but globally unique MAC
	address has this property but may yield privacy issues.
      </t>
      <t>
	<xref target="RFC8505"/> provides a more recent approach to IPv6 ND, in
	particular DAD. <xref target="RFC8505"/> is designed to fit wireless and
	otherwise constrained networks whereby multicast and/or
	continuous access to the medium may not be guaranteed. <xref
	target="RFC8505" sectionFormat="comma" section="5.6"/> ("Link-Local Addresses and Registration")
	indicates that the scope of uniqueness for a link-local
	address is restricted to a pair of nodes that uses it to
	communicate and provides a method to assert the uniqueness
	and resolve the link-layer address using a unicast exchange.
      </t>
      <t>
	<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
	within the associated subnet. A peer host (acting as a 6LN)
	registers an address derived from that prefix and can use it
	for the lifetime of the registration. The prefix is advertised
	as not on-link, which means that the 6LN uses the 6LR to relay
	its packets within the subnet, and participation to the subnet
	is constrained to the time of reachability to the 6LR. Note
	that an RSU that provides internet connectivity <bcp14>MAY</bcp14> announce a
	default router preference <xref target="RFC4191" format="default"/>, whereas a car that does
	not provide that connectivity <bcp14>MUST NOT</bcp14> do so. This operation
	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.
      </t>
      <t>
	Support of <xref target="RFC8505"/> may be implemented on OCB. OCB nodes
	that support <xref target="RFC8505"/> <bcp14>SHOULD</bcp14> support the 6LN operation in order
	to act as a host and may yield privacy issues.
      </t>
      <t>
	RFC 8505 provides a more recent approach to IPv6 ND support the 6LR and 6LBR operations
	in
	particular DAD. RFC 8505 is designed order to fit wireless act as a router and
	otherwise constrained networks whereby multicast and/or
	continuous access in particular to the medium may not own a prefix
	that can be guaranteed. RFC
	8505 Section 5.6 "Link-Local Addresses and Registration"
	indicates used by hosts that the scope of uniqueness are compliant with <xref target="RFC8505"/> for a link local address is restricted
	autoconfiguration and registration.
      </t>
    </section>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        The authors would like to a pair thank <contact fullname="Alexandre Petrescu"/> for
        initiating this work and for being the lead author up to draft version 43 of nodes that use it
	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
	communicate, thank <contact fullname="Mohamed Boucadair"/> for
        proofreading and provides a method suggesting modifications for this document.
      </t>
      <t>

        The authors would like to assert thank <contact fullname="Eric Vyncke"/> for
        reviewing the uniqueness suggesting modifications of this document.
      </t>
      <t>
        The authors would like to thank <contact fullname="Witold Klaudel"/>, <contact 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 Gwynne"/>, <contact fullname="Hans-Joachim Fischer"/>, <contact fullname="Russ
        Housley"/>, <contact fullname="Rex Buddenberg"/>, <contact fullname="Erik 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 fullname="Eric
Gray"/>, and <contact fullname="William Whyte"/>.  Their
        valuable comments clarified particular issues and resolve generally
        helped to improve the link-Layer address using a unicast exchange. document.
      </t>
      <t>
	RFC 8505 also enables a router (acting as a 6LR) to own a
	prefix
        <contact fullname="Pierre Pfister"/>, <contact fullname="Rostislav Lisovy"/>, and act as a registrar (acting as a 6LBR) others wrote 802.11-OCB
        drivers for addresses
	within Linux.
      </t>

      <t>
        For the associated subnet. A peer host (acting as a 6LN)
	registers an address derived from that prefix 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 fullname="Brian
        Haberman"/>, and can use it
	for participants to discussions in network working
        groups.
      </t>

      <t>
        The authors would like to thank the lifetime participants of the registration.
        Birds-of-a-Feather "Intelligent Transportation Systems"
        meetings held at IETF in 2016.
      </t>
      <t>
	The prefix is advertised
	as not onlink, which means that the 6LN uses human rights protocol considerations review was done by <contact fullname="Amelia Andersdotter"/>.
      </t>
<t>The work of <contact fullname="Jong-Hyouk Lee"/> was supported by the 6LR to relay
	its packets within National Research Foundation
of Korea (NRF) grant funded by the subnet, Korea government (MSIT) (NRF-2018R1A4A1025632).</t>

<t>The work of <contact fullname="Jérôme Härri"/> was supported by EURECOM industrial members,
namely BMW Group, IABG, Monaco Telecom, Orange, SAP and participation to Symantec. This RFC
reflects the subnet
	is constrained to view of the time IPWAVE WG and does not necessarily reflect the
official policy or position of reachability 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 IPv6 handovers
        between links running outside the 6LR. Note
	that RSU that provides internet connectivity MAY announce a
	default router preference <xref target='RFC4191'/>, whereas context of a car that does
	not provide that connectivity MUST NOT do so. This operation
	presents similarities with that BSS (802.11-OCB
        links).
      </t>
      <t>
        <contact fullname="Tim Leinmueller"/> contributed the idea of an access point, but at
	Layer-3. This is why RFC 8505 well-suited the use of IPv6 over
        802.11-OCB for wireless in
	general. the distribution of certificates.
      </t>
      <t>
	Support of RFC 8505 may be implemented
        <contact fullname="Marios Makassikis"/>, <contact fullname="Jose Santa Lozano"/>, <contact fullname="Albin Severinson"/>, and
        <contact fullname="Alexey Voronov"/> provided significant feedback on OCB. OCB nodes
	that support RFC 8505 SHOULD support the 6LN operation experience
        of using IP messages over 802.11-OCB in order initial trials.
      </t>
      <t>
        <contact fullname="Michelle Wetterwald"/> contributed extensively to act as a host, and may support the 6LR and 6LBR operations
	in order to act as a router and in particular own a prefix
	that can be used by RFC 8505-compliant hosts for address
	autoconfiguration MTU
        discussion, offered the ETSI ITS perspective, and registration. reviewed
        other parts of the document.
      </t>
    </section>

  </back>

</rfc>