--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-48.txt 2019-07-08 16:13:22.197421297 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-49.txt 2019-07-08 16:13:22.265423013 -0700 @@ -1,24 +1,24 @@ IPWAVE Working Group N. Benamar -Internet-Draft Moulay Ismail University +Internet-Draft Moulay Ismail University of Meknes Intended status: Standards Track J. Haerri -Expires: January 7, 2020 Eurecom +Expires: January 9, 2020 Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - July 6, 2019 + July 8, 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-48 + draft-ietf-ipwave-ipv6-over-80211ocb-49 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. This support does only require minimal changes to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered in this specification and is subject of future work. @@ -30,21 +30,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 January 7, 2020. + This Internet-Draft will expire on January 9, 2020. 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 @@ -71,52 +71,52 @@ 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 . . . . . . . . . . . . . . . . . . 12 - 9.2. Informative References . . . . . . . . . . . . . . . . . 15 + 9.2. Informative References . . . . . . . . . . . . . . . . . 14 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 Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29 Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Links . . . . . . . . . . . . . . . . . . . . . . . 30 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 Appendicies - Appendix A, Appendix B and Appendix C) with minimal changes to - existing stacks. Moreover, the document identifies limitations of - such usage. Concretly, the 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 inherits from IPv6 over Ethernet [RFC 2464], but operates over - 802.11-OCB to provide at least P2P (Point to Point) connectivity - using IPv6 ND and link-local addresses. + 802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, + Appendix B and Appendix C) with minimal changes to existing stacks. + Moreover, the document identifies limitations of such usage. + Concretly, the 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 inherits + from IPv6 over Ethernet [RFC 2464], but operates over 802.11-OCB to + provide at least P2P (Point to Point) connectivity using IPv6 ND and + link-local addresses. The IPv6 network layer operates on 802.11-OCB in the same manner as - operating on Ethernet with following exceptions: + operating on Ethernet with the following 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 movement detection. Security and privacy recommendations are discussed in Section 5 and Section 4.4. The subnet structure is described in Section 4.6. The movement detection on OCB links is @@ -218,39 +218,39 @@ 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. 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 IP6 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' are discussed in Section 4.3. + interfaces in IPv6 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' are discussed in 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. Regardless of how to form the IID, its length is 64 bits, as is the case of the IPv6 over Ethernet [RFC2464]. The bits in the IID have no specific 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 IIDs, instead of meaningful IIs derived from a + Semantically opaque IIDs, instead of meaningful IIDs derived from a valid and meaningful MAC address ([RFC2464], Section 4), help avoid certain privacy risks (see the risks mentioned in Section 5.1.1). If semantically opaque IIDs are needed, they MAY be generated using the method for generating semantically opaque IIDs with IPv6 Stateless Address Autoconfiguration given in [RFC7217]. Typically, an opaque IID is formed starting from identifiers different than the MAC addresses, and from cryptographically strong material. Thus, privacy sensitive information is absent from Interface IDs, because it is impossible to calculate back the initial value from which the Interface ID was first generated. @@ -265,21 +265,21 @@ 4.5. Address Mapping Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces specified in Sections 6 and 7 of [RFC2464]. 4.5.1. Address Mapping -- Unicast This document is scoped for Address Resolution (AR) and Duplicate - Address Detection (DAD) per RFC 4861 [RFC4861]. + Address Detection (DAD) per [RFC4862]. 4.5.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" mentioned in that section 7 of [RFC2464] is defined in section 2.3.1 of [RFC7042]. Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues @@ -527,42 +527,20 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, - DOI 10.17487/RFC2818, May 2000, - . - - [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related - Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, - . - - [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. - Thubert, "Network Mobility (NEMO) Basic Support Protocol", - RFC 3963, DOI 10.17487/RFC3963, January 2005, - . - - [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, - "SEcure Neighbor Discovery (SEND)", RFC 3971, - DOI 10.17487/RFC3971, March 2005, - . - - [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", - RFC 3972, DOI 10.17487/RFC3972, March 2005, - . - [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, @@ -727,20 +705,38 @@ 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.". + [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related + Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, + . + + [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. + Thubert, "Network Mobility (NEMO) Basic Support Protocol", + RFC 3963, DOI 10.17487/RFC3963, January 2005, + . + + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + DOI 10.17487/RFC3971, March 2005, + . + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, DOI 10.17487/RFC3972, March 2005, + . + Appendix A. 802.11p The term "802.11p" is an earlier definition. The behaviour of "802.11p" networks is rolled in the document IEEE Std 802.11-2016. In that document the term 802.11p disappears. Instead, each 802.11p feature is conditioned by the IEEE Management Information Base (MIB) attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated is set to true the IEEE Std 802.11-OCB state is activated. For example, an 802.11 STAtion operating outside the context of a basic service set has the OCBActivated flag set. Such a station, when it @@ -1408,21 +1405,21 @@ 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 + Moulay Ismail University of Meknes Morocco Phone: +212670832236 Email: n.benamar@est.umi.ac.ma Jerome Haerri Eurecom Sophia-Antipolis 06904 France