draft-ietf-ipwave-ipv6-over-80211ocb-27.txt   draft-ietf-ipwave-ipv6-over-80211ocb-28.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: March 18, 2019 Moulay Ismail University Expires: March 23, 2019 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
September 14, 2018 September 19, 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-27 draft-ietf-ipwave-ipv6-over-80211ocb-28
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 March 18, 2019. This Internet-Draft will expire on March 23, 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 . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5
4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5
4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5
4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5
4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7
4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7
4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7
4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 7
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7
4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 9 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
5.2. MAC Address Generation . . . . . . . . . . . . . . . . . 10 5.2. MAC Address and Interface ID Generation . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 25
Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 24 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 25
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 . . . 28 become a 802.11-OCB driver . . . 29
Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 29 Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 30
Appendix F. Design Considerations . . . . . . . . . . . . . . . 30 Appendix F. Design Considerations . . . . . . . . . . . . . . . 31
F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31
Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 31 Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 32
H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33
H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 34 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35
Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 36 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
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.2.1. The operation of IP on Ethernet is described Section 4.3.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 handover behaviour. For security and privacy recommendations see
Section 5 and Section 4.5. The subnet structure is described in Section 5 and Section 4.6. The subnet structure is described in
Section 4.6. The handover behaviour on OCB links is not described Section 4.7. The handover behaviour 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].
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. An IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It
IP-RSU has at least two distinct IP-enabled interfaces. An IP-RSU is has at least two distinct IP-enabled interfaces; the wireless PHY/MAC
similar to a Wireless Termination Point (WTP), as defined in layer of at least one of its IP-enabled interfaces is configured to
[RFC5415], or an Access Point (AP), as defined in IEEE documents, or operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU
an Access Network Router (ANR) defined in [RFC3753], with one key in the vehicle over 802.11 wireless link operating in OCB mode. An
particularity: the wireless PHY/MAC layer of at least one of its IP- IP-RSU is similar to an Access Network Router (ANR) defined in
enabled interfaces is configured to operate in 802.11-OCB mode. The [RFC3753], and a Wireless Termination Point (WTP) defined in
IP-RSU communicates with the IP-OBU in the vehicle over 802.11 [RFC5415].
wireless link operating in OCB mode.
OCB (outside the context of a basic service set - BSS): A mode of OCB (outside the context of a basic service set - BSS): A mode of
operation in which a STA is not a member of a BSS and does not operation in which a STA is not a member of a BSS and does not
utilize IEEE Std 802.11 authentication, association, or data utilize IEEE Std 802.11 authentication, association, or data
confidentiality. confidentiality.
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
attribute dot11OCBActivited is true. Note: compliance with standards attribute dot11OCBActivited is true. Note: compliance with standards
and regulations set in different countries when using the 5.9GHz and regulations set in different countries when using the 5.9GHz
frequency band is required. frequency band is required.
skipping to change at page 5, line 4 skipping to change at page 5, line 6
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 The mechanisms for forming and terminating, discovering, peering and
mobility management for 802.11-OCB links are not described in this mobility management for 802.11-OCB links are not described in this
document. document.
4. IPv6 over 802.11-OCB 4. IPv6 over 802.11-OCB
4.1. Maximum Transmission Unit (MTU)
4.1. Pseudonym Handling
Pseudonym.
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.2. Frame Format 4.3. 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), the value of the Type field MUST be set to Discrimination (EPD), the value of the Type field MUST be set to
0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub- 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. 'QoS Data'); 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 the QoS 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 (i.e. Control field of the 802.11 header MUST be set to binary 001 (i.e.
User Priority 'Background', QoS Access Category 'AC_BK'). 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.2.1. Layer is described in Section 4.3.1.
4.2.1. Ethernet Adaptation Layer 4.3.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 5 skipping to change at page 7, line 8
| 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.3. Link-Local Addresses 4.4. 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].
4.4. Address Mapping For privacy, the link-local address MAY be formed according to the
mechanisms described in Section 5.2.
4.5. 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.4.1. Address Mapping -- Unicast 4.5.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.4.2. Address Mapping -- Multicast 4.5.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]. These issues may be
exacerbated in OCB mode. Solutions for these problems should exacerbated in OCB mode. Solutions for these problems should
consider the OCB mode of operation. consider the OCB mode of operation.
4.5. Stateless Autoconfiguration 4.6. 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.4.
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
'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]. 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].
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.6. Subnet Structure 4.7. 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. This interfaces MUST be assigned IPv6 addresses of type link-local. This
subnet MAY NOT have any other prefix than the link-local prefix. subnet MAY NOT have any other prefix than the link-local prefix.
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].
On another hand, the structure of the internal subnets in each car is On 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
(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
(a default route is absent), and the addressing peers are equally
qualified (impossible to determine that some vehicle owns and
distributes addresses to others) the use of link-local addresses is
RECOMMENDED.
The Neighbor Discovery protocol (ND) [RFC4861] is used over The Neighbor Discovery protocol (ND) [RFC4861] is used over
802.11-OCB links. 802.11-OCB links.
The operation of the Mobile IPv6 protocol over 802.11-OCB links is The operation of the Mobile IPv6 protocol over 802.11-OCB links is
different than on other links. The Movement Detection operation different than on other links. The Movement Detection operation
(section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability (section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability
Detection operation of the Neighbor Discovery protocol, for the Detection operation of the Neighbor Discovery protocol, for the
reason mentioned in the previous paragraph. Also, the 802.11-OCB reason mentioned in the previous paragraph. Also, the 802.11-OCB
link layer is not a lower layer that can provide an indication that a link layer is not a lower layer that can provide an indication that a
link layer handover has occured. The operation of the Mobile IPv6 link layer handover has occured. The operation of the Mobile IPv6
skipping to change at page 10, line 8 skipping to change at page 10, line 21
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.6. This may help mitigate privacy risks to a certain
level. level.
5.2. MAC Address 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
in Appendix C. in Appendix C.
skipping to change at page 10, line 34 skipping to change at page 10, line 47
o Bit "Local/Global" set to "locally admninistered". o Bit "Local/Global" set to "locally admninistered".
o Bit "Unicast/Multicast" set to "Unicast". o Bit "Unicast/Multicast" set to "Unicast".
o The 46 remaining bits are set to a random value, using a random o The 46 remaining bits are set to a random value, using a random
number generator that meets the requirements of [RFC4086]. number generator that meets the requirements of [RFC4086].
To meet the randomization requirements for the 46 remaining bits, a To meet the randomization requirements for the 46 remaining bits, a
hash function may be used. For example, the SHA256 hash function may hash function may be used. For example, the SHA256 hash function may
be used with input a 256 bit local secret, the "nominal" MAC Address be used with input a 256 bit local secret, the 'nominal' MAC Address
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
randomized MAC address, except the length in bits. A MAC address
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
of IPv6 link-local addresses, the length of the Interface ID MAY be
118 decimal.
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 11, line 40 skipping to change at page 12, line 13
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
in 2016. in 2016.
Human Rights Protocol Considerations review by Amelia Andersdotter.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission
of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, of IP datagrams over IEEE 802 networks", STD 43, RFC 1042,
DOI 10.17487/RFC1042, February 1988, DOI 10.17487/RFC1042, February 1988,
<https://www.rfc-editor.org/info/rfc1042>. <https://www.rfc-editor.org/info/rfc1042>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 15, line 5 skipping to change at page 15, line 30
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
http://ieeexplore.ieee.org/document/7426684/ accessed on http://ieeexplore.ieee.org/document/7426684/ accessed on
August 17th, 2017.". August 17th, 2017.".
[IEEE-1609.3]
"IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Networking Services.
Example URL http://ieeexplore.ieee.org/document/7458115/
accessed on August 17th, 2017.".
[IEEE-1609.4]
"IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Multi-Channel
Operation. Example URL
http://ieeexplore.ieee.org/document/7435228/ accessed on
August 17th, 2017.".
[IEEE-802.11-2016] [IEEE-802.11-2016]
"IEEE Standard 802.11-2016 - IEEE Standard for Information "IEEE Standard 802.11-2016 - IEEE Standard for Information
Technology - Telecommunications and information exchange Technology - Telecommunications and information exchange
between systems Local and metropolitan area networks - between systems Local and metropolitan area networks -
Specific requirements - Part 11: Wireless LAN Medium Specific requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Access Control (MAC) and Physical Layer (PHY)
Specifications. Status - Active Standard. Description Specifications. Status - Active Standard. Description
retrieved freely on September 12th, 2017, at URL retrieved freely on September 12th, 2017, at URL
https://standards.ieee.org/findstds/ https://standards.ieee.org/findstds/
standard/802.11-2016.html". standard/802.11-2016.html".
skipping to change at page 15, line 33 skipping to change at page 16, line 22
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.
-28:
o Created a new section 'Pseudonym Handling'.
o removed the 'Vehicle ID' appendix.
o improved the address generation from random MAC address.
o shortened Term IP-RSU definition.
o removed refs to two detail Clauses in IEEE documents, kept just
these latter.
-27: part 1 of addressing Human Rights review from IRTF. Removed -27: part 1 of addressing Human Rights review from IRTF. Removed
appendices F.2 and F.3. Shortened definition of IP-RSU. Removed appendices F.2 and F.3. Shortened definition of IP-RSU. Removed
reference to 1609.4. A few other small changes, see diff. reference to 1609.4. A few other small changes, see diff.
-26: moved text from SLAAC section and from Design Considerations -26: moved text from SLAAC section and from Design Considerations
appendix about privacy into a new Privacy Condiderations subsection appendix about privacy into a new Privacy Condiderations subsection
of the Security section; reformulated the SLAAC and IID sections to of the Security section; reformulated the SLAAC and IID sections to
stress only LLs can use EUI-64; removed the "GeoIP" wireshark stress only LLs can use EUI-64; removed the "GeoIP" wireshark
explanation; reformulated SLAAC and LL sections; added brief mention explanation; reformulated SLAAC and LL sections; added brief mention
of need of use LLs; clarified text about MAC address changes; dropped of need of use LLs; clarified text about MAC address changes; dropped
skipping to change at page 28, line 7 skipping to change at page 29, line 7
related to PHY, and thus has not much impact on the interface related to PHY, and thus has not much impact on the interface
between the IP layer and the MAC layer. between the IP layer and the MAC layer.
o In vehicular communications using 802.11-OCB links, there are o In vehicular communications using 802.11-OCB links, there are
strong privacy requirements with respect to addressing. While the strong privacy requirements with respect to addressing. While the
802.11-OCB standard does not specify anything in particular with 802.11-OCB standard does not specify anything in particular with
respect to MAC addresses, in these settings there exists a strong respect to MAC addresses, in these settings there exists a strong
need for dynamic change of these addresses (as opposed to the non- need for dynamic change of these addresses (as opposed to the non-
vehicular settings - real wall protection - where fixed MAC vehicular settings - real wall protection - where fixed MAC
addresses do not currently pose some privacy risks). This is addresses do not currently pose some privacy risks). This is
further described in Section 5. further described in Section 5. A relevant function is described
in documents IEEE 1609.3-2016 [IEEE-1609.3] and IEEE 1609.4-2016
[IEEE-1609.4].
Appendix D. Changes Needed on a software driver 802.11a to become a Appendix D. Changes Needed on a software driver 802.11a to become a
802.11-OCB driver 802.11-OCB driver
The 802.11p amendment modifies both the 802.11 stack's physical and The 802.11p amendment modifies both the 802.11 stack's physical and
MAC layers but all the induced modifications can be quite easily MAC layers but all the induced modifications can be quite easily
obtained by modifying an existing 802.11a ad-hoc stack. obtained by modifying an existing 802.11a ad-hoc stack.
Conditions for a 802.11a hardware to be 802.11-OCB compliant: Conditions for a 802.11a hardware to be 802.11-OCB compliant:
skipping to change at page 30, line 34 skipping to change at page 31, line 34
The networks defined by 802.11-OCB are in many ways similar to other The networks defined by 802.11-OCB are in many ways similar to other
networks of the 802.11 family. In theory, the encapsulation of IPv6 networks of the 802.11 family. In theory, the encapsulation of IPv6
over 802.11-OCB could be very similar to the operation of IPv6 over over 802.11-OCB could be very similar to the operation of IPv6 over
other networks of the 802.11 family. However, the high mobility, other networks of the 802.11 family. However, the high mobility,
strong link asymmetry and very short connection makes the 802.11-OCB strong link asymmetry and very short connection makes the 802.11-OCB
link significantly different from other 802.11 networks. Also, the link significantly different from other 802.11 networks. Also, the
automotive applications have specific requirements for reliability, automotive applications have specific requirements for reliability,
security and privacy, which further add to the particularity of the security and privacy, which further add to the particularity of the
802.11-OCB link. 802.11-OCB link.
F.1. Vehicle ID
In automotive networks it is required that each node is represented
uniquely at a certain point in time. Accordingly, a vehicle must be
identified by at least one unique identifier. The current
specification at ETSI and at IEEE 1609 identifies a vehicle by its
MAC address, which is obtained from the 802.11-OCB Network Interface
Card (NIC).
In case multiple 802.11-OCB NICs are present in one car, implicitely
multiple vehicle IDs will be generated. Additionally, some software
generates a random MAC address each time the computer boots; this
constitutes an additional difficulty.
A mechanim to uniquely identify a vehicle irrespectively to the
multiplicity of NICs, or frequent MAC address generation, is
necessary.
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode Appendix G. IEEE 802.11 Messages Transmitted in OCB mode
For information, at the time of writing, this is the list of IEEE For information, at the time of writing, this is the list of IEEE
802.11 messages that may be transmitted in OCB mode, i.e. when 802.11 messages that may be transmitted in OCB mode, i.e. when
dot11OCBActivated is true in a STA: dot11OCBActivated is true in a STA:
o The STA may send management frames of subtype Action and, if the o The STA may send management frames of subtype Action and, if the
STA maintains a TSF Timer, subtype Timing Advertisement; STA maintains a TSF Timer, subtype Timing Advertisement;
o The STA may send control frames, except those of subtype PS-Poll, o The STA may send control frames, except those of subtype PS-Poll,
 End of changes. 35 change blocks. 
77 lines changed or deleted 114 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/