--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-19.txt 2018-03-02 02:13:09.289645084 -0800 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-20.txt 2018-03-02 02:13:09.365646879 -0800 @@ -1,26 +1,26 @@ Network Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: August 26, 2018 Moulay Ismail University +Expires: September 3, 2018 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - February 22, 2018 + March 2, 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-19.txt + draft-ietf-ipwave-ipv6-over-80211ocb-20.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 26, 2018. + This Internet-Draft will expire on September 3, 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 @@ -63,31 +63,31 @@ 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 . . . . . . . . . . . . . . . . . . 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 + 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 + 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 + 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 + 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 9.2. Informative References . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . 13 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 @@ -154,25 +154,23 @@ one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode. The IP-RSU communicates with the IP-OBU in the vehicle over 802.11 wireless link operating in OCB mode. 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: 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. - Nota: any implementation should comply with standards and regulations - set in the different countries for using that frequency band. + attribute dot11OCBActivited is true. Note: compliance with standards + and regulations set in different countries when using the 5.9GHz + frequency band is required. 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; in particular, we refer the reader to [I-D.ietf-ipwave-vehicular-networking-survey], that lists some scenarios and requirements for IP in Intelligent Transportation Systems. @@ -194,117 +192,91 @@ 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.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 + packets. As with all 802.11 frames, an Ethernet adaptation layer + MUST be 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]. + The Frame format for transmitting IPv6 on 802.11-OCB networks MUST be + the same as transmitting IPv6 on Ethernet networks, and is described + in section 3 of [RFC2464]. 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 - Logical-Link Layer Control Header and produces an Ethernet II Header. - At sending, the reverse operation is performed. + this layer takes as input the IEEE 802.11 header and the Logical-Link + Layer Control Header and produces an Ethernet II Header. At sending, + the reverse operation is performed. The operation of the Ethernet Adaptation Layer is depicted by the double arrow in Figure 1. +--------------------+------------+-------------+---------+-----------+ - | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| + | 802.11 header | LLC Header | IPv6 Header | Payload |.11 Trailer| +--------------------+------------+-------------+---------+-----------+ \ / \ / ----------------------------- -------- \---------------------------------------------/ ^ | 802.11-to-Ethernet Adaptation Layer | v +---------------------+-------------+---------+ | Ethernet II Header | IPv6 Header | Payload | +---------------------+-------------+---------+ 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 + The Receiver and Transmitter Address fields in the 802.11 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. - 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 "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 specification of which type or subtype of 802.11 headers are used + to transmit IP packets is left outside the scope of this document. The placement of IPv6 networking layer on Ethernet Adaptation Layer - is illustrated in Figure 3. + is illustrated in Figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Adaptation Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 3: Ethernet Adaptation Layer stacked with other layers + Figure 2: Ethernet Adaptation Layer stacked with other layers (in the above figure, a 802.11 profile is represented; this is used 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 Interface Identifiers [RFC8064]. Additionally, if semantically @@ -674,20 +646,32 @@ 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-19 to draft-ietf-ipwave- + ipv6-over-80211ocb-20 + + o Reduced the definition of term "802.11-OCB". + + o Left out of this specification which 802.11 header to use to + transmit IP packets in OCB mode (QoS Data header, Data header, or + any other). + + o Added 'MUST' use an Ethernet Adaptation Layer, instead of 'is + using' an Ethernet Adaptation Layer. + 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. @@ -1074,21 +1059,21 @@ o No encryption is provided in order to be able to communicate o Flag dot11OCBActivated is set to true All the nodes in the radio communication range (IP-OBU and IP-RSU) receive all the messages transmitted (IP-OBU and IP-RSU) within the radio communications range. The eventual conflict(s) are resolved by the MAC CDMA function. - The message exchange diagram in Figure 4 illustrates a comparison + The message exchange diagram in Figure 3 illustrates a comparison between traditional 802.11 and 802.11 in OCB mode. The 'Data' messages can be IP packets such as HTTP or others. Other 802.11 management and control frames (non IP) may be transmitted, as specified in the 802.11 standard. For information, the names of these messages as currently specified by the 802.11 standard are listed in Appendix G. STA AP STA1 STA2 | | | | |<------ Beacon -------| |<------ Data -------->| @@ -1100,21 +1085,21 @@ |<--- Auth Res. -------| |<------ Data -------->| | | | | |---- Asso Req. ------>| |<------ Data -------->| |<--- Asso Res. -------| | | | | |<------ Data -------->| |<------ Data -------->| | | |<------ Data -------->| |<------ Data -------->| (i) 802.11 Infrastructure mode (ii) 802.11-OCB mode - Figure 4: Difference between messages exchanged on 802.11 (left) and + Figure 3: Difference between messages exchanged on 802.11 (left) and 802.11-OCB (right) The interface 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 integrated in IEEE 802.11(TM) -2012 and -2016 [IEEE-802.11-2016]. In document 802.11-2016, anything qualified specifically as "OCBActivated", or "outside the context of a basic service" set to be @@ -1294,41 +1280,41 @@ * 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) A more theoretical and detailed view of layer stacking, and interfaces between the IP layer and 802.11-OCB layers, is illustrated - in Figure 5. The IP layer operates on top of the EtherType Protocol + 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 | +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ { LLC_SAP } 802.11-OCB +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary | EPD | | | | | MLME | | +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | | MAC Sublayer | | | 802.11-OCB | and ch. coord. | | SME | Services +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | | | PLME | | | PHY Layer | PLME_SAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 5: EtherType Protocol Discrimination + Figure 4: EtherType Protocol Discrimination Appendix F. Design Considerations The networks defined by 802.11-OCB are in many ways similar to other networks of the 802.11 family. In theory, the encapsulation of IPv6 over 802.11-OCB could be very similar to the operation of IPv6 over other networks of the 802.11 family. However, the high mobility, strong link asymmetry and very short connection makes the 802.11-OCB link significantly different from other 802.11 networks. Also, the automotive applications have specific requirements for reliability, @@ -1458,41 +1444,41 @@ Appendix H. Implementation Status This section describes an example of an IPv6 Packet captured over a IEEE 802.11-OCB link. By way of example we show that there is no modification in the headers when transmitted over 802.11-OCB networks - they are transmitted like any other 802.11 and Ethernet packets. We describe an experiment of capturing an IPv6 packet on an - 802.11-OCB link. In topology depicted in Figure 6, the packet is an + 802.11-OCB link. In topology depicted in Figure 5, the packet is an IPv6 Router Advertisement. This packet is emitted by a Router on its 802.11-OCB interface. The packet is captured on the Host, using a network protocol analyzer (e.g. Wireshark); the capture is performed in two different modes: direct mode and 'monitor' mode. The topology used during the capture is depicted below. The packet is captured on the Host. The Host is an IP-OBU containing an 802.11 interface in format PCI express (an ITRI product). The kernel runs the ath5k software driver with modifications for OCB mode. The capture tool is Wireshark. The file format for save and analyze is 'pcap'. The packet is generated by the Router. The Router is an IP-RSU (ITRI product). +--------+ +-------+ | | 802.11-OCB Link | | ---| Router |--------------------------------| Host | | | | | +--------+ +-------+ - Figure 6: Topology for capturing IP packets on 802.11-OCB + Figure 5: Topology for capturing IP packets on 802.11-OCB During several capture operations running from a few moments to several hours, no message relevant to the BSSID contexts were captured (no Association Request/Response, Authentication Req/Resp, Beacon). This shows that the operation of 802.11-OCB is outside the context of a BSSID. Overall, the captured message is identical with a capture of an IPv6 packet emitted on a 802.11b interface. The contents are precisely similar.