--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt 2017-09-12 11:13:10.400546806 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-06.txt 2017-09-12 11:13:10.484548834 -0700 @@ -1,30 +1,30 @@ Network Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: March 14, 2018 Moulay Ismail University +Expires: March 16, 2018 Moulay Ismail University J. Haerri Eurecom C. Huitema Private Octopus Inc. J. Lee Sangmyung University T. Ernst YoGoKo T. Li Peloton Technology - September 10, 2017 + September 12, 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-05.txt + draft-ietf-ipwave-ipv6-over-80211ocb-06.txt Abstract In order to transmit IPv6 packets on IEEE 802.11 networks run 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 similarly to @@ -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 14, 2018. + This Internet-Draft will expire on March 16, 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 @@ -74,66 +74,66 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 6 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 . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 13 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 14 - 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 14 + 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 10.2. Informative References . . . . . . . . . . . . . . . . . 21 + 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver . . . 27 - Appendix C. Design Considerations . . . . . . . . . . . . . . . 28 - C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 28 + Appendix C. Design Considerations . . . . . . . . . . . . . . . 29 + C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 C.2. Reliability Requirements . . . . . . . . . . . . . . . . 29 C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 - C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 30 + C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 - Appendix E. Implementation Status . . . . . . . . . . . . . . . 31 + Appendix E. Implementation Status . . . . . . . . . . . . . . . 32 E.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32 - E.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + E.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This document describes the transmission of IPv6 packets on IEEE Std - 802.11-OCB networks (earlier known as 802.11p) [IEEE-802.11-2012]. + 802.11-OCB networks (earlier known as 802.11p) [IEEE-802.11-2016]. This involves the layering of IPv6 networking on top of the IEEE 802.11 MAC layer (with an LLC layer). Compared to running IPv6 over the Ethernet MAC layer, there is no modification required to the standards: IPv6 works fine directly over 802.11-OCB too (with an LLC layer). - The term "802.11p" is an earlier definition. As of year 2012, the - behaviour of "802.11p" networks has been rolled in the document IEEE - Std 802.11-2012. In that document the term 802.11p disappears. - Instead, each 802.11p feature is conditioned by a flag in the - Management Information Base. That flag is named "OCBActivated". - Whenever OCBActivated is set to true the feature it relates to, or - represents, an earlier 802.11p feature. For example, an 802.11 - STAtion operating outside the context of a basic service set has the - OCBActivated flag set. Such a station, when it has the flag set, - uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. + The term "802.11p" is an earlier definition. The behaviour of + "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 + feature is conditioned by a flag in the Management Information Base. + That flag is named "OCBActivated". Whenever OCBActivated is set to + true the feature it relates to, or represents, an earlier 802.11p + feature. For example, an 802.11 STAtion operating outside the + context of a basic service set has the OCBActivated flag set. Such a + station, when it has the flag set, uses a BSS identifier equal to + ff:ff:ff:ff:ff:ff. 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 IPv6 network layer operates on WiFi by involving an Ethernet Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers to Ethernet II headers. The operation of IP on Ethernet is described in [RFC1042], [RFC2464] and [I-D.hinden-6man-rfc2464bis]. The situation of IPv6 networking layer on Ethernet Adaptation Layer is illustrated below: @@ -245,21 +245,21 @@ The RSU communicates with the On board Unit (OBU) in the vehicle over 802.11 wireless link operating in OCB mode. An RSU 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. 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 utilize IEEE Std 802.11 authentication, association, or data confidentiality. - 802.11-OCB, or 802.11-OCB: text in document IEEE 802.11-2012 that is + 802.11-OCB, or 802.11-OCB: text in document IEEE 802.11-2016 that is flagged by "dot11OCBActivated". The text flagged "dot11OCBActivated" includes IEEE 802.11e for quality of service, 802.11j-2004 for half- clocked operations and (what was known earlier as) 802.11p for operation in the 5.9 GHz band and in mode OCB. 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 @@ -330,32 +330,32 @@ |<--- Asso Res. -------| | | | | |<------ Data -------->| |<------ Data -------->| | | |<------ Data -------->| |<------ Data -------->| (a) 802.11 Infrastructure mode (b) 802.11-OCB mode The link 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, titled "Amendment 6: Wireless Access in Vehicular Environments". - Since then, this amendment has been included in IEEE 802.11(TM)-2012 - [IEEE-802.11-2012], titled "IEEE Standard for Information + Since then, this amendment has been included in IEEE 802.11(TM)-2016 + [IEEE-802.11-2016], titled "IEEE Standard for Information 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-2012, specifically anything referring + In document 802.11-2016, anything qualified specifically as "OCBActivated", or "outside the context of a basic service set" is actually referring to OCB aspects introduced to 802.11. Note that in earlier 802.11p documents the term "OCBEnabled" was used instead of the current "OCBActivated". 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 concerned with vehicular communications, where the wireless link is 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 @@ -620,21 +620,26 @@ "Traffic Class", "Flow label") and fields in the "802.11 QoS Data Header" (e.g. "QoS Control") are not specified in this document. Guidance for a potential mapping is provided in [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB mode. 5.3. Link-Local Addresses The link-local address of an 802.11-OCB interface is formed in the same manner as on an Ethernet interface. This manner is described in - section 5 of [RFC2464]. + section 5 of [RFC2464]. Additionally, if stable identifiers are + needed, it is recommended to follow the Recommendation on Stable IPv6 + Interface Identifiers [RFC8064]. Additionally, if semantically + opaque Interface Identifiers are needed, a potential method for + generating semantically opaque Interface Identifiers with IPv6 + Stateless Address Autoconfiguration is given in [RFC7217]. 5.4. Address Mapping For unicast as for multicast, there is no change from the unicast and multicast address mapping format of Ethernet interfaces, as defined by sections 6 and 7 of [RFC2464]. 5.4.1. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into Ethernet link- @@ -724,21 +729,24 @@ the identifier of an 802.11-OCB interface may involve privacy, MAC address spoofing and IP address hijacking risks. A vehicle embarking an On-Board Unit whose egress interface is 802.11-OCB may expose itself to eavesdropping and subsequent correlation of data; this may reveal data considered private by the vehicle owner; there is a risk of being tracked; see the privacy considerations described in Appendix C. If stable Interface Identifiers are needed in order to form IPv6 addresses on 802.11-OCB links, it is recommended to follow the - recommendation in [RFC8064]. + recommendation in [RFC8064]. Additionally, if semantically opaque + Interface Identifiers are needed, a potential method for generating + semantically opaque Interface Identifiers with IPv6 Stateless Address + Autoconfiguration is given in [RFC7217]. 5.6. Subnet Structure A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not their on-board interfaces). This ephemeral subnet structure is strongly influenced by the mobility of vehicles: the 802.11 hidden node effects appear. On another hand, the structure of the internal subnets in each car is relatively stable. @@ -939,20 +945,26 @@ [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, . + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + . + [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . @@ -1021,49 +1033,57 @@ Example URL http://ieeexplore.ieee.org/document/7458115/ accessed on August 17th, 2017.". [IEEE-1609.4] "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Multi-Channel Operation. Example URL http://ieeexplore.ieee.org/document/7435228/ accessed on August 17th, 2017.". - [IEEE-802.11-2012] - "802.11-2012 - IEEE Standard for Information 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. Downloaded - on October 17th, 2013, from IEEE Standards, document - freely available at URL - http://standards.ieee.org/findstds/ - standard/802.11-2012.html retrieved on October 17th, - 2013.". + [IEEE-802.11-2016] + "IEEE Standard 802.11-2016 - IEEE Standard for Information + 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. Status - Active Standard. Description + retrieved freely on September 12th, 2017, at URL + https://standards.ieee.org/findstds/ + standard/802.11-2016.html". [IEEE-802.11p-2010] "IEEE Std 802.11p (TM)-2010, IEEE Standard for Information 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, Amendment 6: Wireless Access in Vehicular Environments; 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-05 to draft-ietf-ipwave- + ipv6-over-80211ocb-06 + + o Updated references of 802.11-OCB document from -2012 to the IEEE + 802.11-2016. + + o In the LL address section, and in SLAAC section, added references + to 7217 opaque IIDs and 8064 stable IIDs. + From draft-ietf-ipwave-ipv6-over-80211ocb-04 to draft-ietf-ipwave- ipv6-over-80211ocb-05 o Lengthened the title and cleanded the abstract. o Added text suggesting LLs may be easy to use on OCB, rather than GUAs based on received prefix. o Added the risks of spoofing and hijacking.