--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-46.txt 2019-06-27 15:13:19.147793121 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-47.txt 2019-06-27 15:13:19.215794840 -0700 @@ -1,24 +1,24 @@ IPWAVE Working Group N. Benamar Internet-Draft Moulay Ismail University Intended status: Standards Track J. Haerri -Expires: December 9, 2019 Eurecom +Expires: December 29, 2019 Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - June 7, 2019 + June 27, 2019 Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) - draft-ietf-ipwave-ipv6-over-80211ocb-46 + draft-ietf-ipwave-ipv6-over-80211ocb-47 Abstract This document provides methods and settings, and describes limitations, for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link with minimal change to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work. Status of This Memo @@ -29,21 +29,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 December 9, 2019. + This Internet-Draft will expire on December 29, 2019. Copyright Notice Copyright (c) 2019 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 @@ -53,38 +53,38 @@ 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 4 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4 - 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9 5.2. MAC Address and Interface ID Generation . . . . . . . . . 9 5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 9.2. Informative References . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16 Appendix C. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver . . . 21 Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22 Appendix E. Design Considerations . . . . . . . . . . . . . . . 23 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23 Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23 G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24 G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27 @@ -94,25 +94,26 @@ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction This document provides a baseline with limitations for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link [IEEE-802.11-2016] (a.k.a "802.11p" see Appendix A, Appendix B and Appendix C) with minimal change to existing stacks. This document describes the layering of IPv6 networking on top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame - translation underneath. The resulting stack operates over 802.11-OCB - and provides at least P2P connectivity using IPv6 ND and link-local - addresses. ND Extensions and IPWAVE optimizations for vehicular - communications are not in scope. The expectation is that further - specs will elaborate for more complex vehicular networking scenarios. + translation underneath. The resulting stack inherits from IPv6 over + Ethernet [RFC 2464] and operates over 802.11-OCB providing at least + P2P connectivity using IPv6 ND and link-local addresses. ND + Extensions and IPWAVE optimizations for vehicular communications are + not in scope. The expectation is that further specs will elaborate + for more complex vehicular networking scenarios. The IPv6 network layer operates on 802.11-OCB in the same manner as operating on Ethernet, but there are two kinds of exceptions: o Exceptions due to different operation of IPv6 network layer on 802.11 than on Ethernet. The operation of IP on Ethernet is described in [RFC1042], [RFC2464] . o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. This has impacts on security, privacy, subnet structure and @@ -205,35 +206,39 @@ 4.3. Link-Local Addresses There are several types of IPv6 addresses [RFC4291], [RFC4193], that MAY be assigned to an 802.11-OCB interface. Among these types of addresses only the IPv6 link-local addresses MAY be formed using an EUI-64 identifier, in particular during transition time. If the IPv6 link-local address is formed using an EUI-64 identifier, then the mechanism of forming that address is the same mechanism as - used to form an IPv6 link-local address on Ethernet links. This - mechanism is described in section 5 of [RFC2464]. + used to form an IPv6 link-local address on Ethernet links. Moreover, + whether or not the interface identifier is derived from the EUI-64 A + identifier, its length is 64 bits as is the case for Ethernet + [RFC2464]. 4.4. Stateless Autoconfiguration The steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 are described in [RFC4862]. This section describes the formation of Interface Identifiers for IPv6 addresses of type 'Global' or 'Unique Local'. For Interface Identifiers for IPv6 address of type 'Link-Local' see Section 4.3. The RECOMMENDED method for forming stable Interface Identifiers (IIDs) is described in [RFC8064]. The method of forming IIDs described in section 4 of [RFC2464] MAY be used during transition - time, in particular for IPv6 link-local addresses. + time, in particular for IPv6 link-local addresses. Regardless of how + to form the Interface Identifier, its length is 64 bits, as is the + case of the IPv6 over Ethernet specification [RFC2464]. 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]. Semantically opaque Interface Identifiers, instead of meaningful Interface Identifiers derived from a valid and meaningful MAC address ([RFC2464], section 4), help avoid certain privacy risks (see the @@ -371,22 +376,23 @@ eavesdropping and subsequent correlation of data; this may reveal data considered private by the vehicle owner; there is a risk of being tracked. In outdoors public environments, where vehicles typically circulate, the privacy risks are more important than in indoors settings. It is highly likely that attacker sniffers are deployed along routes which listen for IEEE frames, including 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 Section 5.2, semantically opaque Interface Identifiers and stable Interface Identifiers - Section 4.4. This may help mitigate privacy risks to a certain - level. + Section 4.4. An example of change policy is to change the MAC + address of the OCB interface each time the system boots upThis may + help mitigate privacy risks to a certain level. 5.1.1. Privacy Risks of Meaningful info in Interface IDs The privacy risks of using MAC addresses displayed in Interface Identifiers are important. The IPv6 packets can be captured easily in the Internet and on-link in public roads. For this reason, an attacker may realize many attacks on privacy. One such attack on 802.11-OCB is to capture, store and correlate Company ID information present in MAC addresses of many cars (e.g. listen for Router Advertisements, or other IPv6 application data packets, and record @@ -1027,22 +1032,21 @@ For information, at the time of writing, this is the list of IEEE 802.11 messages that may be transmitted in OCB mode, i.e. when dot11OCBActivated is true in a STA: o The STA may send management frames of subtype Action and, if the STA maintains a TSF Timer, subtype Timing Advertisement; o The STA may send control frames, except those of subtype PS-Poll, CF-End, and CF-End plus CFAck; - o The STA may send data frames of subtype Data, Null, QoS Data, and - QoS Null. + o The STA MUST send data frames of subtype QoS Data. Appendix G. Examples of Packet Formats 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. @@ -1358,26 +1362,25 @@ all the time and does not meet the DAD requirements for a link local address that could possibly be used anytime, anywhere. The generic expectation of a reliable multicast is not ensured, and the operation of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot be guaranteed. Moreoever, multicast transmissions that rely on broadcast are not only unreliable but are also often detrimental to unicast traffic (see [draft-ietf-mboned-ieee802-mcast-problems]). Early experience indicates that it should be possible to exchange IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR - (Address Resolution) in good conditions. However, this does not - apply if TBD TBD TBD. In the absence of a correct DAD operation, a - node that relies only on IPv6 ND for AR and DAD over OCB should - ensure that the addresses that it uses are unique by means others - than DAD. It must be noted that deriving an IPv6 address from a - globally unique MAC address has this property but may yield privacy + (Address Resolution) in good conditions. In the absence of a correct + DAD operation, a node that relies only on IPv6 ND for AR and DAD over + OCB should ensure that the addresses that it uses are unique by means + others than DAD. It must be noted that deriving an IPv6 address from + a globally unique MAC address has this property but may yield privacy issues. RFC 8505 provides a more recent approach to IPv6 ND and in particular DAD. RFC 8505 is designed to fit wireless and otherwise constrained networks whereby multicast and/or continuous access to the medium may not be guaranteed. RFC 8505 Section 5.6 "Link-Local Addresses and Registration" indicates that the scope of uniqueness for a link local address is restricted to a pair of nodes that use it to communicate, and provides a method to assert the uniqueness and resolve the link- Layer address using a unicast exchange. @@ -1389,24 +1392,24 @@ the registration. The prefix is advertised as not onlink, which means that the 6LN uses the 6LR to relay its packets within the subnet, and participation to the subnet is constrained to the time of reachability to the 6LR. Note that RSU that provides internet connectivity MAY announce a default router preference [RFC 4191], whereas a car that does not provide that connectivity MUST NOT do so. This operation presents similarities with that of an access point, but at Layer-3. This is why RFC 8505 well-suited for wireless in general. - Support of RFC 8505 is may be implemented on OCB. OCB nodes that - support RFC 8505 would support the 6LN operation in order to act as a - host, and may support the 6LR and 6LBR operations in order to act as - a router and in particular own a prefix that can be used by RFC + Support of RFC 8505 may be implemented on OCB. OCB nodes that + support RFC 8505 SHOULD support the 6LN operation in order to act as + a host, and may support the 6LR and 6LBR operations in order to act + as a router and in particular own a prefix that can be used by RFC 8505-compliant hosts for address autoconfiguration and registration. Authors' Addresses Nabil Benamar Moulay Ismail University Morocco Phone: +212670832236 Email: n.benamar@est.umi.ac.ma