--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-36.txt 2019-04-09 10:13:22.370218956 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-37.txt 2019-04-09 10:13:22.458221261 -0700 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: October 10, 2019 Moulay Ismail University +Expires: October 11, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - April 8, 2019 + April 9, 2019 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-36 + draft-ietf-ipwave-ipv6-over-80211ocb-37 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 October 10, 2019. + This Internet-Draft will expire on October 11, 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 @@ -57,54 +57,56 @@ 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 4 - 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 - 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 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. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 10 - 5.2. MAC Address and Interface ID Generation . . . . . . . . . 10 + 5.2. MAC Address and Interface ID Generation . . . . . . . . . 11 5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 27 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 . . . 32 Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 33 Appendix F. Design Considerations . . . . . . . . . . . . . . . 34 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 34 Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 34 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 35 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 + Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless + Links . . . . . . . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 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 @@ -375,22 +377,27 @@ cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. 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] MUST be used over - 802.11-OCB links. + The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used + over 802.11-OCB links. Transmitting ND packets may prove to have + some performance issues. These issues may be exacerbated in OCB + mode. Solutions for these problems SHOULD consider the OCB mode of + operation. The best of current knowledge indicates the kinds of + issues that may arise with ND in OCB mode; they are described in + Appendix J. 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 @@ -742,41 +749,49 @@ http://ieeexplore.ieee.org/document/7435228/ accessed on August 17th, 2017.". [IEEE-802.11-2016] "IEEE Standard 802.11-2016 - IEEE Standard for Information Technology - Telecommunications and information exchange between systems Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. Status - Active Standard. Description - retrieved freely on September 12th, 2017, at URL + retrieved freely; the document itself is also freely + available, but with some difficulty (requires + registration); description and document retrieved on April + 8th, 2019, starting from URL https://standards.ieee.org/findstds/ standard/802.11-2016.html". [IEEE-802.11p-2010] "IEEE Std 802.11p (TM)-2010, IEEE Standard for Information Technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 6: Wireless Access in Vehicular Environments; 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. + -37: added a section about issues on ND wireless; added the qualifier + 'baseline' to using ND on 802.11-OCB; improved the description of the + reference to 802.11-2016 document, with a qualifier about the + difficulty of accessing it, even though it is free. + -36: removed a phrase about the IID formation and MAC generation, but left in the section 5.2 that describes how it happens. -35: addressing the the intarea review: clarified a small apparent contradiction between two parts of text that use the old MAC-based IIDs (clarified by using qualifiers from each other: transition time, and ll addresses); sequenced closer the LL and Stateless Autoconf sections, instead of spacing them; shortened the paragraph of Opaque IIDs; moved the privacy risks of in-clear IIDs in the security section; removed a short phrase duplicating the idea of privacy @@ -1844,20 +1859,94 @@ carried, but it may only operate when the vehicle or hand- carried unit is stationary. Furthermore, an RSU operating under the respectgive 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]. +Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless Links + + IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was designed for + point-to-point and transit links such as Ethernet, with the + expectation of a cheap and reliable support for multicast from the + lower layer. Section 3.2 of RFC 4861 indicates that the operation on + Shared Media and on non-broadcast multi-access (NBMA) networks + require additional support, e.g., for Address Resolution (AR) and + duplicate address detection (DAD), which depend on multicast. An + infrastructureless radio network such as OCB shares properties with + both Shared Media and NBMA networks, and then adds its own + complexity, e.g., from movement and interference that allow only + transient and non-transitive reachability between any set of peers. + + The uniqueness of an address within a scoped domain is a key pillar + of IPv6 and the base for unicast IP communication. RFC 4861 details + the DAD method to avoid that an address is duplicated. For a link + local address, the scope is the link, whereas for a global address + the scope is much larger. The underlying assumption for DAD to + operate correctly is that the node that owns an IPv6 address can + reach any other node within the scope at the time it claims its + address, which is done by sending a NS multicast message, and can + hear any future claim for that address by another party within the + scope for the duration of the address ownership. + + In the case of OCB, there is a potentially a need to define a scope + that is compatible with DAD, and that cannot be the set of nodes that + a transmitter can reach at a particular time, because that set varies + 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 experiences indicate that it should be possible to exchange + IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR + (Address Resolution). 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. + + RFC 8505 also enables a router (acting as a 6LR) to own a prefix and + act as a registrar (acting as a 6LBR) for addresses within the + associated subnet. A peer host (acting as a 6LN) registers an + address derived from that prefix and can use it for the lifetime of + 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 + 8505-compliant hosts for address autoconfiguration and registration. + Authors' Addresses Alexandre Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette , Ile-de-France 91190 France Phone: +33169089223 Email: Alexandre.Petrescu@cea.fr