draft-ietf-ipwave-ipv6-over-80211ocb-45.txt   draft-ietf-ipwave-ipv6-over-80211ocb-46.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: October 31, 2019 Eurecom Expires: December 9, 2019 Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
April 29, 2019 June 7, 2019
Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside
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-45 draft-ietf-ipwave-ipv6-over-80211ocb-46
Abstract Abstract
In order to transmit IPv6 packets on IEEE 802.11 networks running This document provides methods and settings, and describes
outside the context of a basic service set (OCB, earlier "802.11p") limitations, for using IPv6 to communicate among nodes in range of
there is a need to define a few parameters such as the supported one another over a single IEEE 802.11-OCB link with minimal change to
Maximum Transmission Unit size on the 802.11-OCB link, the header existing stacks. Optimizations and usage of IPv6 over more complex
format preceding the IPv6 header, the Type value within it, and scenarios is not covered and is subject of future work.
others. This document describes how IPv6 (including addressing and
basic ND) can be used to communicate among nodes in range of one
another over IEEE 802.11-OCB. Optimizations and usage of IPv6 over
more complex scenarios is not covered 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 October 31, 2019. This Internet-Draft will expire on December 9, 2019.
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 27 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4
4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4
4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4
4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 4
4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5
4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5
4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6
4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6
4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6
4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9
5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 10 5.2. MAC Address and Interface ID Generation . . . . . . . . . 9
5.2. MAC Address and Interface ID Generation . . . . . . . . . 11 5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10
5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16
Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Changes Needed on a software driver 802.11a to
Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 28 become a 802.11-OCB driver . . . 21
Appendix D. Changes Needed on a software driver 802.11a to Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22
become a 802.11-OCB driver . . . 32 Appendix E. Design Considerations . . . . . . . . . . . . . . . 23
Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 33 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23
Appendix F. Design Considerations . . . . . . . . . . . . . . . 34 Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 34 G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24
Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 35 G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27
H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 36 Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29
H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38 Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless
Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40 Links . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Links . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document describes the transmission of IPv6 packets on IEEE Std This document provides a baseline with limitations for using IPv6 to
802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see communicate among nodes in range of one another over a single IEEE
Appendix B, Appendix C and Appendix D). This involves the layering 802.11-OCB link [IEEE-802.11-2016] (a.k.a "802.11p" see Appendix A,
of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC Appendix B and Appendix C) with minimal change to existing stacks.
layer. Compared to running IPv6 over the Ethernet MAC layer, there This document describes the layering of IPv6 networking on top of the
is no modification expected to IEEE Std 802.11 MAC and Logical Link IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame
sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC translation underneath. The resulting stack operates over 802.11-OCB
layer. and provides at least P2P connectivity using IPv6 ND and link-local
addresses. ND Extensions and IPWAVE optimizations for vehicular
communications are not in scope. The expectation is that further
specs will elaborate 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, but there are two kinds of exceptions:
o Exceptions due to different operation of IPv6 network layer on o Exceptions due to different operation of IPv6 network layer on
802.11 than on Ethernet. To satisfy these exceptions, this 802.11 than on Ethernet. The operation of IP on Ethernet is
document describes an Ethernet Adaptation Layer between Ethernet
headers and 802.11 headers. The Ethernet Adaptation Layer is
described Section 4.2.1. 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. For security and privacy recommendations see
Section 5 and Section 4.4. The subnet structure is described in Section 5 and Section 4.4. The subnet structure is described in
Section 4.6. The movement detection on OCB links is not described Section 4.6. The movement detection on OCB links is not described
in this document. in this document.
In the published literature, many documents describe aspects and In the published literature, many documents describe aspects and
skipping to change at page 4, line 9 skipping to change at page 3, line 49
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 IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer
situated in a vehicle such as an automobile, bicycle, or similar. It situated in a vehicle such as an automobile, bicycle, or similar. It
has at least one IP interface that runs in mode OCB of 802.11, and has at least one IP interface that runs in mode OCB of 802.11, and
that has an "OBU" transceiver. See the definition of the term "OBU" that has an "OBU" transceiver. See the definition of the term "OBU"
in section Appendix I. in section Appendix 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/MAC
layer of at least one of its IP-enabled interfaces is configured to layer of at least one of its IP-enabled interfaces is configured to
operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU
in the vehicle over 802.11 wireless link operating in OCB mode. An in the vehicle over 802.11 wireless link operating in OCB mode. An
IP-RSU is similar to an Access Network Router (ANR) defined in 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].
skipping to change at page 4, line 33 skipping to change at page 4, line 24
confidentiality. confidentiality.
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
attribute dot11OCBActivited is true. Note: compliance with standards attribute dot11OCBActivited is true. Note: compliance with standards
and regulations set in different countries when using the 5.9GHz and regulations set in different countries when using the 5.9GHz
frequency band is required. frequency band is required.
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'. The IP communication as 'Wireless Access in Vehicular Environments'. In particular, we
scenarios for these environments have been described in several refer the reader to [I-D.ietf-ipwave-vehicular-networking], that
documents; in particular, we refer the reader to lists some scenarios and requirements for IP in Intelligent
[I-D.ietf-ipwave-vehicular-networking], that lists some scenarios and Transportation Systems.
requirements for IP in Intelligent Transportation Systems.
The link model is the following: STA --- 802.11-OCB --- STA. In The link model is the following: STA --- 802.11-OCB --- STA. In
vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. All links
802.11-OCB is clearly specified, and the use of IPv6 over such link are assumed to be P2P and multiple links can be on one radio
is not radically new, the operating environment (vehicular networks) interface. While 802.11-OCB is clearly specified, and a legacy IPv6
brings in new perspectives. stack can operate on such links, the use of the operating environment
(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 MUST be 1500 octets. It The default MTU for IP packets on 802.11-OCB is inherited from
is the same value as IPv6 packets on Ethernet links, as specified in RFC2464 and is 1500 octets. This value of the MTU respects the
[RFC2464]. This value of the MTU respects the recommendation that recommendation that every link on the Internet must have a minimum
every link on the Internet must have a minimum MTU of 1280 octets MTU of 1280 octets (stated in [RFC8200], and the recommendations
(stated in [RFC8200], and the recommendations therein, especially therein, especially with respect to fragmentation).
with respect to fragmentation).
4.2. Frame Format 4.2. Frame Format
IP packets MUST be transmitted over 802.11-OCB media as QoS Data IP packets MUST be transmitted over 802.11-OCB media as QoS Data
frames whose format is specified in IEEE 802.11(TM) -2016 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 MUST be immediately The IPv6 packet transmitted on 802.11-OCB are immediately preceded by
preceded by a Logical Link Control (LLC) header and an 802.11 header. a Logical Link Control (LLC) header and an 802.11 header. In the LLC
In the LLC header, and in accordance with the EtherType Protocol header, and in accordance with the EtherType Protocol Discrimination
Discrimination (EPD, see Appendix E), the value of the Type field (EPD, see Appendix D), the value of the Type field MUST be set to
MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the 0x86DD (IPv6). The mapping to the 802.11 data service MUST use a
Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. 'priority' value of 1, which specifies the use of QoS with a
'QoS Data'); the value of the Traffic Identifier (TID) sub-field of 'Background' user priority.
the QoS Control field of the 802.11 header MUST be set to binary 001
(i.e. User Priority 'Background', QoS Access Category 'AC_BK').
To simplify the Application Programming Interface (API) between the To simplify the Application Programming Interface (API) between the
operating system and the 802.11-OCB media, device drivers MAY operating system and the 802.11-OCB media, device drivers MAY
implement an Ethernet Adaptation Layer that translates Ethernet II implement IPv6 over Ethernet per RFC 2464 and then a frame
frames to the 802.11 format and vice versa. An Ethernet Adaptation translation from 802.3 to 802.11 in order to minimize the code
Layer is described in Section 4.2.1. changes.
4.2.1. Ethernet Adaptation Layer
An 'adaptation' layer is inserted between a MAC layer and the
Networking layer. This is used to transform some parameters between
their form expected by the IP stack and the form provided by the MAC
layer.
An Ethernet Adaptation Layer makes an 802.11 MAC look to IP
Networking layer as a more traditional Ethernet layer. At reception,
this layer takes as input the IEEE 802.11 header and the Logical-Link
Layer Control Header and produces an Ethernet II Header. At sending,
the reverse operation is performed.
The operation of the Ethernet Adaptation Layer is depicted by the
double arrow in Figure 1.
+------------------+------------+-------------+---------+-----------+
| 802.11 header | LLC Header | IPv6 Header | Payload |.11 Trailer|
+------------------+------------+-------------+---------+-----------+
\ / \ /
--------------------------- --------
\---------------------------------------------/
^
|
802.11-to-Ethernet Adaptation Layer
|
v
+---------------------+-------------+---------+
| Ethernet II Header | IPv6 Header | Payload |
+---------------------+-------------+---------+
Figure 1: Operation of the Ethernet Adaptation Layer
The Receiver and Transmitter Address fields in the 802.11 header MUST
contain the same values as the Destination and the Source Address
fields in the Ethernet II Header, respectively. The value of the
Type field in the LLC Header MUST be the same as the value of the
Type field in the Ethernet II Header. That value MUST be set to
0x86DD (IPv6).
The ".11 Trailer" contains solely a 4-byte Frame Check Sequence.
The placement of IPv6 networking layer on Ethernet Adaptation Layer
is illustrated in Figure 2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Adaptation Layer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 PHY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Ethernet Adaptation Layer stacked with other layers
(in the above figure, a 802.11 profile is represented; this is used
also for 802.11-OCB profile.)
4.3. Link-Local Addresses 4.3. Link-Local Addresses
There are several types of IPv6 addresses [RFC4291], [RFC4193], that There are several types of IPv6 addresses [RFC4291], [RFC4193], that
MAY be assigned to an 802.11-OCB interface. Among these types of MAY be assigned to an 802.11-OCB interface. Among these types of
addresses only the IPv6 link-local addresses MAY be formed using an addresses only the IPv6 link-local addresses MAY be formed using an
EUI-64 identifier, 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. This used to form an IPv6 link-local address on Ethernet links. This
mechanism is described in section 5 of [RFC2464]. mechanism is described in section 5 of [RFC2464].
4.4. Stateless Autoconfiguration 4.4. Stateless Autoconfiguration
There are several types of IPv6 addresses [RFC4291], [RFC4193], that The steps a host takes in deciding how to autoconfigure its
MAY be assigned to an 802.11-OCB interface. This section describes interfaces in IP version 6 are described in [RFC4862]. This section
the formation of Interface Identifiers for IPv6 addresses of type describes the formation of Interface Identifiers for IPv6 addresses
'Global' or 'Unique Local'. For Interface Identifiers for IPv6 of type 'Global' or 'Unique Local'. For Interface Identifiers for
address of type 'Link-Local' see Section 4.3. IPv6 address of type 'Link-Local' see Section 4.3.
The Interface Identifier for an 802.11-OCB interface is formed using The RECOMMENDED method for forming stable Interface Identifiers
the same rules as the Interface Identifier for an Ethernet interface;
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. time, in particular for IPv6 link-local addresses.
The bits in the Interface Identifier have no generic meaning and the The bits in the Interface Identifier have no generic meaning and the
identifier should be treated as an opaque value. The bits identifier should be treated as an opaque value. The bits
'Universal' and 'Group' in the identifier of an 802.11-OCB interface 'Universal' and 'Group' in the identifier of an 802.11-OCB interface
are significant, as this is an IEEE link-layer address. The details are significant, as this is an IEEE link-layer address. The details
of this significance are described in [RFC7136]. of this significance are described in [RFC7136].
skipping to change at page 8, line 21 skipping to change at page 6, line 33
name, or logical interface name, that is decided by a local name, or logical interface name, 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 in sections 6 and 7 of [RFC2464].
4.5.1. Address Mapping -- Unicast 4.5.1. Address Mapping -- Unicast
The procedure for mapping IPv6 unicast addresses into Ethernet link- This draft is scoped for AR and DAD per RFC 4861 [RFC4861].
layer addresses is described in [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. Solutions for these problems SHOULD exacerbated in OCB mode.A Future improvement to this specification
consider the OCB mode of operation. SHOULD consider solutions for these problems.
4.6. Subnet Structure 4.6. Subnet Structure
A subnet is formed by the external 802.11-OCB interfaces of vehicles A subnet may be formed over 802.11-OCB interfaces of vehicles that
that are in close range (not by their in-vehicle interfaces). A are in close range (not by their in-vehicle interfaces). A Prefix
Prefix List conceptual data structure ([RFC4861] section 5.1) is List conceptual data structure ([RFC4861] section 5.1) is maintained
maintained for each 802.11-OCB interface. for each 802.11-OCB interface.
The subnet structure on which the Neighbor Discovery protocol (ND) on An IPv6 subnet on which Neighbor Discovery protocol (ND) can be
OCB works ok is a single-link subnet; the status of ND operation on a mapped on an OCB network iff all nodes share a single broadcast
subnet that covers multiple OCB links that repeat the signal at PHY Domain, which is generally the case for P2P OCB links; The extension
layer, or the messages at MAC layer, is unknown. to IPv6 ND operating on a subnet that covers multiple OCB links and
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 car is
relatively stable. relatively stable.
As recommended in [RFC5889], when the timing requirements are very As recommended in [RFC5889], when the timing requirements are very
strict (e.g. fast drive through IP-RSU coverage), no on-link subnet strict (e.g. fast drive through IP-RSU coverage), no on-link subnet
skipping to change at page 9, line 20 skipping to change at page 7, line 38
cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED.
Additionally, even if the timing requirements are not very strict Additionally, even if the timing requirements are not very strict
(e.g. the moving subnet formed by two following vehicles is stable, a (e.g. the moving subnet formed by two following vehicles is stable, a
fixed IP-RSU is absent), the subnet is disconnected from the Internet fixed IP-RSU is absent), the subnet is disconnected from the Internet
(a default route is absent), and the addressing peers are equally (a default route is absent), and the addressing peers are equally
qualified (impossible to determine that some vehicle owns and qualified (impossible to determine that some vehicle owns and
distributes addresses to others) the use of link-local addresses is distributes addresses to others) the use of link-local addresses is
RECOMMENDED. RECOMMENDED.
The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be
over 802.11-OCB links. Transmitting ND packets may prove to have supported over 802.11-OCB links. Transmitting ND packets may prove
some performance issues. These issues may be exacerbated in OCB to have some performance issues see Section 4.5.2, and Appendix I.
mode. Solutions for these problems SHOULD consider the OCB mode of These issues may be exacerbated in OCB mode. Solutions for these
operation. The best of current knowledge indicates the kinds of problems SHOULD consider the OCB mode of operation. Future solutions
issues that may arise with ND in OCB mode; they are described in to OCB should consider solutions for avoiding broadcast. The best of
Appendix J. current knowledge indicates the kinds of issues that may arise with
ND in OCB mode; they are described in Appendix I.
Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which Protocols like Mobile IPv6 [RFC6275] , [RFC3963] and DNAv6 [RFC6059],
depend on timely movement detection, might need additional tuning which depend on timely movement detection, might need additional
work to handle the lack of link-layer notifications during handover. tuning work to handle the lack of link-layer notifications during
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 application layer, the IEEE
skipping to change at page 10, line 9 skipping to change at page 8, line 29
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 perform 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. and session hijacking, and privacy violation Section 5.1. A previous
work at SAVI WG presents some threats [RFC6959], while SeND presented
in [RFC3971] and [RFC3972] is a solution against address theft but it
is complex and not deployed.
Within the IPsec Security Architecture [RFC4301], the IPsec AH and More IETF protocols are available in the toolbox of the IP security
ESP headers [RFC4302] and [RFC4303] respectively, its multicast protocol designer. Certain ETSI protocols related to security
extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols protocols in Intelligent Transportation Systems are described in
can be used to protect communications. Further, the assistance of [ETSI-sec-archi].
proper Public Key Infrastructure (PKI) protocols [RFC4210] is
necessary to establish credentials. More IETF protocols are
available in the toolbox of the IP security protocol designer.
Certain ETSI protocols related to security protocols in Intelligent
Transportation Systems are described in [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 address hijacking risks. A vehicle embarking
an IP-OBU whose egress interface is 802.11-OCB may expose itself to an IP-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
skipping to change at page 11, line 17 skipping to change at page 9, line 33
5.2. MAC Address and Interface ID Generation 5.2. MAC Address and Interface ID Generation
In 802.11-OCB networks, the MAC addresses MAY change during well In 802.11-OCB networks, the MAC addresses MAY change during well
defined renumbering events. In the moment the MAC address is changed defined renumbering events. In the moment the MAC address is changed
on an 802.11-OCB interface all the Interface Identifiers of IPv6 on an 802.11-OCB interface all the Interface Identifiers of IPv6
addresses assigned to that interface MUST change. addresses assigned to that interface MUST change.
The policy dictating when the MAC address is changed on the The policy dictating when the MAC address is changed on the
802.11-OCB interface is to-be-determined. For more information on 802.11-OCB interface is to-be-determined. For more information on
the motivation of this policy please refer to the privacy discussion the motivation of this policy please refer to the privacy discussion
in Appendix C. in 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].
skipping to change at page 12, line 41 skipping to change at page 11, line 11
Michelle Wetterwald contributed extensively the MTU discussion, Michelle Wetterwald contributed extensively the MTU discussion,
offered the ETSI ITS perspective, and reviewed other parts of the offered the ETSI ITS perspective, and reviewed other parts of the
document. document.
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,
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 13, line 48 skipping to change at page 12, line 22
<https://www.rfc-editor.org/info/rfc2464>. <https://www.rfc-editor.org/info/rfc2464>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
<https://www.rfc-editor.org/info/rfc3753>. <https://www.rfc-editor.org/info/rfc3753>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[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)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[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>.
[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, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
skipping to change at page 14, line 41 skipping to change at page 13, line 26
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <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
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
<https://www.rfc-editor.org/info/rfc5374>. <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>.
skipping to change at page 15, line 18 skipping to change at page 14, line 9
[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
skipping to change at page 16, line 20 skipping to change at page 15, line 18
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-08 (work in progress), March ipwave-vehicular-networking-09 (work in progress), May
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-05 (work
in progress), April 2019. in progress), April 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
skipping to change at page 17, line 31 skipping to change at page 16, line 31
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,
2013.". 2013.".
Appendix A. ChangeLog Appendix A. 802.11p
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
-43: removed the SHOULD 48bit of a MAC address, just stay silent
about it; corrected 'global' address to 'Globally Reachable address';
added a paragraph scoping IPv6-over-OCB ND to work ok on single-link
subnets.
-42: removed 118 len IID; points to 'other documents' for the length
of Interface ID; removed 'directly using' phrase for LLs in a subnet.
-41: updated a reference from draft-ietf-ipwave-vehicular-networking-
survey to draft-ietf-ipwave-vehicular-networking; clarified the link-
local text by eliminating link-local addresses and prefixes
altogether and referring to RFC4861 which requires the prefixes;
added a statement about the subnet being a not multi-link subnet.
-40: added a phrase in appendix to further described a condition
where ND on OCB may not work; that phrase contains a placeholder; the
placeholder is 'TBD' (To Be Defined).
-39: removed a reference to an expired draft trying to update the
IPv6-over-Ethernet spec 'RFC2464bis'; added text in the subnet
structure section saying nodes MUST be able to communicate directly
using their link-local addresses.
-38: removed the word "fe80::/10".
-37: added a section about issues on ND wireless; added the qualifier
'baseline' to using ND on 802.11-OCB; improved the description of the
reference to 802.11-2016 document, with a qualifier about the
difficulty of accessing it, even though it is free.
-36: removed a phrase about the IID formation and MAC generation, but
left in the section 5.2 that describes how it happens.
-35: addressing the the intarea review: clarified a small apparent
contradiction between two parts of text that use the old MAC-based
IIDs (clarified by using qualifiers from each other: transition time,
and ll addresses); sequenced closer the LL and Stateless Autoconf
sections, instead of spacing them; shortened the paragraph of Opaque
IIDs; moved the privacy risks of in-clear IIDs in the security
section; removed a short phrase duplicating the idea of privacy
risks; added third time a reference to the 802.11-2016 document; used
'the hidden terminal' text; updated the Terminology section with new
BCP-14 text 'MUST' to include RFC8174.
-33: substituted 'movement detection' for 'handover behaviour' in
introductory text; removed redundant phrase referring to Security
Considerations section; removed the phrase about forming mechanisms
being left out, as IP is not much concerned about L2 forming; moved
the Pseudonym section from main section to end of Security
Considerations section (and clarified 'concurrently'); capitalized
SHOULD consider OCB in WiFi multicast problems, and referred to more
recent I-D on topic; removed several phrases in a paragraph about
oui.txt and MAC presence in IPv6 address, as they are well known
info, but clarified the example of privacy risk of Company ID in MAC
addresses in public roads; clarified that ND MUST be used over
802.11-OCB.
-32: significantly shortened the relevant ND/OCB paragraph. It now
just states ND is used over OCB, w/o detailing.
-31: filled in the section titled "Pseudonym Handling"; removed a
'MAY NOT' phrase about possibility of having other prefix than the LL
on the link between cars; shortened and improved the paragraph about
Mobile IPv6, now with DNAv6; improved the ND text about ND
retransmissions with relationship to packet loss; changed the title
of an appendix from 'EPD' to 'Protocol Layering'; improved the
'Aspects introduced by OCB' appendix with a few phrases about the
channel use and references.
-30: a clarification on the reliability of ND over OCB and over
802.11.
-29:
o
-28:
o Created a new section 'Pseudonym Handling'.
o removed the 'Vehicle ID' appendix.
o improved the address generation from random MAC address.
o shortened Term IP-RSU definition.
o removed refs to two detail Clauses in IEEE documents, kept just
these latter.
-27: part 1 of addressing Human Rights review from IRTF. Removed
appendices F.2 and F.3. Shortened definition of IP-RSU. Removed
reference to 1609.4. A few other small changes, see diff.
-26: moved text from SLAAC section and from Design Considerations
appendix about privacy into a new Privacy Condiderations subsection
of the Security section; reformulated the SLAAC and IID sections to
stress only LLs can use EUI-64; removed the "GeoIP" wireshark
explanation; reformulated SLAAC and LL sections; added brief mention
of need of use LLs; clarified text about MAC address changes; dropped
pseudonym discussion; changed title of section describing examples of
packet formats.
-25: added a reference to 'IEEE Management Information Base', instead
of just 'Management Information Base'; added ref to further
appendices in the introductory phrases; improved text for IID
formation for SLAAC, inserting recommendation for RFC8064 before
RFC2464.
From draft-ietf-ipwave-ipv6-over-80211ocb-23 to draft-ietf-ipwave-
ipv6-over-80211ocb-24
o Nit: wrote "IPWAVE Working Group" on the front page, instead of
"Network Working Group".
o Addressed the comments on 6MAN: replaced a sentence about ND
problem with "is used over 802.11-OCB".
From draft-ietf-ipwave-ipv6-over-80211ocb-22 to draft-ietf-ipwave-
ipv6-over-80211ocb-23
o No content modifications, but check the entire draft chain on
IPv6-only: xml2rfc, submission on tools.ietf.org and datatracker.
From draft-ietf-ipwave-ipv6-over-80211ocb-21 to draft-ietf-ipwave-
ipv6-over-80211ocb-22
o Corrected typo, use dash in "802.11-OCB" instead of space.
o Improved the Frame Format section: MUST use QoSData, specify the
values within; clarified the Ethernet Adaptation Layer text.
From draft-ietf-ipwave-ipv6-over-80211ocb-20 to draft-ietf-ipwave-
ipv6-over-80211ocb-21
o Corrected a few nits and added names in Acknowledgments section.
o Removed unused reference to old Internet Draft tsvwg about QoS.
From draft-ietf-ipwave-ipv6-over-80211ocb-19 to draft-ietf-ipwave-
ipv6-over-80211ocb-20
o Reduced the definition of term "802.11-OCB".
o Left out of this specification which 802.11 header to use to
transmit IP packets in OCB mode (QoS Data header, Data header, or
any other).
o Added 'MUST' use an Ethernet Adaptation Layer, instead of 'is
using' an Ethernet Adaptation Layer.
From draft-ietf-ipwave-ipv6-over-80211ocb-18 to draft-ietf-ipwave-
ipv6-over-80211ocb-19
o Removed the text about fragmentation.
o Removed the mentioning of WSMP and GeoNetworking.
o Removed the explanation of the binary representation of the
EtherType.
o Rendered normative the paragraph about unicast and multicast
address mapping.
o Removed paragraph about addressing model, subnet structure and
easiness of using LLs.
o Clarified the Type/Subtype field in the 802.11 Header.
o Used RECOMMENDED instead of recommended, for the stable interface
identifiers.
From draft-ietf-ipwave-ipv6-over-80211ocb-17 to draft-ietf-ipwave-
ipv6-over-80211ocb-18
o Improved the MTU and fragmentation paragraph.
From draft-ietf-ipwave-ipv6-over-80211ocb-16 to draft-ietf-ipwave-
ipv6-over-80211ocb-17
o Susbtituted "MUST be increased" to "is increased" in the MTU
section, about fragmentation.
From draft-ietf-ipwave-ipv6-over-80211ocb-15 to draft-ietf-ipwave-
ipv6-over-80211ocb-16
o Removed the definition of the 'WiFi' term and its occurences.
Clarified a phrase that used it in Appendix C "Aspects introduced
by the OCB mode to 802.11".
o Added more normative words: MUST be 0x86DD, MUST fragment if size
larger than MTU, Sequence number in 802.11 Data header MUST be
increased.
From draft-ietf-ipwave-ipv6-over-80211ocb-14 to draft-ietf-ipwave-
ipv6-over-80211ocb-15
o Added normative term MUST in two places in section "Ethernet
Adaptation Layer".
From draft-ietf-ipwave-ipv6-over-80211ocb-13 to draft-ietf-ipwave-
ipv6-over-80211ocb-14
o Created a new Appendix titled "Extra Terminology" that contains
terms DSRC, DSRCS, OBU, RSU as defined outside IETF. Some of them
are used in the main Terminology section.
o Added two paragraphs explaining that ND and Mobile IPv6 have
problems working over 802.11-OCB, yet their adaptations is not
specified in this document.
From draft-ietf-ipwave-ipv6-over-80211ocb-12 to draft-ietf-ipwave-
ipv6-over-80211ocb-13
o Substituted "IP-OBU" for "OBRU", and "IP-RSU" for "RSRU"
throughout and improved OBU-related definitions in the Terminology
section.
From draft-ietf-ipwave-ipv6-over-80211ocb-11 to draft-ietf-ipwave-
ipv6-over-80211ocb-12
o Improved the appendix about "MAC Address Generation" by expressing
the technique to be an optional suggestion, not a mandatory
mechanism.
From draft-ietf-ipwave-ipv6-over-80211ocb-10 to draft-ietf-ipwave-
ipv6-over-80211ocb-11
o Shortened the paragraph on forming/terminating 802.11-OCB links.
o Moved the draft tsvwg-ieee-802-11 to Informative References.
From draft-ietf-ipwave-ipv6-over-80211ocb-09 to draft-ietf-ipwave-
ipv6-over-80211ocb-10
o Removed text requesting a new Group ID for multicast for OCB.
o Added a clarification of the meaning of value "3333" in the
section Address Mapping -- Multicast.
o Added note clarifying that in Europe the regional authority is not
ETSI, but "ECC/CEPT based on ENs from ETSI".
o Added note stating that the manner in which two STAtions set their
communication channel is not described in this document.
o Added a time qualifier to state that the "each node is represented
uniquely at a certain point in time."
o Removed text "This section may need to be moved" (the "Reliability
Requirements" section). This section stays there at this time.
o In the term definition "802.11-OCB" added a note stating that "any
implementation should comply with standards and regulations set in
the different countries for using that frequency band."
o In the RSU term definition, added a sentence explaining the
difference between RSU and RSRU: in terms of number of interfaces
and IP forwarding.
o Replaced "with at least two IP interfaces" with "with at least two
real or virtual IP interfaces".
o Added a term in the Terminology for "OBU". However the definition
is left empty, as this term is defined outside IETF.
o Added a clarification that it is an OBU or an OBRU in this phrase
"A vehicle embarking an OBU or an OBRU".
o Checked the entire document for a consistent use of terms OBU and
OBRU.
o Added note saying that "'p' is a letter identifying the
Ammendment".
o Substituted lower case for capitals SHALL or MUST in the
Appendices.
o Added reference to RFC7042, helpful in the 3333 explanation.
Removed reference to individual submission draft-petrescu-its-
scenario-reqs and added reference to draft-ietf-ipwave-vehicular-
networking-survey.
o Added figure captions, figure numbers, and references to figure
numbers instead of 'below'. Replaced "section Section" with
"section" throughout.
o Minor typographical errors.
From draft-ietf-ipwave-ipv6-over-80211ocb-08 to draft-ietf-ipwave-
ipv6-over-80211ocb-09
o Significantly shortened the Address Mapping sections, by text
copied from RFC2464, and rather referring to it.
o Moved the EPD description to an Appendix on its own.
o Shortened the Introduction and the Abstract.
o Moved the tutorial section of OCB mode introduced to .11, into an
appendix.
o Removed the statement that suggests that for routing purposes a
prefix exchange mechanism could be needed.
o Removed refs to RFC3963, RFC4429 and RFC6775; these are about ND,
MIP/NEMO and oDAD; they were referred in the handover discussion
section, which is out.
o Updated a reference from individual submission to now a WG item in
IPWAVE: the survey document.
o Added term definition for WiFi.
o Updated the authorship and expanded the Contributors section.
o Corrected typographical errors.
From draft-ietf-ipwave-ipv6-over-80211ocb-07 to draft-ietf-ipwave-
ipv6-over-80211ocb-08
o Removed the per-channel IPv6 prohibition text.
o Corrected typographical errors.
From draft-ietf-ipwave-ipv6-over-80211ocb-06 to draft-ietf-ipwave-
ipv6-over-80211ocb-07
o Added new terms: OBRU and RSRU ('R' for Router). Refined the
existing terms RSU and OBU, which are no longer used throughout
the document.
o Improved definition of term "802.11-OCB".
o Clarified that OCB does not "strip" security, but that the
operation in OCB mode is "stripped off of all .11 security".
o Clarified that theoretical OCB bandwidth speed is 54mbits, but
that a commonly observed bandwidth in IP-over-OCB is 12mbit/s.
o Corrected typographical errors, and improved some phrasing.
From draft-ietf-ipwave-ipv6-over-80211ocb-05 to draft-ietf-ipwave-
ipv6-over-80211ocb-06
o Updated references of 802.11-OCB document from -2012 to the IEEE
802.11-2016.
o In the LL address section, and in SLAAC section, added references
to 7217 opaque IIDs and 8064 stable IIDs.
From draft-ietf-ipwave-ipv6-over-80211ocb-04 to draft-ietf-ipwave-
ipv6-over-80211ocb-05
o Lengthened the title and cleanded the abstract.
o Added text suggesting LLs may be easy to use on OCB, rather than
GUAs based on received prefix.
o Added the risks of spoofing and hijacking.
o Removed the text speculation on adoption of the TSA message.
o Clarified that the ND protocol is used.
o Clarified what it means "No association needed".
o Added some text about how two STAs discover each other.
o Added mention of external (OCB) and internal network (stable), in
the subnet structure section.
o Added phrase explaining that both .11 Data and .11 QoS Data
headers are currently being used, and may be used in the future.
o Moved the packet capture example into an Appendix Implementation
Status.
o Suggested moving the reliability requirements appendix out into
another document.
o Added a IANA Consiserations section, with content, requesting for
a new multicast group "all OCB interfaces".
o Added new OBU term, improved the RSU term definition, removed the
ETTC term, replaced more occurences of 802.11p, 802.11-OCB with
802.11-OCB.
o References:
* Added an informational reference to ETSI's IPv6-over-
GeoNetworking.
* Added more references to IETF and ETSI security protocols.
* Updated some references from I-D to RFC, and from old RFC to
new RFC numbers.
* Added reference to multicast extensions to IPsec architecture
RFC.
* Added a reference to 2464-bis.
* Removed FCC informative references, because not used.
o Updated the affiliation of one author.
o Reformulation of some phrases for better readability, and
correction of typographical errors.
From draft-ietf-ipwave-ipv6-over-80211ocb-03 to draft-ietf-ipwave-
ipv6-over-80211ocb-04
o Removed a few informative references pointing to Dx draft IEEE
1609 documents.
o Removed outdated informative references to ETSI documents.
o Added citations to IEEE 1609.2, .3 and .4-2016.
o Minor textual issues.
From draft-ietf-ipwave-ipv6-over-80211ocb-02 to draft-ietf-ipwave-
ipv6-over-80211ocb-03
o Keep the previous text on multiple addresses, so remove talk about
MIP6, NEMOv6 and MCoA.
o Clarified that a 'Beacon' is an IEEE 802.11 frame Beacon.
o Clarified the figure showing Infrastructure mode and OCB mode side
by side.
o Added a reference to the IP Security Architecture RFC.
o Detailed the IPv6-per-channel prohibition paragraph which reflects
the discussion at the last IETF IPWAVE WG meeting.
o Added section "Address Mapping -- Unicast".
o Added the ".11 Trailer" to pictures of 802.11 frames.
o Added text about SNAP carrying the Ethertype.
o New RSU definition allowing for it be both a Router and not
necessarily a Router some times.
o Minor textual issues.
From draft-ietf-ipwave-ipv6-over-80211ocb-01 to draft-ietf-ipwave-
ipv6-over-80211ocb-02
o Replaced almost all occurences of 802.11p with 802.11-OCB, leaving
only when explanation of evolution was necessary.
o Shortened by removing parameter details from a paragraph in the
Introduction.
o Moved a reference from Normative to Informative.
o Added text in intro clarifying there is no handover spec at IEEE,
and that 1609.2 does provide security services.
o Named the contents the fields of the EthernetII header (including
the Ethertype bitstring).
o Improved relationship between two paragraphs describing the
increase of the Sequence Number in 802.11 header upon IP
fragmentation.
o Added brief clarification of "tracking".
From draft-ietf-ipwave-ipv6-over-80211ocb-00 to draft-ietf-ipwave-
ipv6-over-80211ocb-01
o Introduced message exchange diagram illustrating differences
between 802.11 and 802.11 in OCB mode.
o Introduced an appendix listing for information the set of 802.11
messages that may be transmitted in OCB mode.
o Removed appendix sections "Privacy Requirements", "Authentication
Requirements" and "Security Certificate Generation".
o Removed appendix section "Non IP Communications".
o Introductory phrase in the Security Considerations section.
o Improved the definition of "OCB".
o Introduced theoretical stacked layers about IPv6 and IEEE layers
including EPD.
o Removed the appendix describing the details of prohibiting IPv6 on
certain channels relevant to 802.11-OCB.
o Added a brief reference in the privacy text about a precise clause
in IEEE 1609.3 and .4.
o Clarified the definition of a Road Side Unit.
o Removed the discussion about security of WSA (because is non-IP).
o Removed mentioning of the GeoNetworking discussion.
o Moved references to scientific articles to a separate 'overview'
draft, and referred to it.
Appendix B. 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
has the flag set, uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. has the flag set, uses a BSS identifier equal to ff:ff:ff:ff:ff:ff.
Appendix C. Aspects introduced by the OCB mode to 802.11 Appendix B. Aspects introduced by the OCB mode to 802.11
In the IEEE 802.11-OCB mode, all nodes in the wireless range can In the IEEE 802.11-OCB mode, all nodes in the wireless range can
directly communicate with each other without involving authentication directly communicate with each other without involving authentication
or association procedures. In OCB mode, the manner in which channels or association procedures. In OCB mode, the manner in which channels
are selected and used is simplified compared to when in BSS mode. are selected and used is simplified compared to when in BSS mode.
Contrary to BSS mode, at link layer, it is necessary to set Contrary to BSS mode, at link layer, it is necessary to set
statically the same channel number (or frequency) on two stations statically the same channel number (or frequency) on two stations
that need to communicate with each other (in BSS mode this channel that need to communicate with each other (in BSS mode this channel
set operation is performed automatically during 'scanning'). The set operation is performed automatically during 'scanning'). The
manner in which stations set their channel number in OCB mode is not manner in which stations set their channel number in OCB mode is not
skipping to change at page 29, line 4 skipping to change at page 17, line 23
Briefly, the IEEE 802.11-OCB mode has the following properties: Briefly, the IEEE 802.11-OCB mode has the following properties:
o The use by each node of a 'wildcard' BSSID (i.e., each bit of the o The use by each node of a 'wildcard' BSSID (i.e., each bit of the
BSSID is set to 1) BSSID is set to 1)
o No IEEE 802.11 Beacon frames are transmitted o No IEEE 802.11 Beacon frames are transmitted
o No authentication is required in order to be able to communicate o No authentication is required in order to be able to communicate
o No association is needed in order to be able to communicate o No association is needed in order to be able to communicate
o No encryption is provided in order to be able to communicate o No encryption is provided in order to be able to communicate
o Flag dot11OCBActivated is set to true o Flag dot11OCBActivated is set to true
All the nodes in the radio communication range (IP-OBU and IP-RSU) All the nodes in the radio communication range (IP-OBU and IP-RSU)
receive all the messages transmitted (IP-OBU and IP-RSU) within the receive all the messages transmitted (IP-OBU and IP-RSU) within the
radio communications range. The eventual conflict(s) are resolved by radio communications range. The eventual conflict(s) are resolved by
the MAC CDMA function. the MAC CDMA function.
The message exchange diagram in Figure 3 illustrates a comparison The message exchange diagram in Figure 1 illustrates a comparison
between traditional 802.11 and 802.11 in OCB mode. The 'Data' between traditional 802.11 and 802.11 in OCB mode. The 'Data'
messages can be IP packets such as HTTP or others. Other 802.11 messages can be IP packets such as HTTP or others. Other 802.11
management and control frames (non IP) may be transmitted, as management and control frames (non IP) may be transmitted, as
specified in the 802.11 standard. For information, the names of specified in the 802.11 standard. For information, the names of
these messages as currently specified by the 802.11 standard are these messages as currently specified by the 802.11 standard are
listed in Appendix G. listed in Appendix F.
STA AP STA1 STA2 STA AP STA1 STA2
| | | | | | | |
|<------ Beacon -------| |<------ Data -------->| |<------ Beacon -------| |<------ Data -------->|
| | | | | | | |
|---- Probe Req. ----->| |<------ Data -------->| |---- Probe Req. ----->| |<------ Data -------->|
|<--- Probe Res. ------| | | |<--- Probe Res. ------| | |
| | |<------ Data -------->| | | |<------ Data -------->|
|---- Auth Req. ------>| | | |---- Auth Req. ------>| | |
|<--- Auth Res. -------| |<------ Data -------->| |<--- Auth Res. -------| |<------ Data -------->|
| | | | | | | |
|---- Asso Req. ------>| |<------ Data -------->| |---- Asso Req. ------>| |<------ Data -------->|
|<--- Asso Res. -------| | | |<--- Asso Res. -------| | |
| | |<------ Data -------->| | | |<------ Data -------->|
|<------ Data -------->| | | |<------ Data -------->| | |
|<------ Data -------->| |<------ Data -------->| |<------ Data -------->| |<------ Data -------->|
(i) 802.11 Infrastructure mode (ii) 802.11-OCB mode (i) 802.11 Infrastructure mode (ii) 802.11-OCB mode
Figure 3: Difference between messages exchanged on 802.11 (left) and Figure 1: Difference between messages exchanged on 802.11 (left) and
802.11-OCB (right) 802.11-OCB (right)
The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010 The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010
[IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007, [IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007,
titled "Amendment 6: Wireless Access in Vehicular Environments". titled "Amendment 6: Wireless Access in Vehicular Environments".
Since then, this amendment has been integrated in IEEE 802.11(TM) Since then, this amendment has been integrated in IEEE 802.11(TM)
-2012 and -2016 [IEEE-802.11-2016]. -2012 and -2016 [IEEE-802.11-2016].
In document 802.11-2016, anything qualified specifically as In document 802.11-2016, anything qualified specifically as
"OCBActivated", or "outside the context of a basic service" set to be "OCBActivated", or "outside the context of a basic service" set to be
skipping to change at page 32, line 20 skipping to change at page 21, line 5
strong privacy requirements with respect to addressing. While the strong privacy requirements with respect to addressing. While the
802.11-OCB standard does not specify anything in particular with 802.11-OCB standard does not specify anything in particular with
respect to MAC addresses, in these settings there exists a strong respect to MAC addresses, in these settings there exists a strong
need for dynamic change of these addresses (as opposed to the non- need for dynamic change of these addresses (as opposed to the non-
vehicular settings - real wall protection - where fixed MAC vehicular settings - real wall protection - where fixed MAC
addresses do not currently pose some privacy risks). This is addresses do not currently pose some privacy risks). This is
further described in Section 5. A relevant function is described further described in Section 5. A relevant function is described
in documents IEEE 1609.3-2016 [IEEE-1609.3] and IEEE 1609.4-2016 in documents IEEE 1609.3-2016 [IEEE-1609.3] and IEEE 1609.4-2016
[IEEE-1609.4]. [IEEE-1609.4].
Appendix D. Changes Needed on a software driver 802.11a to become a Appendix C. Changes Needed on a software driver 802.11a to become a
802.11-OCB driver 802.11-OCB driver
The 802.11p amendment modifies both the 802.11 stack's physical and The 802.11p amendment modifies both the 802.11 stack's physical and
MAC layers but all the induced modifications can be quite easily MAC layers but all the induced modifications can be quite easily
obtained by modifying an existing 802.11a ad-hoc stack. obtained by modifying an existing 802.11a ad-hoc stack.
Conditions for a 802.11a hardware to be 802.11-OCB compliant: Conditions for a 802.11a hardware to be 802.11-OCB compliant:
o The PHY entity shall be an orthogonal frequency division o The PHY entity shall be an orthogonal frequency division
multiplexing (OFDM) system. It must support the frequency bands multiplexing (OFDM) system. It must support the frequency bands
skipping to change at page 33, line 37 skipping to change at page 22, line 21
Response) and for authentication (Authentication Request/Reply, Response) and for authentication (Authentication Request/Reply,
Challenge) are not called. Challenge) are not called.
* The beacon interval is always set to 0 (zero). * The beacon interval is always set to 0 (zero).
* Timing Advertisement frames, defined in the amendment, should * Timing Advertisement frames, defined in the amendment, should
be supported. The upper layer should be able to trigger such be supported. The upper layer should be able to trigger such
frames emission and to retrieve information contained in frames emission and to retrieve information contained in
received Timing Advertisements. received Timing Advertisements.
Appendix E. Protocol Layering Appendix D. Protocol Layering
A more theoretical and detailed view of layer stacking, and A more theoretical and detailed view of layer stacking, and
interfaces between the IP layer and 802.11-OCB layers, is illustrated interfaces between the IP layer and 802.11-OCB layers, is illustrated
in Figure 4. The IP layer operates on top of the EtherType Protocol in Figure 2. The IP layer operates on top of the EtherType Protocol
Discrimination (EPD); this Discrimination layer is described in IEEE Discrimination (EPD); this Discrimination layer is described in IEEE
Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP
(Link Layer Control Service Access Point). (Link Layer Control Service Access Point).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 | | IPv6 |
+-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+
{ LLC_SAP } 802.11-OCB { LLC_SAP } 802.11-OCB
+-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary
| EPD | | | | EPD | | |
| | MLME | | | | MLME | |
+-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP |
| MAC Sublayer | | | 802.11-OCB | MAC Sublayer | | | 802.11-OCB
| and ch. coord. | | SME | Services | and ch. coord. | | SME | Services
+-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| |
| | PLME | | | | PLME | |
| PHY Layer | PLME_SAP | | PHY Layer | PLME_SAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EtherType Protocol Discrimination Figure 2: EtherType Protocol Discrimination
Appendix F. 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 encapsulation of IPv6
over 802.11-OCB could be very similar to the operation of IPv6 over over 802.11-OCB could be very similar to the operation of IPv6 over
other networks of the 802.11 family. However, the high mobility, other networks of the 802.11 family. However, the high mobility,
strong link asymmetry and very short connection makes the 802.11-OCB strong link asymmetry and very short connection makes the 802.11-OCB
link significantly different from other 802.11 networks. Also, the link significantly different from other 802.11 networks. Also, the
automotive applications have specific requirements for reliability, automotive applications have specific requirements for reliability,
security and privacy, which further add to the particularity of the security and privacy, which further add to the particularity of the
802.11-OCB link. 802.11-OCB link.
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode Appendix F. IEEE 802.11 Messages Transmitted in OCB mode
For information, at the time of writing, this is the list of IEEE For information, at the time of writing, this is the list of IEEE
802.11 messages that may be transmitted in OCB mode, i.e. when 802.11 messages that may be transmitted in OCB mode, i.e. when
dot11OCBActivated is true in a STA: dot11OCBActivated is true in a STA:
o The STA may send management frames of subtype Action and, if the o The STA may send management frames of subtype Action and, if the
STA maintains a TSF Timer, subtype Timing Advertisement; STA maintains a TSF Timer, subtype Timing Advertisement;
o The STA may send control frames, except those of subtype PS-Poll, o The STA may send control frames, except those of subtype PS-Poll,
CF-End, and CF-End plus CFAck; CF-End, and CF-End plus CFAck;
o The STA may send data frames of subtype Data, Null, QoS Data, and o The STA may send data frames of subtype Data, Null, QoS Data, and
QoS Null. QoS Null.
Appendix H. Examples of Packet Formats Appendix G. Examples of Packet Formats
This section describes an example of an IPv6 Packet captured over a This section describes an example of an IPv6 Packet captured over a
IEEE 802.11-OCB link. IEEE 802.11-OCB link.
By way of example we show that there is no modification in the By way of example we show that there is no modification in the
headers when transmitted over 802.11-OCB networks - they are headers when transmitted over 802.11-OCB networks - they are
transmitted like any other 802.11 and Ethernet packets. transmitted like any other 802.11 and Ethernet packets.
We describe an experiment of capturing an IPv6 packet on an We describe an experiment of capturing an IPv6 packet on an
802.11-OCB link. In topology depicted in Figure 5, the packet is an 802.11-OCB link. In topology depicted in Figure 3, the packet is an
IPv6 Router Advertisement. This packet is emitted by a Router on its IPv6 Router Advertisement. This packet is emitted by a Router on its
802.11-OCB interface. The packet is captured on the Host, using a 802.11-OCB interface. The packet is captured on the Host, using a
network protocol analyzer (e.g. Wireshark); the capture is performed network protocol analyzer (e.g. Wireshark); the capture is performed
in two different modes: direct mode and 'monitor' mode. The topology in two different modes: direct mode and 'monitor' mode. The topology
used during the capture is depicted below. used during the capture is depicted below.
The packet is captured on the Host. The Host is an IP-OBU containing The packet is captured on the Host. The Host is an IP-OBU containing
an 802.11 interface in format PCI express (an ITRI product). The an 802.11 interface in format PCI express (an ITRI product). The
kernel runs the ath5k software driver with modifications for OCB kernel runs the ath5k software driver with modifications for OCB
mode. The capture tool is Wireshark. The file format for save and mode. The capture tool is Wireshark. The file format for save and
analyze is 'pcap'. The packet is generated by the Router. The analyze is 'pcap'. The packet is generated by the Router. The
Router is an IP-RSU (ITRI product). Router is an IP-RSU (ITRI product).
+--------+ +-------+ +--------+ +-------+
| | 802.11-OCB Link | | | | 802.11-OCB Link | |
---| Router |--------------------------------| Host | ---| Router |--------------------------------| Host |
| | | | | | | |
+--------+ +-------+ +--------+ +-------+
Figure 5: Topology for capturing IP packets on 802.11-OCB Figure 3: Topology for capturing IP packets on 802.11-OCB
During several capture operations running from a few moments to During several capture operations running from a few moments to
several hours, no message relevant to the BSSID contexts were several hours, no message relevant to the BSSID contexts were
captured (no Association Request/Response, Authentication Req/Resp, captured (no Association Request/Response, Authentication Req/Resp,
Beacon). This shows that the operation of 802.11-OCB is outside the Beacon). This shows that the operation of 802.11-OCB is outside the
context of a BSSID. context of a BSSID.
Overall, the captured message is identical with a capture of an IPv6 Overall, the captured message is identical with a capture of an IPv6
packet emitted on a 802.11b interface. The contents are precisely packet emitted on a 802.11b interface. The contents are precisely
similar. similar.
H.1. Capture in Monitor Mode G.1. Capture in Monitor Mode
The IPv6 RA packet captured in monitor mode is illustrated below. The IPv6 RA packet captured in monitor mode is illustrated below.
The radio tap header provides more flexibility for reporting the The radio tap header provides more flexibility for reporting the
characteristics of frames. The Radiotap Header is prepended by this characteristics of frames. The Radiotap Header is prepended by this
particular stack and operating system on the Host machine to the RA particular stack and operating system on the Host machine to the RA
packet received from the network (the Radiotap Header is not present packet received from the network (the Radiotap Header is not present
on the air). The implementation-dependent Radiotap Header is useful on the air). The implementation-dependent Radiotap Header is useful
for piggybacking PHY information from the chip's registers as data in for piggybacking PHY information from the chip's registers as data in
a packet understandable by userland applications using Socket a packet understandable by userland applications using Socket
interfaces (the PHY interface can be, for example: power levels, data interfaces (the PHY interface can be, for example: power levels, data
skipping to change at page 38, line 31 skipping to change at page 27, line 5
the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 the IEEE 802.11 data, the destination address is 33:33:00:00:00:01
which is the corresponding multicast MAC address. The BSS id is a which is the corresponding multicast MAC address. The BSS id is a
broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link
duration between vehicles and the roadside infrastructure, there is duration between vehicles and the roadside infrastructure, there is
no need in IEEE 802.11-OCB to wait for the completion of association no need in IEEE 802.11-OCB to wait for the completion of association
and authentication procedures before exchanging data. IEEE and authentication procedures before exchanging data. IEEE
802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s)
and may start communicating as soon as they arrive on the and may start communicating as soon as they arrive on the
communication channel. communication channel.
H.2. Capture in Normal Mode G.2. Capture in Normal Mode
The same IPv6 Router Advertisement packet described above (monitor The same IPv6 Router Advertisement packet described above (monitor
mode) is captured on the Host, in the Normal mode, and depicted mode) is captured on the Host, in the Normal mode, and depicted
below. below.
Ethernet II Header Ethernet II Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination... | Destination...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Destination | Source... ...Destination | Source...
skipping to change at page 40, line 23 skipping to change at page 29, line 23
The value of the Type field in the Ethernet II header is 0x86DD The value of the Type field in the Ethernet II header is 0x86DD
(recognized as "IPv6"); this value is the same value as the value of (recognized as "IPv6"); this value is the same value as the value of
the field Type in the Logical-Link Control Header in the "monitor" the field Type in the Logical-Link Control Header in the "monitor"
mode capture. mode capture.
The knowledgeable experimenter will no doubt notice the similarity of The knowledgeable experimenter will no doubt notice the similarity of
this Ethernet II Header with a capture in normal mode on a pure this Ethernet II Header with a capture in normal mode on a pure
Ethernet cable interface. Ethernet cable interface.
An Adaptation layer is inserted on top of a pure IEEE 802.11 MAC A frame translation is inserted on top of a pure IEEE 802.11 MAC
layer, in order to adapt packets, before delivering the payload data layer, in order to adapt packets, before delivering the payload data
to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II
headers. In further detail, this adaptation consists in the headers. In further detail, this adaptation consists in the
elimination of the Radiotap, 802.11 and LLC headers, and in the elimination of the Radiotap, 802.11 and LLC headers, and in the
insertion of the Ethernet II header. In this way, IPv6 runs straight insertion of the Ethernet II header. In this way, IPv6 runs straight
over LLC over the 802.11-OCB MAC layer; this is further confirmed by over LLC over the 802.11-OCB MAC layer; this is further confirmed by
the use of the unique Type 0x86DD. the use of the unique Type 0x86DD.
Appendix I. Extra Terminology Appendix H. Extra Terminology
The following terms are defined outside the IETF. They are used to The following terms are defined outside the IETF. They are used to
define the main terms in the main terminology section Section 2. define the main terms in the main terminology section Section 2.
DSRC (Dedicated Short Range Communication): a term defined outside DSRC (Dedicated Short Range Communication): a term defined outside
the IETF. The US Federal Communications Commission (FCC) Dedicated the IETF. The US Federal Communications Commission (FCC) Dedicated
Short Range Communication (DSRC) is defined in the Code of Federal Short Range Communication (DSRC) is defined in the Code of Federal
Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the
definitions below. At the time of the writing of this Internet definitions below. At the time of the writing of this Internet
Draft, the last update of this Code was dated October 1st, 2010. Draft, the last update of this Code was dated October 1st, 2010.
skipping to change at page 41, line 32 skipping to change at page 30, line 32
carried, but it may only operate when the vehicle or hand- carried carried, but it may only operate when the vehicle or hand- carried
unit is stationary. Furthermore, an RSU operating under the unit is stationary. Furthermore, an RSU operating under the
respectgive part is restricted to the location where it is licensed respectgive part is restricted to the location where it is licensed
to operate. However, portable or hand-held RSUs are permitted to to operate. However, portable or hand-held RSUs are permitted to
operate where they do not interfere with a site-licensed operation. operate where they do not interfere with a site-licensed operation.
A RSU broadcasts data to OBUs or exchanges data with OBUs in its A RSU broadcasts data to OBUs or exchanges data with OBUs in its
communications zone. An RSU also provides channel assignments and communications zone. An RSU also provides channel assignments and
operating instructions to OBUs in its communications zone, when operating instructions to OBUs in its communications zone, when
required. - [CFR 90.7 - Definitions]. required. - [CFR 90.7 - Definitions].
Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless Links Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Links
IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was designed for IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was designed for
point-to-point and transit links such as Ethernet, with the point-to-point and transit links such as Ethernet, with the
expectation of a cheap and reliable support for multicast from the expectation of a cheap and reliable support for multicast from the
lower layer. Section 3.2 of RFC 4861 indicates that the operation on lower layer. Section 3.2 of RFC 4861 indicates that the operation on
Shared Media and on non-broadcast multi-access (NBMA) networks Shared Media and on non-broadcast multi-access (NBMA) networks
require additional support, e.g., for Address Resolution (AR) and require additional support, e.g., for Address Resolution (AR) and
duplicate address detection (DAD), which depend on multicast. An duplicate address detection (DAD), which depend on multicast. An
infrastructureless radio network such as OCB shares properties with infrastructureless radio network such as OCB shares properties with
both Shared Media and NBMA networks, and then adds its own both Shared Media and NBMA networks, and then adds its own
 End of changes. 52 change blocks. 
723 lines changed or deleted 163 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/