draft-ietf-ipwave-ipv6-over-80211ocb-34.txt   draft-ietf-ipwave-ipv6-over-80211ocb-35.txt 
IPWAVE Working Group A. Petrescu IPWAVE Working Group A. Petrescu
Internet-Draft CEA, LIST Internet-Draft CEA, LIST
Intended status: Standards Track N. Benamar Intended status: Standards Track N. Benamar
Expires: June 21, 2019 Moulay Ismail University Expires: October 10, 2019 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
December 18, 2018 April 8, 2019
Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode
Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
draft-ietf-ipwave-ipv6-over-80211ocb-34 draft-ietf-ipwave-ipv6-over-80211ocb-35
Abstract Abstract
In order to transmit IPv6 packets on IEEE 802.11 networks running In order to transmit IPv6 packets on IEEE 802.11 networks running
outside the context of a basic service set (OCB, earlier "802.11p") outside the context of a basic service set (OCB, earlier "802.11p")
there is a need to define a few parameters such as the supported there is a need to define a few parameters such as the supported
Maximum Transmission Unit size on the 802.11-OCB link, the header Maximum Transmission Unit size on the 802.11-OCB link, the header
format preceding the IPv6 header, the Type value within it, and format preceding the IPv6 header, the Type value within it, and
others. This document describes these parameters for IPv6 and IEEE others. This document describes these parameters for IPv6 and IEEE
802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2019. This Internet-Draft will expire on October 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4
4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4
4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4
4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5
4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7
4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7
4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8
4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
5.2. MAC Address and Interface ID Generation . . . . . . . . . 10 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 10
5.2. MAC Address and Interface ID Generation . . . . . . . . . 11
5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 11 5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 27
Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 27 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 27
Appendix D. Changes Needed on a software driver 802.11a to Appendix D. Changes Needed on a software driver 802.11a to
become a 802.11-OCB driver . . . 31 become a 802.11-OCB driver . . . 32
Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 32 Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 33
Appendix F. Design Considerations . . . . . . . . . . . . . . . 33 Appendix F. Design Considerations . . . . . . . . . . . . . . . 34
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 33 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 34
Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 34 Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 34
H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 35 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 35
H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 37 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38
Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 39 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 [IEEE-802.11-2016] (a.k.a "802.11p" see 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see
Appendix B, Appendix C and Appendix D). This involves the layering Appendix B, Appendix C and Appendix D). This involves the layering
of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC 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, there layer. Compared to running IPv6 over the Ethernet MAC layer, there
is no modification expected to IEEE Std 802.11 MAC and Logical Link is no modification expected to IEEE Std 802.11 MAC and Logical Link
sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC
skipping to change at page 3, line 35 skipping to change at page 3, line 36
802.11 than on Ethernet. To satisfy these exceptions, this 802.11 than on Ethernet. To satisfy these exceptions, this
document describes an Ethernet Adaptation Layer between Ethernet document describes an Ethernet Adaptation Layer between Ethernet
headers and 802.11 headers. The Ethernet Adaptation Layer is headers and 802.11 headers. The Ethernet Adaptation Layer is
described Section 4.2.1. The operation of IP on Ethernet is described Section 4.2.1. The operation of IP on Ethernet is
described in [RFC1042], [RFC2464] and described in [RFC1042], [RFC2464] and
[I-D.hinden-6man-rfc2464bis]. [I-D.hinden-6man-rfc2464bis].
o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11.
This has impacts on security, privacy, subnet structure and This has impacts on security, privacy, subnet structure and
movement detection. For security and privacy recommendations see movement detection. For security and privacy recommendations see
Section 5 and Section 4.5. The subnet structure is described in Section 5 and Section 4.4. The subnet structure is described in
Section 4.6. The movement detection on OCB links is not described Section 4.6. The movement detection on OCB links is not described
in this document. in this document.
In the published literature, many documents describe aspects and In the published literature, many documents describe aspects and
problems related to running IPv6 over 802.11-OCB: problems related to running IPv6 over 802.11-OCB:
[I-D.ietf-ipwave-vehicular-networking-survey]. [I-D.ietf-ipwave-vehicular-networking-survey].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer
situated in a vehicle such as an automobile, bicycle, or similar. It situated in a vehicle such as an automobile, bicycle, or similar. It
has at least one IP interface that runs in mode OCB of 802.11, and has at least one IP interface that runs in mode OCB of 802.11, and
that has an "OBU" transceiver. See the definition of the term "OBU" that has an "OBU" transceiver. See the definition of the term "OBU"
in section Appendix I. in section Appendix I.
IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It
has at least two distinct IP-enabled interfaces; the wireless PHY/MAC has at least two distinct IP-enabled interfaces; the wireless PHY/MAC
layer of at least one of its IP-enabled interfaces is configured to layer of at least one of its IP-enabled interfaces is configured to
skipping to change at page 5, line 8 skipping to change at page 5, line 11
The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It
is the same value as IPv6 packets on Ethernet links, as specified in is the 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 on the Internet must have a minimum MTU of 1280 octets every link on the Internet must have a minimum MTU of 1280 octets
(stated in [RFC8200], and the recommendations therein, especially (stated in [RFC8200], and the recommendations therein, especially
with respect to fragmentation). with respect to fragmentation).
4.2. Frame Format 4.2. Frame Format
IP packets MUST be transmitted over 802.11-OCB media as QoS Data IP packets MUST be transmitted over 802.11-OCB media as QoS Data
frames whose format is specified in IEEE Std 802.11. frames whose format is specified in IEEE 802.11(TM) -2016
[IEEE-802.11-2016].
The IPv6 packet transmitted on 802.11-OCB MUST be immediately The IPv6 packet transmitted on 802.11-OCB MUST be immediately
preceded by a Logical Link Control (LLC) header and an 802.11 header. preceded by a Logical Link Control (LLC) header and an 802.11 header.
In the LLC header, and in accordance with the EtherType Protocol In the LLC header, and in accordance with the EtherType Protocol
Discrimination (EPD, see Appendix E), the value of the Type field Discrimination (EPD, see Appendix E), the value of the Type field
MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the
Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. Subtype sub-field in the Frame Control field MUST be set to 8 (i.e.
'QoS Data'); the value of the Traffic Identifier (TID) sub-field of 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of
the QoS Control field of the 802.11 header MUST be set to binary 001 the QoS Control field of the 802.11 header MUST be set to binary 001
(i.e. User Priority 'Background', QoS Access Category 'AC_BK'). (i.e. User Priority 'Background', QoS Access Category 'AC_BK').
skipping to change at page 7, line 10 skipping to change at page 7, line 10
Figure 2: Ethernet Adaptation Layer stacked with other layers Figure 2: Ethernet Adaptation Layer stacked with other layers
(in the above figure, a 802.11 profile is represented; this is used (in the above figure, a 802.11 profile is represented; this is used
also for 802.11-OCB profile.) also for 802.11-OCB profile.)
4.3. Link-Local Addresses 4.3. Link-Local Addresses
There are several types of IPv6 addresses [RFC4291], [RFC4193], that There are several types of IPv6 addresses [RFC4291], [RFC4193], that
MAY be assigned to an 802.11-OCB interface. Among these types of MAY be assigned to an 802.11-OCB interface. Among these types of
addresses only the IPv6 link-local addresses MAY be formed using an addresses only the IPv6 link-local addresses MAY be formed using an
EUI-64 identifier. EUI-64 identifier, in particular during transition time.
If the IPv6 link-local address is formed using an EUI-64 identifier, If the IPv6 link-local address is formed using an EUI-64 identifier,
then the mechanism of forming that address is the same mechanism as then the mechanism of forming that address is the same mechanism as
used to form an IPv6 link-local address on Ethernet links. This used to form an IPv6 link-local address on Ethernet links. This
mechanism is described in section 5 of [RFC2464]. mechanism is described in section 5 of [RFC2464].
For privacy, the link-local address MAY be formed according to the For privacy, the link-local address MAY be formed according to the
mechanisms described in Section 5.2. mechanisms described in Section 5.2.
4.4. Address Mapping 4.4. Stateless Autoconfiguration
Unicast and multicast address mapping MUST follow the procedures
specified for Ethernet interfaces in sections 6 and 7 of [RFC2464].
4.4.1. Address Mapping -- Unicast
The procedure for mapping IPv6 unicast addresses into Ethernet link-
layer addresses is described in [RFC4861].
4.4.2. Address Mapping -- Multicast
The multicast address mapping is performed according to the method
specified in section 7 of [RFC2464]. The meaning of the value "3333"
mentioned in that section 7 of [RFC2464] is defined in section 2.3.1
of [RFC7042].
Transmitting IPv6 packets to multicast destinations over 802.11 links
proved to have some performance issues
[I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be
exacerbated in OCB mode. Solutions for these problems SHOULD
consider the OCB mode of operation.
4.5. Stateless Autoconfiguration
There are several types of IPv6 addresses [RFC4291], [RFC4193], that There are several types of IPv6 addresses [RFC4291], [RFC4193], that
MAY be assigned to an 802.11-OCB interface. This section describes MAY be assigned to an 802.11-OCB interface. This section describes
the formation of Interface Identifiers for IPv6 addresses of type the formation of Interface Identifiers for IPv6 addresses of type
'Global' or 'Unique Local'. For Interface Identifiers for IPv6 'Global' or 'Unique Local'. For Interface Identifiers for IPv6
address of type 'Link-Local' see Section 4.3. address of type 'Link-Local' see Section 4.3.
The Interface Identifier for an 802.11-OCB interface is formed using The Interface Identifier for an 802.11-OCB interface is formed using
the same rules as the Interface Identifier for an Ethernet interface; the same rules as the Interface Identifier for an Ethernet interface;
the RECOMMENDED method for forming stable Interface Identifiers the RECOMMENDED method for forming stable Interface Identifiers
(IIDs) is described in [RFC8064]. The method of forming IIDs (IIDs) is described in [RFC8064]. The method of forming IIDs
described in section 4 of [RFC2464] MAY be used during transition described in section 4 of [RFC2464] MAY be used during transition
time. time, in particular for IPv6 link-local addresses.
The bits in the Interface Identifier have no generic meaning and the The bits in the Interface Identifier have no generic meaning and the
identifier should be treated as an opaque value. The bits identifier should be treated as an opaque value. The bits
'Universal' and 'Group' in the identifier of an 802.11-OCB interface 'Universal' and 'Group' in the identifier of an 802.11-OCB interface
are significant, as this is an IEEE link-layer address. The details are significant, as this is an IEEE link-layer address. The details
of this significance are described in [RFC7136]. If semantically of this significance are described in [RFC7136].
opaque Interface Identifiers are needed, a potential method for
generating semantically opaque Interface Identifiers with IPv6
Stateless Address Autoconfiguration is given in [RFC7217].
Semantically opaque Interface Identifiers, instead of meaningful Semantically opaque Interface Identifiers, instead of meaningful
Interface Identifiers derived from a valid and meaningful MAC address Interface Identifiers derived from a valid and meaningful MAC address
([RFC2464], section 4), MAY be needed in order to avoid certain ([RFC2464], section 4), help avoid certain privacy risks (see the
privacy risks. risks mentioned in Section 5.1.1). If semantically opaque Interface
Identifiers are needed, they MAY be generated using the method for
The IPv6 packets can be captured easily in the Internet and on-link generating semantically opaque Interface Identifiers with IPv6
in public roads. For this reason, an attacker may realize many Stateless Address Autoconfiguration given in [RFC7217]. Typically,
attacks on privacy. One such attack on 802.11-OCB is to capture, an opaque Interface Identifier is formed starting from identifiers
store and correlate Company ID information present in MAC addresses different than the MAC addresses, and from cryptographically strong
of many cars (e.g. listen for Router Advertisements, or other IPv6 material. Thus, privacy sensitive information is absent from
application data packets, and record the value of the source address Interface IDs, because it is impossible to calculate back the initial
in these packets). Further correlation of this information with value from which the Interface ID was first generated (intuitively,
other data captured by other means, or other visual information (car it is as hard as mentally finding the square root of a number, and as
color, others) MAY constitute privacy risks. impossible as trying to use computers to identify quickly whether a
large number is prime).
In order to avoid these risks, opaque Interface Identifiers MAY be
formed according to rules described in [RFC7217]. These opaque
Interface Identifiers are formed starting from identifiers different
than the MAC addresses, and from cryptographically strong material.
Thus, privacy sensitive information is absent from Interface IDs, and
it is impossible to calculate the initial value from which the
Interface ID was calculated.
Some applications that use IPv6 packets on 802.11-OCB links (among Some applications that use IPv6 packets on 802.11-OCB links (among
other link types) may benefit from IPv6 addresses whose Interface other link types) may benefit from IPv6 addresses whose Interface
Identifiers don't change too often. It is RECOMMENDED to use the Identifiers don't change too often. It is RECOMMENDED to use the
mechanisms described in RFC 7217 to permit the use of Stable mechanisms described in RFC 7217 to permit the use of Stable
Interface Identifiers that do not change within one subnet prefix. A Interface Identifiers that do not change within one subnet prefix. A
possible source for the Net-Iface Parameter is a virtual interface possible source for the Net-Iface Parameter is a virtual interface
name, or logical interface name, that is decided by a local name, or logical interface name, that is decided by a local
administrator. administrator.
The way Interface Identifiers are used MAY involve risks to privacy, 4.5. Address Mapping
as described in Section 5.1.
Unicast and multicast address mapping MUST follow the procedures
specified for Ethernet interfaces in sections 6 and 7 of [RFC2464].
4.5.1. Address Mapping -- Unicast
The procedure for mapping IPv6 unicast addresses into Ethernet link-
layer addresses is described in [RFC4861].
4.5.2. Address Mapping -- Multicast
The multicast address mapping is performed according to the method
specified in section 7 of [RFC2464]. The meaning of the value "3333"
mentioned in that section 7 of [RFC2464] is defined in section 2.3.1
of [RFC7042].
Transmitting IPv6 packets to multicast destinations over 802.11 links
proved to have some performance issues
[I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be
exacerbated in OCB mode. Solutions for these problems SHOULD
consider the OCB mode of operation.
4.6. Subnet Structure 4.6. Subnet Structure
A subnet is formed by the external 802.11-OCB interfaces of vehicles A subnet is formed by the external 802.11-OCB interfaces of vehicles
that are in close range (not by their in-vehicle interfaces). This that are in close range (not by their in-vehicle interfaces). This
subnet MUST use at least the link-local prefix fe80::/10 and the subnet MUST use at least the link-local prefix fe80::/10 and the
interfaces MUST be assigned IPv6 addresses of type link-local. interfaces MUST be assigned IPv6 addresses of type link-local.
The structure of this subnet is ephemeral, in that it is strongly The structure of this subnet is ephemeral, in that it is strongly
influenced by the mobility of vehicles: the 802.11 hidden node influenced by the mobility of vehicles: the hidden terminal effects
effects appear; the 802.11 networks in OCB mode may be considered as appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc'
'ad-hoc' networks with an addressing model as described in [RFC5889]. networks with an addressing model as described in [RFC5889]. On
On another hand, the structure of the internal subnets in each car is another hand, the structure of the internal subnets in each car is
relatively stable. relatively stable.
As recommended in [RFC5889], when the timing requirements are very As recommended in [RFC5889], when the timing requirements are very
strict (e.g. fast drive through IP-RSU coverage), no on-link subnet strict (e.g. fast drive through IP-RSU coverage), no on-link subnet
prefix should be configured on an 802.11-OCB interface. In such prefix should be configured on an 802.11-OCB interface. In such
cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED.
Additionally, even if the timing requirements are not very strict Additionally, even if the timing requirements are not very strict
(e.g. the moving subnet formed by two following vehicles is stable, a (e.g. the moving subnet formed by two following vehicles is stable, a
fixed IP-RSU is absent), the subnet is disconnected from the Internet fixed IP-RSU is absent), the subnet is disconnected from the Internet
skipping to change at page 10, line 44 skipping to change at page 10, line 34
eavesdropping and subsequent correlation of data; this may reveal eavesdropping and subsequent correlation of data; this may reveal
data considered private by the vehicle owner; there is a risk of data considered private by the vehicle owner; there is a risk of
being tracked. In outdoors public environments, where vehicles being tracked. In outdoors public environments, where vehicles
typically circulate, the privacy risks are more important than in typically circulate, the privacy risks are more important than in
indoors settings. It is highly likely that attacker sniffers are indoors settings. It is highly likely that attacker sniffers are
deployed along routes which listen for IEEE frames, including IP deployed along routes which listen for IEEE frames, including IP
packets, of vehicles passing by. For this reason, in the 802.11-OCB packets, of vehicles passing by. For this reason, in the 802.11-OCB
deployments, there is a strong necessity to use protection tools such deployments, there is a strong necessity to use protection tools such
as dynamically changing MAC addresses Section 5.2, semantically as dynamically changing MAC addresses Section 5.2, semantically
opaque Interface Identifiers and stable Interface Identifiers opaque Interface Identifiers and stable Interface Identifiers
Section 4.5. This may help mitigate privacy risks to a certain Section 4.4. This may help mitigate privacy risks to a certain
level. level.
5.1.1. Privacy Risks of Meaningful info in Interface IDs
The privacy risks of using MAC addresses displayed in Interface
Identifiers are important. The IPv6 packets can be captured easily
in the Internet and on-link in public roads. For this reason, an
attacker may realize many attacks on privacy. One such attack on
802.11-OCB is to capture, store and correlate Company ID information
present in MAC addresses of many cars (e.g. listen for Router
Advertisements, or other IPv6 application data packets, and record
the value of the source address in these packets). Further
correlation of this information with other data captured by other
means, or other visual information (car color, others) MAY constitute
privacy risks.
5.2. MAC Address and Interface ID Generation 5.2. MAC Address and Interface ID Generation
In 802.11-OCB networks, the MAC addresses MAY change during well In 802.11-OCB networks, the MAC addresses MAY change during well
defined renumbering events. In the moment the MAC address is changed defined renumbering events. In the moment the MAC address is changed
on an 802.11-OCB interface all the Interface Identifiers of IPv6 on an 802.11-OCB interface all the Interface Identifiers of IPv6
addresses assigned to that interface MUST change. addresses assigned to that interface MUST change.
The policy dictating when the MAC address is changed on the The policy dictating when the MAC address is changed on the
802.11-OCB interface is to-be-determined. For more information on 802.11-OCB interface is to-be-determined. For more information on
the motivation of this policy please refer to the privacy discussion the motivation of this policy please refer to the privacy discussion
skipping to change at page 11, line 50 skipping to change at page 12, line 7
critical vehicular communication. critical vehicular communication.
o Particular challenges arise when the pseudonymization mechanism o Particular challenges arise when the pseudonymization mechanism
used relies on (randomized) re-addressing. used relies on (randomized) re-addressing.
o A proper pseudonymization tool operated by a trusted third party o A proper pseudonymization tool operated by a trusted third party
may be needed to ensure both aspects simultaneously (privacy may be needed to ensure both aspects simultaneously (privacy
protection on one hand and trust between participants on another protection on one hand and trust between participants on another
hand). hand).
o This is discussed in Section 4.5 and Section 5 of this document. o This is discussed in Section 4.4 and Section 5 of this document.
o Pseudonymity is also discussed in o Pseudonymity is also discussed in
[I-D.ietf-ipwave-vehicular-networking-survey] in its sections [I-D.ietf-ipwave-vehicular-networking-survey] in its sections
4.2.4 and 5.1.2. 4.2.4 and 5.1.2.
6. IANA Considerations 6. IANA Considerations
No request to IANA. No request to IANA.
7. Contributors 7. Contributors
skipping to change at page 12, line 44 skipping to change at page 12, line 48
Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan
Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray
Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,
Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,
Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark,
Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra
Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun,
Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in
't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith,
Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo, Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo,
Lorenzo Colitti and William Whyte. Their valuable comments clarified Lorenzo Colitti, Pascal Thubert and William Whyte. Their valuable
particular issues and generally helped to improve the document. comments clarified particular issues and generally helped to improve
the document.
Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB
drivers for linux and described how. drivers for linux and described how.
For the multicast discussion, the authors would like to thank Owen For the multicast discussion, the authors would like to thank Owen
DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and
participants to discussions in network working groups. participants to discussions in network working groups.
The authors would like to thank participants to the Birds-of- The authors 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
skipping to change at page 15, line 34 skipping to change at page 15, line 39
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>. <https://www.rfc-editor.org/info/rfc8064>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
9.2. Informative References 9.2. Informative References
[ETSI-sec-archi] [ETSI-sec-archi]
"ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical
Specification, Intelligent Transport Systems (ITS); Specification, Intelligent Transport Systems (ITS);
skipping to change at page 17, line 22 skipping to change at page 17, line 33
document freely available at URL document freely available at URL
http://standards.ieee.org/getieee802/ http://standards.ieee.org/getieee802/
download/802.11p-2010.pdf retrieved on September 20th, download/802.11p-2010.pdf retrieved on September 20th,
2013.". 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.
-35: addressing the the intarea review: clarified a small apparent
contradiction between two parts of text that use the old MAC-based
IIDs (clarified by using qualifiers from each other: transition time,
and ll addresses); sequenced closer the LL and Stateless Autoconf
sections, instead of spacing them; shortened the paragraph of Opaque
IIDs; moved the privacy risks of in-clear IIDs in the security
section; removed a short phrase duplicating the idea of privacy
risks; added third time a reference to the 802.11-2016 document; used
'the hidden terminal' text; updated the Terminology section with new
BCP-14 text 'MUST' to include RFC8174.
-33: substituted 'movement detection' for 'handover behaviour' in -33: substituted 'movement detection' for 'handover behaviour' in
introductory text; removed redundant phrase referring to Security introductory text; removed redundant phrase referring to Security
Considerations section; removed the phrase about forming mechanisms Considerations section; removed the phrase about forming mechanisms
being left out, as IP is not much concerned about L2 forming; moved being left out, as IP is not much concerned about L2 forming; moved
the Pseudonym section from main section to end of Security the Pseudonym section from main section to end of Security
Considerations section (and clarified 'concurrently'); capitalized Considerations section (and clarified 'concurrently'); capitalized
SHOULD consider OCB in WiFi multicast problems, and referred to more SHOULD consider OCB in WiFi multicast problems, and referred to more
recent I-D on topic; removed several phrases in a paragraph about recent I-D on topic; removed several phrases in a paragraph about
oui.txt and MAC presence in IPv6 address, as they are well known oui.txt and MAC presence in IPv6 address, as they are well known
info, but clarified the example of privacy risk of Company ID in MAC info, but clarified the example of privacy risk of Company ID in MAC
 End of changes. 25 change blocks. 
82 lines changed or deleted 103 lines changed or added

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