draft-ietf-ipwave-ipv6-over-80211ocb-47.txt   draft-ietf-ipwave-ipv6-over-80211ocb-48.txt 
IPWAVE Working Group N. Benamar IPWAVE Working Group N. Benamar
Internet-Draft Moulay Ismail University Internet-Draft Moulay Ismail University
Intended status: Standards Track J. Haerri Intended status: Standards Track J. Haerri
Expires: December 29, 2019 Eurecom Expires: January 7, 2020 Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
June 27, 2019 July 6, 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-47 draft-ietf-ipwave-ipv6-over-80211ocb-48
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 with minimal change to one another over a single IEEE 802.11-OCB link. This support does
existing stacks. Optimizations and usage of IPv6 over more complex only require minimal changes to existing stacks. Optimizations and
scenarios is not covered and is subject of future work. usage of IPv6 over more complex scenarios is not covered in this
specification and is subject of future work.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 29, 2019. This Internet-Draft will expire on January 7, 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 3, line 9 skipping to change at page 3, line 9
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 Appendicies
Appendix B and Appendix C) with minimal change to existing stacks. Appendix A, Appendix B and Appendix C) with minimal changes to
This document describes the layering of IPv6 networking on top of the existing stacks. Moreover, the document identifies limitations of
IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame such usage. Concretly, the document describes the layering of IPv6
translation underneath. The resulting stack inherits from IPv6 over networking on top of the IEEE Std 802.11 MAC layer or an IEEE Std
Ethernet [RFC 2464] and operates over 802.11-OCB providing at least 802.3 MAC layer with a frame translation underneath. The resulting
P2P connectivity using IPv6 ND and link-local addresses. ND stack inherits from IPv6 over Ethernet [RFC 2464], but operates over
Extensions and IPWAVE optimizations for vehicular communications are 802.11-OCB to provide at least P2P (Point to Point) connectivity
not in scope. The expectation is that further specs will elaborate using IPv6 ND and link-local addresses.
for more complex vehicular networking scenarios.
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 with 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], [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. For security and privacy recommendations see movement detection. Security and privacy recommendations are
Section 5 and Section 4.4. The subnet structure is described in discussed in Section 5 and Section 4.4. The subnet structure is
Section 4.6. The movement detection on OCB links is not described described in Section 4.6. The movement detection on OCB links is
in this document. not described in this document. Likewise, ND Extensions and
IPWAVE optimizations for vehicular communications are not in
scope. The expectation is that further specifications will be
edited to cover more complex vehicular networking scenarios.
In the published literature, many documents describe aspects and The reader may refer to [I-D.ietf-ipwave-vehicular-networking] for an
problems related to running IPv6 over 802.11-OCB: overview of problems related to running IPv6 over 802.11-OCB. It is
[I-D.ietf-ipwave-vehicular-networking]. out of scope of this document to reiterate those.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer The document makes uses of the following terms: IP-OBU (Internet
situated in a vehicle such as an automobile, bicycle, or similar. It Protocol On-Board Unit): an IP-OBU denotes a computer situated in a
has at least one IP interface that runs in mode OCB of 802.11, and vehicle such as a car, bicycle, or similar. It has at least one IP
that has an "OBU" transceiver. See the definition of the term "OBU" interface that runs in mode OCB of 802.11, and that has an "OBU"
in section Appendix H. transceiver. See the definition of the term "OBU" in section
Appendix H.
IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It
has at least two distinct IP-enabled interfaces; the wireless PHY/MAC has at least two distinct IP-enabled interfaces. The wireless PHY/
layer of at least one of its IP-enabled interfaces is configured to MAC layer of at least one of its IP-enabled interfaces is configured
operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU to operate in 802.11-OCB mode. An IP-RSU communicates with the IP-
in the vehicle over 802.11 wireless link operating in OCB mode. An OBU in the vehicle over 802.11 wireless link operating in OCB mode.
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): 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: mode specified in IEEE Std 802.11-2016 when the MIB 802.11-OCB: refers to the mode specified in IEEE Std 802.11-2016 when
attribute dot11OCBActivited is true. Note: compliance with standards the MIB attribute dot11OCBActivited is 'true'. Note: compliance with
and regulations set in different countries when using the 5.9GHz standards and regulations set in different countries when using the
frequency band is required. 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. 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
vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. All links vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. All links
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 1500 octets. This value of the MTU respects the RFC2464 and is, as such, 1500 octets. This value of the MTU respects
recommendation that every link on the Internet must have a minimum the recommendation that every link on the Internet must have a
MTU of 1280 octets (stated in [RFC8200], and the recommendations minimum MTU of 1280 octets (stated in [RFC8200], and the
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 MUST use a
'priority' value of 1, which specifies the use of QoS with a 'priority' value of 1, which specifies the use of QoS with a
'Background' user priority. 'Background' user priority.
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 per RFC 2464 and then a frame implement IPv6-over-Ethernet as per RFC 2464 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 MAY 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.
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. 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 IP version 6 are described in [RFC4862]. This section interfaces in IP6 are described in [RFC4862]. This section describes
describes the formation of Interface Identifiers for IPv6 addresses the formation of Interface Identifiers for IPv6 addresses of type
of type 'Global' or 'Unique Local'. For Interface Identifiers for 'Global' or 'Unique Local'. For Interface Identifiers for IPv6
IPv6 address of type 'Link-Local' see 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 Interface Identifier, its length is 64 bits, as is the to form the IID, its length is 64 bits, as is the case of the IPv6
case of the IPv6 over Ethernet specification [RFC2464]. over Ethernet [RFC2464].
The bits in the Interface Identifier have no generic meaning and the The bits in the IID have no specific meaning and the identifier
identifier should be treated as an opaque value. The bits should be treated as an opaque value. The bits 'Universal' and
'Universal' and 'Group' in the identifier of an 802.11-OCB interface 'Group' in the identifier of an 802.11-OCB interface are significant,
are significant, as this is an IEEE link-layer address. The details as this is an IEEE link-layer address. The details of this
of this significance are described in [RFC7136]. significance are described in [RFC7136].
Semantically opaque Interface Identifiers, instead of meaningful Semantically opaque IIDs, instead of meaningful IIs derived from a
Interface Identifiers derived from a valid and meaningful MAC address valid and meaningful MAC address ([RFC2464], Section 4), help avoid
([RFC2464], section 4), help avoid certain privacy risks (see the certain privacy risks (see the risks mentioned in Section 5.1.1). If
risks mentioned in Section 5.1.1). If semantically opaque Interface semantically opaque IIDs are needed, they MAY be generated using the
Identifiers are needed, they MAY be generated using the method for method for generating semantically opaque IIDs with IPv6 Stateless
generating semantically opaque Interface Identifiers with IPv6 Address Autoconfiguration given in [RFC7217]. Typically, an opaque
Stateless Address Autoconfiguration given in [RFC7217]. Typically, IID is formed starting from identifiers different than the MAC
an opaque Interface Identifier is formed starting from identifiers addresses, and from cryptographically strong material. Thus, privacy
different than the MAC addresses, and from cryptographically strong sensitive information is absent from Interface IDs, because it is
material. Thus, privacy sensitive information is absent from impossible to calculate back the initial value from which the
Interface IDs, because it is impossible to calculate back the initial Interface ID was first generated.
value from which the Interface ID was first generated (intuitively,
it is as hard as mentally finding the square root of a number, and as
impossible as trying to use computers to identify quickly whether a
large number is prime).
Some applications that use IPv6 packets on 802.11-OCB links (among Some applications that use IPv6 packets on 802.11-OCB links (among
other link types) may benefit from IPv6 addresses whose Interface other link types) may benefit from IPv6 addresses whose IIDs don't
Identifiers don't change too often. It is RECOMMENDED to use the change too often. It is RECOMMENDED to use the mechanisms described
mechanisms described in RFC 7217 to permit the use of Stable in RFC 7217 to permit the use of Stable IIDs that do not change
Interface Identifiers that do not change within one subnet prefix. A within one subnet prefix. A possible source for the Net-Iface
possible source for the Net-Iface Parameter is a virtual interface Parameter is a virtual interface name, or logical interface name,
name, or logical interface name, that is decided by a local that is decided by a local administrator.
administrator.
4.5. Address Mapping 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 specified in Sections 6 and 7 of
[RFC2464].
4.5.1. Address Mapping -- Unicast 4.5.1. Address Mapping -- Unicast
This draft is scoped for AR and DAD per RFC 4861 [RFC4861]. This document is scoped for Address Resolution (AR) and Duplicate
Address Detection (DAD) per RFC 4861 [RFC4861].
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 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.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 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 A subnet may be formed over 802.11-OCB interfaces of vehicles that
are in close range (not by their in-vehicle interfaces). A Prefix are in close range (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 An IPv6 subnet on which Neighbor Discovery protocol (ND) can be
mapped on an OCB network iff all nodes share a single broadcast mapped on an OCB network if all nodes share a single broadcast
Domain, which is generally the case for P2P OCB links; The extension Domain, which is generally the case for P2P OCB links; The extension
to IPv6 ND operating on a subnet that covers multiple OCB links and to IPv6 ND operating on a subnet that covers multiple OCB links and
not fully overlapping (NBMA) is not in scope. not fully overlapping (NBMA) is not in scope.
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 car is another hand, the structure of the internal subnets in each vehicle
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, a (e.g., the moving subnet formed by two following vehicles is stable,
fixed IP-RSU is absent), the subnet is disconnected from the Internet a fixed IP-RSU is absent), the subnet is disconnected from the
(a default route is absent), and the addressing peers are equally Internet (i.e., a default route is absent), and the addressing peers
qualified (impossible to determine that some vehicle owns and are equally qualified (that is, it is impossible to determine that
distributes addresses to others) the use of link-local addresses is some vehicle owns and distributes addresses to others) the use of
RECOMMENDED. link-local addresses is RECOMMENDED.
The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be The baseline ND protocol [RFC4861] MUST be supported over 802.11-OCB
supported over 802.11-OCB links. Transmitting ND packets may prove links. Transmitting ND packets may prove to have some performance
to have some performance issues see Section 4.5.2, and Appendix I. issues as mentioned in Section 4.5.2, and Appendix I. These issues
These issues may be exacerbated in OCB mode. Solutions for these may be exacerbated in OCB mode. Solutions for these problems should
problems SHOULD consider the OCB mode of operation. Future solutions consider the OCB mode of operation. Future solutions to OCB should
to OCB should consider solutions for avoiding broadcast. The best of consider solutions for avoiding broadcast. The best of current
current knowledge indicates the kinds of issues that may arise with knowledge indicates the kinds of issues that may arise with ND in OCB
ND in OCB mode; they are described in Appendix I. mode; they are described in Appendix I.
Protocols like Mobile IPv6 [RFC6275] , [RFC3963] and DNAv6 [RFC6059], Protocols like Mobile IPv6 [RFC6275] , [RFC3963] and DNAv6 [RFC6059],
which depend on 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 is stripped off of all existing 802.11 link-layer
security mechanisms. There is no encryption applied below the security mechanisms. There is no encryption applied below the
network layer running on 802.11-OCB. At application layer, the IEEE network layer running on 802.11-OCB. At the application layer, the
1609.2 document [IEEE-1609.2] does provide security services for IEEE 1609.2 document [IEEE-1609.2] provides security services for
certain applications to use; application-layer mechanisms are out-of- certain applications to use; application-layer mechanisms are out-of-
scope of this document. On another hand, a security mechanism scope of this document. On another hand, a security mechanism
provided at networking layer, such as IPsec [RFC4301], may provide provided at networking layer, such as IPsec [RFC4301], may provide
data security protection to a wider range of applications. data security 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). Any attacker can therefore just
sit in the near range of vehicles, sniff the network (just set the sit in the near range of vehicles, sniff the network (just set the
interface card's frequency to the proper range) and perform attacks interface card's frequency to the proper range) and performs attacks
without needing to physically break any wall. Such a link is less without needing to physically break any wall. Such a link is less
protected than commonly used links (wired link or protected 802.11). protected than commonly used links (wired link or protected 802.11).
The potential attack vectors are: MAC address spoofing, IP address The potential attack vectors are: MAC address spoofing, IP address
and session hijacking, and privacy violation Section 5.1. A previous and session hijacking, and privacy violation Section 5.1. A previous
work at SAVI WG presents some threats [RFC6959], while SeND presented work at SAVI WG identifies some threats [RFC6959], while SeND
in [RFC3971] and [RFC3972] is a solution against address theft but it presented in [RFC3971] and [RFC3972] is a solution against address
is complex and not deployed. theft but it is complex and not deployed.
More IETF protocols are available in the toolbox of the IP security More IETF protocols are available in the toolbox of the IP security
protocol designer. Certain ETSI protocols related to security protocol designer. Some ETSI protocols related to security protocols
protocols in Intelligent Transportation Systems are described in in ITS are described in [ETSI-sec-archi].
[ETSI-sec-archi].
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 address hijacking risks. A vehicle embarking address spoofing and IP hijacking risks. A vehicle embarking an IP-
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 upThis may address of the OCB interface each time the system boots up. This may
help mitigate privacy risks to a certain level. help mitigate privacy risks to a certain level. Futhermore, for
pricavy concerns ([RFC8065]) recommends using an address generation
scheme rather than addresses generated from a fixed link-layer
address.
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
skipping to change at page 14, line 44 skipping to change at page 14, line 44
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>. <https://www.rfc-editor.org/info/rfc8064>.
[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 23, line 8 skipping to change at page 23, line 8
+-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| |
| | PLME | | | | PLME | |
| PHY Layer | PLME_SAP | | PHY Layer | PLME_SAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EtherType Protocol Discrimination Figure 2: EtherType Protocol Discrimination
Appendix E. Design Considerations Appendix E. Design Considerations
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 transportation 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.
Appendix F. IEEE 802.11 Messages Transmitted in OCB mode Appendix F. IEEE 802.11 Messages Transmitted in OCB mode
 End of changes. 42 change blocks. 
121 lines changed or deleted 128 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/