draft-ietf-ipwave-ipv6-over-80211ocb-00.txt   draft-ietf-ipwave-ipv6-over-80211ocb-01.txt 
Network Working Group A. Petrescu Network Working Group A. Petrescu
Internet-Draft CEA, LIST Internet-Draft CEA, LIST
Intended status: Standards Track N. Benamar Intended status: Standards Track N. Benamar
Expires: June 4, 2017 Moulay Ismail University Expires: August 24, 2017 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
C. Huitema C. Huitema
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
T. Li T. Li
Peloton Technology Peloton Technology
December 1, 2016 February 20, 2017
Transmission of IPv6 Packets over IEEE 802.11 Networks in mode Outside Transmission of IPv6 Packets over IEEE 802.11 Networks in mode Outside
the Context of a Basic Service Set (IPv6-over-80211ocb) the Context of a Basic Service Set (IPv6-over-80211ocb)
draft-ietf-ipwave-ipv6-over-80211ocb-00.txt draft-ietf-ipwave-ipv6-over-80211ocb-01.txt
Abstract Abstract
In order to transmit IPv6 packets on IEEE 802.11 networks run outside In order to transmit IPv6 packets on IEEE 802.11 networks run outside
the context of a basic service set (OCB, earlier "802.11p") there is the context of a basic service set (OCB, earlier "802.11p") there is
a need to define a few parameters such as the recommended Maximum a need to define a few parameters such as the recommended Maximum
Transmission Unit size, the header format preceding the IPv6 header, Transmission Unit size, the header format preceding the IPv6 header,
the Type value within it, and others. This document describes these the Type value within it, and others. This document describes these
parameters for IPv6 and IEEE 802.11 OCB networks; it portrays the parameters for IPv6 and IEEE 802.11 OCB networks; it portrays the
layering of IPv6 on 802.11 OCB similarly to other known 802.11 and layering of IPv6 on 802.11 OCB similarly to other known 802.11 and
skipping to change at page 2, line 12 skipping to change at page 2, line 12
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2017. This Internet-Draft will expire on August 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Communication Scenarios where IEEE 802.11p Links are Used . . 6 3. Communication Scenarios where IEEE 802.11 OCB Links are Used 6
4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 6 4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 6
5. Layering of IPv6 over 802.11p as over Ethernet . . . . . . . 9 5. Layering of IPv6 over 802.11p as over Ethernet . . . . . . . 10
5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 9 5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 10
5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 11 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 11
5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 13 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 13
5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 13 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 13
5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 13 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 13
5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 13 5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 13
5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 14 5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 14
5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 15 5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 15
6. Handovers between OCB links . . . . . . . . . . . . . . . . . 15 6. Example IPv6 Packet captured over a IEEE 802.11p link . . . . 15
7. Example IPv6 Packet captured over a IEEE 802.11p link . . . . 17 6.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 15
7.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 18 6.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 18
7.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Changes Needed on a software driver 802.11a to
Appendix B. Explicit Prohibition of IPv6 on Channels become a 802.11-OCB driver . . . 27
Related to ITS Scenarios using 802.11p Networks Appendix C. Design Considerations . . . . . . . . . . . . . . . 28
- an Analysis . . . . . . . . . . . . . . . . . . . 32 C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 28
B.1. Interpretation of FCC and ETSI documents with C.2. Reliability Requirements . . . . . . . . . . . . . . . . 29
respect to running IP on particular channels . . . . . . 32 C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 29
B.2. Interpretations of Latencies of IP datagrams . . . . . . 33 C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 30
Appendix C. Changes Needed on a software driver 802.11a to Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31
become a 802.11-OCB driver . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix D. Design Considerations . . . . . . . . . . . . . . . 34
D.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 35
D.2. Non IP Communications . . . . . . . . . . . . . . . . . . 35
D.3. Reliability Requirements . . . . . . . . . . . . . . . . 36
D.4. Privacy requirements . . . . . . . . . . . . . . . . . . 37
D.5. Authentication requirements . . . . . . . . . . . . . . . 38
D.6. Multiple interfaces . . . . . . . . . . . . . . . . . . . 38
D.7. MAC Address Generation . . . . . . . . . . . . . . . . . 39
D.8. Security Certificate Generation . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document describes the transmission of IPv6 packets on IEEE Std This document describes the transmission of IPv6 packets on IEEE Std
802.11 OCB networks (earlier known as 802.11p). This involves the 802.11 OCB networks (earlier known as 802.11p). This involves the
layering of IPv6 networking on top of the IEEE 802.11 MAC layer (with layering of IPv6 networking on top of the IEEE 802.11 MAC layer (with
an LLC layer). Compared to running IPv6 over the Ethernet MAC layer, an LLC layer). Compared to running IPv6 over the Ethernet MAC layer,
there is no modification required to the standards: IPv6 works fine there is no modification required to the standards: IPv6 works fine
directly over 802.11 OCB too (with an LLC layer). directly over 802.11 OCB too (with an LLC layer).
skipping to change at page 4, line 5 skipping to change at page 3, line 41
Management Information Base. That flag is named "OCBActivated". Management Information Base. That flag is named "OCBActivated".
Whenever OCBActivated is set to true the feature it relates to Whenever OCBActivated is set to true the feature it relates to
represents an earlier 802.11p feature. For example, an 802.11 represents an earlier 802.11p feature. For example, an 802.11
STAtion operating outside the context of a basic service set has the STAtion operating outside the context of a basic service set has the
OCBActivated flag set. Such a station, when it has the flag set, it OCBActivated flag set. Such a station, when it has the flag set, it
uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. uses a BSS identifier equal to ff:ff:ff:ff:ff:ff.
In the following text we use the term "802.11p" to mean 802.11-2012 In the following text we use the term "802.11p" to mean 802.11-2012
OCB, and vice-versa. OCB, and vice-versa.
As an overview, we illustrate how an IPv6 stack runs over 802.11p by The IPv6 network layer operates on 802.11 OCB in the same manner as
layering different protocols on top of each other. The IPv6 it operates on 802.11 WiFi. The IPv6 network layer operates on WiFi
Networking is layered on top of the IEEE 802.2 Logical-Link Control by involving an Ethernet Adaptation Layer; this Ethernet Adaptation
(LLC) layer; this is itself layered on top of the 802.11p MAC; this Layer converts between 802.11 Headers and Ethernet II headers. The
layering illustration is similar to that of running IPv6 over 802.2 operation of IP on Ethernet is described in [RFC1042] and [RFC2464].
LLC over the 802.11 MAC, or over Ethernet MAC. The situation of IPv6 networking layer on Ethernet Adaptation Layer
is illustrated below:
+-----------------+ +-----------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... | | IPv6 |
+-----------------+ +-----------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Networking | | IPv6 Networking | | Ethernet Adaptation Layer |
+-----------------+ +-----------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.2 LLC | vs. | 802.2 LLC | | 802.11 WiFi MAC |
+-----------------+ +-----------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11p MAC | | 802.11b MAC | | 802.11 WiFi PHY |
+-----------------+ +-----------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11p PHY | | 802.11b PHY |
+-----------------+ +-----------------+
However, there are several deployment considerations to optimize the A more theoretical and detailed view of layer stacking, and
performances of running IPv6 over 802.11p (e.g. in the case of interfaces between the IP layer and 802.11 OCB layers, is illustrated
handovers between 802.11p Access Points, or the consideration of below. The IP layer operates on top of the EtherType Protocol
using the IP security layer). Discrimination (EPD); this Discrimination layer is described in IEEE
Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP
(Link Layer Control Service Accesss Point).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
However, there may be some deployment considerations helping optimize
the performances of running IPv6 over 802.11-OCB (e.g. in the case of
handovers between 802.11 OCB-enabled access routers, or the
consideration of using the IP security layer).
We briefly introduce the vehicular communication scenarios where IEEE We briefly introduce the vehicular communication scenarios where IEEE
802.11-OCB links are used. This is followed by a description of 802.11-OCB links are used. This is followed by a description of
differences in specification terms, between 802.11p and 802.11a/b/g/n differences in specification terms, between 802.11 OCB and
(and the same differences expressed in terms of requirements to 802.11a/b/g/n (and the same differences expressed in terms of
software implementation are listed in Appendix C.) requirements to software implementation are listed in Appendix B.)
The document then concentrates on the parameters of layering IP over The document then concentrates on the parameters of layering IP over
802.11p as over Ethernet: MTU, Frame Format, Interface Identifier, 802.11 OCB as over Ethernet: MTU, Frame Format, Interface Identifier,
Address Mapping, State-less Address Auto-configuration. The values Address Mapping, State-less Address Auto-configuration. The values
of these parameters are precisely the same as IPv6 over Ethernet of these parameters are precisely the same as IPv6 over Ethernet
[RFC2464]: the recommended value of MTU to be 1500 octets, the Frame [RFC2464]: the recommended value of MTU to be 1500 octets, the Frame
Format containing the Type 0x86DD, the rules for forming an Interface Format containing the Type 0x86DD, the rules for forming an Interface
Identifier, the Address Mapping mechanism and the Stateless Address Identifier, the Address Mapping mechanism and the Stateless Address
Auto-Configuration. Auto-Configuration.
As an example, these characteristics of layering IPv6 straight over As an example, these characteristics of layering IPv6 straight over
LLC over 802.11p MAC are illustrated by dissecting an IPv6 packet LLC over 802.11 OCB MAC are illustrated by dissecting an IPv6 packet
captured over a 802.11p link; this is described in the section titled captured over a 802.11 OCB link; this is described in the section
"Example of IPv6 Packet captured over an IEEE 802.11p link". Section 6.
A couple of points can be considered as different, although they are A couple of points can be considered as different, although they are
not required in order to have a working implementation of IPv6-over- not required in order to have a working implementation of IPv6-over-
802.11p. These points are consequences of the OCB operation which is 802.11-OCB. These points are consequences of the OCB operation which
particular to 802.11p (Outside the Context of a BSS). First, the is particular to 802.11 OCB (Outside the Context of a BSS). First,
handovers between OCB links need specific behaviour for IP Router the handovers between OCB links need specific behaviour for IP Router
Advertisements, or otherwise 802.11p's Time Advertisement, or of Advertisements, or otherwise 802.11 OCB's Time Advertisement, or of
higher layer messages such as the 'Basic Safety Message' (in the US) higher layer messages such as the 'Basic Safety Message' (in the US)
or the 'Cooperative Awareness Message' (in the EU) or the 'WAVE or the 'Cooperative Awareness Message' (in the EU) or the 'WAVE
Routing Advertisement'; second, the IP security mechanisms are Routing Advertisement'; second, the IP security mechanisms are
necessary, since OCB means that 802.11p is stripped of all 802.11 necessary, since OCB means that 802.11 is stripped of all 802.11
link-layer security; a small additional security aspect which is link-layer security; a small additional security aspect which is
shared between 802.11p and other 802.11 links is the privacy concerns shared between 802.11 OCB and other 802.11 links is the privacy
related to the address formation mechanisms. The OCB handovers and concerns related to the address formation mechanisms.
security are described each in section Section 6 and Section 8
respectively.
In standards, the operation of IPv6 as a 'data plane' over 802.11p is
specified at IEEE P1609 in [ieeep1609.3-D9-2010]. For example, it
mentions that "Networking services also specifies the use of the
Internet protocol IPv6, and supports transport protocols such as UDP
and TCP. [...] A Networking Services implementation shall support
either IPv6 or WSMP or both." and "IP traffic is sent and received
through the LLC sublayer as specified in [...]". The layered stacks
depicted in the "Architecture" document P1609.0 [ieeep1609.0-D2]
suggest that WSMP messages may not be transmitted as payload of IPv6
datagrams; WSMP and IPv6 are parallel (not stacked) layers.
Also, the operation of IPv6 over a GeoNetworking layer and over G5 is
described in [etsi-302663-v1.2.1p-2013].
In the published literature, three documents describe aspects related In the published literature, many documents describe aspects related
to running IPv6 over 802.11p: [vip-wave], [ipv6-80211p-its] and to running IPv6 over 802.11 OCB:
[ipv6-wave]. [I-D.jeong-ipwave-vehicular-networking-survey].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
RSU: Road Side Unit. RSU: Road Side Unit. An IP router equipped with, or connected to, at
least one interface that is 802.11 and that is an interface that
OCB: Outside the Context of a Basic Service Set identifier. operates in OCB mode.
OCB - Outside the Context of a Basic-Service Set ID (BSSID). OCB: outside the context of a basic service set (BSS): A mode of
operation in which a STA is not a member of a BSS and does not
utilize IEEE Std 802.11 authentication, association, or data
confidentiality.
802.11-OCB - IEEE 802.11-2012 text flagged by "dot11OCBActivated". 802.11-OCB: text in document IEEE 802.11-2012 that is flagged by
This means: IEEE 802.11e for quality of service; 802.11j-2004 for "dot11OCBActivated". This means: IEEE 802.11e for quality of
half-clocked operations; and 802.11p for operation in the 5.9 GHz service; 802.11j-2004 for half-clocked operations; and 802.11p for
band and in mode OCB. operation in the 5.9 GHz band and in mode OCB.
3. Communication Scenarios where IEEE 802.11p Links are Used 3. Communication Scenarios where IEEE 802.11 OCB Links are Used
The IEEE 802.11p Networks are used for vehicular communications, as The IEEE 802.11 OCB Networks are used for vehicular communications,
'Wireless Access in Vehicular Environments'. The IP communication as 'Wireless Access in Vehicular Environments'. The IP communication
scenarios for these environments have been described in several scenarios for these environments have been described in several
documents, among which we refer the reader to one recently updated documents, among which we refer the reader to one recently updated
[I-D.petrescu-its-scenarios-reqs], about scenarios and requirements [I-D.petrescu-its-scenarios-reqs], about scenarios and requirements
for IP in Intelligent Transportation Systems. for IP in Intelligent Transportation Systems.
4. Aspects introduced by the OCB mode to 802.11 4. Aspects introduced by the OCB mode to 802.11
In the IEEE 802.11 OCB mode, all nodes in the wireless range can In the IEEE 802.11 OCB mode, all nodes in the wireless range can
directly communicate with each other without authentication/ directly communicate with each other without authentication/
association procedures. Briefly, the IEEE 802.11 OCB mode has the association procedures. Briefly, the IEEE 802.11 OCB mode has the
following properties: following properties:
o Wildcard BSSID (i.e., all bits are set to 1) used by each node o The use by each node of a 'wildcard' BSSID (i.e., each bit of the
BSSID is set to 1)
o No beacons transmitted o No Beacons transmitted
o No authentication required o No authentication required
o No association needed o No association needed
o No encryption provided o No encryption provided
o dot11OCBActivated OID set to true o Flag dot11OCBActivated set to true
The link 802.11p is specified in IEEE Std 802.11p(TM)-2010 The following message exchange diagram illustrates a comparison
between traditional 802.11 and 802.11 in OCB mode. The 'Data'
messages can be IP messages such as the messages used in Stateless or
Stateful Address Auto-Configuration, or other IP messages. Other
802.11 management and control frames (non IP) may be transmitted, as
specified in the 802.11 standard. For information, the names of
these messages as currently specified by the 802.11 standard are
listed in Appendix D.
STA AP STA1 STA2
| | | |
|<------ Beacon -------| |<------ Data -------->|
| | |<------ Data -------->|
|---- Probe Req. ----->| |<------ Data -------->|
|<--- Probe Res. ------| |<------ Data -------->|
| | |<------ Data -------->|
|---- Auth Req. ------>| |<------ Data -------->|
|<--- Auth Res. -------| |<------ Data -------->|
| | |<------ Data -------->|
|---- Asso Req. ------>| |<------ Data -------->|
|<--- Asso Res. -------| |<------ Data -------->|
| | |<------ Data -------->|
|------- Data -------->| |<------ Data -------->|
|------- Data -------->| |<------ Data -------->|
(a) Traditional IEEE 802.11 (b) IEEE 802.11 OCB mode
The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010
[ieee802.11p-2010] as an amendment to the 802.11 specifications, [ieee802.11p-2010] as an amendment to the 802.11 specifications,
titled "Amendment 6: Wireless Access in Vehicular Environments". titled "Amendment 6: Wireless Access in Vehicular Environments".
Since then, these 802.11p amendments have been included in IEEE Since then, these 802.11p amendments have been included in IEEE
802.11(TM)-2012 [ieee802.11-2012], titled "IEEE Standard for 802.11(TM)-2012 [ieee802.11-2012], titled "IEEE Standard for
Information technology--Telecommunications and information exchange Information technology--Telecommunications and information exchange
between systems Local and metropolitan area networks--Specific between systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control (MAC) and requirements Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications"; the modifications are diffused Physical Layer (PHY) Specifications"; the modifications are diffused
throughout various sections (e.g. 802.11p's Time Advertisement throughout various sections (e.g. 802.11p's Time Advertisement
message is described in section 'Frame formats', and the operation message is described in section 'Frame formats', and the operation
outside the context of a BSS described in section 'MLME'). outside the context of a BSS described in section 'MLME').
In document 802.11-2012, specifically anything referring In document 802.11-2012, specifically anything referring
"OCBActivated", or "outside the context of a basic service set" is "OCBActivated", or "outside the context of a basic service set" is
actually referring to the 802.11p aspects introduced to 802.11. Note actually referring to the 802.11p aspects introduced to 802.11. Note
in earlier 802.11p documents the term "OCBEnabled" was used instead. in earlier 802.11p documents the term "OCBEnabled" was used instead.
In order to delineate the aspects introduced by 802.11p to 802.11, we In order to delineate the aspects introduced by 802.11 OCB to 802.11,
refer to the earlier [ieee802.11p-2010]. The amendment is concerned we refer to the earlier [ieee802.11p-2010]. The amendment is
with vehicular communications, where the wireless link is similar to concerned with vehicular communications, where the wireless link is
that of Wireless LAN (using a PHY layer specified by 802.11a/b/g/n), similar to that of Wireless LAN (using a PHY layer specified by
but which needs to cope with the high mobility factor inherent in 802.11a/b/g/n), but which needs to cope with the high mobility factor
scenarios of communications between moving vehicles, and between inherent in scenarios of communications between moving vehicles, and
vehicles and fixed infrastructure deployed along roads. While 'p' is between vehicles and fixed infrastructure deployed along roads.
a letter just like 'a, b, g' and 'n' are, 'p' is concerned more with While 'p' is a letter just like 'a, b, g' and 'n' are, 'p' is
MAC modifications, and a little with PHY modifications; the others concerned more with MAC modifications, and a little with PHY
are mainly about PHY modifications. It is possible in practice to modifications; the others are mainly about PHY modifications. It is
combine a 'p' MAC with an 'a' PHY by operating outside the context of possible in practice to combine a 'p' MAC with an 'a' PHY by
a BSS with OFDM at 5.4GHz. operating outside the context of a BSS with OFDM at 5.4GHz.
The 802.11p links are specified to be compatible as much as possible The 802.11 OCB links are specified to be compatible as much as
with the behaviour of 802.11a/b/g/n and future generation IEEE WLAN possible with the behaviour of 802.11a/b/g/n and future generation
links. From the IP perspective, an 802.11p MAC layer offers IEEE WLAN links. From the IP perspective, an 802.11 OCB MAC layer
practically the same interface to IP as the WiFi and Ethernet layers offers practically the same interface to IP as the WiFi and Ethernet
do (802.11a/b/g/n and 802.3). layers do (802.11a/b/g/n and 802.3).
To support this similarity statement (IPv6 is layered on top of LLC To support this similarity statement (IPv6 is layered on top of LLC
on top of 802.11p similarly as on top of LLC on top of 802.11a/b/g/n, on top of 802.11 OCB similarly as on top of LLC on top of
and as on top of LLC on top of 802.3) it is useful to analyze the 802.11a/b/g/n, and as on top of LLC on top of 802.3) it is useful to
differences between 802.11p and non-p 802.11 specifications. Whereas analyze the differences between 802.11 OCB and 802.11 specifications.
the 802.11p amendment specifies relatively complex and numerous Whereas the 802.11p amendment specifies relatively complex and
changes to the MAC layer (and very little to the PHY layer), we note numerous changes to the MAC layer (and very little to the PHY layer),
there are only a few characteristics which may be important for an we note there are only a few characteristics which may be important
implementation transmitting IPv6 packets on 802.11p links. for an implementation transmitting IPv6 packets on 802.11 OCB links.
In the list below, the only 802.11p fundamental points which In the list below, the only 802.11 OCB fundamental points which
influence IPv6 are the OCB operation and the 12Mbit/s maximum which influence IPv6 are the OCB operation and the 12Mbit/s maximum which
may be afforded by the IPv6 applications. may be afforded by the IPv6 applications.
o Operation Outside the Context of a BSS (OCB): the 802.11p links o Operation Outside the Context of a BSS (OCB): the 802.11p links
are operated without a Basic Service Set (BSS). This means that are operated without a Basic Service Set (BSS). This means that
the messages Beacon, Association Request/Response, Authentication the messages Beacon, Association Request/Response, Authentication
Request/Response, and similar, are not used. The used identifier Request/Response, and similar, are not used. The used identifier
of BSS (BSSID) has a hexadecimal value always ff:ff:ff:ff:ff:ff of BSS (BSSID) has a hexadecimal value always ff:ff:ff:ff:ff:ff
(48 '1' bits, or the 'wildcard' BSSID), as opposed to an arbitrary (48 '1' bits, or the 'wildcard' BSSID), as opposed to an arbitrary
BSSID value set by administrator (e.g. 'My-Home-AccessPoint'). BSSID value set by administrator (e.g. 'My-Home-AccessPoint').
skipping to change at page 8, line 39 skipping to change at page 9, line 31
"2.4GHz" or "5GHz". On one hand, the allowed power levels, and "2.4GHz" or "5GHz". On one hand, the allowed power levels, and
implicitly the maximum allowed distance between vehicles, is of implicitly the maximum allowed distance between vehicles, is of
33dBm for 802.11p (in Europe), compared to 20 dBm for Wireless LAN 33dBm for 802.11p (in Europe), compared to 20 dBm for Wireless LAN
802.11a/b/g/n; this leads to a maximum distance of approximately 802.11a/b/g/n; this leads to a maximum distance of approximately
1km, compared to approximately 50m. On the hand, specific 1km, compared to approximately 50m. On the hand, specific
conditions related to congestion avoidance, jamming avoidance, and conditions related to congestion avoidance, jamming avoidance, and
radar detection are imposed on the use of DSRC (in US) and on the radar detection are imposed on the use of DSRC (in US) and on the
use of frequencies for Intelligent Transportation Systems (in EU), use of frequencies for Intelligent Transportation Systems (in EU),
compared to Wireless LAN (802.11a/b/g/n). compared to Wireless LAN (802.11a/b/g/n).
o Explicit prohibition of IPv6 on some channels relevant for the PHY o Prohibition of IPv6 on some channels relevant for the PHY of IEEE
of IEEE 802.11p, as opposed to IPv6 not being prohibited on any 802.11-OCB, as opposed to IPv6 not being prohibited on any channel
channel on which 802.11a/b/g/n runs; for example, IPv6 is on which 802.11a/b/g/n runs; at the time of writing, this
prohibited on the 'Control Channel' (number 178 at FCC/IEEE, and prohibition is explicit in IEEE 1609 documents.
180 at ETSI); for a detailed analysis of IEEE and ETSI prohibition
of IP in particular channels see Appendix B.
o 'Half-rate' encoding: as the frequency range, this parameter is o 'Half-rate' encoding: as the frequency range, this parameter is
related to PHY, and thus has not much impact on the interface related to PHY, and thus has not much impact on the interface
between the IP layer and the MAC layer. The standard IEEE 802.11p between the IP layer and the MAC layer.
uses OFDM encoding at PHY, as other non-b 802.11 variants do.
This considers 20MHz encoding to be 'full-rate' encoding, as the
earlier 20MHz encoding which is used extensively by 802.11b. In
addition to the full-rate encoding, the OFDM rates also involve
5MHz and 10MHz. The 10MHz encoding is named 'half-rate'. The
encoding dictates the bandwidth and latency characteristics that
can be afforded by the higher-layer applications of IP
communications. The half-rate means that each symbol takes twice
the time to be transmitted; for this to work, all 802.11 software
timer values are doubled. With this, in certain channels of the
"5.9GHz" band, a maximum bandwidth of 12Mbit/s is possible,
whereas in other "5.9GHz" channels a minimal bandwidth of 1Mbit/s
may be used. It is worth mentioning the half-rate encoding is an
optional feature characteristic of OFDM PHY (compared to 802.11b's
full-rate 20MHz), used by 802.11a before 802.11p used it. In
addition to the half-rate (10MHz) used by 802.11p in some
channels, some other 802.11p channels may use full-rate (20MHz) or
quarter-rate(?) (5MHz) encoding instead.
o It is worth mentioning that more precise interpretations of the
'half-rate' term suggest that a maximum throughput be 27Mbit/s
(which is half of 802.11g's 54Mbit/s), whereas 6Mbit/s or 12Mbit/s
throughputs represent effects of further 802.11p-specific PHY
reductions in the throughput necessary to better accommodate
vehicle-class speeds and distance ranges.
o In vehicular communications using 802.11p links, there are strong o In vehicular communications using 802.11p links, there are strong
privacy concerns with respect to addressing. While the 802.11p privacy concerns with respect to addressing. While the 802.11p
standard does not specify anything in particular with respect to standard does not specify anything in particular with respect to
MAC addresses, in these settings there exists a strong need for MAC addresses, in these settings there exists a strong need for
dynamic change of these addresses (as opposed to the non-vehicular dynamic change of these addresses (as opposed to the non-vehicular
settings - real wall protection - where fixed MAC addresses do not settings - real wall protection - where fixed MAC addresses do not
currently pose some privacy risks). This is further described in currently pose some privacy risks). This is further described in
section Section 8. section Section 7. A relevant function is described in IEEE
1609.3, clause 5.5.1 and IEEE 1609.4, clause 6.7.
Other aspects particular to 802.11p which are also particular to Other aspects particular to 802.11p which are also particular to
802.11 (e.g. the 'hidden node' operation) may have an influence on 802.11 (e.g. the 'hidden node' operation) may have an influence on
the use of transmission of IPv6 packets on 802.11p networks. The the use of transmission of IPv6 packets on 802.11p networks. The
subnet structure which may be assumed in 802.11p networks is strongly subnet structure which may be assumed in 802.11p networks is strongly
influenced by the mobility of vehicles. influenced by the mobility of vehicles.
5. Layering of IPv6 over 802.11p as over Ethernet 5. Layering of IPv6 over 802.11p as over Ethernet
5.1. Maximum Transmission Unit (MTU) 5.1. Maximum Transmission Unit (MTU)
skipping to change at page 11, line 5 skipping to change at page 11, line 5
As with all 802.11 frames, an Ethernet adaptation layer is used with As with all 802.11 frames, an Ethernet adaptation layer is used with
802.11p as well. This Ethernet Adaptation Layer 802.11-to-Ethernet 802.11p as well. This Ethernet Adaptation Layer 802.11-to-Ethernet
is described in Section 5.2.1. The Ethernet Type code (EtherType) is described in Section 5.2.1. The Ethernet Type code (EtherType)
for IPv6 is 0x86DD (hexadecimal 86DD, or otherwise #86DD). for IPv6 is 0x86DD (hexadecimal 86DD, or otherwise #86DD).
The Frame format for transmitting IPv6 on 802.11p networks is the The Frame format for transmitting IPv6 on 802.11p networks is the
same as transmitting IPv6 on Ethernet networks, and is described in same as transmitting IPv6 on Ethernet networks, and is described in
section 3 of [RFC2464]. The frame format for transmitting IPv6 section 3 of [RFC2464]. The frame format for transmitting IPv6
packets over Ethernet is illustrated below: packets over Ethernet is illustrated below:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination | | Destination |
+- -+ +- -+
| Ethernet | | Ethernet |
+- -+ +- -+
| Address | | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source | | Source |
+- -+ +- -+
| Ethernet | | Ethernet |
+- -+ +- -+
| Address | | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 | | IPv6 |
+- -+ +- -+
| header | | header |
+- -+ +- -+
| and | | and |
+- -+ +- -+
/ payload ... / / payload ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Each tic mark represents one bit.) (Each tic mark represents one bit.)
5.2.1. Ethernet Adaptation Layer 5.2.1. Ethernet Adaptation Layer
In general, an 'adaptation' layer is inserted between a MAC layer and In general, an 'adaptation' layer is inserted between a MAC layer and
the Networking layer. This is used to transform some parameters the Networking layer. This is used to transform some parameters
between their form expected by the IP stack and the form provided by between their form expected by the IP stack and the form provided by
the MAC layer. For example, an 802.15.4 adaptation layer may perform the MAC layer. For example, an 802.15.4 adaptation layer may perform
fragmentation and reassembly operations on a MAC whose maximum Packet fragmentation and reassembly operations on a MAC whose maximum Packet
Data Unit size is smaller than the minimum MTU recognized by the IPv6 Data Unit size is smaller than the minimum MTU recognized by the IPv6
Networking layer. Other examples involve link-layer address Networking layer. Other examples involve link-layer address
transformation, packet header insertion/removal, and so on. transformation, packet header insertion/removal, and so on.
An Ethernet Adaptation Layer makes an 802.11 MAC look to IP An Ethernet Adaptation Layer makes an 802.11 MAC look to IP
Networking layer as a more traditional Ethernet layer. At reception, Networking layer as a more traditional Ethernet layer. At reception,
this layer takes as input the IEEE 802.11 Data Header and the this layer takes as input the IEEE 802.11 Data Header and the
Logical-Link Layer Control Header and produces an Ethernet II Header. Logical-Link Layer Control Header and produces an Ethernet II Header.
At sending, the reverse operation is performed. At sending, the reverse operation is performed.
+--------------------+-------------+-------------+---------+ +--------------------+-------------+-------------+---------+
| 802.11 Data Header | LLC Header | IPv6 Header | Payload | | 802.11 Data Header | LLC Header | IPv6 Header | Payload |
+--------------------+-------------+-------------+---------+ +--------------------+-------------+-------------+---------+
^ ^
| |
802.11-to-Ethernet Adaptation Layer 802.11-to-Ethernet Adaptation Layer
| |
v v
+---------------------+-------------+---------+ +---------------------+-------------+---------+
| Ethernet II Header | IPv6 Header | Payload | | Ethernet II Header | IPv6 Header | Payload |
+---------------------+-------------+---------+ +---------------------+-------------+---------+
The Receiver and Transmitter Address fields in the 802.11 Data Header The Receiver and Transmitter Address fields in the 802.11 Data Header
contain the same values as the Destination and the Source Address contain the same values as the Destination and the Source Address
fields in the Ethernet II Header, respectively. The value of the 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 Type field in the LLC Header is the same as the value of the Type
field in the Ethernet II Header. field in the Ethernet II Header.
When the MTU value is smaller than the size of the IP packet to be When the MTU value is smaller than the size of the IP packet to be
sent, the IP layer fragments the packet into multiple IP fragments. sent, the IP layer fragments the packet into multiple IP fragments.
During this operation, the "Sequence number" field of the 802.11 Data During this operation, the "Sequence number" field of the 802.11 Data
Header is increased. Header is increased.
In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11 In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11
Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in
the following figure: the following figure:
+--------------------+-------------+-------------+---------+ +--------------------+-------------+-------------+---------+
| 802.11 Data Header | LLC Header | IPv6 Header | Payload | | 802.11 Data Header | LLC Header | IPv6 Header | Payload |
+--------------------+-------------+-------------+---------+ +--------------------+-------------+-------------+---------+
or or
+--------------------+-------------+-------------+---------+ +--------------------+-------------+-------------+---------+
| 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload | | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |
+--------------------+-------------+-------------+---------+ +--------------------+-------------+-------------+---------+
The distinction between the two formats is given by the value of the The distinction between the two formats is given by the value of the
field "Type/Subtype". The value of the field "Type/Subtype" in the field "Type/Subtype". The value of the field "Type/Subtype" in the
802.11 Data header is 0x0020. The value of the field "Type/Subtype" 802.11 Data header is 0x0020. The value of the field "Type/Subtype"
in the 802.11 QoS header is 0x0028. in the 802.11 QoS header is 0x0028.
The mapping between qos-related fields in the IPv6 header (e.g. The mapping between qos-related fields in the IPv6 header (e.g.
"Traffic Class", "Flow label") and fields in the "802.11 QoS Data "Traffic Class", "Flow label") and fields in the "802.11 QoS Data
Header" (e.g. "QoS Control") are not specified in this document. Header" (e.g. "QoS Control") are not specified in this document.
Guidance for a potential mapping is provided in Guidance for a potential mapping is provided in
skipping to change at page 15, line 11 skipping to change at page 15, line 11
If stable Interface Identifiers are needed in order to form IPv6 If stable Interface Identifiers are needed in order to form IPv6
addresses on 802.11-OCB links, it is recommended to follow the addresses on 802.11-OCB links, it is recommended to follow the
recommendation in [I-D.ietf-6man-default-iids]. recommendation in [I-D.ietf-6man-default-iids].
5.6. Subnet Structure 5.6. Subnet Structure
The 802.11 networks in OCB mode may be considered as 'ad-hoc' The 802.11 networks in OCB mode may be considered as 'ad-hoc'
networks. The addressing model for such networks is described in networks. The addressing model for such networks is described in
[RFC5889]. [RFC5889].
6. Handovers between OCB links 6. Example IPv6 Packet captured over a IEEE 802.11p link
A station operating IEEE 802.11p in the 5.9 GHz band in US or EU is
required to send data frames outside the context of a BSS. In this
case, the station does not utilize the IEEE 802.11 authentication,
association, or data confidentiality services. This avoids the
latency associated with establishing a BSS and is particularly suited
to communications between mobile stations or between a mobile station
and a fixed one playing the role of the default router (e.g. a fixed
Road-Side Unit a.k.a RSU acting as an infrastructure router).
The process of movement detection is described in section 11.5.1 of
[RFC6275]. In the context of 802.11p deployments, detecting
movements between two adjacent RSUs becomes harder for the moving
stations: they cannot rely on Layer-2 triggers (such as L2
association/de-association phases) to detect when they leave the
vicinity of an RSU and move within coverage of another RSU. In such
case, the movement detection algorithms require other triggers. We
detail below the potential other indications that can be used by a
moving station in order to detect handovers between OCB ("Outside the
Context of a BSS") links.
A movement detection mechanism may take advantage of positioning data
(latitude and longitude).
Mobile IPv6 [RFC6275] specifies a new Router Advertisement option
called the "Advertisement Interval Option". It can be used by an RSU
to indicate the maximum interval between two consecutive unsolicited
Router Advertisement messages sent by this RSU. With this option, a
moving station can learn when it is supposed to receive the next RA
from the same RSU. This can help movement detection: if the
specified amount of time elapses without the moving station receiving
any RA from that RSU, this means that the RA has been lost. It is up
to the moving node to determine how many lost RAs from that RSU
constitutes a handover trigger.
In addition to the Mobile IPv6 "Advertisement Interval Option", the
Neighbor Unreachability Detection (NUD) [RFC4861] can be used to
determine whether the RSU is still reachable or not. In this
context, reachability confirmation would basically consist in
receiving a Neighbor Advertisement message from a RSU, in response to
a Neighbor Solicitation message sent by the moving station. The RSU
should also configure a low Reachable Time value in its RA in order
to ensure that a moving station does not assume an RSU to be
reachable for too long.
The Mobile IPv6 "Advertisement Interval Option" as well as the NUD
procedure only help knowing if the RSU is still reachable by the
moving station. It does not provide the moving station with
information about other potential RSUs that might be in range. For
this purpose, it is by increasing the RA frequency that the delay
could be reduced to discover the next RSU. The Neighbor Discovery
protocol [RFC4861] limits the unsolicited multicast RA interval to a
minimum of 3 seconds (the MinRtrAdvInterval variable). This value is
too high for dense deployments of Access Routers deployed along fast
roads. The protocol Mobile IPv6 [RFC6275] allows routers to send
such RA more frequently, with a minimum possible of 0.03 seconds (the
same MinRtrAdvInterval variable): this should be preferred to ensure
a faster detection of the potential RSUs in range.
However, frequent RAs (every 0.03 seconds) may occupy the channel
with too many packets leading to other significant packets being
lost. There is a tradeoff to be established: the more frequent the
RAs the better handover performance but the more risks of packet
loss.
If multiple RSUs are in the vicinity of a moving station at the same
time, the station may not be able to choose the "best" one (i.e. the
one that would afford the moving station spending the longest time in
its vicinity, in order to avoid too frequent handovers). In this
case, it would be helpful to base the decision on the signal quality
(e.g. the RSSI of the received RA provided by the radio driver). A
better signal would probably offer a longer coverage. If, in terms
of RA frequency, it is not possible to adopt the recommendations of
protocol Mobile IPv6 (but only the Neighbor Discovery specification
ones, for whatever reason), then another message than the RA could be
emitted periodically by the Access Router (provided its specification
allows to send it very often), in order to help the Host determine
the signal quality. One such message may be the 802.11p's Time
Advertisement, or higher layer messages such as the "Basic Safety
Message" (in the US) or the "Cooperative Awareness Message " (in the
EU), that are usually sent several times per second. Another
alternative replacement for the IPv6 Router Advertisement may be the
message 'WAVE Routing Advertisement' (WRA), which is part of the WAVE
Service Advertisement and which may contain optionally the
transmitter location; this message is described in section 8.2.5 of
[ieeep1609.3-D9-2010].
Once the choice of the default router has been performed by the
moving node, it can be interesting to use Optimistic DAD [RFC4429] in
order to speed-up the address auto-configuration and ensure the
fastest possible Layer-3 handover.
To summarize, efficient handovers between OCB links can be performed
by using a combination of existing mechanisms. In order to improve
the default router unreachability detection, the RSU and moving
stations should use the Mobile IPv6 "Advertisement Interval Option"
as well as rely on the NUD mechanism. In order to allow the moving
station to detect potential default router faster, the RSU should
also be able to be configured with a smaller minimum RA interval such
as the one recommended by Mobile IPv6. When multiple RSUs are
available at the same time, the moving station should perform the
handover decision based on the signal quality. Finally, optimistic
DAD can be used to reduce the handover delay.
The Received Frame Power Level (RCPI) defined in IEEE Std
802.11-2012, conditioned by the dotOCBActived flag, is an information
element which contains a value expressing the power level at which
that frame was received. This value may be used in comparing power
levels when triggering IP handovers.
7. Example IPv6 Packet captured over a IEEE 802.11p link
We remind that a main goal of this document is to make the case that We remind that a main goal of this document is to make the case that
IPv6 works fine over 802.11p networks. Consequently, this section is IPv6 works fine over 802.11p networks. Consequently, this section is
an illustration of this concept and thus can help the implementer an illustration of this concept and thus can help the implementer
when it comes to running IPv6 over IEEE 802.11p. By way of example when it comes to running IPv6 over IEEE 802.11p. By way of example
we show that there is no modification in the headers when transmitted we show that there is no modification in the headers when transmitted
over 802.11p networks - they are transmitted like any other 802.11 over 802.11p networks - they are transmitted like any other 802.11
and Ethernet packets. and Ethernet packets.
We describe an experiment of capturing an IPv6 packet captured on an We describe an experiment of capturing an IPv6 packet on an 802.11p
802.11p link. In this experiment, the packet is an IPv6 Router link. In this experiment, the packet is an IPv6 Router
Advertisement. This packet is emitted by a Router on its 802.11p Advertisement. This packet is emitted by a Router on its 802.11p
interface. The packet is captured on the Host, using a network interface. The packet is captured on the Host, using a network
protocol analyzer (e.g. Wireshark); the capture is performed in two protocol analyzer (e.g. Wireshark); the capture is performed in two
different modes: direct mode and 'monitor' mode. The topology used different modes: direct mode and 'monitor' mode. The topology used
during the capture is depicted below. during the capture is depicted below.
+--------+ +-------+ +--------+ +-------+
| | 802.11-OCB Link | | | | 802.11-OCB Link | |
---| Router |--------------------------------| Host | ---| Router |--------------------------------| Host |
| | | | | | | |
+--------+ +-------+ +--------+ +-------+
During several capture operations running from a few moments to During several capture operations running from a few moments to
several hours, no message relevant to the BSSID contexts were several hours, no message relevant to the BSSID contexts were
captured (no Association Request/Response, Authentication Req/Resp, captured (no Association Request/Response, Authentication Req/Resp,
Beacon). This shows that the operation of 802.11p is outside the Beacon). This shows that the operation of 802.11p is outside the
context of a BSSID. context of a BSSID.
Overall, the captured message is identical with a capture of an IPv6 Overall, the captured message is identical with a capture of an IPv6
packet emitted on a 802.11b interface. The contents are precisely packet emitted on a 802.11b interface. The contents are precisely
similar. similar.
The popular wireshark network protocol analyzer is a free software 6.1. Capture in Monitor Mode
tool for Windows and Unix. It includes a dissector for 802.11p
features along with all other 802.11 features (i.e. it displays these
features in a human-readable format).
7.1. Capture in Monitor Mode
The IPv6 RA packet captured in monitor mode is illustrated below. The IPv6 RA packet captured in monitor mode is illustrated below.
The radio tap header provides more flexibility for reporting the The radio tap header provides more flexibility for reporting the
characteristics of frames. The Radiotap Header is prepended by this characteristics of frames. The Radiotap Header is prepended by this
particular stack and operating system on the Host machine to the RA particular stack and operating system on the Host machine to the RA
packet received from the network (the Radiotap Header is not present packet received from the network (the Radiotap Header is not present
on the air). The implementation-dependent Radiotap Header is useful on the air). The implementation-dependent Radiotap Header is useful
for piggybacking PHY information from the chip's registers as data in for piggybacking PHY information from the chip's registers as data in
a packet understandable by userland applications using Socket a packet understandable by userland applications using Socket
interfaces (the PHY interface can be, for example: power levels, data interfaces (the PHY interface can be, for example: power levels, data
skipping to change at page 21, line 5 skipping to change at page 18, line 33
the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 the IEEE 802.11 data, the destination address is 33:33:00:00:00:01
which is he corresponding multicast MAC address. The BSS id is a which is he corresponding multicast MAC address. The BSS id is a
broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link
duration between vehicles and the roadside infrastructure, there is duration between vehicles and the roadside infrastructure, there is
no need in IEEE 802.11p to wait for the completion of association and no need in IEEE 802.11p to wait for the completion of association and
authentication procedures before exchanging data. IEEE 802.11p authentication procedures before exchanging data. IEEE 802.11p
enabled nodes use the wildcard BSSID (a value of all 1s) and may enabled nodes use the wildcard BSSID (a value of all 1s) and may
start communicating as soon as they arrive on the communication start communicating as soon as they arrive on the communication
channel. channel.
7.2. Capture in Normal Mode 6.2. Capture in Normal Mode
The same IPv6 Router Advertisement packet described above (monitor The same IPv6 Router Advertisement packet described above (monitor
mode) is captured on the Host, in the Normal mode, and depicted mode) is captured on the Host, in the Normal mode, and depicted
below. below.
Ethernet II Header Ethernet II Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination... | Destination...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Destination | Source... ...Destination | Source...
skipping to change at page 23, line 33 skipping to change at page 20, line 33
It may be interpreted that an Adaptation layer is inserted in a pure It may be interpreted that an Adaptation layer is inserted in a pure
IEEE 802.11 MAC packets in the air, before delivering to the IEEE 802.11 MAC packets in the air, before delivering to the
applications. In detail, this adaptation layer may consist in applications. In detail, this adaptation layer may consist in
elimination of the Radiotap, 802.11 and LLC headers and insertion of elimination of the Radiotap, 802.11 and LLC headers and insertion of
the Ethernet II header. In this way, it can be stated that IPv6 runs the Ethernet II header. In this way, it can be stated that IPv6 runs
naturally straight over LLC over the 802.11p MAC layer, as shown by naturally straight over LLC over the 802.11p MAC layer, as shown by
the use of the Type 0x86DD, and assuming an adaptation layer the use of the Type 0x86DD, and assuming an adaptation layer
(adapting 802.11 LLC/MAC to Ethernet II header). (adapting 802.11 LLC/MAC to Ethernet II header).
8. Security Considerations 7. Security Considerations
Any security mechanism at the IP layer or above that may be carried
out for the general case of IPv6 may also be carried out for IPv6
operating over 802.11-OCB.
802.11p does not provide any cryptographic protection, because it 802.11p does not provide any cryptographic protection, because it
operates outside the context of a BSS (no Association Request/ operates outside the context of a BSS (no Association Request/
Response, no Challenge messages). Any attacker can therefore just Response, no Challenge messages). Any attacker can therefore just
sit in the near range of vehicles, sniff the network (just set the sit in the near range of vehicles, sniff the network (just set the
interface card's frequency to the proper range) and perform attacks interface card's frequency to the proper range) and perform attacks
without needing to physically break any wall. Such a link is way without needing to physically break any wall. Such a link is way
less protected than commonly used links (wired link or protected less protected than commonly used links (wired link or protected
802.11). 802.11).
At the IP layer, IPsec can be used to protect unicast communications, At the IP layer, IPsec can be used to protect unicast communications,
and SeND can be used for multicast communications. If no protection and SeND can be used for multicast communications. If no protection
is used by the IP layer, upper layers should be protected. is used by the IP layer, upper layers should be protected.
Otherwise, the end-user or system should be warned about the risks Otherwise, the end-user or system should be warned about the risks
they run. they run.
The WAVE protocol stack provides for strong security when using the
WAVE Short Message Protocol and the WAVE Service Advertisement
[ieeep1609.2-D17].
As with all Ethernet and 802.11 interface identifiers, there may As with all Ethernet and 802.11 interface identifiers, there may
exist privacy risks in the use of 802.11p interface identifiers. exist privacy risks in the use of 802.11p interface identifiers.
However, in outdoors vehicular settings, the privacy risks are more However, in outdoors vehicular settings, the privacy risks are more
important than in indoors settings. New risks are induced by the important than in indoors settings. New risks are induced by the
possibility of attacker sniffers deployed along routes which listen possibility of attacker sniffers deployed along routes which listen
for IP packets of vehicles passing by. For this reason, in the for IP packets of vehicles passing by. For this reason, in the
802.11p deployments, there is a strong necessity to use protection 802.11p deployments, there is a strong necessity to use protection
tools such as dynamically changing MAC addresses. This may help tools such as dynamically changing MAC addresses. This may help
mitigate privacy risks to a certain level. On another hand, it may mitigate privacy risks to a certain level. On another hand, it may
have an impact in the way typical IPv6 address auto-configuration is have an impact in the way typical IPv6 address auto-configuration is
performed for vehicles (SLAAC would rely on MAC addresses amd would performed for vehicles (SLAAC would rely on MAC addresses amd would
hence dynamically change the affected IP address), in the way the hence dynamically change the affected IP address), in the way the
IPv6 Privacy addresses were used, and other effects. IPv6 Privacy addresses were used, and other effects.
9. IANA Considerations 8. IANA Considerations
10. Contributors 9. Contributors
Romain Kuntz contributed extensively the concepts described in Romain Kuntz contributed extensively about IPv6 handovers between
Section 6 about IPv6 handovers between links running outside the links running outside the context of a BSS (802.11p links).
context of a BSS (802.11p links).
Tim Leinmueller contributed the idea of the use of IPv6 over Tim Leinmueller contributed the idea of the use of IPv6 over
802.11-OCB for distribution of certificates. 802.11-OCB for distribution of certificates.
Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey
Voronov provided significant feedback on the experience of using IP Voronov provided significant feedback on the experience of using IP
messages over 802.11-OCB in initial trials. messages over 802.11-OCB in initial trials.
Michelle Wetterwald contributed extensively the MTU discussion Michelle Wetterwald contributed extensively the MTU discussion
offering the ETSI ITS perspective, as well as other parts of the offering the ETSI ITS perspective, as well as other parts of the
document. document.
11. Acknowledgements 10. Acknowledgements
The authors would like to thank Witold Klaudel, Ryuji Wakikawa, The authors would like to thank Witold Klaudel, Ryuji Wakikawa,
Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan
Romascanu, Konstantin Khait, Ralph Droms, Richard Roy, Ray Hunter, Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray
Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Dino Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,
Farinacci, Vincent Park, Jaehoon Paul Jeong and Gloria Gwynne. Their Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,
valuable comments clarified certain issues and generally helped to Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, and William
improve the document. Whyte. Their valuable comments clarified certain issues and
generally helped to improve the document.
Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB
drivers for linux and described how. drivers for linux and described how.
For the multicast discussion, the authors would like to thank Owen For the multicast discussion, the authors would like to thank Owen
DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and
participants to discussions in network working groups. participants to discussions in network working groups.
The authours would like to thank participants to the Birds-of- The authours would like to thank participants to the Birds-of-
a-Feather "Intelligent Transportation Systems" meetings held at IETF a-Feather "Intelligent Transportation Systems" meetings held at IETF
in 2016. in 2016.
12. References 11. References
12.1. Normative References 11.1. Normative References
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU, Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-16 (work in progress), draft-ietf-6man-default-iids-16 (work in progress),
September 2016. September 2016.
[I-D.ietf-6man-ug] [I-D.ietf-6man-ug]
Carpenter, B. and S. Jiang, "Significance of IPv6 Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", draft-ietf-6man-ug-06 (work in Interface Identifiers", draft-ietf-6man-ug-06 (work in
progress), December 2013. progress), December 2013.
[I-D.ietf-tsvwg-ieee-802-11] [I-D.ietf-tsvwg-ieee-802-11]
Szigeti, T. and F. Baker, "DiffServ to IEEE 802.11 Szigeti, T. and F. Baker, "DiffServ to IEEE 802.11
Mapping", draft-ietf-tsvwg-ieee-802-11-01 (work in Mapping", draft-ietf-tsvwg-ieee-802-11-01 (work in
progress), November 2016. progress), November 2016.
[I-D.jeong-ipwave-vehicular-networking-survey]
Jeong, J., Cespedes, S., Benamar, N., and J. Haerri,
"Survey on IP-based Vehicular Networking for Intelligent
Transportation Systems", draft-jeong-ipwave-vehicular-
networking-survey-00 (work in progress), October 2016.
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission
of IP datagrams over IEEE 802 networks", STD 43, RFC 1042,
DOI 10.17487/RFC1042, February 1988,
<http://www.rfc-editor.org/info/rfc1042>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
skipping to change at page 26, line 33 skipping to change at page 23, line 42
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <http://www.rfc-editor.org/info/rfc6775>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>. <http://www.rfc-editor.org/info/rfc7721>.
12.2. Informative References 11.2. Informative References
[etsi-302663-v1.2.1p-2013] [etsi-302663-v1.2.1p-2013]
"Intelligent Transport Systems (ITS); Access layer "Intelligent Transport Systems (ITS); Access layer
specification for Intelligent Transport Systems operating specification for Intelligent Transport Systems operating
in the 5 GHz frequency band, 2013-07, document in the 5 GHz frequency band, 2013-07, document
en_302663v010201p.pdf, document freely available at URL en_302663v010201p.pdf, document freely available at URL
http://www.etsi.org/deliver/etsi_en/302600_302699/302663/ http://www.etsi.org/deliver/etsi_en/302600_302699/302663/
01.02.01_60/en_302663v010201p.pdf downloaded on October 01.02.01_60/en_302663v010201p.pdf downloaded on October
17th, 2013.". 17th, 2013.".
skipping to change at page 27, line 33 skipping to change at page 24, line 33
October 17th, 2013.". October 17th, 2013.".
[fcc-cc-172-184] [fcc-cc-172-184]
"'Memorandum Opinion and Order, Before the Federal "'Memorandum Opinion and Order, Before the Federal
Communications Commission Washington, D.C. 20554', FCC Communications Commission Washington, D.C. 20554', FCC
06-10, Released on July 26, 2006, document FCC- 06-10, Released on July 26, 2006, document FCC-
06-110A1.pdf, document freely available at URL 06-110A1.pdf, document freely available at URL
http://hraunfoss.fcc.gov/edocs_public/attachmatch/ http://hraunfoss.fcc.gov/edocs_public/attachmatch/
FCC-06-110A1.pdf downloaded on June 5th, 2014.". FCC-06-110A1.pdf downloaded on June 5th, 2014.".
[I-D.baccelli-multi-hop-wireless-communication]
Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless
Communication", draft-baccelli-multi-hop-wireless-
communication-06 (work in progress), July 2011.
[I-D.perkins-intarea-multicast-ieee802] [I-D.perkins-intarea-multicast-ieee802]
Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,
"Multicast Considerations over IEEE 802 Wireless Media", "Multicast Considerations over IEEE 802 Wireless Media",
draft-perkins-intarea-multicast-ieee802-01 (work in draft-perkins-intarea-multicast-ieee802-01 (work in
progress), September 2016. progress), September 2016.
[I-D.petrescu-its-scenarios-reqs] [I-D.petrescu-its-scenarios-reqs]
Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel, Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel,
"Scenarios and Requirements for IP in Intelligent "Scenarios and Requirements for IP in Intelligent
Transportation Systems", draft-petrescu-its-scenarios- Transportation Systems", draft-petrescu-its-scenarios-
skipping to change at page 29, line 21 skipping to change at page 26, line 13
http://ieeexplore.ieee.org/servlet/opac?punumber=5562705". http://ieeexplore.ieee.org/servlet/opac?punumber=5562705".
[ieeep1609.4-D9-2010] [ieeep1609.4-D9-2010]
"IEEE P1609.4(tm)/D9 Draft Standard for Wireless Access in "IEEE P1609.4(tm)/D9 Draft Standard for Wireless Access in
Vehicular Environments (WAVE) - Multi-channel Operation. Vehicular Environments (WAVE) - Multi-channel Operation.
Authorized licensed use limited to: CEA. Downloaded on Authorized licensed use limited to: CEA. Downloaded on
June 19, 2013 at 07:34:48 UTC from IEEE Xplore. June 19, 2013 at 07:34:48 UTC from IEEE Xplore.
Restrictions apply. Document at persistent link Restrictions apply. Document at persistent link
http://ieeexplore.ieee.org/servlet/opac?punumber=5551097". http://ieeexplore.ieee.org/servlet/opac?punumber=5551097".
[ipv6-80211p-its]
Shagdar, O., Tsukada, M., Kakiuchi, M., Toukabri, T., and
T. Ernst, "Experimentation Towards IPv6 over IEEE 802.11p
with ITS Station Architecture", International Workshop on
IPv6-based Vehicular Networks, (colocated with IEEE
Intelligent Vehicles Symposium), URL:
http://hal.inria.fr/hal-00702923/en, Downloaded on: 24
October 2013, Availability: free at some sites, paying at
others, May 2012.
[ipv6-wave]
Clausen, T., Baccelli, E., and R. Wakikawa, "IPv6
Operation for WAVE - Wireless Access in Vehicular
Environments", Rapport de Recherche INRIA, number 7383,
URL: http://hal.inria.fr/inria-00517909/, Downloaded on:
24 October 2013, Availability: free at some sites,
September 2010.
[TS103097] [TS103097]
"Intelligent Transport Systems (ITS); Security; Security "Intelligent Transport Systems (ITS); Security; Security
header and certificate formats; document freely available header and certificate formats; document freely available
at URL http://www.etsi.org/deliver/ at URL http://www.etsi.org/deliver/
etsi_ts/103000_103099/103097/01.01.01_60/ etsi_ts/103000_103099/103097/01.01.01_60/
ts_103097v010101p.pdf retrieved on July 08th, 2016.". ts_103097v010101p.pdf retrieved on July 08th, 2016.".
[vip-wave]
Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
Feasibility of IP Communications in 802.11p Vehicular
Networks", IEEE Transactions on Intelligent Transportation
Systems, Volume 14, Issue 1, URL and Digital Object
Identifier: http://dx.doi.org/10.1109/TITS.2012.2206387,
Downloaded on: 24 October 2013, Availability: free at
some sites, paying at others, March 2013.
Appendix A. ChangeLog Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list. changes appearing at the top of the list.
From draft-petrescu-ipv6-over-80211p-05.txt to draft-petrescu-ipv6- From draft-ietf-ipwave-ipv6-over-80211ocb-00 to draft-ietf-ipwave-
over-80211p-06.txt: ipv6-over-80211ocb-01
o Removed IPv4 text.
o Added text about isues with multicast over 802.11 and OCB mode.
o Shortened the subnet structure section, by referring to an
existing RFC.
o Removed the appendix about distribution of certificates.
o Added text about tradeoff of too frequent RAs, handover
performance and risks of packet loss.
o Removed discussion about other MTU possibilities, kept only the
1500 bytes MTU.
o Keep both header "802.11 Data" and header "802.11 QoS Data".
o Referred to default-iids recommendation of generating stable IIDs.
o Moved the Design Considerations sections to an appendix.
From draft-petrescu-ipv6-over-80211p-02.txt to draft-petrescu-ipv6-
over-80211p-03.txt:
o Added clarification about the "OCBActivated" qualifier in the the
new IEEE 802.11-2012 document; this IEEE document integrates now
all earlier 802.11p features; this also signifies the
dissapearance of an IEEE IEEE 802.11p document altogether.
o Added explanation about FCC not prohibiting IP on channels, and
comments about engineering advice and reliability of IP messages.
o Added possibility to use 6lowpan adaptation layer when in OCB
mode.
o Added appendix about the distribution of certificates to vehicles
by using IPv6-over-802.11p single-hop communications.
o Refined the explanation of 'half-rate' mode.
o Added the privacy concerns and necessity of and potential effects
of dynamically changing MAC addresses.
From draft-petrescu-ipv6-over-80211p-01.txt to draft-petrescu-ipv6-
over-80211p-02.txt:
o updated authorship.
o added explanation about FCC not prohibiting IP on channels, and
comments about engineering advice and reliability of IP messages.
o added possibility to use 6lowpan adaptation layer when in OCB
mode.
o added appendix about the distribution of certificates to vehicles
by using IPv6-over-802.11p single-hop communications.
o refined the explanation of 'half-rate' mode.
o added the privacy concerns and necessity of and potential effects
of dynamically changing MAC addresses.
From draft-petrescu-ipv6-over-80211p-00.txt to draft-petrescu-ipv6-
over-80211p-01.txt:
o updated one author's affiliation detail. o Introduced message exchange diagram illustrating differences
between 802.11 and 802.11 in OCB mode.
o added 2 more references to published literature about IPv6 over o Introduced an appendix listing for information the set of 802.11
802.11p. messages that may be transmitted in OCB mode.
From draft-petrescu-ipv6-over-80211p-00.txt to draft-petrescu-ipv6- o Removed appendix sections "Privacy Requirements", "Authentication
over-80211p-00.txt: Requirements" and "Security Certificate Generation".
o first version. o Removed appendix section "Non IP Communications".
Appendix B. Explicit Prohibition of IPv6 on Channels Related to ITS o Introductory phrase in the Security Considerations section.
Scenarios using 802.11p Networks - an Analysis
B.1. Interpretation of FCC and ETSI documents with respect to running o Improved the definition of "OCB".
IP on particular channels
o The FCC created the term "Control Channel" [fcc-cc]. For it, it o Introduced theoretical stacked layers about IPv6 and IEEE layers
defines the channel number to be 178 decimal, and positions it including EPD.
with a 10MHz width from 5885MHz to 5895MHz. The FCC rules point
to standards document ASTM-E2213 (not freely available at the time
of writing of this draft); in an interpretation of a reviewer of
this document, this means not making any restrictions to the use
of IP on the control channel.
o The FCC created two more terms for particular channels o Removed the appendix describing the details of prohibiting IPv6 on
[fcc-cc-172-184], among others. The channel 172 (5855MHz to certain channels relevant to 802.11-OCB.
5865MHz)) is designated "exclusively for [V2V] safety
communications for accident avoidance and mitigation, and safety
of life and property applications", and the channel 184 (5915MHz
to 5925MHz) is designated "exclusively for high-power, longer-
distance communications to be used for public-safety applications
involving safety of life and property, including road-intersection
collision mitigation". However, they are not named "control"
channels, and the document does not mention any particular
restriction on the use of IP on either of these channels.
o On another hand, at IEEE, IPv6 is explicitely prohibited on o Added a brief reference in the privacy text about a precise clause
channel number 178 decimal - the FCC's 'Control Channel'. The in IEEE 1609.3 and .4.
document [ieeep1609.4-D9-2010] prohibits upfront the use of IPv6
traffic on the Control Channel: 'data frames containing IP
datagrams are only allowed on service channels'. Other 'Service
Channels' are allowed to use IP, but the Control Channel is not.
o In Europe, basically ETSI considers FCC's "Control Channel" to be o Clarified the definition of a Road Side Unit.
a "Service Channel", and defines a "Control Channel" to be in a
slot considered by FCC as a "Service Channel". In detail, FCC's
"Control Channel" number 178 decimal with 10MHz width (5885MHz to
5895MHz) is defined by ETSI to be a "Service Channel", and is
named 'G5-SCH2' [etsi-302663-v1.2.1p-2013]. This channel is
dedicated to 'ITS Road Safety' by ETSI. Other channels are
dedicated to 'ITS road traffic efficiency' by ETSI. The ETSI's
"Control Channel" - the "G5-CCH" - number 180 decimal (not 178) is
reserved as a 10MHz-width centered on 5900MHz (5895MHz to 5905MHz)
(the 5895MHz-5905MHz channel is a Service Channel for FCC).
Compared to IEEE, ETSI makes no upfront statement with respect to
IP and particular channels; yet it relates the 'In car Internet'
applications ('When nearby a stationary public internet access
point (hotspot), application can use standard IP services for
applications.') to the 'Non-safety-related ITS application'
[etsi-draft-102492-2-v1.1.1-2006]. Under an interpretation of an
author of this Internet Draft, this may mean ETSI may forbid IP on
the 'ITS Road Safety' channels, but may allow IP on 'ITS road
traffic efficiency' channels, or on other 5GHz channels re-used
from BRAN (also dedicated to Broadband Radio Access Networks).
o At EU level in ETSI (but not some countries in EU with varying o Removed the discussion about security of WSA (because is non-IP).
adoption levels) the highest power of transmission of 33 dBm is
allowed, but only on two separate 10Mhz-width channels centered on
5900MHz and 5880MHz respectively. It may be that IPv6 is not
allowed on these channels (in the other 'ITS' channels where IP
may be allowed, the levels vary between 20dBm, 23 dBm and 30 dBm;
in some of these channels IP is allowed). A high-power of
transmission means that vehicles may be distanced more
(intuitively, for 33 dBm approximately 2km is possible, and for 20
dBm approximately 50meter).
B.2. Interpretations of Latencies of IP datagrams o Removed mentioning of the GeoNetworking discussion.
IPv6 may be "allowed" on any channel. Certain interpretations o Moved references to scientific articles to a separate 'overview'
consider that communicating IP datagrams may involve longer latencies draft, and referred to it.
than non-IP datagrams; this may make them little adapted for safety
applications which require fast reaction. Certain other views
disagree with this, arguing that IP datagrams are transmitted at the
same speed as any other non-IP datagram and may thus offer same level
of reactivity for safety applications.
Appendix C. Changes Needed on a software driver 802.11a to become a Appendix B. Changes Needed on a software driver 802.11a to become a
802.11-OCB driver 802.11-OCB driver
The 802.11p amendment modifies both the 802.11 stack's physical and The 802.11p amendment modifies both the 802.11 stack's physical and
MAC layers but all the induced modifications can be quite easily MAC layers but all the induced modifications can be quite easily
obtained by modifying an existing 802.11a ad-hoc stack. obtained by modifying an existing 802.11a ad-hoc stack.
Conditions for a 802.11a hardware to be 802.11p compliant: Conditions for a 802.11a hardware to be 802.11p compliant:
o The chip must support the frequency bands on which the regulator o The chip must support the frequency bands on which the regulator
recommends the use of ITS communications, for example using IEEE recommends the use of ITS communications, for example using IEEE
skipping to change at page 34, line 47 skipping to change at page 28, line 25
Response) and for authentication (Authentication Request/Reply, Response) and for authentication (Authentication Request/Reply,
Challenge) are not called. Challenge) are not called.
* The beacon interval is always set to 0 (zero). * The beacon interval is always set to 0 (zero).
* Timing Advertisement frames, defined in the amendment, should * Timing Advertisement frames, defined in the amendment, should
be supported. The upper layer should be able to trigger such be supported. The upper layer should be able to trigger such
frames emission and to retrieve information contained in frames emission and to retrieve information contained in
received Timing Advertisements. received Timing Advertisements.
Appendix D. Design Considerations Appendix C. Design Considerations
The networks defined by 802.11-OCB are in many ways similar to other The networks defined by 802.11-OCB are in many ways similar to other
networks of the 802.11 family. In theory, the encapsulation of IPv6 networks of the 802.11 family. In theory, the encapsulation of IPv6
over 802.11-OCB could be very similar to the operation of IPv6 over 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, other networks of the 802.11 family. However, the high mobility,
strong link asymetry and very short connection makes the 802.11-OCB strong link asymetry and very short connection makes the 802.11-OCB
link significantly different from other 802.11 networks. Also, the link significantly different from other 802.11 networks. Also, the
automotive applications have specific requirements for reliability, automotive applications have specific requirements for reliability,
security and privacy, which further add to the particularity of the security and privacy, which further add to the particularity of the
802.11-OCB link. 802.11-OCB link.
This section does not address safety-related applications, which are C.1. Vehicle ID
done on non-IP communications. However, this section will consider
the transmission of such non IP communication in the design
specification of IPv6 over IEEE 802.11-OCB.
D.1. Vehicle ID
Automotive networks require the unique representation of each of Automotive networks require the unique representation of each of
their node. Accordingly, a vehicle must be identified by at least their node. Accordingly, a vehicle must be identified by at least
one unique ID. The current specification at ETSI and at IEEE 1609 one unique ID. The current specification at ETSI and at IEEE 1609
identifies a vehicle by its MAC address uniquely obtained from the identifies a vehicle by its MAC address uniquely obtained from the
802.11-OCB NIC. 802.11-OCB NIC.
A MAC address uniquely obtained from a IEEE 802.11-OCB NIC A MAC address uniquely obtained from a IEEE 802.11-OCB NIC
implicitely generates multiple vehicle IDs in case of multiple implicitely generates multiple vehicle IDs in case of multiple
802.11-OCB NICs. A mechanims to uniquely identify a vehicle 802.11-OCB NICs. A mechanims to uniquely identify a vehicle
irrespectively to the different NICs and/or technologies is required. irrespectively to the different NICs and/or technologies is required.
D.2. Non IP Communications C.2. Reliability Requirements
In IEEE 1609 and ETSI ITS, safety-related communications CANNOT be
used with IP datagrams. For example, Basic Safety Message (BSM, an
IEEE 1609 datagram) and Cooperative Awareness Message (CAM, an ETSI
ITS-G5 datagram), are each transmitted as a payload that is preceded
by link-layer headers, without an IP header.
Each vehicle taking part of traffic (i.e. having its engine turned on
and being located on a road) MUST use Non IP communication to
periodically broadcast its status information (ID, GPS position,
speed,..) in its immediate neighborhood. Using these mechanisms,
vehicles become 'aware' of the presence of other vehicles in their
immediate vicinity. Therefore, IP communication being transmitted by
vehicles taking part of traffic MUST co-exist with Non IP
communication and SHOULD NOT break any Non IP mechanism, including
'harmful' interference on the channel.
The ID of the vehicle transmitting Non IP communication is
transmitted in the src MAC address of the IEEE 1609 / ETSI-ITS-G5
datagrams. Accordingly, non-IP communications expose the ID of each
vehicle, which may be considered as a privacy breach.
IEEE 802.11-OCB bypasses the authentication mechanisms of IEEE 802.11
networks, in order to transmit non IP communications to without any
delay. This may be considered as a security breach.
IEEE 1609 and ETSI ITS provided strong security and privacy
mechanisms for Non IP Communications. Security (authentication,
encryption) is done by asymetric cryptography, where each vehicle
attaches its public key and its certificate to all of its non IP
messages. Privacy is enforced through the use of Pseudonymes. Each
vehicle will be pre-loaded with a large number (>1000s) of
pseudonymes generated by a PKI, which will uniquely assign a
pseudonyme to a certificate (and thus to a public/private key pair).
Non IP Communication being developped for safety-critical
applications, complex mechanisms have been provided for their
support. These mechanisms are OPTIONAL for IP Communication, but
SHOULD be used whenever possible.
D.3. Reliability Requirements
The dynamically changing topology, short connectivity, mobile The dynamically changing topology, short connectivity, mobile
transmitter and receivers, different antenna heights, and many-to- transmitter and receivers, different antenna heights, and many-to-
many communication types, make IEEE 802.11-OCB links significantly many communication types, make IEEE 802.11-OCB links significantly
different from other IEEE 802.11 links. Any IPv6 mechanism operating different from other IEEE 802.11 links. Any IPv6 mechanism operating
on IEEE 802.11-OCB link MUST support strong link asymetry, spatio- on IEEE 802.11-OCB link MUST support strong link asymetry, spatio-
temporal link quality, fast address resolution and transmission. temporal link quality, fast address resolution and transmission.
IEEE 802.11-OCB strongly differs from other 802.11 systems to operate IEEE 802.11-OCB strongly differs from other 802.11 systems to operate
outside of the context of a Basic Service Set. This means in outside of the context of a Basic Service Set. This means in
skipping to change at page 37, line 12 skipping to change at page 29, line 41
between transmitters and receivers without the support of a NTP between transmitters and receivers without the support of a NTP
server. server.
The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB
MUST disable management mechanisms requesting acknowledgements or MUST disable management mechanisms requesting acknowledgements or
replies. replies.
The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE
802.11-OCB MUST implement fast IPv6 mobility management mechanisms. 802.11-OCB MUST implement fast IPv6 mobility management mechanisms.
D.4. Privacy requirements C.3. Multiple interfaces
Vehicles will move. As each vehicle moves, it needs to regularly
announce its network interface and reconfigure its local and global
view of its network. L2 mechanisms of IEEE 802.11-OCB MAY be
employed to assist IPv6 in discovering new network interfaces. L3
mechanisms over IEEE 802.11-OCB SHOULD be used to assist IPv6 in
discovering new network interfaces.
The headers of the L2 mechanisms of IEEE 802.11-OCB and L3 management
mechanisms of IPv6 are not encrypted, and as such expose at least the
src MAC address of the sender. In the absence of mitigations,
adversaries could monitor the L2 or L3 management headers, track the
MAC Addresses, and through that track the position of vehicles over
time; in some cases, it is possible to deduce the vehicle
manufacturer name from the OUI of the MAC address of the interface
(with help of additional databases). It is important that sniffers
along roads not be able to easily identify private information of
automobiles passing by.
Similary to Non IP safety-critical communications, the obvious
mitigation is to use some form of MAC Address Randomization. We can
assume that there will be "renumbering events" causing the MAC
Addresses to change. Clearly, a change of MAC Address should induce
a simultaneous change of IPv6 Addresses, to prevent linkage of the
old and new MAC Addresses through continuous use of the same IP
Addresses.
The change of an IPv6 address also implies the change of the network
prefix. Prefix delegation mechanisms should be available to vehicles
to obtain new prefixes during "renumbering events".
Changing MAC and IPv6 addresses will disrupt communications, which
goes against the reliability requirements expressed in [TS103097].
We will assume that the renumbering events happen only during "safe"
periods, e.g. when the vehicle has come to a full stop. The
determination of such safe periods is the responsibility of
implementors. In automobile settings it is common to decide that
certain operations (e.g. software update, or map update) must happen
only during safe periods.
MAC Address randomization will not prevent tracking if the addresses
stay constant for long intervals. Suppose for example that a vehicle
only renumbers the addresses of its interface when leaving the
vehicle 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. There is clearly a
tension there. If renumbering events are too infrequent, they will
not protect privacy, but if their are too frequent they will affect
reliability. We expect that implementors will eventually find the
right balance.
D.5. Authentication requirements
IEEE 802.11-OCB does not have L2 authentication mechanisms.
Accordingly, a vehicle receiving a IPv6 over IEEE 802.11-OCB packet
cannot check or be sure the legitimacy of the src MAC (and associated
ID). This is a significant breach of security.
Similarly to Non IP safety-critical communications, IPv6 over
802.11-OCB packets must contain a certificate, including at least the
public key of the sender, that will allow the receiver to
authenticate the packet, and guarantee its legitimacy.
To satisfy the privacy requiremrents of Appendix D.4, the certificate
SHALL be changed at each 'renumbering event'.
D.6. Multiple interfaces
There are considerations for 2 or more IEEE 802.11-OCB interface There are considerations for 2 or more IEEE 802.11-OCB interface
cards per vehicle. For each vehicle taking part in road traffic, one cards per vehicle. For each vehicle taking part in road traffic, one
IEEE 802.11-OCB interface card MUST be fully allocated for Non IP IEEE 802.11-OCB interface card MUST be fully allocated for Non IP
safety-critical communication. Any other IEEE 802.11-OCB may be used safety-critical communication. Any other IEEE 802.11-OCB may be used
for other type of traffic. for other type of traffic.
The mode of operation of these other wireless interfaces is not The mode of operation of these other wireless interfaces is not
clearly defined yet. One possibility is to consider each card as an clearly defined yet. One possibility is to consider each card as an
independent network interface, with a specific MAC Address and a set independent network interface, with a specific MAC Address and a set
of IPv6 addresses. Another possibility is to consider the set of of IPv6 addresses. Another possibility is to consider the set of
these wireless interfaces as a single network interface (not these wireless interfaces as a single network interface (not
including the IEEE 802.11-OCB interface used by Non IP safety including the IEEE 802.11-OCB interface used by Non IP safety
critical communications). This will require specific logic to critical communications). This will require specific logic to
ensure, for example, that packets meant for a vehicle in front are ensure, for example, that packets meant for a vehicle in front are
actually sent by the radio in the front, or that multiple copies of actually sent by the radio in the front, or that multiple copies of
the same packet received by multiple interfaces are treated as a the same packet received by multiple interfaces are treated as a
single packet. Treating each wireless interface as a separate single packet. Treating each wireless interface as a separate
network interface pushes such issues to the application layer. network interface pushes such issues to the application layer.
The privacy requirements of Appendix D.4 imply that if these multiple If Mobile IPv6 with NEMO extensions is used, then the MCoA RFC5648
technology is relevant for Mobile Routers with multiple interfaces,
deployed in vehicles.
The privacy requirements of [] imply that if these multiple
interfaces are represented by many network interface, a single interfaces are represented by many network interface, a single
renumbering event SHALL cause renumbering of all these interfaces. renumbering event SHALL cause renumbering of all these interfaces.
If one MAC changed and another stayed constant, external observers If one MAC changed and another stayed constant, external observers
would be able to correlate old and new values, and the privacy would be able to correlate old and new values, and the privacy
benefits of randomization would be lost. benefits of randomization would be lost.
The privacy requirements of Non IP safety-critical communications The privacy requirements of Non IP safety-critical communications
imply that if a change of pseudonyme occurs, renumbering of all other imply that if a change of pseudonyme occurs, renumbering of all other
interfaces SHALL also occur. interfaces SHALL also occur.
D.7. MAC Address Generation C.4. MAC Address Generation
When designing the IPv6 over 802.11-OCB address mapping, we will When designing the IPv6 over 802.11-OCB address mapping, we will
assume that the MAC Addresses will change during well defined assume that the MAC Addresses will change during well defined
"renumbering events". The 48 bits randomized MAC addresses will have "renumbering events". The 48 bits randomized MAC addresses will have
the following characteristics: the following characteristics:
o Bit "Local/Global" set to "locally admninistered". o Bit "Local/Global" set to "locally admninistered".
o Bit "Unicast/Multicast" set to "Unicast". o Bit "Unicast/Multicast" set to "Unicast".
o 46 remaining bits set to a random value, using a random number o 46 remaining bits set to a random value, using a random number
generator that meets the requirements of [RFC4086]. generator that meets the requirements of [RFC4086].
The way to meet the randomization requirements is to retain 46 bits The way to meet the randomization requirements is to retain 46 bits
from the output of a strong hash function, such as SHA256, taking as from the output of a strong hash function, such as SHA256, taking as
input a 256 bit local secret, the "nominal" MAC Address of the input a 256 bit local secret, the "nominal" MAC Address of the
interface, and a representation of the date and time of the interface, and a representation of the date and time of the
renumbering event. renumbering event.
D.8. Security Certificate Generation Appendix D. IEEE 802.11 Messages Transmitted in OCB mode
When designing the IPv6 over 802.11-OCB address mapping, we will For information, at the time of writing, this is the list of IEEE
assume that the MAC Addresses will change during well defined 802.11 messages that may be transmitted in OCB mode, i.e. when
"renumbering events". So MUST also the Security Certificates. dot11OCBActivated is true in a STA:
Unless unavailable, the Security Certificate Generation mechanisms
SHOULD follow the specification in IEEE 1609.2 [ieee16094] or ETSI TS
103 097 [TS103097]. These security mechanisms have the following
characteristics:
o Authentication - Elliptic Curve Digital Signature Algorithm o The STA may send management frames of subtype Action and, if the
(ECDSA) - A Secured Hash Function (SHA-256) will sign the message STA maintains a TSF Timer, subtype Timing Advertisement;
with the public key of the sender.
o Encryption - Elliptic Curve Integrated Encryption Scheme (ECIES) - o The STA may send control frames, except those of subtype PS-Poll,
A Key Derivation Function (KDF) between the sender's public key CF-End, and CF-End plus CFAck;
and the receiver's private key will generate a symetric key used
to encrypt a packet.
If the mechanisms described in IEEE 1609.2 [ieee16094] or ETSI TS 103 o The STA may send data frames of subtype Data, Null, QoS Data, and
097 [TS103097] are either not supported or not capable of running on QoS Null.
the hardware, an alternative approach based on Pretty-Good-Privacy
(PGP) MAY be used as an alternative.
Authors' Addresses Authors' Addresses
Alexandre Petrescu Alexandre Petrescu
CEA, LIST CEA, LIST
CEA Saclay CEA Saclay
Gif-sur-Yvette , Ile-de-France 91190 Gif-sur-Yvette , Ile-de-France 91190
France France
Phone: +33169089223 Phone: +33169089223
 End of changes. 85 change blocks. 
665 lines changed or deleted 292 lines changed or added

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