Transmission of IPv4 over IEEE 802.11 in OCB mode
Peloton Technology
1060 La Avenida St.
Mountain View
California
94043
United States
+1 650 395 7356
tony.li@tony.li
Cisco Systems, Inc.7025 Kit Creek Rd.Research Triangle ParkNC27709USA+1 919 392 3266gsalguei@cisco.comlispers.netSan JoseCAUSAfarinacci@gmail.com
Internet
Network Working Group
IPv4 over 802.11p, OCB, IPv4 over 802.11-OCB
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).
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 . IPv4 packets
are encapsulated in a LLC SNAP layer and then the 802.11 MAC layer
before transmission.
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.
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).
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.
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
RFC 2119.
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.
OCB: Outside the Context of a Basic Service Set identifier.
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.
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.
IP packets are transmitted over 802.11-OCB within the
standard LLC encapsulation using the EtherType code 0x0800,
as specified in and .
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:
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.
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
Within the two Frame Control octets, the bits are:
2 bits: Protocol Version
2 bits: Type
4 bits: Subtype
1 bit: To DS
1 bit: From DS
1 bit: More Frag
1 bit: Retry
1 bit: Power Mgmt
1 bit: More Data
1 bit: WEP
1 bit: Order
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.
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.
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.
The result of the adaptation layer transformation is a
typical IP over Ethernet frame:
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 . While the physical
layer and link layer can support slightly larger packets,
a different MTU value would cause frequent fragmentation,
which would be suboptimal.
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.
Address Resolution Protocol (ARP)
is used to determine the MAC address used for an IPv4
address, exactly as is done for Ethernet and Wi-Fi, with
EtherType 0x0806.
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:
Static addressing
DHCP with network assigned addresses
DHCP with private addressing and NAT
Link-local addressing
Multicast addressing for IPv4 is as for Ethernet, as
described in .
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.
This section does not address safety-related applications,
which are done on non-IP communications.
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.
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.
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.
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.
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.
Normally, hosts would be able to maintain transport
connections across renumbering events by making use of
multi-path TCP. 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.
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.
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.
One approach to simply change certificates. To preserve
privacy, a host MUST change its certificate any time it has
a renumbering event.
Other approaches that allow for the private exchange of
certificates are also possible and are an area for future
study.
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.
This document has no IANA actions.
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 from which much of
this text was taken.
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
SpecificationsIEEE
Fragmentation considered harmful
The following diagram shows an IPv4 packet with the IEEE
802.11 Data Header, Logical Link Control Header, IPv4 Header.