--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-18.txt 2018-02-22 05:13:23.318768765 -0800 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-19.txt 2018-02-22 05:13:23.402770744 -0800 @@ -1,26 +1,26 @@ Network Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: August 23, 2018 Moulay Ismail University +Expires: August 26, 2018 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - February 19, 2018 + February 22, 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-18.txt + draft-ietf-ipwave-ipv6-over-80211ocb-19.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 @@ -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 August 23, 2018. + This Internet-Draft will expire on August 26, 2018. 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,34 +61,34 @@ 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. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 - 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8 - 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 + 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 14 - Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16 + Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 23 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 23 Appendix D. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver . . . 27 Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 28 Appendix F. Design Considerations . . . . . . . . . . . . . . . 29 F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 F.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 @@ -189,51 +189,35 @@ 4. IPv6 over 802.11-OCB 4.1. 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). If IPv6 packets of size larger than - the MTU are sent on an 802.11-OCB interface card then the IP stack - MUST fragment. In case there are IPv6 fragments, the subfield - "Fragment number" within the field "Sequence control" of the 802.11 - Data header containing the IPv6 fragment is increased by the MAC - layer. - - Non-IP packets such as WAVE Short Message Protocol (WSMP) can be - delivered on 802.11-OCB links. Specifications of these packets are - out of scope of this document, and do not impose any limit on the MTU - size, allowing an arbitrary number of 'containers'. Non-IP packets - such as ETSI GeoNetworking packets have an MTU of 1492 bytes. The - operation of IPv6 over GeoNetworking is specified at - [ETSI-IPv6-GeoNetworking]. + with respect to fragmentation). 4.2. Frame Format IP packets are transmitted over 802.11-OCB as standard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation layer is used with 802.11-OCB as well. This Ethernet Adaptation Layer performing 802.11-to-Ethernet is described in Section 4.2.1. The Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD (hexadecimal 86DD, or otherwise #86DD). The Frame format for transmitting IPv6 on 802.11-OCB networks is the same as transmitting IPv6 on Ethernet networks, and is described in section 3 of [RFC2464]. - 1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 - is the binary representation of the EtherType value 0x86DD. - 4.2.1. Ethernet Adaptation Layer An 'adaptation' layer is inserted between a MAC layer and the Networking layer. This is used to transform some parameters between their form expected by the IP stack and the form provided by the MAC layer. An Ethernet Adaptation Layer makes an 802.11 MAC look to IP Networking layer as a more traditional Ethernet layer. At reception, this layer takes as input the IEEE 802.11 Data Header and the @@ -261,44 +245,40 @@ Figure 1: Operation of the Ethernet Adaptation Layer The Receiver and Transmitter Address fields in the 802.11 Data Header MUST contain the same values as the Destination and the Source Address fields in the Ethernet II Header, respectively. The value of the Type field in the LLC Header MUST be the same as the value of the Type field in the Ethernet II Header. The ".11 Trailer" contains solely a 4-byte Frame Check Sequence. - Additionally, the Ethernet Adaptation Layer performs operations in - relation to IP fragmentation and MTU. One of these operations is - briefly described in Section 4.1. - In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in Figure 2. +--------------------+-------------+-------------+---------+-----------+ | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| +--------------------+-------------+-------------+---------+-----------+ or +--------------------+-------------+-------------+---------+-----------+ | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer| +--------------------+-------------+-------------+---------+-----------+ Figure 2: 802.11 Data Header or 802.11 QoS Data Header The distinction between the two formats is given by the value of the - field "Type/Subtype". The value of the field "Type/Subtype" in the - 802.11 Data header is 0x0020. The value of the field "Type/Subtype" - in the 802.11 QoS header is 0x0028. + field "Subtype" in the Frame Control Field. The value of the field + "Subtype" in the 802.11 Data header is 0x0. The value of the field + "Subtype" in the 802.11 QoS header is 8. The mapping between qos-related fields in the IPv6 header (e.g. "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. The placement of IPv6 networking layer on Ethernet Adaptation Layer is illustrated in Figure 3. @@ -319,31 +299,30 @@ also for 802.11 OCB profile.) Other alternative views of layering are EtherType Protocol Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. 4.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]. Additionally, if stable identifiers are - needed, it is recommended to follow the Recommendation on Stable IPv6 + 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]. 4.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]. + Unicast and multicast address mapping MUST follow the procedures + specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. 4.4.1. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into Ethernet link- layer addresses is described in [RFC4861]. 4.4.2. Address Mapping -- Multicast The multicast address mapping is performed according to the method specified in section 7 of [RFC2464]. The meaning of the value "3333" @@ -392,27 +371,20 @@ 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. The 802.11 networks in OCB mode may be considered as 'ad-hoc' networks. The addressing model for such networks is described in [RFC5889]. - An addressing model involves several types of addresses, like - Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique - Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may - have characteristics that lead to difficulty of using GUAs derived - from a received prefix, but the LL addresses may be easier to use - 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 @@ -621,31 +593,20 @@ RFC 8064, DOI 10.17487/RFC8064, February 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 9.2. Informative References - [ETSI-IPv6-GeoNetworking] - "ETSI EN 302 636-6-1 v1.2.1 (2014-05), ETSI, European - Standard, Intelligent Transportation Systems (ITS); - Vehicular Communications; Geonetworking; Part 6: Internet - Integration; Sub-part 1: Transmission of IPv6 Packets over - Geonetworking Protocols. Downloaded on September 9th, - 2017, freely available from ETSI website at URL - http://www.etsi.org/deliver/ - etsi_en/302600_302699/30263601/01.02.01_60/ - en_30263601v010201p.pdf". - [ETSI-sec-archi] "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical Specification, Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management, November 2016. Downloaded on September 9th, 2017, freely available from ETSI website at URL http://www.etsi.org/deliver/ etsi_ts/102900_102999/102940/01.02.01_60/ ts_102940v010201p.pdf". @@ -713,20 +674,41 @@ 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-18 to draft-ietf-ipwave- + ipv6-over-80211ocb-19 + + o Removed the text about fragmentation. + + o Removed the mentioning of WSMP and GeoNetworking. + + o Removed the explanation of the binary representation of the + EtherType. + + o Rendered normative the paragraph about unicast and multicast + address mapping. + + o Removed paragraph about addressing model, subnet structure and + easiness of using LLs. + + o Clarified the Type/Subtype field in the 802.11 Header. + + o Used RECOMMENDED instead of recommended, for the stable interface + identifiers. + From draft-ietf-ipwave-ipv6-over-80211ocb-17 to draft-ietf-ipwave- ipv6-over-80211ocb-18 o Improved the MTU and fragmentation paragraph. From draft-ietf-ipwave-ipv6-over-80211ocb-16 to draft-ietf-ipwave- ipv6-over-80211ocb-17 o Susbtituted "MUST be increased" to "is increased" in the MTU section, about fragmentation.