draft-petrescu-ipv6-over-80211p-05.txt   draft-petrescu-ipv6-over-80211p-06.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: May 4, 2017 Moulay Ismail University Expires: June 3, 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
October 31, 2016 November 30, 2016
Transmission of IP Packets over IEEE 802.11 in mode Outside the Context Transmission of IPv6 Packets over IEEE 802.11 Outside the Context of a
of a Basic Service Set Basic Service Set (OCB)
draft-petrescu-ipv6-over-80211p-05.txt draft-petrescu-ipv6-over-80211p-06.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 May 4, 2017. This Internet-Draft will expire on June 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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.11p Links are Used . . 6
4. Aspects introduced by 802.11p to 802.11 . . . . . . . . . . . 6 4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 6
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 5. Layering of IPv6 over 802.11p as over Ethernet . . . . . . . 9
5.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 9
5.2. Non IP Communications . . . . . . . . . . . . . . . . . . 10 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Reliability Requirements . . . . . . . . . . . . . . . . 11 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 11
5.4. Privacy requirements . . . . . . . . . . . . . . . . . . 12 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 13
5.5. Authentication requirements . . . . . . . . . . . . . . . 13 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 13
5.6. Multiple interfaces . . . . . . . . . . . . . . . . . . . 13 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 13
5.7. MAC Address Generation . . . . . . . . . . . . . . . . . 14 5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 13
5.8. Security Certificate Generation . . . . . . . . . . . . . 14 5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 14
6. Layering of IPv4 and IPv6 over 802.11p as over Ethernet . . . 15 5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 15
6.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 15 6. Handovers between OCB links . . . . . . . . . . . . . . . . . 15
6.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 16 7. Example IPv6 Packet captured over a IEEE 802.11p link . . . . 17
6.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 17 7.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 18
6.2.2. MAC Address Resolution . . . . . . . . . . . . . . . 18 7.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 21
6.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 19 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
6.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
7. Handovers between OCB links . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 26
8. Example IPv6 Packet captured over a IEEE 802.11p link . . . . 24 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 29
8.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 25
8.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Explicit Prohibition of IPv6 on Channels Appendix B. Explicit Prohibition of IPv6 on Channels
Related to ITS Scenarios using 802.11p Networks Related to ITS Scenarios using 802.11p Networks
- an Analysis . . . . . . . . . . . . . . . . . . . 37 - an Analysis . . . . . . . . . . . . . . . . . . . 31
B.1. Interpretation of FCC and ETSI documents with B.1. Interpretation of FCC and ETSI documents with
respect to running IP on particular channels . . . . . . 37 respect to running IP on particular channels . . . . . . 31
B.2. Interpretations of Latencies of IP datagrams . . . . . . 38 B.2. Interpretations of Latencies of IP datagrams . . . . . . 33
Appendix C. Changes Needed on a software driver 802.11a to Appendix C. Changes Needed on a software driver 802.11a to
become a 802.11p driver . . . 38 become a 802.11-OCB driver . . 33
Appendix D. Use of IPv6 over 802.11p for distribution of Appendix D. Design Considerations . . . . . . . . . . . . . . . 34
certificates . . . . . . . . . . . . . . . . . . . . 40 D.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 D.2. Non IP Communications . . . . . . . . . . . . . . . . . . 35
D.3. Reliability Requirements . . . . . . . . . . . . . . . . 36
D.4. Privacy requirements . . . . . . . . . . . . . . . . . . 36
D.5. Authentication requirements . . . . . . . . . . . . . . . 37
D.6. Multiple interfaces . . . . . . . . . . . . . . . . . . . 38
D.7. MAC Address Generation . . . . . . . . . . . . . . . . . 38
D.8. Security Certificate Generation . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 47 skipping to change at page 4, line 44
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.11p 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.
Similarly, for IPv4, the values of these parameters are precisely the
same as IPv4 over Ethernet [RFC0894]: the recommended value of MTU to
be 1500 octets, and the Frame Format containing the Type 0x0800. For
IPv4, Address Resolution Protocol (ARP) [RFC0826] is used to
determine the MAC address used for an IPv4 address, exactly as is
done for Ethernet.
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.11p 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.11p link; this is described in the section titled
"Example of IPv6 Packet captured over an IEEE 802.11p link". "Example of IPv6 Packet captured over an IEEE 802.11p link".
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.11p. These points are consequences of the OCB operation which is
particular to 802.11p (Outside the Context of a BSS). First, the particular to 802.11p (Outside the Context of a BSS). First, the
handovers between OCB links need specific behaviour for IP Router handovers between OCB links need specific behaviour for IP Router
Advertisements, or otherwise 802.11p's Time Advertisement, or of Advertisements, or otherwise 802.11p'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.11p 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.11p and other 802.11 links is the privacy concerns
related to the address formation mechanisms. The OCB handovers and related to the address formation mechanisms. The OCB handovers and
security are described each in section Section 7 and Section 9 security are described each in section Section 6 and Section 8
respectively. respectively.
In standards, the operation of IPv6 as a 'data plane' over 802.11p is 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 specified at IEEE P1609 in [ieeep1609.3-D9-2010]. For example, it
mentions that "Networking services also specifies the use of the mentions that "Networking services also specifies the use of the
Internet protocol IPv6, and supports transport protocols such as UDP Internet protocol IPv6, and supports transport protocols such as UDP
and TCP. [...] A Networking Services implementation shall support and TCP. [...] A Networking Services implementation shall support
either IPv6 or WSMP or both." and "IP traffic is sent and received either IPv6 or WSMP or both." and "IP traffic is sent and received
through the LLC sublayer as specified in [...]". The layered stacks through the LLC sublayer as specified in [...]". The layered stacks
depicted in the "Architecture" document P1609.0 [ieeep1609.0-D2] depicted in the "Architecture" document P1609.0 [ieeep1609.0-D2]
skipping to change at page 6, line 25 skipping to change at page 6, line 14
3. Communication Scenarios where IEEE 802.11p Links are Used 3. Communication Scenarios where IEEE 802.11p Links are Used
The IEEE 802.11p Networks are used for vehicular communications, as The IEEE 802.11p Networks are used for vehicular communications, as
'Wireless Access in Vehicular Environments'. The IP communication '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 802.11p 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 Wildcard BSSID (i.e., all bits are set to 1) used by each node
o No beacons transmitted o No beacons transmitted
skipping to change at page 9, line 45 skipping to change at page 9, line 34
reductions in the throughput necessary to better accommodate reductions in the throughput necessary to better accommodate
vehicle-class speeds and distance ranges. 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 9. section Section 8.
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. Design Considerations 5. Layering of IPv6 over 802.11p as over Ethernet
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
over 802.11-OCB could be very similar to the operation of IPv6 over
other networks of the 802.11 family. However, the high mobility,
strong link asymetry and very short connection makes the 802.11-OCB
link significantly different from other 802.11 networks. Also, the
automotive applications have specific requirements for reliability,
security and privacy, which further add to the particularity of the
802.11-OCB link.
This section does not address safety-related applications, which are
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.
5.1. Vehicle ID
Automotive networks require the unique representation of each of
their node. Accordingly, a vehicle must be identified by at least
one unique ID. The current specification at ETSI and at IEEE 1609
identifies a vehicle by its MAC address uniquely obtained from the
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
802.11-OCB NICs. A mechanims to uniquely identify a vehicle
irrespectively to the different NICs and/or technologies is required.
5.2. Non IP Communications
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.
5.3. Reliability Requirements
The dynamically changing topology, short connectivity, mobile
transmitter and receivers, different antenna heights, and many-to-
many communication types, make IEEE 802.11-OCB links significantly
different from other IEEE 802.11 links. Any IPv6 mechanism operating
on IEEE 802.11-OCB link MUST support strong link asymetry, spatio-
temporal link quality, fast address resolution and transmission.
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
practice that IEEE 802.11-OCB does not rely on a Base Station for all
Basic Service Set management. In particular, IEEE 802.11-OCB SHALL
NOT use beacons. Any IPv6 mechanism requiring L2 services from IEEE
802.11 beacons MUST support an alternative service.
Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST
implement a mechanism for transmitter and receiver to converge to a
common channel.
Authentication not being possible, IPv6 over IEEE 802.11-OCB MUST
implement an distributed mechanism to authenticate transmitters and
receivers without the support of a DHCP server.
Time synchronization not being available, IPv6 over IEEE 802.11-OCB
MUST implement a higher layer mechanism for time synchronization
between transmitters and receivers without the support of a NTP
server.
The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB
MUST disable management mechanisms requesting acknowledgements or
replies.
The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE
802.11-OCB MUST implement fast IPv6 mobility management mechanisms.
5.4. Privacy requirements
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.
5.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 Section 5.4, the certificate
SHALL be changed at each 'renumbering event'.
5.6. Multiple interfaces
There are considerations for 2 or more IEEE 802.11-OCB interface
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
safety-critical communication. Any other IEEE 802.11-OCB may be used
for other type of traffic.
The mode of operation of these other wireless interfaces is not
clearly defined yet. One possibility is to consider each card as an
independent network interface, with a specific MAC Address and a set
of IPv6 addresses. Another possibility is to consider the set of
these wireless interfaces as a single network interface (not
including the IEEE 802.11-OCB interface used by Non IP safety
critical communications). This will require specific logic to
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
the same packet received by multiple interfaces are treated as a
single packet. Treating each wireless interface as a separate
network interface pushes such issues to the application layer.
The privacy requirements of Section 5.4 imply that if these multiple
interfaces are represented by many network interface, a single
renumbering event SHALL cause renumbering of all these interfaces.
If one MAC changed and another stayed constant, external observers
would be able to correlate old and new values, and the privacy
benefits of randomization would be lost.
The privacy requirements of Non IP safety-critical communications
imply that if a change of pseudonyme occurs, renumbering of all other
interfaces SHALL also occur.
5.7. MAC Address Generation
When designing the IPv6 over 802.11-OCB address mapping, we will
assume that the MAC Addresses will change during well defined
"renumbering events". The 48 bits randomized MAC addresses will have
the following characteristics:
o Bit "Local/Global" set to "locally admninistered".
o Bit "Unicast/Multicast" set to "Unicast".
o 46 remaining bits set to a random value, using a random number
generator that meets the requirements of [RFC4086].
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
input a 256 bit local secret, the "nominal" MAC Address of the
interface, and a representation of the date and time of the
renumbering event.
5.8. Security Certificate Generation
When designing the IPv6 over 802.11-OCB address mapping, we will
assume that the MAC Addresses will change during well defined
"renumbering events". So MUST also the Security Certificates.
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
(ECDSA) - A Secured Hash Function (SHA-256) will sign the message
with the public key of the sender.
o Encryption - Elliptic Curve Integrated Encryption Scheme (ECIES) -
A Key Derivation Function (KDF) between the sender's public key
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
097 [TS103097] are either not supported or not capable of running on
the hardware, an alternative approach based on Pretty-Good-Privacy
(PGP) MAY be used as an alternative.
6. Layering of IPv4 and IPv6 over 802.11p as over Ethernet
6.1. Maximum Transmission Unit (MTU) 5.1. Maximum Transmission Unit (MTU)
The default MTU for IP packets on 802.11p is 1500 octets. It is the The default MTU for IP packets on 802.11p is 1500 octets. It is the
same value as IPv6 packets on Ethernet links, as specified in same value as IPv6 packets on Ethernet links, as specified in
[RFC2464]. This value of the MTU respects the recommendation that [RFC2464]. This value of the MTU respects the recommendation that
every link in the Internet must have a minimum MTU of 1280 octets every link in the Internet must have a minimum MTU of 1280 octets
(stated in [RFC2460], and the recommendations therein, especially (stated in [RFC2460], and the recommendations therein, especially
with respect to fragmentation). If IPv6 packets of size larger than with respect to fragmentation). If IPv6 packets of size larger than
1500 bytes are sent on an 802.11-OCB interface then the IP stack will 1500 bytes are sent on an 802.11-OCB interface then the IP stack will
fragment into more IP packets, depending on the initial size. In fragment. In case there are IP fragments, the field "Sequence
case there are IP fragments, the field "Sequence number" of the number" of the 802.11 Data header containing the IP fragment field is
802.11 Data header containing the IP fragment field is increased. increased.
It is possible to send IP packets of size bigger than the MTU of 1500
bytes without the IP fragmentation mechanism to be involved.
However, in such cases it is not safe to assume that the on-link
receiver understands it and does not send a "Packet too Big" ICMPv6
message back - it likely will.
It is possible to set the MTU value on an interface to a value
smaller than 1500 bytes, and thus trigger IP fragmentation for
packets larger than that value. For example, set the MTU to 500
bytes and the IP fragmentation will generate IP fragments as soon as
IP packets to be sent are larger than 500 bytes. However, the lowest
such limit is 255 bytes. It is not possible to set an MTU of 254
bytes or lower on an interface.
It is possible that the MAC layer fragments as well (in addition to
the IP layer performing fragmentation). The 802.11 Data Header
includes a "Fragment number" field and a "More Fragments" field.
This former is set to 0 usually.
It is possible that the application layer fragments.
Non-IP packets such as WAVE Short Message Protocol (WSMP) can be Non-IP packets such as WAVE Short Message Protocol (WSMP) can be
delivered on 802.11-OCB links. Specifications of these packets are delivered on 802.11-OCB links. Specifications of these packets are
out of scope of this document, and do not impose any limit on the MTU out of scope of this document, and do not impose any limit on the MTU
size, allowing an arbitrary number of 'containers'. Non-IP packets size, allowing an arbitrary number of 'containers'. Non-IP packets
such as ETSI 'geonet' packets have an MTU of 1492 bytes. such as ETSI 'geonet' packets have an MTU of 1492 bytes.
The Equivalent Transmit Time on Channel is a concept that may be used The Equivalent Transmit Time on Channel is a concept that may be used
as an alternative to the MTU concept. A rate of transmission may be as an alternative to the MTU concept. A rate of transmission may be
specified as well. The ETTC, rate and MTU may be in direct specified as well. The ETTC, rate and MTU may be in direct
relationship. relationship.
6.2. Frame Format 5.2. Frame Format
IP packets are transmitted over 802.11p as standard Ethernet packets. IP packets are transmitted over 802.11p as standard Ethernet packets.
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 6.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). The for IPv6 is 0x86DD (hexadecimal 86DD, or otherwise #86DD).
EtherType code for IPv4 is 0x0800.
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 IPv4 on section 3 of [RFC2464]. The frame format for transmitting IPv6
802.11p networks is the same as transmitting IPv4 on Ethernet packets over Ethernet is illustrated below:
networks and is described in [RFC0894]. For sake of completeness,
the frame format for transmitting IPv6 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 32 skipping to change at page 11, line 32
| IPv6 | | IPv6 |
+- -+ +- -+
| header | | header |
+- -+ +- -+
| and | | and |
+- -+ +- -+
/ payload ... / / payload ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Each tic mark represents one bit.) (Each tic mark represents one bit.)
6.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.
skipping to change at page 18, line 22 skipping to change at page 12, line 22
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. The other fields in the Data and field in the Ethernet II Header.
LLC Headers are not used by the IPv6 stack.
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.
IPv6 packets can be transmitted as "IEEE 802.11 Data" or In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11
alternatively as "IEEE 802.11 QoS Data". Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in
the following figure:
IEEE 802.11 Data IEEE 802.11 QoS Data +--------------------+-------------+-------------+---------+
Logical-Link Control Logical-Link Control | 802.11 Data Header | LLC Header | IPv6 Header | Payload |
IPv6 Header IPv6 Header +--------------------+-------------+-------------+---------+
The value of the field "Type/Subtype" in the 802.11 Data header is or
0x0020. The value of the field "Type/Subtype" in the 802.11 QoS
header is 0x0028.
6.2.2. MAC Address Resolution +--------------------+-------------+-------------+---------+
| 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |
+--------------------+-------------+-------------+---------+
For IPv4, Address Resolution Protocol (ARP) [RFC0826] is used to The distinction between the two formats is given by the value of the
determine the MAC address used for an IPv4 address, exactly as is field "Type/Subtype". The value of the field "Type/Subtype" in the
done for Ethernet. 802.11 Data header is 0x0020. The value of the field "Type/Subtype"
in the 802.11 QoS header is 0x0028.
6.3. Link-Local Addresses The mapping between qos-related fields in the IPv6 header (e.g.
"Traffic Class", "Flow label") and fields in the "802.11 QoS Data
Header" (e.g. "QoS Control") are not specified in this document.
Guidance for a potential mapping is provided in
[I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB
mode.
For IPv6, the link-local address of an 802.11p interface is formed in 5.3. Link-Local Addresses
the same manner as on an Ethernet interface. This manner is
described in section 5 of [RFC2464].
For IPv4, link-local addressing is described in [RFC3927]. The link-local address of an 802.11p interface is formed in the same
manner as on an Ethernet interface. This manner is described in
section 5 of [RFC2464].
6.4. Address Mapping 5.4. Address Mapping
For unicast as for multicast, there is no change from the unicast and For unicast as for multicast, there is no change from the unicast and
multicast address mapping format of Ethernet interfaces, as defined multicast address mapping format of Ethernet interfaces, as defined
by sections 6 and 7 of [RFC2464]. by sections 6 and 7 of [RFC2464].
(however, there is discussion about geography, networking and IPv6 5.4.1. Address Mapping -- Unicast
multicast addresses: geographical dissemination of IPv6 data over
802.11p may be useful in traffic jams, for example).
6.4.1. Address Mapping -- Unicast
6.4.2. Address Mapping -- Multicast 5.4.2. Address Mapping -- Multicast
IPv6 protocols often make use of IPv6 multicast addresses in the IPv6 protocols often make use of IPv6 multicast addresses in the
destination field of IPv6 headers. For example, an ICMPv6 link- destination field of IPv6 headers. For example, an ICMPv6 link-
scoped Neighbor Advertisement is sent to the IPv6 address ff02::1 scoped Neighbor Advertisement is sent to the IPv6 address ff02::1
denoted "all-nodes" address. When transmitting these packets on denoted "all-nodes" address. When transmitting these packets on
802.11-OCB links it is necessary to map the IPv6 address to a MAC 802.11-OCB links it is necessary to map the IPv6 address to a MAC
address. address.
The same mapping requirement applies to the link-scoped multicast The same mapping requirement applies to the link-scoped multicast
addresses of other IPv6 protocols as well. In DHCPv6, the addresses of other IPv6 protocols as well. In DHCPv6, the
skipping to change at page 20, line 13 skipping to change at page 14, line 13
DST. DST.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[13] | DST[14] | | DST[13] | DST[14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[15] | DST[16] | | DST[15] | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Other than link-scope addressing, it may be possible to conceive
other IPv6 multicast addresses for specific use in vehicular
communication scenarios. For example, certain vehicle types (or road
infrastructure equipment) in a zone can be denoted by an IPv6
multicast address: "all-yellow-taxis-in-street", or "all-uber-cars".
This helps sending a message to these particular types of vehicles,
instead of sending to all vehicles in that same street. The
protocols SDP and LLDP could further be used in managing this as a
service.
It may be possible to map parts of other-than-link-scope IPv6
multicast address (e.g. parts of a global-scope IPv6 multicast
address) into parts of a 802.11-OCB MAC address. This may help
certain IPv6 operations.
A Group ID TBD of length 112bits may be requested from IANA; this A Group ID TBD of length 112bits may be requested from IANA; this
Group ID signifies "All 80211OCB Interfaces Address". Only the least Group ID signifies "All 80211OCB Interfaces Address". Only the least
32 significant bits of this "All 80211OCB Interfaces Address" will be 32 significant bits of this "All 80211OCB Interfaces Address" will be
mapped to and from a MAC multicast address. mapped to and from a MAC multicast address.
Alternatively, instead of 0x3333 address other addresses reserved at Transmitting IPv6 packets to multicast destinations over 802.11 links
IEEE can be considered. The Group MAC addresses reserved at IEEE are proved to have some performance issues
listed at https://standards.ieee.org/develop/regauth/grpmac/ [I-D.perkins-intarea-multicast-ieee802]. These issues may be
public.html (address browsed in July 2016). exacerbated in OCB mode. Solutions for these problems should
consider the OCB mode of operation.
6.5. Stateless Autoconfiguration 5.5. Stateless Autoconfiguration
The Interface Identifier for an 802.11p interface is formed using the The Interface Identifier for an 802.11p interface is formed using the
same rules as the Interface Identifier for an Ethernet interface; same rules as the Interface Identifier for an Ethernet interface;
this is described in section 4 of [RFC2464]. No changes are needed, this is described in section 4 of [RFC2464]. No changes are needed,
but some care must be taken when considering the use of the SLAAC but some care must be taken when considering the use of the SLAAC
procedure. procedure.
For example, the Interface Identifier for an 802.11p interface whose
built-in address is, in hexadecimal:
30-14-4A-D9-F9-6C
would be
32-14-4A-FF-FE-D9-F9-6C.
The bits in the the interface identifier have no generic meaning and The bits in the the interface identifier have no generic meaning and
the identifier should be treated as an opaque value. The bits the identifier should be treated as an opaque value. The bits
'Universal' and 'Group' in the identifier of an 802.11p interface are 'Universal' and 'Group' in the identifier of an 802.11p interface are
significant, as this is a IEEE link-layer address. The details of significant, as this is a IEEE link-layer address. The details of
this significance are described in [I-D.ietf-6man-ug]. this significance are described in [I-D.ietf-6man-ug].
As with all Ethernet and 802.11 interface identifiers, the identifier As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
of an 802.11p interface may involve privacy risks. A vehicle the identifier of an 802.11p interface may involve privacy risks. A
embarking an On-Board Unit whose egress interface is 802.11p may vehicle embarking an On-Board Unit whose egress interface is 802.11p
expose itself to eavesdropping and subsequent correlation of data; may expose itself to eavesdropping and subsequent correlation of
this may reveal data considered private by the vehicle owner. The data; this may reveal data considered private by the vehicle owner.
address generation mechanism should consider these aspects, as
described in [I-D.ietf-6man-ipv6-address-generation-privacy].
6.6. Subnet Structure
In this section the subnet structure may be described: the addressing
model (are multi-link subnets considered?), address resolution,
multicast handling, packet forwarding between IP subnets.
Alternatively, this section may be spinned off into a separate
document.
The 802.11p networks, much like other 802.11 networks, may be
considered as 'ad-hoc' networks. The addressing model for such
networks is described in [RFC5889].
The SLAAC procedure makes the assumption that if a packet is If stable Interface Identifiers are needed in order to form IPv6
retransmitted a fixed number of times (typically 3, but it is link addresses on 802.11-OCB links, it is recommended to follow the
dependent), any connected host receives the packet with high recommendation in [I-D.ietf-6man-default-iids].
probability. On ad-hoc links (when 802.11p is operated in OCB mode,
the link can be considered as 'ad-hoc'), both the hidden terminal
problem and mobility-range considerations make this assumption
incorrect. Therefore, SLAAC should not be used when address
collisions can induce critical errors in upper layers.
Some aspects of multi-hop ad-hoc wireless communications which are 5.6. Subnet Structure
relevant to the use of 802.11p (e.g. the 'hidden' node) are described
in [I-D.baccelli-multi-hop-wireless-communication].
When operating in OCB mode, it may be appropriate to use a 6LoWPAN The 802.11 networks in OCB mode may be considered as 'ad-hoc'
adaptation layer [RFC6775]. However, it should be noted that the use networks. The addressing model for such networks is described in
6lowpan adaptation layer is comparable with the use of Ethernet to [RFC5889].
802.11 adaptation layer.
7. Handovers between OCB links 6. Handovers between OCB links
A station operating IEEE 802.11p in the 5.9 GHz band in US or EU is 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 required to send data frames outside the context of a BSS. In this
case, the station does not utilize the IEEE 802.11 authentication, case, the station does not utilize the IEEE 802.11 authentication,
association, or data confidentiality services. This avoids the association, or data confidentiality services. This avoids the
latency associated with establishing a BSS and is particularly suited latency associated with establishing a BSS and is particularly suited
to communications between mobile stations or between a mobile station 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 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). Road-Side Unit a.k.a RSU acting as an infrastructure router).
skipping to change at page 23, line 9 skipping to change at page 16, line 12
receiving a Neighbor Advertisement message from a RSU, in response to receiving a Neighbor Advertisement message from a RSU, in response to
a Neighbor Solicitation message sent by the moving station. The RSU a Neighbor Solicitation message sent by the moving station. The RSU
should also configure a low Reachable Time value in its RA in order 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 to ensure that a moving station does not assume an RSU to be
reachable for too long. reachable for too long.
The Mobile IPv6 "Advertisement Interval Option" as well as the NUD The Mobile IPv6 "Advertisement Interval Option" as well as the NUD
procedure only help knowing if the RSU is still reachable by the procedure only help knowing if the RSU is still reachable by the
moving station. It does not provide the moving station with moving station. It does not provide the moving station with
information about other potential RSUs that might be in range. For information about other potential RSUs that might be in range. For
this purpose, increasing the RA frequency could reduce the delay to this purpose, it is by increasing the RA frequency that the delay
discover the next RSU. The Neighbor Discovery protocol [RFC4861] could be reduced to discover the next RSU. The Neighbor Discovery
limits the unsolicited multicast RA interval to a minimum of 3 protocol [RFC4861] limits the unsolicited multicast RA interval to a
seconds (the MinRtrAdvInterval variable). This value is too high for minimum of 3 seconds (the MinRtrAdvInterval variable). This value is
dense deployments of Access Routers deployed along fast roads. The too high for dense deployments of Access Routers deployed along fast
protocol Mobile IPv6 [RFC6275] allows routers to send such RA more roads. The protocol Mobile IPv6 [RFC6275] allows routers to send
frequently, with a minimum possible of 0.03 seconds (the same such RA more frequently, with a minimum possible of 0.03 seconds (the
MinRtrAdvInterval variable): this should be preferred to ensure a same MinRtrAdvInterval variable): this should be preferred to ensure
faster detection of the potential RSUs in range. 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 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 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 one that would afford the moving station spending the longest time in
its vicinity, in order to avoid too frequent handovers). In this its vicinity, in order to avoid too frequent handovers). In this
case, it would be helpful to base the decision on the signal quality 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 (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 better signal would probably offer a longer coverage. If, in terms
of RA frequency, it is not possible to adopt the recommendations of of RA frequency, it is not possible to adopt the recommendations of
protocol Mobile IPv6 (but only the Neighbor Discovery specification protocol Mobile IPv6 (but only the Neighbor Discovery specification
skipping to change at page 24, line 15 skipping to change at page 17, line 25
available at the same time, the moving station should perform the available at the same time, the moving station should perform the
handover decision based on the signal quality. Finally, optimistic handover decision based on the signal quality. Finally, optimistic
DAD can be used to reduce the handover delay. DAD can be used to reduce the handover delay.
The Received Frame Power Level (RCPI) defined in IEEE Std The Received Frame Power Level (RCPI) defined in IEEE Std
802.11-2012, conditioned by the dotOCBActived flag, is an information 802.11-2012, conditioned by the dotOCBActived flag, is an information
element which contains a value expressing the power level at which element which contains a value expressing the power level at which
that frame was received. This value may be used in comparing power that frame was received. This value may be used in comparing power
levels when triggering IP handovers. levels when triggering IP handovers.
8. Example IPv6 Packet captured over a IEEE 802.11p link 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 captured on an
skipping to change at page 25, line 10 skipping to change at page 18, line 20
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 The popular wireshark network protocol analyzer is a free software
tool for Windows and Unix. It includes a dissector for 802.11p 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 along with all other 802.11 features (i.e. it displays these
features in a human-readable format). features in a human-readable format).
8.1. Capture in Monitor Mode 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 27, line 42 skipping to change at page 21, line 5
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.
8.2. Capture in Normal Mode 7.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 29, line 33 skipping to change at page 23, 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).
9. Security Considerations 8. Security Considerations
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).
skipping to change at page 30, line 19 skipping to change at page 24, line 19
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.
10. IANA Considerations 9. IANA Considerations
11. Contributors 10. Contributors
Romain Kuntz contributed extensively the concepts described in Romain Kuntz contributed extensively the concepts described in
Section 7 about IPv6 handovers between links running outside the Section 6 about IPv6 handovers between 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 IPv4 Voronov provided significant feedback on the experience of using IP
and IPv6 messages over 802.11-OCB in initial trials. messages over 802.11-OCB in initial trials.
12. Acknowledgements 11. 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 Roy, Ray Hunter,
Tom Kurihara, Michelle Wetterwald, Michal Sojka, Jan de Jongh, Suresh Tom Kurihara, Michelle Wetterwald, Michal Sojka, Jan de Jongh, Suresh
Krishnan, Dino Farinacci, Vincent Park and Gloria Gwynne. Their Krishnan, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong and Gloria
valuable comments clarified certain issues and generally helped to Gwynne. Their valuable comments clarified certain issues and
improve the document. 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.
13. References 12. References
13.1. Normative References 12.1. Normative References
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-default-iids]
Cooper, A., Gont, F., and D. Thaler, "Privacy Gont, F., Cooper, A., Thaler, D., and S. LIU,
Considerations for IPv6 Address Generation Mechanisms", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-ipv6-address-generation-privacy-08 (work draft-ietf-6man-default-iids-16 (work in progress),
in progress), September 2015. 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.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [I-D.ietf-tsvwg-ieee-802-11]
Converting Network Protocol Addresses to 48.bit Ethernet Szigeti, T. and F. Baker, "DiffServ to IEEE 802.11
Address for Transmission on Ethernet Hardware", STD 37, Mapping", draft-ietf-tsvwg-ieee-802-11-01 (work in
RFC 826, DOI 10.17487/RFC0826, November 1982, progress), November 2016.
<http://www.rfc-editor.org/info/rfc826>.
[RFC0894] Hornig, C., "A Standard for the Transmission of IP
Datagrams over Ethernet Networks", STD 41, RFC 894,
DOI 10.17487/RFC0894, April 1984,
<http://www.rfc-editor.org/info/rfc894>.
[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
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>. <http://www.rfc-editor.org/info/rfc2464>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<http://www.rfc-editor.org/info/rfc3927>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<http://www.rfc-editor.org/info/rfc4429>. <http://www.rfc-editor.org/info/rfc4429>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
skipping to change at page 32, line 33 skipping to change at page 26, line 24
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>. 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
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>.
13.2. Informative References [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
12.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 33, line 38 skipping to change at page 27, line 25
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] [I-D.baccelli-multi-hop-wireless-communication]
Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless
Communication", draft-baccelli-multi-hop-wireless- Communication", draft-baccelli-multi-hop-wireless-
communication-06 (work in progress), July 2011. communication-06 (work in progress), July 2011.
[I-D.perkins-intarea-multicast-ieee802]
Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,
"Multicast Considerations over IEEE 802 Wireless Media",
draft-perkins-intarea-multicast-ieee802-01 (work in
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-
reqs-03 (work in progress), October 2013. reqs-03 (work in progress), October 2013.
[ieee16094] [ieee16094]
"1609.2-2016 - IEEE Standard for Wireless Access in "1609.2-2016 - IEEE Standard for Wireless Access in
Vehicular Environments--Security Services for Applications Vehicular Environments--Security Services for Applications
and Management Messages; document freely available at URL and Management Messages; document freely available at URL
skipping to change at page 36, line 5 skipping to change at page 30, line 5
Systems, Volume 14, Issue 1, URL and Digital Object Systems, Volume 14, Issue 1, URL and Digital Object
Identifier: http://dx.doi.org/10.1109/TITS.2012.2206387, Identifier: http://dx.doi.org/10.1109/TITS.2012.2206387,
Downloaded on: 24 October 2013, Availability: free at Downloaded on: 24 October 2013, Availability: free at
some sites, paying at others, March 2013. 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-
over-80211p-06.txt:
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- From draft-petrescu-ipv6-over-80211p-02.txt to draft-petrescu-ipv6-
over-80211p-03.txt: over-80211p-03.txt:
o Added clarification about the "OCBActivated" qualifier in the the o Added clarification about the "OCBActivated" qualifier in the the
new IEEE 802.11-2012 document; this IEEE document integrates now new IEEE 802.11-2012 document; this IEEE document integrates now
all earlier 802.11p features; this also signifies the all earlier 802.11p features; this also signifies the
dissapearance of an IEEE IEEE 802.11p document altogether. dissapearance of an IEEE IEEE 802.11p document altogether.
o Added explanation about FCC not prohibiting IP on channels, and o Added explanation about FCC not prohibiting IP on channels, and
comments about engineering advice and reliability of IP messages. comments about engineering advice and reliability of IP messages.
skipping to change at page 38, line 38 skipping to change at page 33, line 16
IPv6 may be "allowed" on any channel. Certain interpretations IPv6 may be "allowed" on any channel. Certain interpretations
consider that communicating IP datagrams may involve longer latencies consider that communicating IP datagrams may involve longer latencies
than non-IP datagrams; this may make them little adapted for safety than non-IP datagrams; this may make them little adapted for safety
applications which require fast reaction. Certain other views applications which require fast reaction. Certain other views
disagree with this, arguing that IP datagrams are transmitted at the 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 same speed as any other non-IP datagram and may thus offer same level
of reactivity for safety applications. of reactivity for safety applications.
Appendix C. Changes Needed on a software driver 802.11a to become a Appendix C. Changes Needed on a software driver 802.11a to become a
802.11p 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
802.11p layer, in France: 5875MHz to 5925MHz. 802.11p layer, in France: 5875MHz to 5925MHz.
skipping to change at page 40, line 5 skipping to change at page 34, line 29
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. Use of IPv6 over 802.11p for distribution of certificates Appendix D. Design Considerations
Security of vehicular communications is one of the challenging tasks The networks defined by 802.11-OCB are in many ways similar to other
in the Intelligent Transport Systems. The adoption of security networks of the 802.11 family. In theory, the encapsulation of IPv6
procedures becomes an indispensable feature that cannot be neglected over 802.11-OCB could be very similar to the operation of IPv6 over
when designing new protocols. One of the interesting use cases of other networks of the 802.11 family. However, the high mobility,
transmitting IPv6 packets over IEEE 802.11p links is the distribution strong link asymetry and very short connection makes the 802.11-OCB
of certificates between road side infrastructure and the vehicule link significantly different from other 802.11 networks. Also, the
(Figure below). automotive applications have specific requirements for reliability,
security and privacy, which further add to the particularity of the
802.11-OCB link.
########### This section does not address safety-related applications, which are
# # done on non-IP communications. However, this section will consider
# Server # the transmission of such non IP communication in the design
#(backend)# specification of IPv6 over IEEE 802.11-OCB.
# #
###########
|
|
| <-- link (depending on the infrastructure)
|
|
|
|
########## #############
# # # #
# RSU # - - - - - - - - - -# Router #
# # 802.11p Link # in-vehicle#
########## #############
o o
Many security mechanisms have been proposed for the vehicular D.1. Vehicle ID
environment, mechanisms often relying on public key algorithms.
Public key algorithms necessitate a public key infrastructure (PKI) Automotive networks require the unique representation of each of
to distribute and revoke certificates. The server backend in the their node. Accordingly, a vehicle must be identified by at least
figure can play the role of a Certification Authority which will send one unique ID. The current specification at ETSI and at IEEE 1609
certificates and revocation lists to the RSU which in turn identifies a vehicle by its MAC address uniquely obtained from the
retransmits certificates in messages directed to passing-by vehicles. 802.11-OCB NIC.
The initiation distribution of certificates as IPv6 messages over
802.11p links may be realized by WSA messages (WAVE Service A MAC address uniquely obtained from a IEEE 802.11-OCB NIC
Announcement, a non-IP message). The certificate is sent as an IPv6 implicitely generates multiple vehicle IDs in case of multiple
messages over a single-hop 802.11p link. 802.11-OCB NICs. A mechanims to uniquely identify a vehicle
irrespectively to the different NICs and/or technologies is required.
D.2. Non IP Communications
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
transmitter and receivers, different antenna heights, and many-to-
many communication types, make IEEE 802.11-OCB links significantly
different from other IEEE 802.11 links. Any IPv6 mechanism operating
on IEEE 802.11-OCB link MUST support strong link asymetry, spatio-
temporal link quality, fast address resolution and transmission.
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
practice that IEEE 802.11-OCB does not rely on a Base Station for all
Basic Service Set management. In particular, IEEE 802.11-OCB SHALL
NOT use beacons. Any IPv6 mechanism requiring L2 services from IEEE
802.11 beacons MUST support an alternative service.
Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST
implement a mechanism for transmitter and receiver to converge to a
common channel.
Authentication not being possible, IPv6 over IEEE 802.11-OCB MUST
implement an distributed mechanism to authenticate transmitters and
receivers without the support of a DHCP server.
Time synchronization not being available, IPv6 over IEEE 802.11-OCB
MUST implement a higher layer mechanism for time synchronization
between transmitters and receivers without the support of a NTP
server.
The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB
MUST disable management mechanisms requesting acknowledgements or
replies.
The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE
802.11-OCB MUST implement fast IPv6 mobility management mechanisms.
D.4. Privacy requirements
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
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
safety-critical communication. Any other IEEE 802.11-OCB may be used
for other type of traffic.
The mode of operation of these other wireless interfaces is not
clearly defined yet. One possibility is to consider each card as an
independent network interface, with a specific MAC Address and a set
of IPv6 addresses. Another possibility is to consider the set of
these wireless interfaces as a single network interface (not
including the IEEE 802.11-OCB interface used by Non IP safety
critical communications). This will require specific logic to
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
the same packet received by multiple interfaces are treated as a
single packet. Treating each wireless interface as a separate
network interface pushes such issues to the application layer.
The privacy requirements of Appendix D.4 imply that if these multiple
interfaces are represented by many network interface, a single
renumbering event SHALL cause renumbering of all these interfaces.
If one MAC changed and another stayed constant, external observers
would be able to correlate old and new values, and the privacy
benefits of randomization would be lost.
The privacy requirements of Non IP safety-critical communications
imply that if a change of pseudonyme occurs, renumbering of all other
interfaces SHALL also occur.
D.7. MAC Address Generation
When designing the IPv6 over 802.11-OCB address mapping, we will
assume that the MAC Addresses will change during well defined
"renumbering events". The 48 bits randomized MAC addresses will have
the following characteristics:
o Bit "Local/Global" set to "locally admninistered".
o Bit "Unicast/Multicast" set to "Unicast".
o 46 remaining bits set to a random value, using a random number
generator that meets the requirements of [RFC4086].
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
input a 256 bit local secret, the "nominal" MAC Address of the
interface, and a representation of the date and time of the
renumbering event.
D.8. Security Certificate Generation
When designing the IPv6 over 802.11-OCB address mapping, we will
assume that the MAC Addresses will change during well defined
"renumbering events". So MUST also the Security Certificates.
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
(ECDSA) - A Secured Hash Function (SHA-256) will sign the message
with the public key of the sender.
o Encryption - Elliptic Curve Integrated Encryption Scheme (ECIES) -
A Key Derivation Function (KDF) between the sender's public key
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
097 [TS103097] are either not supported or not capable of running on
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. 64 change blocks. 
516 lines changed or deleted 426 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/