draft-ietf-ipwave-ipv6-over-80211ocb-06.txt   draft-ietf-ipwave-ipv6-over-80211ocb-07.txt 
Network Working Group A. Petrescu Network Working Group A. Petrescu
Internet-Draft CEA, LIST Internet-Draft CEA, LIST
Intended status: Standards Track N. Benamar Intended status: Standards Track N. Benamar
Expires: March 16, 2018 Moulay Ismail University Expires: March 21, 2018 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
C. Huitema C. Huitema
Private Octopus Inc. Private Octopus Inc.
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
T. Li T. Li
Peloton Technology Peloton Technology
September 12, 2017 September 17, 2017
Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode
Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
draft-ietf-ipwave-ipv6-over-80211ocb-06.txt draft-ietf-ipwave-ipv6-over-80211ocb-07.txt
Abstract Abstract
In order to transmit IPv6 packets on IEEE 802.11 networks run outside In order to transmit IPv6 packets on IEEE 802.11 networks running
the context of a basic service set (OCB, earlier "802.11p") there is outside the context of a basic service set (OCB, earlier "802.11p")
a need to define a few parameters such as the supported Maximum there is a need to define a few parameters such as the supported
Transmission Unit size on the 802.11-OCB link, the header format Maximum Transmission Unit size on the 802.11-OCB link, the header
preceding the IPv6 header, the Type value within it, and others. format preceding the IPv6 header, the Type value within it, and
This document describes these parameters for IPv6 and IEEE 802.11-OCB others. This document describes these parameters for IPv6 and IEEE
networks; it portrays the layering of IPv6 on 802.11-OCB similarly to 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
other known 802.11 and Ethernet layers - by using an Ethernet similarly to other known 802.11 and Ethernet layers - by using an
Adaptation Layer. Ethernet Adaptation Layer.
In addition, the document lists what is different in 802.11-OCB In addition, the document lists what is different in 802.11-OCB
(802.11p) links compared to more 'traditional' 802.11a/b/g/n links, (802.11p) links compared to more 'traditional' 802.11a/b/g/n links,
where IPv6 protocols operate without issues. Most notably, the where IPv6 protocols operate without issues. Most notably, the
operation outside the context of a BSS (OCB) has impact on IPv6 operation outside the context of a BSS (OCB) impacts IPv6 handover
handover behaviour and on IPv6 security. behaviour and IPv6 security.
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 March 16, 2018. This Internet-Draft will expire on March 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Communication Scenarios where IEEE 802.11-OCB Links are Used 6 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 7
4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 7 4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 7
5. Layering of IPv6 over 802.11-OCB as over Ethernet . . . . . . 11 5. Layering of IPv6 over 802.11-OCB as over Ethernet . . . . . . 11
5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 11 5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 11
5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 13 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 13
5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14
5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 14 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 15
5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 15 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 15
5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 15 5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 15
5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 16 5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 16
5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 17 5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Changes Needed on a software driver 802.11a to Appendix B. Changes Needed on a software driver 802.11a to
become a 802.11-OCB driver . . . 27 become a 802.11-OCB driver . . . 28
Appendix C. Design Considerations . . . . . . . . . . . . . . . 29 Appendix C. Design Considerations . . . . . . . . . . . . . . . 29
C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29
C.2. Reliability Requirements . . . . . . . . . . . . . . . . 29 C.2. Reliability Requirements . . . . . . . . . . . . . . . . 30
C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31
C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31
Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32
Appendix E. Implementation Status . . . . . . . . . . . . . . . 32 Appendix E. Implementation Status . . . . . . . . . . . . . . . 32
E.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32 E.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33
E.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 E.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
This document describes the transmission of IPv6 packets on IEEE Std This document describes the transmission of IPv6 packets on IEEE Std
802.11-OCB networks (earlier known as 802.11p) [IEEE-802.11-2016]. 802.11-OCB networks (a.k.a 802.11p) [IEEE-802.11-2016]. This
This involves the layering of IPv6 networking on top of the IEEE involves the layering of IPv6 networking on top of the IEEE 802.11
802.11 MAC layer (with an LLC layer). Compared to running IPv6 over MAC layer (with an LLC layer). Compared to running IPv6 over the
the Ethernet MAC layer, there is no modification required to the Ethernet MAC layer, there is no modification expected to IEEE Std
standards: IPv6 works fine directly over 802.11-OCB too (with an LLC 802.11 MAC and Logical Link sublayers: IPv6 works fine directly over
layer). 802.11-OCB too (with an LLC layer).
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 a flag in the Management Information Base. feature is conditioned by the Management Information Base (MIB)
That flag is named "OCBActivated". Whenever OCBActivated is set to attribute "OCBActivated". Whenever OCBActivated is set to true the
true the feature it relates to, or represents, an earlier 802.11p IEEE Std 802.11 OCB state is activated. For example, an 802.11
feature. For example, an 802.11 STAtion operating outside the STAtion operating outside the context of a basic service set has the
context of a basic service set has the OCBActivated flag set. Such a OCBActivated flag set. Such a station, when it has the flag set,
station, when it has the flag set, uses a BSS identifier equal to uses a BSS identifier equal to ff:ff:ff:ff:ff:ff.
ff:ff:ff:ff:ff:ff.
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
it operates on 802.11 WiFi, with a few particular exceptions. The it operates on 802.11 WiFi, with a few particular exceptions. The
IPv6 network layer operates on WiFi by involving an Ethernet IPv6 network layer operates on WiFi by involving an Ethernet
Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers
to Ethernet II headers. The operation of IP on Ethernet is described to Ethernet II headers. The operation of IP on Ethernet is described
in [RFC1042], [RFC2464] and [I-D.hinden-6man-rfc2464bis]. The in [RFC1042], [RFC2464] and [I-D.hinden-6man-rfc2464bis]. The
situation of IPv6 networking layer on Ethernet Adaptation Layer is situation of IPv6 networking layer on Ethernet Adaptation Layer is
illustrated below: illustrated below:
skipping to change at page 5, line 11 skipping to change at page 5, line 11
the performances of running IPv6 over 802.11-OCB (e.g. in the case of the performances of running IPv6 over 802.11-OCB (e.g. in the case of
handovers between 802.11-OCB-enabled access routers, or the handovers between 802.11-OCB-enabled access routers, or the
consideration of using the IP security architecture [RFC4301]). consideration of using the IP security architecture [RFC4301]).
There are currently no specifications for handover between OCB links There are currently no specifications for handover between OCB links
since these are currently specified as LLC-1 links (i.e. since these are currently specified as LLC-1 links (i.e.
connectionless). Any handovers must be performed above the Data Link connectionless). Any handovers must be performed above the Data Link
Layer. To realize handovers between OCB links there is a need of Layer. To realize handovers between OCB links there is a need of
specific indicators to assist in the handover process. The specific indicators to assist in the handover process. The
indicators may be IP Router Advertisements, or 802.11-OCB's Time indicators may be IP Router Advertisements, or 802.11-OCB's Time
Advertisements, or higher layer messages such as the 'Basic Safety Advertisements, or application-layer data. However, this document
Message' (in the US), or the 'Cooperative Awareness Message' (in the
EU), or the 'WAVE Routing Advertisement'. However, this document
does not describe handover behaviour. does not describe handover behaviour.
The OCB operation is stripping off 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
1609.2 document [IEEE-1609.2] does provide security services for 1609.2 document [IEEE-1609.2] does provide security services for
certain applications to use. A security mechanism provided at certain applications to use; application-layer mechanisms are out-of-
networking layer, such as IPsec [RFC4301], may provide data security scope of this document. On another hand, a security mechanism
protection to a wider range of applications. See the section provided at networking layer, such as IPsec [RFC4301], may provide
Security Considerations of this document, Section 6 data security protection to a wider range of applications. See the
section Security Considerations of this document, Section 6
We briefly introduce the vehicular communication scenarios where IEEE We briefly introduce the vehicular communication scenarios where IEEE
802.11-OCB links are used. This is followed by a description of 802.11-OCB links are used. This is followed by a description of
differences in specification terms, between 802.11-OCB and differences in specification terms, between 802.11-OCB and
802.11a/b/g/n - we answer the question of what are the aspects 802.11a/b/g/n - we answer the question of what are the aspects
introduced by OCB mode to 802.11; the same aspects, but expressed in introduced by OCB mode to 802.11; the same aspects, but expressed in
terms of requirements to implementation, are listed in Appendix B.) terms of requirements to implementation, are listed in Appendix B.)
The document then concentrates on the parameters of layering IP over The document then concentrates on the parameters of layering IP over
802.11-OCB as over Ethernet: value of MTU, the Frame Format which 802.11-OCB as over Ethernet: value of MTU, the Frame Format which
skipping to change at page 6, line 11 skipping to change at page 6, line 11
In the published literature, many documents describe aspects related In the published literature, many documents describe aspects related
to running IPv6 over 802.11-OCB: to running IPv6 over 802.11-OCB:
[I-D.jeong-ipwave-vehicular-networking-survey]. [I-D.jeong-ipwave-vehicular-networking-survey].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
OBU (On-Board Unit): contrary to an RSU, an OBU is almost always OBRU (On-Board Router Unit): an OBRU is almost always situated in a
situated in a vehicle; it is a computer with at least two IP vehicle; it is a computer with at least two IP interfaces; at least
interfaces; also, at least one IP interface runs in OCB mode of one IP interface runs in OCB mode of 802.11. It MAY be an IP Router.
802.11. It may be an IP router.
RSU (Road Side Unit): It is a Wireless Termination Point (WTP), as RSRU (Road-Side Router Unit): an RSRU is almost always situated in a
defined in [RFC5415], or an Access Point (AP), or an Access Network box fixed along the road. An RSRU has at least two distinct IP-
Router (ANR) defined in [RFC3753], with one key particularity: the enabled interfaces; at least one interface is operated in mode OCB of
wireless PHY/MAC layer is configured to operate in 802.11-OCB mode. IEEE 802.11 and is IP-enabled. An RSRU is similar to a Wireless
The RSU communicates with the On board Unit (OBU) in the vehicle over Termination Point (WTP), as defined in [RFC5415], or an Access Point
802.11 wireless link operating in OCB mode. An RSU MAY be connected (AP), as defined in IEEE documents, or an Access Network Router (ANR)
to the Internet, and MAY be an IP router. When it is connected to defined in [RFC3753], with one key particularity: the wireless PHY/
the Internet, the term V2I (Vehicle to Internet) is relevant. MAC layer of at least one of its IP-enabled interfaces is configured
to operate in 802.11-OCB mode. The RSRU communicates with the On
board Unit (OBRU) in the vehicle over 802.11 wireless link operating
in OCB mode. An RSRU MAY be connected to the Internet, and MAY be an
IP Router. When it is connected to the Internet, the term V2I
(Vehicle to Internet) is relevant.
RSU (Road-Side Unit): an RSU operates in 802.11-OCB mode. A RSU
broadcasts data to OBUs or exchanges data with OBUs in its
communications zone. An RSU may provides channel assignments and
operating instructions to OBUs in its communications zone, when
required. The basic functional blocks of an RSU are: internal
computer processing, permanent storage capability, an integrated GPS
receiver for positioning and timing and an interface that supports
both IPv4 and IPv6 connectivity, compliant with 802.3at. An OCB
interface of an RSU MAY be IP-enabled simultaneously to being WAVE-
enabled or GeoNetworking-enabled (MAY support simultaneously
EtherTypes 0x86DD for IPv6 _and_ 0x88DC for WAVE and 0x8947 for
GeoNetworking).
OCB (outside the context of a basic service set - BSS): A mode of OCB (outside the context of a basic service set - BSS): A mode of
operation in which a STA is not a member of a BSS and does not operation in which a STA is not a member of a BSS and does not
utilize IEEE Std 802.11 authentication, association, or data utilize IEEE Std 802.11 authentication, association, or data
confidentiality. confidentiality.
802.11-OCB, or 802.11-OCB: text in document IEEE 802.11-2016 that is 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
flagged by "dot11OCBActivated". The text flagged "dot11OCBActivated" attribute dot11OCBActivited is true. The OCB mode requires
includes IEEE 802.11e for quality of service, 802.11j-2004 for half- transmission of QoS data frames (IEEE Std 802.11e), half-clocked
clocked operations and (what was known earlier as) 802.11p for operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band.
operation in the 5.9 GHz band and in mode OCB.
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'. The IP communication
scenarios for these environments have been described in several scenarios for these environments have been described in several
documents, among which we refer the reader to one recently updated documents, among which we refer the reader to one recently updated
[I-D.petrescu-its-scenarios-reqs], about scenarios and requirements [I-D.petrescu-its-scenarios-reqs], about scenarios and requirements
for IP in Intelligent Transportation Systems. 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 RSUs and/or OBUs. While 802.11-OCB vehicular networks, STAs can be RSRUs and/or OBRUs. While 802.11-OCB
is clearly specified, and the use of IPv6 over such link is not is clearly specified, and the use of IPv6 over such link is not
radically new, the operating environment (vehicular networks) brings radically new, the operating environment (vehicular networks) brings
in new perspectives. in new perspectives.
The 802.11-OCB links form and terminate; nodes connected to these The 802.11-OCB links form and terminate; nodes connected to these
links peer, and discover each other; the nodes are mobile. However, links peer, and discover each other; the nodes are mobile. However,
the precise description of how links discover each other, peer and the precise description of how links discover each other, peer and
manage mobility is not given in this document. manage mobility is not given in this document.
4. Aspects introduced by the OCB mode to 802.11 4. Aspects introduced by the OCB mode to 802.11
skipping to change at page 7, line 32 skipping to change at page 7, line 50
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 (OBU and RSU) receive All the nodes in the radio communication range (OBRU and RSRU)
all the messages transmitted (OBU and RSU) within the radio receive all the messages transmitted (OBRU and RSRU) within the radio
communications range. The eventual conflict(s) are resolved by the communications range. The eventual conflict(s) are resolved by the
MAC CDMA function. MAC CDMA function.
The following message exchange diagram illustrates a comparison The following message exchange diagram 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 D. listed in Appendix D.
skipping to change at page 8, line 23 skipping to change at page 8, line 33
|<--- Auth Res. -------| |<------ Data -------->| |<--- Auth Res. -------| |<------ Data -------->|
| | | | | | | |
|---- Asso Req. ------>| |<------ Data -------->| |---- Asso Req. ------>| |<------ Data -------->|
|<--- Asso Res. -------| | | |<--- Asso Res. -------| | |
| | |<------ Data -------->| | | |<------ Data -------->|
|<------ Data -------->| | | |<------ Data -------->| | |
|<------ Data -------->| |<------ Data -------->| |<------ Data -------->| |<------ Data -------->|
(a) 802.11 Infrastructure mode (b) 802.11-OCB mode (a) 802.11 Infrastructure mode (b) 802.11-OCB mode
The link 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 included in IEEE 802.11(TM)-2016 Since then, this amendment has been included in IEEE 802.11(TM) -2012
[IEEE-802.11-2016], titled "IEEE Standard for Information and -2016 [IEEE-802.11-2016].
technology--Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific requirements
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications"; the modifications are diffused throughout
various sections (e.g. the Time Advertisement message described in
the earlier 802.11 (TM) p amendment is now described in section
'Frame formats', and the operation outside the context of a BSS
described in section 'MLME').
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" is "OCBActivated", or "outside the context of a basic service" set to be
actually referring to OCB aspects introduced to 802.11. Note that in true, then it is actually referring to OCB aspects introduced to
earlier 802.11p documents the term "OCBEnabled" was used instead of 802.11.
the current "OCBActivated".
In order to delineate the aspects introduced by 802.11-OCB to 802.11, In order to delineate the aspects introduced by 802.11-OCB to 802.11,
we refer to the earlier [IEEE-802.11p-2010]. The amendment is we refer to the earlier [IEEE-802.11p-2010]. The amendment is
concerned with vehicular communications, where the wireless link is concerned with vehicular communications, where the wireless link is
similar to that of Wireless LAN (using a PHY layer specified by similar to that of Wireless LAN (using a PHY layer specified by
802.11a/b/g/n), but which needs to cope with the high mobility factor 802.11a/b/g/n), but which needs to cope with the high mobility factor
inherent in scenarios of communications between moving vehicles, and inherent in scenarios of communications between moving vehicles, and
between vehicles and fixed infrastructure deployed along roads. between vehicles and fixed infrastructure deployed along roads.
While 'p' is a letter just like 'a, b, g' and 'n' are, 'p' is While 'p' is a letter just like 'a, b, g' and 'n' are, 'p' is
concerned more with MAC modifications, and a little with PHY concerned more with MAC modifications, and a little with PHY
modifications; the others are mainly about PHY modifications. It is modifications; the others are mainly about PHY modifications. It is
possible in practice to combine a 'p' MAC with an 'a' PHY by possible in practice to combine a 'p' MAC with an 'a' PHY by
operating outside the context of a BSS with OFDM at 5.4GHz. operating outside the context of a BSS with OFDM at 5.4GHz and
5.9GHz.
The 802.11-OCB links are specified to be compatible as much as The 802.11-OCB links are specified to be compatible as much as
possible with the behaviour of 802.11a/b/g/n and future generation possible with the behaviour of 802.11a/b/g/n and future generation
IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer
offers practically the same interface to IP as the WiFi and Ethernet offers practically the same interface to IP as the WiFi and Ethernet
layers do (802.11a/b/g/n and 802.3). A packet sent by an OBU may be layers do (802.11a/b/g/n and 802.3). A packet sent by an OBRU may be
received by one or multiple RSUs. The link-layer resolution is received by one or multiple RSRUs. The link-layer resolution is
performed by using the IPv6 Neighbor Discovery protocol. performed by using the IPv6 Neighbor Discovery protocol.
To support this similarity statement (IPv6 is layered on top of LLC To support this similarity statement (IPv6 is layered on top of LLC
on top of 802.11-OCB, in the same way that IPv6 is layered on top of on top of 802.11-OCB, in the same way that IPv6 is layered on top of
LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on
top of 802.3 (for Ethernet)) it is useful to analyze the differences top of 802.3 (for Ethernet)) it is useful to analyze the differences
between 802.11-OCB and 802.11 specifications. During this analysis, between 802.11-OCB and 802.11 specifications. During this analysis,
we note that whereas 802.11-OCB lists relatively complex and numerous we note that whereas 802.11-OCB lists relatively complex and numerous
changes to the MAC layer (and very little to the PHY layer), there changes to the MAC layer (and very little to the PHY layer), there
are only a few characteristics which may be important for an are only a few characteristics which may be important for an
implementation transmitting IPv6 packets on 802.11-OCB links. implementation transmitting IPv6 packets on 802.11-OCB links.
The most important 802.11-OCB point which influences the IPv6 The most important 802.11-OCB point which influences the IPv6
functioning is the OCB characteristic; an additional, less direct functioning is the OCB characteristic; an additional, less direct
influence, is the maximum bandwidth afforded by the PHY modulation/ influence, is the maximum bandwidth afforded by the PHY modulation/
demodulation methods and channel access specified by 802.11-OCB. The demodulation methods and channel access specified by 802.11-OCB. The
maximum bandwidth possible in 802.11-OCB is 12Mbit/s; this bandwidth maximum bandwidth theoretically possible in 802.11-OCB is 54 Mbit/s
(when using, for example, the following parameters: 20 MHz channel;
modulation 64-QAM; codint rate R is 3/4); in practice of IP-over-
802.11-OCB a commonly observed figure is 12Mbit/s; this bandwidth
allows the operation of a wide range of protocols relying on IPv6. allows the operation of a wide range of protocols relying on IPv6.
o Operation Outside the Context of a BSS (OCB): the (earlier o Operation Outside the Context of a BSS (OCB): the (earlier
802.11p) 802.11-OCB links are operated without a Basic Service Set 802.11p) 802.11-OCB links are operated without a Basic Service Set
(BSS). This means that the frames IEEE 802.11 Beacon, Association (BSS). This means that the frames IEEE 802.11 Beacon, Association
Request/Response, Authentication Request/Response, and similar, Request/Response, Authentication Request/Response, and similar,
are not used. The used identifier of BSS (BSSID) has a are not used. The used identifier of BSS (BSSID) has a
hexadecimal value always 0xffffffffffff (48 '1' bits, represented hexadecimal value always 0xffffffffffff (48 '1' bits, represented
as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard'
BSSID), as opposed to an arbitrary BSSID value set by BSSID), as opposed to an arbitrary BSSID value set by
skipping to change at page 10, line 19 skipping to change at page 10, line 27
is worth considering that the frequency range is regulated by a is worth considering that the frequency range is regulated by a
regional authority (ARCEP, ETSI, FCC, etc.); as part of the regional authority (ARCEP, ETSI, FCC, etc.); as part of the
regulation process, specific applications are associated with regulation process, specific applications are associated with
specific frequency ranges. In the case of 802.11-OCB, the specific frequency ranges. In the case of 802.11-OCB, the
regulator associates a set of frequency ranges, or slots within a regulator associates a set of frequency ranges, or slots within a
band, to the use of applications of vehicular communications, in a band, to the use of applications of vehicular communications, in a
band known as "5.9GHz". The 5.9GHz band is different from the band known as "5.9GHz". The 5.9GHz band is different from the
2.4GHz and 5GHz bands used by Wireless LAN. However, as with 2.4GHz and 5GHz bands used by Wireless LAN. However, as with
Wireless LAN, the operation of 802.11-OCB in "5.9GHz" bands is Wireless LAN, the operation of 802.11-OCB in "5.9GHz" bands is
exempt from owning a license in EU (in US the 5.9GHz is a licensed exempt from owning a license in EU (in US the 5.9GHz is a licensed
band of spectrum; for the the fixed infrastructure an explicit FCC band of spectrum; for the fixed infrastructure an explicit FCC
autorization is required; for an onboard device a 'licensed-by- autorization is required; for an onboard device a 'licensed-by-
rule' concept applies: rule certification conformity is required); rule' concept applies: rule certification conformity is required);
however technical conditions are different than those of the bands however technical conditions are different than those of the bands
"2.4GHz" or "5GHz". On one hand, the allowed power levels, and "2.4GHz" or "5GHz". On one hand, the allowed power levels, and
implicitly the maximum allowed distance between vehicles, is of implicitly the maximum allowed distance between vehicles, is of
33dBm for 802.11-OCB (in Europe), compared to 20 dBm for Wireless 33dBm for 802.11-OCB (in Europe), compared to 20 dBm for Wireless
LAN 802.11a/b/g/n; this leads to a maximum distance of LAN 802.11a/b/g/n; this leads to a maximum distance of
approximately 1km, compared to approximately 50m. On the other approximately 1km, compared to approximately 50m. On the other
hand, specific conditions related to congestion avoidance, jamming hand, specific conditions related to congestion avoidance, jamming
avoidance, and radar detection are imposed on the use of DSRC (in avoidance, and radar detection are imposed on the use of DSRC (in
skipping to change at page 19, line 35 skipping to change at page 19, line 39
The authours would like to thank participants to the Birds-of- The authours would like to thank participants to the Birds-of-
a-Feather "Intelligent Transportation Systems" meetings held at IETF a-Feather "Intelligent Transportation Systems" meetings held at IETF
in 2016. in 2016.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-tsvwg-ieee-802-11] [I-D.ietf-tsvwg-ieee-802-11]
Szigeti, T., Henry, J., and F. Baker, "Diffserv to IEEE Szigeti, T., Henry, J., and F. Baker, "Diffserv to IEEE
802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-07 (work in 802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-08 (work in
progress), September 2017. progress), September 2017.
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission
of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, of IP datagrams over IEEE 802 networks", STD 43, RFC 1042,
DOI 10.17487/RFC1042, February 1988, DOI 10.17487/RFC1042, February 1988,
<https://www.rfc-editor.org/info/rfc1042>. <https://www.rfc-editor.org/info/rfc1042>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 24, line 22 skipping to change at page 24, line 22
document freely available at URL document freely available at URL
http://standards.ieee.org/getieee802/ http://standards.ieee.org/getieee802/
download/802.11p-2010.pdf retrieved on September 20th, download/802.11p-2010.pdf retrieved on September 20th,
2013.". 2013.".
Appendix A. ChangeLog Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list. changes appearing at the top of the list.
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- From draft-ietf-ipwave-ipv6-over-80211ocb-05 to draft-ietf-ipwave-
ipv6-over-80211ocb-06 ipv6-over-80211ocb-06
o Updated references of 802.11-OCB document from -2012 to the IEEE o Updated references of 802.11-OCB document from -2012 to the IEEE
802.11-2016. 802.11-2016.
o In the LL address section, and in SLAAC section, added references o In the LL address section, and in SLAAC section, added references
to 7217 opaque IIDs and 8064 stable IIDs. to 7217 opaque IIDs and 8064 stable IIDs.
From draft-ietf-ipwave-ipv6-over-80211ocb-04 to draft-ietf-ipwave- From draft-ietf-ipwave-ipv6-over-80211ocb-04 to draft-ietf-ipwave-
skipping to change at page 28, line 7 skipping to change at page 28, line 21
Appendix B. Changes Needed on a software driver 802.11a to become a Appendix B. 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 chip must support the frequency bands on which the regulator o The PHY entity shall be an orthogonal frequency division
recommends the use of ITS communications, for example using IEEE multiplexing (OFDM) system. It must support the frequency bands
802.11-OCB layer, in France: 5875MHz to 5925MHz. on which the regulator recommends the use of ITS communications,
for example using IEEE 802.11-OCB layer, in France: 5875MHz to
5925MHz.
o The chip must support the half-rate mode (the internal clock o The OFDM system must provide a "half-clocked" operation using 10
should be able to be divided by two). MHz channel spacings.
o The chip transmit spectrum mask must be compliant to the "Transmit o The chip transmit spectrum mask must be compliant to the "Transmit
spectrum mask" from the IEEE 802.11p amendment (but experimental spectrum mask" from the IEEE 802.11p amendment (but experimental
environments tolerate otherwise). environments tolerate otherwise).
o The chip should be able to transmit up to 44.8 dBm when used by o The chip should be able to transmit up to 44.8 dBm when used by
the US government in the United States, and up to 33 dBm in the US government in the United States, and up to 33 dBm in
Europe; other regional conditions apply. Europe; other regional conditions apply.
Changes needed on the network stack in OCB mode: Changes needed on the network stack in OCB mode:
skipping to change at page 28, line 34 skipping to change at page 28, line 50
o Physical layer: o Physical layer:
* The chip must use the Orthogonal Frequency Multiple Access * The chip must use the Orthogonal Frequency Multiple Access
(OFDM) encoding mode. (OFDM) encoding mode.
* The chip must be set in half-mode rate mode (the internal clock * The chip must be set in half-mode rate mode (the internal clock
frequency is divided by two). frequency is divided by two).
* The chip must use dedicated channels and should allow the use * The chip must use dedicated channels and should allow the use
of higher emission powers. This may require modifications to of higher emission powers. This may require modifications to
the regulatory domains rules, if used by the kernel to enforce the local computer file that describes regulatory domains
local specific restrictions. Such modifications must respect rules, if used by the kernel to enforce local specific
the location-specific laws. restrictions. Such modifications to the local computer file
must respect the location-specific regulatory rules.
MAC layer: MAC layer:
* All management frames (beacons, join, leave, and others) * All management frames (beacons, join, leave, and others)
emission and reception must be disabled except for frames of emission and reception must be disabled except for frames of
subtype Action and Timing Advertisement (defined below). subtype Action and Timing Advertisement (defined below).
* No encryption key or method must be used. * No encryption key or method must be used.
* Packet emission and reception must be performed as in ad-hoc * Packet emission and reception must be performed as in ad-hoc
skipping to change at page 32, line 7 skipping to change at page 32, line 25
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 E. Implementation Status Appendix E. Implementation Status
This section describese 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 this experiment, the packet is an IPv6 Router 802.11-OCB link. In this experiment, the packet is an IPv6 Router
Advertisement. This packet is emitted by a Router on its 802.11-OCB Advertisement. This packet is emitted by a Router on its 802.11-OCB
interface. The packet is captured on the Host, using a network interface. The packet is captured on the Host, using a network
 End of changes. 36 change blocks. 
94 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/