draft-ietf-ipwave-ipv6-over-80211ocb-49.txt   draft-ietf-ipwave-ipv6-over-80211ocb-50.txt 
IPWAVE Working Group N. Benamar IPWAVE Working Group N. Benamar
Internet-Draft Moulay Ismail University of Meknes Internet-Draft Moulay Ismail University of Meknes
Intended status: Standards Track J. Haerri Intended status: Standards Track J. Haerri
Expires: January 9, 2020 Eurecom Expires: January 21, 2020 Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
July 8, 2019 July 20, 2019
Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside
the Context of a Basic Service Set (IPv6-over-80211-OCB) the Context of a Basic Service Set (IPv6-over-80211-OCB)
draft-ietf-ipwave-ipv6-over-80211ocb-49 draft-ietf-ipwave-ipv6-over-80211ocb-50
Abstract Abstract
This document provides methods and settings, and describes This document provides methods and settings, and describes
limitations, for using IPv6 to communicate among nodes in range of limitations, for using IPv6 to communicate among nodes in range of
one another over a single IEEE 802.11-OCB link. This support does one another over a single IEEE 802.11-OCB link. This support does
only require minimal changes to existing stacks. Optimizations and only require minimal changes to existing stacks. Optimizations and
usage of IPv6 over more complex scenarios is not covered in this usage of IPv6 over more complex scenarios is not covered in this
specification and is subject of future work. specification and is subject of future work.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 9, 2020. This Internet-Draft will expire on January 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8
5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9
5.2. MAC Address and Interface ID Generation . . . . . . . . . 9 5.2. MAC Address and Interface ID Generation . . . . . . . . . 9
5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10 5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16 Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16
Appendix C. Changes Needed on a software driver 802.11a to Appendix C. Changes Needed on a software driver 802.11a to
become a 802.11-OCB driver . . . 21 become a 802.11-OCB driver . . . . . . . . . . . . . 21
Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22 Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22
Appendix E. Design Considerations . . . . . . . . . . . . . . . 23 Appendix E. Design Considerations . . . . . . . . . . . . . . . 23
Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23
Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23 Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23
G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24 G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24
G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27 G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27
Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29 Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29
Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless
Links . . . . . . . . . . . . . . . . . . . . . . . 30 Links . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document provides a baseline with limitations for using IPv6 to This document provides a baseline with limitations for using IPv6 to
communicate among nodes in range of one another over a single IEEE communicate among nodes in range of one another over a single IEEE
802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, 802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A,
Appendix B and Appendix C) with minimal changes to existing stacks. Appendix B and Appendix C) with minimal changes to existing stacks.
Moreover, the document identifies limitations of such usage. Moreover, the document identifies limitations of such usage.
Concretly, the document describes the layering of IPv6 networking on Concretely, the document describes the layering of IPv6 networking on
top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer
with a frame translation underneath. The resulting stack inherits with a frame translation underneath. The resulting stack inherits
from IPv6 over Ethernet [RFC 2464], but operates over 802.11-OCB to from IPv6 over Ethernet [RFC2464], but operates over 802.11-OCB to
provide at least P2P (Point to Point) connectivity using IPv6 ND and provide at least P2P (Point to Point) connectivity using IPv6 ND and
link-local addresses. link-local addresses.
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 with the following exceptions: operating on Ethernet with the following 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. The operation of IP on Ethernet is 802.11 than on Ethernet. The operation of IP on Ethernet is
described in [RFC1042], [RFC2464] . described in [RFC1042] and [RFC2464].
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. Security and privacy recommendations are movement detection. Security and privacy recommendations are
discussed in Section 5 and Section 4.4. The subnet structure is discussed in Section 5 and Section 4.4. The subnet structure is
described in Section 4.6. The movement detection on OCB links is described in Section 4.6. The movement detection on OCB links is
not described in this document. Likewise, ND Extensions and not described in this document. Likewise, ND Extensions and
IPWAVE optimizations for vehicular communications are not in IPWAVE optimizations for vehicular communications are not in
scope. The expectation is that further specifications will be scope. The expectation is that further specifications will be
edited to cover more complex vehicular networking scenarios. edited to cover more complex vehicular networking scenarios.
skipping to change at page 4, line 22 skipping to change at page 4, line 22
An IP-RSU is similar to an Access Network Router (ANR) defined in An IP-RSU is similar to an Access Network Router (ANR) defined in
[RFC3753], and a Wireless Termination Point (WTP) defined in [RFC3753], and a Wireless Termination Point (WTP) defined in
[RFC5415]. [RFC5415].
OCB (outside the context of a basic service set - BSS): is a mode of OCB (outside the context of a basic service set - BSS): is 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: refers to the mode specified in IEEE Std 802.11-2016 when 802.11-OCB: refers to the mode specified in IEEE Std 802.11-2016 when
the MIB attribute dot11OCBActivited is 'true'. Note: compliance with the MIB attribute dot11OCBActivited is 'true'.
standards and regulations set in different countries when using the
5.9GHz frequency band is required.
3. Communication Scenarios where IEEE 802.11-OCB Links are Used 3. Communication Scenarios where IEEE 802.11-OCB Links are Used
The IEEE 802.11-OCB networks are used for vehicular communications, The IEEE 802.11-OCB networks are used for vehicular communications,
as 'Wireless Access in Vehicular Environments'. In particular, we as 'Wireless Access in Vehicular Environments'. In particular, we
refer the reader to [I-D.ietf-ipwave-vehicular-networking], that refer the reader to [I-D.ietf-ipwave-vehicular-networking], that
lists some scenarios and requirements for IP in Intelligent lists some scenarios and requirements for IP in Intelligent
Transportation Systems (ITS). Transportation Systems (ITS).
The link model is the following: STA --- 802.11-OCB --- STA. In The link model is the following: STA --- 802.11-OCB --- STA. In
skipping to change at page 4, line 46 skipping to change at page 4, line 44
are assumed to be P2P and multiple links can be on one radio are assumed to be P2P and multiple links can be on one radio
interface. While 802.11-OCB is clearly specified, and a legacy IPv6 interface. While 802.11-OCB is clearly specified, and a legacy IPv6
stack can operate on such links, the use of the operating environment stack can operate on such links, the use of the operating environment
(vehicular networks) brings in new perspectives. (vehicular networks) brings in new perspectives.
4. IPv6 over 802.11-OCB 4. IPv6 over 802.11-OCB
4.1. Maximum Transmission Unit (MTU) 4.1. Maximum Transmission Unit (MTU)
The default MTU for IP packets on 802.11-OCB is inherited from The default MTU for IP packets on 802.11-OCB is inherited from
RFC2464 and is, as such, 1500 octets. This value of the MTU respects [RFC2464] and is, as such, 1500 octets. This value of the MTU
the recommendation that every link on the Internet must have a respects the recommendation that every link on the Internet must have
minimum MTU of 1280 octets (stated in [RFC8200], and the a minimum MTU of 1280 octets (stated in [RFC8200], and the
recommendations therein, especially with respect to fragmentation). recommendations therein, especially 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 802.11 spec frames whose format is specified in IEEE 802.11 spec
[IEEE-802.11-2016]. [IEEE-802.11-2016].
The IPv6 packet transmitted on 802.11-OCB are immediately preceded by The IPv6 packet transmitted on 802.11-OCB are immediately preceded by
a Logical Link Control (LLC) header and an 802.11 header. In the LLC a Logical Link Control (LLC) header and an 802.11 header. In the LLC
header, and in accordance with the EtherType Protocol Discrimination header, and in accordance with the EtherType Protocol Discrimination
(EPD, see Appendix D), the value of the Type field MUST be set to (EPD, see Appendix D), the value of the Type field MUST be set to
0x86DD (IPv6). The mapping to the 802.11 data service MUST use a 0x86DD (IPv6). The mapping to the 802.11 data service SHOULD use a
'priority' value of 1, which specifies the use of QoS with a 'priority' value of 1 (QoS with a 'Background' user priority),
'Background' user priority. reserving higher priority values for safety-critical and time-
sensitive traffic, including the ones listed in [ETSI-sec-archi].
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 IPv6-over-Ethernet as per RFC 2464 and then a frame implement IPv6-over-Ethernet as per [RFC2464] and then a frame
translation from 802.3 to 802.11 in order to minimize the code translation from 802.3 to 802.11 in order to minimize the code
changes. changes.
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 can be formed using an addresses only the IPv6 link-local addresses can be formed using an
EUI-64 identifier, in particular during transition time. EUI-64 identifier, in particular during transition time.
skipping to change at page 5, line 44 skipping to change at page 5, line 45
used to form an IPv6 link-local address on Ethernet links. Moreover, used to form an IPv6 link-local address on Ethernet links. Moreover,
whether or not the interface identifier is derived from the EUI-64 A whether or not the interface identifier is derived from the EUI-64 A
identifier, its length is 64 bits as is the case for Ethernet identifier, its length is 64 bits as is the case for Ethernet
[RFC2464]. [RFC2464].
4.4. Stateless Autoconfiguration 4.4. Stateless Autoconfiguration
The steps a host takes in deciding how to autoconfigure its The steps a host takes in deciding how to autoconfigure its
interfaces in IPv6 are described in [RFC4862]. This section interfaces in IPv6 are described in [RFC4862]. This section
describes the formation of Interface Identifiers for IPv6 addresses describes the formation of Interface Identifiers for IPv6 addresses
of type 'Global' or 'Unique Local'. For Interface Identifiers for of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6
IPv6 address of type 'Link-Local' are discussed in Section 4.3. address of type 'Link-Local' are discussed in Section 4.3.
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, in particular for IPv6 link-local addresses. Regardless of how time, in particular for IPv6 link-local addresses. Regardless of how
to form the IID, its length is 64 bits, as is the case of the IPv6 to form the IID, its length is 64 bits, similarely to IPv6 over
over Ethernet [RFC2464]. Ethernet [RFC2464].
The bits in the IID have no specific meaning and the identifier The bits in the IID have no specific meaning and the identifier
should be treated as an opaque value. The bits 'Universal' and should be treated as an opaque value. The bits 'Universal' and
'Group' in the identifier of an 802.11-OCB interface are significant, 'Group' in the identifier of an 802.11-OCB interface are significant,
as this is an IEEE link-layer address. The details of this as this is an IEEE link-layer address. The details of this
significance are described in [RFC7136]. significance are described in [RFC7136].
Semantically opaque IIDs, instead of meaningful IIDs derived from a Semantically opaque IIDs, instead of meaningful IIDs derived from a
valid and meaningful MAC address ([RFC2464], Section 4), help avoid valid and meaningful MAC address ([RFC2464], Section 4), help avoid
certain privacy risks (see the risks mentioned in Section 5.1.1). If certain privacy risks (see the risks mentioned in Section 5.1.1). If
semantically opaque IIDs are needed, they MAY be generated using the semantically opaque IIDs are needed, they may be generated using the
method for generating semantically opaque IIDs with IPv6 Stateless method for generating semantically opaque IIDs with IPv6 Stateless
Address Autoconfiguration given in [RFC7217]. Typically, an opaque Address Autoconfiguration given in [RFC7217]. Typically, an opaque
IID is formed starting from identifiers different than the MAC IID is formed starting from identifiers different than the MAC
addresses, and from cryptographically strong material. Thus, privacy addresses, and from cryptographically strong material. Thus, privacy
sensitive information is absent from Interface IDs, because it is sensitive information is absent from Interface IDs, because it is
impossible to calculate back the initial value from which the impossible to calculate back the initial value from which the
Interface ID was first generated. Interface ID was first generated.
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 IIDs don't other link types) may benefit from IPv6 addresses whose IIDs don't
skipping to change at page 6, line 46 skipping to change at page 6, line 48
4.5.1. Address Mapping -- Unicast 4.5.1. Address Mapping -- Unicast
This document is scoped for Address Resolution (AR) and Duplicate This document is scoped for Address Resolution (AR) and Duplicate
Address Detection (DAD) per [RFC4862]. Address Detection (DAD) per [RFC4862].
4.5.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 there 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.ietf-mboned-ieee802-mcast-problems]. These issues may be [I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be
exacerbated in OCB mode.A A future improvement to this specification exacerbated in OCB mode.A A future improvement to this specification
should consider solutions for these problems. should consider solutions for these problems.
4.6. Subnet Structure 4.6. Subnet Structure
A subnet may be formed over 802.11-OCB interfaces of vehicles that When vehicles are in close range, a subnet may be formed over
are in close range (not by their in-vehicle interfaces). A Prefix 802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix
List conceptual data structure ([RFC4861] Section 5.1) is maintained List conceptual data structure ([RFC4861] Section 5.1) is maintained
for each 802.11-OCB interface. for each 802.11-OCB interface.
An IPv6 subnet on which Neighbor Discovery protocol (ND) can be IPv6 Neighbor Discovery protocol (ND) requires reflexive properties
mapped on an OCB network if all nodes share a single broadcast (bidirectional connectivity) which is generally, though not always,
Domain, which is generally the case for P2P OCB links; The extension the case for P2P OCB links. IPv6 ND also requires transitive
to IPv6 ND operating on a subnet that covers multiple OCB links and properties for DAD and AR, so an IPv6 subnet can be mapped on an OCB
not fully overlapping (NBMA) is not in scope. network only if all nodes in the network share a single physical
broadcast domain. The extension to IPv6 ND operating on a subnet
that covers multiple OCB links and not fully overlapping (NBMA) is
not in scope. Finally, IPv6 ND requires a permanent connectivity of
all nodes in the subnet to defend their addresses, in other words
very stable network conditions.
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 hidden terminal effects influenced by the mobility of vehicles: the hidden terminal effects
appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc'
networks with an addressing model as described in [RFC5889]. On networks with an addressing model as described in [RFC5889]. On
another hand, the structure of the internal subnets in each vehicle another hand, the structure of the internal subnets in each vehicle
is relatively stable. is 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, (e.g., the moving subnet formed by two following vehicles is stable,
a fixed IP-RSU is absent), the subnet is disconnected from the a fixed IP-RSU is absent), the subnet is disconnected from the
Internet (i.e., a default route is absent), and the addressing peers Internet (i.e., a default route is absent), and the addressing peers
are equally qualified (that is, it is impossible to determine that are equally qualified (that is, it is impossible to determine that
some vehicle owns and distributes addresses to others) the use of some vehicle owns and distributes addresses to others) the use of
link-local addresses is RECOMMENDED. link-local addresses is RECOMMENDED.
skipping to change at page 8, line 13 skipping to change at page 8, line 18
which depend on a timely movement detection, might need additional which depend on a timely movement detection, might need additional
tuning work to handle the lack of link-layer notifications during tuning work to handle the lack of link-layer notifications during
handover. This is for further study. handover. 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
out for the general case of IPv6 may also be carried out for IPv6 out for the general case of IPv6 may also be carried out for IPv6
operating over 802.11-OCB. operating over 802.11-OCB.
The OCB operation is stripped off of all existing 802.11 link-layer The OCB operation does not use existing 802.11 link-layer security
security mechanisms. There is no encryption applied below the mechanisms. There is no encryption applied below the network layer
network layer running on 802.11-OCB. At the application layer, the running on 802.11-OCB. At the application layer, the IEEE 1609.2
IEEE 1609.2 document [IEEE-1609.2] provides security services for document [IEEE-1609.2] provides security services for certain
certain applications to use; application-layer mechanisms are out-of- applications to use; application-layer mechanisms are out of scope of
scope of this document. On another hand, a security mechanism this document. On another hand, a security mechanism provided at
provided at networking layer, such as IPsec [RFC4301], may provide networking layer, such as IPsec [RFC4301], may provide data security
data security protection to a wider range of applications. protection to a wider range of applications.
802.11-OCB does not provide any cryptographic protection, because it 802.11-OCB does not provide any cryptographic protection, because it
operates outside the context of a BSS (no Association Request/ operates outside the context of a BSS (no Association Request/
Response, no Challenge messages). Any attacker can therefore just Response, no Challenge messages). Therefore, an attacker can sniff
sit in the near range of vehicles, sniff the network (just set the or inject traffic while within range of a vehicle or IP-RSU (by
interface card's frequency to the proper range) and performs attacks setting an interface carda€™s frequency to the proper
without needing to physically break any wall. Such a link is less range). Also, an attacker may not heed to legal limits for radio
protected than commonly used links (wired link or protected 802.11). power and can use a very sensitive directional antenna; if attackers
wishe to attack a given exchange they do not necessarily need to be
The potential attack vectors are: MAC address spoofing, IP address in close physical proximity. Hence, such a link is less protected
and session hijacking, and privacy violation Section 5.1. A previous than commonly used links (wired link or protected 802.11).
work at SAVI WG identifies some threats [RFC6959], while SeND
presented in [RFC3971] and [RFC3972] is a solution against address
theft but it is complex and not deployed.
More IETF protocols are available in the toolbox of the IP security Therefore, any node can join a subnet, directly communicate with any
protocol designer. Some ETSI protocols related to security protocols nodes on the subset to include potentially impersonating another
in ITS are described in [ETSI-sec-archi]. node.A This design allows for a number of threats outlined in
Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971],
[RFC3972] is a solution that can address Spoof-Based Attack Vectors.
5.1. Privacy Considerations 5.1. Privacy Considerations
As with all Ethernet and 802.11 interface identifiers ([RFC7721]), As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
the identifier of an 802.11-OCB interface may involve privacy, MAC the identifier of an 802.11-OCB interface may involve privacy, MAC
address spoofing and IP hijacking risks. A vehicle embarking an IP- address spoofing and IP hijacking risks. A vehicle embarking an IP-
OBU whose egress interface is 802.11-OCB may expose itself to OBU whose egress interface is 802.11-OCB may expose itself to
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.4. An example of change policy is to change the MAC Section 4.4. An example of change policy is to change the MAC
address of the OCB interface each time the system boots up. This may address of the OCB interface each time the system boots up. This may
help mitigate privacy risks to a certain level. Futhermore, for help mitigate privacy risks to a certain level. Futhermore, for
pricavy concerns ([RFC8065]) recommends using an address generation pricavy concerns, ([RFC8065]) recommends using an address generation
scheme rather than addresses generated from a fixed link-layer scheme rather than addresses generated from a fixed link-layer
address. address. However, there are some specificities related to vehicles.
Since roaming is an important characteristic of moving vehicles, the
use of the same Link-Local Address over time can indicate the
presence of the same vehicle in different places and thus leads to
location tracking. Hence, a vehicle should get hints about a change
of environment (e.g. , engine running, GPS, etc..) and renew the IID
in its LLAs.
5.1.1. Privacy Risks of Meaningful info in Interface IDs 5.1.1. Privacy Risks of Meaningful info in Interface IDs
The privacy risks of using MAC addresses displayed in Interface The privacy risks of using MAC addresses displayed in Interface
Identifiers are important. The IPv6 packets can be captured easily Identifiers are important. The IPv6 packets can be captured easily
in the Internet and on-link in public roads. For this reason, an in the Internet and on-link in public roads. For this reason, an
attacker may realize many attacks on privacy. One such attack on attacker may realize many attacks on privacy. One such attack on
802.11-OCB is to capture, store and correlate Company ID information 802.11-OCB is to capture, store and correlate Company ID information
present in MAC addresses of many cars (e.g. listen for Router present in MAC addresses of many cars (e.g. listen for Router
Advertisements, or other IPv6 application data packets, and record Advertisements, or other IPv6 application data packets, and record
the value of the source address in these packets). Further the value of the source address in these packets). Further
correlation of this information with other data captured by other correlation of this information with other data captured by other
means, or other visual information (car color, others) MAY constitute means, or other visual information (car color, others) may constitute
privacy risks. 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 Implementations should use a policy dictating when the MAC address is
802.11-OCB interface is to-be-determined. For more information on changed on the 802.11-OCB interface. For more information on the
the motivation of this policy please refer to the privacy discussion motivation of this policy please refer to the privacy discussion in
in Appendix B. Appendix B.
A 'randomized' MAC address has the following characteristics: A 'randomized' MAC address has the following characteristics:
o Bit "Local/Global" set to "locally admninistered". o Bit "Local/Global" set to "locally admninistered".
o Bit "Unicast/Multicast" set to "Unicast". o Bit "Unicast/Multicast" set to "Unicast".
o 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 A randomized Interface ID has the same characteristics of a
randomized MAC address, except the length in bits. An Interface ID randomized MAC address, except the length in bits.
SHOULD be of length specified in other documents.
5.3. Pseudonym Handling 5.3. Pseudonym Handling
The demand for privacy protection of vehicles' and drivers' The demand for privacy protection of vehicles' and drivers'
identities, which could be granted by using a pseudonym or alias identities, which could be granted by using a pseudonym or alias
identity at the same time, may hamper the required confidentiality of identity at the same time, may hamper the required confidentiality of
messages and trust between participants - especially in safety messages and trust between participants - especially in safety
critical vehicular communication. critical vehicular communication.
o Particular challenges arise when the pseudonymization mechanism o Particular challenges arise when the pseudonymization mechanism
skipping to change at page 11, line 18 skipping to change at page 11, line 25
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Alexandre Petrescu for initiating The authors would like to thank Alexandre Petrescu for initiating
this work and for being the lead author until the version 43 of this this work and for being the lead author until the version 43 of this
draft. draft.
The authors would like to thank Pascal Thubert for reviewing, The authors would like to thank Pascal Thubert for reviewing,
proofreading and suggesting modifications of this document. proofreading and suggesting modifications of this document.
The authors would like to thank Mohamed Boucadair for proofreading
and suggesting modifications of this document.
The authors would like to thank Witold Klaudel, Ryuji Wakikawa, The authors would like to thank Witold Klaudel, Ryuji Wakikawa,
Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan
Romascanu, Konstantin Khait, Ralph Droms, Richard '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,
skipping to change at page 12, line 4 skipping to change at page 12, line 12
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. Human Rights Protocol Considerations review by Amelia Andersdotter.
9. References 9. References
9.1. Normative References 9.1. Normative References
[IEEE-802.11-2016]
"IEEE Standard 802.11-2016 - IEEE Standard for Information
Technology - Telecommunications and information exchange
between systems Local and metropolitan area networks -
Specific requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications. Status - Active Standard. Description
retrieved freely; the document itself is also freely
available, but with some difficulty (requires
registration); description and document retrieved on April
8th, 2019, starting from URL
https://standards.ieee.org/findstds/
standard/802.11-2016.html".
[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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>. <https://www.rfc-editor.org/info/rfc2464>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
<https://www.rfc-editor.org/info/rfc5374>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415, (CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009, DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>. <https://www.rfc-editor.org/info/rfc5415>.
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059,
DOI 10.17487/RFC6059, November 2010, DOI 10.17487/RFC6059, November 2010,
<https://www.rfc-editor.org/info/rfc6059>. <https://www.rfc-editor.org/info/rfc6059>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959,
DOI 10.17487/RFC6959, May 2013,
<https://www.rfc-editor.org/info/rfc6959>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>. October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>. February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<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>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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
skipping to change at page 14, line 49 skipping to change at page 14, line 40
Security; ITS communications security architecture and Security; ITS communications security architecture and
security management, November 2016. Downloaded on security management, November 2016. Downloaded on
September 9th, 2017, freely available from ETSI website at September 9th, 2017, freely available from ETSI website at
URL http://www.etsi.org/deliver/ URL http://www.etsi.org/deliver/
etsi_ts/102900_102999/102940/01.02.01_60/ etsi_ts/102900_102999/102940/01.02.01_60/
ts_102940v010201p.pdf". ts_102940v010201p.pdf".
[I-D.ietf-ipwave-vehicular-networking] [I-D.ietf-ipwave-vehicular-networking]
Jeong, J., "IP Wireless Access in Vehicular Environments Jeong, J., "IP Wireless Access in Vehicular Environments
(IPWAVE): Problem Statement and Use Cases", draft-ietf- (IPWAVE): Problem Statement and Use Cases", draft-ietf-
ipwave-vehicular-networking-09 (work in progress), May ipwave-vehicular-networking-11 (work in progress), July
2019. 2019.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-05 (work Media", draft-ietf-mboned-ieee802-mcast-problems-06 (work
in progress), April 2019. in progress), July 2019.
[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-1609.3]
"IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access
skipping to change at page 15, line 31 skipping to change at page 15, line 25
Example URL http://ieeexplore.ieee.org/document/7458115/ Example URL http://ieeexplore.ieee.org/document/7458115/
accessed on August 17th, 2017.". accessed on August 17th, 2017.".
[IEEE-1609.4] [IEEE-1609.4]
"IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Multi-Channel in Vehicular Environments (WAVE) -- Multi-Channel
Operation. Example URL Operation. Example URL
http://ieeexplore.ieee.org/document/7435228/ accessed on http://ieeexplore.ieee.org/document/7435228/ accessed on
August 17th, 2017.". August 17th, 2017.".
[IEEE-802.11-2016]
"IEEE Standard 802.11-2016 - IEEE Standard for Information
Technology - Telecommunications and information exchange
between systems Local and metropolitan area networks -
Specific requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications. Status - Active Standard. Description
retrieved freely; the document itself is also freely
available, but with some difficulty (requires
registration); description and document retrieved on April
8th, 2019, starting from URL
https://standards.ieee.org/findstds/
standard/802.11-2016.html".
[IEEE-802.11p-2010] [IEEE-802.11p-2010]
"IEEE Std 802.11p (TM)-2010, IEEE Standard for Information "IEEE Std 802.11p (TM)-2010, 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 Access Specific requirements, Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications, Control (MAC) and Physical Layer (PHY) Specifications,
Amendment 6: Wireless Access in Vehicular Environments; Amendment 6: Wireless Access in Vehicular Environments;
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,
skipping to change at page 16, line 35 skipping to change at page 16, line 9
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959,
DOI 10.17487/RFC6959, May 2013,
<https://www.rfc-editor.org/info/rfc6959>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>.
Appendix A. 802.11p Appendix A. 802.11p
The term "802.11p" is an earlier definition. The behaviour of The term "802.11p" is an earlier definition. The behaviour of
"802.11p" networks is rolled in the document IEEE Std 802.11-2016. "802.11p" networks is rolled in the document IEEE Std 802.11-2016.
In that document the term 802.11p disappears. Instead, each 802.11p In that document the term 802.11p disappears. Instead, each 802.11p
feature is conditioned by the IEEE Management Information Base (MIB) feature is conditioned by the IEEE Management Information Base (MIB)
attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated
is set to true the IEEE Std 802.11-OCB state is activated. For is set to true the IEEE Std 802.11-OCB state is activated. For
example, an 802.11 STAtion operating outside the context of a basic example, an 802.11 STAtion operating outside the context of a basic
service set has the OCBActivated flag set. Such a station, when it service set has the OCBActivated flag set. Such a station, when it
skipping to change at page 18, line 44 skipping to change at page 18, line 44
true, then it is actually referring to OCB aspects introduced to true, then it is actually referring to OCB aspects introduced to
802.11. 802.11.
In order to delineate the aspects introduced by 802.11-OCB to 802.11, In order to delineate the aspects introduced by 802.11-OCB to 802.11,
we refer to the earlier [IEEE-802.11p-2010]. The amendment is we refer to the earlier [IEEE-802.11p-2010]. The amendment is
concerned with vehicular communications, where the wireless link is concerned with vehicular communications, where the wireless link is
similar to that of Wireless LAN (using a PHY layer specified by similar to that of Wireless LAN (using a PHY layer specified by
802.11a/b/g/n), but which needs to cope with the high mobility factor 802.11a/b/g/n), but which needs to cope with the high mobility factor
inherent in scenarios of communications between moving vehicles, and inherent in scenarios of communications between moving vehicles, and
between vehicles and fixed infrastructure deployed along roads. between vehicles and fixed infrastructure deployed along roads.
While 'p' is a letter identifying the Ammendment, just like 'a, b, g' While 'p' is a letter identifying the Amendment, just like 'a, b, g'
and 'n' are, 'p' is concerned more with MAC modifications, and a and 'n' are, 'p' is concerned more with MAC modifications, and a
little with PHY modifications; the others are mainly about PHY little with PHY modifications; the others are mainly about PHY
modifications. It is possible in practice to combine a 'p' MAC with modifications. It is possible in practice to combine a 'p' MAC with
an 'a' PHY by operating outside the context of a BSS with OFDM at an 'a' PHY by operating outside the context of a BSS with OFDM at
5.4GHz and 5.9GHz. 5.4GHz and 5.9GHz.
The 802.11-OCB links are specified to be compatible as much as The 802.11-OCB links are specified to be compatible as much as
possible with the behaviour of 802.11a/b/g/n and future generation possible with the behaviour of 802.11a/b/g/n and future generation
IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer
offers practically the same interface to IP as the 802.11a/b/g/n and offers practically the same interface to IP as the 802.11a/b/g/n and
skipping to change at page 31, line 15 skipping to change at page 31, line 15
claims its address, which is done by sending a NS multicast message, claims its address, which is done by sending a NS multicast message,
and can hear any future claim for that address by another party and can hear any future claim for that address by another party
within the scope for the duration of the address ownership. within the scope for the duration of the address ownership.
In the case of OCB, there is a potentially a need to define a scope In the case of OCB, there is a potentially a need to define a scope
that is compatible with DAD, and that cannot be the set of nodes that that is compatible with DAD, and that cannot be the set of nodes that
a transmitter can reach at a particular time, because that set varies a transmitter can reach at a particular time, because that set varies
all the time and does not meet the DAD requirements for a link local all the time and does not meet the DAD requirements for a link local
address that could possibly be used anytime, anywhere. The generic address that could possibly be used anytime, anywhere. The generic
expectation of a reliable multicast is not ensured, and the operation expectation of a reliable multicast is not ensured, and the operation
of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot of DAD and AR (Address Resolution) as specified by RFC 4861 cannot be
be guaranteed. Moreoever, multicast transmissions that rely on guaranteed. Moreover, multicast transmissions that rely on broadcast
broadcast are not only unreliable but are also often detrimental to are not only unreliable but are also often detrimental to unicast
unicast traffic (see [draft-ietf-mboned-ieee802-mcast-problems]). traffic (see [draft-ietf-mboned-ieee802-mcast-problems]).
Early experience indicates that it should be possible to exchange Early experience indicates that it should be possible to exchange
IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR
(Address Resolution) in good conditions. In the absence of a correct (Address Resolution) in good conditions. In the absence of a correct
DAD operation, a node that relies only on IPv6 ND for AR and DAD over DAD operation, a node that relies only on IPv6 ND for AR and DAD over
OCB should ensure that the addresses that it uses are unique by means OCB should ensure that the addresses that it uses are unique by means
others than DAD. It must be noted that deriving an IPv6 address from others than DAD. It must be noted that deriving an IPv6 address from
a globally unique MAC address has this property but may yield privacy a globally unique MAC address has this property but may yield privacy
issues. issues.
skipping to change at page 31, line 46 skipping to change at page 31, line 46
Layer address using a unicast exchange. Layer address using a unicast exchange.
RFC 8505 also enables a router (acting as a 6LR) to own a prefix and RFC 8505 also enables a router (acting as a 6LR) to own a prefix and
act as a registrar (acting as a 6LBR) for addresses within the act as a registrar (acting as a 6LBR) for addresses within the
associated subnet. A peer host (acting as a 6LN) registers an associated subnet. A peer host (acting as a 6LN) registers an
address derived from that prefix and can use it for the lifetime of address derived from that prefix and can use it for the lifetime of
the registration. The prefix is advertised as not onlink, which the registration. The prefix is advertised as not onlink, which
means that the 6LN uses the 6LR to relay its packets within the means that the 6LN uses the 6LR to relay its packets within the
subnet, and participation to the subnet is constrained to the time of subnet, and participation to the subnet is constrained to the time of
reachability to the 6LR. Note that RSU that provides internet reachability to the 6LR. Note that RSU that provides internet
connectivity MAY announce a default router preference [RFC 4191], connectivity MAY announce a default router preference [RFC4191],
whereas a car that does not provide that connectivity MUST NOT do so. whereas a car that does not provide that connectivity MUST NOT do so.
This operation presents similarities with that of an access point, This operation presents similarities with that of an access point,
but at Layer-3. This is why RFC 8505 well-suited for wireless in but at Layer-3. This is why RFC 8505 well-suited for wireless in
general. general.
Support of RFC 8505 may be implemented on OCB. OCB nodes that Support of RFC 8505 may be implemented on OCB. OCB nodes that
support RFC 8505 SHOULD support the 6LN operation in order to act as support RFC 8505 SHOULD support the 6LN operation in order to act as
a host, and may support the 6LR and 6LBR operations in order to act a host, and may support the 6LR and 6LBR operations in order to act
as a router and in particular own a prefix that can be used by RFC as a router and in particular own a prefix that can be used by RFC
8505-compliant hosts for address autoconfiguration and registration. 8505-compliant hosts for address autoconfiguration and registration.
 End of changes. 49 change blocks. 
127 lines changed or deleted 124 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/