--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-07.txt 2017-09-19 10:13:18.651742319 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-08.txt 2017-09-19 10:13:18.731744223 -0700 @@ -1,30 +1,30 @@ Network Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: March 21, 2018 Moulay Ismail University +Expires: March 23, 2018 Moulay Ismail University J. Haerri Eurecom C. Huitema Private Octopus Inc. J. Lee Sangmyung University T. Ernst YoGoKo T. Li Peloton Technology - September 17, 2017 + September 19, 2017 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode 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 In order to transmit IPv6 packets on IEEE 802.11 networks running 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 Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB @@ -45,21 +45,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -70,43 +70,43 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 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.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 11 - 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 12 - 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 13 + 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 11 + 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 12 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14 - 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 15 - 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 15 + 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 14 + 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 14 5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 15 5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 16 5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 22 - Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 24 + Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver . . . 28 Appendix C. Design Considerations . . . . . . . . . . . . . . . 29 C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 C.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 - C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31 + C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 Appendix E. Implementation Status . . . . . . . . . . . . . . . 32 E.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 E.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This document describes the transmission of IPv6 packets on IEEE Std @@ -147,21 +147,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (in the above figure, a WiFi profile is represented; this is used also for OCB profile.) A more theoretical and detailed view of layer stacking, and interfaces between the IP layer and 802.11-OCB layers, is illustrated below. The IP layer operates on top of the EtherType Protocol Discrimination (EPD); this Discrimination layer is described in IEEE 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 | +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ { LLC_SAP } 802.11-OCB +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary | EPD | | | | | MLME | | +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | | MAC Sublayer | | | 802.11-OCB @@ -177,21 +177,21 @@ the IPv6 Ethertype. However, there may be some deployment considerations helping optimize 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 consideration of using the IP security architecture [RFC4301]). There are currently no specifications for handover between OCB links since these are currently specified as LLC-1 links (i.e. 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 indicators may be IP Router Advertisements, or 802.11-OCB's Time Advertisements, or application-layer data. However, this document does not describe handover behaviour. The OCB operation is stripped off of all existing 802.11 link-layer security mechanisms. There is no encryption applied below the network layer running on 802.11-OCB. At application layer, the IEEE 1609.2 document [IEEE-1609.2] does provide security services for certain applications to use; application-layer mechanisms are out-of- @@ -270,40 +270,40 @@ 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute dot11OCBActivited is true. The OCB mode requires transmission of QoS data frames (IEEE Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. 3. Communication Scenarios where IEEE 802.11-OCB Links are Used The IEEE 802.11-OCB Networks are used for vehicular communications, as 'Wireless Access in Vehicular Environments'. The IP communication 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 for IP in Intelligent Transportation Systems. 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 is clearly specified, and the use of IPv6 over such link is not radically new, the operating environment (vehicular networks) brings in new perspectives. The 802.11-OCB links form and terminate; nodes connected to these links peer, and discover each other; the nodes are mobile. However, the precise description of how links discover each other, peer and manage mobility is not given in this document. 4. Aspects introduced by the OCB mode to 802.11 In the IEEE 802.11-OCB mode, all nodes in the wireless range can 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 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 discover each other by using the IPv6 Neighbor Discovery protocol. 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 BSSID is set to 1) @@ -418,21 +418,21 @@ described in this document. 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 stations to inform other stations about the value of time. It is similar to the time as delivered by a GNSS system (Galileo, GPS, ...) or by a cellular system. This message is optional for implementation. 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 regional authority (ARCEP, ETSI, FCC, etc.); as part of the regulation process, specific applications are associated with specific frequency ranges. In the case of 802.11-OCB, the regulator associates a set of frequency ranges, or slots within 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 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 exempt from owning a license in EU (in US the 5.9GHz is a licensed @@ -443,35 +443,20 @@ "2.4GHz" or "5GHz". On one hand, the allowed power levels, and implicitly the maximum allowed distance between vehicles, is of 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 approximately 1km, compared to approximately 50m. On the other hand, specific conditions related to congestion avoidance, jamming avoidance, and radar detection are imposed on the use of DSRC (in US) and on the use of frequencies for Intelligent Transportation 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 related to PHY, and thus has not much impact on the interface between the IP layer and the MAC layer. o In vehicular communications using 802.11-OCB links, there are strong privacy requirements with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses, in these settings there exists a strong need for dynamic change of these addresses (as opposed to the non- vehicular settings - real wall protection - where fixed MAC @@ -859,21 +844,21 @@ The authours would like to thank participants to the Birds-of- a-Feather "Intelligent Transportation Systems" meetings held at IETF in 2016. 10. References 10.1. Normative References [I-D.ietf-tsvwg-ieee-802-11] 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. [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, DOI 10.17487/RFC1042, February 1988, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, @@ -1071,20 +1056,27 @@ document freely available at URL http://standards.ieee.org/getieee802/ download/802.11p-2010.pdf retrieved on September 20th, 2013.". Appendix A. ChangeLog The changes are listed in reverse chronological order, most recent 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- 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