--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-39.txt 2019-04-15 05:13:17.488564394 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-40.txt 2019-04-15 05:13:17.588566983 -0700 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: October 16, 2019 Moulay Ismail University +Expires: October 17, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - April 14, 2019 + April 15, 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-39 + draft-ietf-ipwave-ipv6-over-80211ocb-40 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 16, 2019. + This Internet-Draft will expire on October 17, 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 @@ -79,29 +79,29 @@ 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 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 B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 28 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 + Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 35 + H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 36 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40 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 @@ -769,20 +769,24 @@ 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. + -40: added a phrase in appendix to further described a condition + where ND on OCB may not work; that phrase contains a placeholder; the + placeholder is 'TBD' (To Be Defined). + -39: removed a reference to an expired draft trying to update the IPv6-over-Ethernet spec 'RFC2464bis'; added text in the subnet structure section saying nodes MUST be able to communicate directly using their link-local addresses. -38: removed the word "fe80::/10". -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 @@ -1897,23 +1899,24 @@ 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 + 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 the absence of a correct DAD operation, a + (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 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