draft-ietf-ipwave-ipv6-over-80211ocb-32.txt   draft-ietf-ipwave-ipv6-over-80211ocb-33.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 13, 2019 Moulay Ismail University Expires: June 20, 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 10, 2018 December 17, 2018
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-32 draft-ietf-ipwave-ipv6-over-80211ocb-33
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 13, 2019. This Internet-Draft will expire on June 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 5 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4
4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4
4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5
4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7
4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7
4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7
4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7
4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7
4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9
4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 11
5.2. MAC Address and Interface ID Generation . . . . . . . . . 11 5.2. MAC Address and Interface ID Generation . . . . . . . . . 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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
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
layer. layer.
The IPv6 network layer operates on 802.11-OCB in the same manner as The IPv6 network layer operates on 802.11-OCB in the same manner as
operating on Ethernet, but there are two kinds of exceptions: operating on Ethernet, but there are two kinds of exceptions:
o Exceptions due to different operation of IPv6 network layer on o Exceptions due to different operation of IPv6 network layer on
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.3.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
handover behaviour. For security and privacy recommendations see movement detection. For security and privacy recommendations see
Section 5 and Section 4.6. The subnet structure is described in Section 5 and Section 4.5. The subnet structure is described in
Section 4.7. The handover behaviour on OCB links is not described Section 4.6. The movement detection on OCB links is not described
in this document. in this document.
The Security Considerations section describes security and privacy
aspects of 802.11-OCB.
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 4, line 46 skipping to change at page 4, line 42
[I-D.ietf-ipwave-vehicular-networking-survey], that lists some [I-D.ietf-ipwave-vehicular-networking-survey], that lists some
scenarios and requirements for IP in Intelligent Transportation scenarios and requirements for IP in Intelligent Transportation
Systems. Systems.
The link model is the following: STA --- 802.11-OCB --- STA. In The link model is the following: STA --- 802.11-OCB --- STA. In
vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While
802.11-OCB is clearly specified, and the use of IPv6 over such link 802.11-OCB is clearly specified, and the use of IPv6 over such link
is not radically new, the operating environment (vehicular networks) is not radically new, the operating environment (vehicular networks)
brings in new perspectives. brings in new perspectives.
The mechanisms for forming and terminating, discovering, peering and
mobility management for 802.11-OCB links are not described in this
document.
4. IPv6 over 802.11-OCB 4. IPv6 over 802.11-OCB
4.1. Pseudonym Handling 4.1. Maximum Transmission Unit (MTU)
The demand for privacy protection of vehicles' and drivers'
identities, which could be granted by using a pseudonym or alias
identity at the same time, may hamper the required confidentiality of
messages and trust between participants - especially in safety
critical vehicular communication.
o Particular challenges arise when the pseudonymization mechanism
used relies on (randomized) re-addressing.
o A proper pseudonymization tool operated by a trusted third party
may be needed to ensure both aspects concurrently.
o This is discussed in Section 4.6 and Section 5.
o Pseudonymity is also discussed in
[I-D.ietf-ipwave-vehicular-networking-survey] in sections 4.2.4
and 5.1.2.
4.2. Maximum Transmission Unit (MTU)
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.3. 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 Std 802.11.
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').
To simplify the Application Programming Interface (API) between the To simplify the Application Programming Interface (API) between the
operating system and the 802.11-OCB media, device drivers MAY operating system and the 802.11-OCB media, device drivers MAY
implement an Ethernet Adaptation Layer that translates Ethernet II implement an Ethernet Adaptation Layer that translates Ethernet II
frames to the 802.11 format and vice versa. An Ethernet Adaptation frames to the 802.11 format and vice versa. An Ethernet Adaptation
Layer is described in Section 4.3.1. Layer is described in Section 4.2.1.
4.3.1. Ethernet Adaptation Layer 4.2.1. Ethernet Adaptation Layer
An 'adaptation' layer is inserted between a MAC layer and the An 'adaptation' layer is inserted between a MAC layer and the
Networking layer. This is used to transform some parameters between Networking layer. This is used to transform some parameters between
their form expected by the IP stack and the form provided by the MAC their form expected by the IP stack and the form provided by the MAC
layer. layer.
An Ethernet Adaptation Layer makes an 802.11 MAC look to IP An Ethernet Adaptation Layer makes an 802.11 MAC look to IP
Networking layer as a more traditional Ethernet layer. At reception, Networking layer as a more traditional Ethernet layer. At reception,
this layer takes as input the IEEE 802.11 header and the Logical-Link this layer takes as input the IEEE 802.11 header and the Logical-Link
Layer Control Header and produces an Ethernet II Header. At sending, Layer Control Header and produces an Ethernet II Header. At sending,
skipping to change at page 7, line 23 skipping to change at page 7, line 5
| 802.11 MAC | | 802.11 MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 PHY | | 802.11 PHY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.4. 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.
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.5. Address Mapping 4.4. Address Mapping
Unicast and multicast address mapping MUST follow the procedures Unicast and multicast address mapping MUST follow the procedures
specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. specified for Ethernet interfaces in sections 6 and 7 of [RFC2464].
4.5.1. Address Mapping -- Unicast 4.4.1. Address Mapping -- Unicast
The procedure for mapping IPv6 unicast addresses into Ethernet link- The procedure for mapping IPv6 unicast addresses into Ethernet link-
layer addresses is described in [RFC4861]. layer addresses is described in [RFC4861].
4.5.2. Address Mapping -- Multicast 4.4.2. Address Mapping -- Multicast
The multicast address mapping is performed according to the method The multicast address mapping is performed according to the method
specified in section 7 of [RFC2464]. The meaning of the value "3333" 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 mentioned in that section 7 of [RFC2464] is defined in section 2.3.1
of [RFC7042]. of [RFC7042].
Transmitting IPv6 packets to multicast destinations over 802.11 links Transmitting IPv6 packets to multicast destinations over 802.11 links
proved to have some performance issues proved to have some performance issues
[I-D.perkins-intarea-multicast-ieee802]. These issues may be [I-D.perkins-intarea-multicast-ieee802],
exacerbated in OCB mode. Solutions for these problems should [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. consider the OCB mode of operation.
4.6. Stateless Autoconfiguration 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.4. 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.
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
skipping to change at page 8, line 47 skipping to change at page 8, line 26
of this significance are described in [RFC7136]. If semantically of this significance are described in [RFC7136]. If semantically
opaque Interface Identifiers are needed, a potential method for opaque Interface Identifiers are needed, a potential method for
generating semantically opaque Interface Identifiers with IPv6 generating semantically opaque Interface Identifiers with IPv6
Stateless Address Autoconfiguration is given in [RFC7217]. 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), MAY be needed in order to avoid certain
privacy risks. privacy risks.
A valid MAC address includes a unique identifier pointing to a The IPv6 packets can be captured easily in the Internet and on-link
company together with its postal address, and a unique number within in public roads. For this reason, an attacker may realize many
that company MAC space (see the oui.txt file). The calculation attacks on privacy. One such attack on 802.11-OCB is to capture,
operation of the MAC address back from a given meaningful Interface store and correlate Company ID information present in MAC addresses
Identifier is straightforward ([RFC2464], section 4). The Interface of many cars (e.g. listen for Router Advertisements, or other IPv6
Identifier is part of an IPv6 address that is stored in IPv6 packets. application data packets, and record the value of the source address
in these packets). Further correlation of this information with
The IPv6 packets can be captured in the Internet easily. For these other data captured by other means, or other visual information (car
reasons, an attacker may realize many attacks on privacy. One such color, others) MAY constitute privacy risks.
attack on 802.11-OCB is to capture, store and correlate Company ID
information of many cars in public areas (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.
In order to avoid these risks, opaque Interface Identifiers MAY be In order to avoid these risks, opaque Interface Identifiers MAY be
formed according to rules described in [RFC7217]. These opaque formed according to rules described in [RFC7217]. These opaque
Interface Identifiers are formed starting from identifiers different Interface Identifiers are formed starting from identifiers different
than the MAC addresses, and from cryptographically strong material. than the MAC addresses, and from cryptographically strong material.
Thus, privacy sensitive information is absent from Interface IDs, and Thus, privacy sensitive information is absent from Interface IDs, and
it is impossible to calculate the initial value from which the it is impossible to calculate the initial value from which the
Interface ID was calculated. 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
skipping to change at page 9, line 35 skipping to change at page 9, line 8
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, The way Interface Identifiers are used MAY involve risks to privacy,
as described in Section 5.1. as described in Section 5.1.
4.7. 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 802.11 hidden node
effects appear; the 802.11 networks in OCB mode may be considered as effects appear; the 802.11 networks in OCB mode may be considered as
'ad-hoc' networks with an addressing model as described in [RFC5889]. 'ad-hoc' networks with an addressing model as described in [RFC5889].
skipping to change at page 10, line 13 skipping to change at page 9, line 35
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
(a default route is absent), and the addressing peers are equally (a default route is absent), and the addressing peers are equally
qualified (impossible to determine that some vehicle owns and qualified (impossible to determine that some vehicle owns and
distributes addresses to others) the use of link-local addresses is distributes addresses to others) the use of link-local addresses is
RECOMMENDED. RECOMMENDED.
The Neighbor Discovery protocol (ND) [RFC4861] is used over The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over
802.11-OCB links. 802.11-OCB links.
Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which
depend on timely movement detection, might need additional tuning depend on timely movement detection, might need additional tuning
work to handle the lack of link-layer notifications during handover. work to handle the lack of link-layer notifications during handover.
This is for further study. This is for further study.
5. Security Considerations 5. Security Considerations
Any security mechanism at the IP layer or above that may be carried Any security mechanism at the IP layer or above that may be carried
skipping to change at page 11, line 24 skipping to change at page 10, line 46
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.6. This may help mitigate privacy risks to a certain Section 4.5. This may help mitigate privacy risks to a certain
level. level.
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
skipping to change at page 12, line 14 skipping to change at page 11, line 39
of the interface, and a representation of the date and time of the of the interface, and a representation of the date and time of the
renumbering event. renumbering event.
A randomized Interface ID has the same characteristics of a A randomized Interface ID has the same characteristics of a
randomized MAC address, except the length in bits. A MAC address randomized MAC address, except the length in bits. A MAC address
SHOULD be of length 48 decimal. An Interface ID SHOULD be of length SHOULD be of length 48 decimal. An Interface ID SHOULD be of length
64 decimal for all types of IPv6 addresses. In the particular case 64 decimal for all types of IPv6 addresses. In the particular case
of IPv6 link-local addresses, the length of the Interface ID MAY be of IPv6 link-local addresses, the length of the Interface ID MAY be
118 decimal. 118 decimal.
5.3. Pseudonym Handling
The demand for privacy protection of vehicles' and drivers'
identities, which could be granted by using a pseudonym or alias
identity at the same time, may hamper the required confidentiality of
messages and trust between participants - especially in safety
critical vehicular communication.
o Particular challenges arise when the pseudonymization mechanism
used relies on (randomized) re-addressing.
o A proper pseudonymization tool operated by a trusted third party
may be needed to ensure both aspects simultaneously (privacy
protection on one hand and trust between participants on another
hand).
o This is discussed in Section 4.5 and Section 5 of this document.
o Pseudonymity is also discussed in
[I-D.ietf-ipwave-vehicular-networking-survey] in its sections
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
Christian Huitema, Tony Li. Christian Huitema, Tony Li.
Romain Kuntz contributed extensively about IPv6 handovers between Romain Kuntz contributed extensively about IPv6 handovers between
links running outside the context of a BSS (802.11-OCB links). links running outside the context of a BSS (802.11-OCB links).
skipping to change at page 16, line 27 skipping to change at page 16, line 27
over Ethernet Networks", draft-hinden-6man-rfc2464bis-02 over Ethernet Networks", draft-hinden-6man-rfc2464bis-02
(work in progress), March 2017. (work in progress), March 2017.
[I-D.ietf-ipwave-vehicular-networking-survey] [I-D.ietf-ipwave-vehicular-networking-survey]
Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M. Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M.
Wetterwald, "Survey on IP-based Vehicular Networking for Wetterwald, "Survey on IP-based Vehicular Networking for
Intelligent Transportation Systems", draft-ietf-ipwave- Intelligent Transportation Systems", draft-ietf-ipwave-
vehicular-networking-survey-00 (work in progress), July vehicular-networking-survey-00 (work in progress), July
2017. 2017.
[I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
in progress), November 2018.
[I-D.perkins-intarea-multicast-ieee802] [I-D.perkins-intarea-multicast-ieee802]
Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,
"Multicast Considerations over IEEE 802 Wireless Media", "Multicast Considerations over IEEE 802 Wireless Media",
draft-perkins-intarea-multicast-ieee802-03 (work in draft-perkins-intarea-multicast-ieee802-03 (work in
progress), July 2017. progress), July 2017.
[IEEE-1609.2] [IEEE-1609.2]
"IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Security Services for in Vehicular Environments (WAVE) -- Security Services for
Applications and Management Messages. Example URL Applications and Management Messages. Example URL
skipping to change at page 17, line 33 skipping to change at page 17, line 40
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.
-33: substituted 'movement detection' for 'handover behaviour' in
introductory text; removed redundant phrase referring to Security
Considerations section; removed the phrase about forming mechanisms
being left out, as IP is not much concerned about L2 forming; moved
the Pseudonym section from main section to end of Security
Considerations section (and clarified 'concurrently'); capitalized
SHOULD consider OCB in WiFi multicast problems, and referred to more
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
info, but clarified the example of privacy risk of Company ID in MAC
addresses in public roads; clarified that ND MUST be used over
802.11-OCB.
-32: significantly shortened the relevant ND/OCB paragraph. It now -32: significantly shortened the relevant ND/OCB paragraph. It now
just states ND is used over OCB, w/o detailing. just states ND is used over OCB, w/o detailing.
-31: filled in the section titled "Pseudonym Handling"; removed a -31: filled in the section titled "Pseudonym Handling"; removed a
'MAY NOT' phrase about possibility of having other prefix than the LL 'MAY NOT' phrase about possibility of having other prefix than the LL
on the link between cars; shortened and improved the paragraph about on the link between cars; shortened and improved the paragraph about
Mobile IPv6, now with DNAv6; improved the ND text about ND Mobile IPv6, now with DNAv6; improved the ND text about ND
retransmissions with relationship to packet loss; changed the title retransmissions with relationship to packet loss; changed the title
of an appendix from 'EPD' to 'Protocol Layering'; improved the of an appendix from 'EPD' to 'Protocol Layering'; improved the
'Aspects introduced by OCB' appendix with a few phrases about the 'Aspects introduced by OCB' appendix with a few phrases about the
 End of changes. 28 change blocks. 
79 lines changed or deleted 87 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/