Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt
Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 30 August 2017 14:33 UTC
Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B257132DBF for <its@ietfa.amsl.com>; Wed, 30 Aug 2017 07:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2COlFLxXi9Y for <its@ietfa.amsl.com>; Wed, 30 Aug 2017 07:33:25 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFF5132DFA for <its@ietf.org>; Wed, 30 Aug 2017 07:33:17 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v7UEXC9Q134877; Wed, 30 Aug 2017 16:33:12 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6DCB3205AAF; Wed, 30 Aug 2017 16:33:12 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 539E1205AAB; Wed, 30 Aug 2017 16:33:12 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7UEXCqj026057; Wed, 30 Aug 2017 16:33:12 +0200
To: Sri Gundavelli <sgundave@cisco.com>
References: <D5C8D565.22C0C0%sgundave@cisco.com>
Cc: its@ietf.org
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <45acdd94-a77f-14aa-c606-d9f506c9b21d@gmail.com>
Date: Wed, 30 Aug 2017 16:33:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <D5C8D565.22C0C0%sgundave@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/lgQAM6sCT9O2BE49Me1nI_LT7GU>
Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Aug 2017 14:33:34 -0000
Sri, I want to let you know I have today finished to read the entire set of comments. I will try to address them soon. Alex Le 28/08/2017 à 05:00, Sri Gundavelli (sgundave) a écrit : > > Attached is my review feedback. > > In general there is lot of good information in the document. But, > there are also few areas where additional clarifications will greatly > help. > > 1.) Its not clear, if the document makes any assumption on the > operating environment/communication profile. There is not much > discussion on that aspect; For example, Is it always a one-hop > communication between RSU and OBU where the 802.11-OCB link? So, is > the use of IPv6 only in that context of 1-hop communication? > > 2.) There is also no discussion on how these links get formed in > vehicular environment and when they are attached/detached. > > 3.) How do nodes discover each other? How does ND resolution work? > Are these messages received by a multiple RSU’s, or a single RSU? > Whats the implication of that. Note that you don’t have that issue in > 802.11, given the association to an access point, which in turn maps > the links to a VLAN/subnet. > > 4.) What happens as a vehicle moves between RSU’s, how does it impact > address configuration? Is DHCPv6 based address configuration > relevant here? > > > Please see inline for additional comments. > [...] > > Transmission of IPv6 Packets over IEEE 802.11 Networks in mode > Outside > > > > > > the Context of a Basic Service Set (IPv6-over-80211ocb) > > > > > > draft-ietf-ipwave-ipv6-over-80211ocb-04.txt > > > > > [Sri] May be change to, “..in mode .." —> “..operating in mode ..”? > > > > Abstract > > In order to transmit IPv6 packets on IEEE 802.11 networks run > outside the context of a basic service set (OCB, earlier "802.11p") > there is a need to define a few parameters such as the recommended > Maximum Transmission Unit size, 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 similarly to other known > 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. > > [Sri] Is it “recommended MTU size", or "supported MTU size on the > 802.11 OCB link? > > > > In addition, the document attempts to list what is different in > 802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n > layers, layers over which IPv6 protocols operates without issues. > Most notably, the operation outside the context of a BSS (OCB) has > impact on IPv6 handover behaviour and on IPv6 security. > > [Sri] Minor comment. May be instead of using the “layer” terminology, > you may want to present this as IPv6 support on "802.11 OCB" links. > > > An example of an IPv6 packet captured while transmitted over an IEEE > 802.11 OCB link (802.11p) is given. > > [Sri] Last paragraph can be ommitted in my view. That’s too much of > detail for Abstract. > > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions ofBCP 78 <https://tools.ietf.org/html/bcp78> andBCP 79 > <https://tools.ietf.org/html/bcp79>. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > > > > Petrescu, et al. Expires February 18, 2018 [Page 1] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-2> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > working documents as Internet-Drafts. The list of current Internet- > Drafts is athttp://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 February 18, 2018. > > Copyright Notice > > Copyright (c) 2017 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject toBCP 78 <https://tools.ietf.org/html/bcp78> > and the IETF Trust's Legal Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with > respect 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 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-1>. > Introduction . . . . . . . . . . . . . . . . . . . . . . . .3 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-3> > > 2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-2>. > Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-5> > > 3. Communication Scenarios where IEEE 802.11 OCB Links are Used 6 > 4 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-4>. > Aspects introduced by the OCB mode to 802.11 . . . . . . . .6 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-6> > > 5 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5>. > Layering of IPv6 over 802.11-OCB as over Ethernet . . . . . .10 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-10> > > 5.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.1>. > Maximum Transmission Unit (MTU) . . . . . . . . . . . . .10 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-10> > > 5.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.2>. > Frame Format . . . . . . . . . . . . . . . . . . . . . .11 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-11> > > 5.2.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.2.1>. > Ethernet Adaptation Layer . . . . . . . . . . . . . .12 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-12> > > 5.3 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.3>. > Link-Local Addresses . . . . . . . . . . . . . . . . . .13 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-13> > > 5.4 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.4>. > Address Mapping . . . . . . . . . . . . . . . . . . . . .14 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-14> > > 5.4.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.4.1>. > Address Mapping -- Unicast . . . . . . . . . . . . .14 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-14> > > 5.4.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.4.2>. > Address Mapping -- Multicast . . . . . . . . . . . .14 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-14> > > 5.5 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.5>. > Stateless Autoconfiguration . . . . . . . . . . . . . . .15 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-15> > > 5.6 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.6>. > Subnet Structure . . . . . . . . . . . . . . . . . . . .16 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-16> > > 6 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6>. > Example IPv6 Packet captured over a IEEE 802.11-OCB link . .16 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-16> > > 6.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6.1>. > Capture in Monitor Mode . . . . . . . . . . . . . . . . .17 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-17> > > 6.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6.2>. > Capture in Normal Mode . . . . . . . . . . . . . . . . .19 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-19> > > 7 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-7>. > Security Considerations . . . . . . . . . . . . . . . . . . .21 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-21> > > 8 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-8>. > IANA Considerations . . . . . . . . . . . . . . . . . . . . .22 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-22> > > 9 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-9>. > Contributors . . . . . . . . . . . . . . . . . . . . . . . .22 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-22> > > 10 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-10>. > Acknowledgements . . . . . . . . . . . . . . . . . . . . . .22 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-22> > > > > > Petrescu, et al. Expires February 18, 2018 [Page 2] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-3> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > 11 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-11>. > References . . . . . . . . . . . . . . . . . . . . . . . . .23 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-23> > > 11.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-11.1>. > Normative References . . . . . . . . . . . . . . . . . .23 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-23> > > 11.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-11.2>. > Informative References . . . . . . . . . . . . . . . . .24 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-24> > > Appendix A > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-A>. > ChangeLog . . . . . . . . . . . . . . . . . . . . .26 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-26> > > Appendix B > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-B>. > Changes Needed on a software driver 802.11a to become a > 802.11-OCB driver . . .28 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-28> > > Appendix C > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C>. > Design Considerations . . . . . . . . . . . . . . .30 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-30> > > C.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.1>. > Vehicle ID . . . . . . . . . . . . . . . . . . . . . . .30 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-30> > > C.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.2>. > Reliability Requirements . . . . . . . . . . . . . . . .30 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-30> > > C.3 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.3>. > Multiple interfaces . . . . . . . . . . . . . . . . . . .31 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-31> > > C.4 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.4>. > MAC Address Generation . . . . . . . . . . . . . . . . .32 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-32> > > Appendix D > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-D>. > IEEE 802.11 Messages Transmitted in OCB mode . . . .32 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-32> > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .32 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-32> > > > > 1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-1>. > > Introduction > > > > This document describes the transmission of IPv6 packets on IEEE Std > 802.11 OCB networks (earlier known as 802.11p). > > > [Sri] Please add a reference to the IEEE specification that defines > the OCB mode. > > > > 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 required to the > standards: IPv6 works fine directly over 802.11 OCB too (with an LLC > layer). > > The term "802.11p" is an earlier definition. As of year 2012, the > behaviour of "802.11p" networks has been rolled in the document IEEE > Std 802.11-2012. In this document the term 802.11p disappears. > Instead, each 802.11p feature is conditioned by a flag in the > Management Information Base. That flag is named "OCBActivated". > Whenever OCBActivated is set to true the feature it relates to > represents an earlier 802.11p feature. 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 has the flag set, it > uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. > > In the following text we use the term "802.11p" to mean 802.11-2012 > OCB. > > The IPv6 network layer operates on 802.11 OCB in the same manner as > it operates on 802.11 WiFi, with a few particular exceptions. The > IPv6 network layer operates on WiFi by involving an Ethernet > Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers > to Ethernet II headers. The operation of IP on Ethernet is > described in [RFC1042 <https://tools.ietf.org/html/rfc1042>] and > [RFC2464 <https://tools.ietf.org/html/rfc2464>]. The situation of > IPv6 networking layer on Ethernet Adaptation Layer is illustrated > below: > > > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 3] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-4> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet > Adaptation Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > 802.11 WiFi MAC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 WiFi > PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > (in the above figure, a WiFi profile is represented; this is used > also for OCB profile.) > > A more theoretical and detailed view of layer stacking, and > interfaces between the IP layer and 802.11 OCB layers, is > illustrated below. The IP layer operates on top of the EtherType > Protocol Discrimination (EPD); this Discrimination layer is described > in IEEE Std 802.3-2012; the interface between IPv6 and EPD is the > LLC_SAP (Link Layer Control Service Accesss Point). > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 > | +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ { LLC_SAP } > 802.11 OCB +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary | > EPD | | | | | MLME | > | +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | | MAC Sublayer > | | | 802.11 OCB | and ch. coord. | | SME | > Services +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | | > | PLME | | | PHY Layer | PLME_SAP | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > In addition to the description of interface between IP and MAC using > "Ethernet Adaptation Layer" and "Ethernet Protocol Discrimination > (EPD)" it is worth mentioning that SNAP [RFC1042 > <https://tools.ietf.org/html/rfc1042>] is used to carry the IPv6 > Ethertype. > > However, there may be some deployment considerations helping > optimize the performances of running IPv6 over 802.11-OCB (e.g. in > the case of handovers between 802.11 OCB-enabled access routers, or > the consideration of using the IP security layer [RFC4301 > <https://tools.ietf.org/html/rfc4301>]). > > > > > Petrescu, et al. Expires February 18, 2018 [Page 4] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-5> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > There are currently no specifications for handover between OCB links > since these are currently specified as LLC-1 links (i.e. > connectionless). Any handovers must be performed above the Data > Link Layer. Also, while there is no encryption applied below the > network layer using 802.11p, 1609.2 [ieee1609.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-ieee1609.2>] > does provide security services for applications to use so that there > can easily be data security over the air without invoking IPsec. > > We briefly introduce the vehicular communication scenarios where > IEEE 802.11-OCB links are used. > > > [Sri] I have not seen much discussion on the link / communication > assumptions. > > > > This is followed by a description of differences in specification > terms, between 802.11 OCB and 802.11a/b/g/n (and the same differences > expressed in terms of requirements to software implementation are > listed inAppendix B > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-B>.) > > The document then concentrates on the parameters of layering IP > over 802.11 OCB as over Ethernet: value of MTU, the contents of > Frame Format, the rules for forming Interface Identifiers, the > mechanism for Address Mapping and for State-less Address > Auto-configuration. These are precisely the same as IPv6 over > Ethernet [RFC2464 <https://tools.ietf.org/html/rfc2464>]. > > As an example, these characteristics of layering IPv6 straight over > LLC over 802.11 OCB MAC are illustrated by dissecting an IPv6 packet > captured over a 802.11 OCB link; this is described in the section > Section 6 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6>. > > A couple of points can be considered as different, although they > are not required in order to have a working implementation of > IPv6-over- 802.11-OCB. These points are consequences of the OCB > operation which is particular to 802.11 OCB (Outside the Context of a > BSS). First, the handovers between OCB links need specific behaviour > for IP Router Advertisements, or otherwise 802.11 OCB's Time > Advertisement, or of higher layer messages such as the 'Basic Safety > Message' (in the US) or the 'Cooperative Awareness Message' (in the > EU) or the 'WAVE Routing Advertisement'; second, the IP security > mechanisms are necessary, since OCB means that 802.11 is stripped of > all 802.11 link-layer security; a small additional security aspect > which is shared between 802.11 OCB and other 802.11 links is the > privacy concerns related to the address formation mechanisms. > > In the published literature, many documents describe aspects related > to running IPv6 over 802.11 OCB: > [I-D.jeong-ipwave-vehicular-networking-survey > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.jeong-ipwave-vehicular-networking-survey>]. > > > > 2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-2>. > > Terminology > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described inRFC 2119 > <https://tools.ietf.org/html/rfc2119> [RFC2119 > <https://tools.ietf.org/html/rfc2119>]. > > > > Petrescu, et al. Expires February 18, 2018 [Page 5] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-6> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > RSU: Road Side Unit. A computer equipped with at least one IEEE > 802.11 interface operated in OCB mode. This definition applies to > this document. An RSU may be connected to the Internet, and may be > equipped with additional wired or wireless network interfaces > running IP. An RSU MAY be an IP Router. > > > [Sri] RSU can be compared to an 802.11 access point; Or, WTP as > defined in CAPWAP specification, RFC5415. > > > Perhaps. rephrase as below?: > > > "RSU: Road Side Unit. Its a wireless termination point (WTP), as > defined in RFC5415 with one key difference, where the wireless > physical and the mac layer is configured to operate in 802.11 OCB > mode. The RSU communicates with the On board Unit (OBU) in the > vehicle over 802.11 wireless link operating in OCB mode.” > > > > ** Also, since you are defining the RSU term, should you also not > define OBU (On board Unit) in the vehicle which is the entity on the > other end of the link? “RSU ----802.11-OCB——OBU” ? May be introduce > the OCB definition separately, just as you did with RSU, and show the > communication link as 802.11-OCB. > > > > OCB: outside the context of a basic service set (BSS): A mode of > operation in which a STA is not a member of a BSS and does not > utilize IEEE Std 802.11 authentication, association, or data > confidentiality. > > 802.11-OCB, or 802.11 OCB: text in document IEEE 802.11-2012 that is > flagged by "dot11OCBActivated". This means: IEEE 802.11e for > quality of service; 802.11j-2004 for half-clocked operations; and > (what was known earlier as) 802.11p for operation in the 5.9 GHz band > and in mode OCB. > > > [Sri] The text starting with. “This means” is not clear to me. Does > it 802.11e is supported with 802.11OCB mode. Please clarify > > > > 3 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-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, among which we refer the reader to one recently > updated [I-D.petrescu-its-scenarios-reqs > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.petrescu-its-scenarios-reqs>], > about scenarios and requirements for IP in Intelligent Transportation > Systems. > > > [Sri] You can do bit more justice to this section. > > Explain the link model. “STA ----802.11-OCB——STA”. Then talk about > the applicability in Vehicular networks, with STA's as RSU and OCB. > > You may also want to talk about, how links get formed/terminated; how > nodes peer/discover and how mobility works ..etc. While 802.11-OCB > is clearly specified and the use of IPv6 over such link is also not > radically new, but the operating environment which is vehicular > brings many new things. That description is not present any where. > > > 4 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-4>. > > Aspects introduced by the OCB mode to 802.11 > > > > In the IEEE 802.11 OCB mode, all nodes in the wireless range can > directly communicate with each other without authentication/ > association procedures. Briefly, the IEEE 802.11 OCB mode has the > following properties: > > > > [Sri] Can you add some text on how nodes (ST1 and STA2) discover each > other on such links supporting 802.11 OCB mode. > > o The use by each node of a 'wildcard' BSSID (i.e., each bit of the > BSSID is set to 1) > > o No IEEE 802.11 Beacon frames transmitted > > o No authentication required > > o No association needed > > o No encryption provided > > > [Sri] Can you clarify what you mean when you say “No xxx required” / > “No xxx needed” for the above capabilities. What does “needed” or > “required” mean? Does it mean, “Authentication", “Association" and > “Encryption” is optional on this link, or that its not supported on > 802.11 OCB links. > > > o Flag dot11OCBActivated set to true > > The following message exchange diagram illustrates a comparison > between traditional 802.11 and 802.11 in OCB mode. The 'Data' > > > > Petrescu, et al. Expires February 18, 2018 [Page 6] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-7> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > messages can be IP messages such as the messages used in Stateless > or Stateful Address Auto-Configuration, or other IP messages. > > > > [Sri] Lets separatethe discussion on IP Address configuration using > SLAAC/DHCP on such links from the above description. The Data packets > here can be application packets such as HTTP or other packets. May > be additional discussion is needed on the IP address configuration on > 802.11-OCB links. > > > > Other 802.11 management and control frames (non IP) may be > transmitted, as specified in the 802.11 standard. For information, > the names of these messages as currently specified by the 802.11 > standard are listed inAppendix D > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-D>. > > > > > > > > STA AP STA1 STA2 | > | | | |<------ Beacon -------| > |<------ Data -------->| | | | > | |---- Probe Req. ----->| |<------ Data -------->| > |<--- Probe Res. ------| | | | > | |<------ Data -------->| |---- Auth Req. ------>| > | | |<--- Auth Res. -------| > |<------ Data -------->| | | | > | |---- Asso Req. ------>| |<------ Data -------->| > |<--- Asso Res. -------| | | | > | |<------ Data -------->| |<------ Data -------->| > | | |<------ Data -------->| > |<------ Data -------->| > > (a) 802.11 Infrastructure mode (b) 802.11 OCB mode > > > The link 802.11 OCB was specified in IEEE Std 802.11p (TM) -2010 > [ieee802.11p-2010 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-ieee802.11p-2010>] > as an amendment to IEEE Std 802.11 (TM) -2007, titled "Amendment 6: > Wireless Access in Vehicular Environments". Since then, this > amendment has been included in IEEE 802.11(TM)-2012 [ieee802.11-2012 > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-ieee802.11-2012>], > titled "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"; the > modifications are diffused throughout various sections (e.g. the Time > Advertisement message described in the earlier 802.11 (TM) p > amendment is now described in section 'Frame formats', and the > operation outside the context of a BSS described in section 'MLME'). > > In document 802.11-2012, specifically anything referring > "OCBActivated", or "outside the context of a basic service set" is > actually referring to the 802.11p aspects introduced to 802.11. > Note that in earlier 802.11p documents the term "OCBEnabled" was > used instead of te current "OCBActivated". > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 7] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-8> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > In order to delineate the aspects introduced by 802.11 OCB to > 802.11, we refer to the earlier [ieee802.11p-2010 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-ieee802.11p-2010>]. > The amendment is concerned with vehicular communications, where the > wireless link is similar to that of Wireless LAN (using a PHY layer > specified by 802.11a/b/g/n), but which needs to cope with the high > mobility factor inherent in scenarios of communications between > moving vehicles, and between vehicles and fixed infrastructure > deployed along roads. While 'p' is a letter just like 'a, b, g' and > 'n' are, 'p' is concerned more with MAC modifications, and a little > with PHY modifications; the others are mainly about PHY > modifications. It is possible in practice to combine a 'p' MAC with > an 'a' PHY by operating outside the context of a BSS with OFDM at > 5.4GHz. > > The 802.11 OCB links are specified to be compatible as much as > possible with the behaviour of 802.11a/b/g/n and future generation > IEEE WLAN links.* From the IP perspective, an 802.11 OCB MAC layer > offers practically the same interface to IP as the WiFi and Ethernet > layers do (802.11a/b/g/n and 802.3).* > > > [Sri] A packet sent from a vehicle’s OBU is received by a single RSU, > or multiple RSU’s? How does the link-layer resolution happen? > > > To support this similarity statement (IPv6 is layered on top of LLC > on top of 802.11 OCB similarly as on top of LLC on top of > 802.11a/b/g/n, and as on top of LLC on top of 802.3) it is useful to > analyze the differences between 802.11 OCB and 802.11 > specifications. Whereas the 802.11p amendment specifies relatively > complex and numerous changes to the MAC layer (and very little to the > PHY layer), we note there are only a few characteristics which may be > important for an implementation transmitting IPv6 packets on 802.11 > OCB links. > > In the list below, the only 802.11 OCB fundamental points which > influence IPv6 are the OCB operation and the 12Mbit/s maximum which > may be afforded by the IPv6 applications. > > > [Sri] I am really not sure how link throughput (12Mbps) relates to > "IPv6 support on OCB links". > > > > o Operation Outside the Context of a BSS (OCB): the (earlier > 802.11p) 802.11-OCB links are operated without a Basic Service Set > (BSS). This means that the frames IEEE 802.11 Beacon, Association > Request/Response, Authentication Request/Response, and similar, are > not used. The used identifier of BSS (BSSID) has a hexadecimal value > always 0xffffffffffff (48 '1' bits, represented as MAC address > ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to > an arbitrary BSSID value set by administrator (e.g. > 'My-Home-AccessPoint'). The OCB operation - namely the lack of > beacon-based scanning and lack of authentication - has a potentially > strong impact on the use of the Mobile IPv6 protocol [RFC6275 > <https://tools.ietf.org/html/rfc6275>] and on the protocols for IP > layer security [RFC4301 <https://tools.ietf.org/html/rfc4301>]. > > > [Sri] The document till now has been arguing heavily on how IPv6 > operates so naturally on these links and now I see discussion on > “Impact to a high-level protocol such as MIPv6”. You may want to fix > the earlier text. In any case, the absence of link-layer security > practically impacts every application, not just MIPv6. Also, MIPv6 > does not make any assumptions on the link-layer security. Also, the > the 0xFF-FF-FF-FF-FF-FF as the BSSID, makes the messages readable by > all other RSU’s in proximity. I think the discussion on the nature of > the link, who all see’s the messages.. how L2 addresses are resolved > is not explained clearly. > > > > > o Timing Advertisement: is a new message defined in 802.11-OCB, > which does not exist in 802.11a/b/g/n. This message is used by > > > > Petrescu, et al. Expires February 18, 2018 [Page 8] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-9> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > stations to inform other stations about the value of time. It is > similar to the time as delivered by a GNSS system (Galileo, GPS, ...) > or by a cellular system. This message is optional for > implementation.*At the date of writing, an experienced reviewer > considers that currently no field testing has used this message. > Another implementor considers this feature implemented in an initial > manner. In the future, it is speculated that this message may be > useful for very simple devices which may not have their own hardware > source of time (Galileo, GPS, cellular network), or by vehicular > devices situated in areas not covered by such network (in tunnels, > underground, outdoors but shaded by foliage or buildings, in remote > areas, etc.) * > > > [Sri] The first part explaining Timing Advertisement messages is > great, but the rest of the commentary is unnecessary and not needed. > We don’t speculate the protocol adoption success in IETF > specifications, or about the experience level of the “reviewer" :) > > > > o Frequency range: this is a characteristic of the PHY layer, with > almost no impact to the interface between MAC and IP. However, it is > worth considering that the frequency range is regulated by a regional > authority (ARCEP, ETSI, FCC, etc.); as part of the regulation > process, specific applications are associated with specific frequency > ranges. In the case of 802.11-OCB, the regulator associates a set of > frequency ranges, or slots within a band, to the use of applications > of vehicular communications, in a band known as "5.9GHz". This band > is "5.9GHz" which is different from the bands "2.4GHz" or "5GHz" used > by Wireless LAN. However, as with Wireless LAN, the operation of > 802.11-OCB in "5.9GHz" bands is exempt from owning a license in EU > (in US the 5.9GHz is a licensed band of spectrum; for the the fixed > infrastructure an explicit FCC autorization is required; for an > onboard device a 'licensed-by-rule' concept applies: rule > certification conformity is required); however technical conditions > are different than those of the bands "2.4GHz" or "5GHz". On one > hand, the allowed power levels, and implicitly the maximum allowed > distance between vehicles, is of 33dBm for 802.11-OCB (in Europe), > compared to 20 dBm for Wireless LAN 802.11a/b/g/n; this leads to a > maximum distance of approximately 1km, compared to approximately 50m. > On the other hand, specific conditions related to congestion > avoidance, jamming avoidance, and radar detection are imposed on the > use of DSRC (in US) and on the use of frequencies for Intelligent > Transportation Systems (in EU), compared to Wireless LAN > (802.11a/b/g/n). > > o Prohibition of IPv6 on some channels relevant for IEEE > 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on > which 802.11a/b/g/n runs: > > * Some channels are reserved for safety communications; the IPv6 > packets should not be sent on these channels. > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 9] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-10> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > * At the time of writing, the prohibition is explicit at higher > layer protocols providing services to the application; these higher > layer protocols are specified in IEEE 1609 documents. > > * National or regional specifications and regulations specify the > use of different channels; these regulations must be followed. > > o 'Half-rate' encoding: as the frequency range, this parameter is > related to PHY, and thus has not much impact on the interface between > the IP layer and the MAC layer. > > o In vehicular communications using 802.11-OCB links, there are > strong privacy requirements with respect to addressing. While the > 802.11-OCB standard does not specify anything in particular with > respect to MAC addresses, in these settings there exists a strong > need for dynamic change of these addresses (as opposed to the non- > vehicular settings - real wall protection - where fixed MAC addresses > do not currently pose some privacy risks). This is further described > in sectionSection 7 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-7>. > A relevant function is described in IEEE 1609.3-2016 [ieee1609.3 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-ieee1609.3>], > clause 5.5.1 and IEEE 1609.4-2016 [ieee1609.4 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-ieee1609.4>], > clause 6.7. > > > Other aspects particular to 802.11-OCB which are also particular to > 802.11 (e.g. the 'hidden node' operation) may have an influence on > the use of transmission of IPv6 packets on 802.11-OCB networks.*The > subnet structure which may be assumed in 802.11-OCB networks is > strongly influenced by the mobility of vehicles.* > > > [Sri] Per my earlier comment, the link model, addressing ..etc needs > to be explained in more detail. It is not clear what exactly the > “subnet structure” that is assumed in 802.11-OCB. > > > 5 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5>. > > Layering of IPv6 over 802.11-OCB as over Ethernet > > > > 5.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.1>. > > Maximum Transmission Unit (MTU) > > > > The default MTU for IP packets on 802.11-OCB is 1500 octets. It is > the same value as IPv6 packets on Ethernet links, as specified in > [RFC2464 <https://tools.ietf.org/html/rfc2464>]. This value of the > MTU respects the recommendation that every link in the Internet must > have a minimum MTU of 1280 octets (stated in [RFC2460 > <https://tools.ietf.org/html/rfc2460>], and the recommendations > therein, especially with respect to fragmentation). If IPv6 packets > of size larger than 1500 bytes are sent on an 802.11-OCB interface > card then the IP stack will fragment. In case there are IP > fragments, the field "Sequence number" of the 802.11 Data header > containing the IP fragment field is increased. > > Non-IP packets such as WAVE Short Message Protocol (WSMP) can be > delivered on 802.11-OCB links. Specifications of these packets are > out of scope of this document, and do not impose any limit on the > MTU size, allowing an arbitrary number of 'containers'. Non-IP > packets such as ETSI 'geonet' packets have an MTU of 1492 bytes. > > > > Petrescu, et al. Expires February 18, 2018 [Page 10] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-11> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > The Equivalent Transmit Time on Channel is a concept that may be > used as an alternative to the MTU concept. A rate of transmission > may be specified as well. The ETTC, rate and MTU may be in direct > relationship. > > [Sri] The last paragraph needs some additional context. Did > 802.11-OCB introduce ETTC concept? > > > > > 5.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.2>. > > Frame Format > > > > IP packets are transmitted over 802.11-OCB as standard Ethernet > packets. As with all 802.11 frames, an Ethernet adaptation layer is > used with 802.11-OCB as well. This Ethernet Adaptation Layer > performing 802.11-to-Ethernet is described inSection 5.2.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.2.1>. > The Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal > 86DD, or otherwise #86DD). > > The Frame format for transmitting IPv6 on 802.11-OCB networks is the > same as transmitting IPv6 on Ethernet networks, and is described in > section 3 of [RFC2464] > <https://tools.ietf.org/html/rfc2464#section-3>. The frame format > for transmitting IPv6 packets over Ethernet is illustrated below: > > > 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | > +- -+ | Ethernet | > +- -+ | Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | > +- -+ | Ethernet | > +- -+ | Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | > +- -+ | header | > +- -+ | and | > +- -+ / payload ... / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Each tic mark represents one > bit.) > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 11] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-12> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > Ethernet II Fields: > > Destination Ethernet Address the MAC destination address. > > Source Ethernet Address the MAC source address. > > 1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 binary representation of the > EtherType value 0x86DD. > > IPv6 header and payload the IPv6 packet containing IPv6 header and > payload. > > > 5.2.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.2.1>. > > Ethernet Adaptation Layer > > > > In general, an 'adaptation' layer is inserted between a MAC layer > and the Networking layer. This is used to transform some parameters > between their form expected by the IP stack and the form provided by > the MAC layer. For example, an 802.15.4 adaptation layer may > perform fragmentation and reassembly operations on a MAC whose > maximum Packet Data Unit size is smaller than the minimum MTU > recognized by the IPv6 Networking layer. Other examples involve > link-layer address transformation, packet header insertion/removal, > and so on. > > An Ethernet Adaptation Layer makes an 802.11 MAC look to IP > Networking layer as a more traditional Ethernet layer. At > reception, this layer takes as input the IEEE 802.11 Data Header and > the Logical-Link Layer Control Header and produces an Ethernet II > Header. At sending, the reverse operation is performed. > > > +--------------------+------------+-------------+---------+-----------+ > > | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| > +--------------------+------------+-------------+---------+-----------+ > > \ / \ / > ----------------------------- -------- > ^---------------------------------------------/ | 802.11-to-Ethernet > Adaptation Layer | v +---------------------+-------------+---------+ > | Ethernet II Header | IPv6 Header | Payload | > +---------------------+-------------+---------+ > > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 12] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-13> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > The Receiver and Transmitter Address fields in the 802.11 Data > Header contain the same values as the Destination and the Source > Address fields in the Ethernet II Header, respectively. The value of > the Type field in the LLC Header is the same as the value of the > Type field in the Ethernet II Header. > > The ".11 Trailer" contains solely a 4-byte Frame Check Sequence. > > The Ethernet Adaptation Layer performs operations in relation to IP > fragmentation and MTU. One of these operations is briefly described > in sectionSection 5.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.1>. > > In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in > the following figure: > > > +--------------------+-------------+-------------+---------+-----------+ > > | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| > +--------------------+-------------+-------------+---------+-----------+ > > or > > +--------------------+-------------+-------------+---------+-----------+ > > | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer| > +--------------------+-------------+-------------+---------+-----------+ > > > > The distinction between the two formats is given by the value of the > field "Type/Subtype". The value of the field "Type/Subtype" in the > 802.11 Data header is 0x0020. The value of the field "Type/Subtype" > in the 802.11 QoS header is 0x0028. > > The mapping between qos-related fields in the IPv6 header (e.g. > "Traffic Class", "Flow label") and fields in the "802.11 QoS Data > Header" (e.g. "QoS Control") are not specified in this document. > Guidance for a potential mapping is provided in > [I-D.ietf-tsvwg-ieee-802-11 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.ietf-tsvwg-ieee-802-11>], > although it is not specific to OCB mode. > > > > [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs > further investigation, IMO. > > > > > 5.3 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.3>. > > Link-Local Addresses > > > > The link-local address of an 802.11-OCB interface is formed in the > same manner as on an Ethernet interface. This manner is described > in section 5 of [RFC2464] > <https://tools.ietf.org/html/rfc2464#section-5>. > > > > [Sri] Does this go against the 8064 recommendation on Interface > identifier generation? > > May be RFC7217 for interface identifier generation in conjunction > with the link-local address generation per RFC2464 > > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 13] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-14> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > 5.4 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.4>. > > Address Mapping > > > > For unicast as for multicast, there is no change from the unicast > and multicast address mapping format of Ethernet interfaces, as > defined by sections6 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6> > and7 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-7> > of [RFC2464 <https://tools.ietf.org/html/rfc2464>]. > > > > [Sri] RFC6085 specified mapping is also relevant; If the > communication peers are aware that there is only one peer, it should > apply 6085 specified mapping. That mode is relevant for 802.11-OCB > types links as well. > > > > 5.4.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.4.1>. > > Address Mapping -- Unicast > > > > The procedure for mapping IPv6 unicast addresses into Ethernet link- > layer addresses is described in [RFC4861 > <https://tools.ietf.org/html/rfc4861>]. The Source/Target Link- > layer Address option has the following form when the link-layer is > Ethernet. > > [Sri] I thought, mapping of IPv6 unicast addresses to Ethernet > link-layer addresses is specified in section 6, of RFC2464 and not in > RFC4861. > > > > > 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | > +- Ethernet -+ | | > +- Address -+ | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Option fields: > > Type 1 for Source Link-layer address. 2 for Target Link-layer > address. > > Length 1 (in units of 8 octets). > > Ethernet Address The 48 bit Ethernet IEEE 802 address, in canonical > bit order. > > > 5.4.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.4.2>. > > Address Mapping -- Multicast > > > > IPv6 protocols often make use of IPv6 multicast addresses in the > destination field of IPv6 headers. For example, an ICMPv6 link- > scoped Neighbor Advertisement is sent to the IPv6 address ff02::1 > denoted "all-nodes" address. When transmitting these packets on > 802.11-OCB links it is necessary to map the IPv6 address to a MAC > address. > > > > > Petrescu, et al. Expires February 18, 2018 [Page 14] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-15> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > The same mapping requirement applies to the link-scoped multicast > addresses of other IPv6 protocols as well. In DHCPv6, the > "All_DHCP_Servers" IPv6 multicast address ff02::1:2, and in OSPF the > "All_SPF_Routers" IPv6 multicast address ff02::5, need to be mapped > on a multicast MAC address. > > An IPv6 packet with a multicast destination address DST, consisting > of the sixteen octets DST[1] through DST[16], is transmitted to the > IEEE 802.11-OCB MAC multicast address whose first two octets are the > value 0x3333 and whose last four octets are the last four octets of > DST. > > [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085. > In general, for both unicast and multicast, you may want to clearly > say that this is per the existing specs and duplicated here for > convenience. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[13] | DST[14] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[15] | DST[16] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > A Group ID TBD of length 112bits may be requested from IANA; this > Group ID signifies "All 80211OCB Interfaces Address". Only the > least 32 significant bits of this "All 80211OCB Interfaces Address" > will be mapped to and from a MAC multicast address. > > Transmitting IPv6 packets to multicast destinations over 802.11 > links proved to have some performance issues > [I-D.perkins-intarea-multicast-ieee802 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.perkins-intarea-multicast-ieee802>]. > These issues may be exacerbated in OCB mode. Solutions for these > problems should consider the OCB mode of operation. > > > 5.5 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.5>. > > Stateless Autoconfiguration > > > > The Interface Identifier for an 802.11-OCB interface is formed using > the same rules as the Interface Identifier for an Ethernet > interface; this is described insection 4 of [RFC2464] > <https://tools.ietf.org/html/rfc2464#section-4>. No changes are > needed, but some care must be taken when considering the use of the > SLAAC procedure. > > > > [Sri] Per my earlier comment, please refer to the current > recommendation on interface-identifier generation and its use in > link-local, global or other addresses. > > The bits in the 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 [I-D.ietf-6man-ug > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.ietf-6man-ug>]. > Petrescu, et al. Expires February 18, 2018 [Page 15] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-16> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > As with all Ethernet and 802.11 interface identifiers ([RFC7721 > <https://tools.ietf.org/html/rfc7721>]), the identifier of an > 802.11-OCB interface may involve privacy risks. A vehicle embarking > an On-Board Unit whose egress interface is 802.11-OCB may expose > itself to eavesdropping and subsequent correlation of data; this may > reveal data considered private by the vehicle owner; there is a risk > of being tracked; see the privacy considerations described inAppendix > C > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C>. > > > > [Sri] I think there are other security issues here; the absence of > link-layer security opens up Mac-spoofing and IP address hijacking. > That should be mentioned. > > > > If stable Interface Identifiers are needed in order to form IPv6 > addresses on 802.11-OCB links, it is recommended to follow the > recommendation in [I-D.ietf-6man-default-iids > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.ietf-6man-default-iids>]. > > > > 5.6 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.6>. > > Subnet Structure > > > > The 802.11 networks in OCB mode may be considered as 'ad-hoc' > networks. The addressing model for such networks is described in > [RFC5889 <https://tools.ietf.org/html/rfc5889>]. > > > [Sri] Per my earlier comment, there is no system level view of the > network where 802.11-OCB links are used. So, in the absence of such > discussion So, I am not sure what part of RFC5889 is applicable here. > For example, link-local addresses may just work fine. > > > > 6 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6>. > > Example IPv6 Packet captured over a IEEE 802.11-OCB link > > > > We remind that a main goal of this document is to make the case that > IPv6 works fine over 802.11-OCB networks. Consequently, this > section is an illustration of this concept and thus can help the > implementer when it comes to running IPv6 over IEEE 802.11-OCB. 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. > > We describe an experiment of capturing an IPv6 packet on an > 802.11-OCB link. In this experiment, the packet is an IPv6 Router > Advertisement. This packet is emitted by a Router on its 802.11-OCB > interface. The packet is captured on the Host, using a network > protocol analyzer (e.g. Wireshark); the capture is performed in two > different modes: direct mode and 'monitor' mode. The topology used > during the capture is depicted below. > > > +--------+ +-------+ | | > 802.11-OCB Link | | ---| Router > |--------------------------------| Host | | | > | | +--------+ +-------+ > > > During several capture operations running from a few moments to > several hours, no message relevant to the BSSID contexts were > captured (no Association Request/Response, Authentication Req/Resp, > > > > > Petrescu, et al. Expires February 18, 2018 [Page 16] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-17> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > Beacon). This shows that the operation of 802.11-OCB is outside the > context of a BSSID. > > Overall, the captured message is identical with a capture of an IPv6 > packet emitted on a 802.11b interface. The contents are precisely > similar. > > > [Sri] I suggest moving this discussion under the section > “Implementation Status”, which will eventually be removed from the > RFC. There is nothing new here. This are details on experimentation. > But, if you think there is some useful information such as discussion > on Capture mode ..etc, you may want to move this entire section to > Appendix. Implementors may use these tools for verification. > > > > > 6.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6.1>. > > Capture in Monitor Mode > > > > The IPv6 RA packet captured in monitor mode is illustrated below. The > radio tap header provides more flexibility for reporting the > characteristics of frames. The Radiotap Header is prepended by this > particular stack and operating system on the Host machine to the RA > packet received from the network (the Radiotap Header is not present > on the air). The implementation-dependent Radiotap Header is useful > for piggybacking PHY information from the chip's registers as data > in a packet understandable by userland applications using Socket > interfaces (the PHY interface can be, for example: power levels, > data rate, ratio of signal to noise). > > The packet present on the air is formed by IEEE 802.11 Data Header, > Logical Link Control Header, IPv6 Base Header and ICMPv6 Header. > > > > Radiotap Header v0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Header Revision| Header Pad | Header length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Present flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Data Rate | Pad | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IEEE 802.11 Data Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Type/Subtype and Frame Ctrl | Duration | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Receiver Address... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > Receiver Address | Transmitter Address... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > Transmitter Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > BSS Id... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > BSS Id | Frag Number and Seq Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Petrescu, et al. Expires February 18, 2018 [Page 17] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-18> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > Logical-Link Control Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > DSAP |I| SSAP |C| Control field | Org. code... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > Organizational Code | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IPv6 Base Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Payload Length | Next Header | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | + + | > | + Source Address + | > | + + | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | + + | > | + Destination Address + | > | + + | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Router Advertisement > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Cur Hop Limit |M|O| Reserved | Router Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Reachable Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Retrans Timer | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Options ... +-+-+-+-+-+-+-+-+-+-+-+- > > > The value of the Data Rate field in the Radiotap header is set to 6 > Mb/s. This indicates the rate at which this RA was received. > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 18] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-19> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > The value of the Transmitter address in the IEEE 802.11 Data Header > is set to a 48bit value. The value of the destination address is > 33:33:00:00:00:1 (all-nodes multicast address). The value of the > BSS Id field is ff:ff:ff:ff:ff:ff, which is recognized by the > network protocol analyzer as being "broadcast". The Fragment number > and sequence number fields are together set to 0x90C6. > > The value of the Organization Code field in the Logical-Link Control > Header is set to 0x0, recognized as "Encapsulated Ethernet". The > value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise > #86DD), recognized as "IPv6". > > A Router Advertisement is periodically sent by the router to > multicast group address ff02::1. It is an icmp packet type 134. > The IPv6 Neighbor Discovery's Router Advertisement message contains > an 8-bit field reserved for single-bit flags, as described in > [RFC4861 <https://tools.ietf.org/html/rfc4861>]. > > The IPv6 header contains the link local address of the router > (source) configured via EUI-64 algorithm, and destination address > set to ff02::1. Recent versions of network protocol analyzers (e.g. > Wireshark) provide additional informations for an IP address, if a > geolocalization database is present. In this example, the > geolocalization database is absent, and the "GeoIP" information is > set to unknown for both source and destination addresses (although > the IPv6 source and destination addresses are set to useful values). > This "GeoIP" can be a useful information to look up the city, > country, AS number, and other information for an IP address. > > > [Sri] Not sure, why all of this text should be in the specification. > > > The Ethernet Type field in the logical-link control header is set to > 0x86dd which indicates that the frame transports an IPv6 packet. In > the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 > which is he corresponding multicast MAC address. The BSS id is a > broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link > duration between vehicles and the roadside infrastructure, there is > no need in IEEE 802.11-OCB to wait for the completion of association > and authentication procedures before exchanging data. IEEE > 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) > and may start communicating as soon as they arrive on the > communication channel. > > > 6.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6.2>. > > Capture in Normal Mode > > > > The same IPv6 Router Advertisement packet described above (monitor > mode) is captured on the Host, in the Normal mode, and depicted > below. > > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 19] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-20> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > Ethernet II Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Destination... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ...Destination | Source... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ...Source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IPv6 Base Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Payload Length | Next Header | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | + + | > | + Source Address + | > | + + | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | + + | > | + Destination Address + | > | + + | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Router Advertisement > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Cur Hop Limit |M|O| Reserved | Router Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Reachable Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Retrans Timer | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Options ... +-+-+-+-+-+-+-+-+-+-+-+- > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 20] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-21> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > One notices that the Radiotap Header is not prepended, and that the > IEEE 802.11 Data Header and the Logical-Link Control Headers are not > present. On another hand, a new header named Ethernet II Header is > present. > > The Destination and Source addresses in the Ethernet II header > contain the same values as the fields Receiver Address and > Transmitter Address present in the IEEE 802.11 Data Header in the > "monitor" mode capture. > > The value of the Type field in the Ethernet II header is 0x86DD > (recognized as "IPv6"); this value is the same value as the value of > the field Type in the Logical-Link Control Header in the "monitor" > mode capture. > > The knowledgeable experimenter will no doubt notice the similarity > of this Ethernet II Header with a capture in normal mode on a pure > Ethernet cable interface. > > It may be interpreted that an Adaptation layer is inserted in a pure > IEEE 802.11 MAC packets in the air, before delivering to the > applications. In detail, this adaptation layer may consist in > elimination of the Radiotap, 802.11 and LLC headers and insertion of > the Ethernet II header. In this way, it can be stated that IPv6 > runs naturally straight over LLC over the 802.11-OCB MAC layer, as > shown by the use of the Type 0x86DD, and assuming an adaptation > layer (adapting 802.11 LLC/MAC to Ethernet II header). > > > 7 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-7>. > > 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 > operating over 802.11-OCB. > > > 802.11-OCB does not provide any cryptographic protection, because it > operates outside the context of a BSS (no Association Request/ > Response, no Challenge messages). Any attacker can therefore just > sit in the near range of vehicles, sniff the network (just set the > interface card's frequency to the proper range) and perform attacks > without needing to physically break any wall. Such a link is way > less protected than commonly used links (wired link or protected > 802.11). > > [Sri] Per my earlier comment, there is more than one attack vector > possible > > 1.) Absence of link-layer security and the potential for mac address > spoofing > > 2.) IP address / Session hijacking > > 3.) Data privacy per your text > > > > At the IP layer, IPsec can be used to protect unicast > communications, and SeND can be used for multicast communications. > > > [Sri] IPSec can be used for protecting both multicast or unicast > communication; RFC-5374 with GDOI. > > > > > If no protection is used by the IP layer, upper layers should be > protected. Otherwise, the end-user or system should be warned about > the risks they run. > > > > Petrescu, et al. Expires February 18, 2018 [Page 21] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-22> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > As with all Ethernet and 802.11 interface identifiers, there may > exist privacy risks in the use of 802.11-OCB interface identifiers. > Moreover, in outdoors vehicular settings, the privacy risks are more > important than in indoors settings. New risks are induced by the > possibility of attacker sniffers deployed along routes which listen > for 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. This > may help mitigate privacy risks to a certain level. On another hand, > it may have an impact in the way typical IPv6 address > auto-configuration is performed for vehicles (SLAAC would rely on MAC > addresses amd would hence dynamically change the affected IP > address), in the way the IPv6 Privacy addresses were used, and other > effects. > > > 8 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-8>. > > IANA Considerations > > > > 9 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-9>. > > Contributors > > > > Romain Kuntz contributed extensively about IPv6 handovers between > links running outside the context of a BSS (802.11-OCB links). > > Tim Leinmueller contributed the idea of the use of IPv6 over > 802.11-OCB for distribution of certificates. > > Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey > Voronov provided significant feedback on the experience of using IP > messages over 802.11-OCB in initial trials. > > Michelle Wetterwald contributed extensively the MTU discussion, > offered the ETSI ITS perspective, and reviewed other parts of the > document. > > > 10 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-10>. > > Acknowledgements > > > > The authors would like to thank Witold Klaudel, Ryuji Wakikawa, > Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan > Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray > Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, > Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, > Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, > Bob Moskowitz, Andrew (Dryden?), Georg Mayer, Dorothy Stanley and > William Whyte. Their valuable comments clarified certain issues and > generally helped to improve the document. > > Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB > drivers for linux and described how. > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 22] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-23> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > For the multicast discussion, the authors would like to thank Owen > DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and > participants to discussions in network working groups. > > The authours would like to thank participants to the Birds-of- > a-Feather "Intelligent Transportation Systems" meetings held at IETF > in 2016. > > > 11 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-11>. > > References > > > > 11.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-11.1>. > > Normative References > > > > [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and S. > LIU, "Recommendation on Stable IPv6 Interface Identifiers", > draft-ietf-6man-default-iids-16 > <https://tools.ietf.org/html/draft-ietf-6man-default-iids-16> (work > in progress), September 2016. > > [I-D.ietf-6man-ug] Carpenter, B. and S. Jiang, "Significance of IPv6 > Interface Identifiers",draft-ietf-6man-ug-06 > <https://tools.ietf.org/html/draft-ietf-6man-ug-06> (work in > progress), December 2013. > > [I-D.ietf-tsvwg-ieee-802-11] Szigeti, T., Henry, J., and F. Baker, > "Diffserv to IEEE 802.11 Mapping",draft-ietf-tsvwg-ieee-802-11-06 > <https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-06> (work > in progress), August 2017. > > [RFC1042] Postel, J. and J. Reynolds, "Standard for the > transmission of IP datagrams over IEEE 802 networks", STD 43,RFC 1042 > <https://tools.ietf.org/html/rfc1042>, DOI 10.17487/RFC1042, February > 1988, <https://www.rfc- <https://www.rfc-editor.org/info/rfc1042> > editor.org/info/rfc1042 <https://www.rfc-editor.org/info/rfc1042>>. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels",BCP 14 <https://tools.ietf.org/html/bcp14>,RFC > 2119 <https://tools.ietf.org/html/rfc2119>, DOI 10.17487/RFC2119, > March 1997, <https://www.rfc- > <https://www.rfc-editor.org/info/rfc2119> editor.org/info/rfc2119 > <https://www.rfc-editor.org/info/rfc2119>>. > > [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 > (IPv6) Specification",RFC 2460 <https://tools.ietf.org/html/rfc2460>, > DOI 10.17487/RFC2460, December 1998, > <https://www.rfc-editor.org/info/rfc2460>. > > [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet > Networks",RFC 2464 <https://tools.ietf.org/html/rfc2464>, DOI > 10.17487/RFC2464, December 1998, > <https://www.rfc-editor.org/info/rfc2464>. > > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 23] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-24> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. > Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963 > <https://tools.ietf.org/html/rfc3963>, DOI 10.17487/RFC3963, January > 2005, <https://www.rfc-editor.org/info/rfc3963>. > > [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, > "Randomness Requirements for Security",BCP 106 > <https://tools.ietf.org/html/bcp106>,RFC 4086 > <https://tools.ietf.org/html/rfc4086>, DOI 10.17487/RFC4086, June > 2005, <https://www.rfc- <https://www.rfc-editor.org/info/rfc4086> > editor.org/info/rfc4086 <https://www.rfc-editor.org/info/rfc4086>>. > > [RFC4301] Kent, S. and K. Seo, "Security Architecture for the > Internet Protocol",RFC 4301 <https://tools.ietf.org/html/rfc4301>, > DOI 10.17487/RFC4301, December 2005, > <https://www.rfc-editor.org/info/rfc4301>. > > [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) > for IPv6",RFC 4429 <https://tools.ietf.org/html/rfc4429>, DOI > 10.17487/RFC4429, April 2006, > <https://www.rfc-editor.org/info/rfc4429>. > > [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, > "Neighbor Discovery for IP version 6 (IPv6)",RFC 4861 > <https://tools.ietf.org/html/rfc4861>, DOI 10.17487/RFC4861, > September 2007, <https://www.rfc- > <https://www.rfc-editor.org/info/rfc4861> editor.org/info/rfc4861 > <https://www.rfc-editor.org/info/rfc4861>>. > > [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing > Model in Ad Hoc Networks",RFC 5889 > <https://tools.ietf.org/html/rfc5889>, DOI 10.17487/RFC5889, > September 2010, <https://www.rfc-editor.org/info/rfc5889>. > > [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility > Support in IPv6",RFC 6275 <https://tools.ietf.org/html/rfc6275>, DOI > 10.17487/RFC6275, July 2011, > <https://www.rfc-editor.org/info/rfc6275>. > > [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. > Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power > Wireless Personal Area Networks (6LoWPANs)", RFC 6775 > <https://tools.ietf.org/html/rfc6775>, DOI 10.17487/RFC6775, November > 2012, <https://www.rfc-editor.org/info/rfc6775>. > > [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and > Privacy Considerations for IPv6 Address Generation Mechanisms", RFC > 7721 <https://tools.ietf.org/html/rfc7721>, DOI 10.17487/RFC7721, > March 2016, <https://www.rfc-editor.org/info/rfc7721>. > > > 11.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-11.2>. > > Informative References > > > > > > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 24] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-25> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > [fcc-cc] "'Report and Order, Before the Federal Communications > Commission Washington, D.C. 20554', FCC 03-324, Released on February > 10, 2004, document FCC-03-324A1.pdf, document freely available at > URL http://www.its.dot.gov/exit/fcc_edocs.htm downloaded on October > 17th, 2013.". > > [fcc-cc-172-184] "'Memorandum Opinion and Order, Before the Federal > Communications Commission Washington, D.C. 20554', FCC 06-10, > Released on July 26, 2006, document FCC- 06-110A1.pdf, document > freely available at URL > http://hraunfoss.fcc.gov/edocs_public/attachmatch/ > <http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-110A1.pdf> > FCC-06-110A1.pdf > <http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-110A1.pdf> > downloaded on June 5th, 2014.". > > [I-D.jeong-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-jeong-ipwave- > <https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-networking-survey-03> > > vehicular-networking-survey-03 > <https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-networking-survey-03> > (work in progress), June 2017. > > [I-D.perkins-intarea-multicast-ieee802] Perkins, C., Stanley, D., > Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 > Wireless Media", draft-perkins-intarea-multicast-ieee802-03 > <https://tools.ietf.org/html/draft-perkins-intarea-multicast-ieee802-03> > (work in progress), July 2017. > > [I-D.petrescu-its-scenarios-reqs] Petrescu, A., Janneteau, C., Boc, > M., and W. Klaudel, "Scenarios and Requirements for IP in > Intelligent Transportation Systems",draft-petrescu-its-scenarios- > <https://tools.ietf.org/html/draft-petrescu-its-scenarios-reqs-03> > reqs-03 > <https://tools.ietf.org/html/draft-petrescu-its-scenarios-reqs-03> > (work in progress), October 2013. > > [ieee1609.2] "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless > Access in Vehicular Environments (WAVE) -- Security Services for > Applications and Management Messages. Example URL > http://ieeexplore.ieee.org/document/7426684/ accessed on August > 17th, 2017.". > > [ieee1609.3] "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless > Access in Vehicular Environments (WAVE) -- Networking Services. > Example URLhttp://ieeexplore.ieee.org/document/7458115/ > <http://ieeexplore.ieee.org/document/7458115/accessed> accessed > <http://ieeexplore.ieee.org/document/7458115/accessed> on August > 17th, 2017.". > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 25] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-26> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > [ieee1609.4] "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless > Access in Vehicular Environments (WAVE) -- Multi-Channel Operation. > Example URL http://ieeexplore.ieee.org/document/7435228/ accessed > on August 17th, 2017.". > > [ieee802.11-2012] "802.11-2012 - 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. Downloaded on October 17th, 2013, from IEEE > Standards, document freely available at URL > http://standards.ieee.org/findstds/ > <http://standards.ieee.org/findstds/standard/802.11-2012.html> > standard/802.11-2012.html > <http://standards.ieee.org/findstds/standard/802.11-2012.html> > retrieved on October 17th, 2013.". > > [ieee802.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/ > <http://standards.ieee.org/getieee802/download/802.11p-2010.pdf> > download/802.11p-2010.pdf > <http://standards.ieee.org/getieee802/download/802.11p-2010.pdf> > retrieved on September 20th, 2013.". > > > Appendix A > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-A>. > > ChangeLog > > > > The changes are listed in reverse chronological order, most recent > changes appearing at the top of the list. > > Fromdraft-ietf-ipwave-ipv6-over-80211ocb-03 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-03> > todraft-ietf-ipwave- > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04> > > ipv6-over-80211ocb-04 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04> > > o Removed a few informative references pointing to Dx draft IEEE > 1609 documents. > > o Removed outdated informative references to ETSI documents. > > o Added citations to IEEE 1609.2, .3 and .4-2016. > > o Minor textual issues. > > > > > Petrescu, et al. Expires February 18, 2018 [Page 26] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-27> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > Fromdraft-ietf-ipwave-ipv6-over-80211ocb-02 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-02> > todraft-ietf-ipwave- > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-03> > > ipv6-over-80211ocb-03 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-03> > > o Keep the previous text on multiple addresses, so remove talk > about MIP6, NEMOv6 and MCoA. > > o Clarified that a 'Beacon' is an IEEE 802.11 frame Beacon. > > o Clarified the figure showing Infrastructure mode and OCB mode > side by side. > > o Added a reference to the IP Security Architecture RFC. > > o Detailed the IPv6-per-channel prohibition paragraph which > reflects the discussion at the last IETF IPWAVE WG meeting. > > o Added section "Address Mapping -- Unicast". > > o Added the ".11 Trailer" to pictures of 802.11 frames. > > o Added text about SNAP carrying the Ethertype. > > o New RSU definition allowing for it be both a Router and not > necessarily a Router some times. > > o Minor textual issues. > > Fromdraft-ietf-ipwave-ipv6-over-80211ocb-01 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-01> > todraft-ietf-ipwave- > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-02> > > ipv6-over-80211ocb-02 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-02> > > o Replaced almost all occurences of 802.11p with 802.11-OCB, > leaving only when explanation of evolution was necessary. > > o Shortened by removing parameter details from a paragraph in the > Introduction. > > o Moved a reference from Normative to Informative. > > o Added text in intro clarifying there is no handover spec at IEEE, > and that 1609.2 does provide security services. > > o Named the contents the fields of the EthernetII header (including > the Ethertype bitstring). > > o Improved relationship between two paragraphs describing the > increase of the Sequence Number in 802.11 header upon IP > fragmentation. > > > > > Petrescu, et al. Expires February 18, 2018 [Page 27] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-28> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > o Added brief clarification of "tracking". > > Fromdraft-ietf-ipwave-ipv6-over-80211ocb-00 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-00> > todraft-ietf-ipwave- > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-01> > > ipv6-over-80211ocb-01 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-01> > > o Introduced message exchange diagram illustrating differences > between 802.11 and 802.11 in OCB mode. > > o Introduced an appendix listing for information the set of 802.11 > messages that may be transmitted in OCB mode. > > o Removed appendix sections "Privacy Requirements", "Authentication > Requirements" and "Security Certificate Generation". > > o Removed appendix section "Non IP Communications". > > o Introductory phrase in the Security Considerations section. > > o Improved the definition of "OCB". > > o Introduced theoretical stacked layers about IPv6 and IEEE layers > including EPD. > > o Removed the appendix describing the details of prohibiting IPv6 > on certain channels relevant to 802.11-OCB. > > o Added a brief reference in the privacy text about a precise > clause in IEEE 1609.3 and .4. > > o Clarified the definition of a Road Side Unit. > > o Removed the discussion about security of WSA (because is non-IP). > > o Removed mentioning of the GeoNetworking discussion. > > o Moved references to scientific articles to a separate 'overview' > draft, and referred to it. > > > Appendix B > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-B>. > > Changes Needed on a software driver 802.11a to become a > > > 802.11-OCB driver > > The 802.11p amendment modifies both the 802.11 stack's physical and > MAC layers but all the induced modifications can be quite easily > obtained by modifying an existing 802.11a ad-hoc stack. > > Conditions for a 802.11a hardware to be 802.11-OCB compliant: > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 28] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-29> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > o The chip must support the frequency bands on which the regulator > recommends the use of ITS communications, for example using IEEE > 802.11-OCB layer, in France: 5875MHz to 5925MHz. > > o The chip must support the half-rate mode (the internal clock > should be able to be divided by two). > > o The chip transmit spectrum mask must be compliant to the > "Transmit spectrum mask" from the IEEE 802.11p amendment (but > experimental environments tolerate otherwise). > > o The chip should be able to transmit up to 44.8 dBm when used by > the US government in the United States, and up to 33 dBm in Europe; > other regional conditions apply. > > Changes needed on the network stack in OCB mode: > > o Physical layer: > > * The chip must use the Orthogonal Frequency Multiple Access (OFDM) > encoding mode. > > * The chip must be set in half-mode rate mode (the internal clock > frequency is divided by two). > > * The chip must use dedicated channels and should allow the use of > higher emission powers. This may require modifications to the > regulatory domains rules, if used by the kernel to enforce local > specific restrictions. Such modifications must respect the > location-specific laws. > > MAC layer: > > * All management frames (beacons, join, leave, and others) emission > and reception must be disabled except for frames of subtype Action > and Timing Advertisement (defined below). > > * No encryption key or method must be used. > > * Packet emission and reception must be performed as in ad-hoc mode, > using the wildcard BSSID (ff:ff:ff:ff:ff:ff). > > * The functions related to joining a BSS (Association Request/ > Response) and for authentication (Authentication Request/Reply, > Challenge) are not called. > > * The beacon interval is always set to 0 (zero). > > > > > Petrescu, et al. Expires February 18, 2018 [Page 29] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-30> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > * Timing Advertisement frames, defined in the amendment, should be > supported. The upper layer should be able to trigger such frames > emission and to retrieve information contained in received Timing > Advertisements. > > > Appendix C > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C>. > > Design Considerations > > > > The networks defined by 802.11-OCB are in many ways similar to other > networks of the 802.11 family. In theory, the encapsulation of IPv6 > over 802.11-OCB could be very similar to the operation of IPv6 over > other networks of the 802.11 family. However, the high mobility, > strong link asymetry and very short connection makes the 802.11-OCB > link significantly different from other 802.11 networks. Also, the > automotive applications have specific requirements for reliability, > security and privacy, which further add to the particularity of the > 802.11-OCB link. > > > C.1 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.1>. > > Vehicle ID > > > > Automotive networks require the unique representation of each of > their node. Accordingly, a vehicle must be identified by at least > one unique identifier. The current specification at ETSI and at > IEEE 1609 identifies a vehicle by its MAC address uniquely obtained > from the 802.11-OCB NIC. > > A MAC address uniquely obtained from a IEEE 802.11-OCB NIC > implicitely generates multiple vehicle IDs in case of multiple > 802.11-OCB NICs. A mechanims to uniquely identify a vehicle > irrespectively to the different NICs and/or technologies is > required. > > > C.2 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.2>. > > Reliability Requirements > > > > The dynamically changing topology, short connectivity, mobile > transmitter and receivers, different antenna heights, and many-to- > many communication types, make IEEE 802.11-OCB links significantly > different from other IEEE 802.11 links. Any IPv6 mechanism > operating on IEEE 802.11-OCB link MUST support strong link asymetry, > spatio- temporal link quality, fast address resolution and > transmission. > > IEEE 802.11-OCB strongly differs from other 802.11 systems to > operate outside of the context of a Basic Service Set. This means > in practice that IEEE 802.11-OCB does not rely on a Base Station for > all Basic Service Set management. In particular, IEEE 802.11-OCB > SHALL NOT use beacons. Any IPv6 mechanism requiring L2 services from > IEEE 802.11 beacons MUST support an alternative service. > > > > > > > Petrescu, et al. Expires February 18, 2018 [Page 30] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-31> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST > implement a mechanism for transmitter and receiver to converge to a > common channel. > > Authentication not being possible, IPv6 over IEEE 802.11-OCB MUST > implement an distributed mechanism to authenticate transmitters and > receivers without the support of a DHCP server. > > Time synchronization not being available, IPv6 over IEEE 802.11-OCB > MUST implement a higher layer mechanism for time synchronization > between transmitters and receivers without the support of a NTP > server. > > The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB > MUST disable management mechanisms requesting acknowledgements or > replies. > > The IEEE 802.11-OCB link having a short duration time, IPv6 over > IEEE 802.11-OCB MUST implement fast IPv6 mobility management > mechanisms. > > > C.3 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.3>. > > Multiple interfaces > > > > There are considerations for 2 or more IEEE 802.11-OCB interface > cards per vehicle. For each vehicle taking part in road traffic, > one IEEE 802.11-OCB interface card could be fully allocated for Non > IP safety-critical communication. Any other IEEE 802.11-OCB may be > used for other type of traffic. > > The mode of operation of these other wireless interfaces is not > clearly defined yet. One possibility is to consider each card as an > independent network interface, with a specific MAC Address and a set > of IPv6 addresses. Another possibility is to consider the set of > these wireless interfaces as a single network interface (not > including the IEEE 802.11-OCB interface used by Non IP safety > critical communications). This will require specific logic to > ensure, for example, that packets meant for a vehicle in front are > actually sent by the radio in the front, or that multiple copies of > the same packet received by multiple interfaces are treated as a > single packet. Treating each wireless interface as a separate > network interface pushes such issues to the application layer. > > The privacy requirements of [] imply that if these multiple > interfaces are represented by many network interface, a single > renumbering event SHALL cause renumbering of all these interfaces. If > one MAC changed and another stayed constant, external observers would > be able to correlate old and new values, and the privacy benefits of > randomization would be lost. > > > > > Petrescu, et al. Expires February 18, 2018 [Page 31] > > ------------------------------------------------------------------------ > > > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page-32> > > Internet-Draft IPv6-over-80211ocb August 2017 > > > The privacy requirements of Non IP safety-critical communications > imply that if a change of pseudonyme occurs, renumbering of all > other interfaces SHALL also occur. > > > C.4 > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-C.4>. > > MAC Address Generation > > > > When designing the IPv6 over 802.11-OCB address mapping, we will > assume that the MAC Addresses will change during well defined > "renumbering events". The 48 bits randomized MAC addresses will > have the following characteristics: > > o Bit "Local/Global" set to "locally admninistered". > > o Bit "Unicast/Multicast" set to "Unicast". > > o 46 remaining bits set to a random value, using a random number > generator that meets the requirements of [RFC4086 > <https://tools.ietf.org/html/rfc4086>]. > > The way to meet the randomization requirements is to retain 46 bits > from the output of a strong hash function, such as SHA256, taking as > input a 256 bit local secret, the "nominal" MAC Address of the > interface, and a representation of the date and time of the > renumbering event. > > > Appendix D > <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appendix-D>. > > IEEE 802.11 Messages Transmitted in OCB mode > > > > 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. > > Authors' Addresses > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its >
- [ipwave] Review comments on draft-ietf-ipwave-ipv… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Russ Housley
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… François Simon
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… William Whyte
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… William Whyte
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… William Whyte
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Tony Li
- Re: [ipwave] Review comments on draft-ietf-ipwave… Sri Gundavelli (sgundave)
- Re: [ipwave] Review comments on draft-ietf-ipwave… Alexandre Petrescu