Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt
"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Thu, 07 September 2017 00:22 UTC
Return-Path: <sgundave@cisco.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 7C0541326EC for <its@ietfa.amsl.com>; Wed, 6 Sep 2017 17:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Rq-R1sZ_i5kp for <its@ietfa.amsl.com>; Wed, 6 Sep 2017 17:22:24 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F33312ECEC for <its@ietf.org>; Wed, 6 Sep 2017 17:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=108420; q=dns/txt; s=iport; t=1504743744; x=1505953344; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zxaHPb6et+Phq0xzSjyXL9m3NpwOfKnULviR+ylpRLI=; b=Xro7DtyL0zgt4aK26YftpoCo0sNMPvDB+uaD0EgUETeQ9KnWN1H55ple syWyIBQJvf8zZeukyTnl0wdhE8YaZf6Jt8SuizEJucK9Cj7K7Nf8m49L0 o97AgrZI8YjDo3MkUzdcShJka8/Vrd1SDARqUWFH1LU2E8Y3OUUsNeMiG 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CPAQCNkLBZ/4MNJK1SChkBAQEBAQEBAQEBAQcBAQEBAYNaZIEVB6Ajd4dCjX2CAQMCCBgNgV6CbE8ChEJDFAECAQEBAQEBAWsohRkBAQEBAQEBARYCAQxABwICBxACAQgSNCEGCxcOAgQOBRuJfgMNCBCqfQMCDIMQOoFDhXoNhAMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdMgGCcwSBMVGBToFiAYJzNYJXgVcLARAFCgQCFiwGhUIFigYJjg6IGzwCh1mBE4JHg1dPhHaCExs/hQ2DfoEqhAaBSYxThTeCdAIRGQGBOAE2IVsydxVJhRMCAgEcgWd2AQGISIExgQ8BAQE
X-IronPort-AV: E=Sophos;i="5.42,355,1500940800"; d="scan'208";a="281827005"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2017 00:22:18 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v870MIcl028567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2017 00:22:18 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 6 Sep 2017 19:22:17 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Wed, 6 Sep 2017 19:22:17 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: "its@ietf.org" <its@ietf.org>
Thread-Topic: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt
Thread-Index: AQHTH6nS3MdwWO6+I0K2nyn/HA8hRQ==
Date: Thu, 07 Sep 2017 00:22:17 +0000
Message-ID: <D5D5DF01.28995C%sgundave@cisco.com>
References: <D5C8D565.22C0C0%sgundave@cisco.com> <45acdd94-a77f-14aa-c606-d9f506c9b21d@gmail.com>
In-Reply-To: <45acdd94-a77f-14aa-c606-d9f506c9b21d@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.62]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <592420029307FF4DBB996014C27F7731@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/9QJf4T4Gu5skwUZyrFLAPwGW574>
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: Thu, 07 Sep 2017 00:22:32 -0000
Alex, Ack! That is fine. I am sure we will have lot more discussions on this draft. I think it needs few more revisions. Sri On 8/30/17, 7:33 AM, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote: >Sri, > >I want to let yo 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 Gundvelli (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 reatly >> help. >> >> 1.) Its not clear, if the document makes any asumption on the >> operating environment/communication profile. There is ot much >> discussion on that aspect; For example, Is it always aone-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 >> vehiclar environment and when they are attached/detached. >> >> 3.) How do ndes discover each other? How does ND resolution work? >> Are these mesages received by a multiple RSU¹s, or a single RSU? >> Whats the impication 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 lins to a VLAN/subnet. >> >> 4.) What happens as a vehicle moves between RU¹s, how does it impact >> address configuration? Is DHCPv6 ased address configuration >> relevant here? >> >> >> Please see inlie for additional comments. >> >[...] >> >> Transmission of Pv6 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 >> decribes 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 Etherne layers - by using an Ethernet Adaptation Layer. >> >> Sri] Is it ³recommended MTU size", or "supported MTU size on the >> 82.11 OCB link? >> >> >> >> In addition, the document attempts to ist 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 ssues. >> Most notably, the operation outside the context of a BSS (OB) 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.1 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 amaximum of six >> months and may be updated, replaced, or obsoleted by other documents >> at any time. It is inapropriate 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) i effect on the date of >> publication of this document. Please review tese documents >> carefully, as they describe your rights and restrictios with >> respect to this document. Code Components extracted from this >> documet must include Simplified BSD License text as described in >> ection 4.e of the Trust Legal Provisions and are provided without >> arranty as described in the Simplified BSD License. >> >> Table of Contents >> >> 1 >> >><http://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>io-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-8011ocb-04#sect >>ion-2>. >> Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5 >> >><https://ools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page >-5> >> >> >3. Communication Scenarios where IEEE 802.11 OCB Lins are Used 6 >> 4 >> >><https://tools.ietf.org/html/draft-ietf-ipwae-ipv6-over-80211ocb-04#sect >>ion-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#sect >>ion-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.ietforg/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-5.1>. >> aximum Transmission Unit (MTU) . . . . . . . . . . . . .10 >> >><https://tools.ietf.org/html/draft-ietf-ipwav-ipv6-over-80211ocb-04#page >>-10> >> >> >5.2 >> >><https://tool.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-5.2> >> Frame Format . . . . . . . . . . . . . . . . . . . . . .11 >> >>https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#pag >>-11> >> >> >5.2.1 >> >><https://tools.ietf.org/html/draft-ietf-iwave-ipv6-over-80211ocb-04#sect >>ion-5.2.1>. >> Ethernet AdaptationLayer . . . . . . . . . . . . . .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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-5.4.2>. >> Address Mapping -- Multicast . . . . . . . . . . . .14 >> >><https://toolsietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page >>-14> >> >> >5.5 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021ocb-04#sect >>ion-5.5>. >> Stateless Autoconfiguration . . . . . . .. . . . . . . .15 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-pv6-over-80211ocb-04#page >>-15> >> >> >5.6 >> >><https://tools.itf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-.2>. >> Capture in Normal Mode . . . . . . . . . . . . . . . . .19 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021ocb-04#page >>-19> >> >> >7 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-7>. > Security Considerations . . . . . . . . . . . . . . . . . . .21 >> >>https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page >>-21> >> >> >8 >> >><https://tools.ietf.or/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-8>. >> IANA onsiderations . . . . . . . . . . . . . . . . . . . . .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-80211cb-04#sect >>ion-9>. >> Contributors . . . . . . . . . . . . . . . . . . . . . . .22 >> >><https://tools.ietf.org/html/draft-ietf-ipwae-ipv6-over-80211ocb-04#page >>-22> >> >> >10 >> >><https://tools.ief.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-10>. > Acknowledgements . . . . . . . . . . . . . . . . . . . . . .22 >> ><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#age >>-22> >> >> >> >> >> Petrescu, et al. Expires February 18, 2018 Page 2] >> >> ------------------------------------------------------------------------ >> >> >> >><https://tool.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#sect >>ion-11>. >> References . . . . . . . . . . . . . . . . . . . . . . . . .23 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page >>-23> >> >> >11.1 >> >><https://tools.ietf.org/tml/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-11.1>. >> Nrmative References . . . . . . . . . . . . . . . . . .23 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb04#page >>-23> >> >> >11.2 >> >><https://tools.ietf.org/html/draft-iet-ipwave-ipv6-over-80211ocb-04#sect >>ion-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#appe >>ndix-A>. >> ChangeLog . . . . . . . . . . . . . . . . . . . . .26 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-0211ocb-04#page >>-26> >> >> >Appedix B >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appe >>ndix-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#appe >>ndix-C>. >> Design Considerations . . . . . . . . . . . . . . .30 >> >><https://tools.ietf.or/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#page >>-30> >> >> >C.1 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appe >>ndix-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-ipv-over-80211ocb-04#appe >>ndix-C.2>. >> Reliability Requirements . . . . . . . . . . . . . . . .30 >> >><https://tools.ietf.org/html/draft-itf-ipwave-ipv6-over-80211ocb-04#page >>-30> >> >> >C.3 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appe >>ndix-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-ipwaveipv6-over-80211ocb-04#appe >>ndix-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.rg/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#appe >>ndix-D>. >> IEEE 802.11 Messages Transmitted i 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#sect >>ion-1>. >> >> >Introduction >> >> >> >> This document decribes 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 o 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 documen 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 s set to true the feature it relates to >> represents an earlier 802.11p feature. For example, an802.11 >> STAtion operating outside the context of a basic service set has the >> OCBActivated flag set. Such a statio, 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 WFi 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 >> [RFC464 <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 (Lin Layer Control Service Accesss Point). >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 >> | +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ { LLC_SAP } >> 802.11 OCB +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary | >> EPD | | | | | LME | >> | +-+-+-{ 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 consideratios 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-itf-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 Laer. Also, while there is no encryption applied below the >> network lyer 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 ivoking IPsec. >> >> We briefly introduce the vehicula 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 i specification >> terms, between 802.11 OCB and 802.11a/b/gn (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#appe >>ndix-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 >> >><htps://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-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 ar consequences of the OCB >> operation wich is particular to 802.11 OCB (Outside the Context of a >> BSS). First, the handovers betweenOCB 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) o 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 >> rivacy concerns related to the address fomation mechanisms. >> >> In the published literature, many document describe aspects related >> o 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#sect >>ion-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 inerpreted 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 comparedto an 802.11 access point; Or, WTP as >> defined in CAPWAP specification, RFC5415. >> >> >> Peraps. 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 authntication, association, or data >> confidentiality. >> >> 802.11-OCB, or 802.11 OCB: text in document IEEE 802.11-2012that is >> flagged by "dot11OCBActivated". This means: IEEE 802.11e for >> quality of service; 82.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#sect >>in-3>. >> >> >Communication Scenarios where IEEE 802.11 OCB Links are Used >> >> >> >> The IEEE 802.11 OCB Networks are used for vehicular communicatons, >> as 'Wireless Access in Vehicular Environments'. The IP >> communication scenarios for these environments have been desribed in >> several documents, among which we refer the reader to one recently >> updated [I-D.petrscu-its-scenarios-reqs >> >><https://tools.ietf.org/html/drft-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 ormed/terminated; how >> nodes peer/discover and how mobility works ..etc. While 802.11-OCB >> i 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/tml/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-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 autentication/ >> 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., ech 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-ipwav-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 addres configuration on >> 802.11-OCB links. >> >> >> >> Other 802.11 anagement and control frames (non IP) may be >> transmitted, as specified in the 802.11 standard. For information, >> the ames 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#appe >>ndix-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 >> amedment 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 80.11. >> Note that in earlier 802.11p documents the term "OCBEnabled" was>> used instead of te current "OCBActivated". >> >> >> >> >> >> Perescu, et al. Expires February 18, 2018 [Page 7] >> >> ----------------------------------------------------------------------- >> >> >> ><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#pge >>-8> >> >> >Internet-Draft IPv6-over-80211ocb August 2017 >> >> > In order to delineate the aspects introduced by 802.11 OCB to >> 802.1, 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 >> wireles link is similar to that of Wireless LAN (using a PHY layer >> specifid 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 ltter just like 'a, b, g' and >> 'n' are, 'p' is concerned more wit MAC modifications, and a little >> with PHY modifications; the thers 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/ and future generation >> IEEE WLAN links.* From the IP perspective, a 802.11 OCB MAC layer >> offers practically the same interface to IP a 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 lik throughput (12Mbps) relates to >> "IPv6 support on OCB links". >> >> >> >> o Operation Outside the Context of a BSS (OCB): the (earlier >> 802.11p) 802.11-OCBlinks are operated without a Basic Service Set >> (BSS). This means tht the frames IEEE 802.11 Beacon, Association >> Request/Response, Authentication Request/Response, and similar, are >> not use. The used identifier of BSS (BSSID) has a hexadecimal value >> alwys 0xffffffffffff (48 '1' bits, represented as MAC address >> ff:ffff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to >> an arbitrary BSSID alue 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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-6> >> and7 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#appe >>ndix-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-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#sect >>ion-8>. >> >> >IANA Considerations >> >> >> >> 9 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-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#sect >>ion-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#sect >>ion-11>. >> >> >References >> >> >> >> 11.1 >> >><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect >>ion-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#sect >>ion-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-surv >>ey-03> >> >> >vehicular-networking-survey-03 >> >><https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-networking-surv >>ey-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#appe >>ndix-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#appe >>ndix-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#appe >>ndix-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#appe >>ndix-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#appe >>ndix-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#appe >>ndix-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#appe >>ndix-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#appe >>ndix-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