| Network Working Group | T. Li |
| Internet-Draft | Peloton Technology |
| Intended status: Standards Track | G. Salgueiro |
| Expires: November 27, 2017 | Cisco Systems, Inc. |
| D. Farinacci | |
| lispers.net | |
| May 26, 2017 |
Transmission of IPv4 over IEEE 802.11 in OCB mode
draft-li-ipv4-over-80211ocb-01
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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 27, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [IEEE802.11-2012]. 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 [RFC2119].
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 [RFC1042] and [RFC0894].
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:
IPv4 packet IPv4 packet
Logical-Link Control Logical-Link Control
IEEE 802.11 Data IEEE 802.11 QoS Data
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Within the two Frame Control octets, the bits are:
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.
+--------------------+-------------+-------------+---------+
| 802.11 Data Header | LLC Header | IPv4 Header | Payload |
+--------------------+-------------+-------------+---------+
^
|
802.11-to-Ethernet Adaptation Layer
|
v
+--------------------+-------------+---------+
| Ethernet II Header | IPv4 Header | Payload |
+--------------------+-------------+---------+
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:
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 ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [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. [Fragmentation]
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) [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.
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:
Multicast addressing for IPv4 is as for Ethernet, as described in [RFC1112].
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. [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.
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 [I-D.petrescu-ipv6-over-80211p] from which much of this text was taken.
| [Fragmentation] | Kent, C. and J. Mogul, "Fragmentation considered harmful", ACM SIGCOMM Computer Communication Review Special twenty-fifth anniversary issue. Highlights from 25 years of the Computer Communication Review, Volume 25, Issue 1, January 1995. |
| [I-D.petrescu-ipv6-over-80211p] | Petrescu, A., Benamar, N., Haerri, J., Huitema, C., Lee, J., Ernst, T. and T. Li, "Transmission of IPv6 Packets over IEEE 802.11 Outside the Context of a Basic Service Set (OCB)", Internet-Draft draft-petrescu-ipv6-over-80211p-06, November 2016. |
| [RFC1918] | Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996. |
| [RFC2131] | Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997. |
| [RFC3022] | Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001. |
| [RFC6824] | Ford, A., Raiciu, C., Handley, M. and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013. |
The following diagram shows an IPv4 packet with the IEEE 802.11 Data Header, Logical Link Control Header, IPv4 Header.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+