--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-30.txt 2018-11-19 10:13:16.041235281 -0800 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-31.txt 2018-11-19 10:13:16.125237261 -0800 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: March 28, 2019 Moulay Ismail University +Expires: May 23, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - September 24, 2018 + November 19, 2018 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-30 + draft-ietf-ipwave-ipv6-over-80211ocb-31 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 @@ -35,21 +35,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 28, 2019. + This Internet-Draft will expire on May 23, 2019. Copyright Notice Copyright (c) 2018 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 @@ -61,49 +61,49 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5 4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5 4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 - 4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 + 4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6 4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 - 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 - 4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 + 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 + 4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8 4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 + 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 11 5.2. MAC Address and Interface ID Generation . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 26 - Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 26 + Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 27 Appendix D. Changes Needed on a software driver 802.11a to - become a 802.11-OCB driver . . . 30 - Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 31 - Appendix F. Design Considerations . . . . . . . . . . . . . . . 32 - Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 + become a 802.11-OCB driver . . . 31 + Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 32 + Appendix F. Design Considerations . . . . . . . . . . . . . . . 33 + Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 33 Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 33 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 34 - H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 36 - Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 37 + Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction 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 Appendix B, Appendix C and Appendix D). 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 expected to IEEE Std 802.11 MAC and Logical Link sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC @@ -182,45 +182,61 @@ brings in new perspectives. The mechanisms for forming and terminating, discovering, peering and mobility management for 802.11-OCB links are not described in this document. 4. IPv6 over 802.11-OCB 4.1. Pseudonym Handling - Pseudonym. + The demand for privacy protection of vehicles' and drivers' + identities, which could be granted by using a pseudonym or alias + identity at the same time, may hamper the required confidentiality of + messages and trust between participants - especially in safety + critical vehicular communication. + + o Particular challenges arise when the pseudonymization mechanism + used relies on (randomized) re-addressing. + + o A proper pseudonymization tool operated by a trusted third party + may be needed to ensure both aspects concurrently. + + o This is discussed in Section 4.6 and Section 5. + + o Pseudonymity is also discussed in + [I-D.ietf-ipwave-vehicular-networking-survey] in sections 4.2.4 + and 5.1.2. 4.2. Maximum Transmission Unit (MTU) The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It is the same value as IPv6 packets on Ethernet links, as specified in [RFC2464]. This value of the MTU respects the recommendation that every link on the Internet must have a minimum MTU of 1280 octets (stated in [RFC8200], and the recommendations therein, especially with respect to fragmentation). 4.3. Frame Format IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE Std 802.11. The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol - Discrimination (EPD), the value of the Type field MUST be set to - 0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub- - field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); - the value of the Traffic Identifier (TID) sub-field of the QoS - Control field of the 802.11 header MUST be set to binary 001 (i.e. - User Priority 'Background', QoS Access Category 'AC_BK'). + Discrimination (EPD, see Appendix E), the value of the Type field + MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the + Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. + 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of + the QoS Control field of the 802.11 header MUST be set to binary 001 + (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY implement an Ethernet Adaptation Layer that translates Ethernet II frames to the 802.11 format and vice versa. An Ethernet Adaptation Layer is described in Section 4.3.1. 4.3.1. Ethernet Adaptation Layer An 'adaptation' layer is inserted between a MAC layer and the @@ -382,22 +399,21 @@ administrator. The way Interface Identifiers are used MAY involve risks to privacy, as described in Section 5.1. 4.7. Subnet Structure A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces). This subnet MUST use at least the link-local prefix fe80::/10 and the - interfaces MUST be assigned IPv6 addresses of type link-local. This - subnet MAY NOT have any other prefix than the link-local prefix. + interfaces MUST be assigned IPv6 addresses of type link-local. The structure of this subnet is ephemeral, in that it is strongly influenced by the mobility of vehicles: the 802.11 hidden node effects appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' networks with an addressing model as described in [RFC5889]. On another hand, the structure of the internal subnets in each car is relatively stable. As recommended in [RFC5889], when the timing requirements are very strict (e.g. fast drive through IP-RSU coverage), no on-link subnet @@ -406,33 +422,30 @@ Additionally, even if the timing requirements are not very strict (e.g. the moving subnet formed by two following vehicles is stable, a fixed IP-RSU is absent), the subnet is disconnected from the Internet (a default route is absent), and the addressing peers are equally qualified (impossible to determine that some vehicle owns and distributes addresses to others) the use of link-local addresses is RECOMMENDED. The Neighbor Discovery protocol (ND) [RFC4861] is used over - 802.11-OCB links. The reliability of the ND protocol over 802.11-OCB - is the reliability of the delivery of ND multicast messages. This - reliability is the same as the reliability of delivery of ND - multicast messages over 802.11 links operated with a BSS ID. + 802.11-OCB links. Due to lack of link-layer acknowledgements in + 802.11-OCB for both unicast and multicast, we can expect higher + unicast loss than for 802.11 BSS. The ND retransmissions are + supposed to handle loss of unicast and/or multicast just as it does + for other link types. - 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. + Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which + depend on timely movement detection, might need additional tuning + work to handle the lack of link-layer notifications during handover. + This is for further study. 5. Security Considerations 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 operating over 802.11-OCB. 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 @@ -543,23 +556,23 @@ The authors would like to thank Witold Klaudel, Ryuji Wakikawa, Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, - Brian Carpenter, Julian Reschke, Mikael Abrahamsson and William - Whyte. Their valuable comments clarified particular issues and - generally helped to improve the document. + Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo, + Lorenzo Colitti and William Whyte. Their valuable comments clarified + particular issues and generally helped to improve the document. Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB drivers for linux and described how. For the multicast discussion, the authors would like to thank Owen DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and participants to discussions in network working groups. The authors would like to thank participants to the Birds-of- a-Feather "Intelligent Transportation Systems" meetings held at IETF @@ -642,20 +655,25 @@ [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, . [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, . + [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for + Detecting Network Attachment in IPv6", RFC 6059, + DOI 10.17487/RFC6059, November 2010, + . + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 @@ -754,20 +772,29 @@ 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. + -31: filled in the section titled "Pseudonym Handling"; removed a + 'MAY NOT' phrase about possibility of having other prefix than the LL + on the link between cars; shortened and improved the paragraph about + Mobile IPv6, now with DNAv6; improved the ND text about ND + retransmissions with relationship to packet loss; changed the title + of an appendix from 'EPD' to 'Protocol Layering'; improved the + 'Aspects introduced by OCB' appendix with a few phrases about the + channel use and references. + -30: a clarification on the reliability of ND over OCB and over 802.11. -29: o -28: o Created a new section 'Pseudonym Handling'. @@ -1205,27 +1234,34 @@ attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated is set to true the IEEE Std 802.11-OCB state is activated. 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. Appendix C. 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 the - same channel number (or frequency) on two stations that need to - communicate with each other. The manner in which stations set their - channel number is not specified in this document. 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. + or association procedures. In OCB mode, the manner in which channels + are selected and used is simplified compared to when in BSS mode. + Contrary to BSS mode, at link layer, it is necessary to set + statically the same channel number (or frequency) on two stations + that need to communicate with each other (in BSS mode this channel + set operation is performed automatically during 'scanning'). The + manner in which stations set their channel number in OCB mode is not + specified in this document. Stations STA1 and STA2 can exchange IP + packets only if they are set on the same channel. At IP layer, they + then discover each other by using the IPv6 Neighbor Discovery + protocol. The allocation of a particular channel for a particular + use is defined statically in standards authored by ETSI (in Europe), + FCC in America, and similar organisations in South Korea, Japan and + other parts of the world. 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) o No IEEE 802.11 Beacon frames are transmitted o No authentication is required in order to be able to communicate @@ -1444,21 +1480,21 @@ Response) and for authentication (Authentication Request/Reply, Challenge) are not called. * The beacon interval is always set to 0 (zero). * Timing Advertisement frames, defined in the amendment, should be supported. The upper layer should be able to trigger such frames emission and to retrieve information contained in received Timing Advertisements. -Appendix E. EtherType Protocol Discrimination (EPD) +Appendix E. Protocol Layering A more theoretical and detailed view of layer stacking, and interfaces between the IP layer and 802.11-OCB layers, is illustrated in Figure 4. 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 Access Point). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 |