From nobody Wed Jul 8 05:29:21 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCB31A1DE1 for ; Wed, 8 Jul 2015 05:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0rkEtP8Jfqcq for ; Wed, 8 Jul 2015 05:29:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258C41A9031 for ; Wed, 8 Jul 2015 05:29:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUX32079; Wed, 08 Jul 2015 12:29:13 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jul 2015 13:29:12 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.194]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 8 Jul 2015 20:29:00 +0800 From: "Huangjing (A)" To: "its@ietf.org" Thread-Topic: Fwd: New Version Notification for draft-petrescu-its-cacc-sdo-01.txt Thread-Index: AdC5eaidCc5cEk8lRAm59NKdPER3FA== Date: Wed, 8 Jul 2015 12:29:00 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC6741F617@SZXEMA501-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: multipart/alternative; boundary="_000_774B240D54DAB844B37EE80C2DD8E8BC6741F617SZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "buddenbergr@gmail.com" , "Huangjing \(A\)" , "alexandre.petrescu@cea.fr" , "thierry.ernst@mines-paristech.fr" Subject: [geonet/its] Fwd: New Version Notification for draft-petrescu-its-cacc-sdo-01.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 12:29:18 -0000 --_000_774B240D54DAB844B37EE80C2DD8E8BC6741F617SZXEMA501MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Folks, A new version of our draft is available online, you can find it by the foll= owing link: https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-01 A new sub-section about the way 3GPP sees C-ACC is added in this version. If you have any opinions or comments, please let us know. Thanks a lot! Best Regards James A new version of I-D, draft-petrescu-its-cacc-sdo-01.txt has been successfully submitted by Alexandre Petrescu and posted to the IET= F repository. Name: draft-petrescu-its-cacc-sdo Revision: 01 Title: Cooperative Adaptive Cruise Control and Platooning = at SDOs Document date: 2015-07-02 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-petrescu-its-cac= c-sdo-01.txt Status: https://datatracker.ietf.org/doc/draft-petrescu-its-cacc-sd= o/ Htmlized: https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-petrescu-its-cacc= -sdo-01 Abstract: This document describes the use-cases of Cooperative Adaptive Cruise Control, and Platooning, as defined by several Standards Development Organizations such as ETSI, IEEE 1609, SAE and 3GPP. C-ACC and Platooning involve concepts of direct vehicle-to-vehicle, and device-to-device communications, which are developped by 3GPP and precursory by the METIS EU project. They are illustrated very clearly in emergency settings such as FirstNet. IP messages - instead of link-layer messages - are pertinent for C-ACC and Platooning use-cases because applications for road safety such as WAZE, iRezQ and Coyote (currently involving infrastructure) are IP messages, and proved succesful in deployments. Applications such as Sentinel are direct between vehicles but are not IP, currently. 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. The IETF Secretariat --_000_774B240D54DAB844B37EE80C2DD8E8BC6741F617SZXEMA501MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Folks,

 

A new version of our draft is a= vailable online, you can find it by the following link:

https://tools.ietf.org/html/draft-p= etrescu-its-cacc-sdo-01

 

A new sub-section about the way= 3GPP sees C-ACC is added in this version.

 

If you have any opinions or com= ments, please let us know. Thanks a lot!

 

Best Regards<= /p>

James

 

 

 

A new version of I-D, draft-= petrescu-its-cacc-sdo-01.txt

has been successfully submit= ted by Alexandre Petrescu and posted to the IETF repository.

 

Name:    = ;           draft-petresc= u-its-cacc-sdo

Revision:  01

Title:   &nbs= p;            &= nbsp; Cooperative Adaptive Cruise Control and Platooning at SDOs=

Document date:  &n= bsp;    2015-07-02

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           10

URL:    =         https://www.ietf.org/internet-drafts/draft-petrescu-its-cacc-sdo-01.txt=

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-petrescu-its-cacc-sdo/

Htmlized:   &= nbsp;   https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-01

Diff:    = ;       https://www.ietf.org/rfcdiff?url2=3Ddraft-petrescu-its-cacc-sdo-01=

 

Abstract:<= /p>

   This document d= escribes the use-cases of Cooperative Adaptive Cruise

   Control, and Pl= atooning, as defined by several Standards Development

   Organizations s= uch as ETSI, IEEE 1609, SAE and 3GPP.

 

   C-ACC and Plato= oning involve concepts of direct vehicle-to-vehicle,

   and device-to-d= evice communications, which are developped by 3GPP and

   precursory by t= he METIS EU project.  They are illustrated very

   clearly in emer= gency settings such as FirstNet.

 

   IP messages - i= nstead of link-layer messages - are pertinent for

   C-ACC and Plato= oning use-cases because applications for road safety

   such as WAZE, i= RezQ and Coyote (currently involving infrastructure)

   are IP messages= , and proved succesful in deployments.  Applications=

   such as Sentine= l are direct between vehicles but are not IP,

   currently.=

 

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; 

 

 

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.

 

The IETF Secretariat

 

 

 

--_000_774B240D54DAB844B37EE80C2DD8E8BC6741F617SZXEMA501MBXchi_-- From nobody Wed Jul 15 01:46:44 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305BE1A914D for ; Mon, 6 Jul 2015 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IHw3dAnPocdZ for ; Mon, 6 Jul 2015 02:03:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290D11A9145 for ; Mon, 6 Jul 2015 02:03:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUT28232; Mon, 06 Jul 2015 09:03:13 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jul 2015 10:03:13 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.194]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Mon, 6 Jul 2015 17:00:18 +0800 From: "Huangjing (A)" To: "its@ietf.org" Thread-Topic: Fwd: New Version Notification for draft-petrescu-its-cacc-sdo-01.txt Thread-Index: AdC3yh2fczv8eyVmSpK92U0YlOBbtQ== Date: Mon, 6 Jul 2015 09:00:17 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC6741F024@SZXEMA501-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: multipart/alternative; boundary="_000_774B240D54DAB844B37EE80C2DD8E8BC6741F024SZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Wed, 15 Jul 2015 01:46:42 -0700 Cc: Rex Buddenberg , "Huangjing \(A\)" , Alexandre Petrescu , "thierry.ernst@mines-paristech.fr" Subject: [geonet/its] Fwd: New Version Notification for draft-petrescu-its-cacc-sdo-01.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 09:03:18 -0000 --_000_774B240D54DAB844B37EE80C2DD8E8BC6741F024SZXEMA501MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Folks, A new version of our draft is available online, you can find it by the foll= owing link: https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-01 A new sub-section about the way 3GPP sees C-ACC is added in this version. If you have any opinions or comments, please let us know. Thanks a lot! Best Regards James A new version of I-D, draft-petrescu-its-cacc-sdo-01.txt has been successfully submitted by Alexandre Petrescu and posted to the IET= F repository. Name: draft-petrescu-its-cacc-sdo Revision: 01 Title: Cooperative Adaptive Cruise Control and Platooning = at SDOs Document date: 2015-07-02 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-petrescu-its-cac= c-sdo-01.txt Status: https://datatracker.ietf.org/doc/draft-petrescu-its-cacc-sd= o/ Htmlized: https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-petrescu-its-cacc= -sdo-01 Abstract: This document describes the use-cases of Cooperative Adaptive Cruise Control, and Platooning, as defined by several Standards Development Organizations such as ETSI, IEEE 1609, SAE and 3GPP. C-ACC and Platooning involve concepts of direct vehicle-to-vehicle, and device-to-device communications, which are developped by 3GPP and precursory by the METIS EU project. They are illustrated very clearly in emergency settings such as FirstNet. IP messages - instead of link-layer messages - are pertinent for C-ACC and Platooning use-cases because applications for road safety such as WAZE, iRezQ and Coyote (currently involving infrastructure) are IP messages, and proved succesful in deployments. Applications such as Sentinel are direct between vehicles but are not IP, currently. 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. The IETF Secretariat --_000_774B240D54DAB844B37EE80C2DD8E8BC6741F024SZXEMA501MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Folks,

 

A new version of our draft is a= vailable online, you can find it by the following link:

https://tools.ietf.org/html/draft-p= etrescu-its-cacc-sdo-01

 

A new sub-section about the way= 3GPP sees C-ACC is added in this version.

 

If you have any opinions or com= ments, please let us know. Thanks a lot!

 

Best Regards<= /p>

James

 

 

 

A new version of I-D, draft-= petrescu-its-cacc-sdo-01.txt

has been successfully submit= ted by Alexandre Petrescu and posted to the IETF repository.

 

Name:    = ;           draft-petresc= u-its-cacc-sdo

Revision:  01

Title:   &nbs= p;            &= nbsp; Cooperative Adaptive Cruise Control and Platooning at SDOs=

Document date:  &n= bsp;    2015-07-02

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           10

URL:    =         https://www.ietf.org/internet-drafts/draft-petrescu-its-cacc-sdo-01.txt=

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-petrescu-its-cacc-sdo/

Htmlized:   &= nbsp;   https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-01

Diff:    = ;       https://www.ietf.org/rfcdiff?url2=3Ddraft-petrescu-its-cacc-sdo-01=

 

Abstract:<= /p>

   This document d= escribes the use-cases of Cooperative Adaptive Cruise

   Control, and Pl= atooning, as defined by several Standards Development

   Organizations s= uch as ETSI, IEEE 1609, SAE and 3GPP.

 

   C-ACC and Plato= oning involve concepts of direct vehicle-to-vehicle,

   and device-to-d= evice communications, which are developped by 3GPP and

   precursory by t= he METIS EU project.  They are illustrated very

   clearly in emer= gency settings such as FirstNet.

 

   IP messages - i= nstead of link-layer messages - are pertinent for

   C-ACC and Plato= oning use-cases because applications for road safety

   such as WAZE, i= RezQ and Coyote (currently involving infrastructure)

   are IP messages= , and proved succesful in deployments.  Applications=

   such as Sentine= l are direct between vehicles but are not IP,

   currently.=

 

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; 

 

 

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.

 

The IETF Secretariat

 

 

--_000_774B240D54DAB844B37EE80C2DD8E8BC6741F024SZXEMA501MBXchi_-- From nobody Thu Jul 16 01:53:02 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7288A1B37BC for ; Thu, 16 Jul 2015 01:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 CLPnoamM3QSR for ; Thu, 16 Jul 2015 01:53:00 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06A01B37BA for ; Thu, 16 Jul 2015 01:52:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6G8qqki020293; Thu, 16 Jul 2015 10:52:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C043F2018E4; Thu, 16 Jul 2015 10:56:19 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AA122200C68; Thu, 16 Jul 2015 10:56:19 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6G8qqUY026057; Thu, 16 Jul 2015 10:52:52 +0200 From: Alexandru Petrescu To: "its@ietf.org" Message-ID: <55A770E4.8050605@gmail.com> Date: Thu, 16 Jul 2015 10:52:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= Subject: [geonet/its] ITS bar bof - meet Wednesday 11h30 at Registration Desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 08:53:01 -0000 Hello, Meet us Wednesday 11h30 at the IETF Registration Desk. We will discuss the current charter proposal for ITS - mainly V2V aspects. I will soon post the integrated text with all the received feedback. Yours, Alex Petrescu and Dapeng Liu From nobody Thu Jul 16 05:20:44 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E951A896F for ; Thu, 16 Jul 2015 05:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 8o7-HHVvNKcL for ; Thu, 16 Jul 2015 05:20:36 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672151A896D for ; Thu, 16 Jul 2015 05:20:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6GCKU87030462; Thu, 16 Jul 2015 14:20:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DDE33203CC0; Thu, 16 Jul 2015 14:23:57 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D089C203BF4; Thu, 16 Jul 2015 14:23:57 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6GCKTgk025757; Thu, 16 Jul 2015 14:20:30 +0200 To: "its@ietf.org" From: Alexandru Petrescu Message-ID: <55A7A18D.4020407@gmail.com> Date: Thu, 16 Jul 2015 14:20:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= Subject: [geonet/its] charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 12:20:43 -0000 Hello, We will discuss this charter proposal in Prague. Alex --------------------------------------------------------------------- Goal ---- Establishing direct and secure IP connectivity between a few vehicles in close range is the goal of this group. Intro ----- Automobiles and vehicles of all types are increasingly connected to the Internet. Entertainment apps enhancing comfort on-board, reliable data exchanges for road safety, and automated driving, are highly appreciated marketing arguments for automobiles to hit the roads from now to year 2020. Emergency apps for new instrumented ambulances carry many benefits both to the users and to society in general. Why IP? ------- Whereas the Vehicle-to-Infrastructure technologies are considered completed and deployed in currently sold automobiles (e.g. car tethering through driver's cellular smartphone, or SIM in On-Board Unit, or cellular USB dongle, with NAT/DHCP and potentially Mobile IP), the Vehicle-to-Vehicle communications are still in an infancy stage: primitive link-specific data exchanges are limited to a non-harmonized and limited set of applications, such as ETSI's CAM/DENM presence signalling. On another hand, the industry needs to employ IP data exchanges between vehicles rather than link-specific exchanges, in order to benefit from the reuse of a huge number of a desktop Internet applications in a vehicular environment (extend the Internet to mobile platforms). Scenarios? ---------- Some of the scenarios needing IP V2V communications are: Cooperative Adaptive Cruise Control and Platooning of vehicles. In the emergency landscape other applications exhibiting a need for V2V comms are also important: virtual siren - emergency vehicle multicasting a radio warning to nearby vehicles to make place. How is V2V vs V2I? ------------------ Establishing direct and secure IP connectivity between a few vehicles in close range is the goal of this group. V2V is more than simply connecting a vehicle to the Internet (V2I). Because it needs a peer-to-peer manner of IP route establishment between equally-potent Routers in vehicles, in such a way to not disturb the V2I communications already in place. This manner is a step forward from known V2I Host-to-Router or Client-to-Server paradigms (protocols Neighbor Discovery, DHCP, ppp, Mobile IP, and similar). What kind of solutions? ----------------------- The current technical solutions considered to achieve IP V2V communications are of two kinds: IP routing protocols for n-hop path establishment between vehicles (e.g. Babel, OSPF, others) and 1-hop link-scoped IP protocol enhancements (such as route establishment with ICMP Router Advertisements). There is a concern in sending IPv6 packets over the current ETSI geonetworking protocols, with risks of the channel being swamped due to inefficiencies of the protocol, or simply due to communication abuse. What kind of requirements? -------------------------- The keyhole applications C-ACC, Platooning and virtual siren involve IP multicast mechanisms. The 1-hop IP V2V paths will gracefully support IP multicast. Due to the inherent characteristics of safety-related communications, all new V2V mechanisms must afford authenticity and confidentiality where necessary. Dynamically establishing ephemeral communication paths between automobiles in public areas must offer privacy safeguards for the end users (passengers). Establishing 1-hop IP V2V paths must not break the existing on-board protocols and applications which communicate with the infrastructure, possibly via multiple radios. Current version of Internet protocols ------------------------------------- The version of the IP protocol is IPv6, to acommodate the current generation of Internet protocols. For backwards compatibility, IPv4 may be considered as well, but not exclusively. Link-local addresses will be used. What SDOs may need this work? ----------------------------- The requirements and standards for an Internet of Vehicles are developed mainly at 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet communications, 3GPP LTE and other cellular technologies represent the long-range connectivity method; for Vehicle-to-Vehicle communications, LTE Direct is currently specified. Several use-cases exhibit a need for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V communications. Work Items ---------- - use-case and scenarios of C-ACC and Platooning at SDOs - Problem Statement for IP V2V application communications - Security and Privacy Requirements for IP V2V communications - Potentially new protocol, or protocol extensions for establishing IP paths for 1-hop V2V communications. With MIB and security. Timeline -------- - BoF in Yokohama - Couple of work items submitted to IESG in November 2016. - recharter to work on solution for IP V2V. From nobody Mon Jul 20 10:33:14 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C34A1B2D1A for ; Mon, 20 Jul 2015 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 JB-saCIW84EZ for ; Mon, 20 Jul 2015 10:33:10 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC751B2CFB for ; Mon, 20 Jul 2015 10:33:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6KHX8i4021116; Mon, 20 Jul 2015 19:33:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8BAC620526E; Mon, 20 Jul 2015 19:36:41 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 716CB2010AD; Mon, 20 Jul 2015 19:36:41 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6KHX7SR031053; Mon, 20 Jul 2015 19:33:07 +0200 To: "its@ietf.org" From: Alexandru Petrescu Message-ID: <55AD30D3.5070407@gmail.com> Date: Mon, 20 Jul 2015 19:33:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060003020802010405070907" Archived-At: Cc: "Wissingh, B.F. \(Bastiaan\)" Subject: [geonet/its] vehicular comm's talk at tomorrow's Technical Plenary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:33:12 -0000 This is a multi-part message in MIME format. --------------060003020802010405070907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit vehicular comm's talk at tomorrow's Technical Plenary: https://datatracker.ietf.org/meeting/93/agenda/iab/ https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-3.pdf https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-3.pdf Alex --------------060003020802010405070907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit vehicular comm's talk at tomorrow's Technical Plenary:

https://datatracker.ietf.org/meeting/93/agenda/iab/

https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-3.pdf
https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-3.pdf

Alex
 --------------060003020802010405070907-- From nobody Mon Jul 20 10:34:41 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21871B2D30 for ; Mon, 20 Jul 2015 10:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 yuCeGgeyg1_b for ; Mon, 20 Jul 2015 10:34:28 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BB81B2D37 for ; Mon, 20 Jul 2015 10:34:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6KHYQVa017259 for ; Mon, 20 Jul 2015 19:34:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ECDB520517E for ; Mon, 20 Jul 2015 19:37:58 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA6EA204829 for ; Mon, 20 Jul 2015 19:37:58 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6KHYP2L031450 for ; Mon, 20 Jul 2015 19:34:25 +0200 To: its@ietf.org References: <75485AE0FF66EA4EA0473A6E912810F52681BD3DDD@MBX061.renault.mail.noxiane.net> <558D392A.2060809@gmail.com> From: Alexandru Petrescu Message-ID: <55AD3121.9000908@gmail.com> Date: Mon, 20 Jul 2015 19:34:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <558D392A.2060809@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] Fwd: TR: New Version Notification for draft-lonc-tls-certieee1609-01.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:34:33 -0000 If time allows this will be presented in the TLS WG Wednesday. Alex Le 26/06/2015 13:36, Alexandru Petrescu a écrit : > Hello, > > For information, there is a new draft about TLS security. It has been > announced on the IETF announcements and ETSI ITS WG5 (Security) email > lists. > > Please comment: > > https://www.ietf.org/internet-drafts/draft-lonc-tls-certieee1609-01.txt > > Yours, > > Alex Petrescu > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Jul 20 10:43:50 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471AE1B3009 for ; Mon, 20 Jul 2015 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 iwsijIXQmSWK for ; Mon, 20 Jul 2015 10:43:47 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2816A1B2D4E for ; Mon, 20 Jul 2015 10:43:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6KHhVhQ018696 for ; Mon, 20 Jul 2015 19:43:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2A635205169 for ; Mon, 20 Jul 2015 19:47:04 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17E70204829 for ; Mon, 20 Jul 2015 19:47:04 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.3]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6KHhUjv001834 for ; Mon, 20 Jul 2015 19:43:30 +0200 To: its@ietf.org References: <55AD30D3.5070407@gmail.com> From: Alexandru Petrescu Message-ID: <55AD3342.6020804@gmail.com> Date: Mon, 20 Jul 2015 19:43:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AD30D3.5070407@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] vehicular comm's talk at tomorrow's Technical Plenary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:43:48 -0000 addition: https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-4.pdf Alex Le 20/07/2015 19:33, Alexandru Petrescu a écrit : > vehicular comm's talk at tomorrow's Technical Plenary: > > https://datatracker.ietf.org/meeting/93/agenda/iab/ > > https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-3.pdf > https://www.ietf.org/proceedings/93/slides/slides-93-iab-techplenary-3.pdf > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Tue Jul 21 00:43:41 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941D1AD218 for ; Tue, 21 Jul 2015 00:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 kTS7iAM_y3R1 for ; Tue, 21 Jul 2015 00:43:37 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6AC1A0211 for ; Tue, 21 Jul 2015 00:43:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6L7hZ6M019857 for ; Tue, 21 Jul 2015 09:43:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE229201F8F for ; Tue, 21 Jul 2015 09:47:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 06893201F50 for ; Tue, 21 Jul 2015 09:47:00 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.6]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6L7hOpQ031647 for ; Tue, 21 Jul 2015 09:43:26 +0200 References: <36637476-26D0-4230-B182-4D9BE464D57B@isoc.org> To: "its@ietf.org" From: Alexandru Petrescu X-Forwarded-Message-Id: <36637476-26D0-4230-B182-4D9BE464D57B@isoc.org> Message-ID: <55ADF81C.8050009@gmail.com> Date: Tue, 21 Jul 2015 09:43:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <36637476-26D0-4230-B182-4D9BE464D57B@isoc.org> Content-Type: multipart/mixed; boundary="------------050608010306040402000407" Archived-At: Subject: [geonet/its] Fwd: [93attendees] FYI - live video streams available for Tech Plenary, Admin Plenary, Thursday lunch speaker X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 07:43:39 -0000 This is a multi-part message in MIME format. --------------050608010306040402000407 Content-Type: multipart/alternative; boundary="------------070404020808010707090101" --------------070404020808010707090101 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit For remote attendance the live video of the Tech Plenary, including the Tech Topic on Vehicular communications is at: https://www.ietf.org/live/ The entire tech plenary is today 9h30-11h30 Prague time: 1. Welcome 2. Reporting - IAB Chair - Appeal discussion (Ted Hardie) - IRTF Chair - RSE and RSOC Chair 3. Technical Topic: Vehicular Communications 4. Message from the ITU Secretary General 5. Highlight: Coordinating Attack Response at Internet Scale (CARIS) Workshop 6. IAB Open Mic (30second delay). There is also a "queue experiment" displayed on a screen in the Congress Hall. Alex -------- Message transfĂ©rĂ© -------- Sujet : [93attendees] FYI - live video streams available for Tech Plenary, Admin Plenary, Thursday lunch speaker Date : Mon, 20 Jul 2015 22:02:17 +0000 De : Dan York Pour : 93attendees@ietf.org <93attendees@ietf.org> IETF 93 attendees, As we have done at recent IETF meetings, we will be streaming the plenaries out of the IETF's YouTube channel. All links can be found at: https://www.ietf.org/live/ We are currently planning streaming coverage of the following IETF 93 sessions: • Technical Plenary - Tuesday, 21 July 2015, 09:30-11:30 CEST, Congress Hall I/II • Administrative Plenary - Thursday, 23 July 2015, 09:00-11:30 CEST, Congress I/II • Thursday lunch presentation - Thursday, 23 July 2015, 12:00-12:45 CEST, Grand Hilton Ballroom If you want to invite anyone remote to watch the sessions, please send them that link. Please note that for viewers in Germany who are restricted from watching YouTube live streams, we have arranged to *also* stream the video through the Internet Society's Livestream.com account which we are told *is* viewable in Germany. Those links are also on the https://www.ietf.org/live/ page. Enjoy, Dan P.S. The Internet Society's briefing panel on Tuesday, 21 July from 11:45-12:45pm CEST will also be streamed live. More info about it can be found at: https://www.internetsociety.org/internet-society-briefing-panel-ietf-93 -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ --------------070404020808010707090101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit For remote attendance the live video of the Tech Plenary, including the Tech Topic on Vehicular communications
is at:

https://www.ietf.org/live/

The entire tech plenary is today 9h30-11h30 Prague time:
1. Welcome
2. Reporting
  - IAB Chair
      - Appeal discussion (Ted Hardie)
  - IRTF Chair
  - RSE and RSOC Chair
3. Technical Topic: Vehicular Communications
4. Message from the ITU Secretary General
5. Highlight: Coordinating Attack Response at Internet Scale (CARIS) Workshop
6. IAB Open Mic

(30second delay).
There is also a "queue experiment" displayed on a screen in the Congress Hall.

Alex


-------- Message transféré --------
Sujet : [93attendees] FYI - live video streams available for Tech Plenary, Admin Plenary, Thursday lunch speaker
Date : Mon, 20 Jul 2015 22:02:17 +0000
De : Dan York <york@isoc.org>
Pour : 93attendees@ietf.org <93attendees@ietf.org>


IETF 93 attendees,

As we have done at recent IETF meetings, we will be streaming the plenaries out of the IETF's YouTube channel.  All links can be found at:


We are currently planning streaming coverage of the following IETF 93 sessions:

• Technical Plenary - Tuesday, 21 July 2015, 09:30-11:30 CEST, Congress Hall I/II
• Administrative Plenary - Thursday, 23 July 2015, 09:00-11:30 CEST, Congress I/II
• Thursday lunch presentation - Thursday, 23 July 2015, 12:00-12:45 CEST, Grand Hilton Ballroom

If you want to invite anyone remote to watch the sessions, please send them that link.  

Please note that for viewers in Germany who are restricted from watching YouTube live streams, we have arranged to *also* stream the video through the Internet Society's Livestream.com account which we are told *is* viewable in Germany.  Those links are also on the https://www.ietf.org/live/ page.

Enjoy,
Dan

P.S. The Internet Society's briefing panel on Tuesday, 21 July from 11:45-12:45pm CEST will also be streamed live. More info about it can be found at: https://www.internetsociety.org/internet-society-briefing-panel-ietf-93 

--
Dan York
Senior Content Strategist, Internet Society
york@isoc.org   +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork






--------------070404020808010707090101-- --------------050608010306040402000407 Content-Type: text/plain; charset=UTF-8; name="Portion de message joint" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Portion de message joint" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjkzYXR0 ZW5kZWVzIG1haWxpbmcgbGlzdA0KOTNhdHRlbmRlZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vOTNhdHRlbmRlZXMNCg0K --------------050608010306040402000407-- From nobody Wed Jul 22 01:50:52 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08691ACED5 for ; Wed, 22 Jul 2015 01:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 RdDV-kYQ12Bk for ; Wed, 22 Jul 2015 01:50:39 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83AF1ACECE for ; Wed, 22 Jul 2015 01:50:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6M8obme028007 for ; Wed, 22 Jul 2015 10:50:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7BE4F2026AF for ; Wed, 22 Jul 2015 10:54:12 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 71F3F2025D6 for ; Wed, 22 Jul 2015 10:54:12 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6M8oYV2027527 for ; Wed, 22 Jul 2015 10:50:37 +0200 References: To: "its@ietf.org" From: Alexandru Petrescu X-Forwarded-Message-Id: Message-ID: <55AF595A.9090402@gmail.com> Date: Wed, 22 Jul 2015 10:50:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [geonet/its] Fwd: TR: I-D Action: draft-ietf-ecrit-car-crash-03.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:50:41 -0000 For your information Pour info -----Message d'origine----- De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org Envoyé : lundi 6 juillet 2015 21:20 Ŕ : i-d-announce@ietf.org Cc : ecrit@ietf.org Objet : I-D Action: draft-ietf-ecrit-car-crash-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-03.txt Pages : 22 Date : 2015-07-06 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. Profiling and simplifications of the general emergency call mechanism, as described in [RFC6443] and [RFC6881], are possible due to the nature of the functionality that is provided in vehicles such as the usage of Global Satellite Navigation System (GNSS). This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions), as described in [I-D.ietf-ecrit-ecall]. However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jul 22 03:05:38 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC841AD082 for ; Wed, 22 Jul 2015 03:05:38 -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, SPF_PASS=-0.001] autolearn=ham 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 TC0A-BnGNXsN for ; Wed, 22 Jul 2015 03:05:36 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::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 9A56B1ACD3C for ; Wed, 22 Jul 2015 03:05:36 -0700 (PDT) Received: by vnaa140 with SMTP id a140so46291797vna.2 for ; Wed, 22 Jul 2015 03:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gx4A61ngak4m6x6YSSAtWgbpoRssBZ2cM7Q0CiUbons=; b=TLO+vwLByN8Qeui6FSlX6eLonlqNpW70t4j0OEOoi4lmPG60ZCHfZcOcM2QIKlzw1C QzMfO91RZVQR0Okhj9ucL7ABVwpddtFtgrbIoI5ZcXI75TfWAerdReDeTnMOaa9uJbc6 V2/YlMzk01Vv0ffS6hpivpyXWSn48G5u5KGaOyo2xoKNYxNX5AZII5duyh5Q/pCuCIBy OIp8ueT4ivDpgBYT0kLekN0Au1AViSibXuytZ6ud6dm4Tn/1GlNE4SkvIzzi0KuPjtod GmmtXR91r0OqVAYIVrjzOfFXQ1+lX/HsU2yVDPT6kR8JtRZdVrqx+vk98JlgcJjlqpGb MUjQ== MIME-Version: 1.0 X-Received: by 10.52.2.170 with SMTP id 10mr1992326vdv.93.1437559535901; Wed, 22 Jul 2015 03:05:35 -0700 (PDT) Received: by 10.31.178.145 with HTTP; Wed, 22 Jul 2015 03:05:35 -0700 (PDT) Date: Wed, 22 Jul 2015 12:05:35 +0200 Message-ID: From: Dapeng Liu To: "its@ietf.org" Content-Type: multipart/alternative; boundary=bcaec502d9fa7b2344051b73e9bc Archived-At: Subject: [geonet/its] ITS barbof draft charter discussion today X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 10:05:38 -0000 --bcaec502d9fa7b2344051b73e9bc Content-Type: text/plain; charset=UTF-8 Hello all, Time: 11:30-13:00 The location is the meeting room near the terminal room called attendee room. If you have interest, please join us. ------ Best Regards, Dapeng Liu & Alex --bcaec502d9fa7b2344051b73e9bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

Time: 11:30-1= 3:00
The location is the meeting room n= ear the terminal room called attendee room.
If you have interest, please join us.

------
Best Regards,
Dapeng Liu & Alex
--bcaec502d9fa7b2344051b73e9bc-- From nobody Wed Jul 22 04:30:08 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C191B2BCF for ; Wed, 22 Jul 2015 04:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DRIUk-psYXSe for ; Wed, 22 Jul 2015 04:30:06 -0700 (PDT) Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::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 684291ACE6D for ; Wed, 22 Jul 2015 04:30:05 -0700 (PDT) Received: by vnds125 with SMTP id s125so46881169vnd.1 for ; Wed, 22 Jul 2015 04:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mVoUw/phlp96CDnZiuer4j8cYXDLIV3OeWzixyPgvzo=; b=x0bWJfNelXHLu8wH6Epmqokl8LLw1S7+Jj82t3Q396ZnnjVP7OOGhjoxuogdH2hoib MxFS9honvDvD8TQDqsgSBsOXOikvy6Xzk2IpVX1i53hFqrbhIGmyUVvDGsa8OspzPayh 87ewRdGx83mqC9ftVkJbSsSs667fHOsYmLEqxj0WdmfU6cVFQJ/eCBtuJ4qdb7p0jiiI eNCtgZIeCQsPuXByny2LCevNM0Capf7XLDIcKRFod5RR0CXQvINnqW31u00XesU0B+az /Dj+XK9w01lMqyppfxha/pQgnXSOXIOHvrWCp18zZS67DwL98QdWaP6emAie4SKyJTa1 u9YQ== MIME-Version: 1.0 X-Received: by 10.52.122.52 with SMTP id lp20mr2355694vdb.64.1437564604767; Wed, 22 Jul 2015 04:30:04 -0700 (PDT) Received: by 10.31.178.145 with HTTP; Wed, 22 Jul 2015 04:30:04 -0700 (PDT) Date: Wed, 22 Jul 2015 13:30:04 +0200 Message-ID: From: Dapeng Liu To: "its@ietf.org" Content-Type: multipart/alternative; boundary=089e013a13bc9be44c051b751766 Archived-At: Subject: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:30:07 -0000 --089e013a13bc9be44c051b751766 Content-Type: text/plain; charset=UTF-8 Hello all, During the noon discussion, we were discussing whether we can use IPv6 link local address for one hop V-V IP communication. One reason is that the vehicle that discover a neighbor with link local IPv6 address can not distinguish whether that is another vehicle or it is a smart phone in the car or it is a smart phone from road side passengers. If we want to use IPv6 link local address, a dedicate prefix for V2V may needed. Any thoughts? ------ Best Regards, Dapeng Liu --089e013a13bc9be44c051b751766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

During the noon discussion, = we were discussing whether we can use IPv6 link local address for one hop V= -V IP communication.

One reason is that the vehicl= e that discover a neighbor with link local IPv6 address can not distinguish= whether that is another vehicle or it is a smart phone in the car or it is= a smart phone from road side passengers. =C2=A0

=
If we want to use IPv6 link local address, a dedicate prefix for= V2V may needed.

Any thoughts?


------
Best Regards,
Dapeng Liu
--089e013a13bc9be44c051b751766-- From nobody Wed Jul 22 05:37:20 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D0E1B32C8 for ; Wed, 22 Jul 2015 05:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 BChViDJYiRxD for ; Wed, 22 Jul 2015 05:37:17 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3BF1B32BF for ; Wed, 22 Jul 2015 05:37:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MCbFDp015142 for ; Wed, 22 Jul 2015 14:37:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8B1ED201F1F for ; Wed, 22 Jul 2015 14:40:50 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 82534200BC5 for ; Wed, 22 Jul 2015 14:40:50 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MCbDVh009581 for ; Wed, 22 Jul 2015 14:37:14 +0200 To: its@ietf.org References: From: Alexandru Petrescu Message-ID: <55AF8E79.7040405@gmail.com> Date: Wed, 22 Jul 2015 14:37:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:37:19 -0000 Hi Dapeng, YEs, during the bar bof discussion a couple of people agreed LL addresses may be sufficient. A question was raised on whether or not the use of link-local addresses is enough to make vehicles in close range talk to each other in a 1-hop manner. To clarify, the topology would be the following: ---- ---- LL LL ---- ---- | H1 |-----| R1 |--o o--| R2 |-----| H2 | ---- ---- ---- ---- R1 and R2 may be able to communicate to each other by using their LL addresses, but could H1 talk to H2? H1, R1 are in car1, and H2, R2 are in car2. H1 is the GPS data source and H2 is the GPS data receiver. H1 needs to send the location data to H2, in order to inform the nearby vehicle about whether they can try to platoon themselves. The GPS data could be any other app-level data, for example the output of the odometer (speed measurement), or a camera streaming an IP video. To me, yes, LL addresses between R1 and R2 are sufficient, but they are not sufficient for communication between H1 and H2. Dedicate prefix for V2V management? Yes, why not, could be a good help in making addresses. What do the other think? Duplicate Address Detection taking too much time between R1 and R2? Maybe yes. Maybe avoid it? LL addresses using random MAC addresses? Good idea for privacy, but maybe depends on the privacy concerns? MAC address randomization impact on fast auto-configuration? Are MAC addresses required by the law to be visible just like the license plates are? Or are the MAC addresses more like the photo of the driver - private data accepted so by the government. Alex Le 22/07/2015 13:30, Dapeng Liu a écrit : > Hello all, > > During the noon discussion, we were discussing whether we can use IPv6 > link local address for one hop V-V IP communication. > > One reason is that the vehicle that discover a neighbor with link local > IPv6 address can not distinguish whether that is another vehicle or it > is a smart phone in the car or it is a smart phone from road side > passengers. > > If we want to use IPv6 link local address, a dedicate prefix for V2V may > needed. > > Any thoughts? > > > ------ > Best Regards, > Dapeng Liu > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Jul 22 06:12:00 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E511A1AA6 for ; Wed, 22 Jul 2015 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xiSU3FZg811g for ; Wed, 22 Jul 2015 06:11:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DD71B3357 for ; Wed, 22 Jul 2015 06:11:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVL64522; Wed, 22 Jul 2015 13:11:17 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 14:11:16 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.213]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 21:11:13 +0800 From: "Huangjing (A)" To: Alexandru Petrescu Thread-Topic: [geonet/its] Why not using IPv6 link local address for one hop V2V Thread-Index: AQHQxHs9XaZPyNJb50mGViQzzaxYeZ3ndaUg Date: Wed, 22 Jul 2015 13:11:13 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC6746D258@SZXEMA501-MBX.china.huawei.com> References: <55AF8E79.7040405@gmail.com> In-Reply-To: <55AF8E79.7040405@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.104.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:11:59 -0000 Hi, Alexandru, Not sure why H1 cannot communicate with H2, is it because they are out of r= ange and need another node to forward/relay the message for them? If this is the case, then I think this is multi-hop communication, rather 1= -hop. Random address generation may not be a good idea due to possible duplicated= address. James > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Wednesday, July 22, 2015 8:37 PM > To: its@ietf.org > Subject: Re: [geonet/its] Why not using IPv6 link local address for one h= op V2V >=20 > Hi Dapeng, >=20 > YEs, during the bar bof discussion a couple of people agreed LL addresses= may > be sufficient. A question was raised on whether or not the use of link-l= ocal > addresses is enough to make vehicles in close range talk to each other in= a > 1-hop manner. >=20 > To clarify, the topology would be the following: >=20 > ---- ---- LL LL ---- ---- > | H1 |-----| R1 |--o o--| R2 |-----| H2 | > ---- ---- ---- ---- >=20 > R1 and R2 may be able to communicate to each other by using their LL > addresses, but could H1 talk to H2? >=20 > H1, R1 are in car1, and H2, R2 are in car2. H1 is the GPS data source an= d H2 > is the GPS data receiver. H1 needs to send the location data to H2, in o= rder to > inform the nearby vehicle about whether they can try to platoon themselve= s. >=20 > The GPS data could be any other app-level data, for example the output of= the > odometer (speed measurement), or a camera streaming an IP video. >=20 > To me, yes, LL addresses between R1 and R2 are sufficient, but they are n= ot > sufficient for communication between H1 and H2. >=20 > Dedicate prefix for V2V management? Yes, why not, could be a good help i= n > making addresses. What do the other think? >=20 > Duplicate Address Detection taking too much time between R1 and R2? > Maybe yes. Maybe avoid it? >=20 > LL addresses using random MAC addresses? Good idea for privacy, but > maybe depends on the privacy concerns? MAC address randomization impact > on fast auto-configuration? Are MAC addresses required by the law to be > visible just like the license plates are? Or are the MAC addresses more = like > the photo of the driver - private data accepted so by the government. >=20 > Alex >=20 > Le 22/07/2015 13:30, Dapeng Liu a =E9crit : > > Hello all, > > > > During the noon discussion, we were discussing whether we can use IPv6 > > link local address for one hop V-V IP communication. > > > > One reason is that the vehicle that discover a neighbor with link > > local > > IPv6 address can not distinguish whether that is another vehicle or it > > is a smart phone in the car or it is a smart phone from road side > > passengers. > > > > If we want to use IPv6 link local address, a dedicate prefix for V2V > > may needed. > > > > Any thoughts? > > > > > > ------ > > Best Regards, > > Dapeng Liu > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Jul 22 06:17:08 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD381A1B43 for ; Wed, 22 Jul 2015 06:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0SI50TEE6lsn for ; Wed, 22 Jul 2015 06:17:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4651B337B for ; Wed, 22 Jul 2015 06:16:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVL65161; Wed, 22 Jul 2015 13:16:53 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 14:16:52 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.213]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 21:16:46 +0800 From: "Huangjing (A)" To: Dapeng Liu , "its@ietf.org" Thread-Topic: [geonet/its] Why not using IPv6 link local address for one hop V2V Thread-Index: AQHQxHHiFuVIyVe7P0WgQROH1uKCFJ3ndv5g Date: Wed, 22 Jul 2015 13:16:45 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.104.150] Content-Type: multipart/alternative; boundary="_000_774B240D54DAB844B37EE80C2DD8E8BC6746D282SZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:17:07 -0000 --_000_774B240D54DAB844B37EE80C2DD8E8BC6746D282SZXEMA501MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERhcGVuZywNCg0KTWF5YmUgd2UgY2FuIGRpc3Rpbmd1aXNoIGEgdmVoaWNsZSBmcm9tIGEg bW9iaWxlIGJ5IG90aGVyIG1lYW5zLCByYXRoZXIgdGhhbiBJUCBwcmVmaXggLyBhZGRyZXNzLg0K Rm9yIG1lc3NhZ2UgYnJvYWRjYXN0IChlLmcuIHNhZmV0eSByZWxhdGVkIG1lc3NhZ2UpLCB3ZSBt YXkgcmVxdWlyZSBhIGRlZGljYXRlZCBtdWx0aWNhc3QgYWRkcmVzczsgZm9yIFVuaWNhc3QgY29t bXVuaWNhdGlvbiwgSSB0aGluayB3ZSBzaG91bGQgbWFrZSB1c2Ugb2YgaGlnaGVyIGxldmVsIGlu Zm9ybWF0aW9uLCBzdWNoIGFzIFRDUC9VRFAob3Igc2ltaWxhciBvbmUpIHBvcnQgb3IgYXBwbGlj YXRpb24gbGV2ZWwgaW5mb3JtYXRpb24NCg0KQW55IHRob3VnaHRzPw0KDQpKYW1lcw0KDQpGcm9t OiBpdHMgW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhcGVuZyBM aXUNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMiwgMjAxNSA3OjMwIFBNDQpUbzogaXRzQGlldGYu b3JnDQpTdWJqZWN0OiBbZ2VvbmV0L2l0c10gV2h5IG5vdCB1c2luZyBJUHY2IGxpbmsgbG9jYWwg YWRkcmVzcyBmb3Igb25lIGhvcCBWMlYNCg0KSGVsbG8gYWxsLA0KDQpEdXJpbmcgdGhlIG5vb24g ZGlzY3Vzc2lvbiwgd2Ugd2VyZSBkaXNjdXNzaW5nIHdoZXRoZXIgd2UgY2FuIHVzZSBJUHY2IGxp bmsgbG9jYWwgYWRkcmVzcyBmb3Igb25lIGhvcCBWLVYgSVAgY29tbXVuaWNhdGlvbi4NCg0KT25l IHJlYXNvbiBpcyB0aGF0IHRoZSB2ZWhpY2xlIHRoYXQgZGlzY292ZXIgYSBuZWlnaGJvciB3aXRo IGxpbmsgbG9jYWwgSVB2NiBhZGRyZXNzIGNhbiBub3QgZGlzdGluZ3Vpc2ggd2hldGhlciB0aGF0 IGlzIGFub3RoZXIgdmVoaWNsZSBvciBpdCBpcyBhIHNtYXJ0IHBob25lIGluIHRoZSBjYXIgb3Ig aXQgaXMgYSBzbWFydCBwaG9uZSBmcm9tIHJvYWQgc2lkZSBwYXNzZW5nZXJzLg0KDQpJZiB3ZSB3 YW50IHRvIHVzZSBJUHY2IGxpbmsgbG9jYWwgYWRkcmVzcywgYSBkZWRpY2F0ZSBwcmVmaXggZm9y IFYyViBtYXkgbmVlZGVkLg0KDQpBbnkgdGhvdWdodHM/DQoNCg0KLS0tLS0tDQpCZXN0IFJlZ2Fy ZHMsDQpEYXBlbmcgTGl1DQo= --_000_774B240D54DAB844B37EE80C2DD8E8BC6746D282SZXEMA501MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSwgRGFw ZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSB3ZSBjYW4gZGlz dGluZ3Vpc2ggYSB2ZWhpY2xlIGZyb20gYSBtb2JpbGUgYnkgb3RoZXIgbWVhbnMsIHJhdGhlciB0 aGFuIElQIHByZWZpeCAvIGFkZHJlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Gb3IgbWVzc2FnZSBicm9hZGNhc3QgKGUuZy4gc2FmZXR5IHJlbGF0ZWQgbWVz c2FnZSksIHdlIG1heSByZXF1aXJlIGEgZGVkaWNhdGVkIG11bHRpY2FzdCBhZGRyZXNzOyBmb3Ig VW5pY2FzdCBjb21tdW5pY2F0aW9uLCBJIHRoaW5rIHdlIHNob3VsZA0KIG1ha2UgdXNlIG9mIGhp Z2hlciBsZXZlbCBpbmZvcm1hdGlvbiwgc3VjaCBhcyBUQ1AvVURQKG9yIHNpbWlsYXIgb25lKSBw b3J0IG9yIGFwcGxpY2F0aW9uIGxldmVsIGluZm9ybWF0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFueSB0aG91Z2h0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SmFtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaXRzIFttYWlsdG86aXRz LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhcGVuZyBMaXU8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDIyLCAyMDE1IDc6MzAgUE08YnI+DQo8Yj5Ubzo8 L2I+IGl0c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbZ2VvbmV0L2l0c10gV2h5IG5v dCB1c2luZyBJUHY2IGxpbmsgbG9jYWwgYWRkcmVzcyBmb3Igb25lIGhvcCBWMlY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gYWxsLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkR1cmluZyB0aGUgbm9vbiBkaXNjdXNzaW9uLCB3 ZSB3ZXJlIGRpc2N1c3Npbmcgd2hldGhlciB3ZSBjYW4gdXNlIElQdjYgbGluayBsb2NhbCBhZGRy ZXNzIGZvciBvbmUgaG9wIFYtViBJUCBjb21tdW5pY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T25lIHJlYXNvbiBpcyB0aGF0IHRoZSB2ZWhp Y2xlIHRoYXQgZGlzY292ZXIgYSBuZWlnaGJvciB3aXRoIGxpbmsgbG9jYWwgSVB2NiBhZGRyZXNz IGNhbiBub3QgZGlzdGluZ3Vpc2ggd2hldGhlciB0aGF0IGlzIGFub3RoZXIgdmVoaWNsZSBvciBp dCBpcyBhIHNtYXJ0IHBob25lIGluIHRoZSBjYXIgb3IgaXQgaXMgYSBzbWFydCBwaG9uZSBmcm9t IHJvYWQgc2lkZSBwYXNzZW5nZXJzLg0KICZuYnNwOzxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHdlIHdhbnQgdG8gdXNlIElQdjYg bGluayBsb2NhbCBhZGRyZXNzLCBhIGRlZGljYXRlIHByZWZpeCBmb3IgVjJWIG1heSBuZWVkZWQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbnkgdGhv dWdodHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQotLS0tLS08YnI+ DQpCZXN0IFJlZ2FyZHMsPGJyPg0KRGFwZW5nIExpdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_774B240D54DAB844B37EE80C2DD8E8BC6746D282SZXEMA501MBXchi_-- From nobody Wed Jul 22 07:14:26 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88DE1B2D84 for ; Wed, 22 Jul 2015 07:14:24 -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, SPF_PASS=-0.001] autolearn=ham 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 F-I1m1OCckg1 for ; Wed, 22 Jul 2015 07:14:23 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (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 C823D1B2C24 for ; Wed, 22 Jul 2015 07:14:22 -0700 (PDT) Received: by vnaa140 with SMTP id a140so48623018vna.2 for ; Wed, 22 Jul 2015 07:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wGyvoRzrUzr+ezLOGIhG5F94JBLXWmVdMXr2FKfNuv4=; b=eL1jfFZWzYswgJvKNGNsiAov6DD84tszBSvjIKcIXxoUYV/yLlcfQhusND7dasKTeY O9nrRZqZWKR4wIWFQ67MDj8CGzw4/K+dvZYRVK2MKtbYEJ9WkeEgytUiKyRf9+b/hBK/ 8AAH7SnFJDhtuAlZRWNFYuriass/Wt8Swp2QU3aPP/GHuy1a+H3qHvDCLUFm3Oj9sqPI TNxJS6TsnPegx/7ZS+jLmcOiG2rlF+OZh2nEbsXodxjhlcSSRr0Pb/xbVmb3uZg2wKky iE8rLOPppCXuQPIGUesNRCqiHw4qQ5M46Ne0zRTRTztgFOLRR58ihlK7PkKHEpZTGTu3 H7Cg== MIME-Version: 1.0 X-Received: by 10.52.2.170 with SMTP id 10mr3361729vdv.93.1437574462084; Wed, 22 Jul 2015 07:14:22 -0700 (PDT) Received: by 10.31.178.145 with HTTP; Wed, 22 Jul 2015 07:14:22 -0700 (PDT) In-Reply-To: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> References: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> Date: Wed, 22 Jul 2015 16:14:22 +0200 Message-ID: From: Dapeng Liu To: "Huangjing (A)" Content-Type: multipart/alternative; boundary=bcaec502d9fa269afa051b776344 Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 14:14:24 -0000 --bcaec502d9fa269afa051b776344 Content-Type: text/plain; charset=UTF-8 Sure. My point is we can not just use IPv6 link local address to fulfill the requirement. agree? Thanks, Dapeng Liu 2015-07-22 15:16 GMT+02:00 Huangjing (A) : > Hi, Dapeng, > > > > Maybe we can distinguish a vehicle from a mobile by other means, rather > than IP prefix / address. > > For message broadcast (e.g. safety related message), we may require a > dedicated multicast address; for Unicast communication, I think we should > make use of higher level information, such as TCP/UDP(or similar one) port > or application level information > > > > Any thoughts? > > > > James > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Dapeng Liu > *Sent:* Wednesday, July 22, 2015 7:30 PM > *To:* its@ietf.org > *Subject:* [geonet/its] Why not using IPv6 link local address for one hop > V2V > > > > Hello all, > > > > During the noon discussion, we were discussing whether we can use IPv6 > link local address for one hop V-V IP communication. > > > > One reason is that the vehicle that discover a neighbor with link local > IPv6 address can not distinguish whether that is another vehicle or it is a > smart phone in the car or it is a smart phone from road side passengers. > > > > If we want to use IPv6 link local address, a dedicate prefix for V2V may > needed. > > > > Any thoughts? > > > > > ------ > Best Regards, > Dapeng Liu > -- ------ Best Regards, Dapeng Liu --bcaec502d9fa269afa051b776344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure. My point is we can not just use IPv6 link local addr= ess to fulfill the requirement. =C2=A0agree?

Thanks,
Dapeng Liu

2015-07-22 15:16 GMT+02:00 Huangjing (A) <= james.huang@hua= wei.com>:

Hi, Dapeng= ,

=C2= =A0

Maybe we c= an distinguish a vehicle from a mobile by other means, rather than IP prefi= x / address.

For messag= e broadcast (e.g. safety related message), we may require a dedicated multi= cast address; for Unicast communication, I think we should make use of higher level information, such as TCP/UDP(or similar one) port= or application level information

=C2= =A0

Any though= ts?

=C2= =A0

James

=C2= =A0




--

------
Best Regards,
Dapeng Liu
--bcaec502d9fa269afa051b776344-- From nobody Wed Jul 22 07:47:18 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6972C1B2E15 for ; Wed, 22 Jul 2015 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 aZqR6Rw2t2Wo for ; Wed, 22 Jul 2015 07:47:15 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2D81B2DFB for ; Wed, 22 Jul 2015 07:47:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MElCKw023719 for ; Wed, 22 Jul 2015 16:47:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 49E0320277B for ; Wed, 22 Jul 2015 16:50:48 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 40982200B3A for ; Wed, 22 Jul 2015 16:50:48 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MElBhp015039 for ; Wed, 22 Jul 2015 16:47:12 +0200 To: its@ietf.org References: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> From: Alexandru Petrescu Message-ID: <55AFACEE.5010408@gmail.com> Date: Wed, 22 Jul 2015 16:47:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 14:47:17 -0000 I tend to agree. Just that I dont think we need another kind of addresses. In other words: yes, just using LL addresses to realize V2V communication is not enough. no, in that messages between routers can be sourced just by their link-local addresses. Or maybe a prefix between vehicles would be needed. The creation of IP addresses _inside_ vehicles is currently a problem as well. Alex Le 22/07/2015 16:14, Dapeng Liu a écrit : > Sure. My point is we can not just use IPv6 link local address to fulfill > the requirement. agree? > > Thanks, > Dapeng Liu > > 2015-07-22 15:16 GMT+02:00 Huangjing (A) >: > > Hi, Dapeng,____ > > __ __ > > Maybe we can distinguish a vehicle from a mobile by other means, > rather than IP prefix / address.____ > > For message broadcast (e.g. safety related message), we may require > a dedicated multicast address; for Unicast communication, I think we > should make use of higher level information, such as TCP/UDP(or > similar one) port or application level information____ > > __ __ > > Any thoughts?____ > > __ __ > > James____ > > __ __ > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Dapeng Liu > *Sent:* Wednesday, July 22, 2015 7:30 PM > *To:* its@ietf.org > *Subject:* [geonet/its] Why not using IPv6 link local address for > one hop V2V____ > > __ __ > > Hello all,____ > > __ __ > > During the noon discussion, we were discussing whether we can use > IPv6 link local address for one hop V-V IP communication.____ > > __ __ > > One reason is that the vehicle that discover a neighbor with link > local IPv6 address can not distinguish whether that is another > vehicle or it is a smart phone in the car or it is a smart phone > from road side passengers. > ____ > > __ __ > > If we want to use IPv6 link local address, a dedicate prefix for V2V > may needed.____ > > __ __ > > Any thoughts?____ > > __ __ > > > ------ > Best Regards, > Dapeng Liu____ > > > > > -- > > ------ > Best Regards, > Dapeng Liu > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Jul 22 07:58:28 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352CF1A0019 for ; Wed, 22 Jul 2015 07:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 2FtqRyykN8oD for ; Wed, 22 Jul 2015 07:58:24 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A611A0018 for ; Wed, 22 Jul 2015 07:58:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MEw1xF019152; Wed, 22 Jul 2015 16:58:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 94A7520277B; Wed, 22 Jul 2015 17:01:36 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86CFC200B3A; Wed, 22 Jul 2015 17:01:36 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MEvxoA028761; Wed, 22 Jul 2015 16:58:00 +0200 To: "Huangjing (A)" References: <55AF8E79.7040405@gmail.com> <774B240D54DAB844B37EE80C2DD8E8BC6746D258@SZXEMA501-MBX.china.huawei.com> From: Alexandru Petrescu Message-ID: <55AFAF76.3030205@gmail.com> Date: Wed, 22 Jul 2015 16:57:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <774B240D54DAB844B37EE80C2DD8E8BC6746D258@SZXEMA501-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 14:58:27 -0000 One has to think these vehicles approach and their Routers (R1, R2) are reachable to each other, on their egress 802.11p interfaces. But the Hosts inside each vehicle (H1 and H2) can not see each other, simple because they have Ethernet cable interfaces (not 802.11p). ---- ---- LL LL ---- ---- | H1 |-----| R1 |--o o--| R2 |-----| H2 | ---- ---- ---- ---- Ethernet 11p Ethernet Between H1 and H2 there are indeed 2 IP hops (R1 and R2). But the range of action of protocols we would like to concentrate on is the hop between vehicles. And use existing protocols on the hop _inside_ the vehicle. R1 and R2 should do something simple between them, on that single 1-hop, such that H1 and H2 can talk to each other, even though H1 and H2 may be separated by 2 or more IP hops. The structure inside each vehicle is relatively stable, there is no mobility. The structure between vehicles is highly dynamic, but they are all neighbors in IP terms. Alex Le 22/07/2015 15:11, Huangjing (A) a écrit : > Hi, Alexandru, > > Not sure why H1 cannot communicate with H2, is it because they are out of range and need another node to forward/relay the message for them? > If this is the case, then I think this is multi-hop communication, rather 1-hop. > > Random address generation may not be a good idea due to possible duplicated address. > > James > >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Wednesday, July 22, 2015 8:37 PM >> To: its@ietf.org >> Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V >> >> Hi Dapeng, >> >> YEs, during the bar bof discussion a couple of people agreed LL addresses may >> be sufficient. A question was raised on whether or not the use of link-local >> addresses is enough to make vehicles in close range talk to each other in a >> 1-hop manner. >> >> To clarify, the topology would be the following: >> >> ---- ---- LL LL ---- ---- >> | H1 |-----| R1 |--o o--| R2 |-----| H2 | >> ---- ---- ---- ---- >> >> R1 and R2 may be able to communicate to each other by using their LL >> addresses, but could H1 talk to H2? >> >> H1, R1 are in car1, and H2, R2 are in car2. H1 is the GPS data source and H2 >> is the GPS data receiver. H1 needs to send the location data to H2, in order to >> inform the nearby vehicle about whether they can try to platoon themselves. >> >> The GPS data could be any other app-level data, for example the output of the >> odometer (speed measurement), or a camera streaming an IP video. >> >> To me, yes, LL addresses between R1 and R2 are sufficient, but they are not >> sufficient for communication between H1 and H2. >> >> Dedicate prefix for V2V management? Yes, why not, could be a good help in >> making addresses. What do the other think? >> >> Duplicate Address Detection taking too much time between R1 and R2? >> Maybe yes. Maybe avoid it? >> >> LL addresses using random MAC addresses? Good idea for privacy, but >> maybe depends on the privacy concerns? MAC address randomization impact >> on fast auto-configuration? Are MAC addresses required by the law to be >> visible just like the license plates are? Or are the MAC addresses more like >> the photo of the driver - private data accepted so by the government. >> >> Alex >> >> Le 22/07/2015 13:30, Dapeng Liu a écrit : >>> Hello all, >>> >>> During the noon discussion, we were discussing whether we can use IPv6 >>> link local address for one hop V-V IP communication. >>> >>> One reason is that the vehicle that discover a neighbor with link >>> local >>> IPv6 address can not distinguish whether that is another vehicle or it >>> is a smart phone in the car or it is a smart phone from road side >>> passengers. >>> >>> If we want to use IPv6 link local address, a dedicate prefix for V2V >>> may needed. >>> >>> Any thoughts? >>> >>> >>> ------ >>> Best Regards, >>> Dapeng Liu >>> >>> >>> _______________________________________________ >>> 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 22 08:18:32 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED971A0396 for ; Wed, 22 Jul 2015 08:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 1fjkwlwpoVgO for ; Wed, 22 Jul 2015 08:18:30 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 EFA001A037E for ; Wed, 22 Jul 2015 08:18:29 -0700 (PDT) Received: by qkfc129 with SMTP id c129so112435728qkf.1 for ; Wed, 22 Jul 2015 08:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=MMkPFlNMkuh9IHdhjo3QXQO+VrskfoxFWZZEckpIoeI=; b=gFkq+1/i7YemHjyGvVz7a4I6iGgvkhcKEhl34vb9JkhFjlOyuUlgi2d6PWqjPZfb7D VmvztMrJQdini2DVw2r4rXYPe9et7d7oks4kDPxqu+xFLs9xLMKSoaIF63IaOkoZODB/ cfFNmdD4YEeIsh9Z4sUs9zHnqA1J+pukVOifE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=MMkPFlNMkuh9IHdhjo3QXQO+VrskfoxFWZZEckpIoeI=; b=gF52ISOGggLCp/LY3vx9QF5cgMMi6k0z1cHEBjdVsffYUW5RIMLN7seYZn7Q2nciqD +MpH+NFkltnAZxBKzjKNrImx1YbgcbJMcx1WT6wJy4KXgUE/YbmtqSsLv3CgoxJFahzG /5+d8WVnXLEsnoDBQF9znX0Sc7uPdkXDJF7RBqfIotOxl/yqY5muPYJ8GpmSax27DAnn Y6XJMBdPp2IOxKpLqOHKAzIK2Ctmlu6FdfUm+KqHAfL/+EV9SZz2o4++KveNxleeZnmR /Tf5M6f7ApXb8J8gJDh37V2EA2i1WGY2KasYdZVEC+N7JhtOoIWi4Ku/lgZ03FyaUZwH 344w== X-Gm-Message-State: ALoCoQkAN4GGBJ2sbDlQtcnNbNZoObUEdy2YbrcZNX8hXPulxnin2AqHPIBOulkb/tteKpSfqnL6 MIME-Version: 1.0 X-Received: by 10.140.16.74 with SMTP id 68mr4253557qga.99.1437578309157; Wed, 22 Jul 2015 08:18:29 -0700 (PDT) Received: by 10.96.238.7 with HTTP; Wed, 22 Jul 2015 08:18:29 -0700 (PDT) Date: Wed, 22 Jul 2015 17:18:29 +0200 Message-ID: From: William Whyte To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a11c0429e745c3a051b7848ab Archived-At: Cc: "Huangjing \(A\)" , "its@ietf.org" Subject: [geonet/its] Prague plans? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:18:31 -0000 --001a11c0429e745c3a051b7848ab Content-Type: text/plain; charset=UTF-8 Hi all -- sorry I wasn't able to get to the meet up after the Plenary. If anyone's still in Prague I'm around after the 17.40-19.40 session and would be interested in meeting up in the hotel lobby to get something to eat or a drink. Cheers, William --001a11c0429e745c3a051b7848ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all -- sorry I wasn't able to get to the meet up af= ter the Plenary. If anyone's still in Prague I'm around after the 1= 7.40-19.40 session and would be interested in meeting up in the hotel lobby= to get something to eat or a drink.

Cheers,
<= br>
William
--001a11c0429e745c3a051b7848ab-- From nobody Wed Jul 22 08:21:31 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5291A0334 for ; Wed, 22 Jul 2015 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 5SVPfWncw7IN for ; Wed, 22 Jul 2015 08:21:28 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0888D1A0113 for ; Wed, 22 Jul 2015 08:21:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MFLE6i002012; Wed, 22 Jul 2015 17:21:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 85E04202A53; Wed, 22 Jul 2015 17:24:49 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D5592029FC; Wed, 22 Jul 2015 17:24:49 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MFLCqj017988; Wed, 22 Jul 2015 17:21:13 +0200 To: William Whyte References: From: Alexandru Petrescu Message-ID: <55AFB4E8.7080803@gmail.com> Date: Wed, 22 Jul 2015 17:21:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Huangjing \(A\)" , "its@ietf.org" Subject: Re: [geonet/its] Prague plans? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:21:29 -0000 Let's meet at 20h at the IETF Registration Desk go for a beer or eat. Alex Le 22/07/2015 17:18, William Whyte a Ă©crit : > Hi all -- sorry I wasn't able to get to the meet up after the Plenary. > If anyone's still in Prague I'm around after the 17.40-19.40 session and > would be interested in meeting up in the hotel lobby to get something to > eat or a drink. > > Cheers, > > William From nobody Wed Jul 22 08:42:50 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B959D1A1A1C for ; Wed, 22 Jul 2015 08:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 vxG1uaNJK4CT for ; Wed, 22 Jul 2015 08:42:47 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 AA20B1A0AC8 for ; Wed, 22 Jul 2015 08:42:47 -0700 (PDT) Received: by qkbm65 with SMTP id m65so101479690qkb.2 for ; Wed, 22 Jul 2015 08:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=S1LjSbZeJw/rAhknJ6Mvd7qFmkeIkobRDDclDNg41i4=; b=VTd882RmfR6xVZm22mW8A5xFpuc6ms3Ti8j93b/SXQu/VToypyo40hAnivktN7Z9KZ Bn1oWCf9Dzj6N1FmCCBrj+NHCHhPRQDe2lMu2nC4Xus69HFb4a+jW1wzsLQIy6P9u82w S3/QBBY5L9STMkYl9J7zpBFmEnbPGBa6N/QL0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=S1LjSbZeJw/rAhknJ6Mvd7qFmkeIkobRDDclDNg41i4=; b=XcP5T3XA+8H88E6HYYXW5iJYc73Uz0tXMgfTCKRRSTA1wn6XTxCb8SvO9hVqOfCYWF hNtZOa9Zql6d9M/rMCytNiA1LnY7Ut3pna9fyVn/BC+NayIDoOIifK43YSlEcK1Q0x6j y0GdICwp73B+vyA+RDVlb7SFW7Q2z/9GBnYeNtEYHQSe+juISn8yrH3A/YAG6RT4XH8k FzchFR0CYbD4OhE9qpb6arWbSjMgmSRTwnBlwa8g/sLrL5Cz0GaXukWvn4fJEQQGRMiH 2FiSxCWO7ocn8JDSuZRO3yKMAsE+goYmntBbZO1ZmMCs3zbgzay3ZkLaaU/w1kOsjeOE a6BA== X-Gm-Message-State: ALoCoQlkUY0Ri6HOQvWrhijUzrpHnAkZVpIN5qNT5Rgs6OnSpWsrwfL2yQjBMOF9wX+ErWd/2weU X-Received: by 10.140.150.198 with SMTP id 189mr4890369qhw.88.1437579766983; Wed, 22 Jul 2015 08:42:46 -0700 (PDT) From: William Whyte References: <55AFB4E8.7080803@gmail.com> In-Reply-To: <55AFB4E8.7080803@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWr32aUhvCHAzoLwcf7dS+d8G3lgKdGOnQncbfoWA= Date: Wed, 22 Jul 2015 17:33:09 +0200 Message-ID: <3edb11803ef2b7e48905edd3149d8671@mail.gmail.com> To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Huangjing \(A\)" , its@ietf.org Subject: Re: [geonet/its] Prague plans? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:42:48 -0000 See you there! -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, July 22, 2015 5:21 PM To: William Whyte Cc: Huangjing (A); its@ietf.org Subject: Re: Prague plans? Let's meet at 20h at the IETF Registration Desk go for a beer or eat. Alex Le 22/07/2015 17:18, William Whyte a =C3=A9crit : > Hi all -- sorry I wasn't able to get to the meet up after the Plenary. > If anyone's still in Prague I'm around after the 17.40-19.40 session and > would be interested in meeting up in the hotel lobby to get something to > eat or a drink. > > Cheers, > > William From nobody Wed Jul 22 09:25:57 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AC71AC3E3 for ; Wed, 22 Jul 2015 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 VYZjBEjJdThC for ; Wed, 22 Jul 2015 09:25:47 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::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 D48751A8A4B for ; Wed, 22 Jul 2015 09:25:12 -0700 (PDT) Received: by pdbbh15 with SMTP id bh15so95313316pdb.1 for ; Wed, 22 Jul 2015 09:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=oXuszAyH/MLn+16wOPzOyQAWF2P42625sJ/OziSLKZY=; b=cHvLT8mhMit/Zmh58+PfqlrjjRZ2qxYlmtl9itHJ1DOz4sb8eKEfEaOqsOicDhtq7y XQ8l1+MQ9MiwUMxvkEt2kgQOE88wTj5mRzMBSjL9D1m0xzAEHeyCV0pjNAcczO3jmw8/ nxBqQblO42vtrRc6cALtppsWZ31Zbi+b5EIv4MyNh0lO31eV5Fk6rATnS6E74s3U/5po /w7Ncah0wZuxQ5d2qW2VLR7wvod1IdCNI8iK7I6lUwqGMh0KZLdx63bpVfB7tqIwoOez Nbs7HqejyuGN+dKIB9aqg1YqZIkvL1ur8PIJAVgoUvTlJV5XBT1zPGT5Z2IJvrN5le8Y EMsA== X-Received: by 10.66.65.227 with SMTP id a3mr6573966pat.147.1437582312458; Wed, 22 Jul 2015 09:25:12 -0700 (PDT) Received: from [192.168.1.107] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by smtp.gmail.com with ESMTPSA id b10sm4142331pdo.84.2015.07.22.09.25.11 (version=TLS1_2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 09:25:11 -0700 (PDT) Message-ID: <1437582310.1975.212.camel@localhost.localdomain> From: Rex Buddenberg To: Dapeng Liu Date: Wed, 22 Jul 2015 09:25:10 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:25:49 -0000 The problem with physical (as opposed to logical) 'v-v' connection is that you have good probability of not reaching the vehicles you need to reach most. Like crossing traffic where the RF path is blocked by a building. Organizing unicast groups seems to me to be the logical way out. The group membership is likely to be very dynamic. On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote: > Hello all, > > > During the noon discussion, we were discussing whether we can use IPv6 > link local address for one hop V-V IP communication. > > > One reason is that the vehicle that discover a neighbor with link > local IPv6 address can not distinguish whether that is another vehicle > or it is a smart phone in the car or it is a smart phone from road > side passengers. > > > If we want to use IPv6 link local address, a dedicate prefix for V2V > may needed. > > > Any thoughts? > > > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Jul 22 16:05:07 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05841A03D5 for ; Wed, 22 Jul 2015 16:05:05 -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, SPF_PASS=-0.001] autolearn=ham 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 zevT8yWAf4-S for ; Wed, 22 Jul 2015 16:05:02 -0700 (PDT) Received: from mail-vn0-x230.google.com (mail-vn0-x230.google.com [IPv6:2607:f8b0:400c:c0f::230]) (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 6E8A21A004E for ; Wed, 22 Jul 2015 16:05:02 -0700 (PDT) Received: by vnk197 with SMTP id 197so54021093vnk.3 for ; Wed, 22 Jul 2015 16:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nKMPEW+1fx8hc1oAT/ETQYWZsripQw8jtnGF05T/59w=; b=pn4cSniIiP/S4vxTX9WfM+CaUWiS6FU5uQQP8EmK/4nrLnMRCKKhYzbAkavkcLNBfR goW0R1jE4kLQhe04TBuzCXxYsj+lSDecH5v4iM57V7IkuIlWmo1RhCRwXP5aGhk1IofA 3Mx7A+NPgjLzQRumv+D+N+vBEhZbP6uTb19Inn60S752MAOaYwwQZQp1gI609pUnlSXE wvetobqDrb4wzg+9q1A4UZULqMIwMPCEPUZbiFvbx5Mqlp/VeuyDZRPzp2ZFetQb4by5 ln++B4tLDD70kHCuATPhpyNDxLq+/fow2KrmHD7hbVvGivzMgpuISjfk6hLXEdxzwrws ijvg== MIME-Version: 1.0 X-Received: by 10.52.3.230 with SMTP id f6mr6154727vdf.49.1437606301664; Wed, 22 Jul 2015 16:05:01 -0700 (PDT) Received: by 10.31.178.145 with HTTP; Wed, 22 Jul 2015 16:05:01 -0700 (PDT) In-Reply-To: References: <1437582310.1975.212.camel@localhost.localdomain> Date: Thu, 23 Jul 2015 01:05:01 +0200 Message-ID: From: Dapeng Liu To: dickroy@alum.mit.edu Content-Type: multipart/alternative; boundary=485b397dd5eff00c4a051b7ecc4c Archived-At: Cc: Rex Buddenberg , "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hopV2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 23:05:05 -0000 --485b397dd5eff00c4a051b7ecc4c Content-Type: text/plain; charset=UTF-8 OK. That comes to the question: should we use IP for one hop V2V. I guess Alex have posted a picture to explain the scenario why IP is needed.. Thanks, Dapeng Liu 2015-07-23 0:33 GMT+02:00 Richard Roy : > The real question is not "can we use IPv6 for single-hop communications?", > the real question is "should we use a network protocol for single-hop > communications when it is really a link-layer issue?" I think most people > would say "IPv6 is not necessary; MAC bridging at the data link layer is > more than enough for this situation". > > IPv6 carries an overhead (>39 bytes) that V2V comms, especially on the > crowded safety channel, do not need. > > Cheers, > > RR > > > -----Original Message----- > > From: Rex Buddenberg [mailto:buddenbergr@gmail.com] > > Sent: Wednesday, July 22, 2015 9:25 AM > > To: Dapeng Liu > > Cc: its@ietf.org > > Subject: Re: [geonet/its] Why not using IPv6 link local address for one > > hopV2V > > > > The problem with physical (as opposed to logical) 'v-v' connection is > > that you have good probability of not reaching the vehicles you need to > > reach most. Like crossing traffic where the RF path is blocked by a > > building. > > Organizing unicast groups seems to me to be the logical way out. > > The group membership is likely to be very dynamic. > > > > On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote: > > > Hello all, > > > > > > > > > During the noon discussion, we were discussing whether we can use IPv6 > > > link local address for one hop V-V IP communication. > > > > > > > > > One reason is that the vehicle that discover a neighbor with link > > > local IPv6 address can not distinguish whether that is another vehicle > > > or it is a smart phone in the car or it is a smart phone from road > > > side passengers. > > > > > > > > > If we want to use IPv6 link local address, a dedicate prefix for V2V > > > may needed. > > > > > > > > > Any thoughts? > > > > > > > > > ------ > > > Best Regards, > > > Dapeng Liu > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > -- ------ Best Regards, Dapeng Liu --485b397dd5eff00c4a051b7ecc4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK. That comes to the question: should we use IP for one h= op V2V. I guess Alex have posted a picture to explain the scenario why IP i= s needed..

Thanks,
Dapeng Liu

2015-07-23 0:33 GMT+02= :00 Richard Roy <dickroy@alum.mit.edu>:
The real question is not "can we use IPv6 for single-= hop communications?",
the real question is "should we use a network protocol for single-hop<= br> communications when it is really a link-layer issue?"=C2=A0 I think mo= st people
would say "IPv6 is not necessary; MAC bridging at the data link layer = is
more than enough for this situation".

IPv6 carries an overhead (>39 bytes) that V2V comms, especially on the crowded safety channel, do not need.

Cheers,

RR

> -----Original Message-----
> From: Rex Buddenberg [mailto:= buddenbergr@gmail.com]
> Sent: Wednesday, July 22, 2015 9:25 AM
> To: Dapeng Liu
> Cc: its@ietf.org
> Subject: Re: [geonet/its] Why not using IPv6 link local address for on= e
> hopV2V
>
> The problem with physical (as opposed to logical) 'v-v' connec= tion is
> that you have good probability of not reaching the vehicles you need t= o
> reach most.=C2=A0 Like crossing traffic where the RF path is blocked b= y a
> building.
>=C2=A0 =C2=A0 =C2=A0 Organizing unicast groups seems to me to be the lo= gical way out.
> The group membership is likely to be very dynamic.
>
> On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote:
> > Hello all,
> >
> >
> > During the noon discussion, we were discussing whether we can use= IPv6
> > link local address for one hop V-V IP communication.
> >
> >
> > One reason is that the vehicle that discover a neighbor with link=
> > local IPv6 address can not distinguish whether that is another ve= hicle
> > or it is a smart phone in the car or it is a smart phone from roa= d
> > side passengers.
> >
> >
> > If we want to use IPv6 link local address, a dedicate prefix for = V2V
> > may needed.
> >
> >
> > Any thoughts?
> >
> >
> > ------
> > Best Regards,
> > Dapeng Liu
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>
>





--
=

------
Best Regards,
Dapeng Liu
--485b397dd5eff00c4a051b7ecc4c-- From nobody Thu Jul 23 01:35:31 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8B1AC3F6 for ; Thu, 23 Jul 2015 01:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 cPBG2Me2DsAn for ; Thu, 23 Jul 2015 01:35:24 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id C5BDF1A8F50 for ; Thu, 23 Jul 2015 01:35:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,529,1432591200"; d="jpg'145?scan'145,208,217,145";a="875249" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 23 Jul 2015 10:35:11 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 68F0E5F2; Thu, 23 Jul 2015 10:35:11 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Dapeng Liu'" , Date: Thu, 23 Jul 2015 10:35:11 +0200 Organization: EURECOM Message-ID: <006d01d0c522$7d3d1760$77b74620$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_006E_01D0C533.40CA7B40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDFInxHFEZZ3JEWSUe49I1VaszXCg== Content-Language: en-us Archived-At: Cc: 'Rex Buddenberg' , its@ietf.org Subject: Re: [geonet/its] Why not using IPv6 link local address for one hopV2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 08:35:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006E_01D0C533.40CA7B40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006F_01D0C533.40CA7B40" ------=_NextPart_001_006F_01D0C533.40CA7B40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Dapeng, =20 To the risk of mentioning it again (Dick and I had a same discussion in = this ITS group around the same time last year, please see the logs) and = again still agree with his statement below, the true question is indeed = not if we should use IP for one-hop V2V, but also which application = would need to have a 1-hop V2V in IPv6.=20 =20 Both ETSI and IEEE do not rely on IP for 1-hop V2V for safety-related = communications, as simply stated: it is not required, period.=20 =20 IP is necessary for interoperability and global connectivity. So, this = group should describe which applications would require either = interoperability between different technologies and/or global = connectivity (to the cloud, between vehicles over the cloud), and which = would require direct V2V communication (which would not be done better = via the cloud/backend).=20 =20 Once we have such description, then we can discuss if we need IPv6 for = V2V and how to make it happen. =20 There could be some of these applications, e.g. proximity/social = networking (unsupervised LTE D2D, maybe WiFi direct, etc..), cellular = traffic offloading, to name a few=E2=80=A6but we should really take the = debate from the right end. =20 My two cents=E2=80=A6 =20 Cheers, =20 J=C3=A9r=C3=B4me =20 =20 -------------------------------------------------------------- Dr. habil J=C3=A9r=C3=B4me H=C3=A4rri Tenured Assistant Professor Wireless Vehicular Networks Description: Description : EURECOM_20ANS_FR_50 EURECOM 2229 Route des Cr=C3=AAtes - BP193 06904 SOPHIA ANTIPOLIS CEDEX -------------------------------------------------------------------------= --- =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Dapeng Liu Sent: Thursday 23 July 2015 01:05 To: dickroy@alum.mit.edu Cc: Rex Buddenberg; its@ietf.org Subject: Re: [geonet/its] Why not using IPv6 link local address for one = hopV2V =20 OK. That comes to the question: should we use IP for one hop V2V. I = guess Alex have posted a picture to explain the scenario why IP is = needed.. =20 Thanks, Dapeng Liu =20 2015-07-23 0:33 GMT+02:00 Richard Roy : The real question is not "can we use IPv6 for single-hop = communications?", the real question is "should we use a network protocol for single-hop communications when it is really a link-layer issue?" I think most = people would say "IPv6 is not necessary; MAC bridging at the data link layer is more than enough for this situation". IPv6 carries an overhead (>39 bytes) that V2V comms, especially on the crowded safety channel, do not need. Cheers, RR > -----Original Message----- > From: Rex Buddenberg [mailto:buddenbergr@gmail.com] > Sent: Wednesday, July 22, 2015 9:25 AM > To: Dapeng Liu > Cc: its@ietf.org > Subject: Re: [geonet/its] Why not using IPv6 link local address for = one > hopV2V > > The problem with physical (as opposed to logical) 'v-v' connection is > that you have good probability of not reaching the vehicles you need = to > reach most. Like crossing traffic where the RF path is blocked by a > building. > Organizing unicast groups seems to me to be the logical way out. > The group membership is likely to be very dynamic. > > On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote: > > Hello all, > > > > > > During the noon discussion, we were discussing whether we can use = IPv6 > > link local address for one hop V-V IP communication. > > > > > > One reason is that the vehicle that discover a neighbor with link > > local IPv6 address can not distinguish whether that is another = vehicle > > or it is a smart phone in the car or it is a smart phone from road > > side passengers. > > > > > > If we want to use IPv6 link local address, a dedicate prefix for V2V > > may needed. > > > > > > Any thoughts? > > > > > > ------ > > Best Regards, > > Dapeng Liu > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > =20 --=20 ------ Best Regards, Dapeng Liu ------=_NextPart_001_006F_01D0C533.40CA7B40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Dapeng,

 

To the risk of mentioning it again (Dick and I had a same discussion = in this ITS group around the same time last=C2=A0 year, please see the = logs) and again still agree with his statement below, the true question = is indeed not if we should use IP for one-hop V2V, but also which = application would need to have a 1-hop V2V in IPv6. =

 

Both ETSI and IEEE do not rely on IP for 1-hop V2V for safety-related = communications, as simply stated: it is not required, period. =

 

IP is necessary for interoperability and global connectivity. So, = this group should describe which applications would require either = interoperability between different technologies and/or global = connectivity (to the cloud, between vehicles over the cloud), and which = would require direct V2V communication (which would not be done better = via the cloud/backend).

 

Once we have such description, then we can discuss if we need IPv6 = for V2V and how to make it happen.

 

There could be some of these applications, e.g. proximity/social = networking (unsupervised LTE D2D, maybe WiFi direct, etc..), cellular = traffic offloading, to name a few=E2=80=A6but we should really take the = debate from the right end.

 

My two cents=E2=80=A6

 

Cheers,

 

J=C3=A9r=C3=B4me

 

 

--------------------------------------------------------------

Dr. habil J=C3=A9r=C3=B4me H=C3=A4rri

Tenured Assistant Professor

Wireless Vehicular Networks

3D"Description:

= EURECOM

= 2229 Route des Cr=C3=AAtes - BP193

= 06904 SOPHIA ANTIPOLIS CEDEX

= -------------------------------------------------------------------------= ---

 

 

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Dapeng = Liu
Sent: Thursday 23 July 2015 01:05
To: = dickroy@alum.mit.edu
Cc: Rex Buddenberg; = its@ietf.org
Subject: Re: [geonet/its] Why not using IPv6 link = local address for one hopV2V

 

OK. = That comes to the question: should we use IP for one hop V2V. I guess = Alex have posted a picture to explain the scenario why IP is = needed..

 

Thanks,

Dapeng Liu

 

2015-07-23 0:33 GMT+02:00 Richard Roy <dickroy@alum.mit.edu>:

The real question is not "can we use IPv6 for = single-hop communications?",
the real question is "should = we use a network protocol for single-hop
communications when it is = really a link-layer issue?"  I think most people
would say = "IPv6 is not necessary; MAC bridging at the data link layer = is
more than enough for this situation".

IPv6 carries an = overhead (>39 bytes) that V2V comms, especially on the
crowded = safety channel, do not = need.

Cheers,

RR


> -----Original = Message-----
> From: Rex Buddenberg [mailto:buddenbergr@gmail.com]
> = Sent: Wednesday, July 22, 2015 9:25 AM
> To: Dapeng Liu
> = Cc: its@ietf.org
> Subject: = Re: [geonet/its] Why not using IPv6 link local address for one
> = hopV2V
>
> The problem with physical (as opposed to logical) = 'v-v' connection is
> that you have good probability of not = reaching the vehicles you need to
> reach most.  Like = crossing traffic where the RF path is blocked by a
> = building.
>      Organizing unicast groups seems to = me to be the logical way out.
> The group membership is likely to = be very dynamic.
>
> On Wed, 2015-07-22 at 13:30 +0200, = Dapeng Liu wrote:
> > Hello all,
> >
> = >
> > During the noon discussion, we were discussing whether = we can use IPv6
> > link local address for one hop V-V IP = communication.
> >
> >
> > One reason is that = the vehicle that discover a neighbor with link
> > local IPv6 = address can not distinguish whether that is another vehicle
> > = or it is a smart phone in the car or it is a smart phone from = road
> > side passengers.
> >
> >
> = > If we want to use IPv6 link local address, a dedicate prefix for = V2V
> > may needed.
> >
> >
> > Any = thoughts?
> >
> >
> > ------
> > = Best Regards,
> > Dapeng Liu
> > = _______________________________________________
> > its mailing = list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>>



 

-- =


------
Best = Regards,
Dapeng Liu

------=_NextPart_001_006F_01D0C533.40CA7B40-- ------=_NextPart_000_006E_01D0C533.40CA7B40 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAMgB6AwERAAIRAQMRAf/EAKYAAAICAgMBAQAAAAAAAAAA AAAHBggFCQIECgMLAQACAQUBAAAAAAAAAAAAAAAAAQIEBQYHCAMQAAEEAgEDAgMEBwUJAAAAAAMB AgQFBgcIABESEwkhFBUxQSIyUSMzNDVVFmFi1JYKgZFCgiRkJUUXEQACAQMDAwIEBAQGAwAAAAAB AgMAEQQSBQYhEwdBFDFRIghhcTIjUjNTFYGRoUJiokNjVP/aAAwDAQACEQMRAD8A9/HRRR0UUdFF HRRR0UUdFFRzJMvxnEK0lxkt3AqK4RkjOkyjJ+KSqKqRhCGhDnk+KKvpsa5/ZFXt2RemAT0FF6WW Qb4xKJS0ljiHlnlhk9ytBQVNOdsQsm0a0TyhnFmjY6tQTZA1X1B+S+o1Ub4qrkYQ369KVx6VDl2d sfYQZmL4XUQMDzCgu2QM7JfTYNo7G6koSPDaVQ1GyNbMMQT2vXxVRKjeyKhEI12Vep6ilcnoPjUk 0BmOW5bTZQ3J7EGQhosml01NlkWGOFHyGJGb2KcIgiCIghERHNejEVWkRq93NVehwB8KFJNP3qFS qt+KcxuJWebWPorCOTmgcw3RGSy9fVOL7dwK+2Cx9ME0m5D/AElV30q7dJp40YhJYkCpIwxvcRrW tcqOxte3SnY/H0qyHSpUdFFHRRR0UVCcyzSFisZGIiSrWSx/ykNrCkRiI1USTK9JERkdj1T8KvY8 nxRn2KqMC9Im1V6tM1yi2edZFzLCA7/JYUOEoIgkROyMEikIfwT+8Ryqv2r1O1qjc1jIV/e1z3Pg 3VlGe5FRysjeSORft7tIr2L/ALui1K5p34FsMtxIHSXjmfPPZ2gzWxTRmzFENquDIRXmE2Y9rXPR yKNj+3ijfLsixK261IG9ZDN9hjx4n0yqaKVb9muO4seRIiwWKrVa0zREjoU5WKvZrSd2dkVydlRF At6ZNqw2LSJ+f4dklBYZBbwbExCR/rVara61hxprGFCSGRrPBiseIjPgn5Pgv6VD0N6Q6iqeMxiT RS8vpnZDVQCaVz8eWV78yDNm1NpT5GsKvEexHBjSpBZDixITlVol8lkv7K1ey9el7/4io2/0qvux uRfFjTtrlE/kPyA03rmbl1hU22swZJs7GtKy8typ090e0lYNGy6aCa3H61TECWcWP6PmMfk5hVRE fXpamAWvYVBOfHJsPt6cLdtcyLnE7HI63LZ2rNf4DguKZ9V21rnX/wBCv4IB2ErP/TuYB4l3De+a SVFHIeeK0qBH4vYioEEhaaoT0+Fa2OUPuzbYovaG1l7lntz7Orx2tFtjCdU8jNYbVxWBmgtIju0k RclwmbjorCth1NnXbCWnCy3c3ytKS3ZKCgHna5jsC2lhXoqWbSa1gchvd32Xzk5h8H8flZrvPhBt PZet9ocG+VeibC+ziHqnAcl5L4lJwfUfJ7B6iRZVlddVdrL2uKeOTKjhu6+HUxvSOcax5xQLYH1q YWwPqKUXGLd+ee0NsfjSzV2P+yry8z2p3C/jYU/FmZmmd87Mwi5rlMrG85l2V/HFQWNZYPdGfWhl S64gUMsYLYxo5SvUOl+hJBtT0lhqs2n5+lfoPbB5ecYtVZcLAtibx11ieYEcFhaG1yCKybXOko1w Eu/RUwaH1WPR7VmvjorFR35VRes32PxZ5F5LtZ3vYdmz8rahe0iRHS9vj272Mlvge2G69PjWpeTe cPEXDd7HHOT8h2vD3y4DQyTDVHq6jvabiG46jvFOhB+BvSIufcl4+YryVmcbc0JeYZMDAqpMHZmQ rSA1rbyb6krMkoRwLuLbyysq7umtGPjWBxhivMnpq5Fc1XZpifb9zrcvHyeQNoEOXEXcNiRdw5aC OR4pC0ZRRrjkQh4lLOF+qxsQNaZ/3Z+Ltm8tSeKN/bIwJ1jjZM+ftDAlaaKOeEJKsjHtyxSKY5mC xlvpJFwSnPb69wnKeXm3t44TltNjdBV4/AhZVqmHSw7CLPk4aC/saSzPfSLGxnLZWTmzqojnhZHE x5CI0aJ27ZZ5z8Fbb4s4ts28bZLkT5M7tDmtIysonMayIIwiroT6ZhZixIC3asD+2D7ot485855F x/eoMTGwsaJMjbkiR1c4yzNFKZmeR+4/7mMbqEUEvZQLAbZ+uYa7bpcZxgEfJ0+oQ3MjXQxME0hT yRxpYh+XpgkeipGh8FeqoRonP+5e6fYwfn8KRFQ3EdVskCWblICja/1GBqhzJwjN8X+CHlHCWO8b lViqxjVcisVHKvf8KMkelFqx+x8Loccr4E+pESKpZjoho5bGcVDeYSGYVj5UkysUPoKitTt3R3f7 umOp60jYdaVUGatfNiT4/ih4UkEoS/PP/aAI0jUXv5IrXK3sqKioqL2VOpWouK4ypb5sqRMkv9WR KMQ5yPnvVzyFcrnL9qIid17IidkRERERETosKLirC6pxwldWkvTFcjroI/RitKUg2RAkeoTkV6o1 xjK5Vb2RUaxU+K+SokG+VMfOvJf772t+d+mcl3jzDke4rl+mP6hyjTuqfbe4i8To2Rws13jsSzsI ES+xvbNMowSswyKOGI+f6oPq9e8SiE8YGjDDleiEEabdPWvRAp6W/OqI3D+LeKe55zJif6hHH8Th 3e9+Duh5Wl9iX9JbWuDYVfUmqsZp9sY1p1+Kw58HGc6qM9DZx4hq5jGw7yrmhG9j5zEkvrpGj51L rp+j0qvwJXJXZ/sJe3Bx+Ka8UN37khb7XeZZdTWN3Vay4y4SfK3a62JsqBBFLmVmsq3O7ywkQRFa g51XWejBaUTBJ1kmw8P5VyjMXF47t2ZmTyKxURxsQQmnWdZsll1LqJYBbi561hvK/IvAuC4su4cw 3jb9uxYdAfvTKGVpNWhe2uqQs+htChCzaTYG1Ma64U5lAnc0YGtOf+n+RmJc0dLbHveaOvLDQuac eaTJtnVmQxs6xLZfHTBaeBMwefkurslYTIWEkHpCHgxbGOgDMmI+PuLC+2byaM3Aj5Djx7btmXkJ C05kjyPbtJcR92KFywEj6YwwOkO6hit6513L72vCR23c5uJZM+777t2K88eL25cT3SRWM3ZmyYgt 4o9czKya2ijdo1a1q2A0nFbV3I3QPDGu5rYPxqzmTxO0KONrLO6TbtjgvMTeVZp7XV3P1zikqHrP J7C8i4is/HIDjVdwoCgWMQsY4TleMma7r4C4ZtevYcKfkWfyFM7GgmzBhGDbcUSZMUczPJIAHtG7 aDHLKNWkkabkaw2L7svJW9BeWZ2LxDa+JPtmblwbadxGVvGYYsOeXHSOOF2MeqeNO4JoMclNag6i oN6OBft96GWlwn3LLTZOttI5rOznJMyyYmvsB1XrDDKFq5BY4uTErK5h1sAeMNv5wwNmtEwTSw5a gRjiG+ZWt8m7xsHFN+zfCvEOFYGQVxkjinaFps6R3iWVsmMhTJIyoX0nXfWhckKpjq1eGeP8t55x fb/uQ8g+St1xFbNklnxlylxtthjiyHgTDmUyLBEskgTWDFYxSCNVLMs1L7R+fcM8E0jyhwbmdiIL TlHcZZnc+RbXeLT8ny3MTXdcEuLT9d5pGiT41O4l8QsscxkmLHkjkDloY4CJ47d5jsnlreuYcc3n xJlGLxvFjYyhI5lhhgEbETLlY5ZTJaMKhQo7KVaIojqb8+eO+R+BuPeOuYcf894An8wzZmW5llxn yMjJaWNTA+FlqjrCTOWlEokjjkV1n7ksbDTK9GcCdm5pJ4bXG4NTZLmOBbG1NsTA9qNkenW3OrsV Hc5BK1NkpZ1iaPKpLushX1fKrhtYQzIcT5ZwXMQgerZzLzZx3aI+WYnFd0x8Te8DdMXJw7XePMmM cQzYgqAiSN2ilSU3CmR+4HBKvV88d/bVy3kM/BNw5zsuZncb3TZs3E3ANZJdvx+7OdvyO45BilRZ oJYBZm7MXZMbKGjra3rbgAzTHI/RW3NZZjX1WFau0EzSuZY/PqjFyHYhYzLlQ5BJlwSw6yDLmWE6 NNkvVhO5oaMaNGu8m8z8g84HlvAN54vyLEkl3fct7OfBKrgRYoJjvEFYM7Kqq8ai4+lyS1xY9ocT +2UcB8q8d5vxHPih4/s/GxteVC8ZM2aVE37zMhWNGd3ilc/UNUIUJYgrsm65+rrKjoorB32RVWOR HS7KQjFVF9CMNhDSZJOy+LAgCwhVRzuyK9U8Gd+7lROmBegm1VeyvKp2VzmyZIngix/UZAhJCcVI 4iORXOI8j3epJKjWo9zUa1fFOzU7fGYFqiTXXiY3Pk0lnkDo5QV1ewXpkJXMYs0xZIAKyM1zkIQQ WmVziI1Wd2q3v3RUQuL2o61Hnduy9hv79l7f+OT9HTpVdGiRiUlOg+3ppV16M7J4p4JED4/h/wCH 4fd93XmfjU68lf8AqBOBbuQfM7iTtzKd9ZzrnEi69ttdYkJMxkYZg+usvqMqNcZPmrMpr4Fpb4hI yOkyStDPkwY6yjCqxfrFaNrW9G+DPFXFPIe2bvuu/wAu6Sz7V229lgrF3shJA9tDSXJYsjLpGn0O sXrkD7nPPfP/AA/u+w8f4jBsUGPvxlT+47m0/t8WSJow3cSGwCBZUfW2s/q/bOnqpdS6N47cctW8 U8ShZrrnlPxs1Dy3sybKx3MNe3GZ4Di1zuGvrbWytolzuyhkWGTlmgorywJLACLDbLEjvTV6Nf1v eDxRxTLwN84pi8VfZ96yNgbI29sqePLzHkx5GDvdJJfbszvjIYw9yrHoASK5bzPPXP8Ab9341zrc edR7/wAexOUJi7smFizbft8UWTGpjjCyRY/u1WKLNkWR47Kyr1Nlargc7Nb4zN5Zb8wbWUihtqbb 3E2DshabDpFfJgY1kekK8eS1Q1i1bnxK1T4trN4o42oz9TcJ4IjSN8rl4R3rLwfFew7hvUcmO+z8 k9kplVk1wZzdghdQF1SXLBPoDBb4qbWL7l+PYG5+c+UbVxyaLMi3/iA3J1gdZRFk7anutTaSwV5I NuYC5BYZd/8AeL4XDqzb+yJ3EXkPvPBKjaXHiwwLMdWUjNF0NXSWOupdrVX2BWR9j1B4sOXcT4rI prN6JJbCO5qrHexyrHkPkm98G4bg8q4dxzc22jmkWfBlytuUryJlaHjyUTEdSwQNdYgAhlUfrUga 0hw7jHk/yLuXBvIHMdlXf/HM+15W3xJs2PHFJhFkmwpHzo2SMuVKmckyiFyP25FJMUk+4tcTeT2D a/ZcUI+IupaqjyCfHsN45LgsXbu7LENpbtr4lcOG+HkdfSgPGnMCGOxtdKWMZvqO7r5dWPnHmLxV y/dSIpuTby80K6cCDIbBwEZI9bMxJhd2BUszN3U1A6RbpWV+NPt586+PthHusfhnHUx531bpk4ib lujrNL20VBpyokRtQRUT28mkgOb9Rba/9tziLDzbI/pNZt64pI8iZlqaUqthR42n8gyuBjIMyHVx sfiBm56yplU52DjlQrg+SpEZIR3gN2vsLz/5Rm2eD3Um1xZjKsH9wfFJzooWmMBcysVxtYcEsukN b90xkXYbV3L7VfCONyLLOBDvk+CrPkjaosxF22bJTHGUI1iVXzhG0RCo+orciFZQ2lTfm0oPIuI3 N3rXU+K1uM41XjZdy6WjsMrw6LGjX9HCrsTjEqrAkRtFJPQTAxxOb6KGdDahXq13WksbOsuViYe4 bnk5GRkMe2skiwzkmKRmnIdQ3cAyY2Yg6tIlJUXFdKZm2Evg5+4bRsmDh4eGgErRQvk4qqs8KR4y mNyvZY4UqopGjWYAJGINZaoy2ZFzX+oFyi3yht/iOPxGY3SwgriRrn+mrK4rRRJFnNjW8G7uJ9NZ emUMFkf0XsDM7GYH0qXK2uKTaPY+2ixjBlSt3ZGPfEfdRHLBFKNGiyRXVpC2oF4voLaq3A32eHkX 9097PmjKwYFGPEg9qZfbySxhWkdZUmleLIsyQiPSyx5H7ipoml1l+XZJSusdYRgzo56qkuame4QW rZnbayQX+NvNZvHCq5fybozmHIMyNb66IxXtaqWjD2rasDLEHI2KSCWSN1ufoGgGOWyXZ11awVBW /wBHWxN8g3Hft+3fbzlcNRZImghlicgfuMJGE+OTJZI20dshyrWHd+ksFIZ3zdx/Jw/wf5v+KD/j H8n/AHX9j/3X5f7nWOdrE/qn+bp/R/4/6n6vj/w/7Vmffz//AJ1/kav5g/m/0v0/D/2fD/jUVzHP 4OMo+HGYywuVanaKkgIhRPJBua+a9zlIPzETyY1rHK/t8fFF79UwF/yquqtdpb2l1KfNs5JJch3w Rz57WjE34fq44Bq0Ecfw7+LGtRV+K/FVXqfQVHrUzxGkxUijn5RkFWIX5h07LU/rO+Dk/wCvKx0Z QOY9EVBscRHJ+ZU+LekSfSmB603bi+wqxoZ9HFvaMDJMIsaKEUkYAiMqK6N4sAiem1p0av4U/wBn URe96ZqsL2mE94yD8CDe4ZGLORFYRjlY9ioru6K16Ki/2p16VHr8hT/wHP6sdOCqvJYq+RWjQIJM qSFwJURq9o7Gl80IkgDPwK1W9la1F8lVVRIEfKpD5VUv3F+PM3lJofHjYBbYsDJ9aZ/V5/UXN+yV Op/ptbFsYGR15Y0CrujWHzAZAyJFWO8cgkZg39mqqpuvwX5N27xjybLz98TJl2TM2+SCRILdwsSr Rst3jAIIK6tQKhyR1Fc1fdB4V3jzZwvA2rjMmFDyXbt2hyopMq/ZCBXSZXAjl1AhlfR22DmNVPQ1 UHC9PZzfQsgpeY2d3+18EyjVl1OxHTddhtHrbVMeRXoC9q7+grcSWqm0NxUlqlbAs4oY8pgClaRV GdyOvW7eatqwJosvxlsi7LvUOSJPfy5MmZmSrpZGimaYMHilDXkiZ3TUqkdVVhj+wfbVvm6Ys23+ aeStyTjuRiGL+1wYce37fAxZXWXHXHZNE0JXTFPHFFJoZ1Y6ZHQsXUXGLBeMmIUGx8EoqOtqdr17 MIyqyhCk2GZVVHeEMRBQMiuZU+QwjmxFecYkCEpAsEZhGo1zcC5j5Y8hc+0xco3OafFjl7qRKEii RwLBlSJV6qCQpYsy3JBBJvtXx54F8SeKy8/CNlx8bOlgMMk8jSZE8kRN2RpJ3eyuQC6oEVrKGUhQ BYfH4Ov9XTNmYrm9SlvW6xvK/KsEr5C+m2WS3iAr4kZ0QCBrjtljSAhPUCoWdnO8URvbrXjvJM3d di0jEkkkkk+pJPUk+pPWttxRxQRiGFVSFAAqqAqgDoAFFgABawAAFTfjzY47cVWa1Lqm5sLPNHWm UXgaypm0+IQOz0ZDxeothmi+EzwkqqOYo2dk8Wu7MRV9seWTHyo542COrizEBrfiQQQbfIg/lVNn 48WXgzY8yNJG8ZuoJUt0vpDAqQT8Lgj86ZNBhe1pVZhMqVNxrX1tj1bAqLepoYUWyqLmprLzFber hsUAINpUtHUQZ9eUAZ74gilVyMkieiNzHO3fjMWRmRxpkZ2LPIzo8jFHjd45kdupZHu7RyqzRhyB a8bDrrXa+Pc2nw9ummkw9rzsSFIpYoUWSKWKObGljQWVJIrRJNAyLMYlZiQsyMLT2PqXDxV8moLA YaokSczctaIYYURa3O3Ka/pzshsC6RCNJVCMVVQg3DH2d+rb1Y35RurTrlK5GUq4/wBZJZteN0ik Gq9mA6H0ILXH1Gsni4LsCYr4MkQbBZ8v9sAIvbzOs0RCgakLWZSfqUqlj9Aqbix+hBLgzw0lQGdW QvptbMFWwxy6+u7OT5CDIYFDRIXZyp6Q1az4r8OrO2dmvE8DzSmGR9bqXYqzfxML2ZvxNz+NZIm1 7ZHNHkx48C5EMfbjcRoGRP4EYC6p1P0qQPwrL9UtV1HRRVXc9p7mTl1yaNVWsgBCxlGaPRTZYXok GK1VZIFGeMvZyKiqir2VO33dTBFqib36VEPoOQfyO7/yzYf4Tp3FLrR9ByD+R3f+WbD/AAnRcUda 5MocgR7F+iXX52d++M2CJ28k791+U+HRcUdadee67kWx3XVCjFnm8fnq94oqNlP7MakkJjOAgjI1 F9RHud59k7eKovlEH0NSI+VImVWWkFe02BOhr3VE+apJEdHK1ey+DihY16Iv3oqp1LpUetPXT8qT 9Mt4JAm8AShy4z3RCxhEWSFRlEwrmIBzmvjtVURfJPPuvw6i1MUiKbGN25bm11mV3guPRm3AX4/H TM7EvoUGHlI8M+op6mtK+Qkqxgkewkko0VziPVGoj16ldQLXpdT1phVXGitgz6yPOzbJrjCKO4W7 psGmqL6dGmtK4wkkSmkVZIWPevkjRCc9HO7r+N6uWv5DrT0/5U75OC4fNu5eRzccqZt1OiRoMufN iDlvNFhkGWKJwpPqgRAlExzVRiO7savf8Kdo3NrelOwqUDGMLGCENghDajWDG1rGMan2NYxqI1rU /QnSp1z6KKOiijooo6KKOiijooo6KKOiijooo6KKxdr+xb/C/wA3/tf2P3fl/vdOivtXfuzf3H7V /h37t/y/29BorvdKijooo6KKOiijooo6KKOiijooo6KK/9k= ------=_NextPart_000_006E_01D0C533.40CA7B40-- From nobody Thu Jul 23 04:20:33 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB731A901C for ; Thu, 23 Jul 2015 04:20:31 -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, SPF_PASS=-0.001] autolearn=ham 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 An68L0dyQgpH for ; Thu, 23 Jul 2015 04:20:28 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 9B0821A8FD6 for ; Thu, 23 Jul 2015 04:20:28 -0700 (PDT) Received: by qged69 with SMTP id d69so86401468qge.0 for ; Thu, 23 Jul 2015 04:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=CWlxCQyYf7ihhyeCOtGtott215cqk0GTwatE7q8HiTc=; b=s7SHsfZkQyLuLKTDwfilGPp8c9xvA96Ruqi4tQoa1qGJZDgyjHRFMjs4iUZYGPX4zf r2PvW3Oyli6ZVrPFktQwxKZxE8eTlrGCilDPqEc0j+3BFDucqCvVbV16C1XYFJI9FlJ+ J0XH+GhDMSskcAgRLhUIt3pnSXAwBaOl0ooE/8HdvLQbDx6aSC4y3AGfKvDRoPIJkl5F dBu1GHCH9Nwk6i5eOFL+QKqPY5T+mSb/Rq5OheSV6wKplWPf5TTZAxgPeIVPsxqtRRSJ 8gF1vI9sZ2EExpf5ZQmbGs7fyfznyDyDClNmMGiOe0lZSPrPHB+kSs/26csfuJ/xfQm/ egZA== X-Received: by 10.140.147.129 with SMTP id 123mr11455638qht.79.1437650427857; Thu, 23 Jul 2015 04:20:27 -0700 (PDT) Received: from hedwig-45.prd.orcali.com (ec2-54-85-253-137.compute-1.amazonaws.com. [54.85.253.137]) by smtp.gmail.com with ESMTPSA id f189sm2197023qhe.43.2015.07.23.04.20.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 04:20:26 -0700 (PDT) Date: Thu, 23 Jul 2015 04:20:26 -0700 (PDT) X-Google-Original-Date: Thu, 23 Jul 2015 11:20:26 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1437650426719.fb5e197c@Nodemailer> In-Reply-To: <631BAC6DDB6D4602AFD2D8B8664C7479@SRA4> References: <631BAC6DDB6D4602AFD2D8B8664C7479@SRA4> X-Orchestra-Oid: 144BD026-5D95-4EAB-8857-C26D5996B897 X-Orchestra-Sig: e5263082d8b0b70b2311f18a30735bf0ea32db4a X-Orchestra-Thrid: TF6799EDC-33A1-4EA4-9687-CF1647E8820B_1507395742768512025 X-Orchestra-Thrid-Sig: 80e51ca1c498961052f490a9780348f7e4f0d067 X-Orchestra-Account: 6fe3dae890556bd4daeb23bbdbd4ecc101c2d767 From: maxpassion@gmail.com To: dickroy@alum.mit.edu Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1437650426982" Archived-At: Cc: Rex Buddenberg , =?UTF-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org Subject: Re: [geonet/its] Why not using IPv6 link local address for one hopV2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:20:31 -0000 ------Nodemailer-0.5.0-?=_1-1437650426982 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the comment=EF=BC=8C I agree with this approach. Regards=EF=BC=8C Dapeng Liu =E2=80=94 =E9=80=9A=E8=BF=87 Mailbox =E5=8F=91=E9=80=81 On Thu, Jul 23, 2015 at 10:43 AM, Richard Roy wrote: > Thanks Jerome. I could not have stated it better! >=20=20 > RR >=20=20 > =5F=5F=5F=5F=5F=20=20 > From: J=C3=A9r=C3=B4me H=C3=A4rri [mailto:jerome.haerri@eurecom.fr]=20 > Sent: Thursday, July 23, 2015 1:35 AM > To: 'Dapeng Liu'; dickroy@alum.mit.edu > Cc: 'Rex Buddenberg'; its@ietf.org > Subject: RE: [geonet/its] Why not using IPv6 link local address for one > hopV2V >=20=20 > Hi Dapeng, >=20=20 > To the risk of mentioning it again (Dick and I had a same discussion in = this > ITS group around the same time last year, please see the logs) and = again > still agree with his statement below, the true question is indeed not if = we > should use IP for one-hop V2V, but also which application would need to = have > a 1-hop V2V in IPv6.=20 >=20=20 > Both ETSI and IEEE do not rely on IP for 1-hop V2V for safety-related > communications, as simply stated: it is not required, period.=20 >=20=20 > IP is necessary for interoperability and global connectivity. So, this = group > should describe which applications would require either interoperability > between different technologies and/or global connectivity (to the cloud, > between vehicles over the cloud), and which would require direct V2V > communication (which would not be done better via the cloud/backend).=20 >=20=20 > Once we have such description, then we can discuss if we need IPv6 for = V2V > and how to make it happen. >=20=20 > There could be some of these applications, e.g. proximity/social = networking > (unsupervised LTE D2D, maybe WiFi direct, etc..), cellular traffic > offloading, to name a few=C2=85but we should really take the debate from = the > right end. >=20=20 > My two cents=C2=85 >=20=20 > Cheers, >=20=20 > J=C3=A9r=C3=B4me >=20=20 >=20=20 > -------------------------------------------------------------- > Dr. habil J=C3=A9r=C3=B4me H=C3=A4rri > Tenured Assistant Professor > Wireless Vehicular Networks > Description: Description : EURECOM=5F20ANS=5FFR=5F50 > EURECOM > 2229 Route des Cr=C3=AAtes - BP193 > 06904 SOPHIA ANTIPOLIS CEDEX > -------------------------------------------------------------------------= --- >=20=20 >=20=20 >=20=20 >=20=20 > From: its [mailto:its-bounces@ietf.org] On Behalf Of Dapeng Liu > Sent: Thursday 23 July 2015 01:05 > To: dickroy@alum.mit.edu > Cc: Rex Buddenberg; its@ietf.org > Subject: Re: [geonet/its] Why not using IPv6 link local address for one > hopV2V >=20=20 > OK. That comes to the question: should we use IP for one hop V2V. I = guess > Alex have posted a picture to explain the scenario why IP is needed.. >=20=20 > Thanks, > Dapeng Liu >=20=20 > 2015-07-23 0:33 GMT+02:00 Richard Roy : > The real question is not =22can we use IPv6 for single-hop = communications=3F=22, > the real question is =22should we use a network protocol for single-hop > communications when it is really a link-layer issue=3F=22 I think most = people > would say =22IPv6 is not necessary; MAC bridging at the data link layer = is > more than enough for this situation=22. > IPv6 carries an overhead (>39 bytes) that V2V comms, especially on the > crowded safety channel, do not need. > Cheers, > RR >> -----Original Message----- >> From: Rex Buddenberg [mailto:buddenbergr@gmail.com] >> Sent: Wednesday, July 22, 2015 9:25 AM >> To: Dapeng Liu >> Cc: its@ietf.org >> Subject: Re: [geonet/its] Why not using IPv6 link local address for one >> hopV2V >> >> The problem with physical (as opposed to logical) 'v-v' connection is >> that you have good probability of not reaching the vehicles you need to >> reach most. Like crossing traffic where the RF path is blocked by a >> building. >> Organizing unicast groups seems to me to be the logical way out. >> The group membership is likely to be very dynamic. >> >> On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote: >> > Hello all, >> > >> > >> > During the noon discussion, we were discussing whether we can use = IPv6 >> > link local address for one hop V-V IP communication. >> > >> > >> > One reason is that the vehicle that discover a neighbor with link >> > local IPv6 address can not distinguish whether that is another = vehicle >> > or it is a smart phone in the car or it is a smart phone from road >> > side passengers. >> > >> > >> > If we want to use IPv6 link local address, a dedicate prefix for V2V >> > may needed. >> > >> > >> > Any thoughts=3F >> > >> > >> > ------ >> > Best Regards, >> > Dapeng Liu >> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> > its mailing list >> > its@ietf.org >> > https://www.ietf.org/mailman/listinfo/its >> >> >=20=20 > --=20 > ------ > Best Regards, > Dapeng Liu ------Nodemailer-0.5.0-?=_1-1437650426982 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for the comment=EF=BC=8C I agree with this approach.=

Regards=EF=BC=8C
Dapeng Liu

=E2=80=94
=E9=80=9A=E8=BF=87 Mailbox =E5=8F=91=E9=80=81


On Thu, Jul 23, 2015 at 10:43 = AM, Richard Roy <dickroy@alum.mit.edu> = wrote:

Thanks Jerome.=C2=A0 I could not = have stated it better!

=C2=A0

RR

=C2=A0

From: J=C3=A9r=C3=B4me H=C3=A4rri [mailto:jerome.haerri@eurecom.fr]
Sent: Thursday, July 23, 2015 1:35 AM
To: 'Dapeng Liu'; = dickroy@alum.mit.edu
Cc:<= /b> 'Rex Buddenberg'; its@ietf.org
Subject: RE: [geonet/its] Why not using IPv6 link local address for one hopV2V

=C2=A0

Hi Dapeng,

=C2=A0

To the risk of mentioning it again (Dick and I had a same discussion in this ITS group = around the same time last=C2=A0 year, please see the logs) and again still agree = with his statement below, the true question is indeed not if we should use IP = for one-hop V2V, but also which application would need to have a 1-hop V2V in = IPv6.

=C2=A0

Both ETSI and IEEE do not rely on IP for 1-hop V2V for safety-related communications, as = simply stated: it is not required, period.

=C2=A0

IP is necessary for interoperability and global connectivity. So, this group should describe = which applications would require either interoperability between different technologies and/or global connectivity (to the cloud, between vehicles = over the cloud), and which would require direct V2V communication (which would = not be done better via the cloud/backend).

=C2=A0

Once we have such description, then we can discuss if we need IPv6 for V2V and how to make = it happen.

=C2=A0

There could be some of these applications, e.g. proximity/social networking (unsupervised LTE = D2D, maybe WiFi direct, etc..), cellular traffic offloading, to name a = few=E2=80=A6but we should really take the debate from the right end.

=C2=A0

My two cents=E2=80=A6

=C2=A0

Cheers,

=C2=A0

J=C3=A9r=C3=B4me

=C2=A0

=C2=A0

------------------------------------= --------------------------

Dr. habil J=C3=A9r=C3=B4me H=C3=A4rri

Tenured Assistant Professor

Wireless Vehicular Networks

<image001.= jpg>

EURECOM

2229 Route des Cr=C3=AAtes - BP193

06904 SOPHIA ANTIPOLIS CEDEX

-------------------------------------------------------------= ---------------

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: its [mailto:its-bounces@ietf.org] On = Behalf Of Dapeng Liu
Sent: Thursday 23= July 2015 01:05
To: = dickroy@alum.mit.edu
Cc:<= /b> Rex Buddenberg; its@ietf.org
Subject: Re: [geonet/its] Why not using IPv6 link local address for one hopV2V

=C2=A0

OK. That comes to the question: should we use IP for one hop V2V.= I guess Alex have posted a picture to explain the scenario why IP is needed..=

=C2=A0

Thanks,

Dapeng Liu

=C2=A0

2015-07-23 0:33 GMT+02:00 Richard Roy <dickroy@alum.mit.= edu>:

The real question is not =22can we use IPv6 for single-hop communications=3F=22,
the real question is =22should we use a network protocol for = single-hop
communications when it is really a link-layer issue=3F=22=C2=A0 I think = most people
would say =22IPv6 is not necessary; MAC bridging at the data link layer = is
more than enough for this situation=22.

IPv6 carries an overhead (>39 bytes) that V2V comms, especially on = the
crowded safety channel, do not need.

Cheers,

RR


> -----Original Message-----
> From: Rex Buddenberg [mailto:buddenbergr@gmail.com]
> Sent: Wednesday, July 22, 2015 9:25 AM
> To: Dapeng Liu
> Cc: its@ietf.org
> Subject: Re: [geonet/its] Why not using IPv6 link local address for = one
> hopV2V
>
> The problem with physical (as opposed to logical) 'v-v' connection = is
> that you have good probability of not reaching the vehicles you need = to
> reach most.=C2=A0 Like crossing traffic where the RF path is blocked = by a
> building.
>=C2=A0 =C2=A0 =C2=A0 Organizing unicast groups seems to me to be the logical way out.
> The group membership is likely to be very dynamic.
>
> On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote:
> > Hello all,
> >
> >
> > During the noon discussion, we were discussing whether we can = use IPv6
> > link local address for one hop V-V IP communication.
> >
> >
> > One reason is that the vehicle that discover a neighbor with = link
> > local IPv6 address can not distinguish whether that is another vehicle
> > or it is a smart phone in the car or it is a smart phone from = road
> > side passengers.
> >
> >
> > If we want to use IPv6 link local address, a dedicate prefix for = V2V
> > may needed.
> >
> >
> > Any thoughts=3F
> >
> >
> > ------
> > Best Regards,
> > Dapeng Liu
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> > its mailing list
> > its@ietf.org
> > https:/= /www.ietf.org/mailman/listinfo/its
>
>



=C2=A0

--


------
Best Regards,
Dapeng Liu


------Nodemailer-0.5.0-?=_1-1437650426982-- From nobody Thu Jul 23 05:25:28 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34801A0BE8 for ; Thu, 23 Jul 2015 05:25:25 -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, SPF_PASS=-0.001] autolearn=ham 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 iEhZBoT3jy98 for ; Thu, 23 Jul 2015 05:25:23 -0700 (PDT) Received: from mail-vn0-x234.google.com (mail-vn0-x234.google.com [IPv6:2607:f8b0:400c:c0f::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 98B811A92F8 for ; Thu, 23 Jul 2015 05:25:17 -0700 (PDT) Received: by vnds125 with SMTP id s125so59611084vnd.1 for ; Thu, 23 Jul 2015 05:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=36k8vW5CIKL+ZvQw+SW6UzzBnVS4Wbi4sw5S+9/S2uo=; b=wlx8bwt3wt0HZo6q8oqrgTIqsLv1ZRL0WD2bDq694U245gXKgsM5CdG+Nuz4/DbX6z clLYT8MEgrglIr/KgYihpSLlAqZHY+ii31RD9PXMk1Ck77Okp4+DEmdaJaEBZlzydggy UnvDvhouyp8c/EquZCMzl3rqPaQXz9qb/bk17WrJLu1sWBuhLgJ74OUmktkWxlwjJuZf +ENfRwYoGyaqXQdJ+dk8K1tRqNmFVe0Q9jvJvoMLtjhae2PVTA74dhrdhzQCp16muEp4 AL36LlvSopCuogEDASKmOQ7q4v/RjL9671YuhiN+DLVzk7QZOWsh3efEAuEJqNjGUQ+3 dA2A== MIME-Version: 1.0 X-Received: by 10.52.176.131 with SMTP id ci3mr9247239vdc.72.1437654316856; Thu, 23 Jul 2015 05:25:16 -0700 (PDT) Received: by 10.31.178.145 with HTTP; Thu, 23 Jul 2015 05:25:16 -0700 (PDT) In-Reply-To: References: <1437582310.1975.212.camel@localhost.localdomain> Date: Thu, 23 Jul 2015 14:25:16 +0200 Message-ID: From: Dapeng Liu To: dickroy@alum.mit.edu Content-Type: multipart/alternative; boundary=bcaec5196a6fddbc54051b89fa34 Archived-At: Cc: Rex Buddenberg , "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hopV2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:25:26 -0000 --bcaec5196a6fddbc54051b89fa34 Content-Type: text/plain; charset=UTF-8 This one: https://mailarchive.ietf.org/arch/msg/its/APoKCskywm6sEVSo2g7RjuRH15E 2015-07-23 1:29 GMT+02:00 Richard Roy : > > > > ------------------------------ > > *From:* Dapeng Liu [mailto:maxpassion@gmail.com] > *Sent:* Wednesday, July 22, 2015 4:05 PM > *To:* dickroy@alum.mit.edu > *Cc:* Rex Buddenberg; its@ietf.org > *Subject:* Re: [geonet/its] Why not using IPv6 link local address for one > hopV2V > > > > OK. That comes to the question: should we use IP for one hop V2V. I guess > Alex have posted a picture to explain the scenario why IP is needed.. > > *[RR>] Not sure I've seen that posting. Perhaps Alex could re-post it??* > > > > Thanks, > > Dapeng Liu > > > > 2015-07-23 0:33 GMT+02:00 Richard Roy : > > The real question is not "can we use IPv6 for single-hop communications?", > the real question is "should we use a network protocol for single-hop > communications when it is really a link-layer issue?" I think most people > would say "IPv6 is not necessary; MAC bridging at the data link layer is > more than enough for this situation". > > IPv6 carries an overhead (>39 bytes) that V2V comms, especially on the > crowded safety channel, do not need. > > Cheers, > > RR > > > > -----Original Message----- > > From: Rex Buddenberg [mailto:buddenbergr@gmail.com] > > Sent: Wednesday, July 22, 2015 9:25 AM > > To: Dapeng Liu > > Cc: its@ietf.org > > Subject: Re: [geonet/its] Why not using IPv6 link local address for one > > hopV2V > > > > The problem with physical (as opposed to logical) 'v-v' connection is > > that you have good probability of not reaching the vehicles you need to > > reach most. Like crossing traffic where the RF path is blocked by a > > building. > > Organizing unicast groups seems to me to be the logical way out. > > The group membership is likely to be very dynamic. > > > > On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote: > > > Hello all, > > > > > > > > > During the noon discussion, we were discussing whether we can use IPv6 > > > link local address for one hop V-V IP communication. > > > > > > > > > One reason is that the vehicle that discover a neighbor with link > > > local IPv6 address can not distinguish whether that is another vehicle > > > or it is a smart phone in the car or it is a smart phone from road > > > side passengers. > > > > > > > > > If we want to use IPv6 link local address, a dedicate prefix for V2V > > > may needed. > > > > > > > > > Any thoughts? > > > > > > > > > ------ > > > Best Regards, > > > Dapeng Liu > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > > > -- > > > ------ > Best Regards, > Dapeng Liu > -- ------ Best Regards, Dapeng Liu --bcaec5196a6fddbc54051b89fa34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <= div class=3D"gmail_extra">
2015-07-23 1:29 GM= T+02:00 Richard Roy <dickroy@alum.mit.edu>:

=C2=A0

=C2=A0

From: Dapeng Liu [mailto:maxpassio= n@gmail.com]
Sent: Wednesday, July 22, 20= 15 4:05 PM
To: dickroy@alum.mit.edu Cc: Rex Buddenberg; its@ietf.org
Subject: Re: [geonet/its] Wh= y not using IPv6 link local address for one hopV2V=

=C2=A0

OK. That comes to the question: should we use IP for= one hop V2V. I guess Alex have posted a picture to explain the scenario why IP is needed..=

[RR>] Not sure I've seen that posting.=C2=A0 = Perhaps Alex could re-post it??<= u>

=C2=A0

Thanks,

Dapeng Liu

=C2=A0

2015-07-23 0:33 GMT+02:00 Richard Roy <dickroy@alum.mit.edu>= ;:

The real question is not "can we use IPv6 for s= ingle-hop communications?",
the real question is "should we use a network protocol for single-hop<= br> communications when it is really a link-layer issue?"=C2=A0 I think mo= st people
would say "IPv6 is not necessary; MAC bridging at the data link layer = is
more than enough for this situation".

IPv6 carries an overhead (>39 bytes) that V2V comms, especially on the crowded safety channel, do not need.

Cheers,

RR


> -----Original Message-----
> From: Rex Buddenberg [mailto:buddenbergr@gmail.com]
> Sent: Wednesday, July 22, 2015 9:25 AM
> To: Dapeng Liu
> Cc: its@ietf.org=
> Subject: Re: [geonet/its] Why not using IPv6 link local address for on= e
> hopV2V
>
> The problem with physical (as opposed to logical) 'v-v' connec= tion is
> that you have good probability of not reaching the vehicles you need t= o
> reach most.=C2=A0 Like crossing traffic where the RF path is blocked b= y a
> building.
>=C2=A0 =C2=A0 =C2=A0 Organizing unicast groups seems to me to be the logical way out.
> The group membership is likely to be very dynamic.
>
> On Wed, 2015-07-22 at 13:30 +0200, Dapeng Liu wrote:
> > Hello all,
> >
> >
> > During the noon discussion, we were discussing whether we can use IPv6
> > link local address for one hop V-V IP communication.
> >
> >
> > One reason is that the vehicle that discover a neighbor with link=
> > local IPv6 address can not distinguish whether that is another vehicle
> > or it is a smart phone in the car or it is a smart phone from roa= d
> > side passengers.
> >
> >
> > If we want to use IPv6 link local address, a dedicate prefix for = V2V
> > may needed.
> >
> >
> > Any thoughts?
> >
> >
> > ------
> > Best Regards,
> > Dapeng Liu
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>
>



=C2=A0

--


------
Best Regards,
Dapeng Liu




--

------
Best Regards,
Dapeng Liu
--bcaec5196a6fddbc54051b89fa34-- From nobody Thu Jul 23 15:40:31 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23F41A1B6D for ; Thu, 23 Jul 2015 15:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, FSL_MY_NAME_IS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ghkB7PqBTZCU for ; Thu, 23 Jul 2015 15:40:28 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 CDA551A1A69 for ; Thu, 23 Jul 2015 15:40:27 -0700 (PDT) Received: by ykax123 with SMTP id x123so5941220yka.1 for ; Thu, 23 Jul 2015 15:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8zyQ5pSBk4YHr0GOylHiHA6PRHhOF/JLjmRyEzNf3xU=; b=DIWoZJwUMM9h+ijEB+N3zp6sfEG7BqJOUmySJkGvyrku+dT2etfYHzwE+QqOgAln1p HHkUR7H7YZ4hdzIcpBN75/BGp+YHywzNangKUUFVFNVcWDpD2HSV2Ep+svU0YBihWNvo s1LrDglcFFLrjatwqGBRKohCO0htu/rmui9/miPhVEwLCrkVRsHcNiClyPGaVpIIOs+J fNc1erDMGmELpXygCql726DssKjdpSXBRnUdLgBtoCCBAC5N60EajzPs0yp+pWIb6JBm qWH6Q05ZjrreWqWJRqAzpsWsZWUk8AZ6+2bY7pW2YfgU+A41jzzVMx2m5hLvbqkRGEDX ZTDQ== MIME-Version: 1.0 X-Received: by 10.170.134.140 with SMTP id a134mr11473643ykc.19.1437691227069; Thu, 23 Jul 2015 15:40:27 -0700 (PDT) Received: by 10.129.84.4 with HTTP; Thu, 23 Jul 2015 15:40:27 -0700 (PDT) Date: Fri, 24 Jul 2015 00:40:27 +0200 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: its@ietf.org Content-Type: multipart/alternative; boundary=001a1139797ee303c5051b9292e6 Archived-At: Subject: [geonet/its] Request for Meeting X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 22:40:29 -0000 --001a1139797ee303c5051b9292e6 Content-Type: text/plain; charset=UTF-8 Hi Geonet/ITS buddy, My name is Paul Jeong, a faculty member at Sungkyunkwan University in South Korea. I heard your activity for ITS and VANET research at IETF. I have much interest in this group because my lab research is focused on vehicular MAC protocols, data forwarding, safety driving, and navigation. If some of you related to this group are still staying in the IETF93 venue, I would like to meet you and discuss how to contribute to the activity of this group. Please let me know when and where I can meet you this Friday. Thanks. Paul -- =========================== 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://cpslab.skku.edu/people-jaehoon-jeong.php --001a1139797ee303c5051b9292e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Geonet/ITS buddy,
My name is Paul Jeong, a faculty = member at Sungkyunkwan University in South Korea.

= I heard your activity for ITS and VANET research at IETF.
I have = much interest in this group because my lab research is focused on
vehicular MAC protocols, data forwarding, safety driving, and navigation.<= /div>

If some of you related to this group are still sta= ying in the IETF93 venue,
I would like to meet you and discuss ho= w to contribute to the activity of this group.
Please let me know= when and where I can meet you this Friday.

Th= anks.

Paul
--
=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 Software
Sungkyun= kwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://cpsl= ab.skku.edu/people-jaehoon-jeong.php
--001a1139797ee303c5051b9292e6-- From nobody Thu Jul 23 21:54:13 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577DA1B2DC9 for ; Thu, 23 Jul 2015 21:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.982 X-Spam-Level: X-Spam-Status: No, score=-3.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, FSL_MY_NAME_IS=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 rYb5tPGsweBS for ; Thu, 23 Jul 2015 21:54:08 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DB61B2DC1 for ; Thu, 23 Jul 2015 21:54:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6O4s6B2031047 for ; Fri, 24 Jul 2015 06:54:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 291CA200FFC for ; Fri, 24 Jul 2015 06:57:44 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 19524200E31 for ; Fri, 24 Jul 2015 06:57:44 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6O4s4au001769 for ; Fri, 24 Jul 2015 06:54:05 +0200 To: its@ietf.org References: From: Alexandru Petrescu Message-ID: <55B1C4EC.10508@gmail.com> Date: Fri, 24 Jul 2015 06:54:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] Request for Meeting X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 04:54:10 -0000 At 12h at the IETF Registration Desk. Alex Le 24/07/2015 00:40, Mr. Jaehoon Paul Jeong a écrit : > Hi Geonet/ITS buddy, > My name is Paul Jeong, a faculty member at Sungkyunkwan University in > South Korea. > > I heard your activity for ITS and VANET research at IETF. > I have much interest in this group because my lab research is focused on > vehicular MAC protocols, data forwarding, safety driving, and navigation. > > If some of you related to this group are still staying in the IETF93 venue, > I would like to meet you and discuss how to contribute to the activity > of this group. > Please let me know when and where I can meet you this Friday. > > Thanks. > > Paul > -- > =========================== > 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://cpslab.skku.edu/people-jaehoon-jeong.php > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Jul 23 22:06:29 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAAF1B2DEA for ; Thu, 23 Jul 2015 22:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, FSL_MY_NAME_IS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 60zejc0sMePg for ; Thu, 23 Jul 2015 22:06:26 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::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 05BBF1B2DE1 for ; Thu, 23 Jul 2015 22:06:26 -0700 (PDT) Received: by ykax123 with SMTP id x123so11516547yka.1 for ; Thu, 23 Jul 2015 22:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wdw0TVkDe3SOGJu4sPbUjUP8GOih03tsB1kzKibSlOo=; b=d+iKtFAXKAvQQpqqtJDd73vRjhB8dN0gMsfDu5GuWu2waXRySaUSYyi0EZbir92EsV rUVLSUg8pJTvgTj0eZ/OUdPTrEiAewgH2Hsjr2S3kVGSdJUbpH0hyLxlB5/Fd09Im+6b zjggZGySLie+EJ9uOB1T7C4Kmr6s46ejak+c0Y/wYotwvbCSEuNIDWF5sfG2vrt78CVO 2cOa2A4oPGj6KrH2OuOadp1zHUFoITCFfLWfXXEU608jDSA5YWrkZn1LIhdfMMVVBHkZ 3pn0627tYxOTYn0VHGr+FOLpi5uNVjtcgNN3mRQ6kpes7SasLUznKKEi941jHYj9wG8+ Vfcw== MIME-Version: 1.0 X-Received: by 10.13.214.198 with SMTP id y189mr12858377ywd.30.1437714385415; Thu, 23 Jul 2015 22:06:25 -0700 (PDT) Received: by 10.129.84.4 with HTTP; Thu, 23 Jul 2015 22:06:25 -0700 (PDT) In-Reply-To: <55B1C4EC.10508@gmail.com> References: <55B1C4EC.10508@gmail.com> Date: Fri, 24 Jul 2015 07:06:25 +0200 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=94eb2c0767f03b3393051b97f7e3 Archived-At: Cc: its@ietf.org Subject: Re: [geonet/its] Request for Meeting X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:06:28 -0000 --94eb2c0767f03b3393051b97f7e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, Sure, let's meet at 12h at IETF registration desk. Other people are welcomed. Thanks. Paul On Fri, Jul 24, 2015 at 6:54 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > At 12h at the IETF Registration Desk. > > Alex > > Le 24/07/2015 00:40, Mr. Jaehoon Paul Jeong a =C3=A9crit : > >> Hi Geonet/ITS buddy, >> My name is Paul Jeong, a faculty member at Sungkyunkwan University in >> South Korea. >> >> I heard your activity for ITS and VANET research at IETF. >> I have much interest in this group because my lab research is focused on >> vehicular MAC protocols, data forwarding, safety driving, and navigation= . >> >> If some of you related to this group are still staying in the IETF93 >> venue, >> I would like to meet you and discuss how to contribute to the activity >> of this group. >> Please let me know when and where I can meet you this Friday. >> >> Thanks. >> >> Paul >> -- >> =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 Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com , >> pauljeong@skku.edu >> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php >> >> >> _______________________________________________ >> 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 > --=20 =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 Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php --94eb2c0767f03b3393051b97f7e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex,
Sure, let's meet at 12h at IETF registrat= ion desk.

Other people are welcomed.
Thanks.

Paul

On Fri, Jul 24, 2015 at 6:54 AM= , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
At 12h at the IETF Registration= Desk.

Alex

Le 24/07/2015 00:40, Mr. Jaehoon Paul Jeong a =C3=A9crit :
Hi Geonet/ITS buddy,
My name is Paul Jeong, a faculty member at Sungkyunkwan University in
South Korea.

I heard your activity for ITS and VANET research at IETF.
I have much interest in this group because my lab research is focused on vehicular MAC protocols, data forwarding, safety driving, and navigation.
If some of you related to this group are still staying in the IETF93 venue,=
I would like to meet you and discuss how to contribute to the activity
of this group.
Please let me know when and where I can meet you this Friday.

Thanks.

Paul
--
=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 Software
Sungkyunkwan University
Office: +82-31-299-4957
 Email: jaehoon.= paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
pauljeong@skku.edu<= /a> <mailto:paul= jeong@skku.edu>
Personal Homepage: http://cpslab.skku.edu/people-jaeh= oon-jeong.php


 _______________________________________________
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



--
=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. J= aehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software=
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
<= /div>
--94eb2c0767f03b3393051b97f7e3-- From nobody Fri Jul 24 03:42:01 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6D91A8A05 for ; Fri, 24 Jul 2015 03:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FOLXRzqJEpic for ; Fri, 24 Jul 2015 03:41:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B801A036E for ; Fri, 24 Jul 2015 03:41:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVN56799; Fri, 24 Jul 2015 10:41:56 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 24 Jul 2015 11:41:55 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.213]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Fri, 24 Jul 2015 18:41:52 +0800 From: "Huangjing (A)" To: Alexandru Petrescu Thread-Topic: [geonet/its] Why not using IPv6 link local address for one hop V2V Thread-Index: AQHQxI1fufkB0OXv+UuwlvWtvN0+ZZ3qcJOw Date: Fri, 24 Jul 2015 10:41:51 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC67470C3D@SZXEMA501-MBX.china.huawei.com> References: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> <55AFACEE.5010408@gmail.com> In-Reply-To: <55AFACEE.5010408@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.97.173] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:42:01 -0000 Agree, link local address is not sufficient for V2V communication. But, if we consider only 1-hop communication, it is probably sufficient. James > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Wednesday, July 22, 2015 10:47 PM > To: its@ietf.org > Subject: Re: [geonet/its] Why not using IPv6 link local address for one h= op V2V >=20 > I tend to agree. Just that I dont think we need another kind of addresse= s. >=20 > In other words: yes, just using LL addresses to realize V2V communication= is > not enough. no, in that messages between routers can be sourced just by > their link-local addresses. >=20 > Or maybe a prefix between vehicles would be needed. >=20 > The creation of IP addresses _inside_ vehicles is currently a problem as = well. >=20 > Alex >=20 > Le 22/07/2015 16:14, Dapeng Liu a =E9crit : > > Sure. My point is we can not just use IPv6 link local address to > > fulfill the requirement. agree? > > > > Thanks, > > Dapeng Liu > > > > 2015-07-22 15:16 GMT+02:00 Huangjing (A) > >: > > > > Hi, Dapeng,____ > > > > __ __ > > > > Maybe we can distinguish a vehicle from a mobile by other means, > > rather than IP prefix / address.____ > > > > For message broadcast (e.g. safety related message), we may require > > a dedicated multicast address; for Unicast communication, I think w= e > > should make use of higher level information, such as TCP/UDP(or > > similar one) port or application level information____ > > > > __ __ > > > > Any thoughts?____ > > > > __ __ > > > > James____ > > > > __ __ > > > > *From:*its [mailto:its-bounces@ietf.org > > ] *On Behalf Of *Dapeng Liu > > *Sent:* Wednesday, July 22, 2015 7:30 PM > > *To:* its@ietf.org > > *Subject:* [geonet/its] Why not using IPv6 link local address for > > one hop V2V____ > > > > __ __ > > > > Hello all,____ > > > > __ __ > > > > During the noon discussion, we were discussing whether we can use > > IPv6 link local address for one hop V-V IP communication.____ > > > > __ __ > > > > One reason is that the vehicle that discover a neighbor with link > > local IPv6 address can not distinguish whether that is another > > vehicle or it is a smart phone in the car or it is a smart phone > > from road side passengers. > > ____ > > > > __ __ > > > > If we want to use IPv6 link local address, a dedicate prefix for V2= V > > may needed.____ > > > > __ __ > > > > Any thoughts?____ > > > > __ __ > > > > > > ------ > > Best Regards, > > Dapeng Liu____ > > > > > > > > > > -- > > > > ------ > > Best Regards, > > Dapeng Liu > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Jul 24 12:09:37 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701A51A9055 for ; Fri, 24 Jul 2015 12:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 7XYaIdnfLFLH for ; Fri, 24 Jul 2015 12:09:33 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C051A8AF8 for ; Fri, 24 Jul 2015 12:09:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6OJ9PX3031392; Fri, 24 Jul 2015 21:09:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A36EB2058DF; Fri, 24 Jul 2015 21:13:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9656720586C; Fri, 24 Jul 2015 21:13:03 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.57]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6OJ9OwI026841; Fri, 24 Jul 2015 21:09:24 +0200 To: "Huangjing (A)" References: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> <55AFACEE.5010408@gmail.com> <774B240D54DAB844B37EE80C2DD8E8BC67470C3D@SZXEMA501-MBX.china.huawei.com> From: Alexandru Petrescu Message-ID: <55B28D64.8060002@gmail.com> Date: Fri, 24 Jul 2015 21:09:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <774B240D54DAB844B37EE80C2DD8E8BC67470C3D@SZXEMA501-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 19:09:35 -0000 Maybe the terminology should change from 1-hop to 1-variable-hop and n stable hops (the Ethernets in the cars). Not sure what name to give to this: n-stable-hops plus 1 variable hop. That's the structure in V2V. Alex Le 24/07/2015 12:41, Huangjing (A) a écrit : > Agree, link local address is not sufficient for V2V communication. > But, if we consider only 1-hop communication, it is probably sufficient. > > James > >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Wednesday, July 22, 2015 10:47 PM >> To: its@ietf.org >> Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V >> >> I tend to agree. Just that I dont think we need another kind of addresses. >> >> In other words: yes, just using LL addresses to realize V2V communication is >> not enough. no, in that messages between routers can be sourced just by >> their link-local addresses. >> >> Or maybe a prefix between vehicles would be needed. >> >> The creation of IP addresses _inside_ vehicles is currently a problem as well. >> >> Alex >> >> Le 22/07/2015 16:14, Dapeng Liu a écrit : >>> Sure. My point is we can not just use IPv6 link local address to >>> fulfill the requirement. agree? >>> >>> Thanks, >>> Dapeng Liu >>> >>> 2015-07-22 15:16 GMT+02:00 Huangjing (A) >> >: >>> >>> Hi, Dapeng,____ >>> >>> __ __ >>> >>> Maybe we can distinguish a vehicle from a mobile by other means, >>> rather than IP prefix / address.____ >>> >>> For message broadcast (e.g. safety related message), we may require >>> a dedicated multicast address; for Unicast communication, I think we >>> should make use of higher level information, such as TCP/UDP(or >>> similar one) port or application level information____ >>> >>> __ __ >>> >>> Any thoughts?____ >>> >>> __ __ >>> >>> James____ >>> >>> __ __ >>> >>> *From:*its [mailto:its-bounces@ietf.org >>> ] *On Behalf Of *Dapeng Liu >>> *Sent:* Wednesday, July 22, 2015 7:30 PM >>> *To:* its@ietf.org >>> *Subject:* [geonet/its] Why not using IPv6 link local address for >>> one hop V2V____ >>> >>> __ __ >>> >>> Hello all,____ >>> >>> __ __ >>> >>> During the noon discussion, we were discussing whether we can use >>> IPv6 link local address for one hop V-V IP communication.____ >>> >>> __ __ >>> >>> One reason is that the vehicle that discover a neighbor with link >>> local IPv6 address can not distinguish whether that is another >>> vehicle or it is a smart phone in the car or it is a smart phone >>> from road side passengers. >>> ____ >>> >>> __ __ >>> >>> If we want to use IPv6 link local address, a dedicate prefix for V2V >>> may needed.____ >>> >>> __ __ >>> >>> Any thoughts?____ >>> >>> __ __ >>> >>> >>> ------ >>> Best Regards, >>> Dapeng Liu____ >>> >>> >>> >>> >>> -- >>> >>> ------ >>> Best Regards, >>> Dapeng Liu >>> >>> >>> _______________________________________________ >>> 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 Fri Jul 24 13:50:13 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC061A0046 for ; Fri, 24 Jul 2015 13:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Uft2z4Z0MosC for ; Fri, 24 Jul 2015 13:50:09 -0700 (PDT) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id AE91C1A896C for ; Fri, 24 Jul 2015 13:50:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id BFC752323FD; Fri, 24 Jul 2015 22:50:07 +0200 (CEST) Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jtvTje72x08J; Fri, 24 Jul 2015 22:50:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id DBBCF2323FE; Fri, 24 Jul 2015 22:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rNn-eclQAqOH; Fri, 24 Jul 2015 22:50:06 +0200 (CEST) Received: from 2a02-8420-4cc2-4400-4999-79fa-5085-0cb9.rev.sfr.net (passerelle-interne.enst-bretagne.fr [192.108.117.210]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 54FC02323FD; Fri, 24 Jul 2015 22:50:06 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_113A69AE-A26C-4A30-8894-B1781EDCD818" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Jean-Marie BONNIN In-Reply-To: <55B28D64.8060002@gmail.com> Date: Fri, 24 Jul 2015 22:50:05 +0200 Message-Id: References: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> <55AFACEE.5010408@gmail.com> <774B240D54DAB844B37EE80C2DD8E8BC67470C3D@SZXEMA501-MBX.china.huawei.com> <55B28D64.8060002@gmail.com> To: "its@ietf.org" X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 20:50:11 -0000 --Apple-Mail=_113A69AE-A26C-4A30-8894-B1781EDCD818 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dick If an application always need only one hop and it is alway deployed in = the same manner in the car, probably we can use only link layer = technologies to address and transport application data. But the same = application could some time use one-hop and another time use multi-hop = communications =85 of course we could manage this in an intermediate = layer such as the ETSI facilities but it becomes more complex. It could = be simpler for the applications to always use IP.=20 If the concern is just about the overhead due to the IP header, is could = be reduce a lot using header compression technics.=20 JM > Le 24 juil. 2015 =E0 21:09, Alexandru Petrescu = a =E9crit : >=20 > Maybe the terminology should change from 1-hop to 1-variable-hop and n = stable hops (the Ethernets in the cars). >=20 > Not sure what name to give to this: n-stable-hops plus 1 variable hop. >=20 > That's the structure in V2V. >=20 > Alex >=20 > Le 24/07/2015 12:41, Huangjing (A) a =E9crit : >> Agree, link local address is not sufficient for V2V communication. >> But, if we consider only 1-hop communication, it is probably = sufficient. >>=20 >> James >>=20 >>> -----Original Message----- >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru = Petrescu >>> Sent: Wednesday, July 22, 2015 10:47 PM >>> To: its@ietf.org >>> Subject: Re: [geonet/its] Why not using IPv6 link local address for = one hop V2V >>>=20 >>> I tend to agree. Just that I dont think we need another kind of = addresses. >>>=20 >>> In other words: yes, just using LL addresses to realize V2V = communication is >>> not enough. no, in that messages between routers can be sourced = just by >>> their link-local addresses. >>>=20 >>> Or maybe a prefix between vehicles would be needed. >>>=20 >>> The creation of IP addresses _inside_ vehicles is currently a = problem as well. >>>=20 >>> Alex >>>=20 >>> Le 22/07/2015 16:14, Dapeng Liu a =E9crit : >>>> Sure. My point is we can not just use IPv6 link local address to >>>> fulfill the requirement. agree? >>>>=20 >>>> Thanks, >>>> Dapeng Liu >>>>=20 >>>> 2015-07-22 15:16 GMT+02:00 Huangjing (A) >>> >: >>>>=20 >>>> Hi, Dapeng,____ >>>>=20 >>>> __ __ >>>>=20 >>>> Maybe we can distinguish a vehicle from a mobile by other = means, >>>> rather than IP prefix / address.____ >>>>=20 >>>> For message broadcast (e.g. safety related message), we may = require >>>> a dedicated multicast address; for Unicast communication, I = think we >>>> should make use of higher level information, such as TCP/UDP(or >>>> similar one) port or application level information____ >>>>=20 >>>> __ __ >>>>=20 >>>> Any thoughts?____ >>>>=20 >>>> __ __ >>>>=20 >>>> James____ >>>>=20 >>>> __ __ >>>>=20 >>>> *From:*its [mailto:its-bounces@ietf.org >>>> ] *On Behalf Of *Dapeng Liu >>>> *Sent:* Wednesday, July 22, 2015 7:30 PM >>>> *To:* its@ietf.org >>>> *Subject:* [geonet/its] Why not using IPv6 link local address = for >>>> one hop V2V____ >>>>=20 >>>> __ __ >>>>=20 >>>> Hello all,____ >>>>=20 >>>> __ __ >>>>=20 >>>> During the noon discussion, we were discussing whether we can = use >>>> IPv6 link local address for one hop V-V IP communication.____ >>>>=20 >>>> __ __ >>>>=20 >>>> One reason is that the vehicle that discover a neighbor with = link >>>> local IPv6 address can not distinguish whether that is another >>>> vehicle or it is a smart phone in the car or it is a smart = phone >>>> from road side passengers. >>>> ____ >>>>=20 >>>> __ __ >>>>=20 >>>> If we want to use IPv6 link local address, a dedicate prefix = for V2V >>>> may needed.____ >>>>=20 >>>> __ __ >>>>=20 >>>> Any thoughts?____ >>>>=20 >>>> __ __ >>>>=20 >>>>=20 >>>> ------ >>>> Best Regards, >>>> Dapeng Liu____ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>=20 >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its ---------------------------- Prof. Jean-Marie BONNIN Institut Mines T=E9l=E9com / T=E9l=E9com Bretagne IRISA / D2 / OCIF Head of Telecom Bretagne / RSM department (Network, Security and = Multimedia) Head of IRISA / D2 (Network, Telecommunication and Services) Mob: +33 660 767 976 --Apple-Mail=_113A69AE-A26C-4A30-8894-B1781EDCD818 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Dick

If an application always need only one = hop and it is alway deployed in the same manner in the car, probably we = can use only link layer technologies to address and transport = application data. But the same application could some time use one-hop = and another time use multi-hop communications =85 of course we could = manage this in an intermediate layer such as the ETSI facilities but it = becomes more complex. It could be simpler for the applications to always = use IP. 

If= the concern is just about the overhead due to the IP header, is could = be reduce a lot using header compression technics. 

JM

Le = 24 juil. 2015 =E0 21:09, Alexandru Petrescu <alexandru.petrescu@gmail.com> a =E9crit :

Maybe the = terminology should change from 1-hop to 1-variable-hop and n stable hops = (the Ethernets in the cars).

Not sure what = name to give to this: n-stable-hops plus 1 variable hop.
That's the structure in V2V.

Alex

Le 24/07/2015 12:41, = Huangjing (A) a =E9crit :
Agree, link local address is not sufficient for V2V = communication.
But, if we consider only 1-hop = communication, it is probably sufficient.

James

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru = Petrescu
Sent: Wednesday, July 22, 2015 10:47 PM
To: its@ietf.org
Subject: Re: [geonet/its] Why = not using IPv6 link local address for one hop V2V

I tend to agree.  Just that I dont think we need another = kind of addresses.

In other words: yes, = just using LL addresses to realize V2V communication is
not = enough.  no, in that messages between routers can be sourced just = by
their link-local addresses.

Or maybe a prefix between vehicles would be needed.

The creation of IP addresses _inside_ vehicles = is currently a problem as well.

Alex

Le 22/07/2015 16:14, Dapeng Liu a =E9crit :
Sure. My point is we can = not just use IPv6 link local address to
fulfill the = requirement.  agree?

Thanks,
Dapeng Liu

2015-07-22 15:16 = GMT+02:00 Huangjing (A) <james.huang@huawei.com
<mailto:james.huang@huawei.com>>:

    Hi, Dapeng,____

    __ __

=     Maybe we can distinguish a vehicle from a mobile = by other means,
    rather than IP = prefix / address.____

=     For message broadcast (e.g. safety related = message), we may require
    a = dedicated multicast address; for Unicast communication, I think we
    should make use of higher level = information, such as TCP/UDP(or
=     similar one) port or application level = information____

    __ = __

    Any = thoughts?____

    __ = __

    James____

    __ __
    *From:*its [mailto:its-bounces@ietf.org
=     <mailto:its-bounces@ietf.org>] *On Behalf Of *Dapeng = Liu
    *Sent:* Wednesday, July 22, = 2015 7:30 PM
    *To:* its@ietf.org <mailto:its@ietf.org>
    *Subject:* [geonet/its] Why not = using IPv6 link local address for
=     one hop V2V____

=     __ __

=     Hello all,____

=     __ __

=     During the noon discussion, we were discussing = whether we can use
    IPv6 link = local address for one hop V-V IP communication.____

    __ __

=     One reason is that the vehicle that discover a = neighbor with link
    local IPv6 = address can not distinguish whether that is another
=     vehicle or it is a smart phone in the car or it = is a smart phone
    from road side = passengers.
    ____

    __ __

=     If we want to use IPv6 link local address, a = dedicate prefix for V2V
    may = needed.____

    __ = __

    Any = thoughts?____

    __ = __


=     ------
=     Best Regards,
=     Dapeng Liu____




--

------
Best Regards,
Dapeng = Liu


_______________________________________________
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


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

----------------------------
Prof. Jean-Marie = BONNIN
Institut Mines = T=E9l=E9com / T=E9l=E9com Bretagne
IRISA / D2 / OCIF
Head of Telecom Bretagne / RSM department (Network, Security = and Multimedia)
Head of IRISA / D2 (Network, = Telecommunication and Services)
Mob: +33 660 767 = 976



= --Apple-Mail=_113A69AE-A26C-4A30-8894-B1781EDCD818-- From nobody Fri Jul 24 16:39:29 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D2C1AD0D6 for ; Fri, 24 Jul 2015 16:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 BFR_kh4tp-Ri for ; Fri, 24 Jul 2015 16:39:25 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 DF7411AD0A8 for ; Fri, 24 Jul 2015 16:39:24 -0700 (PDT) Received: by pdbbh15 with SMTP id bh15so20244655pdb.1 for ; Fri, 24 Jul 2015 16:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=nFyyRVgq9/94HV4cnnLsgrm65Nae9E+enWsrRG0mRxY=; b=VljLmbftP3en/EjWpmJ7SL71RFrnd2qTi8pyhPef53p12Ja7RlrO56kw/a0il2O3rG zBq1EO/5oyI1uRw3t3D5lwfXU14CAibCFOHTm7DGZ+dpAUkfWWYPKzRepIz776vUdGKx vbmVmiSxKZVVgoXpuGNTVNNkoMLd3Hr8OSGyim7QfAtALuMNYPGwitZ6UIrx5x1CMPqH vO4rvTv2LYbM4VpbobwR3VCtsuCaMnJTIFlNGv1zhqu7rm9JG9jNNKCW6MsFYdABs5Z5 C5A/y9FmYi9UagS8d3GCzU7yTJBDsXTQLEsIBxvrNkE5MK46RSYwmhSxmNZrvVTLCLk+ VtPw== X-Received: by 10.70.16.67 with SMTP id e3mr36571948pdd.98.1437781164504; Fri, 24 Jul 2015 16:39:24 -0700 (PDT) Received: from [192.168.1.107] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by smtp.gmail.com with ESMTPSA id ht9sm16539628pdb.0.2015.07.24.16.39.23 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 16:39:23 -0700 (PDT) Message-ID: <1437781161.1977.45.camel@localhost.localdomain> From: Rex Buddenberg To: Jean-Marie BONNIN Date: Fri, 24 Jul 2015 16:39:21 -0700 In-Reply-To: References: <774B240D54DAB844B37EE80C2DD8E8BC6746D282@SZXEMA501-MBX.china.huawei.com> <55AFACEE.5010408@gmail.com> <774B240D54DAB844B37EE80C2DD8E8BC67470C3D@SZXEMA501-MBX.china.huawei.com> <55B28D64.8060002@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Why not using IPv6 link local address for one hop V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 23:39:28 -0000 In line, then comments: On Fri, 2015-07-24 at 22:50 +0200, Jean-Marie BONNIN wrote: > Hi Dick > > > If an application always need only one hop and it is alway deployed in > the same manner in the car, probably we can use only link layer > technologies to address and transport application data. That's what the non-IP stack in IEEE 1609 is trying to do. > But the same application could some time use one-hop and another time > use multi-hop communications … of course we could manage this in an > intermediate layer such as the ETSI facilities but it becomes more > complex. It could be simpler for the applications to always use IP. It is simpler, but there's a much more compelling reason: security. First, understand that the notion of single-hop is fiction. - the other automobile that you want to communicate with is one you can't see (cross-traffic, blocked by a building ... he's about to t-bone you). - we always have three hops in the simplest topology -- local comms within each automobile plus a radio hop. There's a bunch of denial going on ... the two sides of the argument can be stereotyped into the "IoT' faction and the 'gateway faction'. The gateway group tries to deny the multiple hop characteristic, but it doesn't work. The highjacked Jeep conversation shows the fallacy of the gateway problem: you need end-to-end authenticity and gateways can't deliver it. > > > If the concern is just about the overhead due to the IP header, is > could be reduce a lot using header compression technics. Agreed. But this is a minor point. Get the end-end delivery of authenticity in the center of the target. > > > JM > > > Le 24 juil. 2015 à 21:09, Alexandru Petrescu > > a écrit : > > > > Maybe the terminology should change from 1-hop to 1-variable-hop and > > n stable hops (the Ethernets in the cars). > > > > Not sure what name to give to this: n-stable-hops plus 1 variable > > hop. > > > > That's the structure in V2V. > > > > Alex > > > > Le 24/07/2015 12:41, Huangjing (A) a écrit : > > > Agree, link local address is not sufficient for V2V communication. > > > But, if we consider only 1-hop communication, it is probably > > > sufficient. > > > > > > James > > > > > > > -----Original Message----- > > > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru > > > > Petrescu > > > > Sent: Wednesday, July 22, 2015 10:47 PM > > > > To: its@ietf.org > > > > Subject: Re: [geonet/its] Why not using IPv6 link local address > > > > for one hop V2V > > > > > > > > I tend to agree. Just that I dont think we need another kind of > > > > addresses. > > > > > > > > In other words: yes, just using LL addresses to realize V2V > > > > communication is > > > > not enough. no, in that messages between routers can be sourced > > > > just by > > > > their link-local addresses. > > > > > > > > Or maybe a prefix between vehicles would be needed. > > > > > > > > The creation of IP addresses _inside_ vehicles is currently a > > > > problem as well. > > > > > > > > Alex > > > > > > > > Le 22/07/2015 16:14, Dapeng Liu a écrit : > > > > > Sure. My point is we can not just use IPv6 link local address > > > > > to > > > > > fulfill the requirement. agree? > > > > > > > > > > Thanks, > > > > > Dapeng Liu > > > > > > > > > > 2015-07-22 15:16 GMT+02:00 Huangjing (A) > > > > > > > > > >: > > > > > > > > > > Hi, Dapeng,____ > > > > > > > > > > __ __ > > > > > > > > > > Maybe we can distinguish a vehicle from a mobile by other > > > > > means, > > > > > rather than IP prefix / address.____ > > > > > > > > > > For message broadcast (e.g. safety related message), we > > > > > may require > > > > > a dedicated multicast address; for Unicast communication, > > > > > I think we > > > > > should make use of higher level information, such as > > > > > TCP/UDP(or > > > > > similar one) port or application level information____ > > > > > > > > > > __ __ > > > > > > > > > > Any thoughts?____ > > > > > > > > > > __ __ > > > > > > > > > > James____ > > > > > > > > > > __ __ > > > > > > > > > > *From:*its [mailto:its-bounces@ietf.org > > > > > ] *On Behalf Of *Dapeng Liu > > > > > *Sent:* Wednesday, July 22, 2015 7:30 PM > > > > > *To:* its@ietf.org > > > > > *Subject:* [geonet/its] Why not using IPv6 link local > > > > > address for > > > > > one hop V2V____ > > > > > > > > > > __ __ > > > > > > > > > > Hello all,____ > > > > > > > > > > __ __ > > > > > > > > > > During the noon discussion, we were discussing whether we > > > > > can use > > > > > IPv6 link local address for one hop V-V IP > > > > > communication.____ > > > > > > > > > > __ __ > > > > > > > > > > One reason is that the vehicle that discover a neighbor > > > > > with link > > > > > local IPv6 address can not distinguish whether that is > > > > > another > > > > > vehicle or it is a smart phone in the car or it is a smart > > > > > phone > > > > > from road side passengers. > > > > > ____ > > > > > > > > > > __ __ > > > > > > > > > > If we want to use IPv6 link local address, a dedicate > > > > > prefix for V2V > > > > > may needed.____ > > > > > > > > > > __ __ > > > > > > > > > > Any thoughts?____ > > > > > > > > > > __ __ > > > > > > > > > > > > > > > ------ > > > > > Best Regards, > > > > > Dapeng Liu____ > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ------ > > > > > Best Regards, > > > > > Dapeng Liu > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > ---------------------------- > Prof. Jean-Marie BONNIN > Institut Mines Télécom / Télécom Bretagne > IRISA / D2 / OCIF > Head of Telecom Bretagne / RSM department (Network, Security and > Multimedia) > Head of IRISA / D2 (Network, Telecommunication and Services) > Mob: +33 660 767 976 > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Jul 30 05:20:41 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E271A8768 for ; Thu, 30 Jul 2015 05:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 e9qIttPxYftf for ; Thu, 30 Jul 2015 05:20:34 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DEF1A8750 for ; Thu, 30 Jul 2015 05:20:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6UCKVBs027958 for ; Thu, 30 Jul 2015 14:20:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DB472202480 for ; Thu, 30 Jul 2015 14:24:17 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C5E09202474 for ; Thu, 30 Jul 2015 14:24:17 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6UCKUqT016031 for ; Thu, 30 Jul 2015 14:20:31 +0200 To: "its@ietf.org" From: Alexandru Petrescu Message-ID: <55BA168E.3010508@gmail.com> Date: Thu, 30 Jul 2015 14:20:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010500020109050706050004" Archived-At: Subject: [geonet/its] status of open-source 802.11p drivers? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 12:20:39 -0000 This is a multi-part message in MIME format. --------------010500020109050706050004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have been asked what is the status of open-source 802.11p drivers? As far as I know: GCDC 802.11p - no longer online. Czech Tech Uni - trying to merge into linux kernel. Is there another one available freely? (we also have one at work but it is not for public distribution). Alex --------------010500020109050706050004 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I have been asked what is the status of open-source 802.11p drivers?  As far as I know:

GCDC 802.11p - no longer online.
Czech Tech Uni - trying to merge into linux kernel.

Is there another one available freely?

(we also have one at work but it is not for public distribution).

Alex
 --------------010500020109050706050004-- From nobody Thu Jul 30 05:35:29 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112211A9234 for ; Thu, 30 Jul 2015 05:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 i9s2ET3mwW_i for ; Thu, 30 Jul 2015 05:35:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AED1AC3D9 for ; Thu, 30 Jul 2015 05:35:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6UCZEfo029211 for ; Thu, 30 Jul 2015 14:35:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DA2C6202A04 for ; Thu, 30 Jul 2015 14:39:00 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C5E03200B58 for ; Thu, 30 Jul 2015 14:39:00 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6UCZDV8025503 for ; Thu, 30 Jul 2015 14:35:14 +0200 To: "its@ietf.org" From: Alexandru Petrescu Message-ID: <55BA1A01.2070305@gmail.com> Date: Thu, 30 Jul 2015 14:35:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050209090505020905060903" Archived-At: Subject: [its] prefix change in the Subject line X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 12:35:28 -0000 This is a multi-part message in MIME format. --------------050209090505020905060903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Filter update: I just changed the prefix in the Subject line of this list to mean [its]. Alex --------------050209090505020905060903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

Filter update: I just changed the prefix in the Subject line of this list to mean [its].

Alex


 --------------050209090505020905060903-- From nobody Thu Jul 30 05:41:42 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0292F1A8881 for ; Thu, 30 Jul 2015 05:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.441 X-Spam-Level: * X-Spam-Status: No, score=1.441 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 6rO66NRv7ZDi for ; Thu, 30 Jul 2015 05:41:38 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 283A11A887E for ; Thu, 30 Jul 2015 05:41:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,577,1432591200"; d="scan'208,217";a="895341" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 30 Jul 2015 14:41:36 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id DD4CBCF; Thu, 30 Jul 2015 14:41:35 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandru Petrescu'" , References: <55BA168E.3010508@gmail.com> In-Reply-To: <55BA168E.3010508@gmail.com> Date: Thu, 30 Jul 2015 14:41:35 +0200 Organization: EURECOM Message-ID: <04bd01d0cac5$125d3210$37179630$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04BE_01D0CAD5.D5E6C560" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF70kquR2VEXC7hnrHiYX8vj3U8Zp6d5ASg Content-Language: en-us Archived-At: Subject: Re: [its] [geonet/its] status of open-source 802.11p drivers? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 12:41:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04BE_01D0CAD5.D5E6C560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Alex, =20 We have one at EURECOM known as OpenAirInterface ITS = (http://www.openairinterface.org/), but we are also currently merging = with the new version of the linux kernel of Ubuntu 14.04 LTS. More to = come in the following weeks=E2=80=A6 =20 Agostini, Philippe; Knopp, Raymond; H=C3=A4rri, J=C3=A9r=C3=B4me; = Haziza, Nathalie, Implementation and test of a DSRC prototype on = OpenAirInterface SDR platform ICC 2013, IEEE International Conference on = Communications Workshops, 9-13 June 2013, Budapest, Hungary. =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday 30 July 2015 14:21 To: its@ietf.org Subject: [geonet/its] status of open-source 802.11p drivers? =20 Hi, I have been asked what is the status of open-source 802.11p drivers? As = far as I know: GCDC 802.11p - no longer online. Czech Tech Uni - trying to merge into linux kernel. Is there another one available freely? (we also have one at work but it is not for public distribution). Alex ------=_NextPart_000_04BE_01D0CAD5.D5E6C560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Alex,

 

We have one at EURECOM known as OpenAirInterface ITS = (http://www.openairinterface.org/), but we are also currently merging = with the new version of the linux kernel of Ubuntu 14.04 LTS. More to = come in the following weeks=E2=80=A6

 

Agostini, = Philippe; Knopp, Raymond; H=C3=A4rri, J=C3=A9r=C3=B4me; Haziza, = Nathalie, Implementation and test of a DSRC prototype on = OpenAirInterface SDR platform ICC 2013, IEEE International Conference on = Communications Workshops, 9-13 June 2013, Budapest, = Hungary.

 

Best Regards,

 

J=C3=A9r=C3=B4me

 

From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru = Petrescu
Sent: Thursday 30 July 2015 14:21
To: = its@ietf.org
Subject: [geonet/its] status of open-source = 802.11p drivers?

 

Hi,

I have been asked what is = the status of open-source 802.11p drivers?  As far as I = know:

GCDC 802.11p - no longer online.
Czech Tech Uni - trying = to merge into linux kernel.

Is there another one available = freely?

(we also have one at work but it is not for public = distribution).

Alex

------=_NextPart_000_04BE_01D0CAD5.D5E6C560--