--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-40.txt 2019-04-16 03:13:44.400850068 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-41.txt 2019-04-16 03:13:44.492852458 -0700 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: October 17, 2019 Moulay Ismail University +Expires: October 18, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - April 15, 2019 + April 16, 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-40 + draft-ietf-ipwave-ipv6-over-80211ocb-41 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 17, 2019. + This Internet-Draft will expire on October 18, 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 @@ -124,21 +124,21 @@ 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. For security and privacy recommendations see Section 5 and Section 4.4. The subnet structure is described in Section 4.6. The movement detection on OCB links is not described in this document. In the published literature, many documents describe aspects and problems related to running IPv6 over 802.11-OCB: - [I-D.ietf-ipwave-vehicular-networking-survey]. + [I-D.ietf-ipwave-vehicular-networking]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer @@ -165,23 +165,22 @@ attribute dot11OCBActivited is true. Note: compliance with standards and regulations set in different countries when using the 5.9GHz frequency band is required. 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 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. + [I-D.ietf-ipwave-vehicular-networking], 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 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. 4. IPv6 over 802.11-OCB 4.1. Maximum Transmission Unit (MTU) @@ -352,25 +351,26 @@ Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues [I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be exacerbated in OCB mode. Solutions for these problems SHOULD consider the OCB mode of operation. 4.6. Subnet Structure A subnet is formed by the external 802.11-OCB interfaces of vehicles - that are in close range (not by their in-vehicle interfaces). This - subnet MUST use at least the link-local prefix and the interfaces - MUST be assigned IPv6 address(es) of type link-local. All nodes in - the subnet MUST be able to communicate directly using their link- - local unicast addresses. + that are in close range (not by their in-vehicle interfaces). A + Prefix List conceptual data structure ([RFC4861] section 5.1) is + maintained for each 802.11-OCB interface. + + All nodes in the subnet MUST be able to communicate directly using + their link-local unicast addresses. The structure of this subnet is ephemeral, in that it is strongly influenced by the mobility of vehicles: the hidden terminal effects appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' networks with an addressing model as described in [RFC5889]. On another hand, the structure of the internal subnets in each car is relatively stable. As recommended in [RFC5889], when the timing requirements are very strict (e.g. fast drive through IP-RSU coverage), no on-link subnet @@ -513,22 +513,22 @@ used relies on (randomized) re-addressing. o A proper pseudonymization tool operated by a trusted third party may be needed to ensure both aspects simultaneously (privacy protection on one hand and trust between participants on another hand). o This is discussed in Section 4.4 and Section 5 of this document. o Pseudonymity is also discussed in - [I-D.ietf-ipwave-vehicular-networking-survey] in its sections - 4.2.4 and 5.1.2. + [I-D.ietf-ipwave-vehicular-networking] in its sections 4.2.4 and + 5.1.2. 6. IANA Considerations No request to IANA. 7. Contributors Christian Huitema, Tony Li. Romain Kuntz contributed extensively about IPv6 handovers between @@ -705,26 +705,25 @@ [ETSI-sec-archi] "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical Specification, Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management, November 2016. Downloaded on September 9th, 2017, freely available from ETSI website at URL http://www.etsi.org/deliver/ etsi_ts/102900_102999/102940/01.02.01_60/ ts_102940v010201p.pdf". - [I-D.ietf-ipwave-vehicular-networking-survey] - Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M. - Wetterwald, "Survey on IP-based Vehicular Networking for - Intelligent Transportation Systems", draft-ietf-ipwave- - vehicular-networking-survey-00 (work in progress), July - 2017. + [I-D.ietf-ipwave-vehicular-networking] + Jeong, J., "IP Wireless Access in Vehicular Environments + (IPWAVE): Problem Statement and Use Cases", draft-ietf- + ipwave-vehicular-networking-08 (work in progress), March + 2019. [I-D.ietf-mboned-ieee802-mcast-problems] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work in progress), November 2018. [IEEE-1609.2] "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Security Services for @@ -769,20 +768,26 @@ 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. + -41: updated a reference from draft-ietf-ipwave-vehicular-networking- + survey to draft-ietf-ipwave-vehicular-networking; clarified the link- + local text by eliminating link-local addresses and prefixes + altogether and referring to RFC4861 which requires the prefixes; + added a statement about the subnet being a not multi-link subnet. + -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".