<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>


<rfc category="std"
     docName="draft-li-ipv4-over-80211ocb-01"
     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)" -->

  <front>

    <title abbrev="IPv4-over-80211ocb">
      Transmission of IPv4 over IEEE 802.11 in OCB mode
    </title>

    <author initials="T." surname="Li" fullname="Tony Li">
      <organization>Peloton Technology</organization>
      <address>
        <postal>
          <street>
            1060 La Avenida St.
          </street>
          <city>Mountain View</city>
          <region>
            California
          </region>
          <code>
            94043
          </code>
          <country>
            United States
          </country>
        </postal>
        <phone>
          +1 650 395 7356
        </phone>
        <email>
          tony.li@tony.li
        </email>
      </address>
    </author>        

    <author fullname="Gonzalo Salgueiro" initials="G.S." surname="Salgueiro">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>7025 Kit Creek Rd.</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>USA</country>
        </postal>
        <phone>+1 919 392 3266</phone>
        <email>gsalguei@cisco.com</email>
      </address>
    </author>

    <author initials='D' surname="Farinacci" fullname='Dino Farinacci'>
      <organization>lispers.net</organization>
      <address><postal>
        <street></street>
        <city>San Jose</city> <region>CA</region>
        <code></code>
        <country>USA</country>
      </postal>
      <email>farinacci@gmail.com</email></address>
    </author>

    <date/>

    <!-- Meta-data Declarations -->

    <area>Internet</area>

    <workgroup>Network 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>
      IPv4 over 802.11p, OCB, IPv4 over 802.11-OCB
    </keyword>

    <!-- Keywords will be incorporated into HTML output files in a
         meta tag but they have no effect on text or nroff output. If
         you submit your draft to the RFC Editor, the keywords will be
         used for the search engine. -->

    <abstract>
      <t>
        This document describes the transmission of IPv4 packets over
        IEEE 802.11-2012 networks when run Outside the Context of a
        BSS (802.11-OCB, earlier known as 802.11p).
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        This document describes the transmission of IPv4 and ARP
        packets over IEEE 802.11-2012 networks when run Outside the
        Context of a BSS (802.11-OCB, earlier known as 802.11p), as
        documented in <xref target="IEEE802.11-2012"/>. IPv4 packets
        are encapsulated in a LLC SNAP layer and then the 802.11 MAC layer
        before transmission.
      </t>

      <t>
        In the following text we use the term "802.11-OCB" to refer to
        IEEE 802.11-2012 when operated with the "OCBActivated" flag
        set. Previous versions of other documents also referred to
        this as 802.11p.
      </t>

      <t>
        802.11-OCB networks are used frequently in vehicular
        communications and have specific safety related requirements
        that are not discussed here. Nothing in this document should
        be construed to contradict, contravene, or otherwise deter
        compliance with other safety requirements and regulations.
        Specifically, IPv4 is prohibited on the 802.11-OCB 'Control
        Channel' (channel 178 at FCC/IEEE, and 180 at ETSI).
      </t>

      <t>
        This document only describes the encapsulation of IPv4
        packets. Other issues such as addressing, discovery, channel
        selection, and transmission timing are out of scope for this
        document. IPv6 is out of scope for this document.
      </t>

    </section>
    
    <section title="Terminology">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in
        <xref target="RFC2119">RFC 2119</xref>.
      </t>

      <t>
        LLC: The Logical Link Control layer from IEEE 802. Throughout
        this document, this also assumes the Subnetwork Access
        Protocol (SNAP) extension with an EtherType protocol on top of
        SNAP.
      </t>

      <t>
        OCB: Outside the Context of a Basic Service Set identifier.
      </t>

      <t>
        802.11-OCB: IEEE 802.11-2012 text flagged by
        "dot11OCBActivated".  This means: IEEE 802.11e for quality of
        service; 802.11j-2004 for half-clocked operations; and 802.11p
        for operation in the 5.9 GHz band and in mode OCB.
      </t>
    </section>


    <section title="Transmission of IPv4 over 802.11-OCB">

      <t>
        IEEE 802.11-OCB specifies that packets should be framed with
        an LLC header and then one of the various 802.11-OCB
        headers. This document specifies how IPv4 and ARP are encapsulated
        over 802.11-OCB.
      </t>

      <section title="Frame Format">

        <t>
          IP packets are transmitted over 802.11-OCB within the
          standard LLC encapsulation using the EtherType code 0x0800,
          as specified in <xref target='RFC1042'/> and <xref
          target="RFC0894"/>.
        </t>

        <t>
          IPv4 packets can be transmitted as "IEEE 802.11 Data" or
          alternatively as "IEEE 802.11 QoS Data". Thus, formatted
          frames may appear in either of these formats:
        </t>

        <t> 
          <figure align="center">
            <artwork align="center">
              <![CDATA[
   IPv4 packet                        IPv4 packet
   Logical-Link Control               Logical-Link Control
   IEEE 802.11 Data                   IEEE 802.11 QoS Data              ]]>            </artwork>
          </figure>
        </t>
        <t>
          This format is slightly different than standard Ethernet
          framing for IPv4, so implementations SHOULD provide an
          adaptation layer so that the network layer perceives
          traditional Ethernet encapsulation.
        </t>

        <t>
          When transmitting an IPv4 packet, the value of the field
          "Type/Subtype" in the 802.11 Data header is 0x20 (Data,
          Data).  The value of the field "Type/Subtype" in the 802.11
          QoS header is 0x28 (Data, QoS data). The 802.11 data header is
        </t>

        <t> 
          <figure align="center">
            <artwork align="center">
              <![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Frame Control         |          Duration             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Receiver Address...                       
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Receiver Address            |      Transmitter Address...    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Transmitter Address                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            BSS Id...                           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... BSS Id                      |  Frag Number and Seq Number   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            ]]>              </artwork>
          </figure>
        </t>

        <t>
          Within the two Frame Control octets, the bits are:
          <list style='symbols'>

            <t>
              2 bits: Protocol Version
            </t>

            <t>
              2 bits: Type
            </t>

            <t>
              4 bits: Subtype
            </t>

            <t>
              1 bit: To DS
            </t>

            <t>
              1 bit: From DS
            </t>

            <t>
              1 bit: More Frag
            </t>

            <t>
              1 bit: Retry
            </t>

            <t>
              1 bit: Power Mgmt
            </t>

            <t>
              1 bit: More Data
            </t>

            <t>
              1 bit: WEP
            </t>

            <t>
              1 bit: Order
            </t>
          </list>
        </t>

        <section title='Ethernet Adaptation Layer'
                 anchor='aal'>
          <t>
            In general, an adaptation layer is inserted between a MAC
            layer and the Networking layer to transform some
            parameters between the form expected by the IP stack and
            the form provided by the MAC layer. In this case, the goal
            is to transform the LLC encapsulation into traditional
            Ethernet encapsulation. This translated encapsulation is
            not sent over the 802.11-OCB network, but is instead
            presented by the device driver to the operating
            system. This allows 802.11-OCB interfaces to easily take
            advantage of all of the operating system facilities that
            exist for Ethernet already.
          </t>

          <t>
            On packet reception, this layer takes the IEEE 802.11 Data
            Header and the Logical-Link Layer Control Header and
            produces an Ethernet II Header.  At transmission, it
            performs the reverse operation.
          </t>

          <t> 
            <figure align="center">
              <artwork align="center">
                <![CDATA[
   +--------------------+-------------+-------------+---------+
   | 802.11 Data Header | LLC Header  | IPv4 Header | Payload |
   +--------------------+-------------+-------------+---------+
   ^
   |
   802.11-to-Ethernet Adaptation Layer
   |
   v
   +--------------------+-------------+---------+
   | Ethernet II Header | IPv4 Header | Payload |
   +--------------------+-------------+---------+                ]]>              </artwork>
            </figure>
          </t>

          <t>
            The Receiver and Transmitter Address fields in the
            802.11 Data Header contain the same values as the
            Destination and the Source Address fields in the
            Ethernet II Header, respectively.  The value of the Type
            field in the LLC Header is the same as the value of the
            Type field in the Ethernet II Header.  The other fields
            in the Data and LLC Headers are not used by the IPv4
            stack.
          </t>

          <t>
            The result of the adaptation layer transformation is a
            typical IP over Ethernet frame:
          </t>

          <t> 
            <figure align="center">
              <artwork align="center">
                <![CDATA[
   0                   1                 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Destination          |
   +-                             -+
   |            Ethernet           |
   +-                             -+
   |            Address            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Source            |
   +-                             -+
   |            Ethernet           |
   +-                             -+
   |            Address            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IPv4              |
   +-                             -+
   |            header             |
   +-                             -+
   |             and               |
   +-                             -+
   /            payload ...        /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              ]]>              </artwork>
            </figure>
          </t>            
        </section>
      </section>

      <section title="Maximum Transmission Unit (MTU)">
        <t>
          The MTU for IPv4 packets on 802.11-OCB is 1500 octets.
          It is the same value as IP packets on Ethernet links, as
          specified in <xref target="RFC0894"/>. While the physical
          layer and link layer can support slightly larger packets,
          a different MTU value would cause frequent fragmentation,
          which would be suboptimal. <xref target="Fragmentation"/>
        </t>

        <t>
          If a packet is fragmented by the IPv4 network layer before
          transmission on 802.11-OCB, the field "Sequence number" in
          the 802.11 Data header SHOULD increment for each fragment
          and the "Fragment number" field SHOULD remain 0. This is
          recommended because the link layer cannot do IP fragment
          reassembly or aid the final IPv4 recipient in any
          way. Further, the interaction between the network layer and
          the data link layer is a significant blurring of the layer
          boundary.
        </t>
      </section>

      <section title='MAC Address Resolution'>
        <t>
          Address Resolution Protocol (ARP) <xref target="RFC0826"/>
          is used to determine the MAC address used for an IPv4
          address, exactly as is done for Ethernet and Wi-Fi, with
          EtherType 0x0806.
        </t>
      </section>

      <section title='IPv4 Addressing'>

        <t>
          This document does not make a recommendation on the IPv4
          addressing strategy that is used on 802.11-OCB networks. A
          specific network is free to choose the addressing strategy
          that best suits its specific application. Known successful
          IPv4 unicast addressing strategies include, but are not limited to:
        </t>

        <t>
          <list style='symbols'>

            <t>
              Static addressing
            </t>

            <t>
              DHCP with network assigned addresses <xref
              target='RFC2131'/>
            </t>

            <t>
              DHCP with private addressing and NAT <xref
              target='RFC1918'/> <xref target='RFC3022'/>
            </t>

            <t>
              Link-local addressing <xref target='RFC3927'/>
            </t>

          </list>
        </t>

        <t>
          Multicast addressing for IPv4 is as for Ethernet, as
          described in <xref target='RFC1112'/>.
        </t>
        
      </section>

    </section>

    <section anchor="Security" title="Security Considerations">

      <section title="Design Considerations" >
        <t>
          IEEE 802.11-OCB itself does not provide useful security
          guarantees. The link layer does not provide any
          authentication mechanism, leaving hosts just as exposed as
          they would be at a public Wi-Fi hot spot. 
        </t>

        <t>
          This section does not address safety-related applications,
          which are done on non-IP communications. 
        </t>

        <t>
          Because 802.11-OCB is specifically intended for mobile
          applications, privacy is a significant concern. 802.11-OCB
          already attempts to assist with privacy by having a station
          change its MAC address. This raises several issues discussed
          below.
        </t>
      </section>

      
      <section title="Privacy Considerations" anchor="privreq" >

        <t>
          The L2 headers of IEEE 802.11-OCB and L3 headers of IPv4
          are not encrypted, and expose the MAC address and IP
          address of both the the source and destination.
          Adversaries could monitor the L2 or L3 headers, track the
          addresses, and through that track the position of a
          vehicles over time.
        </t>

        <t>
          For hosts that have concerns about privacy, the obvious
          mitigation is to periodically use some form of MAC address
          randomization.  We can assume that there will be
          "renumbering events" causing MAC addresses to change. A
          change of MAC address MUST induce a simultaneous change of
          IPv4 address, to prevent linkage of the old and new MAC
          addresses through continuous use of the same IP Addresses.
        </t>

        <t>
          Unfortunately, the change of an IP address is very likely
          to cause disruption at the transport layer, breaking TCP
          connections at the renumbering event and disrupting any
          outstanding UDP transactions. For this reason, renumbering
          events MUST be coordinated between the transport, network,
          and link layers and MUST only happen when there are no
          active transport connections. For hosts that require a
          long-term continuous uptime, this will be problematic and
          hosts MAY choose to forgo renumbering events and sacrifice
          privacy.
        </t>

        <t>
          MAC address randomization will not prevent tracking if the
          address stays constant for long intervals. Suppose for
          example that a vehicle only renumbers when leaving the
          owner's garage in the morning. It would be trivial to
          observe the "number of the day" at the known garage
          location, and to associate that with the vehicle's identity,
          thereby enabling tracking throughout the day.  If
          renumbering events are too infrequent, they will not protect
          privacy, but if they are too frequent they will disrupt
          service. Careful, detailed communications between an
          implementations layers will be required to produce an
          optimal result.
        </t>

        <t>
          Normally, hosts would be able to maintain transport
          connections across renumbering events by making use of
          multi-path TCP. <xref target="RFC6824"/> With multi-path TCP,
          a host can advertise multiple addresses to its
          correspondents, causing the correspondent to send packets to
          any of the addresses. If any of the addresses stops working,
          traffic continues to flow on the working addresses. However,
          in this situation, advertising multiple addresses would
          defeat the privacy goals.
        </t>

      </section>
      
      <section title="Certificate Considerations" >

        <t>
          Because 802.11-OCB provides no link level security, some
          hosts MAY choose to implement cryptographic techniques to
          provide data privacy and authentication. The common approach
          to that today would be through the use of certificates and
          performing a key-exchange before commencing secure
          communications. 
        </t>

        <t>
          The challenge that this creates is that the key exchange
          needs to be performed prior to the exchange of other key
          information. Simply transmitting constant certificates in
          the clear is not optimal as that would violate the privacy
          requirements.
        </t>

        <t>
          One approach to simply change certificates. To preserve
          privacy, a host MUST change its certificate any time it has
          a renumbering event.
        </t>

        <t>
          Other approaches that allow for the private exchange of
          certificates are also possible and are an area for future
          study.
        </t>

      </section>


      <section title="Other Considerations">

        <t>
          At the IP layer, IPsec can be used to protect unicast
          communications. If no protection is used by the IP layer,
          upper layers should be cryptographically protected. 
        </t>

      </section>    
    </section>    

    <section anchor="IANA" title="IANA Considerations">
      <t>
        This document has no IANA actions.
      </t>
    </section>

    <section anchor="Acknowledgments"
             title="Acknowledgments">
      <t>
        The author would like to thank Alexandre Petrescu, Nabil
        Benamar, Jérôme Härri, Christian Huitema, Jong-Hyouk Lee,
        and Thierry Ernst for their work on <xref
        target='I-D.petrescu-ipv6-over-80211p'/> from which much of
        this text was taken.
      </t>
    </section>

  </middle>

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

    <back>
      <references title="Normative References">

        <?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.0826"

        ?>
        <?rfc
          include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0894"
        ?>

        <?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1042"
        ?>             

        <?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112"
        ?>             

        <?rfc
          include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119"
        ?>

        <?rfc
          include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3927"
        ?>

        <reference anchor="IEEE802.11-2012" >
          <front>
            <title>
              Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
              Specifications</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date day="29" month="March" year="2012"/>
          </front>
          <seriesInfo name="IEEE Standard"
                      value="freely available at http://standards.ieee.org/findstds/standard/802.11-2012.html retrieved on November 17th, 2016"/>
        </reference>

      </references>

      <references title="Informative References">


        <?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918"
        ?>             

        <?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131"
        ?>             

        <?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022"
        ?>             

        <?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6824"
        ?>             

        <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.petrescu-ipv6-over-80211p"?>

        <reference anchor="Fragmentation">
          <front>
            <title>
              Fragmentation considered harmful</title>
            <author initials="C. A."
                    surname="Kent"
                    fullname="Christopher A. Kent"/>
            <author initials="J. C."
                    surname="Mogul"
                    fullname="Jeffrey C. Mogul"/>
            <date month="January" year="1995"/>
          </front>
          <seriesInfo name="ACM SIGCOMM Computer Communication Review"
                      value="Special twenty-fifth anniversary issue. Highlights from 25 years of the Computer Communication Review, Volume 25, Issue 1"/>
        </reference>

      </references>

      <section title="IPv4 Packet in Flight">      

        <t>
          The following diagram shows an IPv4 packet with the IEEE
          802.11 Data Header, Logical Link Control Header, IPv4 Header.
        </t>
        <t> 
          <figure align="center">
            <artwork align="center">
              <![CDATA[
   Radiotap Header v0
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Header Revision|  Header Pad   |    Header length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Present flags                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      |   Data Rate   |    Channel Frequency          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Channel Type               |  SSI Signal   |   Antenna     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Radio Flags                |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   IEEE 802.11 Data Header
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type/Subtype and Frame Ctrl  |          Duration             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Receiver Address...                       
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Receiver Address            |      Destination Address...    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Destination Address                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Transmitter Address...                       
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Transmitter Address            |      Source Address...    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Source Address                                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            BSS Id...                           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... BSS Id                      |  Frag Number and Seq Number   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
   
   Logical-Link Control Header
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      DSAP   |I|     SSAP    |C| Control field | Org. code...   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Organizational Code         |            Type               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    IPv4 Header
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>          </artwork>
          </figure>
        </t>      
      </section>

  </back>
</rfc>
