--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-12.txt 2018-02-04 09:13:30.498441979 -0800 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-13.txt 2018-02-04 09:13:30.578443876 -0800 @@ -1,26 +1,26 @@ Network Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: July 4, 2018 Moulay Ismail University +Expires: August 8, 2018 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - December 31, 2017 + February 4, 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-12.txt + draft-ietf-ipwave-ipv6-over-80211ocb-13.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,74 +35,74 @@ 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 July 4, 2018. + This Internet-Draft will expire on August 8, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 5 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 - 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8 - 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8 - 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8 - 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 + 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 9 + 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 9 + 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 9 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 9 - 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 + 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 9.2. Informative References . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16 - Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 22 - Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 22 + 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 . . . . . . . . . . . . . . . . 29 + F.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 - Appendix H. Implementation Status . . . . . . . . . . . . . . . 31 - H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32 + Appendix H. Implementation Status . . . . . . . . . . . . . . . 32 + H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 H.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 [IEEE-802.11-2016] (a.k.a "802.11p" see Appendix B). 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 @@ -132,57 +132,68 @@ [I-D.ietf-ipwave-vehicular-networking-survey]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. WiFi: Wireless Fidelity. - OBRU (On-Board Router Unit): an OBRU is almost always situated in a - vehicle; it is a computer with at least two IP real or virtual - interfaces; at least one IP interface runs in OCB mode of 802.11. It - MAY be an IP Router. + IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer + situated in a vehicle such as an automobile, bicycle, or similar. It + has at least one IP interface that runs in mode OCB of 802.11, and + that has an "OBU" transceiver. - OBU (On-Board Unit): term defined outside the IETF. + OBU (On-Board Unit): a term defined outside the IETF. An On-Board + Unit is a DSRC transceiver that is normally mounted in or on a + vehicle, or which in some instances may be a portable unit. An OBU + can be operational while a vehicle or person is either mobile or + stationary. The OBUs receive and contend for time to transmit on one + or more radio frequency (RF) channels. Except where specifically + excluded, OBU operation is permitted wherever vehicle operation or + human passage is permitted. The OBUs mounted in vehicles are + licensed by rule under part 95 of this chapter and communicate with + Roadside Units (RSUs) and other OBUs. Portable OBUs are also + licensed by rule under part 95 of this chapter. OBU operations in + the Unlicensed National Information Infrastructure (UNII) Bands + follow the rules in those bands. - [CFR 90.7 - Definitions]. The US + Federal Communications Commission (FCC) Dedicated Short Range + Communication (DSRC) is defined in the Code of Federal Regulations + (CFR) 47, Parts 90 and 95. At the time of the writing of this + Internet Draft, the last update of this document was dated October + 1st, 2010. - RSRU (Road-Side Router Unit): an RSRU is almost always situated in a - box fixed along the road. An RSRU has at least two distinct IP- - enabled interfaces; at least one interface is operated in mode OCB of - IEEE 802.11 and is IP-enabled. An RSRU is similar to a Wireless - Termination Point (WTP), as defined in [RFC5415], or an Access Point - (AP), as defined in IEEE documents, or an Access Network Router (ANR) - defined in [RFC3753], with one key particularity: the wireless PHY/ - MAC layer of at least one of its IP-enabled interfaces is configured - to operate in 802.11-OCB mode. The RSRU communicates with the OBRU - in the vehicle over 802.11 wireless link operating in OCB mode. An - RSRU 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. + IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. An + IP-RSU has at least two distinct IP-enabled interfaces; at least one + interface is operated in mode OCB of IEEE 802.11 and is IP-enabled. + An IP-RSU is similar to a Wireless Termination Point (WTP), as + defined in [RFC5415], or an Access Point (AP), as defined in IEEE + documents, or an Access Network Router (ANR) defined in [RFC3753], + with one key particularity: the wireless PHY/MAC layer of at least + one of its IP-enabled interfaces is configured to operate in + 802.11-OCB mode. The RSRU communicates with the IP-OBU in the + vehicle over 802.11 wireless link operating in OCB mode. - RSU (Road-Side Unit): an RSU operates in 802.11-OCB mode. A RSU - broadcasts data to OBUs or exchanges data with OBUs in its - communications zone. An RSU may provide channel assignments and - operating instructions to OBUs in its communications zone, when - required. The basic functional blocks of an RSU are: internal - computer processing, permanent storage capability, an integrated GPS - receiver for positioning and timing and an interface that supports - both IPv4 and IPv6 connectivity, compliant with 802.3at. An OCB - interface of an RSU MAY be IP-enabled simultaneously to being WAVE- - enabled or GeoNetworking-enabled (MAY support simultaneously - EtherTypes 0x86DD for IPv6 _and_ 0x88DC for WAVE and 0x8947 for - GeoNetworking). The difference between RSU and RSRU is that an RSU - is likely to have one single OCB interface which is likely not IP - enabled, whereas an RSRU is likely to have one or more OCB interfaces - which are almost always IP-enabled; moreover, an RSRU does IP - forwarding, whereas an RSU does not. + RSU (Road-Side Unit): a term defined outside of IETF. A Roadside + Unit is a DSRC transceiver that is mounted along a road or pedestrian + passageway. An RSU may also be mounted on a vehicle or is hand + carried, but it may only operate when the vehicle or hand- carried + unit is stationary. Furthermore, an RSU operating under this part is + restricted to the location where it is licensed to operate. However, + portable or hand-held RSUs are permitted to operate where they do not + interfere with a site-licensed operation. A RSU broadcasts data to + OBUs or exchanges data with OBUs in its communications zone. An RSU + also provides channel assignments and operating instructions to OBUs + in its communications zone, when required. - [CFR 90.7 - + Definitions]. At the time of the writing of this Internet Draft, the + last update of this document was dated October 1st, 2010. 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. @@ -193,35 +204,35 @@ 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. 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. + vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. 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 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. Maximum Transmission Unit (MTU) - The default MTU for IP packets on 802.11-OCB is 1500 octets. It is - the same value as IPv6 packets on Ethernet links, as specified in + 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 1500 bytes are sent on an 802.11-OCB interface card then the IP stack will fragment. In case there are IP fragments, the field "Sequence number" of the 802.11 Data header containing the IP fragment field is increased. Non-IP packets such as WAVE Short Message Protocol (WSMP) can be @@ -387,21 +398,21 @@ The bits in the interface identifier have no generic meaning and the identifier should be treated as an opaque value. The bits 'Universal' and 'Group' in the identifier of an 802.11-OCB interface are significant, as this is an IEEE link-layer address. The details of this significance are described in [RFC7136]. As with all Ethernet and 802.11 interface identifiers ([RFC7721]), the identifier of an 802.11-OCB interface may involve privacy, MAC address spoofing and IP address hijacking risks. A vehicle embarking - an OBU or an OBRU whose egress interface is 802.11-OCB may expose + an OBU or an IP-OBU 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 F. 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]. Additionally, if semantically opaque Interface Identifiers are needed, a potential method for generating semantically opaque Interface Identifiers with IPv6 Stateless Address @@ -466,21 +477,21 @@ As with all Ethernet and 802.11 interface identifiers, there may exist privacy risks in the use of 802.11-OCB interface identifiers. Moreover, in outdoors vehicular settings, the privacy risks are more important than in indoors settings. New risks are induced by the possibility of attacker sniffers deployed along routes which listen for IP packets of vehicles passing by. For this reason, in the 802.11-OCB deployments, there is a strong necessity to use protection tools such as dynamically changing MAC addresses. This may help mitigate privacy risks to a certain level. On another hand, it may have an impact in the way typical IPv6 address auto-configuration is - performed for vehicles (SLAAC would rely on MAC addresses amd would + performed for vehicles (SLAAC would rely on MAC addresses and would hence dynamically change the affected IP address), in the way the IPv6 Privacy addresses were used, and other effects. 6. IANA Considerations No request to IANA. 7. Contributors Christian Huitema, Tony Li. @@ -719,20 +730,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-12 to draft-ietf-ipwave- + ipv6-over-80211ocb-13 + + o Substituted "IP-OBU" for "OBRU", and "IP-RSU" for "RSRU" + throughout and improved OBU-related definitions in the Terminology + section. + From draft-ietf-ipwave-ipv6-over-80211ocb-11 to draft-ietf-ipwave- ipv6-over-80211ocb-12 o Improved the appendix about "MAC Address Generation" by expressing the technique to be an optional suggestion, not a mandatory mechanism. From draft-ietf-ipwave-ipv6-over-80211ocb-10 to draft-ietf-ipwave- ipv6-over-80211ocb-11 @@ -1048,24 +1065,24 @@ o No IEEE 802.11 Beacon frames are transmitted o No authentication is required in order to be able to communicate o No association is needed in order to be able to communicate 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 (OBRU and RSRU) - receive all the messages transmitted (OBRU and RSRU) within the radio - communications range. The eventual conflict(s) are resolved by the - MAC CDMA function. + 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 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 @@ -1111,22 +1128,22 @@ and 'n' are, 'p' is concerned more with MAC modifications, and a little with PHY modifications; the others are mainly about PHY modifications. It is possible in practice to combine a 'p' MAC with an 'a' PHY by operating outside the context of a BSS with OFDM at 5.4GHz and 5.9GHz. The 802.11-OCB links are specified to be compatible as much as possible with the behaviour of 802.11a/b/g/n and future generation IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer offers practically the same interface to IP as the WiFi and Ethernet - layers do (802.11a/b/g/n and 802.3). A packet sent by an OBRU may be - received by one or multiple RSRUs. The link-layer resolution is + layers do (802.11a/b/g/n and 802.3). A packet sent by an IP-OBU may + be received by one or multiple IP-RSUs. The link-layer resolution is performed by using the IPv6 Neighbor Discovery protocol. To support this similarity statement (IPv6 is layered on top of LLC on top of 802.11-OCB, in the same way that IPv6 is layered on top of LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on top of 802.3 (for Ethernet)) it is useful to analyze the differences between 802.11-OCB and 802.11 specifications. During this analysis, we note that whereas 802.11-OCB lists relatively complex and numerous changes to the MAC layer (and very little to the PHY layer), there are only a few characteristics which may be important for an @@ -1444,20 +1461,27 @@ 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 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 During several capture operations running from a few moments to several hours, no message relevant to the BSSID contexts were