From nobody Mon Jul 2 09:24:39 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC6012F1A6; Mon, 2 Jul 2018 09:24:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153054867037.16078.7186550425354386274@ietfa.amsl.com> Date: Mon, 02 Jul 2018 09:24:30 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-03.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 16:24:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases Author : Jaehoon Paul Jeong Filename : draft-ietf-ipwave-vehicular-networking-03.txt Pages : 30 Date : 2018-07-02 Abstract: This document discusses problem statement and use cases on IP-based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and vehicle-to-everything (V2X) networking. First, this document surveys use cases using V2V, V2I, and V2X networking. Second, this document analyzes current protocols for vehicular networking and general problems on those current protocols. Third, this document does problem exploration for key aspects in IP- based vehicular networking, such as IPv6 over IEEE 802.11-OCB, IPv6 Neighbor Discovery, Mobility Management, Vehicle Identities Management, Multihop V2X Communications, Multicast, DNS Naming Services, Service Discovery, IPv6 over Cellular Networks, Security and Privacy. For each key aspect, this document discusses problem statement to analyze the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 10:02:48 2018 Return-Path: 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 64CEE13115E for ; Mon, 2 Jul 2018 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9GjsbIy44y5t for ; Mon, 2 Jul 2018 10:02:39 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF321310FE for ; Mon, 2 Jul 2018 10:02:35 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id q9-v6so4590270ioj.8 for ; Mon, 02 Jul 2018 10:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r/cQJn0kQlhWf0KE19iDe4VOW5nn5FbYyMQNQq/WCmc=; b=i8jiI/TibFJiFmOJTvOK1d23/K6AC81vFmZdGR0I1cRIBJag7ZSHcGkv6FpXF5cCPb +heopOAh6EX+NGpkEin3AUNXGvyh0bI/oAC5DRfB+d54jhsUlvVfs8tvFy77pjriTS9U IF3v/cexXx3TZYG2/dzgKvaaFMZXArD/kmrWJrHUGNtqQo8yElKmdNinyhMkf0CcgPkm 7ImaCrq5EldM4ty4ymqhx0rmffoH1NN6yVqaUh0jCcAdwLlc4+KaJUiLpKUO/0J4I7EE PsNmKHlGOHkl7ovavLT/EYjkP1hmnt7jKycLz3dzqJRBCANaGlLOTjt8zlu9SuFLpiwg dClw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r/cQJn0kQlhWf0KE19iDe4VOW5nn5FbYyMQNQq/WCmc=; b=CyRxQ7TEdSLWSO538ysZ4YfOjgioFCUo5ukESXRtzHbImuAMCWnSytorZFb0aLgTOn 9/HJZkvMHLTtAN6O+fNyAw1QZ97yVsRO/tmIRAss4tO8q7Gs4kAFz1TWb74rgCrPI9Sd necuEgZQ0avkLkauX9VBQ/jELgmO0d+on0ErGzwTkYVrgw5bjyMv4MKkIE3zWcRc7H3c sw0klqu7FCTBvE4lKA4BFFzFkibS/7LtTUmT2Up7uhhhK5l7bvK6FEP46Q2qNPir9AcM A4d4y/dYOyll6Nsu0AXx2Q3UqWtzbGyF7FqroPNAOUwjA/GB6/4L+vYK5IjypkMqFeEt CO7w== X-Gm-Message-State: APt69E0n1H1og9qh2YsmLW3lq9k6lYIfZaan11KZXwNa+9NpOXR7OKU9 uqXBe5l8K3wyZB1aeyW6FmQPwe1WW/lgpgH9a0NefQ== X-Google-Smtp-Source: AAOMgpcYXYl+BsdbGjsrkl4wuTd53jK2HRXm53Sb5pnl761GTj3ApAs/66H75x13gRU5lB9rvWUMsnbYfarrwE6ZbXY= X-Received: by 2002:a6b:b956:: with SMTP id j83-v6mr15680829iof.58.1530550954146; Mon, 02 Jul 2018 10:02:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:2696:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 10:02:03 -0700 (PDT) In-Reply-To: <153054867037.16078.7186550425354386274@ietfa.amsl.com> References: <153054867037.16078.7186550425354386274@ietfa.amsl.com> From: "Mr. Jaehoon Paul Jeong" Date: Tue, 3 Jul 2018 02:02:03 +0900 Message-ID: To: its@ietf.org Cc: skku_iotlab_seminar@googlegroups.com, Chris Shen , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000eec14f0570072938" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-03.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 17:02:47 -0000 --000000000000eec14f0570072938 Content-Type: text/plain; charset="UTF-8" Hi IPWAVE WG, Chris Shen (co-author) and I have revised and submitted the IPWAVE Problem Statement document according to the table of contents agreed in the last IETF-101 meeting as below: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-03 Could you take a look at this document and give me your feedback? I will revise this document with your feedback before the IPWAVE WG session in the IETF-102 meeting. Thanks. Best Regards, Paul On Tue, Jul 3, 2018 at 1:24 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Wireless Access in Vehicular > Environments WG of the IETF. > > Title : IP Wireless Access in Vehicular Environments > (IPWAVE): Problem Statement and Use Cases > Author : Jaehoon Paul Jeong > Filename : draft-ietf-ipwave-vehicular-networking-03.txt > Pages : 30 > Date : 2018-07-02 > > Abstract: > This document discusses problem statement and use cases on IP-based > vehicular networks, which are considered a key component of > Intelligent Transportation Systems (ITS). The main topics of > vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- > infrastructure (V2I), and vehicle-to-everything (V2X) networking. > First, this document surveys use cases using V2V, V2I, and V2X > networking. Second, this document analyzes current protocols for > vehicular networking and general problems on those current protocols. > Third, this document does problem exploration for key aspects in IP- > based vehicular networking, such as IPv6 over IEEE 802.11-OCB, IPv6 > Neighbor Discovery, Mobility Management, Vehicle Identities > Management, Multihop V2X Communications, Multicast, DNS Naming > Services, Service Discovery, IPv6 over Cellular Networks, Security > and Privacy. For each key aspect, this document discusses problem > statement to analyze the gap between the state-of-the-art techniques > and requirements in IP-based vehicular networking. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-03 > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave- > vehicular-networking-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave- > vehicular-networking-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000eec14f0570072938 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi IPWAVE WG,
Chris Shen (co-author) and I have revise= d and submitted the IPWAVE Problem Statement document=C2=A0
accor= ding to the table of contents agreed in the last IETF-101 meeting as below:=


Could you take= a look at this document and give me your feedback?

I will revise this document with your feedback=C2=A0
before the= IPWAVE WG session in the IETF-102 meeting.

Thanks= .

Best Regards,
Paul

On Tue, Jul 3, 2018 at 1:= 24 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Wireless Access in Vehicular Environmen= ts WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement a= nd Use Cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Jaeh= oon Paul Jeong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ipwave-vehicular-networking-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-07-02

Abstract:
=C2=A0 =C2=A0This document discusses problem statement and use cases on IP-= based
=C2=A0 =C2=A0vehicular networks, which are considered a key component of =C2=A0 =C2=A0Intelligent Transportation Systems (ITS).=C2=A0 The main topic= s of
=C2=A0 =C2=A0vehicular networking are vehicle-to-vehicle (V2V), vehicle-to-=
=C2=A0 =C2=A0infrastructure (V2I), and vehicle-to-everything (V2X) networki= ng.
=C2=A0 =C2=A0First, this document surveys use cases using V2V, V2I, and V2X=
=C2=A0 =C2=A0networking.=C2=A0 Second, this document analyzes current proto= cols for
=C2=A0 =C2=A0vehicular networking and general problems on those current pro= tocols.
=C2=A0 =C2=A0Third, this document does problem exploration for key aspects = in IP-
=C2=A0 =C2=A0based vehicular networking, such as IPv6 over IEEE 802.11-OCB,= IPv6
=C2=A0 =C2=A0Neighbor Discovery, Mobility Management, Vehicle Identities =C2=A0 =C2=A0Management, Multihop V2X Communications, Multicast, DNS Naming=
=C2=A0 =C2=A0Services, Service Discovery, IPv6 over Cellular Networks, Secu= rity
=C2=A0 =C2=A0and Privacy.=C2=A0 For each key aspect, this document discusse= s problem
=C2=A0 =C2=A0statement to analyze the gap between the state-of-the-art tech= niques
=C2=A0 =C2=A0and requirements in IP-based vehicular networking.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-ietf-ipwave-vehicular-networking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-03
https://datatracker.i= etf.org/doc/html/draft-ietf-ipwave-vehicular-networking-03
A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-ipwave-vehicular-networking-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--000000000000eec14f0570072938-- From nobody Tue Jul 3 06:36:06 2018 Return-Path: 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 6EBC31294D7 for ; Tue, 3 Jul 2018 06:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioy6ylud3kKc for ; Tue, 3 Jul 2018 06:35:57 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A2E130DED for ; Tue, 3 Jul 2018 06:35:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w63DZtc7038100 for ; Tue, 3 Jul 2018 15:35:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 41A46204FA3 for ; Tue, 3 Jul 2018 15:35:55 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 37F1E204F6D for ; Tue, 3 Jul 2018 15:35:55 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w63DZspR009266 for ; Tue, 3 Jul 2018 15:35:55 +0200 To: its@ietf.org References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> From: Alexandre Petrescu Message-ID: <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> Date: Tue, 3 Jul 2018 15:35:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 13:36:01 -0000 Hi William, Today we performed a visit in a nearby area to test other things. QoSData-vs-Data on road N118 Bièvre to Les Ulis was not the goal of testing, but since we were there we listened to the recently deployed RSUs out of curiosity. We received CAMs with 802.11 QoS Data headers (not Data). The ones deployed in City of Versailles send 802.11 Data headers (not QoS Data). It may be that the manufacturers are different. Alex Le 17/05/2018 à 11:08, Alexandre Petrescu a écrit : > Hi William, > > Recently I performed a visit in the city of Vesailles in France, Europe; > there are deployed about 5 Road-Side Units for experimentations, since a > few years now. > > Some of them send CAMs and SPATs.  The ones I could test use "Data", not > "QoS Data". > > The packet dump is available upon request. > > Here is a wireshark image showing the Data field: > > > Le 02/03/2018 à 18:02, William Whyte a écrit : >> US implementations use QoSData with everything -- although it's not >> required by 802.11-OCB, as we discussed earlier, it *is* required for >> a "WAVE device", which all US devices are. >> >> Here's a Wireshark image from a contact showing the QoSData field: >> >> Inline image 1 >> >> Cheers, >> >> William >> >> On Fri, Mar 2, 2018 at 11:28 AM, Alexandre Petrescu >> > >> wrote: >> >> >> >> Le 02/03/2018 à 17:16, William Whyte a écrit : >> >> I've confirmed that the US implementations use QoSData, just >> to close that loop. >> >> >> Thanks.  It's QoSData with IP, right? >> >> Alex >> >> >> Cheers, >> >> William >> >> >> On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu >> > >> > >> wrote: >> >>     William, >> >>     Le 01/03/2018 à 16:59, William Whyte a écrit : >> >>           > I propose we rename 'OCB' into 'IP-OCB' in the draft. >> >>           > 'IP-OCB' is an OCB mode that can be transport IP >> packets >>         with .11 Data >> >>           > headers or with .11 QoS Data headers. >> >>         If it’s over OCB, then it needs to use QoSData. If >> you’re doing >>         Data, you’re not conformant to OCB. There can’t be an >> OCB mode >>         that transports packets with .11 Data, because OCB by >> definition >>         uses QoSData. If the draft implies that you can do >>         non-conformant OCB, that’s a serious defect in the draft. >> >>         Some implementations may not yet have implemented >> this, but >>         that’s on those developers. >> >> >>     For one second, allow me the benefit of the doubt about >>     specifications that may not be implemented. >> >>     I would like to know whether there is an implementation of >> IP over >>     OCB with QoSData headers?  Packet dump is sufficient, or >> any other >>     kind of statement. >> >>     I agree with you that many times it is good to write >> specification >>     first and implementation after. >> >>     Alex >> >> >>         Cheers, >> >>         William >> >>         Sent from Mail >> > >>         > >> for Windows 10 >> >>         *From: *Alexandre Petrescu >> > >>         > >> >>         *Sent: *Thursday, March 1, 2018 10:54 AM >>         *To: *William Whyte > >>         > >>; its@ietf.org >> >>         > >> >> >> >>         *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >>         IPv6-over-802.11-OCB-implementations >> >> >>         Le 01/03/2018 à 16:50, William Whyte a écrit : >> >>           >  >> (there are some packet dumps with IP packets >> transported >>         with .11 Data >> >>           > >> >>           > headers in OCB mode at 5.9GHz, e.g. attached). >> >>           > >> >>           > My understanding is OCB mode requires QoSData, so >> those >>         packets aren’t >> >>           > conformant to the standard. >> >>         I propose we rename 'OCB' into 'IP-OCB' in the draft. >> >>         'IP-OCB' is an OCB mode that can be transport IP >> packets with >>         .11 Data >> >>         headers or with .11 QoS Data headers. >> >>         Alex >> >>           > >> >>           > Cheers, >> >>           > >> >>           > William >> >>           > >> >>           > Sent from Mail >>         > >>         > >> for >> >>           > Windows 10 >> >>           > >> >>           > *From: *Alexandre Petrescu >>         > >>         > >> >> >>           > *Sent: *Thursday, March 1, 2018 10:48 AM >> >>           > *To: *its@ietf.org >> > >>         >> >> >> >>           > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS >> Data in >> >>           > IPv6-over-802.11-OCB -implementations >> >>           > >> >>           > In a private discussion, this question came up: >> >>           > >> >>           > Is there a packet dump showing an IP packet >> transported with >>         .11 QoSData >> >>           > >> >>           > headers in OCB mode at 5.9GHz. >> >>           > >> >>           > (there are some packet dumps with IP packets >> transported >>         with .11 Data >> >>           > >> >>           > headers in OCB mode at 5.9GHz, e.g. attached). >> >>           > >> >>           > Alex >> >>           > >> >>           > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : >> >>           > >> >>           >  > I received some feedback from programmer. >> >>           > >> >>           >  > >> >>           > >> >>           >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : >> >>           > >> >>           >  > [...] >> >>           > >> >>           >  >> ieee802.11ocb protocol is already >> implemented/tested and >>         it is >> >>           > >> >>           >  >> interoperable, but what is the problem, sorry >> maybe I >>         did not follow >> >>           > >> >>           >  >> the discussion well, >> >>           > >> >>           >  > >> >>           > >> >>           >  > Here is the QoS problem for IP over 802.11 OCB in >>         implementations. >> >>           > >> >>           >  > >> >>           > >> >>           >  > In short, in open source on linux, we dont know >> how to >>         send IP packets >> >>           > >> >>           >  > transported as 802.11 QoSData, all IP packets are >>         transported as 802.11 >> >>           > >> >>           >  > Data instead. >> >>           > >> >>           >  > >> >>           > >> >>           >  > - if you ping -Q at 5.9GHz in OCB mode, the >> DSCP fields >>         do get >> >>           > >> >>           >  >    set properly in IP headers of Echorequest, >> but there >>         is no .11 QoSData >> >>           > >> >>           >  >    headers in packets.  Normally, one expects >> the QoSData >>         headers to be >> >>           > >> >>           >  >    present there when the DSCP (an IP field) is >> set. >> >>           > >> >>           >  > >> >>           > >> >>           >  > - if you want to modify kernel, and force >> always to use >>         QoSData headers >> >>           > >> >>           >  >    on WiFi, including OCB at 5.9GHz, there is a >>         net/mac80211/tx.c file >> >>           > >> >>           >  >    with a flag called wme_sta that you could set to >>         true.  But take care >> >>           > >> >>           >  >    that the C comments there say that it's not >> normal to >>         use QoSData >> >>           > >> >>           >  >    headers in OCB mode, because a terminal sending >>         QoSData has no >> >>           > >> >>           >  >    guarantee that receivers also use QoSData (the >>         negotiation of QoS >> >>           > >> >>           >  >    capabilities are absent in OCB). >> >>           > >> >>           >  > >> >>           > >> >>           >  > As you can see, this can be long to try and fix. >> >>           > >> >>           >  > >> >>           > >> >>           >  > Until then I will propose to set QoS aside from >>         IP-over-OCB at this time. >> >>           > >> >>           >  > >> >>           > >> >>           >  > Alex >> >>           > >> >>           >  > >> >>           > >> >>           >  > _______________________________________________ >> >>           > >> >>           >  > its mailing list >> >>           > >> >>           >  > its@ietf.org >> > >> >>           > >> >>           >  > https://www.ietf.org/mailman/listinfo/its >> >>         > > >> >>           > >> >> >> >> >> -- >> >> >> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >> wwhyte@onboardsecurity.com >> > > >> >> >> >> >> -- >> >> >> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >> wwhyte@onboardsecurity.com > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Tue Jul 3 09:02:26 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E33131026; Tue, 3 Jul 2018 09:00:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: suresh@kaloom.com, its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361460.4893.12511119538701300607.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:14 -0700 Archived-At: Subject: [ipwave] ipwave - Requested session has been scheduled for IETF 102 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:22 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipwave Session 1 (1:30 requested) Monday, 16 July 2018, Afternoon Session I 1330-1530 Room Name: Laurier size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/ipwave.ics Request Information: --------------------------------------------------------- Working Group Name: IP Wireless Access in Vehicular Environments Area Name: Internet Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dmm detnet nfvrg lamps stir intarea 6lo 6man manet rtgarea saag l2sm suit Second Priority: sfc cfrg dhc roll i2nsf secdispatch Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Suresh Krishnan Carlos J. Bernardos Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 20:00:41 2018 Return-Path: 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 5ACAA130934 for ; Tue, 3 Jul 2018 20:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cHPyKcKk9SH1 for ; Tue, 3 Jul 2018 20:00:37 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95326130DD1 for ; Tue, 3 Jul 2018 20:00:37 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id p185-v6so6017516itp.4 for ; Tue, 03 Jul 2018 20:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X/Ggyb71kzHwIWnyFpfVKVL9qMTMfME4reAYxsMHdH4=; b=gZQlI2uOAyRj5HpEzyZ+5+FD54k31lfSnnHjKRfFEwIIX49qB6K+J6+SzvAi326mp+ 92ORW7oFcD5lwt2MmZqYGZFMxgOzvJ3OTg7gfuaAmrLBoV9X8egqTlRWb9YCBHJW+ov3 pv49XPZVXmknrb4/WQMH6EKVvQ0rPfc5YMRUAnj0IW5JY8LPf6ydE/yiH+N9hL/3KoAy zBzYH1mY+y8N4Itk2GYlBZD6qjBwF8XLI50O+icz4Yk3QqIE5A0CNRHyCWLR/AK213B1 U1bQvSsnDduQXHSmrIk6M12qspOMhw/WUG90/ieNy8RGSo+9ypLWW5/NI9k/onf5wvz8 51xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X/Ggyb71kzHwIWnyFpfVKVL9qMTMfME4reAYxsMHdH4=; b=QnhjbU8jWND8TpKpHJKKisxNsKx7PMSmapUqGJjcuOMPONtvchw50d6OVNn/aYmBKo YHU81LFiWpQWQYtSsFoIvqs32eXlXKaYQdVrtEL7DwzaTJegHgBqZ+JleLvWVzUkhgfy O1sym3h+1D5JHFFHu4KtpRB971pvPInayWJ3H2MYSeN6ULntgat2of0F537SmrZIdE/7 oXrYRvDrf4xR8DTuQPTn+Ch4e0DRIZnqEoXQ6BXpBBcsuD3vNUf45iXgqglolVBtcFWK hU8g1f0hupqbkoDZySFyDJ5D8eHen5q7A3JA4ysWDLRNc0lBQtK9wztKBrswIaqWmYSw d3AQ== X-Gm-Message-State: APt69E0p+J4OMZDtu7WF64C3xq8RVqk0fKa9RXxw1qepaNdVwMWjvgLZ spOIe2iihlIzgOGIiFvoNgFLZpv1fcgKu7AK1OodUA== X-Google-Smtp-Source: AAOMgpfOO8KMKiE/tuH2MVxK1QYQD9QdqBv8Pc68yDayEucWqg/k9LrpYAqBRMHuyadQAVExz+3FFBhGu11E+WwxqbA= X-Received: by 2002:a24:355:: with SMTP id e82-v6mr423185ite.64.1530673236795; Tue, 03 Jul 2018 20:00:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:2696:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 20:00:06 -0700 (PDT) In-Reply-To: <30036125-B31A-484C-9042-931F1E5141B0@vigilsec.com> References: <30036125-B31A-484C-9042-931F1E5141B0@vigilsec.com> From: "Mr. Jaehoon Paul Jeong" Date: Wed, 4 Jul 2018 12:00:06 +0900 Message-ID: To: Russ Housley Cc: IP Wireless Access in Vehicular Environments Discussion List Content-Type: multipart/alternative; boundary="0000000000008be6c3057023a282" Archived-At: Subject: Re: [ipwave] DRAFT IPWAVE Agenda for IETF 102 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 03:00:40 -0000 --0000000000008be6c3057023a282 Content-Type: text/plain; charset="UTF-8" Hi Russ, I would like to present our problem statement document as below. IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases (draft-ietf-ipwave-vehicular-networking-03) Link: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-03 Presenter: Jaehoon Paul Jeong Time: 30 min Thanks and see you soon. Best Regards, Paul On Sat, Jun 16, 2018 at 1:19 AM, Russ Housley wrote: > See the DRAFT agenda below. Please review and comment. If you would like > a speaking slot, please send a request to the IPWVE WG chairs very soon. > > Russ > > = = = = = = > > 0) Administrativia > > 1) IPWAVE WG documents > > a) draft-ietf-ipwave-ipv6-over-80211ocb > > b) draft-ietf-ipwave-vehicular-networking > > 2) Additional topics (if time permits) > > a) please contact the chairs if you want to make a presentation > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --0000000000008be6c3057023a282 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,
I would like to present our problem statement= document as below.

IP Wireless Access in Vehic= ular Environments (IPWAVE): Problem Statement and Use Cases
(draft-ietf-ipwave-vehicular-networking-= 03)
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-netw= orking-03
Presenter: Jaehoon Paul Jeong
Time: 30= min

Thanks and see you soon.

=
Best Regards,
Paul


On Sat, Jun 16, 2018 at 1:19 AM, Russ = Housley <housley@vigilsec.com> wrote:
See the DRAFT agenda below.=C2=A0 Please review and comment.= =C2=A0 If you would like a speaking slot, please send a request to the IPWV= E WG chairs very soon.

Russ

=3D =3D =3D =3D =3D =3D

0)=C2=A0 Administrativia

1) IPWAVE WG documents

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) draft-ietf-ipwave-ipv6-over-80211ocb
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) draft-ietf-ipwave-vehicular-networking<= br>
2) Additional topics (if time permits)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) please contact the chairs if you want to mak= e a presentation

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--0000000000008be6c3057023a282-- From nobody Fri Jul 6 08:44:53 2018 Return-Path: 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 B9FFA130EB1 for ; Fri, 6 Jul 2018 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSQz-ykbu-nd for ; Fri, 6 Jul 2018 08:44:47 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297D5130E6E for ; Fri, 6 Jul 2018 08:44:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w66Fijla036165 for ; Fri, 6 Jul 2018 17:44:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 963C0202414 for ; Fri, 6 Jul 2018 17:44:45 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 89C0A202408 for ; Fri, 6 Jul 2018 17:44:45 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w66FijHt029335 for ; Fri, 6 Jul 2018 17:44:45 +0200 To: its@ietf.org References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> From: Alexandre Petrescu Message-ID: <59f90174-5c80-34a8-2618-47ff29052c51@gmail.com> Date: Fri, 6 Jul 2018 17:44:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> Content-Type: multipart/mixed; boundary="------------35481FD9C88BBB72755B3A5E" Content-Language: fr Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 15:44:51 -0000 This is a multi-part message in MIME format. --------------35481FD9C88BBB72755B3A5E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I am still divided about whether QoS Data headers or Data headers are best appropriate for IPv6-over-OCB. Further listening in the 5.9GHz bands while driving car on public road reveals a particular RSU [*] sending CAMs and IPv6 RAs (no WSA) with 802.11 QoS Data headers and 802.11 Data headers respectively (no geonet). Packet dumps available upon request. I am not affiliated to these RSUs in any way. Alex [*]: road N118 at position WGS84 48.7281016 N 2.1652933 E Le 03/07/2018 à 15:35, Alexandre Petrescu a écrit : > Hi William, > > Today we performed a visit in a nearby area to test other things. > > QoSData-vs-Data on road N118 Bièvre to Les Ulis was not the goal of > testing, but since we were there we listened to the recently deployed > RSUs out of curiosity. > > We received CAMs with 802.11 QoS Data headers (not Data). > > The ones deployed in City of Versailles send 802.11 Data headers (not > QoS Data). > > It may be that the manufacturers are different. > > Alex > > Le 17/05/2018 à 11:08, Alexandre Petrescu a écrit : >> Hi William, >> >> Recently I performed a visit in the city of Vesailles in France, >> Europe; there are deployed about 5 Road-Side Units for >> experimentations, since a few years now. >> >> Some of them send CAMs and SPATs.  The ones I could test use "Data", >> not "QoS Data". >> >> The packet dump is available upon request. >> >> Here is a wireshark image showing the Data field: >> >> >> Le 02/03/2018 à 18:02, William Whyte a écrit : >>> US implementations use QoSData with everything -- although it's not >>> required by 802.11-OCB, as we discussed earlier, it *is* required for >>> a "WAVE device", which all US devices are. >>> >>> Here's a Wireshark image from a contact showing the QoSData field: >>> >>> Inline image 1 >>> >>> Cheers, >>> >>> William >>> >>> On Fri, Mar 2, 2018 at 11:28 AM, Alexandre Petrescu >>> > >>> wrote: >>> >>> >>> >>>     Le 02/03/2018 à 17:16, William Whyte a écrit : >>> >>>         I've confirmed that the US implementations use QoSData, just >>>         to close that loop. >>> >>> >>>     Thanks.  It's QoSData with IP, right? >>> >>>     Alex >>> >>> >>>         Cheers, >>> >>>         William >>> >>> >>>         On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu >>>         >>         >>>         >>         >> wrote: >>> >>>             William, >>> >>>             Le 01/03/2018 à 16:59, William Whyte a écrit : >>> >>>                   > I propose we rename 'OCB' into 'IP-OCB' in the >>> draft. >>> >>>                   > 'IP-OCB' is an OCB mode that can be transport IP >>>         packets >>>                 with .11 Data >>> >>>                   > headers or with .11 QoS Data headers. >>> >>>                 If it’s over OCB, then it needs to use QoSData. If >>>         you’re doing >>>                 Data, you’re not conformant to OCB. There can’t be an >>>         OCB mode >>>                 that transports packets with .11 Data, because OCB by >>>         definition >>>                 uses QoSData. If the draft implies that you can do >>>                 non-conformant OCB, that’s a serious defect in the >>> draft. >>> >>>                 Some implementations may not yet have implemented >>>         this, but >>>                 that’s on those developers. >>> >>> >>>             For one second, allow me the benefit of the doubt about >>>             specifications that may not be implemented. >>> >>>             I would like to know whether there is an implementation of >>>         IP over >>>             OCB with QoSData headers?  Packet dump is sufficient, or >>>         any other >>>             kind of statement. >>> >>>             I agree with you that many times it is good to write >>>         specification >>>             first and implementation after. >>> >>>             Alex >>> >>> >>>                 Cheers, >>> >>>                 William >>> >>>                 Sent from Mail >>>         >>         >>>                 >>         >> for >>> Windows 10 >>> >>>                 *From: *Alexandre Petrescu >>>         >>         >>>                 >>         >> >>>                 *Sent: *Thursday, March 1, 2018 10:54 AM >>>                 *To: *William Whyte >>         >>>                 >>         >>; its@ietf.org >>>         >>>                 > >>>         >>>         >> >>>                 *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS >>> Data in >>>                 IPv6-over-802.11-OCB-implementations >>> >>> >>>                 Le 01/03/2018 à 16:50, William Whyte a écrit : >>> >>>                   >  >> (there are some packet dumps with IP packets >>>         transported >>>                 with .11 Data >>> >>>                   > >>> >>>                   > headers in OCB mode at 5.9GHz, e.g. attached). >>> >>>                   > >>> >>>                   > My understanding is OCB mode requires QoSData, so >>>         those >>>                 packets aren’t >>> >>>                   > conformant to the standard. >>> >>>                 I propose we rename 'OCB' into 'IP-OCB' in the draft. >>> >>>                 'IP-OCB' is an OCB mode that can be transport IP >>>         packets with >>>                 .11 Data >>> >>>                 headers or with .11 QoS Data headers. >>> >>>                 Alex >>> >>>                   > >>> >>>                   > Cheers, >>> >>>                   > >>> >>>                   > William >>> >>>                   > >>> >>>                   > Sent from Mail >>>                 >>         >>>                 >>         >> for >>> >>>                   > Windows 10 >>> >>>                   > >>> >>>                   > *From: *Alexandre Petrescu >>>                 >>         >>>                 >>         >> >>> >>>                   > *Sent: *Thursday, March 1, 2018 10:48 AM >>> >>>                   > *To: *its@ietf.org >>>         > >>>                 >>>         >> >>> >>>                   > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS >>>         Data in >>> >>>                   > IPv6-over-802.11-OCB -implementations >>> >>>                   > >>> >>>                   > In a private discussion, this question came up: >>> >>>                   > >>> >>>                   > Is there a packet dump showing an IP packet >>>         transported with >>>                 .11 QoSData >>> >>>                   > >>> >>>                   > headers in OCB mode at 5.9GHz. >>> >>>                   > >>> >>>                   > (there are some packet dumps with IP packets >>>         transported >>>                 with .11 Data >>> >>>                   > >>> >>>                   > headers in OCB mode at 5.9GHz, e.g. attached). >>> >>>                   > >>> >>>                   > Alex >>> >>>                   > >>> >>>                   > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : >>> >>>                   > >>> >>>                   >  > I received some feedback from programmer. >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a >>> écrit : >>> >>>                   > >>> >>>                   >  > [...] >>> >>>                   > >>> >>>                   >  >> ieee802.11ocb protocol is already >>>         implemented/tested and >>>                 it is >>> >>>                   > >>> >>>                   >  >> interoperable, but what is the problem, sorry >>>         maybe I >>>                 did not follow >>> >>>                   > >>> >>>                   >  >> the discussion well, >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > Here is the QoS problem for IP over 802.11 OCB in >>>                 implementations. >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > In short, in open source on linux, we dont know >>>         how to >>>                 send IP packets >>> >>>                   > >>> >>>                   >  > transported as 802.11 QoSData, all IP packets are >>>                 transported as 802.11 >>> >>>                   > >>> >>>                   >  > Data instead. >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > - if you ping -Q at 5.9GHz in OCB mode, the >>>         DSCP fields >>>                 do get >>> >>>                   > >>> >>>                   >  >    set properly in IP headers of Echorequest, >>>         but there >>>                 is no .11 QoSData >>> >>>                   > >>> >>>                   >  >    headers in packets.  Normally, one expects >>>         the QoSData >>>                 headers to be >>> >>>                   > >>> >>>                   >  >    present there when the DSCP (an IP field) is >>>         set. >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > - if you want to modify kernel, and force >>>         always to use >>>                 QoSData headers >>> >>>                   > >>> >>>                   >  >    on WiFi, including OCB at 5.9GHz, there is a >>>                 net/mac80211/tx.c file >>> >>>                   > >>> >>>                   >  >    with a flag called wme_sta that you could >>> set to >>>                 true.  But take care >>> >>>                   > >>> >>>                   >  >    that the C comments there say that it's not >>>         normal to >>>                 use QoSData >>> >>>                   > >>> >>>                   >  >    headers in OCB mode, because a terminal >>> sending >>>                 QoSData has no >>> >>>                   > >>> >>>                   >  >    guarantee that receivers also use QoSData (the >>>                 negotiation of QoS >>> >>>                   > >>> >>>                   >  >    capabilities are absent in OCB). >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > As you can see, this can be long to try and fix. >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > Until then I will propose to set QoS aside from >>>                 IP-over-OCB at this time. >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > Alex >>> >>>                   > >>> >>>                   >  > >>> >>>                   > >>> >>>                   >  > _______________________________________________ >>> >>>                   > >>> >>>                   >  > its mailing list >>> >>>                   > >>> >>>                   >  > its@ietf.org >>>         > >>> >>>                   > >>> >>>                   >  > https://www.ietf.org/mailman/listinfo/its >>>         >>>                 >>         > >>> >>>                   > >>> >>> >>> >>> >>>         -- >>> >>>         PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >>>         wwhyte@onboardsecurity.com >>>         >>         > >>> >>> >>> >>> >>> -- >>> >>> >>> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >>> wwhyte@onboardsecurity.com >> >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------35481FD9C88BBB72755B3A5E Content-Type: application/octet-stream; name="CAM-RA-5900.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="CAM-RA-5900.pcap" 1MOyoQIABAAAAAAAAAAAAP//AAB/AAAAKAUhAGlhAQCxAAAAsQAAAAAAJgAvQACgIAgAoCAI AACwvVzqAAAAABAMDBdAQa0AAACkAKwBiAAAAP///////1atkywY4v///////6DAIwCqqgMA AACJRwEAEAEgUAIAAD0BADz6Vq2TLBjioS+Rwh0LUWgBSmW0AAUAAAAAAAAH0QAAAQIAAAB7 NFQA+lYHTQ2ShvaAAgA8IjjijMAjoCwGjjBfL73IMCoAgb+gAAAAAAAAIwwX//+L73IAhJn6 imEIIQBRlQYA0gAAANIAAAAAACYAL0AAoCAIAKAgCAAAEKWOGwEAAAAQBgwXQEG7AAAApAC7 AQgAAAAzMwAAAAEAGXCWITT///////9Qi6qqAwAAAIbdYAOi/QBgOv/+gAAAAAAAAAIZcP/+ liE0/wIAAAAAAAAAAAAAAAAAAYYAWZRAAAAMAAAAAAAAAAADBEDgAAFRgAAAOEAAAAAAIAEG YDAxDOYAAAAAAAAAABkFAAAAAAAEIAFIYEhgAAAAAAAAAACIiCABSGBIYAAAAAAAAAAAiEQB AQAZcJYhNM57dsQ= --------------35481FD9C88BBB72755B3A5E Content-Type: application/octet-stream; name="RA-5880.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="RA-5880.pcap" 1MOyoQIABAAAAAAAAAAAAP//AAB/AAAAvQQhAOj+DgDCAAAAwgAAAAAAJgAvQACgIAgAoCAI AAAQSArkAAAAABAM+BZAQaYAAACmAJwBCAAAADMzAAAAAY4wXy+9yP///////yBUqqoDAAAA ht1gAAAAAFA6//6AAAAAAAAAjDBf//4vvcj/AgAAAAAAAAAAAAAAAAABhgCsb0A4AAEAAAAA AAAAAAMEQMAAAVGAAAA4QAAAAAD9AA4AAAQP/wAAAAAAAAAAGQMAAAAAAB4gAUhgSGAAAAAA AAAAAIiIAQGOMF8vvcj+SF/0 --------------35481FD9C88BBB72755B3A5E-- From nobody Wed Jul 11 16:29:38 2018 Return-Path: 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 D99DD127333 for ; Wed, 11 Jul 2018 16:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.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 ZeDHtjx-zOzp for ; Wed, 11 Jul 2018 16:29:31 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379EA124BE5 for ; Wed, 11 Jul 2018 16:29:31 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id m1-v6so7062109wrg.5 for ; Wed, 11 Jul 2018 16:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=J6OQRQuqxNFMdwSzZWEkiJ8syD9HbghJZ2naAc+NQq8=; b=QZjl/QSXwDRw5YzwaMPWFh9ag1WOdbT4rbRBlzqn5NNAJX+JlqlXD3voWhw4G6ul3H faYGgIiO4zD/wRqhYzD/n1TVHlOaRbJZo8PZjprtpvMKsnOFIAY91maooIj91g3x3yiB SrE2mAPIDVjqK2Db1s5q1otvleOAqMDbK6e1KEHginuCSh8ecNcs8bkP3yF8h5SDztTf AjvObThM8ivdQzxtIPcA7eWE2444oruFKmEQwpu6m9y90Zc+MsOBYFhlrHxiU68LsKfp m5W1PY1JIfrs56iPfkEzomze05OCDNgr+t703aEixUZ477N2s/zbYIHzeTdXqXg3CfVq zRug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=J6OQRQuqxNFMdwSzZWEkiJ8syD9HbghJZ2naAc+NQq8=; b=t2YrGAw+VIqTu5xVIqnR8gHxMjD+8w1YjXoLy9d5XIR3+W/DLkJwzKooy5dGr+vyRg MqGtOJpzF5lPqzsIGkWvnmTC2USvkrLdmozrB/gFRIgSRbj+BLWRQsgWAUVdbc3u6D1q NaV5kEAjF0FqRmWZFlV5aw/4uzGkZN4ObiZW62iBPyCTAdZEtBFB8yI1AiT3k2yj5a3a bbLew4ChkPN9nozPUvNnYXjarqcjWyId9HpTjr4ZfreyROvrDDQ0t3nfFge1CPL8eL3l SX9ZJqGuTV1tzQUEooUq3CVn4nVIRIqkzVomOGxRao7zwyljfQCXJNrvzzFElWk76bwx OKsA== X-Gm-Message-State: AOUpUlGigYuKwehatRA/iSFegJzYRdfTbZ8HgpxzrOlHScpy5bC5u9oI HX/gCKN3Xn0HBQVOx+Vm1Y+VnPL7 X-Google-Smtp-Source: AAOMgpcjLS8JbIdjoNrXpuUzA+kflRH7u/+JGIzLYBk1addGCFtQuS3WfGkjB4nh1mviRSlpt4WdOw== X-Received: by 2002:adf:90e9:: with SMTP id i96-v6mr425651wri.146.1531351769341; Wed, 11 Jul 2018 16:29:29 -0700 (PDT) Received: from acorde ([145.253.78.226]) by smtp.gmail.com with ESMTPSA id 31-v6sm15887066wra.26.2018.07.11.16.29.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Jul 2018 16:29:28 -0700 (PDT) Message-ID: <958359406239a108140d0113154ecab94ed2fb98.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: IP Wireless Access in Vehicular Environments Discussion List Cc: Russ Housley Date: Thu, 12 Jul 2018 01:29:26 +0200 In-Reply-To: <30036125-B31A-484C-9042-931F1E5141B0@vigilsec.com> References: <30036125-B31A-484C-9042-931F1E5141B0@vigilsec.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ipwave] DRAFT IPWAVE Agenda for IETF 102 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 23:29:36 -0000 Hi, Agenda is posted [1]. If you want to present on the "Additional topics" part of the agenda, contact the chairs asap. Thanks, Carlos & Russ [1] https://datatracker.ietf.org/meeting/102/materials/agenda-102-ipwav e-00 On Fri, 2018-06-15 at 12:19 -0400, Russ Housley wrote: > See the DRAFT agenda below. Please review and comment. If you would > like a speaking slot, please send a request to the IPWVE WG chairs > very soon. > > Russ > > = = = = = = > > 0) Administrativia > > 1) IPWAVE WG documents > > a) draft-ietf-ipwave-ipv6-over-80211ocb > > b) draft-ietf-ipwave-vehicular-networking > > 2) Additional topics (if time permits) > > a) please contact the chairs if you want to make a presentation > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Jul 13 01:33:00 2018 Return-Path: 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 0A6C6130E50 for ; Fri, 13 Jul 2018 01:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FZWlMjlw7ony for ; Fri, 13 Jul 2018 01:32:56 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8F81277C8 for ; Fri, 13 Jul 2018 01:32:56 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id r16-v6so60869728oie.3 for ; Fri, 13 Jul 2018 01:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lXOmcK8tegTarGNTkUOpW8rUZNf/sNACYSxm41nQF48=; b=igTlcSyXA9srFTQ90NpP12WzpztsNnEo/twSKNjw18Si3tvY2wTms3IE+bhEsTddIv ER34MWrD/N32QhggeIqIC/IsHRHRdCVUjFnGV106UoaUUkztzRwi2cdEY1ZP81kP/rWc TKcaSeBy08ZC23HSY4UcBey/7nPdIV869NbVehCEotZUUlrIz/qpDKu6zI86FmEd1A2w oItvcYp+/T4ZpRDVix8OTh+u4ZPXcsvz8HOa49ohtMITiVYTOppj6An3WY3ZO26BSdGj NJ90libRKkdHU7yRADmkftefsDnY5vjlYN6CgY8XlwCL4IO4dqMfBLJitl3Z+rm7PgDt 8bzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lXOmcK8tegTarGNTkUOpW8rUZNf/sNACYSxm41nQF48=; b=BdOE6xzWNAqKrlDDwL83vE1KWpy6eqj++ppSH9eazucoLibUvQBrVHTK8fQOx+PWk1 1QXWsXWfnDpX/E3b9Q8wQeQSoX/FMz4HRsXtWW5TMW/GKSlHjd752dBWuStBnOtUfgpG hJGCBsiOVIbuyEeQ4gfDFHK777FNpLRILwCXrRJiNqfBNGpwosOGeZo4bCCpGfOCA6Oz TrWRyAQ7H/ofWNf1VLMeeCecqgjQGFlYj4hX77pIjWXyo/TF/2EJaelngborwM/aH6g8 lx/RXKxkYYJnTdZ9Bn9Ldn+65+xHYy8WznlFNzNODV+hDRelxoVYvoMyAzq2mdrrEbNL LyWg== X-Gm-Message-State: AOUpUlHHpp3BXCkX/lhaTLZPGsf2xgco9nU4VyWLrCOyTKBeMkzhRM4a XfKyAW/W9wZD6kxgEldlRos6tDpK2r7RtShlhIPz0w== X-Google-Smtp-Source: AAOMgpdA4kTjW7rP0dsKp8BRfsW2723KoIVGmwj3blc77pOanYdeGz0cpwIeePwG/ivQQ/e+QpR61JOAxO8N1cTfLh8= X-Received: by 2002:aca:171a:: with SMTP id j26-v6mr6224150oii.277.1531470775662; Fri, 13 Jul 2018 01:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:d32:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 01:32:55 -0700 (PDT) In-Reply-To: <59f90174-5c80-34a8-2618-47ff29052c51@gmail.com> References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> <59f90174-5c80-34a8-2618-47ff29052c51@gmail.com> From: Abdussalam Baryun Date: Fri, 13 Jul 2018 10:32:55 +0200 Message-ID: To: its Content-Type: multipart/alternative; boundary="000000000000913d4a0570dd5391" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 08:32:58 -0000 --000000000000913d4a0570dd5391 Content-Type: text/plain; charset="UTF-8" > > > On Fri, Jul 6, 2018 at 5:44 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi, > > I am still divided about whether QoS Data headers or Data headers are best > appropriate for IPv6-over-OCB. > it just depends on the application used, so both can be used per car. --000000000000913d4a0570dd5391 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jul 6, 2018 at 5:44 PM, Alexandre Petr= escu <alexandre.petrescu@gmail.com> wrote:
Hi,

I am still divided about whether QoS Data headers= or Data headers are best appropriate for IPv6-over-OCB.

it just depends on the application used, so both c= an be used per car.=C2=A0
--000000000000913d4a0570dd5391-- From nobody Fri Jul 13 05:36:13 2018 Return-Path: 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 67174130EF3 for ; Fri, 13 Jul 2018 05:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYIkIjVau3Qj for ; Fri, 13 Jul 2018 05:36:09 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A90130EB7 for ; Fri, 13 Jul 2018 05:36:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w6DCa69M006638; Fri, 13 Jul 2018 14:36:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D04CC2035D8; Fri, 13 Jul 2018 14:36:06 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C20232034A6; Fri, 13 Jul 2018 14:36:06 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w6DCa6lG007563; Fri, 13 Jul 2018 14:36:06 +0200 To: Abdussalam Baryun References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> <59f90174-5c80-34a8-2618-47ff29052c51@gmail.com> Cc: its From: Alexandre Petrescu Message-ID: <57806d48-1d1f-c179-3e55-ba154d4e8baf@gmail.com> Date: Fri, 13 Jul 2018 14:36:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 12:36:12 -0000 Le 13/07/2018 à 10:32, Abdussalam Baryun a écrit : > > On Fri, Jul 6, 2018 at 5:44 PM, Alexandre Petrescu > > wrote: > > Hi, > > I am still divided about whether QoS Data headers or Data headers > are best appropriate for IPv6-over-OCB. > > > it just depends on the application used, so both can be used per car. I will not make a fuss about this, and please excuse me if I am too blunt. Currently the draft says only "QoS Data" is a MUST, not "both". For my part, I am very much divided about this, because I have hands on experience with several production Road-Side Units on roads (highway and city area) that use "Data" instead. Worse, some use IPv6 as "Data" in addition to useing CAM as "Data". I dont want these RSUs, especially the ones that send IPv6, to become non-standard all of a sudden. Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Jul 13 08:59:57 2018 Return-Path: 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 0E0DC130E01 for ; Fri, 13 Jul 2018 08:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9xax1_a-Jbxp for ; Fri, 13 Jul 2018 08:59:54 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0B0130E00 for ; Fri, 13 Jul 2018 08:59:53 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id l9-v6so11245327pff.9 for ; Fri, 13 Jul 2018 08:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F2s69nBrhj96DY9OjUW0kFzbFaJARtarFEZavYvY47U=; b=Vu6LJgUBnbXTrIBr7vru8x0F4t2nsiYtWc6vXwzuFda0+GUhVBtCYE6rsQfu/BVAW2 Bt7ndoxlcHessos87rU5hu0TdTLaxvUxz5unnks6P5YSAHGIGbd1xuwEqvy7dq/Us6M8 JX8bgLiJDk2vehai+0pJRCEEOj9sVuwXbn43rt8J73jySSaWeVuvuDmk0pDpctj8W/Q6 YfI1X5kF3J4EcyRH03/wqKZPS7h5Bgh0oRVyv3pQRUay//aVriC+J0DD0CZ18ir0bxH3 WD9ul9b7tmNzwv8gujP4p78EmCdbgAwEuE6w0X1WbhZOq3IHMYSFDoCAy/ltNyAAtMfB 9bHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F2s69nBrhj96DY9OjUW0kFzbFaJARtarFEZavYvY47U=; b=sFIzNIcYO6S1cf2CmhmDVswYANVy7PQx6zEhtiRXfT6Xgh9ZIVcxt2IJCNFNfvhgnL JcKVuX5K9JEmzSlA7cpKzAclhyU4d0vChE8g7jd+fkL86fHvzRF4NQUIhcyxhJH1JuQo w0+FbMoudtSkdZaDjBCHut+9icT7I0NOSGpQ8TgVUbaFfkTFloX1aRAaUd9jY6gYBEBS MvvznoxbTeN4LJ88VRR9HJNXXYLzNF+5Ki8b0mj3pAtBg/VcComJXvtsSon57hYPYygW XoPgFOADq5T1Slr78HJCKKGrHhOwj7+LN3+vdCrJKMo712HmD7FcLQqvrv1JC+59qPI3 hrMw== X-Gm-Message-State: AOUpUlGJPQ//lHMQbmmVSzyJjBY3dzV0XZeMgsw6e50Iovp6QCj1BfNU wIr0bSNQAamAj4a3ZoIvojGe8adY X-Google-Smtp-Source: AAOMgpe97x47pucxScOAuMuE/jO8Af7N0S78q5M/lJLrX3p+vNNm75rPEthFOuszOp0XZziI2IsSMA== X-Received: by 2002:a63:de10:: with SMTP id f16-v6mr6493249pgg.97.1531497593526; Fri, 13 Jul 2018 08:59:53 -0700 (PDT) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id l70-v6sm12283719pge.64.2018.07.13.08.59.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 08:59:52 -0700 (PDT) From: Tony Li Message-Id: <135A489E-AC1A-40B8-AC86-DF63CE28BC4F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3FABECDA-18FF-421D-8B85-F4DAA7B68747" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 13 Jul 2018 08:59:38 -0700 In-Reply-To: <57806d48-1d1f-c179-3e55-ba154d4e8baf@gmail.com> Cc: Abdussalam Baryun , its To: Alexandre Petrescu References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> <59f90174-5c80-34a8-2618-47ff29052c51@gmail.com> <57806d48-1d1f-c179-3e55-ba154d4e8baf@gmail.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 15:59:56 -0000 --Apple-Mail=_3FABECDA-18FF-421D-8B85-F4DAA7B68747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 13, 2018, at 5:36 AM, Alexandre Petrescu = wrote: >=20 > I dont want these RSUs, especially the ones that send IPv6, to become = non-standard all of a sudden. How do you accommodate that when there are multiple existing = implementations that have chosen different directions? The point of making standards is to make an agreement about how to = proceed. That requires making decisions. Sometimes it means making hard = decisions. We need one and only one way of transmitting v6. Tony --Apple-Mail=_3FABECDA-18FF-421D-8B85-F4DAA7B68747 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 13, 2018, at 5:36 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

I dont want these RSUs, = especially the ones that send IPv6, to become non-standard all of a = sudden.


How do you accommodate that when there = are multiple existing implementations that have chosen different = directions?

The = point of making standards is to make an agreement about how to proceed. = That requires making decisions. Sometimes it means making hard = decisions.

We = need one and only one way of transmitting v6.

Tony

= --Apple-Mail=_3FABECDA-18FF-421D-8B85-F4DAA7B68747-- From nobody Sun Jul 15 07:14:56 2018 Return-Path: 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 93F1E130EF0 for ; Sun, 15 Jul 2018 07:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1fqcxa8vHN4 for ; Sun, 15 Jul 2018 07:14:42 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F8C130EE2 for ; Sun, 15 Jul 2018 07:14:42 -0700 (PDT) Received: from [192.168.0.26] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id A1F9519F5B6; Sun, 15 Jul 2018 16:14:40 +0200 (CEST) To: Tony Li Cc: Abdussalam Baryun , its References: <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> <59f90174-5c80-34a8-2618-47ff29052c51@gmail.com> <57806d48-1d1f-c179-3e55-ba154d4e8baf@gmail.com> <135A489E-AC1A-40B8-AC86-DF63CE28BC4F@gmail.com> From: Alexandre Petrescu Organization: CEA Message-ID: Date: Sun, 15 Jul 2018 16:14:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <135A489E-AC1A-40B8-AC86-DF63CE28BC4F@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 14:14:53 -0000 Le 13/07/2018 à 17:59, Tony Li a écrit : > > >> On Jul 13, 2018, at 5:36 AM, Alexandre Petrescu >> > > wrote: >> >> I dont want these RSUs, especially the ones that send IPv6, to >> become non-standard all of a sudden. > > > How do you accommodate that when there are multiple existing > implementations that have chosen different directions? If you ask me, then I would go check which implementation choosing the direction of IPv6 with "QoS Data" headers. But I dont know of any, despite active research. I already checked and found many implementations that use IPv6 with "Data" headers. They work ok. I am worried that we go a wrong direction with the "QoS Data". In return, as a side point, I would ask whether or not a car with IPv6 with "Data" headers talks to an RSU which implements IPv6 "QoS Data" headers? The answer to this would be a good information point in deciding. The only thing that we know is that, theoretically, if at least one car in a set of cars is _not_ using "QoS Data" then the QoS guarantees are not ensured. But that's in theory. > The point of making standards is to make an agreement about how to > proceed. That requires making decisions. Sometimes it means making > hard decisions. > We need one and only one way of transmitting v6. I agree. Alex > > Tony > From nobody Sun Jul 15 09:04:05 2018 Return-Path: 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 2726D130E74 for ; Sun, 15 Jul 2018 09:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Itu8A5_dNGon for ; Sun, 15 Jul 2018 09:04:01 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D03130E47 for ; Sun, 15 Jul 2018 09:04:01 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id v13-v6so6590623pgr.10 for ; Sun, 15 Jul 2018 09:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ICeVa2gJhrcOj+szTZSyzSxPTseGQUdr59KGKuOCies=; b=V0esNK7pXU1Cy2bZpBTPRD3PguCcl7+JQ3MiVN2dDzdtftfqKSoey8JscX1rIsM7X3 BzN2/Pa86K4utwM+HbxwBiQMoOABc2pDwtS3WwfSp/ZZ4TRhvcIQlPB30/MaS0EiEYm+ FAO2aUTB7yrJL81yKtxlPxrRnf30yAttuQ9Za78/ZCcWNu9hwTtgqq+3Jpb03kWDMx4m rctph/nkEEt0o5V625bJh9yqN+aJ4JD19gFjqbpN7oWZrI/NlSa9+/u9kZZd0te9ikzB P0VLXgGaLA80TZpiRNHvOKz32JozblODgiPGo+W7QbHjH3Nk4H9aKFt1R6sD4+0zA1ay w/5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ICeVa2gJhrcOj+szTZSyzSxPTseGQUdr59KGKuOCies=; b=dgxCOlo5vHKaFvB3cNt65HfUwocafpkArcg4mP3VW8P7BgSB3NYGhd5KOGXxL9HRGD owVDiSk0QgDX+maKlRdXwXxlENc9lufeDe7+P+y9Lqj201PUvCUWx8e8pCOjkXUixyTc +48PMRqX0x49Kdk0ITOpDi0Tl7KtW2wMt7VIlpfEMb7CxkoywQW79Nh+VoYfD0RZl3aD SZy4DYVeGY5Uew7OpI1aaduPyepFT+3WU3Dj3/7B9XdTPR0e3nwf5eM8eWyEUpRngqRi PE7h7+bdOOYaeOsJU3mQ6pwRKMZeHZC0ga199mJHppqpmhpwcM6RVShGTFdDX3S6flFK iRQA== X-Gm-Message-State: AOUpUlE1Dkk6zvnStl2B6fdMuXdpewDkPjdGS6CYQOQf3B4cchkFhlnR uX0igIo5oL0tT4scTsjIFn8= X-Google-Smtp-Source: AAOMgpdARblgKPirvnGCr+HVSryIeUPoMWILFdqLwOrQViwNVFsnZ76DEeNMrVQmX8ww7T3REpKRlA== X-Received: by 2002:a63:6188:: with SMTP id v130-v6mr12742443pgb.100.1531670641406; Sun, 15 Jul 2018 09:04:01 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-209-5.hsd1.ca.comcast.net. [24.130.209.5]) by smtp.gmail.com with ESMTPSA id f6-v6sm40822200pgp.13.2018.07.15.09.04.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Jul 2018 09:04:00 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FE8FF090-3BB2-4685-B94B-DE7140B91EB5" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 15 Jul 2018 09:03:59 -0700 In-Reply-To: Cc: its , Abdussalam Baryun To: Alexandre Petrescu References: <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> <3097ed69-7f42-1d78-2fd6-003f76e4bea3@gmail.com> <59f90174-5c80-34a8-2618-47ff29052c51@gmail.com> <57806d48-1d1f-c179-3e55-ba154d4e8baf@gmail.com> <135A489E-AC1A-40B8-AC86-DF63CE28BC4F@gmail.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 16:04:03 -0000 --Apple-Mail=_FE8FF090-3BB2-4685-B94B-DE7140B91EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 15, 2018, at 7:14 AM, Alexandre Petrescu = wrote: >=20 > In return, as a side point, I would ask whether or not a car with IPv6 > with "Data" headers talks to an RSU which implements IPv6 "QoS Data" > headers? The answer to this would be a good information point in = deciding. Some device drivers may choose to parse both. Some may choose to parse = only one. I don=E2=80=99t see how this helps in deciding. Tony --Apple-Mail=_FE8FF090-3BB2-4685-B94B-DE7140B91EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 15, 2018, at 7:14 AM, Alexandre Petrescu <alexandre.petrescu@cea.fr> wrote:

In return, as a side point, I = would ask whether or not a car with IPv6
with "Data" headers talks to an RSU which implements IPv6 = "QoS Data"
headers? =  The answer to this would be a good information point in = deciding.


Some device drivers may = choose to parse both.  Some may choose to parse only one.

I don=E2=80=99t see how = this helps in deciding.

Tony

= --Apple-Mail=_FE8FF090-3BB2-4685-B94B-DE7140B91EB5-- From nobody Mon Jul 16 02:34:48 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C95D2130F83; Mon, 16 Jul 2018 02:34:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <153173368076.22957.11710630143747180156@ietfa.amsl.com> Date: Mon, 16 Jul 2018 02:34:40 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 09:34:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases Author : Jaehoon Paul Jeong Filename : draft-ietf-ipwave-vehicular-networking-04.txt Pages : 30 Date : 2018-07-16 Abstract: This document discusses the problem statement and use cases on IP- based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and vehicle-to-everything (V2X) networking. First, this document surveys use cases using V2V, V2I, and V2X networking. Second, it analyzes proposed protocols for IP-based vehicular networking and highlights the limitations and difficulties found on those protocols. Third, it presents a problem exploration for key aspects in IP-based vehicular networking, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect, this document discusses a problem statement to analyze the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 17 10:41:33 2018 Return-Path: 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 49FDB13103A for ; Tue, 17 Jul 2018 10:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtN0XBSyMKHX for ; Tue, 17 Jul 2018 10:41:19 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B7D13101C for ; Tue, 17 Jul 2018 10:41:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3B71F300A32 for ; Tue, 17 Jul 2018 13:41:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id febV-RqkFD9b for ; Tue, 17 Jul 2018 13:41:16 -0400 (EDT) Received: from dhcp-8ced.meeting.ietf.org (dhcp-8ced.meeting.ietf.org [31.133.140.237]) by mail.smeinc.net (Postfix) with ESMTPSA id 49E4F3002C6 for ; Tue, 17 Jul 2018 13:41:16 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 17 Jul 2018 13:41:15 -0400 References: To: IP Wireless Access in Vehicular Environments Discussion List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [ipwave] Minutes from IETF 102 IPWAVE session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 17:41:30 -0000 Please review and comment on the draft minutes. There have been posted here: https://datatracker.ietf.org/meeting/102/materials/minutes-102-ipwave-00 Russ From nobody Wed Jul 18 08:03:42 2018 Return-Path: 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 CFC741311C7 for ; Wed, 18 Jul 2018 08:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pu7T51mamts for ; Wed, 18 Jul 2018 08:03:31 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F61813118B for ; Wed, 18 Jul 2018 08:03:31 -0700 (PDT) Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w6IF3Rjg007449 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jul 2018 08:03:28 -0700 From: Erik Nordmark To: its , cjbc@it.uc3m.es Message-ID: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> Date: Wed, 18 Jul 2018 11:03:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaLKG9/DQ0InuUvZiokS+fb7x5ES5i83Joc1IuMeboNbgZrx2elbUrNCB5c9rEc6eJDpXyRb86Bqe9jrdas1EDJ X-Sonic-ID: C;eg/PuZuK6BGCivMw1zjrCw== M;JDZEupuK6BGCivMw1zjrCw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 15:03:40 -0000 I volunteered (or was volunteered) to review this document during the ipwave meeting this week. Here are my comments and suggested modifications. Level 0. My assumption is that the OCB interface (in vehicles and infrastructure nodes) are attached to a router, and not a host. Is that correct? That assumption has a significant implication on the subnet/ND material. (And appendix H talks about hosts!) Section 4.5: "see the privacy considerations described in Appendix F." I think the key privacy considerations are (or should be if something is missing) in the security considerations section and not in an appendix. Appendix F provides useful background and design considerations, but I think this reference to appendix F is confusing. Section 4.3: I think the section should explicitly say that at most the link-local address can use the EUI-64 based interface identifier, by saying that any other IPv6 address should use either RFC8064 or RFC7217. I think that is the intent, but the wording doesn't make it clear. Section 4.6 first paragraph: I don't understand why there needs to be a subnet prefix assigned to the ephemeral connectivity between the vehicles in range. AFAIU that is router to router communication which can use link-local IPv6 addresses. The routing protocols I know can operate using link-local addresses. Section 4.6 third paragraph: 802.11 does not provide reliability for the ND multicast messages. Thus I don't think OCB is any different than 802.11 in this respect. I think this paragraph can be removed. If not, it should say the opposite of that it says right now. Section 4.6 forth paragraph: I don't know why one would have a mobile host directly attached to the OCB link. My understanding is that only routers are attached to the OCB link. Is that correct? In summary I think section 4.6 should say that the OCB link might not have any IP address prefix apart from the link-local prefix. If it does have some other IP prefix, then one would need to determine who would advertise that/those prefixes (will the infrastructure nodes send RAs with prefixes? Each vehicle??) After the reference to RFC5889 it might make sense to explicitly restate this from that RFC: o no on-link subnet prefix should be configured on such an interface. RFC5889 seems to suggest that it would be useful and in some cases required to configure a non-link-local address for the OCB interface. But such an address would probably need to be checked for uniqness in the routing domain, and it isn't clear to me whether that would fit the timing requirements for v2x. Section 5 IPSec and SeND discussion. I'll defer to security experts on this. I suspect it requires a separate draft to specify how IPsec and/or SeND can be part of a security solution. Section 5 last paragraph. I think this section should say at the instant the MAC address is changed on the OCB interface, the node needs to also change all of the IIDs on the OCB interface (link-local and any globals). Section 5 last paragraph. I don't understand what this text is trying to say and I suggest it be dropped: 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 and would hence dynamically change the affected IP address), in the way the IPv6 Privacy addresses were used, and other effects. The actual policy for when the MAC address is changed on the OCB interface is presumably to-be-determined. Might make sense to note that in the text. I note there is some mention of this in appendix C thus it might make sense to add a reference to that appendix. Appendix C last paragraph: The "may have an influence" followed by the reference to 4.6 seems to imply that something special is going on in section 4.6 which isn't there. That's confusing. I suggest dropping that paragraph. Appendix F.4 uses the term pseudonyme without ever defining it. Hence it isn't clear what the stated requirement is. Appendix H refers to a geolocation database and a GeoIP, yet the changelog claims that those concepts have been removed from the document. (I don't know how useful appendix H is to an implementor. It isn't about how to implement things but what wireshark will show so doesn't match the name of the section.) Appendix I seems misplaced. If the reader needs to know these terms, then they should be in the terminology section and not in an appendix. If the reader doesn't need to know then, then they don't need to be in the document. Note that the document has a lot more of appendix text than body text. It is a 15 page document with 25 pages of appendices. I don't know how useful those appendices will be to a new reader; they might have been useful as part of producing the document. But might want to consider which part of the appendices are still needed. Erik From nobody Wed Jul 18 08:19:08 2018 Return-Path: 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 B30A81311FD for ; Wed, 18 Jul 2018 08:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 iJnTbuiKt3pH for ; Wed, 18 Jul 2018 08:18:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E5513117A for ; Wed, 18 Jul 2018 08:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6002; q=dns/txt; s=iport; t=1531927126; x=1533136726; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8lBbD+WcQG64xAcLZ0Joj1i2Fr30PlMBIyRGfc9R6aA=; b=P3dwaXM/k7+634TDcZiQv5tMVOsizaxYzWHY2m1eUN2DDJbPLRYb5Dxx 71/BAYGvYajmH/oXO8Q+X2B551UIBTmNlOIbjKGx+BMZ94QcXultj5mmU QZE5pEdvMZgBiks0S80mNQg04mh1tOQ5JgQy8ep7jqvRwY3Hj2dnnNa1w A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAAD0WU9b/4oNJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNJY38oCot4jCyCDJU5FIFmCxgLhEkCgnkhNBgBAgEBAgEBAm0?= =?us-ascii?q?cDIU3AQEDAQEBODEDEAsCAQg2ECcLJQIEARIbgwaBdwgPqwGEW4VpBYkCgVc?= =?us-ascii?q?/hCKDGQEBgSQkhW4CjFqFEId2CQKPJYk4hC6RcAIRFIEkHThAgRJwFTuCaYs?= =?us-ascii?q?VhT5vi3qBGgEB?= X-IronPort-AV: E=Sophos;i="5.51,370,1526342400"; d="scan'208";a="425555045" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 15:18:45 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w6IFIjQe008005 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2018 15:18:45 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 18 Jul 2018 10:18:45 -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.1320.000; Wed, 18 Jul 2018 10:18:45 -0500 From: "Sri Gundavelli (sgundave)" To: Erik Nordmark , its , "cjbc@it.uc3m.es" Thread-Topic: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 Thread-Index: AQHUHqixOSsI+N4zO0eZIYzvpV6Aa6SU9mAA Date: Wed, 18 Jul 2018 15:18:45 +0000 Message-ID: References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> In-Reply-To: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> 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.24.70.204] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 15:19:02 -0000 > Section 4.6 forth paragraph: > I don't know why one would have a mobile host directly attached to the > OCB link. My understanding is that only routers are attached to the OCB > link. Is that correct? Typically it will be a router; a router with the OCB interface as the egress WAN interface, and with Ethernet (including CAN2IP), Wi-Fi interfaces on the ingress side. Though nothing stops an OEM to allow an host with Safety applications directly using the OCB interface for sending/receiving traffic, but I would not bother to deal with that case, as that is highly unlikely some one would do that. Sri On 7/18/18, 8:03 AM, "its on behalf of Erik Nordmark" wrote: > >I volunteered (or was volunteered) to review this document during the >ipwave meeting this week. >Here are my comments and suggested modifications. > > >Level 0. My assumption is that the OCB interface (in vehicles and >infrastructure nodes) are attached to a router, and not a host. Is that >correct? >That assumption has a significant implication on the subnet/ND material. >(And appendix H talks about hosts!) > > >Section 4.5: "see the privacy considerations described in Appendix F." >I think the key privacy considerations are (or should be if something is >missing) in the security considerations section and not in an appendix. >Appendix F provides useful background and design considerations, but I >think this reference to appendix F is confusing. > >Section 4.3: >I think the section should explicitly say that at most the link-local >address can use the EUI-64 based interface identifier, by saying that >any other IPv6 address should use either RFC8064 or RFC7217. I think >that is the intent, but the wording doesn't make it clear. > >Section 4.6 first paragraph: >I don't understand why there needs to be a subnet prefix assigned to the >ephemeral connectivity between the vehicles in range. AFAIU that is >router to router communication which can use link-local IPv6 addresses. >The routing protocols I know can operate using link-local addresses. > >Section 4.6 third paragraph: >802.11 does not provide reliability for the ND multicast messages. >Thus I don't think OCB is any different than 802.11 in this respect. >I think this paragraph can be removed. If not, it should say the >opposite of that it says right now. > >Section 4.6 forth paragraph: >I don't know why one would have a mobile host directly attached to the >OCB link. My understanding is that only routers are attached to the OCB >link. Is that correct? > >In summary I think section 4.6 should say that the OCB link might not >have any IP address prefix apart from the link-local prefix. > >If it does have some other IP prefix, then one would need to determine >who would advertise that/those prefixes (will the infrastructure nodes >send RAs with prefixes? Each vehicle??) > >After the reference to RFC5889 it might make sense to explicitly restate >this from that RFC: > o no on-link subnet prefix should be configured on such an > interface. > >RFC5889 seems to suggest that it would be useful and in some cases >required to configure a non-link-local address for the OCB interface. >But such an address would probably need to be checked for uniqness in >the routing domain, and it isn't clear to me whether that would fit the >timing requirements for v2x. > >Section 5 IPSec and SeND discussion. I'll defer to security experts on >this. I suspect it requires a separate draft to specify how IPsec and/or >SeND can be part of a security solution. > >Section 5 last paragraph. I think this section should say at the instant >the MAC address is changed on the OCB interface, the node needs to also >change all of the IIDs on the OCB interface (link-local and any globals). > >Section 5 last paragraph. I don't understand what this text is trying to >say and I suggest it be dropped: > 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 and would > hence dynamically change the affected IP address), in the way the > IPv6 Privacy addresses were used, and other effects. > >The actual policy for when the MAC address is changed on the OCB >interface is presumably to-be-determined. Might make sense to note that >in the text. I note there is some mention of this in appendix C thus it >might make sense to add a reference to that appendix. > >Appendix C last paragraph: >The "may have an influence" followed by the reference to 4.6 seems to >imply that something special is going on in section 4.6 which isn't >there. That's confusing. I suggest dropping that paragraph. > >Appendix F.4 uses the term pseudonyme without ever defining it. Hence it >isn't clear what the stated requirement is. > >Appendix H refers to a geolocation database and a GeoIP, yet the >changelog claims that those concepts have been removed from the >document. (I don't know how useful appendix H is to an implementor. It >isn't about how to implement things but what wireshark will show so >doesn't match the name of the section.) > >Appendix I seems misplaced. >If the reader needs to know these terms, then they should be in the >terminology section and not in an appendix. If the reader doesn't need >to know then, then they don't need to be in the document. > >Note that the document has a lot more of appendix text than body text. >It is a 15 page document with 25 pages of appendices. >I don't know how useful those appendices will be to a new reader; they >might have been useful as part of producing the document. But might want >to consider which part of the appendices are still needed. > > Erik > > >_______________________________________________ >its mailing list >its@ietf.org >https://www.ietf.org/mailman/listinfo/its From nobody Wed Jul 18 10:55:32 2018 Return-Path: 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 216B2130EB2 for ; Wed, 18 Jul 2018 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7b3s9s3UMMS for ; Wed, 18 Jul 2018 10:55:24 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F16130E66 for ; Wed, 18 Jul 2018 10:55:24 -0700 (PDT) Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w6IHtJsl012732 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jul 2018 10:55:21 -0700 To: "Sri Gundavelli (sgundave)" , its , "cjbc@it.uc3m.es" References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> From: Erik Nordmark Message-ID: Date: Wed, 18 Jul 2018 13:55:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaLkoS2O/WpbObdCAovz6Y+8KNmcDHVXdnuimhGVJpXpWGhbV0erZlt6MeLn76LPiEuVHOxYIQs/dkUpLsTZGFw X-Sonic-ID: C;zgBCvLOK6BGG0PMw1zjrCw== M;bnzavLOK6BGG0PMw1zjrCw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 17:55:28 -0000 On 07/18/2018 11:18 AM, Sri Gundavelli (sgundave) wrote: >> Section 4.6 forth paragraph: >> I don't know why one would have a mobile host directly attached to the >> OCB link. My understanding is that only routers are attached to the OCB >> link. Is that correct? > > > Typically it will be a router; a router with the OCB interface as the > egress WAN interface, and with Ethernet (including CAN2IP), Wi-Fi > interfaces on the ingress side. > > Though nothing stops an OEM to allow an host with Safety applications > directly using the OCB interface for sending/receiving traffic, but I > would not bother to deal with that case, as that is highly unlikely some > one would do that. As long as that node participates in the routing protocol it is OK, since that removes the need to assign a subnet prefix to the OCB interface. The fact that the node doesn't have any downstream networks or hosts doesn't matter. Erik > > > > Sri > > > > > > On 7/18/18, 8:03 AM, "its on behalf of Erik Nordmark" > wrote: > >> >> I volunteered (or was volunteered) to review this document during the >> ipwave meeting this week. >> Here are my comments and suggested modifications. >> >> >> Level 0. My assumption is that the OCB interface (in vehicles and >> infrastructure nodes) are attached to a router, and not a host. Is that >> correct? >> That assumption has a significant implication on the subnet/ND material. >> (And appendix H talks about hosts!) >> >> >> Section 4.5: "see the privacy considerations described in Appendix F." >> I think the key privacy considerations are (or should be if something is >> missing) in the security considerations section and not in an appendix. >> Appendix F provides useful background and design considerations, but I >> think this reference to appendix F is confusing. >> >> Section 4.3: >> I think the section should explicitly say that at most the link-local >> address can use the EUI-64 based interface identifier, by saying that >> any other IPv6 address should use either RFC8064 or RFC7217. I think >> that is the intent, but the wording doesn't make it clear. >> >> Section 4.6 first paragraph: >> I don't understand why there needs to be a subnet prefix assigned to the >> ephemeral connectivity between the vehicles in range. AFAIU that is >> router to router communication which can use link-local IPv6 addresses. >> The routing protocols I know can operate using link-local addresses. >> >> Section 4.6 third paragraph: >> 802.11 does not provide reliability for the ND multicast messages. >> Thus I don't think OCB is any different than 802.11 in this respect. >> I think this paragraph can be removed. If not, it should say the >> opposite of that it says right now. >> >> Section 4.6 forth paragraph: >> I don't know why one would have a mobile host directly attached to the >> OCB link. My understanding is that only routers are attached to the OCB >> link. Is that correct? >> >> In summary I think section 4.6 should say that the OCB link might not >> have any IP address prefix apart from the link-local prefix. >> >> If it does have some other IP prefix, then one would need to determine >> who would advertise that/those prefixes (will the infrastructure nodes >> send RAs with prefixes? Each vehicle??) >> >> After the reference to RFC5889 it might make sense to explicitly restate >> this from that RFC: >> o no on-link subnet prefix should be configured on such an >> interface. >> >> RFC5889 seems to suggest that it would be useful and in some cases >> required to configure a non-link-local address for the OCB interface. >> But such an address would probably need to be checked for uniqness in >> the routing domain, and it isn't clear to me whether that would fit the >> timing requirements for v2x. >> >> Section 5 IPSec and SeND discussion. I'll defer to security experts on >> this. I suspect it requires a separate draft to specify how IPsec and/or >> SeND can be part of a security solution. >> >> Section 5 last paragraph. I think this section should say at the instant >> the MAC address is changed on the OCB interface, the node needs to also >> change all of the IIDs on the OCB interface (link-local and any globals). >> >> Section 5 last paragraph. I don't understand what this text is trying to >> say and I suggest it be dropped: >> 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 and would >> hence dynamically change the affected IP address), in the way the >> IPv6 Privacy addresses were used, and other effects. >> >> The actual policy for when the MAC address is changed on the OCB >> interface is presumably to-be-determined. Might make sense to note that >> in the text. I note there is some mention of this in appendix C thus it >> might make sense to add a reference to that appendix. >> >> Appendix C last paragraph: >> The "may have an influence" followed by the reference to 4.6 seems to >> imply that something special is going on in section 4.6 which isn't >> there. That's confusing. I suggest dropping that paragraph. >> >> Appendix F.4 uses the term pseudonyme without ever defining it. Hence it >> isn't clear what the stated requirement is. >> >> Appendix H refers to a geolocation database and a GeoIP, yet the >> changelog claims that those concepts have been removed from the >> document. (I don't know how useful appendix H is to an implementor. It >> isn't about how to implement things but what wireshark will show so >> doesn't match the name of the section.) >> >> Appendix I seems misplaced. >> If the reader needs to know these terms, then they should be in the >> terminology section and not in an appendix. If the reader doesn't need >> to know then, then they don't need to be in the document. >> >> Note that the document has a lot more of appendix text than body text. >> It is a 15 page document with 25 pages of appendices. >> I don't know how useful those appendices will be to a new reader; they >> might have been useful as part of producing the document. But might want >> to consider which part of the appendices are still needed. >> >> Erik >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > From nobody Wed Jul 18 11:24:14 2018 Return-Path: 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 70D01130EDA for ; Wed, 18 Jul 2018 11:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 17LOSyPnplwc for ; Wed, 18 Jul 2018 11:24:09 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18655130EEA for ; Wed, 18 Jul 2018 11:24:09 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id w3-v6so2410834plq.2 for ; Wed, 18 Jul 2018 11:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:mime-version :content-transfer-encoding; bh=+Xso6UTxvqVJkqUAp5KDkLc0LHKvd1TOZ1hg8QCXGD8=; b=cxBA3m9qBiAzDUjekVhJ9zqrAL3rZkQpZ1FUuKGzYUzbJfYwIXJuqYpvCez4O0j/Xf XgOJ1lzlJ/Qv3Sfcu17YpYfOWZh2Hukbsx5k5yJq9gBZ7X306ks22iuqUwZytesI+J59 z5cHQyGJ1fHmPGz0Vv3X0ix2a4sUyAhEDx8umPyCRzxGjNYhy8ckeNQ6e4MNPytXYLg6 XB+LD5yQwas+6Uyqf2Xtp9olLYUkSnfY2SENhnQ8leh2TsMDrySEWPJosUtv50e+9rjn yVMihatt1zKvtYXlXlRCY+KnktP+0MOWZWk6asuyKhvNBjmOwnkmIKLQNWjzVUi6WSmH aDhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=+Xso6UTxvqVJkqUAp5KDkLc0LHKvd1TOZ1hg8QCXGD8=; b=ZLff1lxik81+r8Xk4+qQYn0tLYGG5W09BoxnfEWKr2mdG6Sjajk+AlQvlRlz1RL0w1 9IQOSS/EyDqNopXR8JjCFF5CnTOt4LqsDD/yuvAD59WTeaqcokjxGyZZF++hSu4XsRZ1 Dc8gX30nHzXbu8Q59xgOnNAk/g1IweJhn9/IHec8JVSb35Cwt3mSGVsuFkG7Lw+6ijIa 5s6Sd9zxlyJrOvgDyFXN6pY5H24Bkf1XUcxFRJqMq7/itXZJGQoLXah59k5WBOtWK/c7 wlD23Xuq88aZsvGh2HBeOyG27LG/b8b9BInqixFlMxKXz1X+gD++4H7GDlZdCW2sbj4A icKg== X-Gm-Message-State: AOUpUlFCgWZnb9DBPDDOkBNmLR+qZpec1H8d8N1ZO7FfJZyO2/xvts4w XIBi4ZOWFc4aJTy4Xs900Og= X-Google-Smtp-Source: AAOMgpeCzZRU7ut32GPtBgo7qi5Rqfzd6TOlIZk/Xu//aRlvTi742rckfCBE72fCkWF7yJxF4zPKPw== X-Received: by 2002:a17:902:1d4a:: with SMTP id u10-v6mr5698598plu.267.1531938248715; Wed, 18 Jul 2018 11:24:08 -0700 (PDT) Received: from localhost.localdomain (c-73-241-197-249.hsd1.ca.comcast.net. [73.241.197.249]) by smtp.gmail.com with ESMTPSA id b192-v6sm22302937pga.2.2018.07.18.11.24.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Jul 2018 11:24:08 -0700 (PDT) Message-ID: <1531938247.2298.134.camel@gmail.com> From: Rex Buddenberg To: Erik Nordmark , "Sri Gundavelli (sgundave)" , its , "cjbc@it.uc3m.es" Date: Wed, 18 Jul 2018 11:24:07 -0700 In-Reply-To: References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:24:13 -0000 Erik, You've tripped over an important observation.  And I think you're right. A lot of the IEEE 1609 conversation circa a couple years ago tacitly assumed [host--single-link--host] and ignored even the possibility of a backside LAN in the vehicle.  This oversimplifies the problem and makes it look like it can all fit in the ethernet technology.  Every time I asked about multiple segments, I got layer 2 bridging answers (and not very articulate ones).  Nobody remembered spanning tree so the ringing implications of that were never considered in the environment.  The 1609 short stack essentially voids layers 3,4,5 so they have to go through those contortions for completeness.       IMHO, you should worry primarily about router-router (with lots of multicast) as the main event.  Presence of hosts directly on the radio- WAN should be simply a degenerate case. A little out of scope of your question, but the voiding of the internetworking layers in 1609 did have one beneficial side effect: it forced the security problem into layers 6/7 where it belongs.   b On Wed, 2018-07-18 at 13:55 -0400, Erik Nordmark wrote: > On 07/18/2018 11:18 AM, Sri Gundavelli (sgundave) wrote: > > > > > > > > Section 4.6 forth paragraph: > > > I don't know why one would have a mobile host directly attached > > > to the > > > OCB link. My understanding is that only routers are attached to > > > the OCB > > > link. Is that correct? > > > > Typically it will be a router; a router with the OCB interface as > > the > > egress WAN interface, and with Ethernet (including CAN2IP), Wi-Fi > > interfaces on the ingress side. > > > > Though nothing stops an OEM to allow an host with Safety > > applications > > directly using the OCB interface for sending/receiving traffic, but > > I > > would not bother to deal with that case, as that is highly unlikely > > some > > one would do that. > As long as that node participates in the routing protocol it is OK,  > since that removes the need to assign a subnet prefix to the OCB > interface. > > The fact that the node doesn't have any downstream networks or hosts  > doesn't matter. > >     Erik > > > > > > > > > > > Sri > > > > > > > > > > > > On 7/18/18, 8:03 AM, "its on behalf of Erik Nordmark" > > wrote: > > > > > > > > > > > I volunteered (or was volunteered) to review this document during > > > the > > > ipwave meeting this week. > > > Here are my comments and suggested modifications. > > > > > > > > > Level 0. My assumption is that the OCB interface (in vehicles and > > > infrastructure nodes) are attached to a router, and not a host. > > > Is that > > > correct? > > > That assumption has a significant implication on the subnet/ND > > > material. > > > (And appendix H talks about hosts!) > > > > > > > > > Section 4.5: "see the privacy considerations described in > > > Appendix F." > > > I think the key privacy considerations are (or should be if > > > something is > > > missing) in the security considerations section and not in an > > > appendix. > > > Appendix F provides useful background and design considerations, > > > but I > > > think this reference to appendix F is confusing. > > > > > > Section 4.3: > > > I think the section should explicitly say that at most the link- > > > local > > > address can use the EUI-64 based interface identifier, by saying > > > that > > > any other IPv6 address should use either RFC8064 or RFC7217. I > > > think > > > that is the intent, but the wording doesn't make it clear. > > > > > > Section 4.6 first paragraph: > > > I don't understand why there needs to be a subnet prefix assigned > > > to the > > > ephemeral connectivity between the vehicles in range. AFAIU that > > > is > > > router to router communication which can use link-local IPv6 > > > addresses. > > > The routing protocols I know can operate using link-local > > > addresses. > > > > > > Section 4.6 third paragraph: > > > 802.11 does not provide reliability for the ND multicast > > > messages. > > > Thus I don't think OCB is any different than 802.11 in this > > > respect. > > > I think this paragraph can be removed. If not, it should say the > > > opposite of that it says right now. > > > > > > Section 4.6 forth paragraph: > > > I don't know why one would have a mobile host directly attached > > > to the > > > OCB link. My understanding is that only routers are attached to > > > the OCB > > > link. Is that correct? > > > > > > In summary I think section 4.6 should say that the OCB link might > > > not > > > have any IP address prefix apart from the link-local prefix. > > > > > > If it does have some other IP prefix, then one would need to > > > determine > > > who would advertise that/those prefixes (will the infrastructure > > > nodes > > > send RAs with prefixes? Each vehicle??) > > > > > > After the reference to RFC5889 it might make sense to explicitly > > > restate > > > this from that RFC: > > >     o  no on-link subnet prefix should be configured on such an > > >        interface. > > > > > > RFC5889 seems to suggest that it would be useful and in some > > > cases > > > required to configure a non-link-local address for the OCB > > > interface. > > > But such an address would probably need to be checked for > > > uniqness in > > > the routing domain, and it isn't clear to me whether that would > > > fit the > > > timing requirements for v2x. > > > > > > Section 5 IPSec and SeND discussion. I'll defer to security > > > experts on > > > this. I suspect it requires a separate draft to specify how IPsec > > > and/or > > > SeND can be part of a security solution. > > > > > > Section 5 last paragraph. I think this section should say at the > > > instant > > > the MAC address is changed on the OCB interface, the node needs > > > to also > > > change all of the IIDs on the OCB interface (link-local and any > > > globals). > > > > > > Section 5 last paragraph. I don't understand what this text is > > > trying to > > > say and I suggest it be dropped: > > >     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 and > > > would > > >     hence dynamically change the affected IP address), in the way > > > the > > >     IPv6 Privacy addresses were used, and other effects. > > > > > > The actual policy for when the MAC address is changed on the OCB > > > interface is presumably to-be-determined. Might make sense to > > > note that > > > in the text. I note there is some mention of this in appendix C > > > thus it > > > might make sense to add a reference to that appendix. > > > > > > Appendix C last paragraph: > > > The "may have an influence" followed by the reference to 4.6 > > > seems to > > > imply that something special is going on in section 4.6 which > > > isn't > > > there. That's confusing. I suggest dropping that paragraph. > > > > > > Appendix F.4 uses the term pseudonyme without ever defining it. > > > Hence it > > > isn't clear what the stated requirement is. > > > > > > Appendix H refers to a geolocation database and a GeoIP, yet the > > > changelog claims that those concepts have been removed from the > > > document. (I don't know how useful appendix H is to an > > > implementor. It > > > isn't about how to implement things but what wireshark will show > > > so > > > doesn't match the name of the section.) > > > > > > Appendix I seems misplaced. > > > If the reader needs to know these terms, then they should be in > > > the > > > terminology section and not in an appendix. If the reader doesn't > > > need > > > to know then, then they don't need to be in the document. > > > > > > Note that the document has a lot more of appendix text than body > > > text. > > > It is a 15 page document with 25 pages of appendices. > > > I don't know how useful those appendices will be to a new reader; > > > they > > > might have been useful as part of producing the document. But > > > might want > > > to consider which part of the appendices are still needed. > > > > > >     Erik > > > > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Jul 18 11:49:25 2018 Return-Path: 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 B18E5130F8D for ; Wed, 18 Jul 2018 11:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be4WxevLpQG9 for ; Wed, 18 Jul 2018 11:49:17 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D933130FBA for ; Wed, 18 Jul 2018 11:49:16 -0700 (PDT) Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w6IInCIA011602 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jul 2018 11:49:13 -0700 To: its From: Erik Nordmark Message-ID: <43613716-8628-486f-99ed-f09e881534a9@acm.org> Date: Wed, 18 Jul 2018 14:49:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYVpwEX0FdVNOwxtZpIildTlPMzRaYFEOaERyqv3wpvSGf3guyR0YNX/uHYd5Jphe+XQ5d2Z+V0R2GnGAYCKnS9 X-Sonic-ID: C;jCwBQ7uK6BGUGYG7ftbltA== M;jk+BQ7uK6BGUGYG7ftbltA== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: [ipwave] Comments on draft-ietf-ipwave-vehicular-networking-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:49:20 -0000 Here are some comments mostly around IP address management, neighbor discovery, and routing. I have not looked at the details for the proposals around geographic routing, but our collective experience and discussion of this in the IETF seems to indicate that geographic routing is difficult to deploy. I suspect we can solve this using existing mechanisms (such as PMIP-like solutions, or overlay networks, plus existing routing protocols on the OCB interfaces.) Level 0: Section 4 is titled "Analysis for Current Protocols", but it doesn't appear to discuss gaps in currently implemented and deployed protocols, but discuss some set of proposals for new protocols or protocol changes/extensions. That confusing makes it hard to use this document as input to gap analysis and rechartering. So while it is useful to have an inventory of various proposals, I'd be more comfortable with a gap analysis of what can't be done using existing RFCs. --- The document, just like the 80211-OCB document, doesn't state whether there is an assumption that only routers have OCB interfaces. That has significant impact on address configuration and neighbor discovery (and the associated bringup and convergence time when there is a change in connectivity.) I think it would be required to make an explicit and well-motivated choice in this space. Section 4.2.1.2. V2V-based Internetworking Shows as an example that 2001:DB8:1:1::/64 is assigned to the OCB link. I do not think it is useful to assing a global prefix to this very ephemeral link. Routing protocols can use link-local addresses. Section 4.1.5 DNS This seems to assume that somehow the applications in one vehicle would somehow know the names of hosts or services in an adjacent car. That doesn't seem realistic. I suspect that V2V applications will need some multicast or anycast discovery of services, and not rely on domain names. Section 5.1.1. Link Model This statement is factually incorrect: Also, in an IPv6 link, it is assumed that all interfaces which are configured with the same subnet prefix are on the same IP link. RFC4861 has an on-link bit for each prefix which allows e.g., stateless address autoconfiguration while not assuming a subnet prefix per link. RFC6775 shows an example where there is a subnet prefix spanning multiple links. *If* there is a need to not run routing protocols on the OCB interface, then I would strongly suggest that the working group look at RFC6675bis as a way to avoid the subnet prefix per link and avoid the 1 second DAD delay in RFC4862. However, if a routing protocol will be used then this isn't needed since no prefix (apart from link-local fe80::/64) is needed in that case. Based on that I'm not convinced of this statement in the section: Thus, IPv6 ND should be extended to support the concept of a link for an IPv6 prefix in terms of multicast in VANET. Section 5.1.2. MAC Address Pseudonym The draft seems to suggest that after the MAC and IP addresses have been changed, existing sessions should exchange their new IP addresses to provide session continuity. If that is done without strong end-to-end confidentiality there is no privacy benefit to changing the MAC and IP addresses, since an observer can see the change in the IP addresses. I suspect some VPN or encrypted overlay technology is needed to be able to provide these privacy benefits while providing session continuity. Section 5.1.3. Prefix Dissemination/Exchange seems to argue that neighbor discovery should become a routing protocol. That seems unwise because we already have a large body of routing protocols with different characteristics and some security support. Thus it doesn't seem useful to try to extend neighbor discovery in that direction. Section 5.1.4. Routing Note that DAD can be avoided on router-to-router links. If you do need a faster DAD there is the alternative in RFC6775. --- Erik From nobody Wed Jul 18 12:33:08 2018 Return-Path: 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 80372130FB8 for ; Wed, 18 Jul 2018 12:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ciLY9bmcHPP for ; Wed, 18 Jul 2018 12:33:01 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D76130F7F for ; Wed, 18 Jul 2018 12:33:01 -0700 (PDT) Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w6IJWuuS001614 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jul 2018 12:32:57 -0700 To: dickroy@alum.mit.edu, "'Erik Nordmark'" , "'its'" , cjbc@it.uc3m.es References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> <4F2339AADA044151BB499CD74C9D8500@SRA6> From: Erik Nordmark Message-ID: <9a81ba1b-ad6e-af18-2b41-dd2073dd3230@acm.org> Date: Wed, 18 Jul 2018 15:32:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4F2339AADA044151BB499CD74C9D8500@SRA6> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVbInNk7W4CiYdq2d6NDD/fVlwinZxULe3Uqwp7vXPH5ZywJDsyNVPBslwvIcggnrneJY5Yhfalbprz5RFrE9A/f X-Sonic-ID: C;+pX4XsGK6BGIE/Mw1zjrCw== M;XI5rX8GK6BGIE/Mw1zjrCw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 19:33:06 -0000 Dick, if you are in Montreal it would be quicker to chat in the hallway. Some responses below. On 07/18/2018 02:33 PM, Dick Roy wrote: > [RR] No it is not correct in all cases.  It is entirely possible to have > a node that consists of a host with an 802.11 MAC&PHY (OCB is > irrelevant) as the ingress/egress interface with no router functionality > at all. Fair enough. It's just that you need a completely different approach to support nodes which do not run routing protocols (~hosts) than those that do. That makes the overall system more complex, in particular if most of the time there will be a router. > In summary I think section 4.6 should say that the OCB link might not > > have any IP address prefix apart from the link-local prefix. > > [RR] OCB links do NOT have network layer addresses. OCB links are layer > 2 objects and as such, use layer 2 addressing which for all 802 LANs is > 802 MAC addressing. Furthermore, not all nodes in a LAN (or VLAN) need > network layer addresses.  Bridged LANs are everywhere and .11ak now > provides means for using 802.11 links in such LANs! Note that the definition of "link" is different in the IETF and IEEE 802. For the IETF definition we do assign IP subnet prefixes to links, whether the link is Ethernet or anything else. For "link" as defined and used in IEEE 802 I agree with you about the layer 2 object. However, if you are considering bridging things then ipwave isn't the right place to work on things. Regards, Erik From nobody Fri Jul 20 05:27:59 2018 Return-Path: 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 55B91127AC2 for ; Fri, 20 Jul 2018 05:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sfeQOeWzK84d for ; Fri, 20 Jul 2018 05:27:55 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B341124D68 for ; Fri, 20 Jul 2018 05:27:55 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id w16-v6so14420057ita.0 for ; Fri, 20 Jul 2018 05:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AfXRA068Dc/RS1BXiVE54wocq+qJ3d1+9u07gbLAcUk=; b=TEC32ntpkBGXL0cMuOcBQKOYzp3hY9e5XXsquh/lZVrRgJJENGFa4rEUEta4VI4GXz aQOTry7fJ6Ow2R3X4a9SnkGh7mbKb3m+h2fnqSvCemHGtEEemxD4OkXkW/29N8tm3MGC ITkz3dvsex+fQXOwMJtuPK36CtYr2dkv7zKCsS7LiMkONJ4cEh05IJkr7g422wxtXYas ZgX2rtJqhtZwJHxAKVxVqDpGhVyUAXxPyRCCWCr/WU/QxwXz1GZbmBhFZcCoYHYWM0Pj msN9Cgi5QxUwVeGo4bSGsQB1ajPNv6+p1RZ38jniC8nFE/td2qHSIyNxZiyxxUD/CfM6 Bb4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AfXRA068Dc/RS1BXiVE54wocq+qJ3d1+9u07gbLAcUk=; b=h++xwJWCwU/KaSft1eBiou9la5rYapvjdxryUd5xD+ZTRoOHpmendGnX8dSavS5XwN jF/XLopnsQhONLdE01KR0iMKRgGun8q+tUG51IzfVbjLsMXPfRohHnO7u+kknwT9H335 2BVbaJTiRi3OPwAoJDdf4TchBE5WG2gd2jrK2YYqZVNQ4qx+gLx4Vs5ZC4sq0N2M/P6h Y3OrrMp/m+JVqupojgBP9gWMQ8vU7EQ4T40z2qXBzNKGlWclNAHjciwOlU4un9LbxmZf 1d044Kx8YO0NoGly5VMaxsVcTMlol/O8AgDqBW8hvvcb391lIYM3GGCYAVAGpX74fw48 r4xQ== X-Gm-Message-State: AOUpUlFZVg13fVtSheybHZqrUxlHFwrsrYvmdEeK3b1ait22QELEDPHM Ptk4GidSQ6IvCjdhNZfrqDzPDlgDakMP83kOXTY= X-Google-Smtp-Source: AAOMgpcAH03X3K1ztSU8WMGrVO+1HO2ZTn40Jfp5X0R6UBD+zjH0yDUluSQV/OfySdC+R7/97h2p+lOi9o3aq8RY4Ac= X-Received: by 2002:a24:fc85:: with SMTP id b127-v6mr1516789ith.133.1532089674183; Fri, 20 Jul 2018 05:27:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:2696:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 05:27:23 -0700 (PDT) In-Reply-To: <43613716-8628-486f-99ed-f09e881534a9@acm.org> References: <43613716-8628-486f-99ed-f09e881534a9@acm.org> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 20 Jul 2018 08:27:23 -0400 Message-ID: To: Erik Nordmark Cc: its , skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000cb3bd805716d6c00" Archived-At: Subject: Re: [ipwave] Comments on draft-ietf-ipwave-vehicular-networking-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 12:27:58 -0000 --000000000000cb3bd805716d6c00 Content-Type: text/plain; charset="UTF-8" Erik, Thanks for your intensive review on this Problem Statement (PS) draft. I put my answers inline. On Wed, Jul 18, 2018 at 2:49 PM, Erik Nordmark wrote: > Here are some comments mostly around IP address management, neighbor > discovery, and routing. > > I have not looked at the details for the proposals around geographic > routing, but our collective experience and discussion of this in the IETF > seems to indicate that geographic routing is difficult to deploy. > I suspect we can solve this using existing mechanisms (such as PMIP-like > solutions, or overlay networks, plus existing routing protocols on the OCB > interfaces.) > > => Geographic routing is not in the scope of our IPWAVE, but it will be > useful to route an event or notification > message to vehicles around a geographic position, such as an accident area. > > Level 0: Section 4 is titled "Analysis for Current Protocols", but it > doesn't appear to discuss gaps in currently implemented and deployed > protocols, but discuss some set of proposals for new protocols or protocol > changes/extensions. > > That confusing makes it hard to use this document as input to gap analysis > and rechartering. > > So while it is useful to have an inventory of various proposals, I'd be > more comfortable with a gap analysis of what can't be done using existing > RFCs => The current protocols are about academia research papers rather than IETF protocols. The gap analysis using existing RFCs will be enhanced in the next revision. > > > --- > > The document, just like the 80211-OCB document, doesn't state whether > there is an assumption that only routers have OCB interfaces. That has > significant impact on address configuration and neighbor discovery (and the > associated bringup and convergence time when there is a change in > connectivity.) > > I think it would be required to make an explicit and well-motivated choice > in this space. > => Both routers as RSUs and vehicles have OCB interfaces for wireless vehicular networks. I will include the assumption explicitly in the next revision. > > > Section 4.2.1.2. V2V-based Internetworking > > Shows as an example that 2001:DB8:1:1::/64 is assigned to the OCB link. > I do not think it is useful to assing a global prefix to this very > ephemeral link. Routing protocols can use link-local addresses. > > => In pure V2V, you are right. Link-local addresses are enough. However, in our vehicular network architecture in Figure 1 in the PS draft, V2V and V2I are supported together, so a global prefix will be useful. > > Section 4.1.5 DNS > This seems to assume that somehow the applications in one vehicle would > somehow know the names of hosts or services in an adjacent car. That > doesn't seem realistic. > => If in-vehicle devices use DNSNA protocol (in draft-jeong-ipwave-iot-dns-autoconf-03) and vehicular ND (in draft-jeong-ipwave-vehicular-neighbor-discovery-03), the DNS names of those devices are registered into a DNS server within a vehicle (or RSU), and the services of in-vehicle devices in another vehicle are advertised to other vehicles. In this case, such an assumption is valid. > I suspect that V2V applications will need some multicast or anycast > discovery of services, and not rely on domain names. > => In Section 4.1.6 (Service Discovery), DNS-SD and Vehicular ND can be used for service discovery based on multicast. Both port numbers and DNS names for services can be used for service discovery. Eric, your comment here is not clear to me. > > Section 5.1.1. Link Model > > This statement is factually incorrect: > Also, in an IPv6 link, it is assumed that all interfaces which are > configured with the same subnet prefix are on the same IP link. > => The statement can be revised as follows: Also, in the concept of IPv6 link model, it is assumed that all interfaces which are configured with the same prefix with on-link bit set can communicate with each other on an IP link or extended IP links via ND proxy. Is it better? > RFC4861 has an on-link bit for each prefix which allows e.g., stateless > address autoconfiguration while not assuming a subnet prefix per link. > RFC6775 shows an example where there is a subnet prefix spanning multiple > links. > > *If* there is a need to not run routing protocols on the OCB interface, > then I would strongly suggest that the working group look at RFC6675bis as > a way to avoid the subnet prefix per link and avoid the 1 second DAD delay > in RFC4862. > => Eric, I will look at RFC 6775 (RFC6775bis) and RFC 4862 according to your suggestion in non-routing protocol scenario. > However, if a routing protocol will be used then this isn't needed since > no prefix (apart from link-local fe80::/64) is needed in that case. > > Based on that I'm not convinced of this statement in the section: > Thus, IPv6 ND should be extended to support the concept of a link for > an IPv6 prefix in terms of multicast in VANET. > => This statement is clarified as follows: Thus, IPv6 ND should be extended to support a multi-link subnet with the same prefix with on-link bit set in a connected VANET, consisting of vehicles interconnected with DSRC communication range. > Section 5.1.2. MAC Address Pseudonym > > The draft seems to suggest that after the MAC and IP addresses have been > changed, existing sessions should exchange their new IP addresses to > provide session continuity. > If that is done without strong end-to-end confidentiality there is no > privacy benefit to changing the MAC and IP addresses, since an observer can > see the change in the IP addresses. > => That is a good point. I will address this privacy issue of strong end-to-end confidentiality in the revision. > > I suspect some VPN or encrypted overlay technology is needed to be able to > provide these privacy benefits while providing session continuity. > > > Section 5.1.3. Prefix Dissemination/Exchange > seems to argue that neighbor discovery should become a routing protocol. > That seems unwise because we already have a large body of routing > protocols with different characteristics and some security support. > > Thus it doesn't seem useful to try to extend neighbor discovery in that > direction. > > => You are right, but the consolidation of ND and routing functionality can help the reduction of control traffic in vehicular networks. So we need to study how to consolidate them in an efficient way. > Section 5.1.4. Routing > Note that DAD can be avoided on router-to-router links. > If you do need a faster DAD there is the alternative in RFC6775. > => I will include this DAD optimization in the revision. Thanks. Paul > > --- > > Erik > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000cb3bd805716d6c00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Erik,
Thanks for your intensive review on this Problem= Statement (PS) draft.
I put my answers inline.

On Wed, Jul 18, 2018 at 2:49 PM= , Erik Nordmark <nordmark@acm.org> wrote:
Here are some comments mostly around IP a= ddress management, neighbor discovery, and routing.

I have not looked at the details for the proposals around geographic routin= g, but our collective experience and discussion of this in the IETF seems t= o indicate that geographic routing is difficult to deploy.
I suspect we can solve this using existing mechanisms (such as PMIP-like so= lutions, or overlay networks, plus existing routing protocols on the OCB in= terfaces.)
=C2=A0
=3D> Geographic routing is not in the scope of our IPWAVE, but it will b= e useful to route an event or notification
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0message to vehicles around a geographic position, s= uch as an accident area.=C2=A0 =C2=A0 =C2=A0

Level 0: Section 4 is titled "Analysis for Current Protocols", bu= t it doesn't appear to discuss gaps in currently implemented and deploy= ed protocols, but discuss some set of proposals for new protocols or protoc= ol changes/extensions.

That confusing makes it hard to use this document as input to gap analysis = and rechartering.

So while it is useful to have an inventory of various proposals, I'd be= more comfortable with a gap analysis of what can't be done using exist= ing RFCs

=C2=A0 =C2=A0 =3D> The current = protocols are about academia research papers rather than IETF protocols.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The gap analysis using existing = RFCs will be enhanced in the next revision.
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0
=

---

The document, just like the 80211-OCB document, doesn't state whether t= here is an assumption that only routers have OCB interfaces. That has signi= ficant impact on address configuration and neighbor discovery (and the asso= ciated bringup and convergence time when there is a change in connectivity.= )

I think it would be required to make an explicit and well-motivated choice = in this space.

=C2=A0 =C2=A0 =3D> Bo= th routers as RSUs and vehicles have OCB interfaces for wireless vehicular = networks.=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I will i= nclude the assumption=20
Section 4.1.5 DNS
This seems to assume that somehow the applications in one vehicle would som= ehow know the names of hosts or services in an adjacent car. That doesn'= ;t seem realistic.

=C2=A0 =C2=A0 =3D>= ; If in-vehicle devices use DNSNA protocol (in draft-jeong-ipwave-iot-dns-a= utoconf-03) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vehicular= ND (in draft-jeong-ipwave-vehicular-neighbor-discovery-03), the DNS n= ames of=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0those devices are= registered into a DNS server within a vehicle (or RSU), and the services= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of in-vehicle devices in= another vehicle are advertised to other vehicles.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0In this case, such an assumption is valid.

I suspect that V2V applications will need some multicast or anycast discove= ry of services, and not rely on domain names.

=C2=A0 =C2=A0 =3D> In Section=C2=A04.1.6 (Service Discovery), DNS= -SD and Vehicular ND can be used for service discovery based on
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multicast. Both port numbers and DNS name= s for services can be used for service discovery.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Eric,=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0your comment here is not clear to me.
=C2=A0=C2=A0

Section 5.1.1.=C2=A0 Link Model

This statement is factually incorrect:
=C2=A0 =C2=A0Also, in an IPv6 link, it is assumed that all interfaces which= are
=C2=A0 =C2=A0configured with the same subnet prefix are on the same IP link= .

=C2=A0 =C2=A0 =C2=A0=3D> The state= ment can be revised as follows:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Also, in the concept of IPv6 link model, it is assumed that all i= nterfaces which are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0configured with the same prefix with on-link bit set can communicate wit= h=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0each other on an= IP link or extended IP links via ND proxy.

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Is it better?


RFC4861 has an on-link bit for each prefix which allows e.g., stateless add= ress autoconfiguration while not assuming a subnet prefix per link.
RFC6775 shows an example where there is a subnet prefix spanning multiple l= inks.

*If* there is a need to not run routing protocols on the OCB interface, the= n I would strongly suggest that the working group look at RFC6675bis as a w= ay to avoid the subnet prefix per link and avoid the 1 second DAD delay in = RFC4862.

=C2=A0 =C2=A0 =C2=A0=3D> Er= ic,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I will look at RFC 6= 775 (RFC6775bis) and RFC 4862 according to your suggestion
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in non-routing protocol scenario.
<= div>=C2=A0
However, if a routing protocol will be used then this isn't needed sinc= e no prefix (apart from link-local fe80::/64) is needed in that case.

Based on that I'm not convinced of this statement in the section:
=C2=A0 =C2=A0Thus, IPv6 ND should be extended to support the concept of a l= ink for
=C2=A0 =C2=A0an IPv6 prefix in terms of multicast in VANET.
=C2=A0
=C2=A0 =C2=A0 =3D> This statement is clarified as= follows:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Thus, IPv6 ND should be extended to support a multi= -link subnet with the same prefix=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0with on-link bit set in a connected VANET, consisting of vehicles= interconnected=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with DSRC= communication range.


Section 5.1.2.=C2=A0 MAC Address Pseudonym

The draft seems to suggest that after the MAC and IP addresses have been ch= anged, existing sessions should exchange their new IP addresses to provide = session continuity.
If that is done without strong end-to-end confidentiality there is no priva= cy benefit to changing the MAC and IP addresses, since an observer can see = the change in the IP addresses.

=C2=A0 = =C2=A0 =3D> That is a good point.=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 I will address this privacy issue of=20
I suspect some VPN or encrypted overlay technology is needed to be able to = provide these privacy benefits while providing session continuity.


Section 5.1.3.=C2=A0 Prefix Dissemination/Exchange
seems to argue that neighbor discovery should become a routing protocol. That seems unwise because we already have a large body of routing protocols= with different characteristics and some security support.

Thus it doesn't seem useful to try to extend neighbor discovery in that= direction.

=C2=A0 =C2=A0 =C2=A0=3D> You are right, but the co= nsolidation of ND and routing functionality can help
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the reduction of control traffic in vehicula= r networks.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So we need t= o study how to consolidate them in an efficient way.
=C2=A0
=
Section 5.1.4.=C2=A0 Routing
Note that DAD can be avoided on router-to-router links.
If you do need a faster DAD there is the alternative in RFC6775.
=C2=A0
=C2=A0 =C2=A0 =C2=A0=3D> I will include this= DAD optimization in the revision.

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Thanks.
=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul
=C2=A0

---

=C2=A0 =C2=A0Erik

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr= . Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Softw= are
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com= ,=C2=A0pauljeong@skku.edu
Personal Homepage: htt= p://iotlab.skku.edu/people-jaehoon-jeong.php
=
--000000000000cb3bd805716d6c00-- From nobody Fri Jul 20 10:18:04 2018 Return-Path: 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 081E5130E28 for ; Fri, 20 Jul 2018 10:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.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 z75CgPGxxCLf for ; Fri, 20 Jul 2018 10:17:58 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7648130EF6 for ; Fri, 20 Jul 2018 10:17:57 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id y124-v6so5749058itc.0 for ; Fri, 20 Jul 2018 10:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=MBTy29nPIv/76LUhXG6zQyudNfgeC92zmn49exl1EUQ=; b=Cbf6J1BlgA9Ejowwln+1C1PvXhPMcQi0bmDd/gg+NLwpikAtD8w94IT9PpGQc4cXsL ICHHDZGWEAsngb7dyaT2vpLsRWq3YIbOOb9JvWul3Bf0i5mxV372dJNsmM4cE64Vt+Kd Gon5W3b5A5W9gK4eVTNaBRdX7gXRoWAeUsBOWsb4qE8jgoTDZUF8A1VA28G+DDQsv9x+ bZhb8cuWugZL1LpYkri+jekGEbpMHdvgwgvbJh+MFkXqtlaH6E5D5H60ZAAdxHD/YNak sswi4LvYN0HWU/3QpKoKf21JvocmnqsnzEhhH2+oH4q77topfB0HxJGOszbTC4O/SVC4 gD9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=MBTy29nPIv/76LUhXG6zQyudNfgeC92zmn49exl1EUQ=; b=h0feze/aGCtyEKoXujjhljJ04F1ux67kLFFwESRPJhcqWziYDd/T9jzknojVyhziaM UeqKn6IwqcO6ntJiITyTSrYqNHbMgSjW+yDMo6llXiEmY2/dwVGE996c+mxVkM0Z/QcW BdnuLT13nuhH2vruMCf9piktDYIVrPq9L2P0Ys/hlmkH+T/YZTMkHTUWllMLfMnPr9Tr +kg05WBzAr0XWaYDHAHYNSdSLPwOjXWTEb1J9rXOb55wbbBfH2AvvaeVzSQJnxQV0s+s 6jX4XKo6Dn7Kv2NcdwjRqNpdD3m+vFTDfarRxlZjoWhha+l9aNWv71vcOfONwe8cU63Z /tAw== X-Gm-Message-State: AOUpUlHWlBuY0fcrvSgdnyGwDJZVsvxQB9gw0lORq3W2MW2QF24W4fKW 8HO4k5ko46vYA83Hn9RTjEf3Xwr/S2spzQ== X-Google-Smtp-Source: AAOMgpdxH0S+mUDem6Aft7XWr/O4qoRgTtLRT1/ZgCq1QCxLUjc/6G40MiupwZ0zGRZuAAhWB1HkNw== X-Received: by 2002:a02:f02:: with SMTP id h2-v6mr2675282jad.24.1532107077194; Fri, 20 Jul 2018 10:17:57 -0700 (PDT) Received: from acorde ([2001:67c:1232:144:48f4:b271:bd94:f687]) by smtp.gmail.com with ESMTPSA id q204-v6sm1183360itb.27.2018.07.20.10.17.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Jul 2018 10:17:56 -0700 (PDT) Message-ID: <482b019aa0a6afc7863b7d9da2537c41faa890f9.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Erik Nordmark , dickroy@alum.mit.edu, 'its' Date: Fri, 20 Jul 2018 19:17:39 +0200 In-Reply-To: <9a81ba1b-ad6e-af18-2b41-dd2073dd3230@acm.org> References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> <4F2339AADA044151BB499CD74C9D8500@SRA6> <9a81ba1b-ad6e-af18-2b41-dd2073dd3230@acm.org> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 17:18:02 -0000 Hi Dick, On Wed, 2018-07-18 at 15:32 -0400, Erik Nordmark wrote: > > Dick, > > if you are in Montreal it would be quicker to chat in the hallway. > Some responses below. > > On 07/18/2018 02:33 PM, Dick Roy wrote: > > > [RR] No it is not correct in all cases. It is entirely possible to > > have > > a node that consists of a host with an 802.11 MAC&PHY (OCB is > > irrelevant) as the ingress/egress interface with no router > > functionality > > at all. > > Fair enough. It's just that you need a completely different approach > to > support nodes which do not run routing protocols (~hosts) than those > that do. > > That makes the overall system more complex, in particular if most of > the > time there will be a router. > > > > In summary I think section 4.6 should say that the OCB link might > > not > > > > have any IP address prefix apart from the link-local prefix. > > > > [RR] OCB links do NOT have network layer addresses. OCB links are > > layer > > 2 objects and as such, use layer 2 addressing which for all 802 > > LANs is > > 802 MAC addressing. Furthermore, not all nodes in a LAN (or VLAN) > > need > > network layer addresses. Bridged LANs are everywhere and .11ak > > now > > provides means for using 802.11 links in such LANs! > > Note that the definition of "link" is different in the IETF and IEEE > 802. > > For the IETF definition we do assign IP subnet prefixes to links, > whether the link is Ethernet or anything else. > > For "link" as defined and used in IEEE 802 I agree with you about > the > layer 2 object. > > > However, if you are considering bridging things then ipwave isn't > the > right place to work on things. [Carlos] Fully echoing Erik's comment. Just an excerpt from our charter: " [...] specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode. [...]". Thanks, Carlos > > Regards, > Erik From nobody Fri Jul 20 19:50:37 2018 Return-Path: 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 1D02C130E55 for ; Fri, 20 Jul 2018 19:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.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 xweOuJRMxMzM for ; Fri, 20 Jul 2018 19:50:32 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885E6130DC5 for ; Fri, 20 Jul 2018 19:50:32 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id d70-v6so6735430ith.1 for ; Fri, 20 Jul 2018 19:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=ZxJOndJ3vM3YwnUHyPwLWQYSvXuOmhsKI1J5HbhzXNE=; b=SWb75CDC6rq7XVPhmR2c/Xa6/5xsdy+8uqNh8EADo28+VEK6nJEGqmNCd8SOD5FfYv ok7o3ASkWpRMego32y6CIh9GnU9Ly9rVTaHFV5/yU4cnQ2TtHI0rFo/ZEDoYkPL6fENW aWVHA5zWPWfaF6hOZtBfE3f9268K0ePvjIBcLvOzfOVD1QD3lLn8c3wG6jSUmMfw0fBL aY9jnESKN79HEEXZHkCAFRL9a1VhthwZGo64bGZgXp9GC3L7ce/UBoWyd/igqKOoxZ3s x2iif6tgjOnkFZ7vax7WiRtDxC2WJAa++zdF/nx2kosfUdxuMvI16nIhw/DWqn/NItJh WNcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=ZxJOndJ3vM3YwnUHyPwLWQYSvXuOmhsKI1J5HbhzXNE=; b=hdFS3LN2xSsAVEmM2TpQlc875Oa14kqLaDVWxp4lCdLgsNwruc6FQZLPBTBbq4b+LR k2twBDIxjBun3M6daGaMh7faH2rxCO9U7qH938AilKzextdwny72bUrqFAW8oMZoJ1d8 Z9paZNDP5tfRPaaMxKBBhaGVbRXH/giZa8QA9cotUVd74Ql2lmvWAqPPtr1un2JO0EmN XDrSUHDl3X1hrwFxt9762tWo+upPZnsC5SfWiqSVuuz8bE7X2yt+XUnnUz/xzN+i/oeu PJpKRQ42EuzubdN19Am09omZOgQyiu32fOZA+NUX1SW0lUlVp8uw+rOwjCaWrS1m/hbp bhxw== X-Gm-Message-State: AOUpUlETxlrzEPyJojVjE7DOWkR/oTl6EPetNsdoUgr/IaHa8bANZXXq CqXxqc7HU1CUT+oirrAuvvKxbQ== X-Google-Smtp-Source: AAOMgpds6CQhJA1q9iubi+iGs5r77q5sHUMmVo23DFy3PWN6l41cm4eK9/jdr7+brAdAuk3TJxgNrA== X-Received: by 2002:a02:ac8f:: with SMTP id x15-v6mr4092579jan.132.1532141431620; Fri, 20 Jul 2018 19:50:31 -0700 (PDT) Received: from acorde (ecp01.openface.ca. [207.115.96.130]) by smtp.gmail.com with ESMTPSA id 80-v6sm1923043itl.35.2018.07.20.19.50.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Jul 2018 19:50:30 -0700 (PDT) Message-ID: From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: dickroy@alum.mit.edu, 'Erik Nordmark' , 'its' Date: Sat, 21 Jul 2018 04:50:29 +0200 In-Reply-To: <7342FEE1ECFC4078B42D50E009F1CB08@SRA6> References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> <4F2339AADA044151BB499CD74C9D8500@SRA6> <9a81ba1b-ad6e-af18-2b41-dd2073dd3230@acm.org> <482b019aa0a6afc7863b7d9da2537c41faa890f9.camel@it.uc3m.es> <7342FEE1ECFC4078B42D50E009F1CB08@SRA6> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 02:50:36 -0000 Hi Dick, On Fri, 2018-07-20 at 14:44 -0700, Dick Roy wrote: > I realize the charter says "OCB mode" and I have fought against that > from > day one when we asked the IETF to look into the issue of rapidly > varying > network (LAN) topologies, but they just couldn't free themselves from > such > constrained thinking. Oh well :^((( Rapid varying topologies is not something exclusive of vehicular networks using IEEE 802.11-OCB. Current charter of ipwave is about to specify/describe what needs to be done to support basic IPv6 over IEEE 802.11-OCB as layer-2. Let's get this done, and then, if the community is interested and show enough energy, we can talk about tackling more complex networks (and see if the IESG thinks this WG is the right place to do it). Thanks, Carlos > > -----Original Message----- > From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] > Sent: Friday, July 20, 2018 10:18 AM > To: Erik Nordmark; dickroy@alum.mit.edu; 'its' > Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb- > 25 > > Hi Dick, > > On Wed, 2018-07-18 at 15:32 -0400, Erik Nordmark wrote: > > > > Dick, > > > > if you are in Montreal it would be quicker to chat in the hallway. > > Some responses below. > > > > On 07/18/2018 02:33 PM, Dick Roy wrote: > > > > > [RR] No it is not correct in all cases. It is entirely possible > > > to > > > have > > > a node that consists of a host with an 802.11 MAC&PHY (OCB is > > > irrelevant) as the ingress/egress interface with no router > > > functionality > > > at all. > > > > Fair enough. It's just that you need a completely different > > approach > > to > > support nodes which do not run routing protocols (~hosts) than > > those > > that do. > > > > That makes the overall system more complex, in particular if most > > of > > the > > time there will be a router. > > > > > > > In summary I think section 4.6 should say that the OCB link might > > > not > > > > > > have any IP address prefix apart from the link-local prefix. > > > > > > [RR] OCB links do NOT have network layer addresses. OCB links are > > > layer > > > 2 objects and as such, use layer 2 addressing which for all 802 > > > LANs is > > > 802 MAC addressing. Furthermore, not all nodes in a LAN (or VLAN) > > > need > > > network layer addresses. Bridged LANs are everywhere and .11ak > > > now > > > provides means for using 802.11 links in such LANs! > > > > Note that the definition of "link" is different in the IETF and > > IEEE > > 802. > > > > For the IETF definition we do assign IP subnet prefixes to links, > > whether the link is Ethernet or anything else. > > > > For "link" as defined and used in IEEE 802 I agree with you about > > the > > layer 2 object. > > > > > > However, if you are considering bridging things then ipwave isn't > > the > > right place to work on things. > > [Carlos] Fully echoing Erik's comment. Just an excerpt from our > charter: " [...] specify the mechanisms for transmission of IPv6 > datagrams over IEEE 802.11-OCB mode. [...]". > > Thanks, > > Carlos > > > > > Regards, > > Erik > > From nobody Fri Jul 27 06:27:14 2018 Return-Path: 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 3F911130E1E; Fri, 27 Jul 2018 06:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=c+e7j3p+; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=XeEWBzza 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 V-iSY2HBX6YZ; Fri, 27 Jul 2018 06:27:08 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B540130E5A; Fri, 27 Jul 2018 06:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1532698027; x=1564234027; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AjWVjcIkHe1OVApc7MpvEg91qR7KJvp4Zokq/Vd8pP4=; b=c+e7j3p+/KhntAtZJtrZ75ssF+DNL1AF44Vqcx+XiZiS3+d1naGm1YVU 8ui6oAbPSzVC5xYxPK8xWifysPXJrmJel1V6MwjDXXoWG2nin7ab1+AUz GE3ANAufLRSFJlPJDz6rKnbmXEaUvVMuXm7gs7MGxXGhHvScKjzbcriSY lIom8s5msaHzLsz7t091W+3lI1sAL1MEeTOF7pgEuq3EsonCkGoQCZKFb i/I9UGBKf6r4U5jGHtmeDW6YLhwQKtuId4O0uoiMs9KQphWy9MN3pdsQc niWtoZm1Fdf3KZRBrUnGGRZ9RMnxugIAGN3VNSEH/ztcCcVT3/Ty2hGsg Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2018 15:27:03 +0200 X-IronPort-AV: E=Sophos;i="5.51,409,1526335200"; d="scan'208";a="303134998" Received: from he106162.emea1.cds.t-internal.com ([10.169.118.73]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 27 Jul 2018 15:27:03 +0200 Received: from HE105848.EMEA1.cds.t-internal.com (10.169.118.22) by HE106162.emea1.cds.t-internal.com (10.169.118.73) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 27 Jul 2018 15:27:03 +0200 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105848.EMEA1.cds.t-internal.com (10.169.118.22) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 27 Jul 2018 15:27:03 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.17) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 27 Jul 2018 15:28:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AjWVjcIkHe1OVApc7MpvEg91qR7KJvp4Zokq/Vd8pP4=; b=XeEWBzzai5dkCXziUX4V5nZdY4OAWjrWTbXxzzgwz3McToFfGDaa4tpqQfZ0LbkfWpBnNhHGUSoXQ8gUDEnLZcTD/s/ehnNlmr6+/asvnNVDEEa4qD2V9WR8yNtWXvyT9+vJbQTEW2PHADHeOnqKlI7AOo5M189DJRKeg4DOlaw= Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.18) by FRAPR01MB0802.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Fri, 27 Jul 2018 13:27:01 +0000 Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::5812:8a3a:4362:c2d1]) by FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::5812:8a3a:4362:c2d1%4]) with mapi id 15.20.0995.019; Fri, 27 Jul 2018 13:27:01 +0000 From: To: , CC: , Thread-Topic: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt Thread-Index: AQHUHOhgJ4Onz+QK8UC1nbLZsTjEaKSi1hmw Date: Fri, 27 Jul 2018 13:27:01 +0000 Message-ID: References: <153173368076.22957.11710630143747180156@ietfa.amsl.com> In-Reply-To: <153173368076.22957.11710630143747180156@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.von-Hugo@telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0802; 6:mYD56HqnP9HEfPIwfe5TWJeorEV4/pS53j9b/I+yzNxkw/Mb0OVulNwKZSA0JR1b65KxCL62/TogLJVgnQCmROM3+KffRajbtPVxao8OVT1WXYjsCAnPlmhnm5du+MkW39YzFzvP7cftFGAB8s94Y3xC/VA8fgl3yk22NqeG4YrRVBGqq8FkhUaNpTc0857FXLVvb7FOdE0dnuwVRKQzKCHUnr0oPeJnTFnOeJXRo4oJvgmc/kP7/v69iu8Qp0kQlVc7Q9VN6k83WpPdwy0n7sHxULNudjFIWhCYY8wImfyrtdLEhuUl38X1Y+CV3lf/gsuvtswemtXfA7mqiQ5idnBjjpfAPXC+MePP8h6ERPvHFx0gYInxGB2KuNfNbCxz6WzmYjWSXmshuND+dmWWZIMORGLc9EJpnwE8O8NbrarEtR9/e6Hu+0LleaK6OUXdt3xIf1IYruzWS4Y7/DmFjA==; 5:gDouWhyL8CddSyXOoFt+f0igC5Gy7HhP7hPgezN7Zihvrcm605+0kHqiKJeyxMmMP/DphiIF6NjdxdQ1Y3kYYOMcN2AyvVam12tYI5NwpKPZa52a1rgaIygURxzob7bnPuNNd+FOYoJ/KUC+djokcbIzYcBqqYSQA0bvJ1PS0Jw=; 7:K1SSgAYoMwY5JpdK4RYPA01NHSDh97e/0xvnrw8VzzvO54PiDk1WsfjeNn2hqZFYn1szz74A6ju36b+Of3V7iU80kcH5sQUGpdOKagtZK7/JaFJCkh7jHtf3HEHyk3YQvforobCovHLbCAUa8QT0uOKHJsj6CwhRFQGkjVzVK99STm38jSGcJaUY+SO/4DbvjlnmAJcASwNDWSQxkj9sFTZNX9aTLfopmSjaO93N/XBRW+jjuAWZA4Wzh+CKl3S/ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 907d4e58-f911-4c7e-22c2-08d5f3c4a31c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0802; x-ms-traffictypediagnostic: FRAPR01MB0802: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(192374486261705)(788757137089)(21532816269658); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:FRAPR01MB0802; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0802; x-forefront-prvs: 07467C4D33 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(39860400002)(376002)(366004)(136003)(396003)(189003)(13464003)(199004)(81156014)(75402003)(7736002)(6246003)(305945005)(966005)(4326008)(14454004)(39060400002)(66066001)(229853002)(11346002)(7696005)(26005)(446003)(5250100002)(186003)(76176011)(102836004)(486006)(55016002)(476003)(53546011)(256004)(9686003)(14444005)(2501003)(86362001)(5660300001)(6306002)(2900100001)(52396003)(54906003)(2906002)(33656002)(316002)(53936002)(8676002)(110136005)(68736007)(72206003)(478600001)(6116002)(3846002)(106356001)(74482002)(8936002)(97736004)(413944005)(81166006)(105586002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0802; H:FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: VddCPmw8Mf0UTjOD9YIMRicDev/c0XMSDwUEStsWqs1ce5adSVFUox/bukGvSKQ7FTQlCyrjmOUhHkM2WsAHFevX1LtDPxxWKxmgPhMZOgUa67jbVcQ9LkfqVA4H/UyryraIDNGjo0bu9mQIjm3NHNb4jELVfC3HRr/RTKHH2dR0ynciEwzyCOTHalk4vpYKSiL/NqOeKazr0Y0pf5k7NBpEfnTcTgExS1xxp3WyXibTeZcmtVXTETuShLlZI6EEuj+SC/kvOXZdD121VhjklT87vYnvrCLgATTj8mxAlT8JVL4ux2zOuGel8p2e8ZaYEWjPlGfWV9ceN5s67THFzaII6OqlzwCBVrFOduwp1X4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 907d4e58-f911-4c7e-22c2-08d5f3c4a31c X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 13:27:01.7522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0802 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 13:27:12 -0000 Dear Jaehoon, all, I also volunteered in Montreal to review this draft which is a good startin= g point to identify work items for the future. I mainly agree with comments already made - especially on the privacy chall= enges and IP addresses - and would like to add some partly more editorial c= omments: I suggest to add already in the abstract the clarification (given later in = ch. 3) that X in V2X is understood here as everything else than I and V ...= if used together with V2V and V2I. I suggest to replace in Ch.1: For driving safety services based on the DSRC, IEEE has standardized Access= in Vehicular Environments (WAVE) standards, such as IEEE 802.11p [IEEE-802= .11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], and IEEE 1609.= 4 [WAVE-1609.4]. =20 By=20 For direct inter-vehicular wireless connectivity IEEE has amended WiFi stan= dard 802.11 to enable driving safety services based on the DSRC in terms of= standards for the Wireless Access in Vehicular Environments (WAVE) system.= L2 and L3 issues are addressed in IEEE 802.11p [IEEE-802.11p], security a= spects are covered in IEEE 1609.2 [WAVE-1609.2], while IEEE 1609.3 [WAVE-16= 09.3] defines related services at network and transport layers and IEEE 160= 9.4 [WAVE-1609.4] specifies the multi-channel operation. Furthermore I suggest to put references near the related terms e.g.:=20 IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to veh= icular networks [RFC8200][RFC5944][RFC6275] =3D>=20 IPv6 [RFC8200] and Mobile IP protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RF= C6275]) can be applied or easily modified to vehicular networks. standardized a standard specifying =3D> approved a standard specifying which is IP ...=3D> denoted as IP ... Also, it also discusses relevant work items to IPWAVE =3D> Also, it discuss= es relevant and potential new work items to IPWAVE WG In Ch. 2 I suggest to change: An RSU is deployed either at an intersection or in a road segment =3D> An R= SU is typically deployed at an intersection or in a road segment, but may a= lso be located in car parking areas=20 communications with other OBUs and RSUs. =3D> communications with other OBU= s and RSUs and may be connected to in-vehicle devices or networks a vehicular cloud should be defined (I guess it shall just denot cloud infr= astructure for vehicular networks and not computing resources distributed a= cross a multitide of vehicles? Ch.3: Vehicle-to-Device (V2D) is never used again - isn't it always in the end a = device? Perhaps better to add other Vulnerable Road Users (RSUs) as cyclist= s/bicycles ... [CA-Cuise-Control] =3D> [CA-Cruise-Control] share environmental information from various sensors, such as radars, LiDAR= s and cameras, mounted on them with other vehicles =3D> share environmental= information from various vehicle-mounted sensors, such as radars, LiDARs a= nd cameras, with other vehicles=20 driver vehicles =3D> driver operated vehicles / (hu)man-driven vehicles [??= ] for the global road traffic optimization =3D> for the large-scale/long-rang= e road traffic optimization [IMHO true _global_ optimization is wishful thi= nking ;-)] DSRC-based vehicular networks can be used for V2I in near future [DSRC]. I = doubt this, especially since the reference is from 2010! ;-) What about: Some players expect that DSRC-[DSRC] based vehicular networks w= ill be availabel for V2I in the future.[?] collision of a pedestrian and a vehicle, which have a smartphone, in a road= network. =3D> collision of a vehicle and a pedestrian carrying a smartphon= e equipped with corresponding access technology. RSU that delivers scheduling information for wireless communication to save= the smartphones' battery: Not clear which role RSU plays: that of a cellul= ar base station or WiFi-AP to connect to smartphone? Can you please elabora= te? Ch.4: We analyze the current protocols from the following aspects: =3D> We descri= be some currently existing/proposed protocols with respect to following asp= ects relevant/essential for vehicular networking: conducted a comprehensive study of the cross-layer identities management in= vehicular networks using multiple access network technologies, which const= itutes a fundamental element of the ITS architecture=20 =3D> conducted for heterogeneous vehicular network (i.e. employing multiple= access technologies) a comprehensive study of the cross-layer identities m= anagement, which constitutes a fundamental element of the ITS architecture speeds of vehicles are varied =3D> speeds of vehicles are highly variable/s= trongly varying For service discovery, as a popular existing service discovery protocol, DN= S-based Service Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] provides s= ervice discovery. =3D> To discover instances of a demanded service in vehicular networks DNS-based= Service Discovery (DNS-SD) [RFC6763] with Multicast DNS [RFC6762] provides= such feature, using standard DNS queries.=20 via RSU1 and RSU2 via V2I communication =3D> via RSU1 and RSU2 employing V2= I (i.e. V2I2V) communication of a mobile device (e.g., vehicle) =3D> of a mobile (e.g., vehicle-mounted)= device=20 accommodation of proactive protocols because it is usually equipped with a = GPS receiver. =3D> accommodation of (mobility aware) proactive communicatio= n protocols. [i.e. independent of where the mobility information is origina= ting from - may also be the cellular network!] Vehicles can use the TCC as its Home =3D> Vehicles can use the TCC as their= Home / A vehicle can use the TCC as its Home It recommebs =3D> It recommends=20 Figure 2: I miss the 2nd/3rd interface of RSU towards Internet (cloud) and = other RSU as shown in Figure 1. LTE D2D (Device to Device), =3D> LTE Uu and D2D (Device to Device), aka. si= delink PC5 [TS-23.285-3GPP],=20 Figure 3: I suggest to use not same node names for vehicle2 as used in Figu= re 2 for RSU1, so Router3 =3D> Router5, RDNSS2 =3D> RDNSS3 etc.! Security protects vehicles roaming =3D> strong security measures shall prot= ect vehicles roaming interface is used, which the interface's identifier is changed =3D> interfa= ce should be used, with the help of which the interface's identifier can be= changed=20 test yet =3D> tested yet Ch. 5 a GPS navigator as a dedicated navigation system or a smartphone App. With = this GPS navigator, =3D> a GPS receiver as part of a dedicated navigation system or a corresponding = smartphone App. In case the provided location information is precise enoug= h (well-known temporary degradations in precision may occur due to system c= onfiguration or the adverse local environment) or the precision is improved= thanks to assistance by the RSUs or a cellular system with this navigation= system,=20 horizontal/vertical handover: I haven't found the definition here - is V2V/= V2I HO meant? Such an update of the MAC and IPv6 addresses should not interrupt the end-to-end communications between two vehicular nodes (e.g., vehicle and RSU) in terms of transport layer. We should add here that this is a long living challenge in higher layers! Appendix: an intersection area, which is a coordinator for the access to wireless cha= nnels =3D> an intersection area, where the cluster head can work as a coord= inator for the access to wireless channels Neighbor Discovery (called ND) =3D> Neighbor Discovery (ND) The emerging services, functions and applications in automotive industry sp= urs ehhanced V2X (eV2X)-based services in the future 5G era. The 3GPP Tech= nical Report [TR-22.886-3GPP] is studying new use cases for V2X using 5G in= the future. =3D> The emerging services, functions, and applications developped in autom= otive industry demand for reliable and efficient communication infrastructu= re for road networks. Correspondingly the support of enhanced V2X (eV2X)-ba= sed services by future converged and interoperable 5G systems is required. = The 3GPP Technical Report [TR-22.886-3GPP] is studying new use cases and c= orresponding service requirements for V2X (including V2V and V2I) using 5G = in both infrastructure mode and the sidelink variations in the future. Thanks a lot! Best Regards Dirk=20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Montag, 16. Juli 2018 11:35 To: i-d-announce@ietf.org Cc: its@ietf.org Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Wireless Access in Vehicular Environmen= ts WG of the IETF. Title : IP Wireless Access in Vehicular Environments (IPW= AVE): Problem Statement and Use Cases Author : Jaehoon Paul Jeong Filename : draft-ietf-ipwave-vehicular-networking-04.txt Pages : 30 Date : 2018-07-16 Abstract: This document discusses the problem statement and use cases on IP- based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and vehicle-to-everything (V2X) networking. First, this document surveys use cases using V2V, V2I, and V2X networking. Second, it analyzes proposed protocols for IP-based vehicular networking and highlights the limitations and difficulties found on those protocols. Third, it presents a problem exploration for key aspects in IP-based vehicular networking, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect, this document discusses a problem statement to analyze the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networkin= g-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-vehicular-networking-= 04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Sun Jul 29 04:58:19 2018 Return-Path: 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 88A18130DF4 for ; Sun, 29 Jul 2018 04:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2z-Jb6UpYQFm for ; Sun, 29 Jul 2018 04:58:13 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C9C130DC1 for ; Sun, 29 Jul 2018 04:58:12 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id f18-v6so9453104qtp.10 for ; Sun, 29 Jul 2018 04:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=5Xe+qKMk9mQNAtSXnrQ5T8lpe+60iNP1dgh3YxF1UQk=; b=Ol+07KWrWPOG/sc9MFlPXT0c/eqbq6IDE6b2QloWIcimtZT8oElx3+cDMVAp0ToGy+ fx549SkzE4IaYSxncoorpYa5mqfXXzCcWIkyVKPRIG17pomCa4IklzwltIp8FvxgMqvV OGAlE3hQpLM3IhTlQnUTZCGmfwvCnMoaKLKTeZzHZA7p7+bgkb9HkxoLPcOEafcw/Tob JwxrluDAvzXuYTBFfMsvpE2FRl+Z5oLyxUhVZsb5Gmt2Fp9XNeU3lLU4OyMZhZkHJo4W Loj3BV7PIQLXWC0l4Be9hN3+zX01hV/jHDQXCTevKODP51QWzJSgJdVrO9qcoZI/E4ff 3kFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=5Xe+qKMk9mQNAtSXnrQ5T8lpe+60iNP1dgh3YxF1UQk=; b=bB8s7KSECzZ3NSGkQBbawXtfXejnUsuBdG8zHPmOcOV6vTLTVk1EZuw46W6E2Q5Xwn NO10nl9/XuKviNOc42mDPnQQVkDn0oB9xRHY8qm5vFXXF/LjGEkGT8aEDtoC0nC6PD2w gEWCBOinPWUM0gR9ewba+LRidd8J+vtJO/TQUkapNZjIL027DUHrpInKNylHayJeG88M Re2uVCCXLUevSE3GjhgdSlgZY+BX3Nv3gR0pajrJTUMnArkeIauyGDL6h3jLRdKaR1bl ue4jbwPzlnVbYzYm0Xn6UVaz+Zuy6ESIr/ymL3EvjdpM2FjY8y2+SVLrPB7AAPuw3kjn p9yA== X-Gm-Message-State: AOUpUlELn86lzIoAw2MKQHld7+xqga+8t7lOZCxXGdqZWEk7r/geGuSE PirZiYlomPtQRnn/0aHLy/IuzJlE X-Google-Smtp-Source: AAOMgpcaccbJcZf1YSmOn9lSXqxQ4VHUPQ861c6dMl66l0Kvg//7zbh8LkNdcpu/QRjtZPkeYGNWOQ== X-Received: by 2002:aed:23f8:: with SMTP id k53-v6mr12554610qtc.230.1532865491806; Sun, 29 Jul 2018 04:58:11 -0700 (PDT) Received: from FrancoisPC (pool-108-48-53-211.washdc.fios.verizon.net. [108.48.53.211]) by smtp.gmail.com with ESMTPSA id b22-v6sm5235383qtq.93.2018.07.29.04.58.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jul 2018 04:58:11 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: Cc: References: <153173368076.22957.11710630143747180156@ietfa.amsl.com> In-Reply-To: Date: Sun, 29 Jul 2018 07:58:09 -0400 Message-ID: <000c01d42733$6c6a53f0$453efbd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D42711.E55FDFE0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEX+mZVQBTlS5U8ah6W1QE6OBbFMwHRYaBgpg/g3tA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 11:58:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01D42711.E55FDFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit " For direct inter-vehicular wireless connectivity IEEE has amended WiFi standard 802.11 to enable driving safety services based on the DSRC in terms of standards for the Wireless Access in Vehicular Environments (WAVE) system. L2 and L3 issues are addressed in IEEE 802.11p [IEEE-802.11p], security aspects are covered in IEEE 1609.2 [WAVE-1609.2], while IEEE 1609.3 [WAVE-1609.3] defines related services at network and transport layers and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel operation." - In the US, DSRC denotes only the MAC and PHY specified in IEEE Std 802.11-2016; OCB mode. WAVE applies to 1609.2, 1609.3, 1609.4, and 1609.12. " DSRC-based vehicular networks can be used for V2I in near future [DSRC]. I doubt this, especially since the reference is from 2010! ;-) What about: Some players expect that DSRC-[DSRC] based vehicular networks will be availabel for V2I in the future.[?]" -In the US, there is no distinctions in DSRC (MAC and PHY) for V2I and V2V. Fygs -----Original Message----- From: its On Behalf Of Dirk.von-Hugo@telekom.de Sent: Friday, July 27, 2018 9:27 AM To: its@ietf.org; i-d-announce@ietf.org Cc: jaehoon.paul@gmail.com; pauljeong@skku.edu Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt Dear Jaehoon, all, I also volunteered in Montreal to review this draft which is a good starting point to identify work items for the future. I mainly agree with comments already made - especially on the privacy challenges and IP addresses - and would like to add some partly more editorial comments: I suggest to add already in the abstract the clarification (given later in ch. 3) that X in V2X is understood here as everything else than I and V ... if used together with V2V and V2I. I suggest to replace in Ch.1: For driving safety services based on the DSRC, IEEE has standardized Access in Vehicular Environments (WAVE) standards, such as IEEE 802.11p [IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], and IEEE 1609.4 [WAVE-1609.4]. By For direct inter-vehicular wireless connectivity IEEE has amended WiFi standard 802.11 to enable driving safety services based on the DSRC in terms of standards for the Wireless Access in Vehicular Environments (WAVE) system. L2 and L3 issues are addressed in IEEE 802.11p [IEEE-802.11p], security aspects are covered in IEEE 1609.2 [WAVE-1609.2], while IEEE 1609.3 [WAVE-1609.3] defines related services at network and transport layers and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel operation. Furthermore I suggest to put references near the related terms e.g.: IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to vehicular networks [RFC8200][RFC5944][RFC6275] => IPv6 [RFC8200] and Mobile IP protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can be applied or easily modified to vehicular networks. standardized a standard specifying => approved a standard specifying which is IP ...=> denoted as IP ... Also, it also discusses relevant work items to IPWAVE => Also, it discusses relevant and potential new work items to IPWAVE WG In Ch. 2 I suggest to change: An RSU is deployed either at an intersection or in a road segment => An RSU is typically deployed at an intersection or in a road segment, but may also be located in car parking areas communications with other OBUs and RSUs. => communications with other OBUs and RSUs and may be connected to in-vehicle devices or networks a vehicular cloud should be defined (I guess it shall just denot cloud infrastructure for vehicular networks and not computing resources distributed across a multitide of vehicles? Ch.3: Vehicle-to-Device (V2D) is never used again - isn't it always in the end a device? Perhaps better to add other Vulnerable Road Users (RSUs) as cyclists/bicycles ... [CA-Cuise-Control] => [CA-Cruise-Control] share environmental information from various sensors, such as radars, LiDARs and cameras, mounted on them with other vehicles => share environmental information from various vehicle-mounted sensors, such as radars, LiDARs and cameras, with other vehicles driver vehicles => driver operated vehicles / (hu)man-driven vehicles [??] for the global road traffic optimization => for the large-scale/long-range road traffic optimization [IMHO true _global_ optimization is wishful thinking ;-)] DSRC-based vehicular networks can be used for V2I in near future [DSRC]. I doubt this, especially since the reference is from 2010! ;-) What about: Some players expect that DSRC-[DSRC] based vehicular networks will be availabel for V2I in the future.[?] collision of a pedestrian and a vehicle, which have a smartphone, in a road network. => collision of a vehicle and a pedestrian carrying a smartphone equipped with corresponding access technology. RSU that delivers scheduling information for wireless communication to save the smartphones' battery: Not clear which role RSU plays: that of a cellular base station or WiFi-AP to connect to smartphone? Can you please elaborate? Ch.4: We analyze the current protocols from the following aspects: => We describe some currently existing/proposed protocols with respect to following aspects relevant/essential for vehicular networking: conducted a comprehensive study of the cross-layer identities management in vehicular networks using multiple access network technologies, which constitutes a fundamental element of the ITS architecture => conducted for heterogeneous vehicular network (i.e. employing multiple access technologies) a comprehensive study of the cross-layer identities management, which constitutes a fundamental element of the ITS architecture speeds of vehicles are varied => speeds of vehicles are highly variable/strongly varying For service discovery, as a popular existing service discovery protocol, DNS-based Service Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] provides service discovery. => To discover instances of a demanded service in vehicular networks DNS-based Service Discovery (DNS-SD) [RFC6763] with Multicast DNS [RFC6762] provides such feature, using standard DNS queries. via RSU1 and RSU2 via V2I communication => via RSU1 and RSU2 employing V2I (i.e. V2I2V) communication of a mobile device (e.g., vehicle) => of a mobile (e.g., vehicle-mounted) device accommodation of proactive protocols because it is usually equipped with a GPS receiver. => accommodation of (mobility aware) proactive communication protocols. [i.e. independent of where the mobility information is originating from - may also be the cellular network!] Vehicles can use the TCC as its Home => Vehicles can use the TCC as their Home / A vehicle can use the TCC as its Home It recommebs => It recommends Figure 2: I miss the 2nd/3rd interface of RSU towards Internet (cloud) and other RSU as shown in Figure 1. LTE D2D (Device to Device), => LTE Uu and D2D (Device to Device), aka. sidelink PC5 [TS-23.285-3GPP], Figure 3: I suggest to use not same node names for vehicle2 as used in Figure 2 for RSU1, so Router3 => Router5, RDNSS2 => RDNSS3 etc.! Security protects vehicles roaming => strong security measures shall protect vehicles roaming interface is used, which the interface's identifier is changed => interface should be used, with the help of which the interface's identifier can be changed test yet => tested yet Ch. 5 a GPS navigator as a dedicated navigation system or a smartphone App. With this GPS navigator, => a GPS receiver as part of a dedicated navigation system or a corresponding smartphone App. In case the provided location information is precise enough (well-known temporary degradations in precision may occur due to system configuration or the adverse local environment) or the precision is improved thanks to assistance by the RSUs or a cellular system with this navigation system, horizontal/vertical handover: I haven't found the definition here - is V2V/V2I HO meant? Such an update of the MAC and IPv6 addresses should not interrupt the end-to-end communications between two vehicular nodes (e.g., vehicle and RSU) in terms of transport layer. We should add here that this is a long living challenge in higher layers! Appendix: an intersection area, which is a coordinator for the access to wireless channels => an intersection area, where the cluster head can work as a coordinator for the access to wireless channels Neighbor Discovery (called ND) => Neighbor Discovery (ND) The emerging services, functions and applications in automotive industry spurs ehhanced V2X (eV2X)-based services in the future 5G era. The 3GPP Technical Report [TR-22.886-3GPP] is studying new use cases for V2X using 5G in the future. => The emerging services, functions, and applications developped in automotive industry demand for reliable and efficient communication infrastructure for road networks. Correspondingly the support of enhanced V2X (eV2X)-based services by future converged and interoperable 5G systems is required. The 3GPP Technical Report [TR-22.886-3GPP] is studying new use cases and corresponding service requirements for V2X (including V2V and V2I) using 5G in both infrastructure mode and the sidelink variations in the future. Thanks a lot! Best Regards Dirk -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Montag, 16. Juli 2018 11:35 To: i-d-announce@ietf.org Cc: its@ietf.org Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases Author : Jaehoon Paul Jeong Filename : draft-ietf-ipwave-vehicular-networking-04.txt Pages : 30 Date : 2018-07-16 Abstract: This document discusses the problem statement and use cases on IP- based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and vehicle-to-everything (V2X) networking. First, this document surveys use cases using V2V, V2I, and V2X networking. Second, it analyzes proposed protocols for IP-based vehicular networking and highlights the limitations and difficulties found on those protocols. Third, it presents a problem exploration for key aspects in IP-based vehicular networking, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect, this document discusses a problem statement to analyze the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking -04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_000D_01D42711.E55FDFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipwave] I-D Action: = draft-ietf-ipwave-vehicular-networking-04.txt

" For direct inter-vehicular wireless connectivity IEEE = has amended WiFi standard 802.11 to enable driving safety services based = on the DSRC in terms of standards for the Wireless Access in Vehicular = Environments (WAVE) system.  L2 and L3 issues are addressed in IEEE = 802.11p [IEEE-802.11p], security aspects are covered in IEEE 1609.2 = [WAVE-1609.2], while IEEE 1609.3 [WAVE-1609.3] defines related services = at network and transport layers and IEEE 1609.4 [WAVE-1609.4] specifies = the multi-channel operation."

- In the US, DSRC denotes only the MAC and PHY specified = in IEEE Std 802.11-2016; OCB mode.  WAVE applies to = 1609.2, = 1609.3, 1609.4, and 1609.12.

" DSRC-based vehicular networks can be used for V2I in = near future [DSRC]. I doubt this, especially since the reference is from = 2010! ;-) What about: Some players expect that DSRC-[DSRC] based = vehicular networks will be availabel for V2I in the = future.[?]"

-In the US, = there = is no distinctions  in DSRC (MAC and PHY) for V2I and = V2V.


Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of = Dirk.von-Hugo@telekom.de
Sent: Friday, July 27, 2018 9:27 AM
To: its@ietf.org; i-d-announce@ietf.org
Cc: jaehoon.paul@gmail.com; pauljeong@skku.edu
Subject: Re: [ipwave] I-D Action: = draft-ietf-ipwave-vehicular-networking-04.txt

Dear Jaehoon, = all,

I also = volunteered in Montreal to review this draft which is a good starting = point to identify work items for the future.

I mainly agree = with comments already made - especially on the privacy challenges and IP = addresses - and would like to add some partly more editorial = comments:

I suggest to = add already in the abstract the clarification (given later in ch. 3) = that X in V2X is understood here as everything else than I and V ... if = used together with V2V and V2I.

I suggest to = replace in Ch.1:

For driving = safety services based on the DSRC, IEEE has standardized Access in = Vehicular Environments (WAVE) standards, such as IEEE 802.11p = [IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], = and IEEE 1609.4 [WAVE-1609.4]. 

By

For direct = inter-vehicular wireless connectivity IEEE has amended WiFi standard = 802.11 to enable driving safety services based on the DSRC in terms of = standards for the Wireless Access in Vehicular Environments (WAVE) = system.  L2 and L3 issues are addressed in IEEE 802.11p = [IEEE-802.11p], security aspects are covered in IEEE 1609.2 = [WAVE-1609.2], while IEEE 1609.3 [WAVE-1609.3] defines related services = at network and transport layers and IEEE 1609.4 [WAVE-1609.4] specifies = the multi-channel operation.

Furthermore I = suggest to put references near the related terms e.g.: =

IPv6 and Mobile = IP protocols (e.g., MIPv4 and MIPv6) can be extended to vehicular = networks [RFC8200][RFC5944][RFC6275] =3D>

IPv6 [RFC8200] = and Mobile IP protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can = be applied or easily modified to vehicular networks.

standardized a = standard specifying =3D> approved a standard = specifying

which is IP = ...=3D> denoted as IP ...

Also, it also = discusses relevant work items to IPWAVE =3D> Also, it discusses = relevant and potential new work items to IPWAVE WG

In Ch. 2 I = suggest to change:

An RSU is = deployed either at an intersection or in a road segment =3D> An RSU = is typically deployed at an intersection or in a road segment, but may = also be located in car parking areas

communications = with other OBUs and RSUs. =3D> communications with other OBUs and = RSUs and may be connected to in-vehicle devices or = networks

a vehicular = cloud should be defined (I guess it shall just denot cloud = infrastructure for vehicular networks and not computing resources = distributed across a multitide of vehicles?

Ch.3:

Vehicle-to-Device (V2D) is never used again - isn't it = always in the end a device? Perhaps better to add other Vulnerable Road = Users (RSUs) as cyclists/bicycles ...

[CA-Cuise-Control] =3D> = [CA-Cruise-Control]

share = environmental information from various sensors, such as radars, LiDARs = and cameras, mounted on them with other vehicles =3D> share = environmental information from various vehicle-mounted sensors, such as = radars, LiDARs and cameras, with other vehicles

driver vehicles = =3D> driver operated vehicles / (hu)man-driven vehicles = [??]

for the global = road traffic optimization =3D> for the large-scale/long-range road = traffic optimization [IMHO true _global_ optimization is wishful = thinking ;-)]

DSRC-based = vehicular networks can be used for V2I in near future [DSRC]. I doubt = this, especially since the reference is from 2010! ;-) What about: Some = players expect that DSRC-[DSRC] based vehicular networks will be = availabel for V2I in the future.[?]

collision of a = pedestrian and a vehicle, which have a smartphone, in a road network. = =3D> collision of a vehicle and a pedestrian carrying a smartphone = equipped with corresponding access technology.

RSU that = delivers scheduling information for wireless communication to save the = smartphones' battery: Not clear which role RSU plays: that of a cellular = base station or WiFi-AP to connect to smartphone? Can you please = elaborate?

Ch.4:

We analyze the = current protocols from the following aspects: =3D> We describe some = currently existing/proposed protocols with respect to following aspects = relevant/essential for vehicular networking:

conducted a = comprehensive study of the cross-layer identities management in = vehicular networks using multiple access network technologies, which = constitutes a fundamental element of the ITS architecture =3D> = conducted for heterogeneous vehicular network (i.e. employing multiple = access technologies) a comprehensive study of the cross-layer identities = management, which constitutes a fundamental element of the ITS = architecture

speeds of = vehicles are varied =3D> speeds of vehicles are highly = variable/strongly varying

For service = discovery, as a popular existing service discovery protocol, DNS-based = Service Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] provides = service discovery. =3D> To discover instances of a demanded service = in vehicular networks DNS-based Service Discovery (DNS-SD) [RFC6763] = with Multicast DNS [RFC6762] provides such feature, using standard DNS = queries.

via RSU1 and = RSU2 via V2I communication =3D> via RSU1 and RSU2 employing V2I (i.e. = V2I2V) communication

of a mobile = device (e.g., vehicle) =3D> of a mobile (e.g., vehicle-mounted) = device

accommodation = of proactive protocols because it is usually equipped with a GPS = receiver. =3D> accommodation of (mobility aware) proactive = communication protocols. [i.e. independent of where the mobility = information is originating from - may also be the cellular = network!]

Vehicles can = use the TCC as its Home =3D> Vehicles can use the TCC as their Home / = A vehicle can use the TCC as its Home

It recommebs = =3D> It recommends

Figure 2: I = miss the 2nd/3rd interface of RSU towards Internet (cloud) and other RSU = as shown in Figure 1.

LTE D2D (Device = to Device), =3D> LTE Uu and D2D (Device to Device), aka. sidelink PC5 = [TS-23.285-3GPP],

Figure 3: I = suggest to use not same node names for vehicle2 as used in Figure 2 for = RSU1, so Router3 =3D> Router5, RDNSS2 =3D> RDNSS3 = etc.!

Security = protects vehicles roaming =3D> strong security measures shall protect = vehicles roaming

interface is = used, which the interface's identifier is changed =3D> interface = should be used, with the help of which the interface's identifier can be = changed

test yet = =3D> tested yet

Ch. = 5

a GPS navigator = as a dedicated navigation system or a smartphone App. With this GPS = navigator, =3D> a GPS receiver as part of a dedicated navigation = system or a corresponding smartphone App.  In case the provided = location information is precise enough (well-known temporary = degradations in precision may occur due to system configuration or the = adverse local environment) or the precision is improved thanks to = assistance by the RSUs or a cellular system with this navigation system, =

horizontal/vertical handover: I haven't found the = definition here - is V2V/V2I HO meant?

Such an update = of the MAC and IPv6 addresses

   = should not interrupt the end-to-end communications between = two

   = vehicular nodes (e.g., vehicle and RSU) in terms of transport = layer.

We should add = here that this is a long living challenge in higher = layers!

Appendix:

an intersection = area, which is a coordinator for the access to wireless channels =3D> = an intersection area, where the cluster head can work as a coordinator = for the access to wireless channels

Neighbor = Discovery (called ND) =3D> Neighbor Discovery (ND)

The emerging = services, functions and applications in automotive industry spurs = ehhanced V2X (eV2X)-based services in the future 5G era.  The 3GPP = Technical Report [TR-22.886-3GPP] is studying new use cases for V2X = using 5G in the future.

=3D> The = emerging services, functions, and applications developped in automotive = industry demand for reliable and efficient communication infrastructure = for road networks. Correspondingly the support of enhanced V2X = (eV2X)-based services by future converged and interoperable 5G systems = is required.  The 3GPP Technical Report [TR-22.886-3GPP] is = studying new use cases and corresponding service requirements for V2X = (including V2V and V2I) using 5G in both infrastructure mode and the = sidelink variations in the future.

Thanks a = lot!

Best = Regards

Dirk =

-----Original = Message-----

From: its = [mailto:its-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org

Sent: Montag, = 16. Juli 2018 11:35

To: i-d-announce@ietf.org

Cc: its@ietf.org

Subject: = [ipwave] I-D Action: = draft-ietf-ipwave-vehicular-networking-04.txt


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

This draft is a = work item of the IP Wireless Access in Vehicular Environments WG of the = IETF.

        = Title           : IP = Wireless Access in Vehicular Environments (IPWAVE): Problem Statement = and Use Cases

        = Author          : Jaehoon = Paul Jeong

        Filename        : = draft-ietf-ipwave-vehicular-networking-04.txt

        Pages        &nb= sp;  : 30

        Date        &nbs= p;   : 2018-07-16

Abstract:

   = This document discusses the problem statement and use cases on = IP-

   = based vehicular networks, which are considered a key component = of

   = Intelligent Transportation Systems (ITS).  The main topics = of

   = vehicular networking are vehicle-to-vehicle (V2V), = vehicle-to-

   = infrastructure (V2I), and vehicle-to-everything (V2X) = networking.

   = First, this document surveys use cases using V2V, V2I, and = V2X

   = networking.  Second, it analyzes proposed protocols for = IP-based

   = vehicular networking and highlights the limitations and = difficulties

   = found on those protocols.  Third, it presents a problem = exploration

   = for key aspects in IP-based vehicular networking, such as = IPv6

   = Neighbor Discovery, Mobility Management, and Security & = Privacy.  For

   = each key aspect, this document discusses a problem statement = to

   = analyze the gap between the state-of-the-art techniques = and

   = requirements in IP-based vehicular networking.


The IETF = datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehic= ular-networking/

There are also = htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-= networking-04

https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-= vehicular-networking-04

A diff from the = previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ve= hicular-networking-04


Please note = that it may take a couple of minutes from the time of submission until = the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts = are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

------=_NextPart_000_000D_01D42711.E55FDFE0--