draft-ietf-ipwave-ipv6-over-80211ocb-07.txt   draft-ietf-ipwave-ipv6-over-80211ocb-08.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 21, 2018 Moulay Ismail University Expires: March 23, 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 17, 2017 September 19, 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-07.txt draft-ietf-ipwave-ipv6-over-80211ocb-08.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 2, line 10 skipping to change at page 2, line 10
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 21, 2018. This Internet-Draft will expire on March 23, 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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 7 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 . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 13 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 12
5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14
5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 15 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 14
5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 15 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . 23
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 . . . 28 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 . . . . . . . . . . . . . . . . 30 C.2. Reliability Requirements . . . . . . . . . . . . . . . . 30
C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31 C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30
C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31
Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 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 . . . . . . . . . . . . . . . . . 33 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
skipping to change at page 4, line 23 skipping to change at page 4, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(in the above figure, a WiFi profile is represented; this is used (in the above figure, a WiFi profile is represented; this is used
also for OCB profile.) also for OCB profile.)
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
below. The IP layer operates on top of the EtherType Protocol below. 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 Accesss 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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
the IPv6 Ethertype. the IPv6 Ethertype.
However, there may be some deployment considerations helping optimize However, there may be some deployment considerations helping optimize
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 for
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 application-layer data. However, this document Advertisements, or application-layer data. However, this document
does not describe handover behaviour. does not describe handover behaviour.
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
certain applications to use; application-layer mechanisms are out-of- certain applications to use; application-layer mechanisms are out-of-
skipping to change at page 7, line 10 skipping to change at page 7, line 10
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.
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; in particular, we refer the reader to
[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 RSRUs and/or OBRUs. 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
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. At link layer, it is necessary to set a or association procedures. At link layer, it is necessary to set the
same channel number (or frequency) on two stations that need to same channel number (or frequency) on two stations that need to
communicate with each other. Stations STA1 and STA2 can exchange IP communicate with each other. Stations STA1 and STA2 can exchange IP
packets if they are set on the same channel. At IP layer, they then packets if they are set on the same channel. At IP layer, they then
discover each other by using the IPv6 Neighbor Discovery protocol. discover each other by using the IPv6 Neighbor Discovery protocol.
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)
skipping to change at page 10, line 16 skipping to change at page 10, line 16
described in this document. described in this document.
o Timing Advertisement: is a new message defined in 802.11-OCB, o Timing Advertisement: is a new message defined in 802.11-OCB,
which does not exist in 802.11a/b/g/n. This message is used by which does not exist in 802.11a/b/g/n. This message is used by
stations to inform other stations about the value of time. It is stations to inform other stations about the value of time. It is
similar to the time as delivered by a GNSS system (Galileo, GPS, similar to the time as delivered by a GNSS system (Galileo, GPS,
...) or by a cellular system. This message is optional for ...) or by a cellular system. This message is optional for
implementation. implementation.
o Frequency range: this is a characteristic of the PHY layer, with o Frequency range: this is a characteristic of the PHY layer, with
almost no impact to the interface between MAC and IP. However, it almost no impact on the interface between MAC and IP. However, it
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
skipping to change at page 10, line 41 skipping to change at page 10, line 41
"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
US) and on the use of frequencies for Intelligent Transportation US) and on the use of frequencies for Intelligent Transportation
Systems (in EU), compared to Wireless LAN (802.11a/b/g/n). Systems (in EU), compared to Wireless LAN (802.11a/b/g/n).
o Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB,
as opposed to IPv6 not being prohibited on any channel on which
802.11a/b/g/n runs:
* Some channels are reserved for safety communications; the IPv6
packets should not be sent on these channels.
* At the time of writing, the prohibition is explicit at higher
layer protocols providing services to the application; these
higher layer protocols are specified in IEEE 1609 documents,
i.e. the "WAVE" stack.
* National or regional specifications and regulations specify the
use of different channels; these regulations must be followed.
o 'Half-rate' encoding: as the frequency range, this parameter is o 'Half-rate' encoding: as the frequency range, this parameter is
related to PHY, and thus has not much impact on the interface related to PHY, and thus has not much impact on the interface
between the IP layer and the MAC layer. between the IP layer and the MAC layer.
o In vehicular communications using 802.11-OCB links, there are o In vehicular communications using 802.11-OCB links, there are
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
skipping to change at page 19, line 39 skipping to change at page 19, line 26
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-08 (work in 802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-09 (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 5
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-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- From draft-ietf-ipwave-ipv6-over-80211ocb-06 to draft-ietf-ipwave-
ipv6-over-80211ocb-07 ipv6-over-80211ocb-07
o Added new terms: OBRU and RSRU ('R' for Router). Refined the o Added new terms: OBRU and RSRU ('R' for Router). Refined the
existing terms RSU and OBU, which are no longer used throughout existing terms RSU and OBU, which are no longer used throughout
the document. the document.
o Improved definition of term "802.11-OCB". o Improved definition of term "802.11-OCB".
o Clarified that OCB does not "strip" security, but that the o Clarified that OCB does not "strip" security, but that the
 End of changes. 17 change blocks. 
32 lines changed or deleted 24 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/