draft-ietf-ipwave-ipv6-over-80211ocb-13.txt   draft-ietf-ipwave-ipv6-over-80211ocb-14.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: August 8, 2018 Moulay Ismail University Expires: August 15, 2018 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
February 4, 2018 February 11, 2018
Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode
Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
draft-ietf-ipwave-ipv6-over-80211ocb-13.txt draft-ietf-ipwave-ipv6-over-80211ocb-14.txt
Abstract Abstract
In order to transmit IPv6 packets on IEEE 802.11 networks running In order to transmit IPv6 packets on IEEE 802.11 networks running
outside the context of a basic service set (OCB, earlier "802.11p") outside the context of a basic service set (OCB, earlier "802.11p")
there is a need to define a few parameters such as the supported there is a need to define a few parameters such as the supported
Maximum Transmission Unit size on the 802.11-OCB link, the header Maximum Transmission Unit size on the 802.11-OCB link, the header
format preceding the IPv6 header, the Type value within it, and format preceding the IPv6 header, the Type value within it, and
others. This document describes these parameters for IPv6 and IEEE others. This document describes these parameters for IPv6 and IEEE
802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2018. This Internet-Draft will expire on August 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Communication Scenarios where IEEE 802.11-OCB Links are Used 5 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4
4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5
4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5
4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5
4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8
4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 9 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8
4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 9 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8
4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 9 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 8
4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 9 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 10 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 22
Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 23 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 23
Appendix D. Changes Needed on a software driver 802.11a to Appendix D. Changes Needed on a software driver 802.11a to
become a 802.11-OCB driver . . . 27 become a 802.11-OCB driver . . . 27
Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 28 Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 28
Appendix F. Design Considerations . . . . . . . . . . . . . . . 29 Appendix F. Design Considerations . . . . . . . . . . . . . . . 29
F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29
F.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 F.2. Reliability Requirements . . . . . . . . . . . . . . . . 29
F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30
F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31
Appendix H. Implementation Status . . . . . . . . . . . . . . . 32 Appendix H. Implementation Status . . . . . . . . . . . . . . . 31
H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32
H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document describes the transmission of IPv6 packets on IEEE Std This document describes the transmission of IPv6 packets on IEEE Std
802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see
Appendix B). This involves the layering of IPv6 networking on top of Appendix B). This involves the layering of IPv6 networking on top of
the IEEE 802.11 MAC layer, with an LLC layer. Compared to running the IEEE 802.11 MAC layer, with an LLC layer. Compared to running
IPv6 over the Ethernet MAC layer, there is no modification expected IPv6 over the Ethernet MAC layer, there is no modification expected
to IEEE Std 802.11 MAC and Logical Link sublayers: IPv6 works fine to IEEE Std 802.11 MAC and Logical Link sublayers: IPv6 works fine
directly over 802.11-OCB too, with an LLC layer. directly over 802.11-OCB too, with an LLC layer.
skipping to change at page 4, line 5 skipping to change at page 4, line 8
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].
WiFi: Wireless Fidelity. WiFi: Wireless Fidelity.
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. that has an "OBU" transceiver. See the definition of the term "OBU"
in section Appendix I.
OBU (On-Board Unit): a term defined outside the IETF. An On-Board
Unit is a DSRC transceiver that is normally mounted in or on a
vehicle, or which in some instances may be a portable unit. An OBU
can be operational while a vehicle or person is either mobile or
stationary. The OBUs receive and contend for time to transmit on one
or more radio frequency (RF) channels. Except where specifically
excluded, OBU operation is permitted wherever vehicle operation or
human passage is permitted. The OBUs mounted in vehicles are
licensed by rule under part 95 of this chapter and communicate with
Roadside Units (RSUs) and other OBUs. Portable OBUs are also
licensed by rule under part 95 of this chapter. OBU operations in
the Unlicensed National Information Infrastructure (UNII) Bands
follow the rules in those bands. - [CFR 90.7 - Definitions]. The US
Federal Communications Commission (FCC) Dedicated Short Range
Communication (DSRC) is defined in the Code of Federal Regulations
(CFR) 47, Parts 90 and 95. At the time of the writing of this
Internet Draft, the last update of this document was dated October
1st, 2010.
IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. An IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. An
IP-RSU has at least two distinct IP-enabled interfaces; at least one IP-RSU has at least two distinct IP-enabled interfaces; at least one
interface is operated in mode OCB of IEEE 802.11 and is IP-enabled. interface is operated in mode OCB of IEEE 802.11 and is IP-enabled.
An IP-RSU is similar to a Wireless Termination Point (WTP), as An IP-RSU is similar to a Wireless Termination Point (WTP), as
defined in [RFC5415], or an Access Point (AP), as defined in IEEE defined in [RFC5415], or an Access Point (AP), as defined in IEEE
documents, or an Access Network Router (ANR) defined in [RFC3753], documents, or an Access Network Router (ANR) defined in [RFC3753],
with one key particularity: the wireless PHY/MAC layer of at least with one key particularity: the wireless PHY/MAC layer of at least
one of its IP-enabled interfaces is configured to operate in one of its IP-enabled interfaces is configured to operate in
802.11-OCB mode. The RSRU communicates with the IP-OBU in the 802.11-OCB mode. The IP-RSU communicates with the IP-OBU in the
vehicle over 802.11 wireless link operating in OCB mode. vehicle over 802.11 wireless link operating in OCB mode.
RSU (Road-Side Unit): a term defined outside of IETF. A Roadside
Unit is a DSRC transceiver that is mounted along a road or pedestrian
passageway. An RSU may also be mounted on a vehicle or is hand
carried, but it may only operate when the vehicle or hand- carried
unit is stationary. Furthermore, an RSU operating under this part is
restricted to the location where it is licensed to operate. However,
portable or hand-held RSUs are permitted to operate where they do not
interfere with a site-licensed operation. A RSU broadcasts data to
OBUs or exchanges data with OBUs in its communications zone. An RSU
also provides channel assignments and operating instructions to OBUs
in its communications zone, when required. - [CFR 90.7 -
Definitions]. At the time of the writing of this Internet Draft, the
last update of this document was dated October 1st, 2010.
OCB (outside the context of a basic service set - BSS): A mode of OCB (outside the context of a basic service set - BSS): A mode of
operation in which a STA is not a member of a BSS and does not operation in which a STA is not a member of a BSS and does not
utilize IEEE Std 802.11 authentication, association, or data utilize IEEE Std 802.11 authentication, association, or data
confidentiality. confidentiality.
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
attribute dot11OCBActivited is true. The OCB mode requires attribute dot11OCBActivited is true. The OCB mode requires
transmission of QoS data frames (IEEE Std 802.11e), half-clocked transmission of QoS data frames (IEEE Std 802.11e), half-clocked
operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band.
Nota: any implementation should comply with standards and regulations Nota: any implementation should comply with standards and regulations
skipping to change at page 10, line 32 skipping to change at page 9, line 41
networks. The addressing model for such networks is described in networks. The addressing model for such networks is described in
[RFC5889]. [RFC5889].
An addressing model involves several types of addresses, like An addressing model involves several types of addresses, like
Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique
Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may
have characteristics that lead to difficulty of using GUAs derived have characteristics that lead to difficulty of using GUAs derived
from a received prefix, but the LL addresses may be easier to use from a received prefix, but the LL addresses may be easier to use
since the prefix is constant. since the prefix is constant.
The operation of the Neighbor Discovery protocol (ND) over 802.11 OCB
links is different than over 802.11 links. In OCB, the link layer
does not ensure that all associated members receive all messages,
because there is no association operation. The operation of ND over
802.11 OCB is not specified in this document.
The operation of the Mobile IPv6 protocol over 802.11 OCB links is
different than on other links. The Movement Detection operation
(section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability
Detection operation of the Neighbor Discovery protocol, for the
reason mentioned in the previous paragraph. Also, the 802.11 OCB
link layer is not a lower layer that can provide an indication that a
link layer handover has occured. The operation of the Mobile IPv6
protocol over 802.11 OCB is not specified in this document.
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
1609.2 document [IEEE-1609.2] does provide security services for 1609.2 document [IEEE-1609.2] does provide security services for
skipping to change at page 17, line 5 skipping to change at page 16, line 22
document freely available at URL document freely available at URL
http://standards.ieee.org/getieee802/ http://standards.ieee.org/getieee802/
download/802.11p-2010.pdf retrieved on September 20th, download/802.11p-2010.pdf retrieved on September 20th,
2013.". 2013.".
Appendix A. ChangeLog Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list. changes appearing at the top of the list.
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- From draft-ietf-ipwave-ipv6-over-80211ocb-12 to draft-ietf-ipwave-
ipv6-over-80211ocb-13 ipv6-over-80211ocb-13
o Substituted "IP-OBU" for "OBRU", and "IP-RSU" for "RSRU" o Substituted "IP-OBU" for "OBRU", and "IP-RSU" for "RSRU"
throughout and improved OBU-related definitions in the Terminology throughout and improved OBU-related definitions in the Terminology
section. section.
From draft-ietf-ipwave-ipv6-over-80211ocb-11 to draft-ietf-ipwave- From draft-ietf-ipwave-ipv6-over-80211ocb-11 to draft-ietf-ipwave-
ipv6-over-80211ocb-12 ipv6-over-80211ocb-12
skipping to change at page 37, line 32 skipping to change at page 37, line 32
An Adaptation layer is inserted on top of a pure IEEE 802.11 MAC An Adaptation layer 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
The following terms are defined outside the IETF. They are used to
define the main terms in the main terminology section Section 2.
DSRC (Dedicated Short Range Communication): a term defined outside
the IETF. The US Federal Communications Commission (FCC) Dedicated
Short Range Communication (DSRC) is defined in the Code of Federal
Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the
definitions below. At the time of the writing of this Internet
Draft, the last update of this Code was dated October 1st, 2010.
DSRCS (Dedicated Short-Range Communications Services): a term defined
outside the IETF. The use of radio techniques to transfer data over
short distances between roadside and mobile units, between mobile
units, and between portable and mobile units to perform operations
related to the improvement of traffic flow, traffic safety, and other
intelligent transportation service applications in a variety of
environments. DSRCS systems may also transmit status and
instructional messages related to the units involve. [Ref. 47 CFR
90.7 - Definitions]
OBU (On-Board Unit): a term defined outside the IETF. An On-Board
Unit is a DSRCS transceiver that is normally mounted in or on a
vehicle, or which in some instances may be a portable unit. An OBU
can be operational while a vehicle or person is either mobile or
stationary. The OBUs receive and contend for time to transmit on one
or more radio frequency (RF) channels. Except where specifically
excluded, OBU operation is permitted wherever vehicle operation or
human passage is permitted. The OBUs mounted in vehicles are
licensed by rule under part 95 of the respective chapter and
communicate with Roadside Units (RSUs) and other OBUs. Portable OBUs
are also licensed by rule under part 95 of the respective chapter.
OBU operations in the Unlicensed National Information Infrastructure
(UNII) Bands follow the rules in those bands. - [CFR 90.7 -
Definitions].
RSU (Road-Side Unit): a term defined outside of IETF. A Roadside
Unit is a DSRC transceiver that is mounted along a road or pedestrian
passageway. An RSU may also be mounted on a vehicle or is hand
carried, but it may only operate when the vehicle or hand- carried
unit is stationary. Furthermore, an RSU operating under the
respectgive part is restricted to the location where it is licensed
to operate. However, portable or hand-held RSUs are permitted to
operate where they do not interfere with a site-licensed operation.
A RSU broadcasts data to OBUs or exchanges data with OBUs in its
communications zone. An RSU also provides channel assignments and
operating instructions to OBUs in its communications zone, when
required. - [CFR 90.7 - Definitions].
Authors' Addresses Authors' Addresses
Alexandre Petrescu Alexandre Petrescu
CEA, LIST CEA, LIST
CEA Saclay CEA Saclay
Gif-sur-Yvette , Ile-de-France 91190 Gif-sur-Yvette , Ile-de-France 91190
France France
Phone: +33169089223 Phone: +33169089223
Email: Alexandre.Petrescu@cea.fr Email: Alexandre.Petrescu@cea.fr
 End of changes. 19 change blocks. 
54 lines changed or deleted 98 lines changed or added

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