From nobody Fri Jun 1 04:53:00 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9359D12D77E for ; Fri, 1 Jun 2018 04:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8zIhvSYFAd0 for ; Fri, 1 Jun 2018 04:52:56 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA9312711E for ; Fri, 1 Jun 2018 04:52:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B4BE9300A42 for ; Fri, 1 Jun 2018 07:52:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Urj1esSrIFKh for ; Fri, 1 Jun 2018 07:52:52 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 28FFB300A08; Fri, 1 Jun 2018 07:52:52 -0400 (EDT) From: Russ Housley Message-Id: <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F666B3D7-6BF5-4096-9D8A-68A0E920D5C9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 1 Jun 2018 07:52:56 -0400 In-Reply-To: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> Cc: Suresh Krishnan To: its References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 11:52:58 -0000 --Apple-Mail=_F666B3D7-6BF5-4096-9D8A-68A0E920D5C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 1, 2018, at 12:51 AM, Suresh Krishnan = wrote: >=20 > Hi all, > I had requested the 6man WG to review = draft-ietf-ipwave-ipv6-over-80211ocb-22 after the WGLC here as per the = ipwave charter. The request resulted in several comments and some of = them are major and, in my opinion, require significant changes to the = draft to address.=20 >=20 > The thread starts with this email >=20 > https://www.ietf.org/mail-archive/web/ipv6/current/msg30065.html = >=20 > and the further emails in this thread can be found at >=20 > https://mailarchive.ietf.org/arch/browse/ipv6/?q=3D80211ocb-22 = >=20 > One of the proposals that emerged there was that this document can be = discussed at the 6man WG meeting in Montreal to identify potential ways = forward. I=E2=80=99d rather not wait till the Montreal meeting if we can = make progress on this document before then. I think we should start = discussing the issues raised on the ipwave mailing list and come up with = a plan to address them. In my mind the major issues that were raised are >=20 > * Lack of specification of how ND will work on these links (the = underlying assumption of the commenters is that standard ND would not = work) > * Multicast support (or the lack of it) and how it will be addressed - = e.g. should we specify an NBMA oriented ND procedure? > * Not enough basic background information about 802.11OCB >=20 > Comments and potential solutions are greatly appreciated. I know that there are several people that have done implementations. = Please share with us what you did for neighbor discovery (ND). My hope = is that there is something that we can add to the document based on your = implementation experience. It is obvious that ND techniques that would be acceptable while the = vehicle is parked in a garage would not be acceptable while the same = vehicle is a speed on the highway. The later is clearly the hard case. Russ --Apple-Mail=_F666B3D7-6BF5-4096-9D8A-68A0E920D5C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 1, 2018, at 12:51 AM, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:



I know = that there are several people that have done implementations. =  Please share with us what you did for neighbor discovery (ND). =  My hope is that there is something that we can add to the document = based on your implementation experience.

It is obvious that ND techniques that = would be acceptable while the vehicle is parked in a garage would not be = acceptable while the same vehicle is a speed on the highway.  The = later is clearly the hard case.

Russ

= --Apple-Mail=_F666B3D7-6BF5-4096-9D8A-68A0E920D5C9-- From nobody Mon Jun 4 12:58:00 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 310A5130DC0; Mon, 4 Jun 2018 12:57:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Carlos Bernardos" , "Russ Housley" Cc: Terry Manderson , IP Wireless Access in Vehicular Environments Discussion List , Carlos Bernardos , Russ Housley , itu-t-liaison@iab.org, Suresh Krishnan X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152814227815.30650.13041947227574583212.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2018 12:57:58 -0700 Archived-At: Subject: [ipwave] New Liaison Statement, "LS from ITU-R WP 5A to External Organizations" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 19:57:59 -0000 Title: LS from ITU-R WP 5A to External Organizations Submission Date: 2018-06-04 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1580/ Please reply by 2018-10-29 From: Sergio Buonomo To: Carlos Bernardos ,Russ Housley Cc: Terry Manderson ,IP Wireless Access in Vehicular Environments Discussion List ,Russ Housley ,Carlos Bernardos ,itu-t-liaison@iab.org,Suresh Krishnan Response Contacts: Technical Contacts: Purpose: For action Body: In the November 2017 liaison statement, Working Party (WP) 5A had informed that it is working on the revision of Recommendation ITU-R M.2084-0 “Radio interface standards of vehicle-to-vehicle and vehicle to-infrastructure communications for Intelligent Transport System applications”. In its May 2018 meeting, WP 5A agreed to allow a final extension, until its November 2018 meeting, for the finalization of this revision to allow some members to submit their standards and technical specifications. The current draft revision is attached for reference. Even though the work will continue, the document is considered stable as a preliminary draft revision of Recommendation ITU-R M.2084 and WP 5A plans to submit the final draft to ITU-R Study Group 5 for consideration for adoption. WP 5A invites external organizations to submit updated information, if any, on technical standards, and will consider the input contributions at its next meeting in November 2018. The deadline for submission of contributions is prior to 16:00 (UTC) on 29 October 2018. Attachments: No document has been attached From nobody Mon Jun 4 14:40:09 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA889130E01 for ; Mon, 4 Jun 2018 14:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2uC8Vk2fgyc for ; Mon, 4 Jun 2018 14:40:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475E1130E00 for ; Mon, 4 Jun 2018 14:40:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F50E300A45 for ; Mon, 4 Jun 2018 17:40:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7NuL9lEyB3QF for ; Mon, 4 Jun 2018 17:39:59 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 56A69300523; Mon, 4 Jun 2018 17:39:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <152814227815.30650.13041947227574583212.idtracker@ietfa.amsl.com> Date: Mon, 4 Jun 2018 17:39:59 -0400 Cc: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , itu-t-liaison@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <14485475-2C7A-47E3-B130-247F857D681F@vigilsec.com> References: <152814227815.30650.13041947227574583212.idtracker@ietfa.amsl.com> To: IP Wireless Access in Vehicular Environments Discussion List X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] New Liaison Statement, "LS from ITU-R WP 5A to External Organizations" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 21:40:06 -0000 Please take a look at the liaison statement. To see the actual = document, you need to open the (MS Word) attachment, and then click the = icon at the bottom of the page to open an embedded MS Word document. We are invited to submit updated information on technical standards fir = consideration at the ITU-R WP 5A meeting in November 2018. If we have = any input, we need to provide it by 29 October 2018. Russ > On Jun 4, 2018, at 3:57 PM, Liaison Statement Management Tool = wrote: >=20 > Title: LS from ITU-R WP 5A to External Organizations > Submission Date: 2018-06-04 > URL of the IETF Web page: https://datatracker.ietf.org/liaison/1580/ > Please reply by 2018-10-29 > From: Sergio Buonomo > To: Carlos Bernardos ,Russ Housley = > Cc: Terry Manderson ,IP Wireless Access in = Vehicular Environments Discussion List ,Russ Housley = ,Carlos Bernardos = ,itu-t-liaison@iab.org,Suresh Krishnan = > Response Contacts:=20 > Technical Contacts:=20 > Purpose: For action >=20 > Body: In the November 2017 liaison statement, Working Party (WP) 5A = had informed that it is working on the revision of Recommendation ITU-R = M.2084-0 =E2=80=9CRadio interface standards of vehicle-to-vehicle and = vehicle to-infrastructure communications for Intelligent Transport = System applications=E2=80=9D. In its May 2018 meeting, WP 5A agreed to = allow a final extension, until its November 2018 meeting, for the = finalization of this revision to allow some members to submit their = standards and technical specifications. The current draft revision is = attached for reference. Even though the work will continue, the document = is considered stable as a preliminary draft revision of Recommendation = ITU-R M.2084 and WP 5A plans to submit the final draft to ITU-R Study = Group 5 for consideration for adoption.=20 >=20 > WP 5A invites external organizations to submit updated information, if = any, on technical standards, and will consider the input contributions = at its next meeting in November 2018. The deadline for submission of = contributions is prior to 16:00 (UTC) on 29 October 2018. > Attachments: From nobody Fri Jun 8 08:29:01 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304E0130EED for ; Fri, 8 Jun 2018 08:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-bVBBS9lK3E for ; Fri, 8 Jun 2018 08:28:57 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9918130EEB for ; Fri, 8 Jun 2018 08:28:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w58FSpew039180; Fri, 8 Jun 2018 17:28:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9C8EE206440; Fri, 8 Jun 2018 17:28:51 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8912B20402A; Fri, 8 Jun 2018 17:28:51 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w58FSpjs027970; Fri, 8 Jun 2018 17:28:51 +0200 To: Russ Housley , IP Wireless Access in Vehicular Environments Discussion List Cc: itu-t-liaison@iab.org, =?UTF-8?Q?Carlos_Jes=c3=bas_Bernardos_Cano?= References: <152814227815.30650.13041947227574583212.idtracker@ietfa.amsl.com> <14485475-2C7A-47E3-B130-247F857D681F@vigilsec.com> From: Alexandre Petrescu Message-ID: <735d3673-c222-f987-56fa-a79e937783d3@gmail.com> Date: Fri, 8 Jun 2018 17:28:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <14485475-2C7A-47E3-B130-247F857D681F@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] New Liaison Statement, "LS from ITU-R WP 5A to External Organizations" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 15:29:00 -0000 Le 04/06/2018 à 23:39, Russ Housley a écrit : > Please take a look at the liaison statement. To see the actual > document, you need to open the (MS Word) attachment, and then click > the icon at the bottom of the page to open an embedded MS Word > document. > > We are invited to submit updated information on technical standards > fir consideration at the ITU-R WP 5A meeting in November 2018. If we > have any input, we need to provide it by 29 October 2018. > > Russ > > >> On Jun 4, 2018, at 3:57 PM, Liaison Statement Management Tool >> wrote: >> >> Title: LS from ITU-R WP 5A to External Organizations Submission >> Date: 2018-06-04 URL of the IETF Web page: >> https://datatracker.ietf.org/liaison/1580/ Please reply by >> 2018-10-29 From: Sergio Buonomo To: Carlos >> Bernardos ,Russ Housley Cc: >> Terry Manderson ,IP Wireless Access in >> Vehicular Environments Discussion List ,Russ Housley >> ,Carlos Bernardos >> ,itu-t-liaison@iab.org,Suresh Krishnan >> Response Contacts: Technical Contacts: Purpose: >> For action >> >> Body: In the November 2017 liaison statement, Working Party (WP) 5A >> had informed that it is working on the revision of Recommendation >> ITU-R M.2084-0 “Radio interface standards of vehicle-to-vehicle and For standards of vehicle-to-vehicle communication: 1. this is something that is highly interesting. The interest has been expressed by this letter, but also by other SDOs (recently SAE) and other organisms. 2. from my side, in my project, and with some of my partners, we do have a strong interest in vehicle-to-vehicle communications, with applications such as convoy maintenance with RTMaps and IP messages between cars (without RSU presence). 3. there are some Internet Drafts posted on the topic of the use of IP protocols for vehicle-to-vehicle communications, such as, but not limited to, draft-petrescu-autoconf-ra-based- routing-05.txt and draft-petrescu-its-cacc-sdo-05.txt 4. also, the protocol Babel was tried in practice between two OBUs, but on table (not on car). I would like to learn whether WP 5A considers the use of IP protocols, and notably Neighbor Discovery (ND), for vehicle-to-vehicle communications without RSU presence. Alex >> vehicle to-infrastructure communications for Intelligent Transport >> System applications”. In its May 2018 meeting, WP 5A agreed to >> allow a final extension, until its November 2018 meeting, for the >> finalization of this revision to allow some members to submit their >> standards and technical specifications. The current draft revision >> is attached for reference. Even though the work will continue, the >> document is considered stable as a preliminary draft revision of >> Recommendation ITU-R M.2084 and WP 5A plans to submit the final >> draft to ITU-R Study Group 5 for consideration for adoption. >> >> WP 5A invites external organizations to submit updated information, >> if any, on technical standards, and will consider the input >> contributions at its next meeting in November 2018. The deadline >> for submission of contributions is prior to 16:00 (UTC) on 29 >> October 2018. Attachments: > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Fri Jun 8 09:13:53 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F37130F07; Fri, 8 Jun 2018 09:13:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Carlos Bernardos" , "Russ Housley" Cc: Terry Manderson , IP Wireless Access in Vehicular Environments Discussion List , Carlos Bernardos , Scott Mansfield , Russ Housley , itu-t-liaison@iab.org, Suresh Krishnan X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152847443042.15372.2179965298121626247.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2018 09:13:50 -0700 Archived-At: Subject: [ipwave] New Liaison Statement, "International Forum on ITS plus Collaboration meeting -- Nanjing, China, 6-7 September 2018" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 16:13:51 -0000 Title: International Forum on ITS plus Collaboration meeting -- Nanjing, China, 6-7 September 2018 Submission Date: 2018-06-08 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1581/ From: Stefano Polidori To: Carlos Bernardos ,Russ Housley Cc: Terry Manderson ,IP Wireless Access in Vehicular Environments Discussion List ,Carlos Bernardos ,Scott Mansfield ,Russ Housley ,itu-t-liaison@iab.org,Suresh Krishnan Response Contacts: Technical Contacts: Purpose: For information Body: On 6-7 September 2018, the ITS Industry Alliance (C-ITS ) of China and the International Telecommunication Union (ITU ) will convene the International Forum on ITS (ITS-2018 ) with the aim to explore How Communications will Change Vehicles and Transport. A meeting of the Collaboration on ITS Communication Standards (CITS ) will be co-located to the ITS-2018 forum. Both events will take place in Nanjing, China. To advance Intelligent Transport Systems (ITS), the vehicle industry and the information and communication technology (ICT) industry continue to converge. Undoubtedly, this will provide new business opportunities and new scenarios to the benefit of the industry, as well as consumers and government agencies. Fresh approaches are expected to grow to develop innovative technologies to support a range of smart city solutions enabling more intelligent transport systems aiming at better road safety, reduced traffic congestion, and increased connectivity and mobility for urban dwellers. But how can these two very different industries find ways to collaborate to extend the benefits of connected vehicle innovation safely to everyone? In this ITS landscape, automated driving is moving towards commercialization. The innovations leading to driverless vehicles on the road are planned in parallel to innovations in the field of vehicles' energy. The international community is attentive to the environmental challenges and aim to reduce the emissions to mitigate the climate changes. The future ITS can only be imagined with autonomous and environmentally friendly vehicles, powered by alternative fuels and advanced vehicle technologies, also to increase the accessibility of personal mobility to the elderly and persons with disabilities. For more information on the ITS-2018, please visit the Forum webpage here or consult TSB Circular 89 . www.itu.int/go/ITSforum/2018 The Forum is co‑located with the meeting of the Collaboration on ITS Communication Standards (CITS ), which is scheduled on 7 September 2018 (pm) and aims to review the state of ITS communication standards and discuss the road ahead. The CITS meeting provides an opportunity to collaborate, exchange information and keep experts updated on ITS standardization. The representatives of various involved standards bodies are invited to submit to the CITS meeting a status report on ITS standardization ongoing in their respective organizations. These progress reports should be sent to Mr Stefano Polidori (ITU) at tsbcits@itu.int . Feel free to distribute this information to relevant mailing lists. Attachments: International Forum on ITS plus Collaboration meeting -- Nanjing, China, 6-7 September 2018 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-06-08-itu-t-sg-9-ipwave-international-forum-on-its-plus-collaboration-meeting-nanjing-china-6-7-september-2018-attachment-1.docx From nobody Sun Jun 10 08:52:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0179A130E70 for ; Sun, 10 Jun 2018 08:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztrmgfjvsc6f for ; Sun, 10 Jun 2018 08:52:31 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3A6130DFF for ; Sun, 10 Jun 2018 08:52:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5AFqSte151430 for ; Sun, 10 Jun 2018 17:52:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 162882010A0 for ; Sun, 10 Jun 2018 17:52:28 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0C53C200C68 for ; Sun, 10 Jun 2018 17:52:28 +0200 (CEST) Received: from [132.166.84.24] ([132.166.84.24]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5AFqQ2O021498 for ; Sun, 10 Jun 2018 17:52:27 +0200 To: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> From: Alexandre Petrescu Message-ID: Date: Sun, 10 Jun 2018 17:52:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 15:52:33 -0000 Hi, Sorry for late reply. Le 01/06/2018 à 13:52, Russ Housley a écrit : > >> On Jun 1, 2018, at 12:51 AM, Suresh Krishnan >> > wrote: >> >> Hi all, >>   I had requested the 6man WG to review >> draft-ietf-ipwave-ipv6-over-80211ocb-22 after the WGLC here as per the >> ipwave charter. The request resulted in several comments and some of >> them are major and, in my opinion, require significant changes to the >> draft to address. >> >> The thread starts with this email >> >> https://www.ietf.org/mail-archive/web/ipv6/current/msg30065.html >> >> and the further emails in this thread can be found at >> >> https://mailarchive.ietf.org/arch/browse/ipv6/?q=80211ocb-22 >> * >> * >> One of the proposals that emerged there was that this document can be >> discussed at the 6man WG meeting in Montreal to identify potential >> ways forward. I’d rather not wait till the Montreal meeting if we can >> make progress on this document before then. I think we should start >> discussing the issues raised on the ipwave mailing list and come up >> with a plan to address them. In my mind the major issues that were >> raised are >> >> * Lack of specification of how ND will work on these links (the >> underlying assumption of the commenters is that standard ND would not >> work) >> * Multicast support (or the lack of it) and how it will be addressed - >> e.g. should we specify an NBMA oriented ND procedure? >> * Not enough basic background information about 802.11OCB >> >> Comments and potential solutions are greatly appreciated. > > > I know that there are several people that have done implementations. >  Please share with us what you did for neighbor discovery (ND).  My > hope is that there is something that we can add to the document based on > your implementation experience. The ND protocol is very important in vehicle communications. In particular, in the zone outside of the car, the ND protocol is very important (also inside the car). In the zone outside the car, there are two typical ways to employ ND. In the first way, the ND protocol is used without much modifications. This is when the car connects to a fixed road-side unit. The RSU sends a Router Advertisement, and NAs, to the car. And the car configures an address on its egress interface, and connects to the Internet. This has been trialled in the lab, and now there are a few RSUs deployed in that way - on some roads. In this 'first way', there are very simple tweaks necessary in the ND space. One tweak that is absolutely necessary is that the RSU absolutely must send some presence messages for the cars to detect its presence. One must remember the RSUs on 802.11 OCB do not send any IEEE 'Beacon' which are otherwise very normal in 802.11 not-OCB. Absent these Beacons it is hard for a vehicle to detect the presence of RSUs and decide to connect to it. The interoperability problem in this 'first way' is to decide _which_ message the RSU to send out periodically, and the car to check _that_ particular message. There are very many candidates, contrary to expectations, and deployments do many distinct incompatible things. Examples noticed in practice are: TSA (Time Stamp Advertisemt), IPv6 Router Advertisement, 802.21 message, Europe's CAM message, and probably more. Each one of these is different, yet one little cheap car can not implement _all_ of them in order to sense presence. The IPv4 problem of this 'first way' is that in IPv4 there are not many platforms that implement IPv4 Router Advertisement. And if we want to do IPv4 deployment similar to IPv6 deployment then we would have preferred to use IPv6 RAs (that all routers do) _and_ IPv4 RA. These are the ND problems with this 'first way'. In one of my implementations we have solved it like this: use IPv6 RA to detect presence in IPv6 (not CAM, not 802.21, not TSA) and use IPv4 RA to detect presence in IPv4. In another implementation on which I work right now the European CAM message is mandatory for some reason. It may be possible that we will use this CAM message (instead of IPv6 RA) to detect presence, but I am not very sure at this time. Another necessary aspect for ND in this 'first way' is that the RSU sends RAs very frequently. This is a parameter to set in a configuration file. This parameter _is_ specified in RFCs, there is nothing new. One RA must be sent every 10ms or so. Calculations have been performed to evaluate that number, starting from emission power parameter, and vehicle speed. When put in practice, these parameters (10ms) do prove successful. In the 'second way', the ND is used also outside the car, but this time it is used to connect from one vehicle to another nearby. In this 'second way', one vehicle sends an IPv6 Router Advertisement to another vehicle on same channel and nearby. Here, the ND protocol needs much more tweaks than simple parameters. One important new thing is a prefix that must be put in this RA. Of course, RAs already has prefixes, but the prefix I am writing about is different: it is not the prefix on the link, but the prefix(es) present inside the car. So one car informs another car about its own inner prefixes. Among those two 'ways', I believe we only need to document the 'first' way in the IPv6-over-OCB. The doubt I have is that we already did document it, and then we removed it somehow. I can try again soon. > It is obvious that ND techniques that would be acceptable while the > vehicle is parked in a garage would not be acceptable while the same > vehicle is a speed on the highway.  The later is clearly the hard case. I fully agree. In this distinction (fast vs slow) I think we can leave out the 'fast' way from the IPv6-over-OCB. Alex > > Russ > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Sun Jun 10 09:11:58 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B68130E74 for ; Sun, 10 Jun 2018 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK9x3IP134Fl for ; Sun, 10 Jun 2018 09:11:54 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E351D130E32 for ; Sun, 10 Jun 2018 09:11:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5AGBqHG003571 for ; Sun, 10 Jun 2018 18:11:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E861E201104 for ; Sun, 10 Jun 2018 18:11:51 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DE8D7200D0C for ; Sun, 10 Jun 2018 18:11:51 +0200 (CEST) Received: from [132.166.84.24] ([132.166.84.24]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5AGBode023726 for ; Sun, 10 Jun 2018 18:11:51 +0200 To: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> From: Alexandre Petrescu Message-ID: Date: Sun, 10 Jun 2018 18:11:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 16:11:56 -0000 There was some question about broadcast vs unicast vs multicast in vehicular communications. Typically, extremely many people call 'vehicular communications' to be the cars that 'broadcast' messages around, containing positions, and make local decisions about who is where, such as to avoid accidents. Despite the ultra-importance of accident avoiding, this view is still a too narrow view of 'vehicular communications'. Where is the Internet in this 'vehicular communications'? There are other views of vehicular communications which are encompassing much more than just accident avoidance. One of these views is the following: The use of IP unicast in vehicle-to-vehicle communications is the following: top-antenna top-antenna | | front-antenna--CAR1--rear-atenna front-antenna--CAR2--rear-atenna In this view, CARs 'broadcast' CAMs on a particular 5.9GHz channel on their top antennas, but use IP between rear-antenna and front-antenna. They are on distinct interfaces than top antenna, different 5.9GHz channel than from top antenna, but on same 5.9GHz channel between front of a car and rear of another car. Channel mgmt is performed by somebody. So one has an IP subnet between CAR1 rear-antenna and CAR2 front-antenna. On this IP subnet the ND protocol works. The way it works is like on an Ethernet in the Enterprise network: use the IPv6 'unicast' and 'multicast' concept of IPv6 MLD. The ND problem in this space is the exchange of prefixes. We have solved it with software and a draft. The 'multicast' problem in this space is the following: a PC inside a car needs to send a convoy 'maintenance' message to each other similar PC in each other car in a convoy (not to the Routers in the cars, but to the PCs in charge of automated driving). Is MLD sufficient to establish the multicast tree? Which multicast address to use? This is my 'multicast' problem right now. To summarize: yes, we do use unicast messages between cars in convoy: we ping unicast, ssh between PCs of distinct cars in convoy, etc. We do not like 'broadcast' even though 1000 people request for CAM. We can send these CAMs, they are 'broadcast', we do not like it, we can write a howto make CAMs with cheap open source, and it all ends there until someone at ETSI agrees CAM is wrong. I am afraid that will take so much time to change people's minds... For multicast: I need to understand whether IP multicast in a multi-subnet IP network formed in a convoy can be implemented simply with MLD or some other protocol is needed, and whether that is open source. Alex Le 01/06/2018 à 13:52, Russ Housley a écrit : > >> On Jun 1, 2018, at 12:51 AM, Suresh Krishnan >> > wrote: >> >> Hi all, >>   I had requested the 6man WG to review >> draft-ietf-ipwave-ipv6-over-80211ocb-22 after the WGLC here as per the >> ipwave charter. The request resulted in several comments and some of >> them are major and, in my opinion, require significant changes to the >> draft to address. >> >> The thread starts with this email >> >> https://www.ietf.org/mail-archive/web/ipv6/current/msg30065.html >> >> and the further emails in this thread can be found at >> >> https://mailarchive.ietf.org/arch/browse/ipv6/?q=80211ocb-22 >> * >> * >> One of the proposals that emerged there was that this document can be >> discussed at the 6man WG meeting in Montreal to identify potential >> ways forward. I’d rather not wait till the Montreal meeting if we can >> make progress on this document before then. I think we should start >> discussing the issues raised on the ipwave mailing list and come up >> with a plan to address them. In my mind the major issues that were >> raised are >> >> * Lack of specification of how ND will work on these links (the >> underlying assumption of the commenters is that standard ND would not >> work) >> * Multicast support (or the lack of it) and how it will be addressed - >> e.g. should we specify an NBMA oriented ND procedure? >> * Not enough basic background information about 802.11OCB >> >> Comments and potential solutions are greatly appreciated. > > > I know that there are several people that have done implementations. >  Please share with us what you did for neighbor discovery (ND).  My > hope is that there is something that we can add to the document based on > your implementation experience. > > It is obvious that ND techniques that would be acceptable while the > vehicle is parked in a garage would not be acceptable while the same > vehicle is a speed on the highway.  The later is clearly the hard case. > > Russ > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Sun Jun 10 19:06:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C81130DD9 for ; Sun, 10 Jun 2018 19:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z8WPNsts1ND for ; Sun, 10 Jun 2018 19:06:14 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 B9B0A126DBF for ; Sun, 10 Jun 2018 19:06:14 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id w23-v6so12110662qkb.8 for ; Sun, 10 Jun 2018 19:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2zVIQBuxB5D84B5lyeuV6e9/ac6LKeQm0UqZKnfCq9A=; b=qGkS8TIC8WMbeob52g7nYxW+MGWNYe8RVnv3swUDmSAyW8Go+qA34N9selPcju+PYG OhQiCsCBZYKpNk1OuP9fHxfUUSNFDxQ3wB7NP8AReK3Myhv7NO1R7A/9KiZMeP13XLew h4pXNBZWg8wdgJldK8wgjJZCQquNjRc0cq/g2yvVmFox5o/uIIlQ0rraHSmNFh3fqzjK dhYKDEBDsjY2l62al/wkLrWvrh0vyC3T1f6oNoxL45u9L1pl0kIqBGf20WReDXJT1Ewr rIArN4gdlvMMaxicYqpamdakItE3st04mWaKMYD2fhI0oUY3MoMeYpwgMIYzvVBOnK2M xD6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2zVIQBuxB5D84B5lyeuV6e9/ac6LKeQm0UqZKnfCq9A=; b=KD4KxQkhB8/oT5BmLkR3spPzjSn06eetCb6Of+6VEvoh33kZ6ODxUWhvtDgJ3LLjge DKJiCkJHOQ7TBgZFPly0LEO4werg4s3HaPP2ISv83wci2WOH4XxbipviJpRK2AUdK8sj k9YmumyFUXfoFh+L9vhiufwyVMSw5/2k88rbAnydA1YPRw3+2bmahxo7VvoWSRsxgMIC tmDxNz5PTo7EbPRDcLAAUtvbK022TXiB9LhfRFZ53wLCrVDKpQcOPuHmNQAgWGJiJcs4 370ytMzC6nE7rHBWYCorFNTYMX5C3GrpRr4pnlDKL3DmTup+rCUDEp1/vD6RZPhzjhvL 8s4g== X-Gm-Message-State: APt69E0EPFYosnpmsI41JeksffuCSp6hOyYCM2EqrmTPClhEozOR+d2x +EWH8h/YcKmaQtdOpCFgS0w= X-Google-Smtp-Source: ADUXVKKPDx6IvUxGoJ/gYB/421U8MTanc5yr7llgi30rh09DAGueiMI9Wc6wO+zHalsjcyTiJInFeg== X-Received: by 2002:a37:1314:: with SMTP id d20-v6mr13026454qkh.422.1528682773743; Sun, 10 Jun 2018 19:06:13 -0700 (PDT) Received: from [192.168.5.29] (rrcs-24-97-200-194.nys.biz.rr.com. [24.97.200.194]) by smtp.gmail.com with ESMTPSA id 79-v6sm18872488qkv.48.2018.06.10.19.06.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jun 2018 19:06:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Tony Li In-Reply-To: Date: Sun, 10 Jun 2018 15:34:49 -0700 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <90D2906A-D471-4C66-99E9-4F93BEF4ED0F@gmail.com> References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 02:06:16 -0000 Alex, > The IPv4 problem of this 'first way' is that in IPv4 there are not = many platforms that implement IPv4 Router Advertisement. And if we want = to do IPv4 deployment similar to IPv6 deployment then we would have = preferred to use IPv6 RAs (that all routers do) _and_ IPv4 RA. For IPv4 router based deployments this is a solved problem through the = use of DHCP. The client requests an address and is provided one, along = with router information. There is no good reason not to use this = mechanism in any router based OCB subnet. For ad-hoc OCB subnets, it makes sense to use IPv4 link local = addressing. There are already well-documented mechanisms for this that = ensure that nodes avoid address collisions. I know of no reason not to = make use of this. I also see no reason not to use the analogous mechanisms in IPv6. >=20 > Here, the ND protocol needs much more tweaks than simple parameters. = One important new thing is a prefix that must be put in this RA. Of = course, RAs already has prefixes, but the prefix I am writing about is = different: it is not the prefix on the link, but the prefix(es) present = inside the car. So one car informs another car about its own inner = prefixes. Using ND as a routing protocol has been discussed many times. It is not = advisable. It does not prefix collisions nor multi-hop scenarios. If we = want a routing protocol, we should use a routing protocol. Tony From nobody Sun Jun 10 19:06:23 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D43130F43 for ; Sun, 10 Jun 2018 19:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJP8e-hFKcPb for ; Sun, 10 Jun 2018 19:06:17 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 9FF91126DBF for ; Sun, 10 Jun 2018 19:06:17 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id c131-v6so3546813qkb.0 for ; Sun, 10 Jun 2018 19:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gFYlUzmTm7EJwd/dbOvbGKgE1OXcmlNJBxmRJzW1wWo=; b=aDtG4RlrgDQrw+mAqmeDj5oYd9KjRdyWQEgIS2sbrNB4EaJMjLS0mHPZErF97mJ4k1 b4Kve2gQI6ARmdgWHVETEclr09BmBIVwUT8aMo3cvcWadMkKe5lRPNnT4ie1H4H0j4kO Zil0lMUAeeGNXv3fI489+cpaig9ap9/kjOCUL8Q1TjlzBeeVXeJjneML/YjfbSkaJeZF q/FCvp0HjTmOMea/L8nPQ3KXCV5uGTpwQ+IDux9CzvLn8TtNCWAxqTo3i7MS4aW1M7qs cSFhHwYSbKJoY+O2HjI1LT+Hc6+ZQZ1d9IWa/VBdcCCk5Pb7zwtw6+n0xy/QB9jSm7wr OLrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gFYlUzmTm7EJwd/dbOvbGKgE1OXcmlNJBxmRJzW1wWo=; b=ZG554zEFx2N665Jz8OXNJPJ5DWPp2hcPBiGgHP4fqgnyJ4QNqLDC2/eeMs1CxTA9+G 9g/RQWj6pEkKb5zYUqecOgV2JBoBibciclF+HNztt/xPF4CrOnaVZt/38s+K3X+2kPS6 /JSgAzFvwgOfBKv7903tJPxF/3ep+3fHPPHkgkpV9UnfqYmbVj8pXuhIOoWK5RMdkp1U Nwll5MgYv2NknjVi1oEGpkQVkLGlKvHMR5/uSQLhvp1z6N3M4u8c/oObV1DsMwdciUq+ IVicuTeoQxtoqRK6sjDvrpDddvKZnlq2ncJx2Kx3gqLS0u8jHdhVAYD9QlG9Zdb+vfGT +9gg== X-Gm-Message-State: APt69E0Sbl770y/NPBAoN2kKXATGt1c9/AnBhFfEBbE4qY0sUTW8D7KI tOzNLTwJbxNj44/TvQ5mItxckViw X-Google-Smtp-Source: ADUXVKKzKGRBhqDYRt2I7Xgy3jbY1DLfQLbtk4ya+xstTBhuchqmczu4uhOFV9HnDa7YqYjJMhH85Q== X-Received: by 2002:a37:105c:: with SMTP id a89-v6mr13275257qkh.441.1528682776789; Sun, 10 Jun 2018 19:06:16 -0700 (PDT) Received: from [192.168.5.29] (rrcs-24-97-200-194.nys.biz.rr.com. [24.97.200.194]) by smtp.gmail.com with ESMTPSA id 79-v6sm18872488qkv.48.2018.06.10.19.06.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jun 2018 19:06:16 -0700 (PDT) From: Tony Li Message-Id: <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B59FF6A4-00B0-491D-8774-F2A00893990D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 10 Jun 2018 15:43:04 -0700 In-Reply-To: Cc: its@ietf.org To: Alexandre Petrescu References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 02:06:22 -0000 --Apple-Mail=_B59FF6A4-00B0-491D-8774-F2A00893990D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Despite the ultra-importance of accident avoiding, this view is still = a too narrow view of 'vehicular communications'. Where is the Internet = in this 'vehicular communications=E2=80=99? The Internet is largely irrelevant. If we simply enable IP connectivity, = then we have an infrastructure to enable any application. Internet = access falls out for free. > The use of IP unicast in vehicle-to-vehicle communications is the = following: >=20 > top-antenna = top-antenna > | = | =09 > front-antenna--CAR1--rear-atenna front-antenna--CAR2--rear-atenna >=20 > In this view, CARs 'broadcast' CAMs on a particular 5.9GHz channel on = their top antennas, but use IP between rear-antenna and front-antenna. = They are on distinct interfaces than top antenna, different 5.9GHz = channel than from top antenna, but on same 5.9GHz channel between front = of a car and rear of another car. Channel mgmt is performed by = somebody. I=E2=80=99ll avoid the question of who the =E2=80=98somebody=E2=80=99 is = and point out that you=E2=80=99ve then posited the creation of four = separate IP subnets here:=20 1) top-antennas 2) front of Car1 3) between the two Cars 4) rear of Car2 >=20 > So one has an IP subnet between CAR1 rear-antenna and CAR2 = front-antenna. >=20 > On this IP subnet the ND protocol works. >=20 > The way it works is like on an Ethernet in the Enterprise network: use = the IPv6 'unicast' and 'multicast' concept of IPv6 MLD. >=20 > The ND problem in this space is the exchange of prefixes. We have = solved it with software and a draft. >=20 > The 'multicast' problem in this space is the following: a PC inside a = car needs to send a convoy 'maintenance' message to each other similar = PC in each other car in a convoy (not to the Routers in the cars, but to = the PCs in charge of automated driving). Is MLD sufficient to establish = the multicast tree? Which multicast address to use? This is my = 'multicast' problem right now. Given that you=E2=80=99ve chosen to model this as four separate subnets, = the obvious approach would be to employ existing multicast routing = protocols. This then becomes a trivial topology. Tony --Apple-Mail=_B59FF6A4-00B0-491D-8774-F2A00893990D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Despite the = ultra-importance of accident avoiding, this view is still a too narrow = view of 'vehicular communications'.  Where is the Internet in this = 'vehicular communications=E2=80=99?


The Internet is largely = irrelevant. If we simply enable IP connectivity, then we have an = infrastructure to enable any application. Internet access falls out for = free.

The use of IP = unicast in vehicle-to-vehicle communications is the following:

        =             top-antenna     =                     =               top-antenna
        =                     =  | =          =                     =                |
 front-antenna--CAR1--rear-atenna =  front-antenna--CAR2--rear-atenna

In this view, CARs 'broadcast' CAMs on a particular 5.9GHz = channel on their top antennas, but use IP between rear-antenna and = front-antenna. They are on distinct interfaces than top antenna, = different 5.9GHz channel than from top antenna, but on same 5.9GHz = channel between front of a car and rear of another car.  Channel = mgmt is performed by somebody.


I=E2=80=99ll avoid the = question of who the =E2=80=98somebody=E2=80=99 is and point out that = you=E2=80=99ve then posited the creation of four separate IP subnets = here: 
1) top-antennas
2) front of = Car1
3) between the two Cars
4) rear of = Car2


So one has an = IP subnet between CAR1 rear-antenna and CAR2 front-antenna.

On this IP subnet the ND = protocol works.

The way it works is like on an Ethernet in the Enterprise = network: use the IPv6 'unicast' and 'multicast' concept of IPv6 = MLD.

The ND = problem in this space is the exchange of prefixes.  We have solved = it with software and a draft.

The 'multicast' problem in this space is the following: a PC = inside a car needs to send a convoy 'maintenance' message to each other = similar PC in each other car in a convoy (not to the Routers in the = cars, but to the PCs in charge of automated driving).  Is MLD = sufficient to establish the multicast tree?  Which multicast = address to use?  This is my 'multicast' problem right = now.

Given that you=E2=80=99ve chosen to model this as four = separate subnets, the obvious approach would be to employ existing = multicast routing protocols. This then becomes a trivial = topology.


Tony

= --Apple-Mail=_B59FF6A4-00B0-491D-8774-F2A00893990D-- From nobody Mon Jun 11 02:45:58 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7ADF130F59 for ; Mon, 11 Jun 2018 02:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEvkv5CRDyQo for ; Mon, 11 Jun 2018 02:45:54 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28630130DDA for ; Mon, 11 Jun 2018 02:45:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5B9jpp6154960; Mon, 11 Jun 2018 11:45:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7DE6D2023A4; Mon, 11 Jun 2018 11:45:51 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6E93F201AE1; Mon, 11 Jun 2018 11:45:51 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5B9joEQ032085; Mon, 11 Jun 2018 11:45:51 +0200 To: Tony Li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <90D2906A-D471-4C66-99E9-4F93BEF4ED0F@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 11 Jun 2018 11:45:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <90D2906A-D471-4C66-99E9-4F93BEF4ED0F@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 09:45:57 -0000 Le 11/06/2018 à 00:34, Tony Li a écrit : > > Alex, > > >> The IPv4 problem of this 'first way' is that in IPv4 there are not >> many platforms that implement IPv4 Router Advertisement. And if we >> want to do IPv4 deployment similar to IPv6 deployment then we would >> have preferred to use IPv6 RAs (that all routers do) _and_ IPv4 >> RA. > > > For IPv4 router based deployments this is a solved problem through > the use of DHCP. The client requests an address and is provided one, > along with router information. There is no good reason not to use > this mechanism in any router based OCB subnet. Whereas I agree in IPv4 the use of the DHCP protocol is very useful, it can not be used to detect the presence of RSUs. The IP-OBU can not keep sending DHCP requests and wait for replies from candidate RSUs. Because the wait time is the time that people will feel as too long and will complain about it. Another reason why it can not be this way in IPv4 (DHCP) is the following: in IPv6 the logic is reversed: the IP-OBU listens to RAs (without requesting them). The RAs are 'beaconed' very frequently by the RSU. It is hard to do things in one way in IPv6 and in another way in IPv4. It is too much work for the programmer, and hard to debug by other programmers. The way to do it in IPv4 that is very much like IPv6 is to use IPv4 Router Advertisements RFC1256. As a reminder, the goal of these messages sent by RSU is for the IP-OBU to be able to measure their signal strength, and less the read the values specified by the RFC. The useful value is found in the Radiotap Header (signal strength). These messages just have to be 'beaconed' periodically by the RSU. > For ad-hoc OCB subnets, it makes sense to use IPv4 link local > addressing. There are already well-documented mechanisms for this > that ensure that nodes avoid address collisions. I know of no reason > not to make use of this. I agree: use IPv4 link-local addresses in IPv4 in OCB mode. The IPv6 ND question is the following: is it appropriate for IP-OBU to rely on IPv6 RAs to sense the presence of IP-RSU? My answer is yes. It is more appropriate than beaconing TSAs, 802.21 messages or IEEE WSAs. If it were me I would put that in the draft IPv6-over-OCB right away. > I also see no reason not to use the analogous mechanisms in IPv6. I agree, we should use link-local addresses for communication between IP-OBU and IP-RSU, at least until it gets GUAs or ULAs. For IP-OBU to IP-OBU communications also the link local addresses can be used. But in that case (IP-OBU to IP-OBU) it is not clear if ever will there be a GUA or ULA set of interfaces. PRobably these ULAs or GUAs are not needed there. >> Here, the ND protocol needs much more tweaks than simple >> parameters. One important new thing is a prefix that must be put in >> this RA. Of course, RAs already has prefixes, but the prefix I am >> writing about is different: it is not the prefix on the link, but >> the prefix(es) present inside the car. So one car informs another >> car about its own inner prefixes. > > > Using ND as a routing protocol has been discussed many times. It is > not advisable. Well, I strongly recommend it. > It does not prefix collisions nor multi-hop scenarios. I think no routing protocol identifies prefix collisions. I think ND exchanging prefixes works very well in scenarios of convoy of 3 vehicles. Generally speaking, in linear structures like trains of wagons, or convoys: ND exchanging prefixes works very well. > If we want a routing protocol, we should use a routing protocol. I dont think we want a routing protocol in a convoy. Routing protocols implement very complicated algorithms like Yen, Bellman-Ford, or others, which are not really necessary in such stable structures such as convoys. It's too big of a hammer if I can say so. Alex > > Tony > > From nobody Mon Jun 11 03:49:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AB1130E2E for ; Mon, 11 Jun 2018 03:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY_p_ezYUnFa for ; Mon, 11 Jun 2018 03:49:01 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AC112777C for ; Mon, 11 Jun 2018 03:49:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5BAmxxv011951; Mon, 11 Jun 2018 12:48:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 78A66202B8C; Mon, 11 Jun 2018 12:48:59 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6AB952023CF; Mon, 11 Jun 2018 12:48:59 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5BAmxC2005997; Mon, 11 Jun 2018 12:48:59 +0200 To: Tony Li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> From: Alexandre Petrescu Message-ID: <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> Date: Mon, 11 Jun 2018 12:48:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 10:49:04 -0000 Le 11/06/2018 à 00:43, Tony Li a écrit : > > >> Despite the ultra-importance of accident avoiding, this view is still >> a too narrow view of 'vehicular communications'.  Where is the >> Internet in this 'vehicular communications’? > > > The Internet is largely irrelevant. If we simply enable IP connectivity, > then we have an infrastructure to enable any application. Internet > access falls out for free. I agree. But if there is no default router then there is no Internet. No CAM messaging provides a default route. A Router Advertisement does. > >> The use of IP unicast in vehicle-to-vehicle communications is the >> following: >> >>                     top-antenna >> top-antenna >>                              |                                           | >>  front-antenna--CAR1--rear-atenna  front-antenna--CAR2--rear-atenna >> >> In this view, CARs 'broadcast' CAMs on a particular 5.9GHz channel on >> their top antennas, but use IP between rear-antenna and front-antenna. >> They are on distinct interfaces than top antenna, different 5.9GHz >> channel than from top antenna, but on same 5.9GHz channel between >> front of a car and rear of another car.  Channel mgmt is performed by >> somebody. > > > I’ll avoid the question of who the ‘somebody’ is In the first demonstration that somebody is a human, probably me. I will allocate initially fixed channels between the three cars. When that works, we will look at about how to automate it. I dont think it is difficult and it will be a pleasure to come up with an algorithm. > and point out that > you’ve then posited the creation of four separate IP subnets here: > 1) top-antennas The top-antenna may make an IP subnet with the RSU, yes. > 2) front of Car1 front of Car1 and rear of Car2 form a single IP subnet. > 3) between the two Cars The IP subnet between two Cars is the same IP subnet as the IP subnet of the rear antenna of Car1 and the IP subnet of Car2. There is just one IP subnet between Car1 and Car2, and the members of that subnet are the front-antenna of Car1 and rear-antenna of Car2. > 4) rear of Car2 > >> >> So one has an IP subnet between CAR1 rear-antenna and CAR2 front-antenna. >> >> On this IP subnet the ND protocol works. >> >> The way it works is like on an Ethernet in the Enterprise network: use >> the IPv6 'unicast' and 'multicast' concept of IPv6 MLD. >> >> The ND problem in this space is the exchange of prefixes.  We have >> solved it with software and a draft. >> >> The 'multicast' problem in this space is the following: a PC inside a >> car needs to send a convoy 'maintenance' message to each other similar >> PC in each other car in a convoy (not to the Routers in the cars, but >> to the PCs in charge of automated driving).  Is MLD sufficient to >> establish the multicast tree?  Which multicast address to use?  This >> is my 'multicast' problem right now. > > Given that you’ve chosen to model this as four separate subnets, the > obvious approach would be to employ existing multicast routing > protocols. This then becomes a trivial topology. I would very much like if only one protocol were used. I dont want _one_ protocol for IP routing, another one for multicast routing, and probably 3rd protocol for link-scoped multicast. I want that protocol to be cheap open source, proven to work in this topology, to download and play with it right away. PC1 must send a maintenance IP message to PC2 and PC3, as an IP multicast message. I dont want PC1 to send a distinct message to each other PCx in the convoy because it wont scale. s4 s5 IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x | | | PCx: Autonomous Drv. PC w/ RTMaps |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode | | | s1, s2, s3: Ethernet PC1 PC2 PC3 Alex > > > Tony > From nobody Mon Jun 11 06:03:44 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D32130E35 for ; Mon, 11 Jun 2018 06:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgm3rN0JsH1u for ; Mon, 11 Jun 2018 06:03:36 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 9AEF2130DC8 for ; Mon, 11 Jun 2018 06:03:36 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id g14-v6so12823675qkm.6 for ; Mon, 11 Jun 2018 06:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eEErKORWwy/Q0WUapGk3HK4tyb75xmeTcrEggH6M9Jw=; b=QZaxcV/7gl4q4ocWjFA2qDcfwit8RM753wT7EZKI0s8CjgHquaBKL8oAdV5GQPFw6X +2HHJFG8RHF2Fqo5OsehI41cE/1OkwubHDFHeEMqA6cbCvw2RmJ1sutHtvxQa6j1rCyB BGbrIvDlvAIZzmhv1os7z0I6snmI/esxiGYjnH6NsYL5mhC9UwW0SH7ePW6aPTqDtr5l ThPON/o9bKK3jU7B+QtbdkE2av+cr+AHpU/rOlzrwNY7Uz9HfE1Huk5OpvHsyxwjUIzi rJU3vnyjNPAlMIjmyUSaGa/B29vJN1eUDMmBtArIYwzuBe1GD7+m1ZwKQDtxtMAYqlgD gHIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=eEErKORWwy/Q0WUapGk3HK4tyb75xmeTcrEggH6M9Jw=; b=s0tlP8wTfIvsdbdWXyzC6EkmljjJ0xR38kJxS3RTQPssKOI3wLzzNHhuvuCxakhLVv O+VhI9fTui1QdEHiUzgV3wdrkm8DMEMRLdPrW/54Qd6edtMdcsU1eocB1QeNg7AJE57z MHSpTFtx7ZKh5L+6ajUT7rVPdjsF7ofX5OXVcbKWh42qynr8sY+haEWeZTbRs0hmqAZv P26rCPRK9U7uTlFbycTmrI4pAnFF4gunIImJFreaeqTuj21qigESxGTc1F0LjyEaPBzS WE8RCt86kDAItY4B4OegH/YAzNn/gDAVflmoaPl4RyWDFYjN/grzWbW5FdXLYarANtZA Bc7Q== X-Gm-Message-State: APt69E11M82s9T4coCHxVb9WJ6j5d/vA4zGs64GZtZMmUhP2oAKC9vYp tDND+uNu6FdhegIiWGc0S08= X-Google-Smtp-Source: ADUXVKJC08tn3OiulZBKDKuVRRn9fW2s5ehNVGx3eIXpKdIQExaKEq10s343+09BflSUXQdrIMQUAQ== X-Received: by 2002:a37:76c3:: with SMTP id r186-v6mr14572540qkc.409.1528722215630; Mon, 11 Jun 2018 06:03:35 -0700 (PDT) Received: from [192.168.5.29] (rrcs-24-97-200-194.nys.biz.rr.com. [24.97.200.194]) by smtp.gmail.com with ESMTPSA id z202-v6sm14107598qka.8.2018.06.11.06.03.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 06:03:34 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: tony.li@tony.li In-Reply-To: Date: Mon, 11 Jun 2018 09:03:33 -0400 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C1C8D49-2189-4174-A92D-0DFC58CB791F@tony.li> References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <90D2906A-D471-4C66-99E9-4F93BEF4ED0F@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 13:03:42 -0000 Alex, > The IP-OBU can not keep sending DHCP requests and wait for replies = from candidate RSUs. Because the wait time is the time that people will = feel as too long and will complain about it. Ok, that presumes some requirements that haven=E2=80=99t been shared. Normally DHCP response is quite rapid. On a Wi-Fi network, it=E2=80=99s = less than the association time. > Another reason why it can not be this way in IPv4 (DHCP) is the = following: in IPv6 the logic is reversed: the IP-OBU listens to RAs = (without requesting them). The RAs are 'beaconed' very frequently by = the RSU. It is hard to do things in one way in IPv6 and in another way = in IPv4. It is too much work for the programmer, and hard to debug by = other programmers. This sounds like a personal problem. :-) There is always DHCPv6, if you choose.=20 > The way to do it in IPv4 that is very much like IPv6 is to use IPv4 = Router Advertisements RFC1256. Yes. That was widely ignored. We can invoke it, but it will not be the = obvious approach for most folks. > The IPv6 ND question is the following: is it appropriate for IP-OBU to = rely on IPv6 RAs to sense the presence of IP-RSU? My answer is yes. I concur. That=E2=80=99s what they=E2=80=99re there for. > For IP-OBU to IP-OBU communications also the link local addresses can = be used. But in that case (IP-OBU to IP-OBU) it is not clear if ever = will there be a GUA or ULA set of interfaces. PRobably these ULAs or = GUAs are not needed there. I concur. Link local alone is sufficient for ad-hoc ephemeral = connections, which is what we should be assuming for the V2V case. >=20 > I think ND exchanging prefixes works very well in scenarios of convoy = of 3 vehicles. Generally speaking, in linear structures like trains of = wagons, or convoys: ND exchanging prefixes works very well. Yes, but how does it scale? How does it deal with loops in the = topology? Topological changes? >> If we want a routing protocol, we should use a routing protocol. >=20 > I dont think we want a routing protocol in a convoy. Each to their own. I see no good alternative. > Routing protocols implement very complicated algorithms like Yen, = Bellman-Ford, or others, which are not really necessary in such stable = structures such as convoys. It's too big of a hammer if I can say so. Actually, the better ones implement an even more complicated algorithm = called Dijkstra. ;-) If there=E2=80=99s one thing I know about wireless, it=E2=80=99s never = to say =E2=80=98stable=E2=80=99. ;-) Tony From nobody Mon Jun 11 20:25:04 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52D9130F12 for ; Mon, 11 Jun 2018 20:25:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG2vJOLKEe8L for ; Mon, 11 Jun 2018 20:24:58 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 8EF7D130F07 for ; Mon, 11 Jun 2018 20:24:58 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id x34-v6so22445078qtk.5 for ; Mon, 11 Jun 2018 20:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5w5x9tZhdjmASEI5ltDawnu6+XgXbueCQrrvUeIBEqk=; b=KFu1/EBQau0einqgz1TDO3YllxUBIqNJmefbnuFnik5RivqDIqAdkiit8UKpm6b26F ggl0U71A9cNa/1Z7bPEBs/REmulC3V65anqSqLTy1JUyPkjKH7+HF+SzSqPgSghmpYsK I2ZQpyZ4XeoF8I3dTX+zfC1xhXgXIylvcNfS0+L88F17/txcuXd+xBnYXojZCOrr7cr4 CUinbFpRwzda+RLxIIW75/BdA5ixWl6R3Z5Co91kMINmLo1Sdb96QqR2pu/8HNwlpB7L LY4bq9NcxthymXbTtq3Rt96wndowkLdaefp+RuRVomkl7YSC5pViG5iDOQ7AYSwUsf2i nt7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5w5x9tZhdjmASEI5ltDawnu6+XgXbueCQrrvUeIBEqk=; b=YssGHwjohpI/0/EhGw4YbiZKINmbrvuoDN9Uqnzab5feLPy0tzBiRDbeBRv8q3Fmyc Z2iKi/QpImc1tCPj5mweTedzzitoTJzls0Te2IehoEhVr94bMr1KrxTH3cY4cBXgHgSW f8HpDODxEBBzwGIePOpD8YlgQ/jqrBgSq5pO7nXXYi+xW13QkmmKTwaoZP8kn4Jp1WBy /FwdSYMZEZl/kd2mBWBAonXBED71DQT5MdEHsYlZ80vGmYNrgifbW53zSzJOn5p75TVB tvfRdL1MqPDOx+i10K0pFIG5mOhHyWFmnm7ONZ4Mqi3isqeNG8RUvxgi48lRtL3WdlAG vj5w== X-Gm-Message-State: APt69E3SoiOx+82O2mqAxFhLrnvNCdetIZGi8culZaVz5iLPSNQWTkVQ aoj3vK48OaR4EBuhDTmTgHg= X-Google-Smtp-Source: ADUXVKKhj0nVc2RTTNS0cWdJHLZr9bcGCRvXxOKcSKAaY3APqgngiaNpd2xGcc7YXF+2OsXZqYgvDA== X-Received: by 2002:a0c:d08c:: with SMTP id z12-v6mr1766591qvg.195.1528773897697; Mon, 11 Jun 2018 20:24:57 -0700 (PDT) Received: from [172.20.11.23] (50-78-157-210-static.hfc.comcastbusiness.net. [50.78.157.210]) by smtp.gmail.com with ESMTPSA id w21-v6sm27304092qkb.36.2018.06.11.20.24.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 20:24:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Tony Li In-Reply-To: <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> Date: Mon, 11 Jun 2018 23:24:55 -0400 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 03:25:02 -0000 Alex, >> 1) top-antennas >=20 > The top-antenna may make an IP subnet with the RSU, yes. >=20 >> 2) front of Car1 >=20 > front of Car1 and rear of Car2 form a single IP subnet. >=20 >> 3) between the two Cars >=20 > The IP subnet between two Cars is the same IP subnet as the IP subnet = of the rear antenna of Car1 and the IP subnet of Car2. >=20 > There is just one IP subnet between Car1 and Car2, and the members of = that subnet are the front-antenna of Car1 and rear-antenna of Car2. Ok, if you choose to model things this way, then you effectively have = only two subnets, one for the top antenna and one for everything else. = This CAN work for some things, but will necessarily be problematic in = some ways. As the convoy grows, the front antenna on the front car may = not have connectivity to the back antenna on the rear car. As such, = your subnet may not be fully connected, and that=E2=80=99s going to = cause some confusion and failures.=20 I don=E2=80=99t recommend this approach. If it were up to me, I would = make each pairing a separate subnet and enable routing. >=20 > I dont want _one_ protocol for IP routing, another one for multicast = routing, and probably 3rd protocol for link-scoped multicast. Well, sorry, the IP protocol stack decouples multicast and unicast = routing. We made that call along time ago, as having their development = coupled would have slowed both of them. >=20 > PC1 must send a maintenance IP message to PC2 and PC3, as an IP = multicast message. I dont want PC1 to send a distinct message to each = other PCx in the convoy because it wont scale. >=20 > s4 s5 > IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x > | | | PCx: Autonomous Drv. PC w/ RTMaps > |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode > | | | s1, s2, s3: Ethernet > PC1 PC2 PC3 That can work as long as the convoy is all in range of a single radio = and then it is just a link layer multicast. Tony From nobody Tue Jun 12 00:24:37 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0081B130E0A for ; Tue, 12 Jun 2018 00:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0dKhbWUGT63 for ; Tue, 12 Jun 2018 00:24:31 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09D8130DFC for ; Tue, 12 Jun 2018 00:24:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5C7OQsr048118; Tue, 12 Jun 2018 09:24:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BCBBA2023EA; Tue, 12 Jun 2018 09:24:26 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AE3D9200EA3; Tue, 12 Jun 2018 09:24:26 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5C7OQrg019674; Tue, 12 Jun 2018 09:24:26 +0200 To: tony.li@tony.li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <90D2906A-D471-4C66-99E9-4F93BEF4ED0F@gmail.com> <1C1C8D49-2189-4174-A92D-0DFC58CB791F@tony.li> From: Alexandre Petrescu Message-ID: Date: Tue, 12 Jun 2018 09:24:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1C1C8D49-2189-4174-A92D-0DFC58CB791F@tony.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 07:24:35 -0000 Le 11/06/2018 à 15:03, tony.li@tony.li a écrit : > Alex, > >> The IP-OBU can not keep sending DHCP requests and wait for replies >> from candidate RSUs. Because the wait time is the time that people >> will feel as too long and will complain about it. > > > Ok, that presumes some requirements that haven’t been shared. > > Normally DHCP response is quite rapid. On a Wi-Fi network, it’s less > than the association time. However we express DHCP to be fast, it will always be at least the double of the speed of using beacons. DHCP is a request-response, whereas the 'beaconing' mechanisms are just the advertisement message (just the response, if you wish). > > >> Another reason why it can not be this way in IPv4 (DHCP) is the >> following: in IPv6 the logic is reversed: the IP-OBU listens to RAs >> (without requesting them). The RAs are 'beaconed' very frequently >> by the RSU. It is hard to do things in one way in IPv6 and in >> another way in IPv4. It is too much work for the programmer, and >> hard to debug by other programmers. > > > This sounds like a personal problem. :-) YEs, it is a personal problem. Maybe other person has tried IPv4 and IPv6 on OCB IP-RSU. > > There is always DHCPv6, if you choose. > >> The way to do it in IPv4 that is very much like IPv6 is to use IPv4 >> Router Advertisements RFC1256. > > > Yes. That was widely ignored. We can invoke it, but it will not be > the obvious approach for most folks. The issue is to choose _which_ message to use as a beacon on IP-RSU. Should we use an IP message as 'beacon', or something else? If we said that IPv4 RAs and IPv6 RAs are good candidates then IP is the right messagge for 'beacon'. But if we say that IPv6 RA is fine, whereas in IPv4 RA is not appropriate and DHCP is more appropriate, then the other non-IP candidates will look more attractive (WSA, TSA, 802.21) because they will always be faster than DHCP. >> The IPv6 ND question is the following: is it appropriate for IP-OBU >> to rely on IPv6 RAs to sense the presence of IP-RSU? My answer is >> yes. > > > I concur. That’s what they’re there for. > > >> For IP-OBU to IP-OBU communications also the link local addresses >> can be used. But in that case (IP-OBU to IP-OBU) it is not clear >> if ever will there be a GUA or ULA set of interfaces. PRobably >> these ULAs or GUAs are not needed there. > > > I concur. Link local alone is sufficient for ad-hoc ephemeral > connections, which is what we should be assuming for the V2V case. > >> >> I think ND exchanging prefixes works very well in scenarios of >> convoy of 3 vehicles. Generally speaking, in linear structures >> like trains of wagons, or convoys: ND exchanging prefixes works >> very well. > > > Yes, but how does it scale? Yes. However long the convoy is the route propagation will scale. The speed of propagation is something like n(n-1)/2 if I remember correctly. It scales better than repeating messages at link-layer. But of course it depends of what one considers by 'scaling' - which factors. > How does it deal with loops in the > topology? On one hand, there are no loops in a convoy: it's linear. Second, there are some proposals to try to answer to that question. An implementer reserved two bits in the 'R' field of an RA and thought (without writing it down) to use these fields to solve such a loop if it appeared. draft-pfister-moving-net-autoconf-00 > Topological changes? I hope topological changes dont appear. I hope once formed the convoy stays that way for a long time. Convoy demonstrators strive for arbitrary position of vehicle in convoy, but in practice they do use lots of manual configurations and dedicated positions. In the future this may become more dynamic. >>> If we want a routing protocol, we should use a routing protocol. >> >> I dont think we want a routing protocol in a convoy. > > > Each to their own. I see no good alternative. > > >> Routing protocols implement very complicated algorithms like Yen, >> Bellman-Ford, or others, which are not really necessary in such >> stable structures such as convoys. It's too big of a hammer if I >> can say so. > > > Actually, the better ones implement an even more complicated > algorithm called Dijkstra. ;-) > > If there’s one thing I know about wireless, it’s never to say > ‘stable’. ;-) I tend to agree, yet there is much stability in very many wireless deployments like WiFi access points at conference. A convoy is maintained stable by RTMaps programs that exchange IP datagrams. If the convoy de-stabilizes somehow then there are many other problems than just IP routing or wireless. Alex > > Tony > > From nobody Tue Jun 12 00:29:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD64130DFC for ; Tue, 12 Jun 2018 00:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDAa-MNwIStw for ; Tue, 12 Jun 2018 00:29:40 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EAC12F1A2 for ; Tue, 12 Jun 2018 00:29:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5C7Tbh0050143; Tue, 12 Jun 2018 09:29:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4864D20201B; Tue, 12 Jun 2018 09:29:37 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3A884200E66; Tue, 12 Jun 2018 09:29:37 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5C7Taos023083; Tue, 12 Jun 2018 09:29:37 +0200 To: Tony Li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> From: Alexandre Petrescu Message-ID: <13b7679f-d448-0637-f2a1-84e2c729dd61@gmail.com> Date: Tue, 12 Jun 2018 09:29:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 07:29:43 -0000 Le 12/06/2018 à 05:24, Tony Li a écrit : > > Alex, > > >>> 1) top-antennas >> >> The top-antenna may make an IP subnet with the RSU, yes. >> >>> 2) front of Car1 >> >> front of Car1 and rear of Car2 form a single IP subnet. >> >>> 3) between the two Cars >> >> The IP subnet between two Cars is the same IP subnet as the IP >> subnet of the rear antenna of Car1 and the IP subnet of Car2. >> >> There is just one IP subnet between Car1 and Car2, and the members >> of that subnet are the front-antenna of Car1 and rear-antenna of >> Car2. > > > Ok, if you choose to model things this way, then you effectively have > only two subnets, one for the top antenna and one for everything > else. No. There is one subnet for the top antenna and its RSU, one subnet for rear antenna and one subnet for front antenna. > This CAN work for some things, but will necessarily be > problematic in some ways. As the convoy grows, the front antenna on > the front car may not have connectivity to the back antenna on the > rear car. As such, your subnet may not be fully connected, and > that’s going to cause some confusion and failures. I agree with the problem you describe, but note that this is not what I meant. What I meant is this: one subnet for top antenna with RSU, one subnet in front of car and one subnet in rear of car. With this schema I think it is not problematic. > > I don’t recommend this approach. If it were up to me, I would make > each pairing a separate subnet and enable routing. YEs, this is what we try to do. > >> >> I dont want _one_ protocol for IP routing, another one for >> multicast routing, and probably 3rd protocol for link-scoped >> multicast. > > > Well, sorry, the IP protocol stack decouples multicast and unicast > routing. We made that call along time ago, as having their > development coupled would have slowed both of them. > >> >> PC1 must send a maintenance IP message to PC2 and PC3, as an IP >> multicast message. I dont want PC1 to send a distinct message to >> each other PCx in the convoy because it wont scale. >> >> s4 s5 IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP >> subnet x | | | PCx: Autonomous Drv. PC >> w/ RTMaps |s1 |s2 |s3 s4, s5: IPv6 over OCB, >> in LL mode | | | s1, s2, s3: Ethernet >> PC1 PC2 PC3 > > > That can work as long as the convoy is all in range of a single radio > and then it is just a link layer multicast. > s4 s5 > IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x > | | | PCx: Autonomous Drv. PC w/ RTMaps > |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode > | | | s1, s2, s3: Ethernet > PC1 PC2 PC3 In this schema there is an IP subnet in front of the car (s4) and another IP subnet in the rear of the car (s5). IP routing is enabled. Alex > > Tony > > From nobody Tue Jun 12 00:35:29 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980951310DC for ; Tue, 12 Jun 2018 00:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFt8xfRVd4zt for ; Tue, 12 Jun 2018 00:35:03 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1079E130E0C for ; Tue, 12 Jun 2018 00:34:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5C7Yv41006915; Tue, 12 Jun 2018 09:34:57 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36AEB201C07; Tue, 12 Jun 2018 09:34:57 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 287B420201B; Tue, 12 Jun 2018 09:34:57 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5C7Yu3u028494; Tue, 12 Jun 2018 09:34:57 +0200 To: Tony Li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 12 Jun 2018 09:34:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 07:35:12 -0000 Le 12/06/2018 à 05:24, Tony Li a écrit : [...] >> I dont want _one_ protocol for IP routing, another one for multicast routing, and probably 3rd protocol for link-scoped multicast. > > > Well, sorry, the IP protocol stack decouples multicast and unicast routing. We made that call along time ago, as having their development coupled would have slowed both of them. I can agree. But I need somebody who has tried IPv6 multicast in an IP structure like this. PC1 must send an IP datagram to an IP multicast address to which PC2 and PC3 are part of. > s4 s5 > IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x > | | | PCx: Autonomous Drv. PC w/ RTMaps > |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode > | | | s1, s2, s3: Ethernet > PC1 PC2 PC3 If this does not work with IPv6 multicast between laptops on a table then it will not work in a convoy either. Alex From nobody Tue Jun 12 05:10:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98279130E29 for ; Tue, 12 Jun 2018 05:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy55_ZlYzdPm for ; Tue, 12 Jun 2018 05:10:14 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 068DE126CC7 for ; Tue, 12 Jun 2018 05:10:14 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id c131-v6so6294514qkb.0 for ; Tue, 12 Jun 2018 05:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/UuQYI0PsPuI20QfWwq6LwiZoIOcLiGsnCskaoYp6Zk=; b=YVgzjySb8i4sqY148b1Vruh7cem056sm7WgKUyF5+iIRxijXFIkCnPTFhBYKylpNkQ AF6tTpOu6F4s7wgPcPky4xJxM6+GCeMVn59+26JOcndhSsBzWTL+gCLXhaOJCMO77DxG ugxXvJc6kkmi8zqShky20mO1rW3jh6jqipRJAA0T4Cu4X9esI1iIFb8lQ0X8sF4Cx7Br vVO3r3tKnROJvTKG0mdxj5UAJcHzTQ4f62yET+CmT668N0nmIGRtcf+oCYJW/u7kQNZG erJjh0zVNTpSksbsPJNBDAgvtPmGvW6t0nI8532u81iRi0xcSEwh2mIcTy7EbW55ZjBJ Tb4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=/UuQYI0PsPuI20QfWwq6LwiZoIOcLiGsnCskaoYp6Zk=; b=kvzc4AuoDT05rlP5Fez9JUh5gEPG2+b2kh8YpkJY0wUeznzt284ix1D+6vsuUg6j4H 43aLEVZdJtwHshiGM5Kl6Z5HMVJKyq0PdU4pAYm3HoOJLaZ/THN6lvU0WhIYThzE+hd5 pz3sfELckWJp9Jrd65A9Zl2i0edpbtnY8ShFgWuA4xu9OUvjHkqHGHAgzsh7QSuAJ8BQ n72LA6rsPmK53ZDn7+ieE4L2NOqxQL2v7pJGlrrsRMKhV4y2nl2VslrGtt9F5y4oBk2Y UXNS0id4agQSHDpXYbhPAK+EZyZUWa/OePKMkdkUZNIZ08ldQoMImEawlBwD5YXEFVR2 Eyig== X-Gm-Message-State: APt69E0Ig/cIiCm3iqcGR29f+eHQ/X+lzXUibQYiug+imELo/3DaJdeB qOSqR8SkTJROcca89ooliOc= X-Google-Smtp-Source: ADUXVKJ7d7KRzPf60mlHfyVcJdiblnivKwv9Q0/CON2WKHzT0xPCcZW3pxr2upCgqz/gYjx+3p1zcw== X-Received: by 2002:a37:4917:: with SMTP id w23-v6mr113617qka.328.1528805413204; Tue, 12 Jun 2018 05:10:13 -0700 (PDT) Received: from [172.20.11.23] (50-78-157-210-static.hfc.comcastbusiness.net. [50.78.157.210]) by smtp.gmail.com with ESMTPSA id k30-v6sm4767qtc.31.2018.06.12.05.10.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 05:10:12 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: tony.li@tony.li In-Reply-To: Date: Tue, 12 Jun 2018 08:09:54 -0400 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 12:10:18 -0000 > But I need somebody who has tried IPv6 multicast in an IP structure = like this. PC1 must send an IP datagram to an IP multicast address to = which PC2 and PC3 are part of. >=20 >> s4 s5 >> IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x >> | | | PCx: Autonomous Drv. PC w/ RTMaps >> |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode >> | | | s1, s2, s3: Ethernet >> PC1 PC2 PC3 >=20 > If this does not work with IPv6 multicast between laptops on a table = then it will not work in a convoy either. This should work with IP multicast right out of the box, but you will = need both unicast and mcast protocols, plus mcast listeners. Tony From nobody Tue Jun 12 06:54:53 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4841130F08 for ; Tue, 12 Jun 2018 06:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEQphLIldb2h for ; Tue, 12 Jun 2018 06:54:49 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186BF130E27 for ; Tue, 12 Jun 2018 06:54:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5CDsiDw003712; Tue, 12 Jun 2018 15:54:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 74ED9206BD4; Tue, 12 Jun 2018 15:54:44 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 67201206B87; Tue, 12 Jun 2018 15:54:44 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5CDsi5G021631; Tue, 12 Jun 2018 15:54:44 +0200 To: tony.li@tony.li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> From: Alexandre Petrescu Message-ID: <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> Date: Tue, 12 Jun 2018 15:54:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 13:54:51 -0000 Le 12/06/2018 à 14:09, tony.li@tony.li a écrit : > > >> But I need somebody who has tried IPv6 multicast in an IP structure like this. PC1 must send an IP datagram to an IP multicast address to which PC2 and PC3 are part of. >> >>> s4 s5 >>> IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x >>> | | | PCx: Autonomous Drv. PC w/ RTMaps >>> |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode >>> | | | s1, s2, s3: Ethernet >>> PC1 PC2 PC3 >> >> If this does not work with IPv6 multicast between laptops on a table then it will not work in a convoy either. > > > > This should work with IP multicast right out of the box, but you will need both unicast and mcast protocols, plus mcast listeners. I need to know how it works. I have the ability to some trial here, but if somebody already did, and has some howto, then I would be very much grateful. Alex > > Tony > > From nobody Tue Jun 12 11:25:31 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04482130FA5 for ; Tue, 12 Jun 2018 11:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftwRfSqFgkn2 for ; Tue, 12 Jun 2018 11:25:26 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 CB595130E7B for ; Tue, 12 Jun 2018 11:25:25 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id c198-v6so15647682qkg.12 for ; Tue, 12 Jun 2018 11:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jxkzRuXDJRAN9jWbAC2E4pk6ZIu+1uYqt/Mp8imb8kc=; b=fbdiEuA8S/R0lDGcy5N908r4hl97mor07EzdBo4aMH5ltosnsVuG4zkfESBmbMNH6d D1P2sSersDUBLgeBCGsmHmiBleBdJQSrT55N6H/ZqD7RDGFP/EpB+aGXI0Scgqaqn00W W3Ek71ZIX1FQkcaEASHk1w/kTqfQMTVHhYcEaDtr0A5b1/6oG0QZToS+7ncmVDD+Mzax kEo8Pv9HJCJOPdI5mUdfrtBosGMfFdXCXvSTtGyjhwG1ag1pDpHjlz6oMpDQW0e5YDrZ dFjxNRzF6cNVp0gQ5IlSyCZA25yJi06kMZRFsxfK4mcm1SwFLpRQiaqcheVkzJEZvDHB fbnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=jxkzRuXDJRAN9jWbAC2E4pk6ZIu+1uYqt/Mp8imb8kc=; b=QQOZB0m573kFwHcVabLQEof2KlDTPb94YilUJMnsFz4k9YKn7YJhuTEVudetjHuP7P ocTW/Cr3Unb0O99MYZqLfo7YPI5v3Xa0mD8sXXfPizFIihBJZ6A2+GxHblcmIGc1nsVw v2nfv16FK9PpgatsAdaO+DK7peH/piFUWIzPmEbI8D+IXYrWf+svXAki8/ypKHe0s7Jo tf5QZ1kZE3MTS/eOaMwpd52eNtu4Mx8cbb6R1uAWGDtS9AJCxOsoVt8eLnHfg9F5ih5h MaHNC55hscpLpwByrmd5hB0VMBIC5UZ7PwMWkQX264TZgVW62JqsmoEuUl9UeqNTw6B2 u5XQ== X-Gm-Message-State: APt69E0qC3XxMuDAibTW3SqOYJWYMkACNIBP4zTCyEBH0bPutfajElyA GKd1XAEw4GIvV02WdwArkB4= X-Google-Smtp-Source: ADUXVKIwLu3K/Aodb3fBUZAvuI20WF9fZEIDasksmfoBZd+m2cXcAVdbCR+2H6s/TE8PzMEbyG7VUg== X-Received: by 2002:a37:28c4:: with SMTP id o65-v6mr1579783qko.200.1528827924955; Tue, 12 Jun 2018 11:25:24 -0700 (PDT) Received: from [10.36.135.134] ([69.241.19.12]) by smtp.gmail.com with ESMTPSA id s39-v6sm702156qts.42.2018.06.12.11.25.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 11:25:24 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: tony.li@tony.li In-Reply-To: <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> Date: Tue, 12 Jun 2018 14:25:23 -0400 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 18:25:28 -0000 >>> But I need somebody who has tried IPv6 multicast in an IP structure = like this. PC1 must send an IP datagram to an IP multicast address to = which PC2 and PC3 are part of. >>>=20 >>>> s4 s5 >>>> IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x >>>> | | | PCx: Autonomous Drv. PC w/ = RTMaps >>>> |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL = mode >>>> | | | s1, s2, s3: Ethernet >>>> PC1 PC2 PC3 >>>=20 >>> If this does not work with IPv6 multicast between laptops on a table = then it will not work in a convoy either. >> This should work with IP multicast right out of the box, but you will = need both unicast and mcast protocols, plus mcast listeners. >=20 > I need to know how it works. I have the ability to some trial here, = but if somebody already did, and has some howto, then I would be very = much grateful. This is unicast and mcast 101. Almost any PD stack that has OSPF and an = mcast protocol will work. DVMRP is sufficient, if wildly antiquated. = PIM-DM would also work. There are of course more sophisticated variants of PIM if you can find them. Your app will need to generate IGMP Joins. Tony From nobody Wed Jun 13 01:26:53 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2921A130E0E for ; Wed, 13 Jun 2018 01:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx-oqKHgaZGb for ; Wed, 13 Jun 2018 01:26:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE3A130E05 for ; Wed, 13 Jun 2018 01:26:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5D8QgZt083437; Wed, 13 Jun 2018 10:26:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 27906202895; Wed, 13 Jun 2018 10:26:42 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 192BE202707; Wed, 13 Jun 2018 10:26:42 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5D8QfVb011319; Wed, 13 Jun 2018 10:26:42 +0200 To: tony.li@tony.li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> From: Alexandre Petrescu Message-ID: <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> Date: Wed, 13 Jun 2018 10:26:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 08:26:51 -0000 Le 12/06/2018 à 20:25, tony.li@tony.li a écrit : > >>>> But I need somebody who has tried IPv6 multicast in an IP structure like this. PC1 must send an IP datagram to an IP multicast address to which PC2 and PC3 are part of. >>>> >>>>> s4 s5 >>>>> IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x >>>>> | | | PCx: Autonomous Drv. PC w/ RTMaps >>>>> |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode >>>>> | | | s1, s2, s3: Ethernet >>>>> PC1 PC2 PC3 >>>> >>>> If this does not work with IPv6 multicast between laptops on a table then it will not work in a convoy either. >>> This should work with IP multicast right out of the box, but you will need both unicast and mcast protocols, plus mcast listeners. >> >> I need to know how it works. I have the ability to some trial here, but if somebody already did, and has some howto, then I would be very much grateful. > > > > This is unicast and mcast 101. Unicast is fixed: we use prefix exchanges in router advertisements. > Almost any PD stack that has OSPF and > an mcast protocol will work. DVMRP is sufficient, if wildly antiquated. 'PD' is? DVMRP has some open source implementation available on linux? > PIM-DM would also work. There are of course more > sophisticated variants of PIM if you can find them. PIM-DM is available as open source for linux? > Your app will need to generate IGMP Joins. In IPv6: the app on PC would need to do MLD REPORT to join a newly defined group, that we would define. I suppose there is a socket interface to generate that MLD? I suppose the mcast group would be with scope global. I would need to define that mcast group, and give it a name. Alex > > Tony > > From nobody Wed Jun 13 04:44:49 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7414130E1A; Wed, 13 Jun 2018 04:44:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152889028289.15184.7135435304711702425@ietfa.amsl.com> Date: Wed, 13 Jun 2018 04:44:42 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 11:44:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-23.txt Pages : 39 Date : 2018-06-13 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 13 05:04:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EAC130DCB for ; Wed, 13 Jun 2018 05:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REiQ0q0vm54p for ; Wed, 13 Jun 2018 05:04:35 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 81C9712F1A5 for ; Wed, 13 Jun 2018 05:04:34 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id v13-v6so2455949wrp.13 for ; Wed, 13 Jun 2018 05:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Jv1216mWGeJeakGuN4CpyVl8/wmVyw15Q3sxkRmJxts=; b=EsOBgtmJwKmroA3hkPlQ5IsvXv0jKzDNlLJxAVF2hKZa0bSoNY5xpw6dJpZkmMP0uO 65P2zQDj5sLvCFXvmEWu+s9cnWmeZx50xH3d4Jd0ahZ38WCh+YEu2nPHF/06JGzdsq8B 7xtwYXm5vvnydLAHYPbyo1yY8TNEvbCi9pdZISvD3MOe/zy92/yUth02oGc17ZeYNYjc HdNzGk7UIAGr/ze/0RS3+IFtVrnushxYYE6rmbmpc6hSU2P7lOYaPqerU7Pa3HAauIxT UjpaN9gE1Vv78SGt5CKmsyHTJB9ot0SJglwbZ2nZOSRFneS4Z9XUUOc4tS8k5ei5oUjb 2P2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Jv1216mWGeJeakGuN4CpyVl8/wmVyw15Q3sxkRmJxts=; b=XUk/ykDAizjkzHzWfdQF/KHAilNAKY+D+Wybu0A4jwv+Y5OpKD0KtTtCC/bLW959iL PYRRqz2sPFQWxEMYsZ126ULCd8KD/NS7YHrA5ocPogWu8pGADlllKKl9lKtSTRyeb/Vk sP2OKGGrvCzJP55vGz0SYo2JIuKQlneRRxKaO/dqPKqFB4ZX2pC21jVZ9nhz+5YoXX4Z 905tiMQx62mKBcDRHTY5Vs9iVezqZ6sBRezg9I6uWvh/G2JaQsJixuLi96esvAyETp0v BYHwZ6/NP1gOT8mmGuTysDtBpsyNszAFA7aBFnB53GPpAeeSpyRGxYbJBWoMf6nnnIUd 56+g== X-Gm-Message-State: APt69E3SG+AfxG2BVrzjWqln8EJjuW3WpYA8/4PuwEU4DXzQS+WD/Zjn R59Z7npGz7BE9CBNMJMDINFf1Q== X-Google-Smtp-Source: ADUXVKJ7dIbr687SZUZOfsetKFGMac0AQE7EDLtm6vI0iAXa9STaK9joLmWWN6EfdrWZROmLlPNBIg== X-Received: by 2002:adf:ae09:: with SMTP id x9-v6mr3945463wrc.19.1528891472804; Wed, 13 Jun 2018 05:04:32 -0700 (PDT) Received: from ?IPv6:2a01:cb09:9f2e:2c:3db9:641:5f8e:385? (2a01cb099f2e002c3db906415f8e0385.ipv6.abo.wanadoo.fr. [2a01:cb09:9f2e:2c:3db9:641:5f8e:385]) by smtp.gmail.com with ESMTPSA id n12-v6sm2236459wrp.69.2018.06.13.05.04.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 05:04:32 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> To: "its@ietf.org" X-Forwarded-Message-Id: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> Message-ID: <69542de6-fdef-7ef8-c029-0a063b25a87f@gmail.com> Date: Wed, 13 Jun 2018 14:04:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------A62ECBC326D43217493616AD" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:04:40 -0000 This is a multi-part message in MIME format. --------------A62ECBC326D43217493616AD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I submitted the version -23 of the IPv6-over-OCB draft. There is no content modification.  (I will do the ND modifs requested  by AD later). You should ignore this version -23. The goal of this -23 version is to verify the following: check our car network is connected to the Internet, and check the process. The results of this check are the following: - the car is able to offer both IPv4 and IPv6 to its computers. - the github.com is only on IPv4; it can not be accessed on IPv6. - the ietf.org process is ok on IPv6.  The following work ok if accessed from a Client that does only IPv6: xml2rfc.ietf.org, and submission on datatracker.ietf.org. - during submission, the confirmation email is sent to the author's organisation.  In my case that email is on IPv4 only. - sidenote: submission does not accept if submit just the .xml, it needs .txt as well, otherwise it complains about title and filename. - I send this email on google smtp with a client on IPv6, and IPv4 unchecked box.  If it reaches the list it means that gmail works on IPv6 only, and that the mailing lists at IETF also work ok if   accessed from a Client that does only IPv6. You are free to ignore this -23 version, it's not very important to the contents of our draft. Yours, Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt Date : Wed, 13 Jun 2018 04:44:43 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 23 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-06-13 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-23.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-23 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. 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 --------------A62ECBC326D43217493616AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I submitted the version -23 of the IPv6-over-OCB draft.

There is no content modification.  (I will do the ND modifs requested  by AD later).

You should ignore this version -23.

The goal of this -23 version is to verify the following: check our car network is connected to the Internet, and check the process.

The results of this check are the following:

- the car is able to offer both IPv4 and IPv6 to its computers.
- the github.com is only on IPv4; it can not be accessed on IPv6.
- the ietf.org process is ok on IPv6.  The following work ok if accessed from a Client that does only IPv6: xml2rfc.ietf.org, and submission on datatracker.ietf.org.
- during submission, the confirmation email is sent to the author's organisation.  In my case that email is on IPv4 only.
- sidenote: submission does not accept if submit just the .xml, it needs .txt as well, otherwise it complains about title and filename.
- I send this email on google smtp with a client on IPv6, and IPv4 unchecked box.  If it reaches the list it means that gmail works on IPv6 only, and that the mailing lists at IETF also work ok if
  accessed from a Client that does only IPv6.

You are free to ignore this -23 version, it's not very important to the contents of our draft.

Yours,

Alex


-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt
Date : Wed, 13 Jun 2018 04:44:43 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr>


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	23
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-06-13
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-23.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-23

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

--------------A62ECBC326D43217493616AD-- From nobody Wed Jun 13 05:06:07 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D58312F1A5 for ; Wed, 13 Jun 2018 05:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIV9FiFk2kdJ for ; Wed, 13 Jun 2018 05:06:00 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 A3761130DCB for ; Wed, 13 Jun 2018 05:05:59 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id e18-v6so2489552wrs.5 for ; Wed, 13 Jun 2018 05:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AK8Kv78+I1aIhmJYTqh1kkfSxtwt7JikwGoBHmDjwuE=; b=F67wcihE2XYA572Tx0nsJ5B+xYICQKtjctFB7D15wwznNrj6XteTzsV84YF/ppl+aO ydQPOBi5+dB7asSjY4wbkfy+5Ol1y6q8pUMQuqSM4VYK4/R/adAzdChMaV/1tjekX2Rj 0NjLUBLpCDjwzwNPmWg+fnx9v+hmCLvS07KzUHE2YqGnVqs5WUIGU0B8XqMGtQPNH/fS pe/8OSXYrsLblmM5RM/gQzAbHb+tk2BMbHChfTRg1ZgOkI/7+fLt6jVBrvUdq8Nozu70 NsZ2+FlnxodxQpGJSEIV8/9a0QTPuEyG43deFWRJ/9gXrZuunoJL8fUVCTIQ6CYjpJKo nmrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AK8Kv78+I1aIhmJYTqh1kkfSxtwt7JikwGoBHmDjwuE=; b=M6KO4PM4LNw3zVIVTe/W9T1Zo2VeQecrYpXkMIgGtEIMeTvUyIDso/Eickb/co6ID0 4/O+OH8NhTePPJ0dsHACE3tu2aIjveODUIIy2YK1FFfN0oOZthroaajGbKgcKwvQf6fZ wBpRFbXa5DyE6lV+8bXe0ShgW93olYVS5XjRctHNsR+fLKS/lZPO9Y1HZm6ZjdLZm65d UYLF1y8f66GcblwoLvsZAsIWyyixN2j7eGQ/wZPwGv2+AF6sOU8gIF3FqifNRsEyvXww 3a1ZSSlU5iP/FVcFaYCdCDx05i1p5yU6fCt47ip7PIrcV7Rg4oTRvG+hNfBg3/XQnL2b rFiQ== X-Gm-Message-State: APt69E2N7tBCcUtQU9JzPMPDzdB9wRkspwRG7BA8czqsmCaqKA6WeaFe YTfDD65ZHTD4NmqErnIAgQ9yxQ== X-Google-Smtp-Source: ADUXVKLRGBbUZmNHbIRFyMms/txnPnQ3MofsHHZohzqCzBuNmwrXzlsnqcHg4UK7g0+lSIQZSZkwBQ== X-Received: by 2002:adf:ef4f:: with SMTP id c15-v6mr3679081wrp.182.1528891557988; Wed, 13 Jun 2018 05:05:57 -0700 (PDT) Received: from ?IPv6:2a01:cb09:9f2e:2c:3db9:641:5f8e:385? (2a01cb099f2e002c3db906415f8e0385.ipv6.abo.wanadoo.fr. [2a01:cb09:9f2e:2c:3db9:641:5f8e:385]) by smtp.gmail.com with ESMTPSA id d3-v6sm3737436wri.24.2018.06.13.05.05.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 05:05:57 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: "its@ietf.org" References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> Message-ID: <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> Date: Wed, 13 Jun 2018 14:05:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------FB6493D6FDB4751C8FE3B767" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:06:04 -0000 This is a multi-part message in MIME format. --------------FB6493D6FDB4751C8FE3B767 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit [only this email was sent on IPv6 only: IPv4 was unchecked in the sending Windows] Hi IPWAVErs, I submitted the version -23 of the IPv6-over-OCB draft. There is no content modification.  (I will do the ND modifs requested  by AD later). You should ignore this version -23. The goal of this -23 version is to verify the following: check our car network is connected to the Internet, and check the process. The results of this check are the following: - the car is able to offer both IPv4 and IPv6 to its computers. - the github.com is only on IPv4; it can not be accessed on IPv6. - the ietf.org process is ok on IPv6.  The following work ok if accessed from a Client that does only IPv6: xml2rfc.ietf.org, and submission on datatracker.ietf.org. - during submission, the confirmation email is sent to the author's organisation.  In my case that email is on IPv4 only. - sidenote: submission does not accept if submit just the .xml, it needs .txt as well, otherwise it complains about title and filename. - I send this email on google smtp with a client on IPv6, and IPv4 unchecked box.  If it reaches the list it means that gmail works on IPv6 only, and that the mailing lists at IETF also work ok if   accessed from a Client that does only IPv6. You are free to ignore this -23 version, it's not very important to the contents of our draft. Yours, Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt Date : Wed, 13 Jun 2018 04:44:43 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 23 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-06-13 Group: ipwave Pages: 39 URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-23.txt Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23 Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-23 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. 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 --------------FB6493D6FDB4751C8FE3B767 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

[only this email was sent on IPv6 only: IPv4 was unchecked in the sending Windows]

Hi IPWAVErs,

I submitted the version -23 of the IPv6-over-OCB draft.

There is no content modification.  (I will do the ND modifs requested  by AD later).

You should ignore this version -23.

The goal of this -23 version is to verify the following: check our car network is connected to the Internet, and check the process.

The results of this check are the following:

- the car is able to offer both IPv4 and IPv6 to its computers.
- the github.com is only on IPv4; it can not be accessed on IPv6.
- the ietf.org process is ok on IPv6.  The following work ok if accessed from a Client that does only IPv6: xml2rfc.ietf.org, and submission on datatracker.ietf.org.
- during submission, the confirmation email is sent to the author's organisation.  In my case that email is on IPv4 only.
- sidenote: submission does not accept if submit just the .xml, it needs .txt as well, otherwise it complains about title and filename.
- I send this email on google smtp with a client on IPv6, and IPv4 unchecked box.  If it reaches the list it means that gmail works on IPv6 only, and that the mailing lists at IETF also work ok if
  accessed from a Client that does only IPv6.

You are free to ignore this -23 version, it's not very important to the contents of our draft.

Yours,

Alex


-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt
Date : Wed, 13 Jun 2018 04:44:43 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr>


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	23
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-06-13
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-23.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-23

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

--------------FB6493D6FDB4751C8FE3B767-- From nobody Wed Jun 13 05:10:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5E5130F59 for ; Wed, 13 Jun 2018 05:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fXtQsoiwzHC for ; Wed, 13 Jun 2018 05:10:28 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFF5130F93 for ; Wed, 13 Jun 2018 05:10:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DCAP95184891 for ; Wed, 13 Jun 2018 14:10:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C002B2016A5 for ; Wed, 13 Jun 2018 14:10:25 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B6D3E200CFB for ; Wed, 13 Jun 2018 14:10:25 +0200 (CEST) Received: from [132.166.85.208] ([132.166.85.208]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DCAOdh010811 for ; Wed, 13 Jun 2018 14:10:25 +0200 To: its@ietf.org References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 13 Jun 2018 14:10:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:10:43 -0000 The email was sent ok on IPv6, from the car network, up to the server, and to the email list and in the archive ietf.org/mailman/listinfo/its IPv4 was disabled during this entire chain - I am happy! Alex Le 13/06/2018 à 14:05, Alexandre Petrescu a écrit : > [only this email was sent on IPv6 only: IPv4 was unchecked in the > sending Windows] > > Hi IPWAVErs, > > I submitted the version -23 of the IPv6-over-OCB draft. > > There is no content modification.  (I will do the ND modifs requested > by AD later). > > You should ignore this version -23. > > The goal of this -23 version is to verify the following: check our car > network is connected to the Internet, and check the process. > > The results of this check are the following: > > - the car is able to offer both IPv4 and IPv6 to its computers. > - the github.com is only on IPv4; it can not be accessed on IPv6. > - the ietf.org process is ok on IPv6.  The following work ok if accessed > from a Client that does only IPv6: xml2rfc.ietf.org, and submission on > datatracker.ietf.org. > - during submission, the confirmation email is sent to the author's > organisation.  In my case that email is on IPv4 only. > - sidenote: submission does not accept if submit just the .xml, it needs > .txt as well, otherwise it complains about title and filename. > - I send this email on google smtp with a client on IPv6, and IPv4 > unchecked box.  If it reaches the list it means that gmail works on IPv6 > only, and that the mailing lists at IETF also work ok if >   accessed from a Client that does only IPv6. > > You are free to ignore this -23 version, it's not very important to the > contents of our draft. > > Yours, > > Alex > > > -------- Message transféré -------- > Sujet : New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > Date : Wed, 13 Jun 2018 04:44:43 -0700 > De : internet-drafts@ietf.org > Pour : Jerome Haerri , > ipwave-chairs@ietf.org, Jerome Haerri , > Alexandre Petrescu , Alexandre Petrescu > , Nabil Benamar , > Thierry Ernst , Jong-Hyouk Lee > > > > > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > has been successfully submitted by Alexandre Petrescu and posted to the > IETF repository. > > Name: draft-ietf-ipwave-ipv6-over-80211ocb > Revision: 23 > Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) > Document date: 2018-06-13 > Group: ipwave > Pages: 39 > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23 > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-23 > > Abstract: > In order to transmit IPv6 packets on IEEE 802.11 networks running > outside the context of a basic service set (OCB, earlier "802.11p") > there is a need to define a few parameters such as the supported > Maximum Transmission Unit size on the 802.11-OCB link, the header > format preceding the IPv6 header, the Type value within it, and > others. This document describes these parameters for IPv6 and IEEE > 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB > similarly to other known 802.11 and Ethernet layers - by using an > Ethernet Adaptation Layer. > > > > > 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 > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Jun 13 06:16:01 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24F2130E29 for ; Wed, 13 Jun 2018 06:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuMFAe3DBs2k for ; Wed, 13 Jun 2018 06:15:57 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 68517130E22 for ; Wed, 13 Jun 2018 06:15:57 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id l10-v6so2280782qtj.0 for ; Wed, 13 Jun 2018 06:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PMnECFY3aqgBoqd3uDfMqF/Pf2ro7jxgZUic9uh/2qY=; b=ZwindqUrKijhHAa+bAcRWz01B2TWRE8h1CbuCoLmtJ9NatRSpuu37LZSb2FYWjLQjM dZgV2grtf8kl6tNbtRutzWfCBGbxzJhDbzOr1Ft0S82j9Wr/DTHAQbLKbxyJrRzVM45f 5Glf+KA0gClriycY07MbG4QjxFvBs9cODezVupVrs+3botnv6cszpwVce55nIfzWmaXM rkrCsvCclBUYp/OVyaGzh7Za8qaOZxhtpAHSrlQI3/yP8thIZ2NyhwzyhYVvflwexSUm GdukxTl7IdGRq9d8clveNztanOQ0DKiPXHaGZCBk2TjlYxvUeglHPpd/sS83BvAZgn9c UNLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PMnECFY3aqgBoqd3uDfMqF/Pf2ro7jxgZUic9uh/2qY=; b=fOs75F1esu8L9eE037pLRzQbXuUJ6TxBIyOPALc0jGXGCiyle8dIA+6PRxe1dBuIoH o4hMIw7Pw3KHcj5I55oR2hE/Ac1SLE4QTCA6xXVurVWByWpwVUyJJtNXv/lyvUG72hMS WNXeznhlcY5tyZQp0l3KHQeBa6ZVswm1tutjZgb5o+BhS5ypxSAtC6po/kaFYI/12Ury QnEwjU+HJSu0YDAMr6y/L3r4L01V/gfoaZsyNtnrobXEPAGieF97yjRRuTrhaM6jQY8y Qj2qYKySiOxvzqsJgMivvVbgVnps7SSEM+dk+dpKp5oKHsMQt1QBQ+eV3J/wAsKzM0kz Hzog== X-Gm-Message-State: APt69E22LS+R3horw4RyYYBDRIKVHZWNVn2Re7Hu09ycoyBLY4T+6EEK NKd1n0iqmzDXujsXz7dJu1E= X-Google-Smtp-Source: ADUXVKLZBKAM9JAKctWGrUPCw/s3V1tmvXxTWlQ+RlYtRuclqIDHWlyprLZ05+JB26KYNd3e/R1T7A== X-Received: by 2002:a0c:d026:: with SMTP id u35-v6mr4183666qvg.210.1528895756598; Wed, 13 Jun 2018 06:15:56 -0700 (PDT) Received: from [10.35.94.152] (107-1-136-3-ip-static.hfc.comcastbusiness.net. [107.1.136.3]) by smtp.gmail.com with ESMTPSA id i23-v6sm1676559qtp.44.2018.06.13.06.15.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 06:15:55 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_41582C70-564A-4015-BDA4-D135579BA6CC" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 13 Jun 2018 09:15:24 -0400 In-Reply-To: <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> Cc: its@ietf.org To: Alexandre Petrescu References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 13:15:59 -0000 --Apple-Mail=_41582C70-564A-4015-BDA4-D135579BA6CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alex, > Unicast is fixed: we use prefix exchanges in router advertisements. That doesn=E2=80=99t sound quite right. Aren=E2=80=99t your RAs local = to the subnet? How does the information propagate to the rest of the = convoy? >=20 >> Almost any PD stack that has OSPF and >> an mcast protocol will work. DVMRP is sufficient, if wildly = antiquated. >=20 > 'PD' is? Public Domain, but I should have said Open Source >=20 > DVMRP has some open source implementation available on linux? >=20 >> PIM-DM would also work. There are of course more >> sophisticated variants of PIM if you can find them. >=20 > PIM-DM is available as open source for linux? https://frrouting.org/ http://git.savannah.gnu.org/cgit/quagga.git = >=20 >> Your app will need to generate IGMP Joins. >=20 > In IPv6: the app on PC would need to do MLD REPORT to join a newly = defined group, that we would define. >=20 > I suppose there is a socket interface to generate that MLD? Not AFAIK, you should use a raw socket. Tony --Apple-Mail=_41582C70-564A-4015-BDA4-D135579BA6CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Alex,

Unicast is fixed: we use = prefix exchanges in router advertisements.


That doesn=E2=80=99t sound quite right. =  Aren=E2=80=99t your RAs local to the subnet? How does the = information propagate to the rest of the convoy?


Almost = any PD stack that has OSPF and
an mcast protocol will = work. DVMRP is sufficient, if wildly antiquated.

'PD' is?

Public = Domain, but I should have said Open Source


DVMRP has some open source implementation = available on linux?

PIM-DM would also work. There are of course more
sophisticated variants of PIM if you can find them.

PIM-DM is available as open = source for linux?





Your app will need to generate IGMP Joins.

In IPv6: the app on PC would need = to do MLD REPORT to join a newly defined group, that we would define.

I suppose there is a socket interface to = generate that MLD?


Not AFAIK, you should = use a raw socket.

Tony

= --Apple-Mail=_41582C70-564A-4015-BDA4-D135579BA6CC-- From nobody Wed Jun 13 07:02:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B282F130E29 for ; Wed, 13 Jun 2018 07:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSujRC6ZE5sm for ; Wed, 13 Jun 2018 07:02:39 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 8E55D130DC0 for ; Wed, 13 Jun 2018 07:02:39 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id l10-v6so2445438qtj.0 for ; Wed, 13 Jun 2018 07:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=swkqPS4hBarul1b4dikuQgDwPdceQ6ilFDCfZquM8iY=; b=oJUy8DDb+LGi27wCh5DueMv/Ir6TvJlaGvBBimEFvfcMj/mlCCMacpbjWWZfdj0uEg sz5JrjDt96+WnseIKgUCQ8PuVCk33h9Ik5wKdJhdCKcj5Wki3fItEfrszRjOMdzT1Zrt oc3Zd4lVMtvEz1NuM33370abznpFg8ds3bSjIxW4ECnqnwpcPbi7XoqXygw8DgMT3tvq 3zKsF83UyHdRKQU1/iduKt35eArPLhyEk4H4+JrYp6vlioqz4VueM3jxITNq5YX0SIrV 5Ar+t6XkjQXh9OEtK+EvaK0y7TqnnwoOcncNzkwz4IBlvAnCe2zHlPS9MveBkmOXOTRa fthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=swkqPS4hBarul1b4dikuQgDwPdceQ6ilFDCfZquM8iY=; b=Yfk70hKvWsLE27LgQZNQC1PYItJxD85T/WAHKhluBbzpFiLOXwfNHvaUiqIpkBdBEt g9R1AIeh/6xSrp2PyiWDhgMZgjFdovZy4Q1PmzbS1EgYSlcqPJWhxwHaZhhzlzNAYoA4 y4tE5CVJHY0x3sS2z0BBRgGonSJ3e5WPYXnSy3QiRtSvs2hjkfeIgyeYL23yG2J6CKBm ueyNfBPDqWgld3H0TEqjDNpmdAA7TSI9P64L4Qwdhat1xZ3oLh+DXmdbFAb2PmiSV6mt lWPQLru2Apcuz0fEJMSMWHq9yNL/85wcuR/r9UbshnKskPrUVtcJnShGafXpSsDC57W4 lYjQ== X-Gm-Message-State: APt69E2qj10339keqC8JAhEQsafZY3ie6IJGINaE5s8Jw8Qi8yjwgRTA qIKEyLP60NaOsL23MdF6rAA= X-Google-Smtp-Source: ADUXVKJBjgHy9UV4NSgjBDUcTlplvaA3NfP2Y6eEKN4OZ2Ae7eUJ2sZaeLG8kW1pEJKk9IpZ14tVRg== X-Received: by 2002:a0c:b2ca:: with SMTP id d10-v6mr4528896qvf.16.1528898558540; Wed, 13 Jun 2018 07:02:38 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id o58-v6sm2584269qtb.88.2018.06.13.07.02.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 07:02:37 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> In-Reply-To: <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> Date: Wed, 13 Jun 2018 10:02:38 -0400 Message-ID: <003e01d4031f$309eccd0$91dc6670$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01D402FD.A98F76C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIRVZ1W12PVHITJkSGsbBgSxda3lgMFBx1Ao8tn84A= Content-Language: en-us Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:02:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003F_01D402FD.A98F76C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you for let me know. Here again=E2=80=A6.Whoaaaa! about the = testing. I am sure that there are serious test suites already written = that can be modified for the purpose. Fygs =20 From: its On Behalf Of Alexandre Petrescu Sent: Wednesday, June 13, 2018 8:06 AM To: its@ietf.org Subject: [ipwave] Fwd: New Version Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-23.txt =20 [only this email was sent on IPv6 only: IPv4 was unchecked in the = sending Windows] Hi IPWAVErs, I submitted the version -23 of the IPv6-over-OCB draft. There is no content modification. (I will do the ND modifs requested = by AD later). You should ignore this version -23. The goal of this -23 version is to verify the following: check our car = network is connected to the Internet, and check the process. The results of this check are the following: - the car is able to offer both IPv4 and IPv6 to its computers. - the github.com is only on IPv4; it can not be accessed on IPv6. - the ietf.org process is ok on IPv6. The following work ok if accessed = from a Client that does only IPv6: xml2rfc.ietf.org, and submission on = datatracker.ietf.org. - during submission, the confirmation email is sent to the author's = organisation. In my case that email is on IPv4 only. - sidenote: submission does not accept if submit just the .xml, it needs = .txt as well, otherwise it complains about title and filename. - I send this email on google smtp with a client on IPv6, and IPv4 = unchecked box. If it reaches the list it means that gmail works on IPv6 = only, and that the mailing lists at IETF also work ok if=20 accessed from a Client that does only IPv6. You are free to ignore this -23 version, it's not very important to the = contents of our draft.=20 Yours, Alex -------- Message transf=C3=A9r=C3=A9 --------=20 Sujet :=20 New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt Date :=20 Wed, 13 Jun 2018 04:44:43 -0700 De :=20 internet-drafts@ietf.org =20 Pour :=20 Jerome Haerri = , ipwave-chairs@ietf.org = , Jerome Haerri = , Alexandre = Petrescu = , Alexandre Petrescu = , Nabil = Benamar , = Thierry Ernst = , Jong-Hyouk Lee = =20 A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. =20 Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 23 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks = operating in mode Outside the Context of a Basic Service Set = (IPv6-over-80211-OCB) Document date: 2018-06-13 Group: ipwave Pages: 39 URL: = https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb= -23.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: = https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211oc= b Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-= 23 =20 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. =20 = =20 =20 =20 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. =20 The IETF Secretariat =20 ------=_NextPart_000_003F_01D402FD.A98F76C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thank you for let me = know.=C2=A0 =C2=A0Here again=E2=80=A6.Whoaaaa! about the = testing.=C2=A0=C2=A0 I am sure that there are serious test suites = already written that can be modified for the purpose.=C2=A0 = Fygs

 

From: its <its-bounces@ietf.org> On = Behalf Of Alexandre Petrescu
Sent: Wednesday, June 13, = 2018 8:06 AM
To: its@ietf.org
Subject: [ipwave] Fwd: = New Version Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-23.txt

 

[only this email = was sent on IPv6 only: IPv4 was unchecked in the sending = Windows]

Hi = IPWAVErs,

I submitted the = version -23 of the IPv6-over-OCB draft.

There is no content = modification.  (I will do the ND modifs requested  by AD = later).

You should ignore = this version -23.

The goal of this = -23 version is to verify the following: check our car network is = connected to the Internet, and check the = process.

The results of this = check are the following:

- the car is able = to offer both IPv4 and IPv6 to its computers.
- the github.com is = only on IPv4; it can not be accessed on IPv6.
- the ietf.org process = is ok on IPv6.  The following work ok if accessed from a Client = that does only IPv6: xml2rfc.ietf.org, and submission on = datatracker.ietf.org.
- during submission, the confirmation email is = sent to the author's organisation.  In my case that email is on = IPv4 only.
- sidenote: submission does not accept if submit just the = .xml, it needs .txt as well, otherwise it complains about title and = filename.
- I send this email on google smtp with a client on IPv6, = and IPv4 unchecked box.  If it reaches the list it means that gmail = works on IPv6 only, and that the mailing lists at IETF also work ok if =
  accessed from a Client that does only IPv6.

You are = free to ignore this -23 version, it's not very important to the contents = of our draft.

Yours,

Alex



-------- Message transf=C3=A9r=C3=A9 -------- =

<= td nowrap valign=3Dtop style=3D'padding:0in 0in 0in 0in'>

Date :

Sujet :

New Version = Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-23.txt

Wed, 13 Jun 2018 = 04:44:43 -0700

De :

internet-drafts@ietf.org

Pour :

Jerome Haerri <Jerome.Haerri@eurecom.fr>= , ipwave-chairs@ietf.org, = Jerome Haerri <jerome.haerri@eurecom.fr>= , Alexandre Petrescu <Alexandre.Petrescu@cea.fr&g= t;, Alexandre Petrescu <alexandre.petrescu@cea.fr&g= t;, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr><= /o:p>

 

A new version =
of I-D, =
draft-ietf-ipwave-ipv6-over-80211ocb-23.txt
has =
been successfully submitted by Alexandre Petrescu and posted to =
the
IETF =
repository.
 
Name:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
draft-ietf-ipwave-ipv6-over-80211ocb
Revision:=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =
23
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in =
mode Outside the Context of a Basic Service Set =
(IPv6-over-80211-OCB)
Document date: =
2018-06-13
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =
ipwave
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =
39
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-ipwave-i=
pv6-over-80211ocb-23.txt
Status:=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211=
ocb/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-o=
ver-80211ocb
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-ov=
er-80211ocb-23
 
Abstr=
act:
=C2=A0=C2=A0 In order to transmit IPv6 packets =
on IEEE 802.11 networks running
=C2=A0=C2=A0 =
outside the context of a basic service set (OCB, earlier =
"802.11p")
=C2=A0=C2=A0 there is a need =
to define a few parameters such as the =
supported
=C2=A0=C2=A0 Maximum Transmission Unit =
size on the 802.11-OCB link, the =
header
=C2=A0=C2=A0 format preceding the IPv6 =
header, the Type value within it, and
=C2=A0=C2=A0 =
others.=C2=A0 This document describes these parameters for IPv6 and =
IEEE
=C2=A0=C2=A0 802.11-OCB networks; it portrays =
the layering of IPv6 on 802.11-OCB
=C2=A0=C2=A0 =
similarly to other known 802.11 and Ethernet layers - by using =
an
=C2=A0=C2=A0 Ethernet Adaptation =
Layer.
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 =
 
 
=
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
 
------=_NextPart_000_003F_01D402FD.A98F76C0-- From nobody Wed Jun 13 07:02:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0F2130E30 for ; Wed, 13 Jun 2018 07:02:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOno8EV1-sTp for ; Wed, 13 Jun 2018 07:02:40 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 4875512F18C for ; Wed, 13 Jun 2018 07:02:40 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id y31-v6so2417643qty.9 for ; Wed, 13 Jun 2018 07:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=9JtfupZSfWTTRijQwxRGxWiQwg4TDQEpWNloxavJ6aQ=; b=cAOzcQdtBz2YM8Cjxk+ozJLy83o5PuxWALsDL2eEJxaYaSrw1MQUkWyGpoq5zEjYZ0 svQs//o5v8SiSUG6o9tsGkrYtKmPYuaTvCBJbbKMpHWsrqoyh6CfLKXBbJJ0QbWgX2wx 88p7DquVyyAl5fSNdKnvaFqUUOoadvrHyB/K5h4C1eOA691XSU2s47wuZxq65g9B9B5e LCudhm+Tn0mzhVW7pn5CS18Ld5hOJF6GVJOsJTBQu/qvJikSYrBifd2tmeZ2RFOhmqHL 3nAE4L+usu7kWBvisSbSgNGucULqSJgUNxmnJpVuhYduTyXzp/wlOsvrZDoqUYPVfvoy JEGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=9JtfupZSfWTTRijQwxRGxWiQwg4TDQEpWNloxavJ6aQ=; b=Q0rIrs2NfAUcxso5J96KPbW4a6KX4HL/QzxfK+B3R72ebrx/AQ6dSzon2CASXUix+K HFh6Tg4+crd7vSZvcAUdGSqKWKP3WZpJsyvSGYySkwn+90cYh4FgGvjKjAEQDra//zCp 7Iu1DV2o/8P4BjyVDtiOAaMskj+Ze0Mrkxxs6eS3RBCLtuhVqr/sKJEAF1BDwIRZm2Zo qbZDNU+/eP42AIL/53mikpZ3deVjam9jhjTJA7WwEJcdMW6eGyR0cxk1OVn578lrPiGL vIJnuKp4AKuTrFMUqSDbkXtq5waD15/i65KuTIBmbLQyiWx3zIZO2GBGu27Viw9JF0/X xEJQ== X-Gm-Message-State: APt69E1KWs5ZZONbm1/qn7gQxzMXyqh6OkGJcPlaWyHNVnL+KWuXFQxn pRw1u0jSBnhsYqjg6ykqf+1czw== X-Google-Smtp-Source: ADUXVKIyv6wWzCKVI6HuY9dkyMFC04crrR2ND3gVuwKkfRc68GWwfeZjY0ILuzMlzkm1+YpoBH/fZQ== X-Received: by 2002:a0c:c251:: with SMTP id w17-v6mr4362020qvh.91.1528898559473; Wed, 13 Jun 2018 07:02:39 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id o58-v6sm2584269qtb.88.2018.06.13.07.02.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 07:02:38 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> In-Reply-To: Date: Wed, 13 Jun 2018 10:02:38 -0400 Message-ID: <004301d4031f$312dc660$93895320$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIRVZ1W12PVHITJkSGsbBgSxda3lgMFBx1AAkoTtt6juRaOsA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:02:48 -0000 Just curious. Is the way you are testing functions which eventually = going to part of a standard? Fygs -----Original Message----- From: its On Behalf Of Alexandre Petrescu Sent: Wednesday, June 13, 2018 8:10 AM To: its@ietf.org Subject: Re: [ipwave] Fwd: New Version Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-23.txt The email was sent ok on IPv6, from the car network, up to the server, = and to the email list and in the archive ietf.org/mailman/listinfo/its IPv4 was disabled during this entire chain - I am happy! Alex Le 13/06/2018 =C3=A0 14:05, Alexandre Petrescu a =C3=A9crit : > [only this email was sent on IPv6 only: IPv4 was unchecked in the=20 > sending Windows] >=20 > Hi IPWAVErs, >=20 > I submitted the version -23 of the IPv6-over-OCB draft. >=20 > There is no content modification. (I will do the ND modifs requested=20 > by AD later). >=20 > You should ignore this version -23. >=20 > The goal of this -23 version is to verify the following: check our car = > network is connected to the Internet, and check the process. >=20 > The results of this check are the following: >=20 > - the car is able to offer both IPv4 and IPv6 to its computers. > - the github.com is only on IPv4; it can not be accessed on IPv6. > - the ietf.org process is ok on IPv6. The following work ok if=20 > accessed from a Client that does only IPv6: xml2rfc.ietf.org, and=20 > submission on datatracker.ietf.org. > - during submission, the confirmation email is sent to the author's=20 > organisation. In my case that email is on IPv4 only. > - sidenote: submission does not accept if submit just the .xml, it=20 > needs .txt as well, otherwise it complains about title and filename. > - I send this email on google smtp with a client on IPv6, and IPv4=20 > unchecked box. If it reaches the list it means that gmail works on=20 > IPv6 only, and that the mailing lists at IETF also work ok if > accessed from a Client that does only IPv6. >=20 > You are free to ignore this -23 version, it's not very important to=20 > the contents of our draft. >=20 > Yours, >=20 > Alex >=20 >=20 > -------- Message transf=C3=A9r=C3=A9 -------- > Sujet : New Version Notification for=20 > draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > Date : Wed, 13 Jun 2018 04:44:43 -0700 > De : internet-drafts@ietf.org > Pour : Jerome Haerri ,=20 > ipwave-chairs@ietf.org, Jerome Haerri ,=20 > Alexandre Petrescu , Alexandre Petrescu=20 > , Nabil Benamar ,=20 > Thierry Ernst , Jong-Hyouk Lee=20 > >=20 >=20 >=20 > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > has been successfully submitted by Alexandre Petrescu and posted to=20 > the IETF repository. >=20 > Name: draft-ietf-ipwave-ipv6-over-80211ocb > Revision: 23 > Title: Transmission of IPv6 Packets over IEEE 802.11 Networks = operating in mode Outside the Context of a Basic Service Set = (IPv6-over-80211-OCB) > Document date: 2018-06-13 > Group: ipwave > Pages: 39 > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-8 > 0211ocb-23.txt=20 > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80 > 211ocb/ > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211 > ocb-23=20 > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6- > over-80211ocb > = Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-802 > 11ocb-23 >=20 > Abstract: > In order to transmit IPv6 packets on IEEE 802.11 networks running > outside the context of a basic service set (OCB, earlier = "802.11p") > there is a need to define a few parameters such as the supported > Maximum Transmission Unit size on the 802.11-OCB link, the header > format preceding the IPv6 header, the Type value within it, and > others. This document describes these parameters for IPv6 and = IEEE > 802.11-OCB networks; it portrays the layering of IPv6 on = 802.11-OCB > similarly to other known 802.11 and Ethernet layers - by using an > Ethernet Adaptation Layer. >=20 > = =20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > 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 Jun 13 07:10:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B31130E30 for ; Wed, 13 Jun 2018 07:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FTNdnODXQhZ for ; Wed, 13 Jun 2018 07:10:11 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F461130EBB for ; Wed, 13 Jun 2018 07:08:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DE86Ok004889; Wed, 13 Jun 2018 16:08:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 86DD32037F9; Wed, 13 Jun 2018 16:08:06 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 797B82034F5; Wed, 13 Jun 2018 16:08:06 +0200 (CEST) Received: from [132.166.84.67] ([132.166.84.67]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DE85kM028337; Wed, 13 Jun 2018 16:08:06 +0200 To: tony.li@tony.li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> From: Alexandre Petrescu Message-ID: <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> Date: Wed, 13 Jun 2018 16:08:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:10:15 -0000 Le 13/06/2018 à 15:15, tony.li@tony.li a écrit : > > Alex, > >> Unicast is fixed: we use prefix exchanges in router advertisements. > > > That doesn’t sound quite right.  Aren’t your RAs local to the subnet? Yes. > How does the information propagate to the rest of the convoy? I agree with you, it does not propagate. We have to find a way to propagate it. At this time, an IP-OBU receives an RA from another IP-OBU. That RA contains the prefix of the Ethernet of one car. A receiving IP-OBU inserts an entry in the routing table containing that prefix and the sender's LL address. This works ok between two cars. In order to work with three cars, we must find a way for one IP-OBU to read its own routing table, realize that a new entry is present and then send it on an interface that is not the interface on which that prefix arrived. That would propagate it. If there is another means to propagate, then I am listening. > >> >>> Almost any PD stack that has OSPF and >>> an mcast protocol will work. DVMRP is sufficient, if wildly antiquated. >> >> 'PD' is? > > Public Domain, but I should have said Open Source > >> >> DVMRP has some open source implementation available on linux? >> >>> PIM-DM would also work. There are of course more >>> sophisticated variants of PIM if you can find them. >> >> PIM-DM is available as open source for linux? > > > https://frrouting.org/ > http://git.savannah.gnu.org/cgit/quagga.git Thanks! Alex > > >> >>> Your app will need to generate IGMP Joins. >> >> In IPv6: the app on PC would need to do MLD REPORT to join a newly >> defined group, that we would define. >> >> I suppose there is a socket interface to generate that MLD? > > > Not AFAIK, you should use a raw socket. > > Tony > From nobody Wed Jun 13 07:12:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C37130E30 for ; Wed, 13 Jun 2018 07:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93PYHHSE8qBe for ; Wed, 13 Jun 2018 07:12:50 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 A6A92130E29 for ; Wed, 13 Jun 2018 07:12:50 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id g126-v6so1547856qke.10 for ; Wed, 13 Jun 2018 07:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mEda+s4bZCmhpnW4WBXLwqEfbOn7IDKRFgE4hIQoEQ4=; b=KHQaPwxDZLa9egw77l6x8GTY2BlzRWq793VNCxt0BTBsRACeUSWqbguolbXwzb9Dg/ Z7upAvTNsrwajSSN2BLDmrHLPUiwUm5xNMRie9EvViri/a8omhBv4qpc8DxVI3vWflHp PsxDRBFLcTIENmu8mtrqeYiC3PxlugMbGLQNHw17LW/hFI4zHeXwyGI3kyEXnBVPbtF7 TrfvgGvQBEd4BHZThziHri7zy7akVLzviU0YMUSJHbkJ/nSwCnBKK+wt6LIsnx7v4vHQ bWgPFXxtNq0duVXLguVeOHdPageyne6ILGiinE2P+X4mX91peZrm9ebFDdomoazHr9G5 e2kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mEda+s4bZCmhpnW4WBXLwqEfbOn7IDKRFgE4hIQoEQ4=; b=pupmAUPLH147SjFU0a6y58WZM+pqB8B6mqnm1Vc4ANC0v4cgJj8hAGigFTY5cpGi06 s/fitQPg7wdRpH5f8Q0JSAKzOLE228AnGM5P4/KgacH/CN1Bzun82zM0EN4XpZ2NrJAD hKA6ANUyBWf1MIe/fGcJ2o7BxqOo0nsJxjI4dHNRrOsyWuVB+lKuoDYMToVbqstDXvrH iSpN0XBTXqo6Fk2+3PgzEXppEL/zgoXY9IoeLyM/YFq8mGd7zrVfp8jRNh/qLu+ehDzX Jb1oKN+kWgGGkBPVa1fCaOBhQpBrC8E5aPyQin3aXfyi/UPUHVwcREEhwMG1i7CelGgZ AdlQ== X-Gm-Message-State: APt69E3htGYOIN2Ei681mWz4ABrNWxRtQfQd4gKSwWDd95rCxchHMOxQ W3WDhFa1hU551cSJW2VMrxMON6kJ X-Google-Smtp-Source: ADUXVKIzsn0L17a6BvYZbp6M0yksgTdYi6HVeTZiHg+qr9gr8uXlTOZc4mwgmpYtk1GYwpHFsaGUKQ== X-Received: by 2002:a37:81c6:: with SMTP id c189-v6mr4320225qkd.314.1528899169906; Wed, 13 Jun 2018 07:12:49 -0700 (PDT) Received: from [10.35.94.152] (107-1-136-3-ip-static.hfc.comcastbusiness.net. [107.1.136.3]) by smtp.gmail.com with ESMTPSA id l5-v6sm2441290qtl.58.2018.06.13.07.12.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 07:12:49 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_119E1412-F157-49C5-B9C9-DC66D1E5889D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 13 Jun 2018 10:12:48 -0400 In-Reply-To: <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> Cc: its@ietf.org To: Alexandre Petrescu References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:12:53 -0000 --Apple-Mail=_119E1412-F157-49C5-B9C9-DC66D1E5889D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu = wrote: >=20 > n order to work with three cars, we must find a way for one IP-OBU to = read its own routing table, realize that a new entry is present and then = send it on an interface that is not the interface on which that prefix = arrived. >=20 > That would propagate it. >=20 > If there is another means to propagate, then I am listening. That would be called a routing protocol. I would suggest OSPF (or, if you=E2=80=99re very brave, IS-IS). Tony --Apple-Mail=_119E1412-F157-49C5-B9C9-DC66D1E5889D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

n order to work with three cars, = we must find a way for one IP-OBU to read its own routing table, realize = that a new entry is present and then send it on an interface that is not = the interface on which that prefix arrived.

That would propagate = it.

If there is = another means to propagate, then I am = listening.


That would be called a = routing protocol.

I would suggest OSPF (or, if you=E2=80=99re very brave, = IS-IS).

Tony

= --Apple-Mail=_119E1412-F157-49C5-B9C9-DC66D1E5889D-- From nobody Wed Jun 13 07:18:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74AB130E30 for ; Wed, 13 Jun 2018 07:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYSVzOOEK7Fj for ; Wed, 13 Jun 2018 07:18:47 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249B5130DC0 for ; Wed, 13 Jun 2018 07:18:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DEIjur027969; Wed, 13 Jun 2018 16:18:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2EA912037A2; Wed, 13 Jun 2018 16:18:45 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 21033202CA5; Wed, 13 Jun 2018 16:18:45 +0200 (CEST) Received: from [132.166.84.67] ([132.166.84.67]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DEIioc003903; Wed, 13 Jun 2018 16:18:44 +0200 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , its@ietf.org References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> <004301d4031f$312dc660$93895320$@gmail.com> From: Alexandre Petrescu Message-ID: <8281d386-deb6-d943-8472-aed47123ef4d@gmail.com> Date: Wed, 13 Jun 2018 16:18:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <004301d4031f$312dc660$93895320$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:18:50 -0000 Yes, for example, when we write standards-to-be we would like to be sure they are used, and not just write for writing. For example, IPv6 is a technology that could be used in a car, and also used to standardise. This is not the case with CAM: one can standardise CAMs, but can not use CAM to standardise CAMs. In this sense, this exercise is a proof of implementability. It is very positive for any draft. On a more mundane matter, this test allowed me to realise that both .xml _and_ .txt files are still mandatory during the submmission process. This is not related to IPv6, but it is a mundane issue that people who write documents at IETF are confronted with. The basic question is: why should I submit _both_ an xml _and_ a txt when the latter is automatically deduced from the first (e.g. the tool at xml2rfc.ietf.org). It sounds redundant. It's as if I had to submit both a pdf and a doc, of the same document, to some organisation. The temptation to complain is itching. At some point, this redundancy was acknowledged on the submission site: it said you _must_ submit both (an asterisk was present, as mandatory fields). Then the asterisks disappeared, yet the mechanics have the same effect: one _must_ submit both formats. But again, this is about the process, which is dear overall. This is not about the draft contents. In the long term, if the process is easier, the contents may become smoother too :-) Alex Le 13/06/2018 à 16:02, François Simon a écrit : > Just curious. Is the way you are testing functions which eventually going to part of a standard? Fygs > > -----Original Message----- > From: its On Behalf Of Alexandre Petrescu > Sent: Wednesday, June 13, 2018 8:10 AM > To: its@ietf.org > Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > > The email was sent ok on IPv6, from the car network, up to the server, and to the email list and in the archive ietf.org/mailman/listinfo/its > > IPv4 was disabled during this entire chain - I am happy! > > Alex > > Le 13/06/2018 à 14:05, Alexandre Petrescu a écrit : >> [only this email was sent on IPv6 only: IPv4 was unchecked in the >> sending Windows] >> >> Hi IPWAVErs, >> >> I submitted the version -23 of the IPv6-over-OCB draft. >> >> There is no content modification. (I will do the ND modifs requested >> by AD later). >> >> You should ignore this version -23. >> >> The goal of this -23 version is to verify the following: check our car >> network is connected to the Internet, and check the process. >> >> The results of this check are the following: >> >> - the car is able to offer both IPv4 and IPv6 to its computers. >> - the github.com is only on IPv4; it can not be accessed on IPv6. >> - the ietf.org process is ok on IPv6. The following work ok if >> accessed from a Client that does only IPv6: xml2rfc.ietf.org, and >> submission on datatracker.ietf.org. >> - during submission, the confirmation email is sent to the author's >> organisation. In my case that email is on IPv4 only. >> - sidenote: submission does not accept if submit just the .xml, it >> needs .txt as well, otherwise it complains about title and filename. >> - I send this email on google smtp with a client on IPv6, and IPv4 >> unchecked box. If it reaches the list it means that gmail works on >> IPv6 only, and that the mailing lists at IETF also work ok if >> accessed from a Client that does only IPv6. >> >> You are free to ignore this -23 version, it's not very important to >> the contents of our draft. >> >> Yours, >> >> Alex >> >> >> -------- Message transféré -------- >> Sujet : New Version Notification for >> draft-ietf-ipwave-ipv6-over-80211ocb-23.txt >> Date : Wed, 13 Jun 2018 04:44:43 -0700 >> De : internet-drafts@ietf.org >> Pour : Jerome Haerri , >> ipwave-chairs@ietf.org, Jerome Haerri , >> Alexandre Petrescu , Alexandre Petrescu >> , Nabil Benamar , >> Thierry Ernst , Jong-Hyouk Lee >> >> >> >> >> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt >> has been successfully submitted by Alexandre Petrescu and posted to >> the IETF repository. >> >> Name: draft-ietf-ipwave-ipv6-over-80211ocb >> Revision: 23 >> Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) >> Document date: 2018-06-13 >> Group: ipwave >> Pages: 39 >> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-8 >> 0211ocb-23.txt >> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80 >> 211ocb/ >> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211 >> ocb-23 >> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6- >> over-80211ocb >> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-802 >> 11ocb-23 >> >> Abstract: >> In order to transmit IPv6 packets on IEEE 802.11 networks running >> outside the context of a basic service set (OCB, earlier "802.11p") >> there is a need to define a few parameters such as the supported >> Maximum Transmission Unit size on the 802.11-OCB link, the header >> format preceding the IPv6 header, the Type value within it, and >> others. This document describes these parameters for IPv6 and IEEE >> 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB >> similarly to other known 802.11 and Ethernet layers - by using an >> Ethernet Adaptation Layer. >> >> >> >> >> 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 >> >> >> >> _______________________________________________ >> 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 Jun 13 07:26:51 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2325E130E31 for ; Wed, 13 Jun 2018 07:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUYVK7SlFqNl for ; Wed, 13 Jun 2018 07:26:48 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76707130E30 for ; Wed, 13 Jun 2018 07:26:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DEQkVN031109; Wed, 13 Jun 2018 16:26:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DA36A203817; Wed, 13 Jun 2018 16:26:46 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CC86A202CA5; Wed, 13 Jun 2018 16:26:46 +0200 (CEST) Received: from [132.166.84.67] ([132.166.84.67]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DEQjKT009064; Wed, 13 Jun 2018 16:26:46 +0200 To: tony.li@tony.li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> From: Alexandre Petrescu Message-ID: <8de4f661-01da-daac-d084-f4c6c11fe966@gmail.com> Date: Wed, 13 Jun 2018 16:26:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:26:50 -0000 Le 13/06/2018 à 16:12, tony.li@tony.li a écrit : > > >> On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu >> > >> wrote: >> >> n order to work with three cars, we must find a way for one IP-OBU to >> read its own routing table, realize that a new entry is present and >> then send it on an interface that is not the interface on which that >> prefix arrived. >> >> That would propagate it. >> >> If there is another means to propagate, then I am listening. > > > That would be called a routing protocol. > > I would suggest OSPF (or, if you’re very brave, IS-IS). Routing protocols like OSPF and IS-IS were designed and implemented with Ethernet in mind, not OCB. Some times they dont react, some times they over-react. Some times they are not available on embedded platforms, or significant work must be produced to port them. But yes, I take the suggestion of OSPF. Somebody else also suggested Babel and we tried it with 3 computers and it worked. But we did not try multicast. I guess Babel, which seems to be adapted ok for WiFi, does support multicast. Maybe there is nothing new to standardise here. Unless of course we can see that a convoy is something different than a LAN, or than a smartphone. I will take that quagga and see how it does multicast. If it does not work maybe we will try to fix it. Maybe we will be fed up and try to start something from scratch. Or maybe it will work right away. Alex > > Tony > From nobody Wed Jun 13 07:41:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30698130E31 for ; Wed, 13 Jun 2018 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up_KWZ0bd0NQ for ; Wed, 13 Jun 2018 07:41:41 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924C7130E30 for ; Wed, 13 Jun 2018 07:41:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DEfdgD016835; Wed, 13 Jun 2018 16:41:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8CE3A203825; Wed, 13 Jun 2018 16:41:39 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7F9A72037A2; Wed, 13 Jun 2018 16:41:39 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5DEfdNL026044; Wed, 13 Jun 2018 16:41:39 +0200 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , its@ietf.org References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> <003e01d4031f$309eccd0$91dc6670$@gmail.com> From: Alexandru Petrescu Message-ID: <2fb48dbc-3b82-1a0f-9f09-fbdf4c67c796@gmail.com> Date: Wed, 13 Jun 2018 16:41:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <003e01d4031f$309eccd0$91dc6670$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:41:44 -0000 Is there a test suite to test IPv6 in a car? Alex Le 13/06/2018 à 16:02, François Simon a écrit : > Thank you for let me know.   Here again….Whoaaaa! about the testing.   I > am sure that there are serious test suites already written that can be > modified for the purpose.  Fygs > > *From:*its *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday, June 13, 2018 8:06 AM > *To:* its@ietf.org > *Subject:* [ipwave] Fwd: New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > > [only this email was sent on IPv6 only: IPv4 was unchecked in the > sending Windows] > > Hi IPWAVErs, > > I submitted the version -23 of the IPv6-over-OCB draft. > > There is no content modification.  (I will do the ND modifs requested > by AD later). > > You should ignore this version -23. > > The goal of this -23 version is to verify the following: check our car > network is connected to the Internet, and check the process. > > The results of this check are the following: > > - the car is able to offer both IPv4 and IPv6 to its computers. > - the github.com is only on IPv4; it can not be accessed on IPv6. > - the ietf.org process is ok on IPv6.  The following work ok if accessed > from a Client that does only IPv6: xml2rfc.ietf.org, and submission on > datatracker.ietf.org. > - during submission, the confirmation email is sent to the author's > organisation.  In my case that email is on IPv4 only. > - sidenote: submission does not accept if submit just the .xml, it needs > .txt as well, otherwise it complains about title and filename. > - I send this email on google smtp with a client on IPv6, and IPv4 > unchecked box.  If it reaches the list it means that gmail works on IPv6 > only, and that the mailing lists at IETF also work ok if >   accessed from a Client that does only IPv6. > > You are free to ignore this -23 version, it's not very important to the > contents of our draft. > > Yours, > > Alex > > > > -------- Message transféré -------- > > *Sujet : * > > > > New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > > *Date : * > > > > Wed, 13 Jun 2018 04:44:43 -0700 > > *De : * > > > > internet-drafts@ietf.org > > *Pour : * > > > > Jerome Haerri > , ipwave-chairs@ietf.org > , Jerome Haerri > , Alexandre > Petrescu , > Alexandre Petrescu > , Nabil Benamar > , Thierry > Ernst , > Jong-Hyouk Lee > > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > > has been successfully submitted by Alexandre Petrescu and posted to the > > IETF repository. > > Name:          draft-ietf-ipwave-ipv6-over-80211ocb > > Revision:      23 > > Title:         Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) > > Document date: 2018-06-13 > > Group:         ipwave > > Pages:         39 > > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-23.txt > > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-23 > > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb > > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-23 > > Abstract: > >    In order to transmit IPv6 packets on IEEE 802.11 networks running > >    outside the context of a basic service set (OCB, earlier "802.11p") > >    there is a need to define a few parameters such as the supported > >    Maximum Transmission Unit size on the 802.11-OCB link, the header > >    format preceding the IPv6 header, the Type value within it, and > >    others.  This document describes these parameters for IPv6 and IEEE > >    802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB > >    similarly to other known 802.11 and Ethernet layers - by using an > >    Ethernet Adaptation Layer. > > > > 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 > From nobody Wed Jun 13 08:33:08 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB59130E44 for ; Wed, 13 Jun 2018 08:33:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbEoYCPYCK-3 for ; Wed, 13 Jun 2018 08:33:03 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 0A9E1127148 for ; Wed, 13 Jun 2018 08:33:03 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id l33-v6so2738024qta.11 for ; Wed, 13 Jun 2018 08:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=3tdY9HIPa8396kqNFr1ee1AoNlqBUlJObpdL2+DMVA0=; b=N1CXG5ONO09+HgpqDennqSNRkxHgrB1rk7MYklUsdWRKsJUpV2OKUe5GmKNLHuqf29 uBah83BE4caZIsNB9LGiqqdWraWuU8uzs7q22G1bkrjnen1NOJtUgZSfuLxQR4+tGdag dOuM1pFEPoPE/LQN9rguu6KdnPMoU6VWW8sTo2+l9x0vCEYHLrBM76rR/AmQ5//fmawu RxvOMu/bCTVIREuYcDVHvA870hBClknwgTz+/tN8+bQnWjrDDnPaQBAeB4x4piEaOPMp R5DpOgGnDdrXu7wSv6HHgTHASeVMriesQLJtnNZNQLixrqXHZbyWTm2/m2DNuziVDJGa a8Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=3tdY9HIPa8396kqNFr1ee1AoNlqBUlJObpdL2+DMVA0=; b=JrKF34og2Sc9JESNnnRWNikEG/0zBnblOovXxRdLID4XBnwDHWilbNQowsI4B+Xv0D BSsFIM9jdfWKRk5yufOM/mchJEDkWZpMj+IW2JHYB1nTyumDjOWalqH5bpK3ut+SYQ4f 1kvbUXDIz8ijZ6kB4EGqp2j0YtHKYUnek+Pbj87Zw7iITtgMSY6LYunzJlcvsv72beMm Zqd/GshbTIOWiIBMiDNmY7EkLk/ba740OLXnrs8qyGJXNr0bRIJQpamBVhoULktup1wY uIEVQUy7+NXcKarp+T4C3N6Ul9K9exATUdyySlzopINM47RWwpczqXbbLXZDcxII78R5 F3tA== X-Gm-Message-State: APt69E3m4TjCgacuiNhaw/4iOBd3Vkub9jl7VxH3/KInjg/IuS9v3GfF C1XpFbViuACr5GLf/9cG3wg= X-Google-Smtp-Source: ADUXVKJTe0oZbsRK82mXM9rRkf3AULLOHZXwQRmS3+tDTVTwU8Tg81uF5Rx/scPtMdsw2ohxCVLZbg== X-Received: by 2002:ac8:2485:: with SMTP id s5-v6mr4961173qts.350.1528903982019; Wed, 13 Jun 2018 08:33:02 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id u83-v6sm2186394qka.10.2018.06.13.08.33.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 08:33:01 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandru Petrescu'" , References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> <107917ea-95c3-5dfa-b2f8-e6f68493d5ed@gmail.com> <003e01d4031f$309eccd0$91dc6670$@gmail.com> <2fb48dbc-3b82-1a0f-9f09-fbdf4c67c796@gmail.com> <000201d4032a$be1ba6e0$3a52f4a0$@gmail.com> In-Reply-To: <000201d4032a$be1ba6e0$3a52f4a0$@gmail.com> Date: Wed, 13 Jun 2018 11:33:02 -0400 Message-ID: <000201d4032b$d14e6580$73eb3080$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIRVZ1W12PVHITJkSGsbBgSxda3lgMFBx1AAeJe53ICCbiPMAKidjJYo5cOYzA= Content-Language: en-us Archived-At: Subject: [ipwave] FW: Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 15:33:06 -0000 Since the Certification Service Providers (in the US) are suppose to = test IEEE 1609.3 (see below) then it should be test cases for IPv6 in = WAVE. Fygs USDOT Connected Vehicle PlugFest=20 Date: May 8-12, 2017 Registration: Click Here =20 The U.S. Department of Transportation (USDOT) will hold its next = Connected Vehicle PlugFest in San Antonio, TX, from May 8 through 12, = 2017. These events provide a venue for vendor-to-vendor connected = vehicle device testing as needed to develop certification services for = multi-vendor connected vehicle networks. Three certification service providers (Danlaw, OmniAir, and 7Layers) = will be on site to demonstrate certification testing products developed = through the USDOT Certification Testing Program. Testing will focus on = verifying conformance to current baseline standards for = vehicle-to-infrastructure communications (i.e., IEEE 802.11, IEEE = 1609.2, IEEE 1609.3, IEEE 1609.4, RSU 4.1). Provisions will be available = to support continued testing of vehicle-to-vehicle communications as = time permits. -----Original Message----- From: Fran=C3=A7ois Simon =20 Sent: Wednesday, June 13, 2018 11:25 AM To: fygsimon@gmail.com Subject: FW: [ipwave] Fwd: New Version Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-23.txt -----Original Message----- From: Alexandru Petrescu Sent: Wednesday, June 13, 2018 10:42 AM To: Fran=C3=A7ois Simon ; its@ietf.org Subject: Re: [ipwave] Fwd: New Version Notification for = draft-ietf-ipwave-ipv6-over-80211ocb-23.txt Is there a test suite to test IPv6 in a car? Alex Le 13/06/2018 =C3=A0 16:02, Fran=C3=A7ois Simon a =C3=A9crit : > Thank you for let me know. Here again=E2=80=A6.Whoaaaa! about the = testing. =20 > I am sure that there are serious test suites already written that can=20 > be modified for the purpose. Fygs >=20 > *From:*its *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday, June 13, 2018 8:06 AM > *To:* its@ietf.org > *Subject:* [ipwave] Fwd: New Version Notification for=20 > draft-ietf-ipwave-ipv6-over-80211ocb-23.txt >=20 > [only this email was sent on IPv6 only: IPv4 was unchecked in the=20 > sending Windows] >=20 > Hi IPWAVErs, >=20 > I submitted the version -23 of the IPv6-over-OCB draft. >=20 > There is no content modification. (I will do the ND modifs requested=20 > by AD later). >=20 > You should ignore this version -23. >=20 > The goal of this -23 version is to verify the following: check our car = > network is connected to the Internet, and check the process. >=20 > The results of this check are the following: >=20 > - the car is able to offer both IPv4 and IPv6 to its computers. > - the github.com is only on IPv4; it can not be accessed on IPv6. > - the ietf.org process is ok on IPv6. The following work ok if=20 > accessed from a Client that does only IPv6: xml2rfc.ietf.org, and=20 > submission on datatracker.ietf.org. > - during submission, the confirmation email is sent to the author's=20 > organisation. In my case that email is on IPv4 only. > - sidenote: submission does not accept if submit just the .xml, it=20 > needs .txt as well, otherwise it complains about title and filename. > - I send this email on google smtp with a client on IPv6, and IPv4=20 > unchecked box. If it reaches the list it means that gmail works on > IPv6 only, and that the mailing lists at IETF also work ok if > accessed from a Client that does only IPv6. >=20 > You are free to ignore this -23 version, it's not very important to=20 > the contents of our draft. >=20 > Yours, >=20 > Alex >=20 >=20 >=20 > -------- Message transf=C3=A9r=C3=A9 -------- >=20 > *Sujet : * >=20 > =09 >=20 > New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-23.txt >=20 > *Date : * >=20 > =09 >=20 > Wed, 13 Jun 2018 04:44:43 -0700 >=20 > *De : * >=20 > =09 >=20 > internet-drafts@ietf.org >=20 > *Pour : * >=20 > =09 >=20 > Jerome Haerri =20 > , ipwave-chairs@ietf.org=20 > , Jerome Haerri=20 > , > Alexandre Petrescu =20 > , > Alexandre Petrescu =20 > , Nabil Benamar=20 > , Thierry=20 > Ernst ,=20 > Jong-Hyouk Lee >=20 > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-23.txt >=20 > has been successfully submitted by Alexandre Petrescu and posted to=20 > the >=20 > IETF repository. >=20 > Name: draft-ietf-ipwave-ipv6-over-80211ocb >=20 > Revision: 23 >=20 > Title: Transmission of IPv6 Packets over IEEE 802.11 Networks=20 > operating in mode Outside the Context of a Basic Service Set > (IPv6-over-80211-OCB) >=20 > Document date: 2018-06-13 >=20 > Group: ipwave >=20 > Pages: 39 >=20 > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-8 > 0211ocb-23.txt >=20 > Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80 > 211ocb/ >=20 > Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211 > ocb-23 >=20 > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6- > over-80211ocb >=20 > = Diff:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-802 > 11ocb-23 >=20 > Abstract: >=20 > In order to transmit IPv6 packets on IEEE 802.11 networks running >=20 > outside the context of a basic service set (OCB, earlier > "802.11p") >=20 > there is a need to define a few parameters such as the supported >=20 > Maximum Transmission Unit size on the 802.11-OCB link, the header >=20 > format preceding the IPv6 header, the Type value within it, and >=20 > others. This document describes these parameters for IPv6 and=20 > IEEE >=20 > 802.11-OCB networks; it portrays the layering of IPv6 on=20 > 802.11-OCB >=20 > similarly to other known 802.11 and Ethernet layers - by using an >=20 > Ethernet Adaptation Layer. >=20 > = =20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission >=20 > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Jun 13 09:22:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5644A130E47 for ; Wed, 13 Jun 2018 09:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfaQgboOWynr for ; Wed, 13 Jun 2018 09:22:24 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA0B124C04 for ; Wed, 13 Jun 2018 09:22:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 34F6F300A3D for ; Wed, 13 Jun 2018 12:22:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DPYwNRkm-EZO for ; Wed, 13 Jun 2018 12:22:21 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 367A3300541; Wed, 13 Jun 2018 12:22:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <69542de6-fdef-7ef8-c029-0a063b25a87f@gmail.com> Date: Wed, 13 Jun 2018 12:22:22 -0400 Cc: IP Wireless Access in Vehicular Environments Discussion List Content-Transfer-Encoding: quoted-printable Message-Id: References: <152889028318.15184.15133330819400962385.idtracker@ietfa.amsl.com> <69542de6-fdef-7ef8-c029-0a063b25a87f@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-23.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 16:22:26 -0000 Alex: > - sidenote: submission does not accept if submit just the .xml, it = needs .txt as well, otherwise it complains about title and filename. Others have had success submitting just the .xml file. Looking at your .xml file, you need to remove the ".txt" from the = docName as follows: OLD: NEW: Russ= From nobody Wed Jun 13 09:22:56 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59566130E67 for ; Wed, 13 Jun 2018 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNvFJy0sNIYN for ; Wed, 13 Jun 2018 09:22:51 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41560124C04 for ; Wed, 13 Jun 2018 09:22:51 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.51,219,1526335200"; d="scan'208,217"; a="26920991" Received: from UCP13.tsn.tno.nl (134.221.225.173) by UCP11.tsn.tno.nl (134.221.225.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1415.2; Wed, 13 Jun 2018 18:22:49 +0200 Received: from UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298]) by UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298%7]) with mapi id 15.01.1415.007; Wed, 13 Jun 2018 18:22:48 +0200 From: "Velt, R. (Ronald) in 't" To: "tony.li@tony.li" , Alexandre Petrescu CC: "its@ietf.org" Thread-Topic: [ipwave] multicast in convoy Thread-Index: AQHUAh/5i10jYSl7kkmsrrE+zEJyc6RcZsQAgAAdSgCAAEuegIAA6w4AgABQrACAAA64gIAAAVEAgAA6J5A= Date: Wed, 13 Jun 2018 16:22:48 +0000 Message-ID: <701f0d97c27249cb8ed282d9f5fd9976@tno.nl> References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> In-Reply-To: <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] x-esetresult: clean, is OK x-esetid: 37303A291940B36E627562 Content-Type: multipart/alternative; boundary="_000_701f0d97c27249cb8ed282d9f5fd9976tnonl_" MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 16:22:54 -0000 --_000_701f0d97c27249cb8ed282d9f5fd9976tnonl_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 KGJlbG93KQ0KDQpGcm9tOiBpdHMgW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIHRvbnkubGlAdG9ueS5saQ0KU2VudDogd29lbnNkYWcgMTMganVuaSAyMDE4IDE2OjEz DQpUbzogQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPg0K Q2M6IGl0c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtpcHdhdmVdIG11bHRpY2FzdCBpbiBjb252 b3kNCg0KDQoNCg0KT24gSnVuIDEzLCAyMDE4LCBhdCAxMDowOCBBTSwgQWxleGFuZHJlIFBldHJl c2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPG1haWx0bzphbGV4YW5kcmUucGV0cmVz Y3VAZ21haWwuY29tPj4gd3JvdGU6DQoNCm4gb3JkZXIgdG8gd29yayB3aXRoIHRocmVlIGNhcnMs IHdlIG11c3QgZmluZCBhIHdheSBmb3Igb25lIElQLU9CVSB0byByZWFkIGl0cyBvd24gcm91dGlu ZyB0YWJsZSwgcmVhbGl6ZSB0aGF0IGEgbmV3IGVudHJ5IGlzIHByZXNlbnQgYW5kIHRoZW4gc2Vu ZCBpdCBvbiBhbiBpbnRlcmZhY2UgdGhhdCBpcyBub3QgdGhlIGludGVyZmFjZSBvbiB3aGljaCB0 aGF0IHByZWZpeCBhcnJpdmVkLg0KDQpUaGF0IHdvdWxkIHByb3BhZ2F0ZSBpdC4NCg0KSWYgdGhl cmUgaXMgYW5vdGhlciBtZWFucyB0byBwcm9wYWdhdGUsIHRoZW4gSSBhbSBsaXN0ZW5pbmcuDQoN Cg0KVGhhdCB3b3VsZCBiZSBjYWxsZWQgYSByb3V0aW5nIHByb3RvY29sLg0KDQo6LV0NCg0KSSB3 b3VsZCBzdWdnZXN0IE9TUEYgKG9yLCBpZiB5b3XigJlyZSB2ZXJ5IGJyYXZlLCBJUy1JUykuDQoN Ckkgd291bGQgc3VnZ2VzdCBPTFNSdjIgKFJGQyA3MTgxIGFuZCBmcmllbmRzKSwgYW4gSUVURiBT dGFuZGFyZHMgVHJhY2sgcHJvdG9jb2wgdGhhdCB3b3JrcyBldmVuIGlmIHlvdXIgSVAtT0JVIGhh cyBvbmx5IG9uZSByYWRpbyBpbnRlcmZhY2UuIEltcGxlbWVudGF0aW9uIGhlcmU6DQoNCmh0dHBz Oi8vZ2l0aHViLmNvbS9PTFNSL09PTkYNCg0KVGhhdOKAmXMgZm9yIHVuaWNhc3QuIE1BTkVUIG11 bHRpY2FzdCBpcyBhIHRhZCBtb3JlIGNvbXBsaWNhdGVkLiBTTUYgKFJGQyA2NjIxLCBFeHBlcmlt ZW50YWwpIGlzIGEgZmlyc3QgYXR0ZW1wdC4gKEltcGxlbWVudGF0aW9uIGhlcmU6IGh0dHBzOi8v d3d3Lm5ybC5uYXZ5Lm1pbC9pdGQvbmNzL3Byb2R1Y3RzL3NtZiApDQoNClJvbmFsZA0KDQpUb255 DQoNClRoaXMgbWVzc2FnZSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBpbnRl bmRlZCBmb3IgeW91LiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlmIHRoaXMgbWVz c2FnZSB3YXMgc2VudCB0byB5b3UgYnkgbWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0ZWQgdG8gaW5m b3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZS4gVE5PIGFjY2VwdHMgbm8gbGlh YmlsaXR5IGZvciB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFpbCwgZm9yIHRoZSBtYW5uZXIgaW4g d2hpY2ggeW91IHVzZSBpdCBhbmQgZm9yIGRhbWFnZSBvZiBhbnkga2luZCByZXN1bHRpbmcgZnJv bSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gdGhlIGVsZWN0cm9uaWMgdHJhbnNtaXNzaW9uIG9mIG1l c3NhZ2VzLgo= --_000_701f0d97c27249cb8ed282d9f5fd9976tnonl_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9Ik5MIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4o YmVsb3cpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBpdHMgW21haWx0 bzppdHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+dG9ueS5saUB0b255 LmxpPGJyPg0KPGI+U2VudDo8L2I+IHdvZW5zZGFnIDEzIGp1bmkgMjAxOCAxNjoxMzxicj4NCjxi PlRvOjwvYj4gQWxleGFuZHJlIFBldHJlc2N1ICZsdDthbGV4YW5kcmUucGV0cmVzY3VAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaXRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbaXB3YXZlXSBtdWx0aWNhc3QgaW4gY29udm95PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz NS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24g SnVuIDEzLCAyMDE4LCBhdCAxMDowOCBBTSwgQWxleGFuZHJlIFBldHJlc2N1ICZsdDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20iPjxzcGFuIGxhbmc9 IkVOLVVTIj5hbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPm4gb3JkZXIgdG8gd29yayB3aXRoIHRocmVlIGNhcnMsIHdlIG11c3QgZmluZCBhIHdh eSBmb3Igb25lIElQLU9CVSB0byByZWFkIGl0cyBvd24gcm91dGluZyB0YWJsZSwgcmVhbGl6ZSB0 aGF0IGEgbmV3IGVudHJ5IGlzIHByZXNlbnQNCiBhbmQgdGhlbiBzZW5kIGl0IG9uIGFuIGludGVy ZmFjZSB0aGF0IGlzIG5vdCB0aGUgaW50ZXJmYWNlIG9uIHdoaWNoIHRoYXQgcHJlZml4IGFycml2 ZWQuPGJyPg0KPGJyPg0KVGhhdCB3b3VsZCBwcm9wYWdhdGUgaXQuPGJyPg0KPGJyPg0KSWYgdGhl cmUgaXMgYW5vdGhlciBtZWFucyB0byBwcm9wYWdhdGUsIHRoZW4gSSBhbSBsaXN0ZW5pbmcuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoYXQgd291bGQgYmUgY2FsbGVkIGEgcm91dGluZyBwcm90b2Nv bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjotXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+SSB3b3VsZCBzdWdnZXN0IE9TUEYgKG9yLCBpZiB5b3XigJlyZSB2ZXJ5 IGJyYXZlLCBJUy1JUykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdvdWxkIHN1Z2dlc3QgT0xTUnYy IChSRkMgNzE4MSBhbmQgZnJpZW5kcyksIGFuIElFVEYgU3RhbmRhcmRzIFRyYWNrIHByb3RvY29s IHRoYXQgd29ya3MgZXZlbiBpZiB5b3VyIElQLU9CVSBoYXMgb25seSBvbmUgcmFkaW8gaW50ZXJm YWNlLiBJbXBsZW1lbnRhdGlvbiBoZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL09MU1IvT09ORiI+aHR0cHM6Ly9naXRodWIuY29tL09MU1IvT09ORjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYXTigJlzIGZvciB1bmljYXN0LiBNQU5FVCBtdWx0aWNh c3QgaXMgYSB0YWQgbW9yZSBjb21wbGljYXRlZC4gU01GIChSRkMgNjYyMSwgRXhwZXJpbWVudGFs KSBpcyBhIGZpcnN0IGF0dGVtcHQuIChJbXBsZW1lbnRhdGlvbiBoZXJlOg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cubnJsLm5hdnkubWlsL2l0ZC9uY3MvcHJvZHVjdHMvc21mIj5odHRwczovL3d3dy5u cmwubmF2eS5taWwvaXRkL25jcy9wcm9kdWN0cy9zbWY8L2E+ICk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlJvbmFsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VG9u eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogOHB0OyBtc28tYmlkaS1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgc3R5bGU9IkZPTlQtU0laRTogMTFweCIgc2l6ZT0i MyI+DQo8L2ZvbnQ+PHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHN0eWxlPSJGT05ULVNJWkU6IDExcHgiIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogOHB0OyBtc28tYmlk aS1mb250LXNpemU6IDguNXB0Ij5UaGlzIG1lc3NhZ2UgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24g dGhhdCBpcyBub3QgaW50ZW5kZWQgZm9yIHlvdS4gSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3Nl ZSBvciBpZiB0aGlzIG1lc3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5IG1pc3Rha2UsIHlvdSBhcmUg cmVxdWVzdGVkIHRvIGluZm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UuIFRO TyBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgdGhlIGNvbnRlbnQgb2YgdGhpcyBlLW1haWwsIGZv ciB0aGUgbWFubmVyIGluIHdoaWNoIHlvdSB1c2UgaXQgYW5kIGZvciBkYW1hZ2Ugb2YgYW55IGtp bmQgcmVzdWx0aW5nIGZyb20gdGhlIHJpc2tzIGluaGVyZW50IHRvIHRoZSBlbGVjdHJvbmljIHRy YW5zbWlzc2lvbiBvZiBtZXNzYWdlcy48YnI+PGJyPjwvc3Bhbj48L2ZvbnQ+PC9wPjwvYm9keT4N CjwvaHRtbD4NCg== --_000_701f0d97c27249cb8ed282d9f5fd9976tnonl_-- From nobody Wed Jun 13 20:22:00 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53770131026 for ; Wed, 13 Jun 2018 20:21:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlCp8vQ1zuRf for ; Wed, 13 Jun 2018 20:21:56 -0700 (PDT) Received: from mail-yb0-x244.google.com (mail-yb0-x244.google.com [IPv6:2607:f8b0:4002:c09::244]) (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 CAF6C13101E for ; Wed, 13 Jun 2018 20:21:55 -0700 (PDT) Received: by mail-yb0-x244.google.com with SMTP id x36-v6so1724746ybi.0 for ; Wed, 13 Jun 2018 20:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5RWXGm3KctU5FSgVPVIRv6wbFlLEPFHA4ldPA9nsmQ4=; b=QMX1s4qZB1OJo70zYiNabh/etgOqsrr56P4kJppGDkqnCOgZ3FizmI0JSIf1ZTEDuD ecL+WmLtbYDHZmSMhNTWkB5k64E5aPKiFc3bgBR21GsImetbWvY93NFjro6gxbuD6If2 GTQyQADfMhjeJ5nturUv5Kc+D2BCSl4/X1OXH8Y7n6HOrm5l4OtzpOBuA2Y/cvtDjBqa nj83V9xTAelJpguqGXrozLQ62dsOPHRd9o1EH2+yGfJz0x0UQGjdk2Ja19KcoCCzcuWf UIqTx6mztmKXI81L1hlRan7+EZMXGQcfKw6fkJLZwB8sCbfb3ngYpkTbTUkkKEalojL0 HAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5RWXGm3KctU5FSgVPVIRv6wbFlLEPFHA4ldPA9nsmQ4=; b=d6puTYWVtG73seNpBEMmdRtLiAi+OjfBm1wRBRgH8LmmV4CddriKZMSZd7jvr/QQJX Diw1kWYUwbn0Z6S81ePlFwyiNKYiNXwGUpfYImItUv215SoP8dBnvSuQ6GhdNHQNTF8q 5g1vMzEjRl/d2eE5nkIw8x2yj9Gtk4eUEd/MruyzVASAAMHlsNTr2jmLs7DXcnLekgfA AgeT6iYLxWmlH1ftTiotaA/7CapsQnywb2Qx7MV7CqZufIQlPGvTANmKIUg4VX4kBnr/ BFgbYANSHiZ3uZ5XGBJDJBYF28JNnspuHxPjEA7FieOx3Ln4Ocxm5BXTSSG17V/ByuXV pqAg== X-Gm-Message-State: APt69E2BhTHiDkh91KvcHPDyuFs3fRyHI2mN/132uwTR4Ml3TlnW9uhl ZTPlZBq35OeKcTGafrekMb4= X-Google-Smtp-Source: ADUXVKKo036u1wVquWrjLxHaWjSl9PumAwdde1oRaN9a8XfTnJBDGdAVC36jjZE1UGLsANHP4fZY0A== X-Received: by 2002:a25:6d06:: with SMTP id i6-v6mr422560ybc.299.1528946514687; Wed, 13 Jun 2018 20:21:54 -0700 (PDT) Received: from [10.0.0.9] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id o79-v6sm834283ywd.80.2018.06.13.20.21.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 20:21:53 -0700 (PDT) From: Suresh Krishnan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_57F1715A-D4E4-4154-90B9-EFF53ED4BD5E" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 13 Jun 2018 23:21:52 -0400 In-Reply-To: <13b7679f-d448-0637-f2a1-84e2c729dd61@gmail.com> Cc: Tony Li , its@ietf.org To: Alexandre Petrescu References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <13b7679f-d448-0637-f2a1-84e2c729dd61@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [ipwave] ND implementations (was Re: Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 03:21:59 -0000 --Apple-Mail=_57F1715A-D4E4-4154-90B9-EFF53ED4BD5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alex/Tony, Doing a routing based solution for this is certainly possible, but the = fact remains that the IPv6 over 802.11 OCB document is still missing a = description of how ND works on such links. It would be great if people = with implementations chime in here as Russ said, so that we can progress = this draft and then open up for further improvements. Thanks Suresh > On Jun 12, 2018, at 3:29 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 12/06/2018 =C3=A0 05:24, Tony Li a =C3=A9crit : >> Alex, >>>> 1) top-antennas >>> The top-antenna may make an IP subnet with the RSU, yes. >>>> 2) front of Car1 >>> front of Car1 and rear of Car2 form a single IP subnet. >>>> 3) between the two Cars >>> The IP subnet between two Cars is the same IP subnet as the IP >>> subnet of the rear antenna of Car1 and the IP subnet of Car2. >>> There is just one IP subnet between Car1 and Car2, and the members >>> of that subnet are the front-antenna of Car1 and rear-antenna of >>> Car2. >> Ok, if you choose to model things this way, then you effectively have >> only two subnets, one for the top antenna and one for everything >> else. >=20 > No. There is one subnet for the top antenna and its RSU, one subnet = for rear antenna and one subnet for front antenna. >=20 >> This CAN work for some things, but will necessarily be >> problematic in some ways. As the convoy grows, the front antenna on >> the front car may not have connectivity to the back antenna on the >> rear car. As such, your subnet may not be fully connected, and >> that=E2=80=99s going to cause some confusion and failures. >=20 > I agree with the problem you describe, but note that this is not what = I meant. >=20 > What I meant is this: one subnet for top antenna with RSU, one subnet = in front of car and one subnet in rear of car. >=20 > With this schema I think it is not problematic. >=20 >> I don=E2=80=99t recommend this approach. If it were up to me, I would = make >> each pairing a separate subnet and enable routing. >=20 > YEs, this is what we try to do. >=20 >>> I dont want _one_ protocol for IP routing, another one for >>> multicast routing, and probably 3rd protocol for link-scoped >>> multicast. >> Well, sorry, the IP protocol stack decouples multicast and unicast >> routing. We made that call along time ago, as having their >> development coupled would have slowed both of them. >>> PC1 must send a maintenance IP message to PC2 and PC3, as an IP >>> multicast message. I dont want PC1 to send a distinct message to >>> each other PCx in the convoy because it wont scale. >>> s4 s5 IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP >>> subnet x | | | PCx: Autonomous Drv. PC >>> w/ RTMaps |s1 |s2 |s3 s4, s5: IPv6 over OCB, >>> in LL mode | | | s1, s2, s3: Ethernet PC1 = PC2 PC3 >> That can work as long as the convoy is all in range of a single radio >> and then it is just a link layer multicast. >=20 > > s4 s5 > > IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x > > | | | PCx: Autonomous Drv. PC w/ = RTMaps > > |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL = mode > > | | | s1, s2, s3: Ethernet > > PC1 PC2 PC3 >=20 > In this schema there is an IP subnet in front of the car (s4) and = another IP subnet in the rear of the car (s5). >=20 > IP routing is enabled. >=20 > Alex >> Tony >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = --Apple-Mail=_57F1715A-D4E4-4154-90B9-EFF53ED4BD5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alex/Tony,
  Doing a routing based solution for this = is certainly possible, but the fact remains that the IPv6 over 802.11 = OCB document is still missing a description of how ND works on such = links. It would be great if people with implementations chime in here as = Russ said, so that we can progress this draft and then open up for = further improvements.

Thanks
Suresh

On Jun = 12, 2018, at 3:29 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 12/06/2018 =C3=A0 05:24, Tony = Li a =C3=A9crit :
Alex,
1) = top-antennas
The top-antenna may make an IP = subnet with the RSU, yes.
2) front of Car1
front of Car1 and = rear of Car2 form a single IP subnet.
3) between the two Cars
The IP subnet between two Cars is the same IP = subnet as the IP
subnet of the rear antenna of Car1 and = the IP subnet of Car2.
There is just one IP subnet between = Car1 and Car2, and the members
of that subnet are the = front-antenna of Car1 and rear-antenna of
Car2.
Ok, if you choose to model things this way, then = you effectively have
only two subnets, one for the top = antenna and one for everything
else.

No.  There is one subnet for the top antenna and its = RSU, one subnet for rear antenna and one subnet for front = antenna.

This = CAN work for some things, but will necessarily be
problematic in some ways. As the convoy grows, the front = antenna on
the front car may not have connectivity to the = back antenna on the
rear car.  As such, your subnet = may not be fully connected, and
that=E2=80=99s going to = cause some confusion and failures.

I agree with the problem you = describe, but note that this is not what I meant.

What I meant is this: one subnet = for top antenna with RSU, one subnet in front of car and one subnet in = rear of car.

With this = schema I think it is not problematic.

I don=E2=80=99t recommend this = approach. If it were up to me, I would make
each pairing a = separate subnet and enable routing.

YEs, this is what we try to = do.

I dont want _one_ = protocol for IP routing, another one for
multicast = routing, and probably 3rd protocol for link-scoped
multicast.
Well, sorry, the IP = protocol stack decouples multicast and unicast
routing. We = made that call along time ago, as having their
development = coupled would have slowed both of them.
PC1 must send a maintenance IP message to PC2 = and PC3, as an IP
multicast message.  I dont want PC1 = to send a distinct message to
each other PCx in the convoy = because it wont scale.
s4 =          s5 IP-OBU1 --- = IP-OBU2 --- IP-OBU3    sx: distinct IP
subnet= x |           | =           | =        PCx: Autonomous Drv. PC
w/ RTMaps |s1 =         |s2 =         |s3 =      s4, s5: IPv6 over OCB,
in LL = mode |           | =           | =        s1, s2, s3: Ethernet PC1 =         PC2 =         PC3
That can work as long as the convoy is all in = range of a single radio
and then it is just a link layer = multicast.

>          s4 =          s5
>  IP-OBU1 --- IP-OBU2 = --- IP-OBU3    sx: distinct IP subnet x
>    | =           | =           | =        PCx: Autonomous Drv. PC w/ = RTMaps
> =    |s1 =         |s2 =         |s3 =      s4, s5: IPv6 over OCB, in LL = mode
> =    | =           | =           | =        s1, s2, s3: Ethernet
>   PC1 =         PC2 =         PC3

In this schema there is an IP = subnet in front of the car (s4) and another IP subnet in the rear of the = car (s5).

IP routing is = enabled.

Alex
Tony

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

= --Apple-Mail=_57F1715A-D4E4-4154-90B9-EFF53ED4BD5E-- From nobody Wed Jun 13 22:14:09 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA16813109F for ; Wed, 13 Jun 2018 22:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u45y4QIVyUNF for ; Wed, 13 Jun 2018 22:14:06 -0700 (PDT) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (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 783F5131093 for ; Wed, 13 Jun 2018 22:14:06 -0700 (PDT) Received: by mail-pl0-x22a.google.com with SMTP id 6-v6so2290529plb.0 for ; Wed, 13 Jun 2018 22:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Uz1cPJYXzSgo9uwEtMoFcntTQy7GH7aD4Wk/wozvUXs=; b=o+YGmQbDriz1S/+zfXoOpX1G+6/XcVKr0G890P7EQpqDnQqwGqgWfPyusNXGw+pY5U hX8vp2QFBqZmVFMWMppAe0NuRDlSUEKnbC8cxKJ2KH6wQOrPyzcuhdCBknmBGF2p3y2W +aCI11x/1YhXtf0ztxf0thCmV/TmcIBkp2pFrxWORBIxgCe87ITOlI3lMEWf6UXws0lj G5ZPVGXY8G/8NnVegMQ6SIB+1Ci9Hwby4RxZ/rKwzteo/7qi1I6T93dq/AZpTVM20LWz Nhh2kZiF9UYXSQrFtkTTRdY9mF+BQnaogq8vtpBu7A1v8JgSo5brapiVqGFP/fQPKBdY 4oLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Uz1cPJYXzSgo9uwEtMoFcntTQy7GH7aD4Wk/wozvUXs=; b=of8O3gRilQA+hYZFVwxkv6ye5bH9lAA+ecgGs5IeYWz9+okivWkA/oBo+9Bp4Z5Oqa fcEg0ty7IiSQf9NIcJ94q6W0PsxYVEZMb5/cPXyEk2lZWYvFX0vxveQ5NX69M0K+4Ku4 PDu5/JWX5QI1W4IgCAmiGHo/1KvDIa65xHxA1EzafYm16a3IAfQJsIO5bPt5nyM4WQFO hcVvUKBDtIl89iIAtsigY+zf2rbDBQ0KEWlybOrizuCZsFHQG6ZTWEt+awTUPGaBTuhp dnhF3/EfOyvocAaQ/KsYFqIHPntL7toV5BdFNvnS0jGTEECCK7swOyOJqWXADPb0a0Vf XPdw== X-Gm-Message-State: APt69E0Use/rZVkPyI6ThZe9qzoiIFNrJhLW7+xtrtQmsidKCsaQf8tC oCqq5xXXJxeUau5DqC7AOXM= X-Google-Smtp-Source: ADUXVKJnR6OHOdimkq6qIJoHVP2oP/3tb+KVhek+bzb94LgBpZI2sP/DIy9KLqeMPuVbgwdMUtGymA== X-Received: by 2002:a17:902:760d:: with SMTP id k13-v6mr1282563pll.56.1528953246169; Wed, 13 Jun 2018 22:14:06 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-209-5.hsd1.ca.comcast.net. [24.130.209.5]) by smtp.gmail.com with ESMTPSA id y15-v6sm6184223pfm.136.2018.06.13.22.14.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 22:14:05 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_61EC905B-7991-4685-9F2A-E0904E62033D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 13 Jun 2018 22:14:04 -0700 In-Reply-To: Cc: Alexandre Petrescu , its@ietf.org To: Suresh Krishnan References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <13b7679f-d448-0637-f2a1-84e2c729dd61@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] ND implementations (was Re: Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 05:14:08 -0000 --Apple-Mail=_61EC905B-7991-4685-9F2A-E0904E62033D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 13, 2018, at 8:21 PM, Suresh Krishnan = wrote: >=20 > Doing a routing based solution for this is certainly possible, but the = fact remains that the IPv6 over 802.11 OCB document is still missing a = description of how ND works on such links. It would be great if people = with implementations chime in here as Russ said, so that we can progress = this draft and then open up for further improvements. I=E2=80=99ll say it again: ND over OCB should operate just as over = Ethernet or Wi-Fi. Folks are, of course, welcome to make local timing = configuration changes, but that doesn=E2=80=99t affect anything = fundamental. T --Apple-Mail=_61EC905B-7991-4685-9F2A-E0904E62033D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 13, 2018, at 8:21 PM, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:

Doing a routing based solution = for this is certainly possible, but the fact remains that the IPv6 over = 802.11 OCB document is still missing a description of how ND works on = such links. It would be great if people with implementations chime in = here as Russ said, so that we can progress this draft and then open up = for further improvements.


I=E2=80=99= ll say it again: ND over OCB should operate just as over Ethernet or = Wi-Fi. Folks are, of course, welcome to make local timing configuration = changes, but that doesn=E2=80=99t affect anything fundamental.

T
= --Apple-Mail=_61EC905B-7991-4685-9F2A-E0904E62033D-- From nobody Fri Jun 15 01:51:53 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F975130DE0 for ; Fri, 15 Jun 2018 01:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCX6wW2HfoX7 for ; Fri, 15 Jun 2018 01:51:50 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FAC130DDD for ; Fri, 15 Jun 2018 01:51:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F8plmX069241; Fri, 15 Jun 2018 10:51:47 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD75E20496E; Fri, 15 Jun 2018 10:51:47 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CF8EB20324A; Fri, 15 Jun 2018 10:51:47 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F8plRt032059; Fri, 15 Jun 2018 10:51:47 +0200 To: tony.li@tony.li Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> From: Alexandre Petrescu Message-ID: <0ee5fcb8-5a45-29a3-28f5-9a567c1dfd3f@gmail.com> Date: Fri, 15 Jun 2018 10:51:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 08:51:53 -0000 Le 12/06/2018 à 20:25, tony.li@tony.li a écrit : > >>>> But I need somebody who has tried IPv6 multicast in an IP structure like this. PC1 must send an IP datagram to an IP multicast address to which PC2 and PC3 are part of. >>>> >>>>> s4 s5 >>>>> IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x >>>>> | | | PCx: Autonomous Drv. PC w/ RTMaps >>>>> |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode >>>>> | | | s1, s2, s3: Ethernet >>>>> PC1 PC2 PC3 >>>> >>>> If this does not work with IPv6 multicast between laptops on a table then it will not work in a convoy either. >>> This should work with IP multicast right out of the box, but you will need both unicast and mcast protocols, plus mcast listeners. >> >> I need to know how it works. I have the ability to some trial here, but if somebody already did, and has some howto, then I would be very much grateful. > > > > This is unicast and mcast 101. I can agree with yout hat this is unicast one-on-one: something very straightforward and easy to to, that can be done just by two people. However, for multicat it is not that 101. Multicast 101 as deployed in the Internet is like a tree. In the root and in the middle the bandwidths are very high, and at the edges the bandwidht is much lower. E.g. 10Gbp/s in the root and 10Mbit/s at the edge. However, in the case of convoy of cars, that ratio is reversed. We have 1Gbit/s in the car Ethernet (the edge, s1, s2, s3 in figure) but we only have 54Mbit/s in the OCB network between cars (the core, s4, s5). Will multicast of Internet - PIM-DM quagga and MLD linux - work ok in convoy? Alex Almost any PD stack that has OSPF and an mcast protocol will work. DVMRP is sufficient, if wildly antiquated. PIM-DM would also work. There are of course more > sophisticated variants of PIM if you can find them. > > Your app will need to generate IGMP Joins. > > Tony > > From nobody Fri Jun 15 01:56:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF9E130DDD for ; Fri, 15 Jun 2018 01:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9Uc5TNlP2Rs for ; Fri, 15 Jun 2018 01:56:38 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8CD130DE0 for ; Fri, 15 Jun 2018 01:56:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F8ua4M033924; Fri, 15 Jun 2018 10:56:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F7A020477A; Fri, 15 Jun 2018 10:56:36 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F2A78201FB5; Fri, 15 Jun 2018 10:56:35 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F8uZnI002567; Fri, 15 Jun 2018 10:56:35 +0200 To: tony.li@tony.li, Suresh Krishnan Cc: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <13b7679f-d448-0637-f2a1-84e2c729dd61@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 15 Jun 2018 10:56:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] ND implementations (was Re: Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 - broadcast vs unicast vs multicast) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 08:56:41 -0000 Le 14/06/2018 à 07:14, tony.li@tony.li a écrit : > > >> On Jun 13, 2018, at 8:21 PM, Suresh Krishnan >> > wrote: >> >> Doing a routing based solution for this is certainly possible, but the >> fact remains that the IPv6 over 802.11 OCB document is still missing a >> description of how ND works on such links. It would be great if people >> with implementations chime in here as Russ said, so that we can >> progress this draft and then open up for further improvements. > > > I’ll say it again: ND over OCB should operate just as over Ethernet or > Wi-Fi. Folks are, of course, welcome to make local timing configuration > changes, but that doesn’t affect anything fundamental. I fully agree. There is however some messages from Lorenzo on 6MAN WG that I need to better understand. He claims, by logical thinking, visibly not by trying ND on OCB, that ND does not work on OCB if certain conditions are unsatisfied. That is something we could address. _If_ we address it, then maybe it will persuade google Android team to modify their WiFi drivers in Android to run OCB. If so, that would be a huge advantage in VRU (Virtual Road Users) demonstrators. They just carry the smartphones they usually carry anyways, turn 'detectability' on, and thus avoid accidents. If you know the recent self-driving car accidents between car and VRU then you realize how important that can be. Until now, all the VRU demonstrators must equip people with some specific OCB device (not Android) before any demo can be performed. Alex > > T > From nobody Fri Jun 15 05:04:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D90D130DF7 for ; Fri, 15 Jun 2018 05:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fpXiMnkn5nM for ; Fri, 15 Jun 2018 05:04:41 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5522D130E06 for ; Fri, 15 Jun 2018 05:04:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FC4cTS000539 for ; Fri, 15 Jun 2018 14:04:38 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BEE2A204B26 for ; Fri, 15 Jun 2018 14:04:38 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B58D9204AA5 for ; Fri, 15 Jun 2018 14:04:38 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FC4cHo025259 for ; Fri, 15 Jun 2018 14:04:38 +0200 References: <10d242f7-dcc4-ebcb-9501-59f32e723ec8@gmail.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <10d242f7-dcc4-ebcb-9501-59f32e723ec8@gmail.com> Message-ID: Date: Fri, 15 Jun 2018 14:04:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <10d242f7-dcc4-ebcb-9501-59f32e723ec8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [ipwave] Fwd: Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 12:04:43 -0000 Hi IPWAVErs, An important comment was made on our draft, in the 6man WG. The comment is the following: ND on OCB can not be 'different' than ND on normal links, while being at the same time 'not specified' And this is what this current text suggests: >> The operation of the Neighbor Discovery protocol (ND) over >> 802.11-OCB links is different than over 802.11 links. In OCB, the >> link layer ^^^^^^^^^ >> does not ensure that all associated members receive all messages, >> because there is no association operation. The operation of ND >> over 802.11-OCB is not specified in this document. [...] >> The operation of ND over 802.11-OCB is not specified in this >> document. To solve this issue, I propose that we remove the latter phrase. Do you disagree? Alex -------- Message transféré -------- Sujet : Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 Date : Thu, 14 Jun 2018 08:50:17 +1200 De : Brian E Carpenter Pour : Suresh Krishnan , Lorenzo Colitti Copie à : Alexandre Petrescu , 6man , draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org I see that there has been no significant change in the -23 version. The two contradictory statements are still present: > The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB > links is different than over 802.11 links. In OCB, the link layer > does not ensure that all associated members receive all messages, > because there is no association operation. The operation of ND over > 802.11-OCB is not specified in this document. ND can't be both "different" and "not specified". Also, an IPv6 spec without neighbour discovery is incomplete and seems likely to be unusable. Regards Brian Carpenter On 17/05/2018 04:37, Suresh Krishnan wrote: > Hi Lorenzo, > > On May 14, 2018, at 9:41 PM, Lorenzo Colitti > > wrote: > > On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter > > > wrote: What I understand is that multicast is highly unreliable on > OCB (as opposed to reasonably reliable on classical 802.11). > > Because you not specify how neighbours are discovered, I don't see > how an actual IPv6 service could be provided. > > If that's true then that means this document does not actually > specify a feasible scheme to implement IPv6 over this network type. > As such, perhaps the 6man WG should recommend that this document > should not be published until it either documents a working > specification or at least clearly and unambiguously documents what > works and what doesn’t. > > Yep. That would be the right thing to do, > > > Suresh, chairs - what's the best way forward here? Would it be a good > idea to present this document at the 6man slot in Montreal to solicit > input from other participants and see if together we can come up with > better text? > > I’d rather not wait till the Montreal meeting if we can make progress > on this document before then. I will have a discussion with the > ipwave/6man chairs and the document editor to work out a way forward > > Regards Suresh > From nobody Fri Jun 15 05:13:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5B130DF5 for ; Fri, 15 Jun 2018 05:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR44cbs6z6Mj for ; Fri, 15 Jun 2018 05:13:52 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 848AF130DF2 for ; Fri, 15 Jun 2018 05:13:52 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id q6-v6so8764869qtn.7 for ; Fri, 15 Jun 2018 05:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=SUx9J+P5G+txq0f0sTcCCN7WdpOY/+FSJFJjQTD1SPk=; b=pLCe9pBiwEBN/JIUG2dv7kWpHaXkuiXHxrUF1SIeAJvyTgHyV3h2xI0KkLUMOnSRRE J/dI+FX0GmjWcEczx18qBUiJlVmkdjxhaTZAF08F7uTDef1C/tjVp90PyZVFon3/F7Jf zH7d+X+cm+n3Mj+iuwdSFzqodq/ffZEnzNhvnsjDVGYp2oo9ol9aq81Ya6mid4MfZvt/ rUSi14Ssn4JGGhjMlz1+weMu2+Fe5Zn1zS1vpBaoq4b4vo0xm0gRXL1fXnb7psSxbNBV pAiF9Z9DhbaTQwdGGEY/TRO8v+SIUWdbi1X47lAhe5R0J0NQchABX3qUiMiZw8N2/QHn JmFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=SUx9J+P5G+txq0f0sTcCCN7WdpOY/+FSJFJjQTD1SPk=; b=h22ayQhjo1f07cAluZkd1TnFcOF99y5aHX0EDESbdsgGZQktHd2xWMdsnJ4RDbcPoq Rt3i67KQGKep08t1bkspnjrN11czsc3a1csl2DsDzJwxnFvQhSE6H4/MftqBKMtBSary lS7hfcKFCeoRV+1smTt6SpMtEQ0U5cFFUnwc//gD5FTkYey1wRB5XmSV1MWIX9yRx88S nvQDqmQGchEL8qd13sYBMuyawbcS66MUVdSXdlPUaaHmKtpYe9Fj2xG2BoUztxe84yTH yV7kVg+UWDOmQUYwFXxZ8Ger78bghyEwf7dvB1NChWCI+0W0rK7Y6puqmfL3aZv+sOMW /TTw== X-Gm-Message-State: APt69E0Gey1w5kp9CE5crVx1/XgXJxYoxIXhvwQIIqqsREbaPRVXumE3 fKtmgEki9azJnQ0POAPRIYc= X-Google-Smtp-Source: ADUXVKKbXKwA1/+zkw1LRAIQ9yJ8RgglOMPYBHiqLXvmu8gG/gRfL8HRn7gq+NbdmRwsa0dUA6iVDQ== X-Received: by 2002:a0c:d276:: with SMTP id o51-v6mr1101968qvh.182.1529064831652; Fri, 15 Jun 2018 05:13:51 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id r29-v6sm5960157qki.0.2018.06.15.05.13.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 05:13:50 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , , References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> <701f0d97c27249cb8ed282d9f5fd9976@tno.nl> <001701d40448$0c2e14d0$248a3e70$@gmail.com> In-Reply-To: <001701d40448$0c2e14d0$248a3e70$@gmail.com> Date: Fri, 15 Jun 2018 08:13:51 -0400 Message-ID: <003701d404a2$532c1d00$f9845700$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0038_01D40480.CC1CC6F0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQH3iqU+zn5zmzS6LbSK5N2mXxh6VAIdH2vXAr6d+zcBaUNIvgISdb7qA3efq9ECQzDtFgIM/giZArsPBlEBqG7lJwL7Ao/UAmp+OmkCIamg2AG5gRw+Ammq6hwCAgfgXqMIr4Zw Archived-At: Subject: [ipwave] FW: multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 12:13:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0038_01D40480.CC1CC6F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0039_01D40480.CC1CC6F0" ------=_NextPart_001_0039_01D40480.CC1CC6F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9CThat would be called a routing protocol.=E2=80=9D Below is a = sample of the list of routing protocols that are developed for ad-hoc = networks (e.g.; V2V). Extracted from =E2=80=9CMOBILE AD-HOC DIGITAL = COMMUNICATIONS NETWORK - OVERVIEW=E2=80=9D - 2007 =20 =E2=80=9CRouting Protocols for Ad-hoc Networks =20 Here is where the =E2=80=98madness=E2=80=99 starts. Since ad-hoc is = such a complex network infrastructure and also has a high profile in the = Government (i.e. DoD) as well as in the commercial sectors, every = standard, research, and academia organizations have their own idea and = solution for a wireless ad-hoc network routing protocol (in some cases = application dependent). There are no less than 130 routing protocols, = and growing, related to ad-hoc wireless network. The routing protocol = is the key factor for Ad Hoc Network. It decides directly the = performance of the whole network: =20 Table-Driven Routing Protocols * Destination-Sequenced Distance-Vector (DSDV)=20 * Clusterhead Gateway Switch Routing (CGSR)=20 * The Wireless Routing Protocol (WRP)=20 * More....=20 Source-Initiated On-Demand Routing Protocols=20 * Ad Hoc On-Demand Distance Vector Routing (AODV)=20 * Dynamic Source Routing (DSR)=20 * Temporally Ordered Routing Algorithm (TORA)=20 * Associativity-Based Routing (ABR) * More=E2=80=A6=E2=80=A6. =20 Location Information Based (Based) Routing Protocols=20 * Location Aid Routing (LAR)=20 * Grid's Location Service Routing (GLS)=20 * More....=E2=80=9D =20 Fygs =20 =20 From: Fran=C3=A7ois Simon =20 Sent: Thursday, June 14, 2018 9:28 PM To: fygsimon@gmail.com Subject: FW: [ipwave] multicast in convoy =20 =20 =20 From: its > On = Behalf Of Velt, R. (Ronald) in 't Sent: Wednesday, June 13, 2018 12:23 PM To: tony.li@tony.li ; Alexandre Petrescu = > Cc: its@ietf.org =20 Subject: Re: [ipwave] multicast in convoy =20 (below) =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of tony.li@tony.li = =20 Sent: woensdag 13 juni 2018 16:13 To: Alexandre Petrescu > Cc: its@ietf.org =20 Subject: Re: [ipwave] multicast in convoy =20 =20 =20 On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu < = alexandre.petrescu@gmail.com> = wrote: =20 n order to work with three cars, we must find a way for one IP-OBU to = read its own routing table, realize that a new entry is present and then = send it on an interface that is not the interface on which that prefix = arrived. That would propagate it. If there is another means to propagate, then I am listening. =20 =20 That would be called a routing protocol. =20 :-] =20 I would suggest OSPF (or, if you=E2=80=99re very brave, IS-IS). =20 I would suggest OLSRv2 (RFC 7181 and friends), an IETF Standards Track = protocol that works even if your IP-OBU has only one radio interface. = Implementation here: =20 https://github.com/OLSR/OONF =20 That=E2=80=99s for unicast. MANET multicast is a tad more complicated. = SMF (RFC 6621, Experimental) is a first attempt. (Implementation here: = https://www.nrl.navy.mil/itd/ncs/products/smf ) =20 Ronald =20 Tony =20 =20 This message may contain information that is not intended for you. If = you are not the addressee or if this message was sent to you by mistake, = you are requested to inform the sender and delete the message. TNO = accepts no liability for the content of this e-mail, for the manner in = which you use it and for damage of any kind resulting from the risks = inherent to the electronic transmission of messages. ------=_NextPart_001_0039_01D40480.CC1CC6F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=E2=80=9CThat would be called a = routing protocol.=E2=80=9D=C2=A0 =C2=A0Below is a sample of the list = of routing protocols that are developed for ad-hoc networks (e.g.; = V2V).=C2=A0 Extracted from =E2=80=9CMOBILE AD-HOC DIGITAL = COMMUNICATIONS NETWORK - =C2=A0OVERVIEW=E2=80=9D - 2007

 

=E2=80=9CRouting = Protocols for Ad-hoc Networks

 

Here is where the =E2=80=98madness=E2=80=99 = starts.=C2=A0 Since ad-hoc is such a complex network infrastructure and = also has a high profile in the Government (i.e. DoD) as well as in the = commercial sectors, every standard, research, and academia organizations = have their own idea and solution for a wireless ad-hoc network routing = protocol (in some cases application dependent).=C2=A0 There are no less = than 130 routing protocols, and growing, related to ad-hoc wireless = network.=C2=A0 The routing protocol is the key factor for Ad Hoc = Network. It decides directly the performance of the whole = network:

 

Table-Driven = Routing Protocols

  • Destination-S= equenced Distance-Vector (DSDV)
  • Clusterhead = Gateway Switch Routing (CGSR)
  • The Wireless = Routing Protocol (WRP)
  • More.... =

Source-Initia= ted On-Demand Routing Protocols

  • Ad Hoc = On-Demand Distance Vector Routing (AODV)
  • Dynamic = Source Routing (DSR)
  • Temporally = Ordered Routing Algorithm (TORA)
  • Associativity-Based Routing (ABR)
  • More=E2=80=A6=E2=80=A6.

 

Location = Information Based (Based) Routing Protocols =

  • Location Aid = Routing  (LAR)
  • Grid's = Location Service Routing (GLS)
  • More....=E2=80= =9D

 

Fygs

 

 

From: Fran=C3=A7ois Simon = <fygsimon@gmail.com>
Sent: Thursday, June 14, 2018 9:28 = PM
To: fygsimon@gmail.com
Subject: FW: [ipwave] = multicast in convoy

 

 

 

From: its <its-bounces@ietf.org> On = Behalf Of Velt, R. (Ronald) in 't
Sent: Wednesday, June = 13, 2018 12:23 PM
To: tony.li@tony.li; Alexandre Petrescu = <alexandre.petrescu@gmail.com= >
Cc: its@ietf.org
Subject: Re: = [ipwave] multicast in convoy

 

(below)

 

From: = its [mailto:its-bounces@ietf.org] = On Behalf Of tony.li@tony.li
Sent: = woensdag 13 juni 2018 16:13
To: Alexandre Petrescu <alexandre.petrescu@gmail.com= >
Cc: its@ietf.org
Subject: Re: = [ipwave] multicast in convoy

 

 

 

On Jun 13, 2018, at 10:08 AM, Alexandre = Petrescu <alexandre.petrescu@gmail.com> = wrote:

 

n order to = work with three cars, we must find a way for one IP-OBU to read its own = routing table, realize that a new entry is present and then send it on = an interface that is not the interface on which that prefix = arrived.

That would propagate it.

If there is another = means to propagate, then I am = listening.

 

 

That would be called a = routing protocol.

 

:-]

 

I would suggest OSPF (or, = if you=E2=80=99re very brave, IS-IS).

 

I would = suggest OLSRv2 (RFC 7181 and friends), an IETF Standards Track protocol = that works even if your IP-OBU has only one radio interface. = Implementation here:

 

https://github.com/OLSR/OONF

 

That=E2=80=99s for unicast. MANET multicast is a tad = more complicated. SMF (RFC 6621, Experimental) is a first attempt. = (Implementation here: https://www.nrl.na= vy.mil/itd/ncs/products/smf )

 

Ronald

 

Tony

 

 

This = message may contain information that is not intended for you. If you are = not the addressee or if this message was sent to you by mistake, you are = requested to inform the sender and delete the message. TNO accepts no = liability for the content of this e-mail, for the manner in which you = use it and for damage of any kind resulting from the risks inherent to = the electronic transmission of messages.

------=_NextPart_001_0039_01D40480.CC1CC6F0-- ------=_NextPart_000_0038_01D40480.CC1CC6F0 Content-Type: text/plain; name="Untitled attachment 00009.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Untitled attachment 00009.txt" _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_0038_01D40480.CC1CC6F0-- From nobody Fri Jun 15 05:16:49 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EF5130DF5 for ; Fri, 15 Jun 2018 05:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuP4pOPWxVVX for ; Fri, 15 Jun 2018 05:16:44 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AA1130DF2 for ; Fri, 15 Jun 2018 05:16:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FCGgjt004506; Fri, 15 Jun 2018 14:16:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7D1E20190E; Fri, 15 Jun 2018 14:16:42 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9B39A20101B; Fri, 15 Jun 2018 14:16:42 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FCGgi7032538; Fri, 15 Jun 2018 14:16:42 +0200 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , tony.li@tony.li, its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> <701f0d97c27249cb8ed282d9f5fd9976@tno.nl> <001701d40448$0c2e14d0$248a3e70$@gmail.com> <003701d404a2$532c1d00$f9845700$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 15 Jun 2018 14:16:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <003701d404a2$532c1d00$f9845700$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 12:16:47 -0000 Thank you for the list. It is very useful. However: none of them is maintained, or available as cheap open source, like quagga suite is (OSPF, BGP, etc). Alex Le 15/06/2018 à 14:13, François Simon a écrit : > /“That would be called a routing protocol.” / Below is a sample of the > list of routing protocols that are developed for ad-hoc networks (e.g.; > V2V).  Extracted from “*MOBILE AD-HOC DIGITAL COMMUNICATIONS NETWORK - >  OVERVIEW” - 2007*** > > > “*/Routing Protocols for Ad-hoc Networks/* > > // > > /Here is where the ‘madness’ starts.  Since ad-hoc is such a complex > network infrastructure and also has a high profile in the Government > (i.e. DoD) as well as in the commercial sectors, every standard, > research, and academia organizations have their own idea and solution > for a wireless ad-hoc network routing protocol (in some cases > application dependent).  There are no less than 130 routing protocols, > and growing, related to ad-hoc wireless network.  The routing protocol > is the key factor for Ad Hoc Network. It decides directly the > performance of the whole network:/ > > // > > */Table-Driven Routing Protocols/* > > * /Destination-Sequenced Distance-Vector (DSDV) / > * /Clusterhead Gateway Switch Routing (CGSR) / > * /The Wireless Routing Protocol (WRP) / > * /More.... / > > */Source-Initiated On-Demand Routing Protocols /* > > * /Ad Hoc On-Demand Distance Vector Routing (AODV) / > * /Dynamic Source Routing (DSR) / > * /Temporally Ordered Routing Algorithm (TORA) / > * /Associativity-Based Routing (ABR)/ > * /More……./ > > // > > */Location Information Based (Based) Routing Protocols /* > > * /Location Aid Routing  (LAR) / > * /Grid's Location Service Routing (GLS) / > * /More....”/ > > Fygs > > *From:* François Simon > *Sent:* Thursday, June 14, 2018 9:28 PM > *To:* fygsimon@gmail.com > *Subject:* FW: [ipwave] multicast in convoy > > *From:* its > *On > Behalf Of *Velt, R. (Ronald) in 't > *Sent:* Wednesday, June 13, 2018 12:23 PM > *To:* tony.li@tony.li ; Alexandre Petrescu > > > *Cc:* its@ietf.org > *Subject:* Re: [ipwave] multicast in convoy > > (below) > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *tony.li@tony.li > > *Sent:* woensdag 13 juni 2018 16:13 > *To:* Alexandre Petrescu > > *Cc:* its@ietf.org > *Subject:* Re: [ipwave] multicast in convoy > > On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu > > > wrote: > > n order to work with three cars, we must find a way for one IP-OBU > to read its own routing table, realize that a new entry is present > and then send it on an interface that is not the interface on which > that prefix arrived. > > That would propagate it. > > If there is another means to propagate, then I am listening. > > That would be called a routing protocol. > > :-] > > I would suggest OSPF (or, if you’re very brave, IS-IS). > > I would suggest OLSRv2 (RFC 7181 and friends), an IETF Standards Track > protocol that works even if your IP-OBU has only one radio interface. > Implementation here: > > https://github.com/OLSR/OONF > > That’s for unicast. MANET multicast is a tad more complicated. SMF (RFC > 6621, Experimental) is a first attempt. (Implementation here: > https://www.nrl.navy.mil/itd/ncs/products/smf ) > > Ronald > > Tony > > This message may contain information that is not intended for you. If > you are not the addressee or if this message was sent to you by mistake, > you are requested to inform the sender and delete the message. TNO > accepts no liability for the content of this e-mail, for the manner in > which you use it and for damage of any kind resulting from the risks > inherent to the electronic transmission of messages. > From nobody Fri Jun 15 05:21:39 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D091130DF5 for ; Fri, 15 Jun 2018 05:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWO_1JYWSyGT for ; Fri, 15 Jun 2018 05:21:35 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 7FFE5130DF2 for ; Fri, 15 Jun 2018 05:21:35 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id h5-v6so8757154qtm.13 for ; Fri, 15 Jun 2018 05:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:content-language :thread-index; bh=1seKOl6rgjDI/unCUWel8dyzxppOdYasyuDoIfyUnfo=; b=QNNsYOdik8uceR6y0w+aS7BvV3NbJre22PRZGckrxgILVp5H77ysDQCgwIQdYO4qyS gGAZBokNiw8FWvfrBv9jxYsZvESRCZ+dAEqwLAzHxiaCob/Mis2M/OhV94dXhHdi+aAi S5p2rYIoR46XwVT0p1gSOAVhtnltyDq3ItS6JFH3xGJxXyKjZzq7SXPFJygqLj3eNYg+ V1S2WfNbTsPX17wdAMd5CY7VZzQ+ry4fV8KekQyYjgwgQV6UuWn2mxbmMO9Etbz8XZ0v 0CuJOh7pi1656BBdxQNcj2R9ya+UCdxb/NxuwYGxBXz14b2aeCyX6WpES7Kq82hdpiIA sQBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-language:thread-index; bh=1seKOl6rgjDI/unCUWel8dyzxppOdYasyuDoIfyUnfo=; b=DShnfXjasQtqjmXce+pChT6cXXPVGGFheb9G1OKhOm/QnkL1pAmKophbXXJUWMNc+7 DtehXcHcNdjRagfI+Az3XFSeGbsIUnP+s5MqVhx81EDKSqpasJu00GL72MizpPr9wxdo zXdibMlkzeFxpW9upRNLVHW/jyHM9BE/BfqgIN3k+X8vbTdMXs4TS3BwT4O5Fiog0+20 9pK1BqgEi4hfwdz0VhqOQiCzSAI5VOK/emzxMIgXcv1jzABVUlliLasAIt5ByxtcyNbB zeEe1fZwHOqeRmar00/U0RHo6ULm8ntlx2refuOReAiPVydFfYi2+PWHw1qou8fQG4vz jL3Q== X-Gm-Message-State: APt69E20K7Vsmld+6sYvFy+LZKodcH7NRnb2tSDrR9UBn5RPOYEeD1Ik iXxhwvDHF5pV+jjOyDeb6pk= X-Google-Smtp-Source: ADUXVKJo6kiZzS9ssgzSp7yy66szf5yy1zYt3UToldH9peNkN0Pgf6korIymfOcaQgmxZ6WyTECNsw== X-Received: by 2002:ac8:2fec:: with SMTP id m41-v6mr1225804qta.55.1529065294605; Fri, 15 Jun 2018 05:21:34 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id y128-v6sm5142458qkc.1.2018.06.15.05.21.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 05:21:34 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: Cc: Date: Fri, 15 Jun 2018 08:21:35 -0400 Message-ID: <004101d404a3$67598f50$360cadf0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D40481.E047EF50" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdQEoyNFvFIqK0GyS7O4M7TE9Oml1w== Archived-At: Subject: [ipwave] TTNT X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 12:21:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01D40481.E047EF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting article =96 =93just made for IP=85..=94 http://www.mwrf.com/systems/tapping-tactical-targeting-network-technology= Fygs =20 ------=_NextPart_000_0042_01D40481.E047EF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Interesting article – “just made for = IP…..”=A0 http://www.mwrf.com/systems/tapping-tactical-targeting-network-= technology=A0=A0=A0=A0=A0 Fygs

 

------=_NextPart_000_0042_01D40481.E047EF50-- From nobody Fri Jun 15 05:41:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63CD130E5C for ; Fri, 15 Jun 2018 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCbWU4UmbcDn for ; Fri, 15 Jun 2018 05:41:26 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010: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 788E6130E0F for ; Fri, 15 Jun 2018 05:41:25 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id q11-v6so14435310lfc.7 for ; Fri, 15 Jun 2018 05:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UGEteIRrrWo/468Nu/9THdm4E90mTfMVAEynRH0IHxE=; b=DkzxH5JJbf65ZNUYLmCaQMpzp3nFMa2tBoDLM4v4nrv8QEDop9kYjrSHPf9xrxwJgw PZU0j8Pdg2B7Lodmr0HRiBFbXNLBtwEMB/6NhPaLyaVeiaVOMYdNu7sNI+5fKww2E+aj 95zcynfXQRR+kYXusNYxZbpolwaaUlPaO8bclD82Id6zI/uBn+qoUxHb0WVmXc7nC7J/ TIrq3ipVBMqQI/RrNp1DqvgG+hM6E31Tm9NySLHEIZ4Ou9esjl0E0eAAFkbPIPgmzRHi VQ3Z/Tpkpp3kfJpZqybaFy4BXvBXeAvzx4o7sqe4V1mp40oIH9Gu5IMwuAVktan4a1bd dt1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UGEteIRrrWo/468Nu/9THdm4E90mTfMVAEynRH0IHxE=; b=a3yAeC4Wbnl9HwVT+0KrnhC5kP3pd/drYjZ1HKesNyjaefHgUrzc/oU/m3Z6dUI2me 3aGkPKN7ftTRhKL8ghDCmc5ylPXR35qqCgzifloIf2gkOCF+3WIJCGvAZdZKlbQtzjZg BPEaWOCay4S3Y1JRI2AwFYMTS5Rj1REOfCKwZ5glNudnU4QwRWmpfiGfVB6dNwGwL0nf y+UQefgIK6giUCt3+U1mD5CHcsUE4yUkvpTMXTOB0qou3IIkQPv9e3TZPzdQKXxGlMbH XVf/1ORm5Oz2cWXZpXripTyzY2Sp4kku9yQBAdoOiN8ixUZS7VcAqEgQ33CNORRdbQxB yH9Q== X-Gm-Message-State: APt69E1ZPrHPfskWRldKQ241EQCuwc1K8J/lwvgvwsJ9vugFUe15GU86 Eu/gyljBy1Rz0njzDQ1yDDCekYq3/uEOUZXHGHA= X-Google-Smtp-Source: ADUXVKJVKXfKUxLFk3sRg1gx3vYyHdDAC/2M/VlGlrDDHWXQYJy/md5g9ASrqhRG3nbzmwPlESsYSN85cnH81os0hGw= X-Received: by 2002:a2e:870d:: with SMTP id m13-v6mr1218934lji.139.1529066483500; Fri, 15 Jun 2018 05:41:23 -0700 (PDT) MIME-Version: 1.0 References: <10d242f7-dcc4-ebcb-9501-59f32e723ec8@gmail.com> In-Reply-To: From: Nabil Benamar Date: Fri, 15 Jun 2018 12:41:10 +0000 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009649b6056ead889e" Archived-At: Subject: Re: [ipwave] Fwd: Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 12:41:28 -0000 --0000000000009649b6056ead889e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, I agree on removing this sentence: "The operation of ND over 802.11-OCB is not specified in this document." Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 On Fri, Jun 15, 2018 at 12:04 PM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi IPWAVErs, > > An important comment was made on our draft, in the 6man WG. > > The comment is the following: ND on OCB can not be 'different' than ND > on normal links, while being at the same time 'not specified' > And this is what this current text suggests: > > >> The operation of the Neighbor Discovery protocol (ND) over > >> 802.11-OCB links is different than over 802.11 links. In OCB, the > >> link layer > ^^^^^^^^^ > >> does not ensure that all associated members receive all messages, > >> because there is no association operation. The operation of ND > >> over 802.11-OCB is not specified in this document. > [...] > >> The operation of ND over 802.11-OCB is not specified in this > >> document. > > To solve this issue, I propose that we remove the latter phrase. > > Do you disagree? > > Alex > > > > > > > -------- Message transf=C3=A9r=C3=A9 -------- > Sujet : Re: Request for 6man review of > draft-ietf-ipwave-ipv6-over-80211ocb-22 > Date : Thu, 14 Jun 2018 08:50:17 +1200 > De : Brian E Carpenter > Pour : Suresh Krishnan , Lorenzo Colitti > > Copie =C3=A0 : Alexandre Petrescu , 6man > , draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > > I see that there has been no significant change in the -23 version. > The two contradictory statements are still present: > > The operation of the Neighbor Discovery protocol (ND) over > 802.11-OCB > > links is different than over 802.11 links. In OCB, the link layer > > does not ensure that all associated members receive all messages, > > because there is no association operation. The operation of ND over > > 802.11-OCB is not specified in this document. > > ND can't be both "different" and "not specified". > > Also, an IPv6 spec without neighbour discovery is incomplete and seems > likely to be unusable. > > Regards > Brian Carpenter > > > > On 17/05/2018 04:37, Suresh Krishnan wrote: > > Hi Lorenzo, > > > > On May 14, 2018, at 9:41 PM, Lorenzo Colitti > > > wrote: > > > > On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter > > > > > wrote: What I understand is that multicast is highly unreliable on > > OCB (as opposed to reasonably reliable on classical 802.11). > > > > Because you not specify how neighbours are discovered, I don't see > > how an actual IPv6 service could be provided. > > > > If that's true then that means this document does not actually > > specify a feasible scheme to implement IPv6 over this network type. > > As such, perhaps the 6man WG should recommend that this document > > should not be published until it either documents a working > > specification or at least clearly and unambiguously documents what > > works and what doesn=E2=80=99t. > > > > Yep. That would be the right thing to do, > > > > > > Suresh, chairs - what's the best way forward here? Would it be a good > > idea to present this document at the 6man slot in Montreal to solicit > > input from other participants and see if together we can come up with > > better text? > > > > I=E2=80=99d rather not wait till the Montreal meeting if we can make pr= ogress > > on this document before then. I will have a discussion with the > > ipwave/6man chairs and the document editor to work out a way forward > > > > Regards Suresh > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --0000000000009649b6056ead889e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

I agree on removing this sentence:= =C2=A0"The operation of ND= =C2=A0over 802.11-OCB is = not specified in this document."=C2=A0


Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86= =D8=B9=D9=85=D8=B1=D9=88






=
On Fri, Jun 15, 2018 at 12:04 P= M Alexandre Petrescu <al= exandre.petrescu@gmail.com> wrote:
Hi IPWAVErs,

An important comment was made on our draft, in the 6man WG.

The comment is the following: ND on OCB can not be 'different' than= ND
on normal links, while being at the same time 'not specified'
And this is what this current text suggests:

>> The operation of the Neighbor Discovery protocol (ND) over
>> 802.11-OCB links is different than over 802.11 links.=C2=A0 In OCB= , the
>> link layer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^
>> does not ensure that all associated members receive all messages, =
>> because there is no association operation.=C2=A0 The operation of = ND
>> over 802.11-OCB is not specified in this document.
[...]
>> The operation of ND over 802.11-OCB is not specified in this
>> document.

To solve this issue, I propose that we remove the latter phrase.

Do you disagree?

Alex






-------- Message transf=C3=A9r=C3=A9 --------
Sujet : Re: Request for 6man review of
draft-ietf-ipwave-ipv6-over-80211ocb-22
Date : Thu, 14 Jun 2018 08:50:17 +1200
De : Brian E Carpenter <brian.e.carpenter@gmail.com>
Pour : Suresh Krishnan <Suresh@kaloom.com>, Lorenzo Colitti
<lorenzo@google.= com>
Copie =C3=A0 : Alexandre Petrescu <alexandre.petrescu@gmail.com>, 6man
<ipv6@ietf.org>= ;, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org

I see that there has been no significant change in the -23 version.
The two contradictory statements are still present:
=C2=A0 >=C2=A0 =C2=A0 The operation of the Neighbor Discovery protocol (= ND) over 802.11-OCB
> links is different than over 802.11 links.=C2=A0 In OCB, the link laye= r
> does not ensure that all associated members receive all messages,
> because there is no association operation.=C2=A0 The operation of ND o= ver
> 802.11-OCB is not specified in this document.

ND can't be both "different" and "not specified".
Also, an IPv6 spec without neighbour discovery is incomplete and seems
likely to be unusable.

Regards
=C2=A0 =C2=A0 Brian Carpenter



On 17/05/2018 04:37, Suresh Krishnan wrote:
> Hi Lorenzo,
>
> On May 14, 2018, at 9:41 PM, Lorenzo Colitti
> <lorenzo@go= ogle.com<mailto:lorenzo@google.com>> wrote:
>
> On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter
> <b= rian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>
> wrote: What I understand is that multicast is highly unreliable on
> OCB (as opposed to reasonably reliable on classical 802.11).
>
> Because you not specify how neighbours are discovered, I don't see=
> how an actual IPv6 service could be provided.
>
> If that's true then that means this document does not actually
> specify a feasible scheme to implement IPv6 over this network type. > As such, perhaps the 6man WG should recommend that this document
> should not be published until it either documents a working
> specification or at least clearly and unambiguously documents what
> works and what doesn=E2=80=99t.
>
> Yep. That would be the right thing to do,
>
>
> Suresh, chairs - what's the best way forward here? Would it be a g= ood
> idea to present this document at the 6man slot in Montreal to solicit<= br> > input from other participants and see if together we can come up with<= br> > better text?
>
> I=E2=80=99d rather not wait till the Montreal meeting if we can make p= rogress
> on this document before then. I will have a discussion with the
> ipwave/6man chairs and the document editor to work out a way forward >
> Regards Suresh
>


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--0000000000009649b6056ead889e-- From nobody Fri Jun 15 07:11:14 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06EC130F20 for ; Fri, 15 Jun 2018 07:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdcpU65_P55k for ; Fri, 15 Jun 2018 07:11:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE6C130E0D for ; Fri, 15 Jun 2018 07:11:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4AABD20090 for ; Fri, 15 Jun 2018 10:24:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5AC3661; Fri, 15 Jun 2018 10:08:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5830314 for ; Fri, 15 Jun 2018 10:08:03 -0400 (EDT) From: Michael Richardson To: its@ietf.org In-Reply-To: <003701d404a2$532c1d00$f9845700$@gmail.com> References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> <701f0d97c27249cb8ed282d9f5fd9976@tno.nl> <001701d40448$0c2e14d0$248a3e70$@gmail.com> <003701d404a2$532c1d00$f9845700$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [ipwave] FW: multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 14:11:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Also, ROLL's RPL (RFC6550), and it's multicast *MPL* RFC7731. The trickle mechanism is often not associated with fast changing networks. To the extent that changes can be detected, trickle can operate as fast (or as slow, reducing power or bandwidth used) as needed. OLSRv2 is also an interesting choice. RFC6550 has an assymmetric (public key) authentication/authorization mode that has not been interesting in LLNs, but may be very much appropriate in this situation. Fran=C3=A7ois Simon wrote: > =E2=80=9CThat would be called a routing protocol.=E2=80=9D Below is a= sample of the list of > routing protocols that are developed for ad-hoc networks (e.g.; V2V). > Extracted from =E2=80=9CMOBILE AD-HOC DIGITAL COMMUNICATIONS NETWORK = - OVERVIEW=E2=80=9D - > 2007 > =E2=80=9CRouting Protocols for Ad-hoc Networks > Here is where the =E2=80=98madness=E2=80=99 starts. Since ad-hoc is s= uch a complex network > infrastructure and also has a high profile in the Government (i.e. Do= D) as > well as in the commercial sectors, every standard, research, and acad= emia > organizations have their own idea and solution for a wireless ad-hoc = network > routing protocol (in some cases application dependent). There are no = less > than 130 routing protocols, and growing, related to ad-hoc wireless n= etwork. > The routing protocol is the key factor for Ad Hoc Network. It decides > directly the performance of the whole network: > Table-Driven Routing Protocols > * Destination-Sequenced Distance-Vector (DSDV) > * Clusterhead Gateway Switch Routing (CGSR) > * The Wireless Routing Protocol (WRP) > * More.... > Source-Initiated On-Demand Routing Protocols > * Ad Hoc On-Demand Distance Vector Routing (AODV) > * Dynamic Source Routing (DSR) > * Temporally Ordered Routing Algorithm (TORA) > * Associativity-Based Routing (ABR) > * More=E2=80=A6=E2=80=A6. > Location Information Based (Based) Routing Protocols > * Location Aid Routing (LAR) > * Grid's Location Service Routing (GLS) > * More....=E2=80=9D > Fygs > From: Fran=C3=A7ois Simon > Sent: Thursday, June 14, 2018 9:28 PM > To: fygsimon@gmail.com > Subject: FW: [ipwave] multicast in convoy > From: its On Behalf Of Velt, R. (Ronald) in 't > Sent: Wednesday, June 13, 2018 12:23 PM > To: tony.li@tony.li; Alexandre Petrescu > Cc: its@ietf.org > Subject: Re: [ipwave] multicast in convoy > (below) > From: its [mailto:its-bounces@ietf.org] On Behalf Of tony.li@tony.li > Sent: woensdag 13 juni 2018 16:13 > To: Alexandre Petrescu > Cc: its@ietf.org > Subject: Re: [ipwave] multicast in convoy > On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu > wrote: > n order to work with three cars, we must find a way for one IP-OBU to > read its own routing table, realize that a new entry is present and t= hen > send it on an interface that is not the interface on which that prefix > arrived. > That would propagate it. > If there is another means to propagate, then I am listening. > That would be called a routing protocol. > :-] > I would suggest OSPF (or, if you=E2=80=99re very brave, IS-IS). > I would suggest OLSRv2 (RFC 7181 and friends), an IETF Standards Track > protocol that works even if your IP-OBU has only one radio interface. > Implementation here: > https://github.com/OLSR/OONF > That=E2=80=99s for unicast. MANET multicast is a tad more complicated= . SMF (RFC 6621, > Experimental) is a first attempt. (Implementation here: > https://www.nrl.navy.mil/itd/ncs/products/smf ) > Ronald > Tony > This message may contain information that is not intended for you. If= you are > not the addressee or if this message was sent to you by mistake, you = are > requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you= use it > and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages. > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyPIQICLcPvd0N1lAQLDfAgAooIhq9Lgd8SXNRJympQQ4wzoO5OP37YF YazaXoOvLPTQ64oDrKnCDoCsLkmJ6jFnXONwbwLEdJOy6wgD/B9DLnE+XhixsDWa jsqsYjCcwmOLVRSoM5eRejOfIWmtdYOAmM5SCJNblmWlpRqqIuZRJXZkwUikehSI S28mlS6ksWC46w+fYOoJPBRx9Y/bKymFhgrjlKq9D2g7i2M61BmWXmxNKMqKruRv mBS3ZZlHm7ZUKf2e92D1t8ivlvUb2/Yi90J9NXRvPABlh+x9c3c2s/S8WLetya8k WXMQRPQkVet3bIO5SoM2QLWMCrsuX9i6XY9ap3Io2PQJ5Tz6psXl+Q== =MSVh -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 15 08:11:18 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A6D130E1F for ; Fri, 15 Jun 2018 08:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dqVOxADX6GX for ; Fri, 15 Jun 2018 08:11:14 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 14281130DC0 for ; Fri, 15 Jun 2018 08:11:14 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id a63-v6so5025109pfl.1 for ; Fri, 15 Jun 2018 08:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qWhWL2AtqJj1viXZqyWKZWZ/7l0NBHCxJKZSdWNnhrE=; b=m3v2vNO3USylwBOpv0ktvlqif62Mc5wW/Uj/L/kB4xLlL9GNg7dstW+7pL33dEoHN9 p7NXi9xicJT63xsUXHJrOi/5+fJGO/xQsOJRQ8xrxzIyL6Dy88f+BH2UfcZW52Dgiuw0 j2QtSMYO7tc/Onbto56C3zuZElIHt3FxpI0CL+1PDT6vuKRlpsErbvN44LE+Du6IX5Wj hFK/nIW+MIn4htmNUxz8Tc5vGq4OKf6y+u8bkRt8tkUoW6QxOUIvG+vfbzZjGTh4TWmE hcIEv7hCMsEQU6SzZ+UJBSTYsyYCv47QWHZlEW0mN2cJW3CU/1RED0omYVa2uUYdO222 TNFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qWhWL2AtqJj1viXZqyWKZWZ/7l0NBHCxJKZSdWNnhrE=; b=MmH7TD1SesUpI+t7eXRKnhKDlSMcra8A7LF1M4ghDKhA7yhzlHtCG+20nM3O6PCnlv ViY7xKYT3p3yDR88YMlbCkbib8kZFjI8T92Enee4z7sdzNc13iQdVZtZKjtXVRCeTfRV M6SI3+QSASYhLYpmkRiLY7Yf7DpZSXncOdjmvoARb3bzH09eaCYIJF3WyAdzMtCJk9PZ ZDTqIzGU2JhjdKqlOwtKt6KSKabEIpaCHZb016gC/wtvyHyKT7KGGE6VjPItnZ7o8D1n 4CjPsPpz/iSr84qJ+DJt7yKBdPZh6twx9hig3j/io8SBSoN/qHVekoOVlclAYsr35ElM btwQ== X-Gm-Message-State: APt69E10t64f7VKRRWgZv1IQBdNyvyrrbUKoh4P22HiC9/m1MyJbfoYt uNEoIjdopBMI6/kMRbbqdvA= X-Google-Smtp-Source: ADUXVKLxqq/Dp9p5cAvrfX+pxF1MI0OoNCjKlAUMWndYjKaIZmmpWJOiLugqVZ8TKjZxaanvyINtEA== X-Received: by 2002:a63:6807:: with SMTP id d7-v6mr1920864pgc.7.1529075473691; Fri, 15 Jun 2018 08:11:13 -0700 (PDT) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id r188-v6sm15208869pgr.78.2018.06.15.08.11.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 08:11:12 -0700 (PDT) From: Tony Li Message-Id: <3E010323-B478-450F-A3ED-3AE5AEE86A30@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D0ACC24E-B042-4AE9-ABC2-E90F90C7EBED" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 15 Jun 2018 08:11:11 -0700 In-Reply-To: Cc: Alexandre Petrescu , "its@ietf.org" To: Nabil Benamar References: <10d242f7-dcc4-ebcb-9501-59f32e723ec8@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Fwd: Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 15:11:17 -0000 --Apple-Mail=_D0ACC24E-B042-4AE9-ABC2-E90F90C7EBED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, please remove that sentence. Further, I suggest replacing the entire paragraph with: =E2=80=9CNeighbor = Discovery (ND) is used over 802.11-OCB.=E2=80=9D Tony > On Jun 15, 2018, at 5:41 AM, Nabil Benamar = wrote: >=20 > Hi Alex, >=20 > I agree on removing this sentence: "The operation of ND over = 802.11-OCB is not specified in this document."=20 >=20 >=20 > Best regards > Nabil Benamar > ------------------- > =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Fri, Jun 15, 2018 at 12:04 PM Alexandre Petrescu = > = wrote: > Hi IPWAVErs, >=20 > An important comment was made on our draft, in the 6man WG. >=20 > The comment is the following: ND on OCB can not be 'different' than ND > on normal links, while being at the same time 'not specified' > And this is what this current text suggests: >=20 > >> The operation of the Neighbor Discovery protocol (ND) over > >> 802.11-OCB links is different than over 802.11 links. In OCB, the > >> link layer > ^^^^^^^^^ > >> does not ensure that all associated members receive all messages,=20= > >> because there is no association operation. The operation of ND > >> over 802.11-OCB is not specified in this document. > [...] > >> The operation of ND over 802.11-OCB is not specified in this > >> document. >=20 > To solve this issue, I propose that we remove the latter phrase. >=20 > Do you disagree? >=20 > Alex >=20 >=20 >=20 >=20 >=20 >=20 > -------- Message transf=C3=A9r=C3=A9 -------- > Sujet : Re: Request for 6man review of > draft-ietf-ipwave-ipv6-over-80211ocb-22 > Date : Thu, 14 Jun 2018 08:50:17 +1200 > De : Brian E Carpenter > > Pour : Suresh Krishnan >, = Lorenzo Colitti > > > Copie =C3=A0 : Alexandre Petrescu >, 6man > >, = draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org = >=20 > I see that there has been no significant change in the -23 version. > The two contradictory statements are still present: > > The operation of the Neighbor Discovery protocol (ND) over = 802.11-OCB > > links is different than over 802.11 links. In OCB, the link layer=20= > > does not ensure that all associated members receive all messages,=20 > > because there is no association operation. The operation of ND over=20= > > 802.11-OCB is not specified in this document. >=20 > ND can't be both "different" and "not specified". >=20 > Also, an IPv6 spec without neighbour discovery is incomplete and seems > likely to be unusable. >=20 > Regards > Brian Carpenter >=20 >=20 >=20 > On 17/05/2018 04:37, Suresh Krishnan wrote: > > Hi Lorenzo, > >=20 > > On May 14, 2018, at 9:41 PM, Lorenzo Colitti > > >> wrote: > >=20 > > On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter > > >> > > wrote: What I understand is that multicast is highly unreliable on > > OCB (as opposed to reasonably reliable on classical 802.11). > >=20 > > Because you not specify how neighbours are discovered, I don't see > > how an actual IPv6 service could be provided. > >=20 > > If that's true then that means this document does not actually > > specify a feasible scheme to implement IPv6 over this network type. > > As such, perhaps the 6man WG should recommend that this document > > should not be published until it either documents a working > > specification or at least clearly and unambiguously documents what > > works and what doesn=E2=80=99t. > >=20 > > Yep. That would be the right thing to do, > >=20 > >=20 > > Suresh, chairs - what's the best way forward here? Would it be a = good > > idea to present this document at the 6man slot in Montreal to = solicit > > input from other participants and see if together we can come up = with > > better text? > >=20 > > I=E2=80=99d rather not wait till the Montreal meeting if we can make = progress > > on this document before then. I will have a discussion with the > > ipwave/6man chairs and the document editor to work out a way forward > >=20 > > Regards Suresh > >=20 >=20 >=20 > _______________________________________________ > 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 --Apple-Mail=_D0ACC24E-B042-4AE9-ABC2-E90F90C7EBED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Yes, please remove that sentence.


Further, I suggest = replacing the entire paragraph with: =E2=80=9CNeighbor Discovery (ND) is = used over 802.11-OCB.=E2=80=9D

Tony


On Jun 15, 2018, at 5:41 AM, Nabil Benamar <benamar73@gmail.com>= wrote:

Hi = Alex,
I = agree on removing this sentence: "The operation of = ND over 802.11-OCB is not = specified in this document." 


Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88







On Fri, Jun 15, 2018 = at 12:04 PM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Hi IPWAVErs,

An important comment was made on our draft, in the 6man WG.
=
The comment is the following: ND on OCB can not be 'different' than = ND
on normal links, while being at the same time 'not specified'
And this is what this current text suggests:

>> The operation of the Neighbor Discovery protocol (ND) over
>> 802.11-OCB links is different than over 802.11 links.  In = OCB, the
>> link layer
                ^^^^^^^^^
>> does not ensure that all associated members receive all = messages,
>> because there is no association operation.  The operation = of ND
>> over 802.11-OCB is not specified in this document.
= [...]
>> The operation of ND over 802.11-OCB is not specified in this
>> document.

To solve this issue, I propose that we remove the latter phrase.

Do you disagree?

Alex






-------- Message transf=C3=A9r=C3=A9 --------
Sujet : Re: Request for 6man review of
draft-ietf-ipwave-ipv6-over-80211ocb-22
Date : Thu, 14 Jun 2018 08:50:17 +1200
De : Brian E Carpenter <brian.e.carpenter@gmail.com>
Pour : Suresh Krishnan <Suresh@kaloom.com>, Lorenzo = Colitti
<lorenzo@google.com>
Copie =C3=A0 : Alexandre Petrescu <alexandre.petrescu@gmail.com>, 6man
<ipv6@ietf.org>, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org

I see that there has been no significant change in the -23 version.
The two contradictory statements are still present:
  >    The operation of the Neighbor Discovery = protocol (ND) over 802.11-OCB
> links is different than over 802.11 links.  In OCB, the link = layer
> does not ensure that all associated members receive all messages, =
> because there is no association operation.  The operation of = ND over
> 802.11-OCB is not specified in this document.

ND can't be both "different" and "not specified".

Also, an IPv6 spec without neighbour discovery is incomplete and = seems
likely to be unusable.

Regards
    Brian Carpenter



On 17/05/2018 04:37, Suresh Krishnan wrote:
> Hi Lorenzo,
>
> On May 14, 2018, at 9:41 PM, Lorenzo Colitti
> <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:
>
> On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter
> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>
> wrote: What I understand is that multicast is highly unreliable = on
> OCB (as opposed to reasonably reliable on classical 802.11).
>
> Because you not specify how neighbours are discovered, I don't = see
> how an actual IPv6 service could be provided.
>
> If that's true then that means this document does not actually
> specify a feasible scheme to implement IPv6 over this network = type.
> As such, perhaps the 6man WG should recommend that this document
> should not be published until it either documents a working
> specification or at least clearly and unambiguously documents = what
> works and what doesn=E2=80=99t.
>
> Yep. That would be the right thing to do,
>
>
> Suresh, chairs - what's the best way forward here? Would it be a = good
> idea to present this document at the 6man slot in Montreal to = solicit
> input from other participants and see if together we can come up = with
> better text?
>
> I=E2=80=99d rather not wait till the Montreal meeting if we can = make progress
> on this document before then. I will have a discussion with the
> ipwave/6man chairs and the document editor to work out a way = forward
>
> Regards Suresh
>


_______________________________________________
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

= --Apple-Mail=_D0ACC24E-B042-4AE9-ABC2-E90F90C7EBED-- From nobody Fri Jun 15 08:57:12 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5894130E29 for ; Fri, 15 Jun 2018 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1jeWDEyYQ5h for ; Fri, 15 Jun 2018 08:57:09 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC85C130E2C for ; Fri, 15 Jun 2018 08:57:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FFv7Q7029284 for ; Fri, 15 Jun 2018 17:57:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 224F82048EB for ; Fri, 15 Jun 2018 17:57:07 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 173DA201031 for ; Fri, 15 Jun 2018 17:57:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FFv6rL001085 for ; Fri, 15 Jun 2018 17:57:07 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <4d0cad79-e4c0-81c4-1955-f930babe540c@gmail.com> Date: Fri, 15 Jun 2018 17:57:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C91A7DEF1D18970A9E1B1B55" Content-Language: fr Archived-At: Subject: [ipwave] IPv6 over OCB draft - nit - name of WG on front page X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 15:57:11 -0000 This is a multi-part message in MIME format. --------------C91A7DEF1D18970A9E1B1B55 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit A person in the ietf@ietf.org email list pointed me in private that the draft should say "IPWAVE Working Group" on its front page, rather than what it says currently: "Network Working Group". I will do the update in XML. Alex --------------C91A7DEF1D18970A9E1B1B55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

A person in the ietf@ietf.org email list pointed me in private that the draft should say "IPWAVE Working Group" on its front page, rather than what it says currently: "Network Working Group".

I will do the update in XML.

Alex

--------------C91A7DEF1D18970A9E1B1B55-- From nobody Fri Jun 15 09:15:17 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8D1131016; Fri, 15 Jun 2018 09:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152907929345.27341.9756050748596080421@ietfa.amsl.com> Date: Fri, 15 Jun 2018 09:14:53 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:15:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-24.txt Pages : 39 Date : 2018-06-15 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 15 09:19:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2635D130E31 for ; Fri, 15 Jun 2018 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQUwEpAJBcQh for ; Fri, 15 Jun 2018 09:19:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33F4130DC0 for ; Fri, 15 Jun 2018 09:19:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9B7B9300A3D for ; Fri, 15 Jun 2018 12:19:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 07S7Y9DDSKKZ for ; Fri, 15 Jun 2018 12:19:35 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id CFFE130044B for ; Fri, 15 Jun 2018 12:19:35 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Jun 2018 12:19:38 -0400 References: To: IP Wireless Access in Vehicular Environments Discussion List In-Reply-To: Message-Id: <30036125-B31A-484C-9042-931F1E5141B0@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [ipwave] DRAFT IPWAVE Agenda for IETF 102 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:19:41 -0000 See the DRAFT agenda below. Please review and comment. If you would = like a speaking slot, please send a request to the IPWVE WG chairs very = soon. Russ =3D =3D =3D =3D =3D =3D 0) Administrativia 1) IPWAVE WG documents a) draft-ietf-ipwave-ipv6-over-80211ocb b) draft-ietf-ipwave-vehicular-networking 2) Additional topics (if time permits) a) please contact the chairs if you want to make a presentation From nobody Fri Jun 15 09:21:50 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75645130F73 for ; Fri, 15 Jun 2018 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JHqTumeyjj5 for ; Fri, 15 Jun 2018 09:21:30 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07AD130FB4 for ; Fri, 15 Jun 2018 09:21:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FGLShL035276 for ; Fri, 15 Jun 2018 18:21:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B29D204CFA for ; Fri, 15 Jun 2018 18:21:28 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3FC91204C70 for ; Fri, 15 Jun 2018 18:21:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FGLRRY008349 for ; Fri, 15 Jun 2018 18:21:28 +0200 References: <152907929383.27341.4373701073052357831.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <152907929383.27341.4373701073052357831.idtracker@ietfa.amsl.com> Message-ID: <6154a21f-f11f-9ff5-ff4c-89f8edeeb6cf@gmail.com> Date: Fri, 15 Jun 2018 18:21:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152907929383.27341.4373701073052357831.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------12AD760F87891E2F08531FD6" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-24.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:21:46 -0000 This is a multi-part message in MIME format. --------------12AD760F87891E2F08531FD6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I submitted a new version of the IPv6 over OCB draft - the 24th. The goal of this version is to address the comments of 6man WG, and a few nits in xml. This is the changelog from 23 to 24: o removed a sentence about ND problem, and said rather that ND is used on OCB. o put "IPWAVE Working Group" on the front page (thanks J. Reschke) o fixed a nit in the xml about '.txt' to ease the submission process (thanks R. Housley) Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-24.txt Date : Fri, 15 Jun 2018 09:14:53 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-24.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 24 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-06-15 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-24.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. 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 --------------12AD760F87891E2F08531FD6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I submitted a new version of the IPv6 over OCB draft - the 24th.

The goal of this version is to address the comments of 6man WG, and a few nits in xml.

This is the changelog from 23 to 24:

o removed a sentence about ND problem, and said rather that ND is used on OCB.
o put "IPWAVE Working Group" on the front page (thanks J. Reschke)
o fixed a nit in the xml about '.txt' to ease the submission process (thanks R. Housley)

Alex


-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-24.txt
Date : Fri, 15 Jun 2018 09:14:53 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr>


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-24.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	24
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-06-15
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-24.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

--------------12AD760F87891E2F08531FD6-- From nobody Fri Jun 15 09:39:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEC7130DFB for ; Fri, 15 Jun 2018 09:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDYg6AoqsL27 for ; Fri, 15 Jun 2018 09:39:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9E112F18C for ; Fri, 15 Jun 2018 09:39:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FGdg7Y022583 for ; Fri, 15 Jun 2018 18:39:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3658F204C1C for ; Fri, 15 Jun 2018 18:39:42 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2C294204D95 for ; Fri, 15 Jun 2018 18:39:42 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FGdftx013538 for ; Fri, 15 Jun 2018 18:39:42 +0200 To: its@ietf.org References: <3447130C-8EFB-41CE-B827-410A5B05ABFD@gmail.com> <8BF5DA62-8F05-40DD-B547-E1BE5096DAC5@vigilsec.com> <62692696-0887-4FD2-B2EF-BA3B804D1E62@gmail.com> <067fef0a-32aa-f13f-e2ef-ebe7839ccc2f@gmail.com> <3B659E83-C181-46DE-9A35-04242E214E8E@gmail.com> <008b4204-3488-ddbf-f561-19e22529837f@gmail.com> <4b20a8a9-4eb1-30b8-709f-a9073ea607e7@gmail.com> <7ED43CE6-3855-40F6-9BB6-DBC4E8824DAA@tony.li> <3704546f-bf9a-2f15-5a50-5afc92af5547@gmail.com> <2B1FAA46-15D1-40D7-8A8D-90CFDABA8198@tony.li> <701f0d97c27249cb8ed282d9f5fd9976@tno.nl> <001701d40448$0c2e14d0$248a3e70$@gmail.com> <003701d404a2$532c1d00$f9845700$@gmail.com> <1528_1529071908_5B23C923_1528_16311_1_4886.1529071683@localhost> From: Alexandre Petrescu Message-ID: Date: Fri, 15 Jun 2018 18:39:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1528_1529071908_5B23C923_1528_16311_1_4886.1529071683@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: multicast in convoy X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:39:46 -0000 Le 15/06/2018 à 16:08, Michael Richardson a écrit : [...] > ----------------MESSAGE ORGINAL ci-dessous------------------ > > > Also, ROLL's RPL (RFC6550), and it's multicast *MPL* RFC7731. Are there cheap open source RPL implementations available for i386 (not Contiki and friends). > The trickle mechanism is often not associated with fast changing networks. > > To the extent that changes can be detected, trickle can operate as fast > (or as slow, reducing power or bandwidth used) as needed. > > OLSRv2 is also an interesting choice. Is there cheap open source implementation available? > > RFC6550 has an assymmetric (public key) authentication/authorization mode > that has not been interesting in LLNs, but may be very much appropriate > in this situation. The vehicular network for convoy is not an LLN. It has very strong Ethernet links inside each car, and some little variation outside the car. > s4 s5 > IP-OBU1 --- IP-OBU2 --- IP-OBU3 sx: distinct IP subnet x > | | | PCx: Autonomous Drv. PC w/ RTMaps > |s1 |s2 |s3 s4, s5: IPv6 over OCB, in LL mode > | | | s1, s2, s3: Ethernet > PC1 PC2 PC3 Alex > > François Simon wrote: > > “That would be called a routing protocol.” Below is a sample of the list of > > routing protocols that are developed for ad-hoc networks (e.g.; V2V). > > Extracted from “MOBILE AD-HOC DIGITAL COMMUNICATIONS NETWORK - OVERVIEW” - > > 2007 > > > “Routing Protocols for Ad-hoc Networks > > > Here is where the ‘madness’ starts. Since ad-hoc is such a complex network > > infrastructure and also has a high profile in the Government (i.e. DoD) as > > well as in the commercial sectors, every standard, research, and academia > > organizations have their own idea and solution for a wireless ad-hoc network > > routing protocol (in some cases application dependent). There are no less > > than 130 routing protocols, and growing, related to ad-hoc wireless network. > > The routing protocol is the key factor for Ad Hoc Network. It decides > > directly the performance of the whole network: > > > Table-Driven Routing Protocols > > > * Destination-Sequenced Distance-Vector (DSDV) > > > > * Clusterhead Gateway Switch Routing (CGSR) > > > > * The Wireless Routing Protocol (WRP) > > > > * More.... > > > > > Source-Initiated On-Demand Routing Protocols > > > * Ad Hoc On-Demand Distance Vector Routing (AODV) > > > > * Dynamic Source Routing (DSR) > > > > * Temporally Ordered Routing Algorithm (TORA) > > > > * Associativity-Based Routing (ABR) > > > > * More……. > > > > > Location Information Based (Based) Routing Protocols > > > * Location Aid Routing (LAR) > > > > * Grid's Location Service Routing (GLS) > > > > * More....” > > > > > Fygs > > > From: François Simon > > Sent: Thursday, June 14, 2018 9:28 PM > > To: fygsimon@gmail.com > > Subject: FW: [ipwave] multicast in convoy > > > From: its On Behalf Of Velt, R. (Ronald) in 't > > Sent: Wednesday, June 13, 2018 12:23 PM > > To: tony.li@tony.li; Alexandre Petrescu > > Cc: its@ietf.org > > Subject: Re: [ipwave] multicast in convoy > > > (below) > > > From: its [mailto:its-bounces@ietf.org] On Behalf Of tony.li@tony.li > > Sent: woensdag 13 juni 2018 16:13 > > To: Alexandre Petrescu > > Cc: its@ietf.org > > Subject: Re: [ipwave] multicast in convoy > > > On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu > > wrote: > > > > > > n order to work with three cars, we must find a way for one IP-OBU to > > read its own routing table, realize that a new entry is present and then > > send it on an interface that is not the interface on which that prefix > > arrived. > > > That would propagate it. > > > If there is another means to propagate, then I am listening. > > > > That would be called a routing protocol. > > > :-] > > > I would suggest OSPF (or, if you’re very brave, IS-IS). > > > I would suggest OLSRv2 (RFC 7181 and friends), an IETF Standards Track > > protocol that works even if your IP-OBU has only one radio interface. > > Implementation here: > > > https://github.com/OLSR/OONF > > > That’s for unicast. MANET multicast is a tad more complicated.. SMF (RFC 6621, > > Experimental) is a first attempt. (Implementation here: > > https://www.nrl.navy.mil/itd/ncs/products/smf ) > > > Ronald > > > Tony > > > This message may contain information that is not intended for you. If you are > > not the addressee or if this message was sent to you by mistake, you are > > requested to inform the sender and delete the message. TNO accepts no > > liability for the content of this e-mail, for the manner in which you use it > > and for damage of any kind resulting from the risks inherent to the > > electronic transmission of messages. > > > > > ---------------------------------------------------- > > Alternatives: > > > ---------------------------------------------------- > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Jun 15 13:46:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADD8130E44; Fri, 15 Jun 2018 13:46:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjdmom9px7Zt; Fri, 15 Jun 2018 13:46:23 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 F25C8126CB6; Fri, 15 Jun 2018 13:46:22 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id a22-v6so5383156pfo.12; Fri, 15 Jun 2018 13:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=354MwsYs9BgDH69tuFV9f6zbenF5NKZNaf7xWj/EPlI=; b=sc87oCiWjM3vSE2r9NaRb6clw32ipL1pI8hnGMFxY9I+m2s9O+no8d05fw94+IiZqw lrC1TjQXvmlqGfBZZUGyOquiuV5uGYCn7D5NiECE9/Y4FNlfjVQdazMxXViu1J+eTLwF ntuUdJe3cQDgJoFj5zR6A77goDG5ysqniQbxmDajm/p0hpcaKu9qUN+J6Y3iBcdF4zG0 hviJEz/Wkib9E1QWfMr8atY5lp/InDXJOOUmnqRa3R8Vn6oa0RRYjqmgAUoTCj5O/7/Q HUjReLN9r6k7Koja22ClDI33zXVWsfcN45XUVsZzcnPDQKQH6xTJ+EwqbHkRWOiOLK08 S5KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=354MwsYs9BgDH69tuFV9f6zbenF5NKZNaf7xWj/EPlI=; b=k5GrdcoY0jekH0Xj2P+HvMZJnhTrXJTm0OhddCRD5cN5GQnZFGLOnZKKrKYCRuuqxf XmfkGjPwceX2C5pqzku7YRd/IjZ6S1H2YqzqQ8kFOZSGqCxQndFD+5xXJkIT1G2sHdeY wSRTsZHkfuYcX7+u4w1GBbjcfaVwt+nf79t0FIT+1XMuOlyOhdunCdHzJ1gryCJcL5rd AbxV6RS/ly20G6PPLLtc9FUR8wg1A298Rl0QV9tufXRcm6t5iUbiva81eVtce4kb6na9 OShjdfJE32q5n7ct0mjGnYLrI9aqDvWMpNkt4wR8GZBRmr+WtBHta61qR9qp4JEWGjU4 9Xyg== X-Gm-Message-State: APt69E2oC3swEj/f8hxQkKuoVIkPGhqa1HL3SXgft3tlftsiuR4xzNq5 1mt7IUWsSGPdsdLsx2d6OsdyYQ== X-Google-Smtp-Source: ADUXVKITJxSuYtZ76ehcX9dZyuirQLuTPY0Y1MSI7hFbPSUG9b7+KbxZmSsSE7PUJtUrnsXE2mpYQQ== X-Received: by 2002:a65:56c1:: with SMTP id w1-v6mr3002728pgs.227.1529095582246; Fri, 15 Jun 2018 13:46:22 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z192-v6sm10595893pgz.6.2018.06.15.13.46.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 13:46:21 -0700 (PDT) To: 6man Cc: its@ietf.org References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> Date: Sat, 16 Jun 2018 08:46:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152907929345.27341.9756050748596080421@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 20:46:26 -0000 Hi, > The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB > links is different than over 802.11 links. In OCB, the link layer > does not ensure that all associated members receive all messages, > because there is no association operation. Neighbor Discovery (ND) > is used over 802.11-OCB. It's different and not all members receive all multicasts? Since ND assumes that nodes receive multicasts, *how* is it used? Since there is no reference, does ND actually mean RFC4861? If not, where is the appropriate form of ND (that does not rely on multicasts) defined? > 4.5. Stateless Autoconfiguration > > The Interface Identifier for an 802.11-OCB interface is formed using > the same rules as the Interface Identifier for an Ethernet interface; > this is described in section 4 of [RFC2464]. No changes are needed, > but some care must be taken when considering the use of the Stateless > Address Auto-Configuration procedure. RFC2464 is no longer the recommended method of IID formation. Also, since there is no reference to RFC4862, where is the appropriate form of SLAAC (that does not rely on multicasts) defined? Regards Brian On 16/06/2018 04:14, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. > > Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) > Authors : Alexandre Petrescu > Nabil Benamar > Jerome Haerri > Jong-Hyouk Lee > Thierry Ernst > Filename : draft-ietf-ipwave-ipv6-over-80211ocb-24.txt > Pages : 39 > Date : 2018-06-15 > > Abstract: > In order to transmit IPv6 packets on IEEE 802.11 networks running > outside the context of a basic service set (OCB, earlier "802.11p") > there is a need to define a few parameters such as the supported > Maximum Transmission Unit size on the 802.11-OCB link, the header > format preceding the IPv6 header, the Type value within it, and > others. This document describes these parameters for IPv6 and IEEE > 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB > similarly to other known 802.11 and Ethernet layers - by using an > Ethernet Adaptation Layer. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24 > > > 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 Fri Jun 15 15:17:09 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9A3130E6D; Fri, 15 Jun 2018 15:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiLAc5yhv_rs; Fri, 15 Jun 2018 15:17:05 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010: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 984E7130E27; Fri, 15 Jun 2018 15:17:04 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id n3-v6so16655822lfe.12; Fri, 15 Jun 2018 15:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UK1A0O+zUiKp7U5ozcKId1ne6+jeF+L5YCn1ANky+eM=; b=pB8bwftZUnMYJd3ubwbXKYBCp9Qw/5ukpSJyy0d2knj3c41QEb7ORliZPUZ/a8vwwN ZPScodnvUcogGxkacDQJtrCcQArkOfTknZ6X3yQe8zQn1TIRQyhzBtFAS5V8mGSAzA7N bxHKrcJcjNSgt++q8z7mbST5qapQbPXIxsOgXqr6A3foWEq9E2MJb5W2SfWcw6gF/Dzz tYYF1EjU8oXAoQPLrVanIiQIy0ky5u82MQPQIygpj2eCzWufJydEyhKR/nyAf9D7EkI9 j/5LxHVTt5gzAtNMe21eZzww54S9s5ZRlvvrVOdcY9KpLuRSGfdeRS7eIeIS66Ec1psy 3gvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UK1A0O+zUiKp7U5ozcKId1ne6+jeF+L5YCn1ANky+eM=; b=N1clycvNkreChYGPyz/PFfbZZVev5UG2MsMSjx8btK6s+vROJSD9e7n8wwsRKNF2Wp uSKds497PHtZUGVXxYmc98aZgbsdrl2JqkMxZLfSER2KrVaVvwX3HU/OE/Ky/f8z9YBR Z/AYTVkTDIKQP0Oq2F6h5pG6xbCkNvKppVd/eaeQC26Gi3jLza6UPjETxVzbujpqYM8H r3/gqJQPl8tMiP6ilhj0KkOpjdwrssHEXxsSbWse+8i3XDCLdvf0rHEr1echXakQgeAO /BWwB2Qz1RBTcEAOzD8tMGTx/9PjJ9TPORqc0HdsYoVju0EvoKEpHHVGYE8n+z9nrEOu zPXQ== X-Gm-Message-State: APt69E3IxaRYQYtu/X4XjknTK5evMz5CNc1INWJ9lKVpyVn8eIunaWJc mXVTu4VxFsiLTToQn9+SG4gIrvxK7xsKbXSYUHs= X-Google-Smtp-Source: ADUXVKLymI2AtKgb7K7W7KAvcSiDEezblVscOsZKixeRQVEw01GwuzEV2F4ioPFpmamFQ6dkCYbIHtzod4nDsDyP5jw= X-Received: by 2002:a19:12c7:: with SMTP id 68-v6mr2336691lfs.10.1529101022766; Fri, 15 Jun 2018 15:17:02 -0700 (PDT) MIME-Version: 1.0 References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> In-Reply-To: <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> From: Nabil Benamar Date: Fri, 15 Jun 2018 22:16:50 +0000 Message-ID: To: Brian E Carpenter Cc: "ipv6@ietf.org" , "its@ietf.org" Content-Type: multipart/alternative; boundary="00000000000049acd5056eb593b4" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 22:17:08 -0000 --00000000000049acd5056eb593b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brian, Which RFC is now the recommended method of IID formation? Are you suggesting to use rfc8064 (still a proposed standard) instead of RFC2464? Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 On Fri, Jun 15, 2018 at 8:46 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > > The operation of the Neighbor Discovery protocol (ND) over 802.11-OC= B > > links is different than over 802.11 links. In OCB, the link layer > > does not ensure that all associated members receive all messages, > > because there is no association operation. Neighbor Discovery (ND) > > is used over 802.11-OCB. > > It's different and not all members receive all multicasts? Since ND > assumes that nodes receive multicasts, *how* is it used? Since there > is no reference, does ND actually mean RFC4861? If not, where is the > appropriate form of ND (that does not rely on multicasts) defined? > > > 4.5. Stateless Autoconfiguration > > > > The Interface Identifier for an 802.11-OCB interface is formed using > > the same rules as the Interface Identifier for an Ethernet interface= ; > > this is described in section 4 of [RFC2464]. No changes are needed, > > but some care must be taken when considering the use of the Stateles= s > > Address Auto-Configuration procedure. > > RFC2464 is no longer the recommended method of IID formation. Also, > since there is no reference to RFC4862, where is the appropriate form > of SLAAC (that does not rely on multicasts) defined? > > Regards > Brian > > On 16/06/2018 04:14, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IP Wireless Access in Vehicular > Environments WG of the IETF. > > > > Title : Transmission of IPv6 Packets over IEEE 802.11 > Networks operating in mode Outside the Context of a Basic Service Set > (IPv6-over-80211-OCB) > > Authors : Alexandre Petrescu > > Nabil Benamar > > Jerome Haerri > > Jong-Hyouk Lee > > Thierry Ernst > > Filename : draft-ietf-ipwave-ipv6-over-80211ocb-24.txt > > Pages : 39 > > Date : 2018-06-15 > > > > Abstract: > > In order to transmit IPv6 packets on IEEE 802.11 networks running > > outside the context of a basic service set (OCB, earlier "802.11p") > > there is a need to define a few parameters such as the supported > > Maximum Transmission Unit size on the 802.11-OCB link, the header > > format preceding the IPv6 header, the Type value within it, and > > others. This document describes these parameters for IPv6 and IEEE > > 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB > > similarly to other known 802.11 and Ethernet layers - by using an > > Ethernet Adaptation Layer. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211oc= b-24 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-= 24 > > > > > > 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 > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --00000000000049acd5056eb593b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

Which RFC i= s now the recommended method of IID formation? Are you suggesting to use=C2= =A0rfc8064 (still a proposed standard) instead of RFC2464?

Best regards
Nabil Benamar
--= -----------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88
=







On Fri, Jun 15, 2018 at 8:46 PM Brian E Carpenter <brian.e.carpenter@gmail.com>= wrote:
Hi,

>=C2=A0 =C2=A0 The operation of the Neighbor Discovery protocol (ND) ove= r 802.11-OCB
>=C2=A0 =C2=A0 links is different than over 802.11 links.=C2=A0 In OCB, = the link layer
>=C2=A0 =C2=A0 does not ensure that all associated members receive all m= essages,
>=C2=A0 =C2=A0 because there is no association operation.=C2=A0 Neighbor= Discovery (ND)
>=C2=A0 =C2=A0 is used over 802.11-OCB.

It's different and not all members receive all multicasts? Since ND
assumes that nodes receive multicasts, *how* is it used? Since there
is no reference, does ND actually mean RFC4861? If not, where is the
appropriate form of ND (that does not rely on multicasts) defined?

> 4.5.=C2=A0 Stateless Autoconfiguration
>
>=C2=A0 =C2=A0 The Interface Identifier for an 802.11-OCB interface is f= ormed using
>=C2=A0 =C2=A0 the same rules as the Interface Identifier for an Etherne= t interface;
>=C2=A0 =C2=A0 this is described in section 4 of [RFC2464].=C2=A0 No cha= nges are needed,
>=C2=A0 =C2=A0 but some care must be taken when considering the use of t= he Stateless
>=C2=A0 =C2=A0 Address Auto-Configuration procedure.

RFC2464 is no longer the recommended method of IID formation. Also,
since there is no reference to RFC4862, where is the appropriate form
of SLAAC (that does not rely on multicasts) defined?

Regards
=C2=A0 =C2=A0Brian

On 16/06/2018 04:14, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IP Wireless Access in Vehicular Envir= onments WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Transmission of IPv6 Packets over IEEE 802.11 Networks operatin= g in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Alexandre Petrescu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Nabil Benamar
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jerome Haerri
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jong-Hyouk Lee
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Thierry Ernst
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-ipwave-ipv6-over-80211ocb-24.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 39
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-06-15
>
> Abstract:
>=C2=A0 =C2=A0 In order to transmit IPv6 packets on IEEE 802.11 networks= running
>=C2=A0 =C2=A0 outside the context of a basic service set (OCB, earlier = "802.11p")
>=C2=A0 =C2=A0 there is a need to define a few parameters such as the su= pported
>=C2=A0 =C2=A0 Maximum Transmission Unit size on the 802.11-OCB link, th= e header
>=C2=A0 =C2=A0 format preceding the IPv6 header, the Type value within i= t, and
>=C2=A0 =C2=A0 others.=C2=A0 This document describes these parameters fo= r IPv6 and IEEE
>=C2=A0 =C2=A0 802.11-OCB networks; it portrays the layering of IPv6 on = 802.11-OCB
>=C2=A0 =C2=A0 similarly to other known 802.11 and Ethernet layers - by = using an
>=C2=A0 =C2=A0 Ethernet Adaptation Layer.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.= org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/= draft-ietf-ipwave-ipv6-over-80211ocb-24
> https://datatracke= r.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-24
>
> A diff from the previous version is available at:
> https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-24
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--00000000000049acd5056eb593b4-- From nobody Fri Jun 15 16:07:59 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59C6130E5A; Fri, 15 Jun 2018 16:07:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aul1G0E6gk9; Fri, 15 Jun 2018 16:07:48 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667AA12D949; Fri, 15 Jun 2018 16:07:48 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id e11-v6so5038264pgq.0; Fri, 15 Jun 2018 16:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ne0DFUo+6dxlGU7yhzqiw3G0u76fP0DvAOoLY4VWUxU=; b=UvI6LPzvB4UxS00Mq2yw95ppQtdrscWEJDfSrdMu7XjAW3VTeggBidaI7mj0eYIbgn VRLAaeAiAU8ByIeUjp2dqsAHFchkzdxYl8gGO3vXNHvLvUbWnAJL/0QnHkYPoEi/6gXF BY3Pranx/XnY3F4u8Utv9Ohg6Eyyc/OsNQKLHRaDaaNO9w5p7bO+lWD8Y0l5vjhF7jnK QPuQlpPfshLum/iz4i8zbFb+3hG0BIriIEU7BwdsX97zb98YkiIW4hv7SE7klzlFLWvP WektYjxJUslXJdO0xZCoWHSeMypGENmrOLvmP7x95UwKv4c7LsCbnAykHhdJQXUa24rN YIVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ne0DFUo+6dxlGU7yhzqiw3G0u76fP0DvAOoLY4VWUxU=; b=s2wev0aTcflub4zi++bxhoz6NzGFPu0viznj3JTvlLZ39jDVynMgHf5znRISX54kkH mJnvTpk6+teaRXoiYL7rtnVuhSFnboIDoSeXddUj0jpyNhzG7anoX17tKk7FglN8dY0y I/6c7zlLoDKasXcS3AAFebG2+p9PhSSiDiylPb01JMpG84DaO2S1mrLc2y0SOSro4Ybo 76AqaSmh9seKogtUb5inggpt0bdrYOJXsfgQaWvsY66S7MvkKgIe3dfCw3KqgL2nt0dx gPV45HpxjSZgWjKUlBVIxMM6edEIau/OWxtnSuHgTl5UiQ5WqNQnk5TaOVGAZ65TOZme wnPg== X-Gm-Message-State: APt69E11teGzfJQ0Pp8H8x+0CTZg6NfpaYiAqdLUydaTFinawbJ6mfRx mPwHdxKTiW4k69qpII2hcr0NIQ== X-Google-Smtp-Source: ADUXVKJaMjl8iDrjHOwu4VdRgyBjR8B1bCj36gGXhWUaoMzRAKEhWj1hPM1hNXBekROgoJlb0m9w9A== X-Received: by 2002:a63:648:: with SMTP id 69-v6mr3318148pgg.205.1529104067582; Fri, 15 Jun 2018 16:07:47 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id t23-v6sm17858141pfa.86.2018.06.15.16.07.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 16:07:46 -0700 (PDT) To: Nabil Benamar Cc: "ipv6@ietf.org" , "its@ietf.org" References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> From: Brian E Carpenter Message-ID: <5e99d50a-5b67-4b45-a056-172cfaffdcdb@gmail.com> Date: Sat, 16 Jun 2018 11:07:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 23:07:52 -0000 On 16/06/2018 10:16, Nabil Benamar wrote: > Hi Brian, >=20 > Which RFC is now the recommended method of IID formation? Are you > suggesting to use rfc8064 (still a proposed standard) instead of RFC246= 4? Of course. It updates RFC2464 and many other IPv6-over-foo standards. Brian >=20 >=20 > Best regards > Nabil Benamar > ------------------- > =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Fri, Jun 15, 2018 at 8:46 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> Hi, >> >>> The operation of the Neighbor Discovery protocol (ND) over 802.11-= OCB >>> links is different than over 802.11 links. In OCB, the link layer= >>> does not ensure that all associated members receive all messages, >>> because there is no association operation. Neighbor Discovery (ND= ) >>> is used over 802.11-OCB. >> >> It's different and not all members receive all multicasts? Since ND >> assumes that nodes receive multicasts, *how* is it used? Since there >> is no reference, does ND actually mean RFC4861? If not, where is the >> appropriate form of ND (that does not rely on multicasts) defined? >> >>> 4.5. Stateless Autoconfiguration >>> >>> The Interface Identifier for an 802.11-OCB interface is formed usi= ng >>> the same rules as the Interface Identifier for an Ethernet interfa= ce; >>> this is described in section 4 of [RFC2464]. No changes are neede= d, >>> but some care must be taken when considering the use of the Statel= ess >>> Address Auto-Configuration procedure. >> >> RFC2464 is no longer the recommended method of IID formation. Also, >> since there is no reference to RFC4862, where is the appropriate form >> of SLAAC (that does not rely on multicasts) defined? >> >> Regards >> Brian >> >> On 16/06/2018 04:14, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the IP Wireless Access in Vehicular >> Environments WG of the IETF. >>> >>> Title : Transmission of IPv6 Packets over IEEE 802.= 11 >> Networks operating in mode Outside the Context of a Basic Service Set >> (IPv6-over-80211-OCB) >>> Authors : Alexandre Petrescu >>> Nabil Benamar >>> Jerome Haerri >>> Jong-Hyouk Lee >>> Thierry Ernst >>> Filename : draft-ietf-ipwave-ipv6-over-80211ocb-24.txt >>> Pages : 39 >>> Date : 2018-06-15 >>> >>> Abstract: >>> In order to transmit IPv6 packets on IEEE 802.11 networks running >>> outside the context of a basic service set (OCB, earlier "802.11p"= ) >>> there is a need to define a few parameters such as the supported >>> Maximum Transmission Unit size on the 802.11-OCB link, the header >>> format preceding the IPv6 header, the Type value within it, and >>> others. This document describes these parameters for IPv6 and IEE= E >>> 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OC= B >>> similarly to other known 802.11 and Ethernet layers - by using an >>> Ethernet Adaptation Layer. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb= / >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 >>> >> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-8021= 1ocb-24 >>> >>> A diff from the previous version is available at: >>> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211o= cb-24 >>> >>> >>> 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 >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >=20 From nobody Sat Jun 16 02:42:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76FF130FF1; Sat, 16 Jun 2018 02:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt0c06KU1PRz; Sat, 16 Jun 2018 02:42:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B19130FEE; Sat, 16 Jun 2018 02:42:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5G9gZoD170499; Sat, 16 Jun 2018 11:42:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8BC7A200F05; Sat, 16 Jun 2018 11:42:35 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7B2E8200C4A; Sat, 16 Jun 2018 11:42:35 +0200 (CEST) Received: from [132.166.84.70] ([132.166.84.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5G9gYWS030361; Sat, 16 Jun 2018 11:42:34 +0200 To: Brian E Carpenter , 6man Cc: its@ietf.org References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> From: Alexandre Petrescu Message-ID: <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> Date: Sat, 16 Jun 2018 11:42:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 09:42:41 -0000 Brian, Thank you very much for the emessage. I agree with you we could clarify. Le 15/06/2018 à 22:46, Brian E Carpenter a écrit : > Hi, > >> The operation of the Neighbor Discovery protocol (ND) over >> 802.11-OCB links is different than over 802.11 links. In OCB, the >> link layer does not ensure that all associated members receive all >> messages, because there is no association operation. Neighbor >> Discovery (ND) is used over 802.11-OCB. > > It's different and not all members receive all multicasts? Since ND > assumes that nodes receive multicasts, *how* is it used? Since there > is no reference, does ND actually mean RFC4861? If not, where is the > appropriate form of ND (that does not rely on multicasts) defined? ND assumes that IPv6 multicast addresses are implemented, but does not assume that nodes always receive multicasts. ND is more like UDP rather than like TCP. ND has this NUD procedure when something may go wrong. ND implementations often send 2 or 3 redundant messages of same content, just to be sure. The fact that the link layer does not ensure that all nodes receive multicasts is not a problem for ND. In WiFi too some times packets are lost, despite being in mode 'associated', yet ND works ok there too. I propose this change: OLD: > The operation of the Neighbor Discovery protocol (ND) over > 802.11-OCB links is different than over 802.11 links. In OCB, the > link layer does not ensure that all associated members receive all > messages, because there is no association operation. Neighbor > Discovery (ND) is used over 802.11-OCB. NEW: > The operation of the Neighbor Discovery protocol (ND) over > 802.11-OCB links is similar as over 802.11 links. In OCB, even if > the link layer does not ensure that all associated members receive > all messages, because there is no association operation, Neighbor > Discovery (ND) is used over 802.11-OCB. Do you disagree? Alex From nobody Sat Jun 16 02:43:33 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB7B131001; Sat, 16 Jun 2018 02:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_eRcmxVmFHE; Sat, 16 Jun 2018 02:43:15 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96814131069; Sat, 16 Jun 2018 02:43:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5G9hDi9041487; Sat, 16 Jun 2018 11:43:13 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B7F16200F05; Sat, 16 Jun 2018 11:43:13 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A7F25200F04; Sat, 16 Jun 2018 11:43:13 +0200 (CEST) Received: from [132.166.84.70] ([132.166.84.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5G9hCQX030430; Sat, 16 Jun 2018 11:43:12 +0200 To: Brian E Carpenter , 6man Cc: its@ietf.org References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> From: Alexandre Petrescu Message-ID: <8ae0e29d-6767-b430-00a5-74371405ef6f@gmail.com> Date: Sat, 16 Jun 2018 11:43:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 09:43:27 -0000 Le 15/06/2018 à 22:46, Brian E Carpenter a écrit : [...] > >> 4.5. Stateless Autoconfiguration >> >> The Interface Identifier for an 802.11-OCB interface is formed >> using the same rules as the Interface Identifier for an Ethernet >> interface; this is described in section 4 of [RFC2464]. No >> changes are needed, but some care must be taken when considering >> the use of the Stateless Address Auto-Configuration procedure. > > RFC2464 is no longer the recommended method of IID formation. What is now the recommended method of IID formation? Do you think of RFC8064 "Recommendation of Stable IPv6 Interface Identifiers"? (as an aside, we do refer to RFC8064 in section 4.3 "Link-Local Addresses", conditioned by a 'need'). > Also, since there is no reference to RFC4862, where is the > appropriate form of SLAAC (that does not rely on multicasts) > defined? If we see what is the recommended method of IID formation that you mean, then I will quickly propose text and that text will refer to RFC4862. (as an aside, yes, it seems there to be an error: lack of ref to rfc4862 "slaac"; or maybe it is not an error, thinking of places where I use IPv6-over-OCB between cars and rfc4862 is not used). Alex > Regards Brian > > On 16/06/2018 04:14, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IP Wireless Access >> in Vehicular Environments WG of the IETF. >> >> Title : Transmission of IPv6 Packets over IEEE 802.11 >> Networks operating in mode Outside the Context of a Basic Service >> Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu >> Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : >> draft-ietf-ipwave-ipv6-over-80211ocb-24.txt Pages : 39 >> Date : 2018-06-15 >> >> Abstract: In order to transmit IPv6 packets on IEEE 802.11 >> networks running outside the context of a basic service set (OCB, >> earlier "802.11p") there is a need to define a few parameters such >> as the supported Maximum Transmission Unit size on the 802.11-OCB >> link, the header format preceding the IPv6 header, the Type value >> within it, and others. This document describes these parameters >> for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of >> IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet >> layers - by using an Ethernet Adaptation Layer. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ >> >> >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 >> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24 >> >> >> >> >> 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 >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Sat Jun 16 02:55:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E710131004; Sat, 16 Jun 2018 02:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24oXjz15wwks; Sat, 16 Jun 2018 02:55:11 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D1A131001; Sat, 16 Jun 2018 02:55:11 -0700 (PDT) Received: from [192.168.10.187] (145.51-175-104.customer.lyse.net [51.175.104.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 108BB2D51E7; Sat, 16 Jun 2018 09:55:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15F79) In-Reply-To: <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> Date: Sat, 16 Jun 2018 11:55:04 +0200 Cc: Brian E Carpenter , 6man , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> To: Alexandre Petrescu Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 09:55:13 -0000 > On 16 Jun 2018, at 11:42, Alexandre Petrescu wrote: >=20 > ND assumes that IPv6 multicast addresses are implemented, but does not > assume that nodes always receive multicasts. ND is more like UDP rather t= han like TCP. ND has this NUD procedure when something may go wrong. ND imp= lementations often send 2 or 3 redundant messages of same content, > just to be sure. >=20 > The fact that the link layer does not ensure that all nodes receive > multicasts is not a problem for ND. In WiFi too some times packets are lo= st, despite being in mode 'associated', yet ND works ok there too. And DAD? Ole= From nobody Sat Jun 16 03:07:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF74130FFB; Sat, 16 Jun 2018 03:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPGPNc3wYv9r; Sat, 16 Jun 2018 03:07:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7741130E07; Sat, 16 Jun 2018 03:07:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5GA7OK8174185; Sat, 16 Jun 2018 12:07:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4F808201515; Sat, 16 Jun 2018 12:07:24 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3D73E200DAF; Sat, 16 Jun 2018 12:07:24 +0200 (CEST) Received: from [132.166.84.70] ([132.166.84.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5GA7MVr001459; Sat, 16 Jun 2018 12:07:23 +0200 To: Ole Troan Cc: Brian E Carpenter , 6man , its@ietf.org References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> From: Alexandre Petrescu Message-ID: Date: Sat, 16 Jun 2018 12:07:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 10:07:41 -0000 Le 16/06/2018 à 11:55, Ole Troan a écrit : > > >> On 16 Jun 2018, at 11:42, Alexandre Petrescu wrote: >> >> ND assumes that IPv6 multicast addresses are implemented, but does not >> assume that nodes always receive multicasts. ND is more like UDP rather than like TCP. ND has this NUD procedure when something may go wrong. ND implementations often send 2 or 3 redundant messages of same content, >> just to be sure. >> >> The fact that the link layer does not ensure that all nodes receive >> multicasts is not a problem for ND. In WiFi too some times packets are lost, despite being in mode 'associated', yet ND works ok there too. > > And DAD? Yes, Duplicate Address Detection is a procedure part of ND. DAD works OCB as it works on WiFi. Alex > > Ole > From nobody Sat Jun 16 03:08:49 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9777513104F; Sat, 16 Jun 2018 03:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGDIZ-cF0BWb; Sat, 16 Jun 2018 03:08:30 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 85B0C131011; Sat, 16 Jun 2018 03:08:30 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id x13-v6so2609945lff.10; Sat, 16 Jun 2018 03:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h0zM9v5UGvmHjbWlauYbR+maeYFTyrQO/oC17oqWJEg=; b=qx6/kooqqfxUmwfIzTL4QdaZY+kdgtGxl2Fa9wsZaiBZABty5eQxGn046DWNdANEmp 9kgB7iZMt53ZL6W/OOJP8SGguTR9llELIzXRjYiv24zxniHG0hqYj5f15Peqi03bgjt9 ErQ4CoEyjiM4qFf8biqSDiVYXwooMH7WQRAaiieIcWKrQPECxuiG8/D/N43+BDJUNizO 24R7Epat+5OKUs38SAmjYCPTfKIZA2DphHWqBcHxdeAizrgF0//uPzFHAfvEJ36kCvpM gflQmypB+q6xDHKAYR8vgI+OblA6Vtl2sSHU2TcmChHBhSL8wf2tIqMTWcAsmSp5TSh8 THNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h0zM9v5UGvmHjbWlauYbR+maeYFTyrQO/oC17oqWJEg=; b=R2Qz8bFWRlfHUdAt6gBCWXtIMd1zDPm1GKFegLBtV946F300nus3cG2oGL/vYbaFHY NEFM1ty/jMOxvc7qtn/UiORGBc6f+4yRQcr45wqPCXA5vZbIxu/9eLgqIYGOvRycCL8g JHFTg6TzLdAzUX452WLmzi6mJUIPt13vslBlGDcn6g03tCzJg9ij6p2A/idkhSOIoLcj DZHjTzexkI3/335yTde8DaOJCZ3F6WcD+vU7VUp5YoIjfTevTfMRJ3tmf9HfH14Sw7o+ f/t2uWLhtCx+wpQRuU4g55FajJeEVVQyRQLs12cxMbH86qaQtDwExuPglrvn7FDnYojH OU8g== X-Gm-Message-State: APt69E032GNevxh+T/OJrVBWxRsdy010oouH323fr8N1rMlWmIMUiJrb 24gaVUTOmwxYpTVl0IDDuwVgHskJP/DC5CmtH3A= X-Google-Smtp-Source: ADUXVKKaOF1BReclHITBeyQ8YHGiNrCMEnX6jYaeZ9dfWAfITjyzjkE8ybnoEg2Ex00swuhh5Rlg2b2+QPOoJF/EQM8= X-Received: by 2002:a19:920a:: with SMTP id u10-v6mr3361326lfd.33.1529143708731; Sat, 16 Jun 2018 03:08:28 -0700 (PDT) MIME-Version: 1.0 References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> In-Reply-To: <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> From: Nabil Benamar Date: Sat, 16 Jun 2018 10:08:17 +0000 Message-ID: To: Ole Troan Cc: Alexandre Petrescu , "ipv6@ietf.org" , "its@ietf.org" Content-Type: multipart/alternative; boundary="00000000000091d0f7056ebf838d" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 10:08:41 -0000 --00000000000091d0f7056ebf838d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What we have said about ND is applicable for DAD! Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 On Sat, Jun 16, 2018 at 9:55 AM Ole Troan wrote: > > > > On 16 Jun 2018, at 11:42, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > > > ND assumes that IPv6 multicast addresses are implemented, but does not > > assume that nodes always receive multicasts. ND is more like UDP rathe= r > than like TCP. ND has this NUD procedure when something may go wrong. ND > implementations often send 2 or 3 redundant messages of same content, > > just to be sure. > > > > The fact that the link layer does not ensure that all nodes receive > > multicasts is not a problem for ND. In WiFi too some times packets are > lost, despite being in mode 'associated', yet ND works ok there too. > > And DAD? > > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000091d0f7056ebf838d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What we have said about ND is app= licable for DAD!
<= div dir=3D"ltr">

=

Best regards
Nabil Benamar
---------= ----------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88




<= br>
=


--00000000000091d0f7056ebf838d-- From nobody Sat Jun 16 03:40:10 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D196131004; Sat, 16 Jun 2018 03:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4jAJ5cfI9nz; Sat, 16 Jun 2018 03:40:04 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC659130DE2; Sat, 16 Jun 2018 03:40:04 -0700 (PDT) Received: from [192.168.10.187] (145.51-175-104.customer.lyse.net [51.175.104.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 46AE72D51D4; Sat, 16 Jun 2018 10:40:04 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-C54ABF66-E5EB-4871-8E6D-C179CE3AB358 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Sat, 16 Jun 2018 12:40:02 +0200 Cc: Alexandre Petrescu , "ipv6@ietf.org" , "its@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <79F20E22-B2A5-48B3-9993-860DF47DC4A8@employees.org> References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> To: Nabil Benamar Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 10:40:08 -0000 --Apple-Mail-C54ABF66-E5EB-4871-8E6D-C179CE3AB358 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 16 Jun 2018, at 12:08, Nabil Benamar wrote: >=20 > What we have said about ND is applicable for DAD! How so, given that DAD depends on reliable multicast delivery to all nodes t= o function? Cheers=20 Ole >=20 >=20 > Best regards > Nabil Benamar > ------------------- > =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan wrote: >>=20 >>=20 >> > On 16 Jun 2018, at 11:42, Alexandre Petrescu wrote: >> >=20 >> > ND assumes that IPv6 multicast addresses are implemented, but does not >> > assume that nodes always receive multicasts. ND is more like UDP rathe= r than like TCP. ND has this NUD procedure when something may go wrong. ND i= mplementations often send 2 or 3 redundant messages of same content, >> > just to be sure. >> >=20 >> > The fact that the link layer does not ensure that all nodes receive >> > multicasts is not a problem for ND. In WiFi too some times packets are= lost, despite being in mode 'associated', yet ND works ok there too. >>=20 >> And DAD? >>=20 >> Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- --Apple-Mail-C54ABF66-E5EB-4871-8E6D-C179CE3AB358 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 16 Ju= n 2018, at 12:08, Nabil Benamar <b= enamar73@gmail.com> wrote:

What we have said about ND is app= licable for DAD!

How so, given t= hat DAD depends on reliable multicast delivery to all nodes to function?
Cheers 
Ole


<= div dir=3D"ltr">


Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88<= /div>



=




On Sat, Jun 16, 2018 at 9:55 AM Ole Troan <otroan@employees.org> wrote:


> On 16 Jun 2018, at 11:42, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:
>
> ND assumes that IPv6 multicast addresses are implemented, but does not<= br> > assume that nodes always receive multicasts.  ND is more like UDP r= ather than like TCP.  ND has this NUD procedure when something may go w= rong. ND implementations often send 2 or 3 redundant messages of same conten= t,
> just to be sure.
>
> The fact that the link layer does not ensure that all nodes receive
= > multicasts is not a problem for ND.  In WiFi too some times packet= s are lost, despite being in mode 'associated', yet ND works ok there too.
And DAD?

Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listin= fo/ipv6
--------------------------------------------------------------------
= --Apple-Mail-C54ABF66-E5EB-4871-8E6D-C179CE3AB358-- From nobody Sat Jun 16 05:23:32 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4DE130DE8; Sat, 16 Jun 2018 05:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCKxlBxMFK0D; Sat, 16 Jun 2018 05:23:29 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C660E120049; Sat, 16 Jun 2018 05:23:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5GCNF1j016668; Sat, 16 Jun 2018 14:23:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F417F2014E6; Sat, 16 Jun 2018 14:23:14 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E2037200803; Sat, 16 Jun 2018 14:23:14 +0200 (CEST) Received: from [132.166.84.70] ([132.166.84.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5GCNDee018152; Sat, 16 Jun 2018 14:23:14 +0200 To: Ole Troan , Nabil Benamar Cc: "ipv6@ietf.org" , "its@ietf.org" References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> <79F20E22-B2A5-48B3-9993-860DF47DC4A8@employees.org> From: Alexandre Petrescu Message-ID: <2eb1370a-54ed-a65f-25a2-2372f420e8e4@gmail.com> Date: Sat, 16 Jun 2018 14:23:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <79F20E22-B2A5-48B3-9993-860DF47DC4A8@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 12:23:31 -0000 Le 16/06/2018 à 12:40, Ole Troan a écrit : > > > On 16 Jun 2018, at 12:08, Nabil Benamar > wrote: > >> What we have said about ND is applicable for DAD! > > How so, given that DAD depends on reliable multicast delivery to all > nodes to function? Is DAD working on WiFi? Alex > > Cheers > Ole > > >> >> >> Best regards >> Nabil Benamar >> ------------------- >> نبيل بنعمرو >> >> >> >> >> >> >> >> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan > > wrote: >> >> >> >> > On 16 Jun 2018, at 11:42, Alexandre Petrescu >> > > wrote: >> > >> > ND assumes that IPv6 multicast addresses are implemented, but >> does not >> > assume that nodes always receive multicasts.  ND is more like >> UDP rather than like TCP.  ND has this NUD procedure when >> something may go wrong. ND implementations often send 2 or 3 >> redundant messages of same content, >> > just to be sure. >> > >> > The fact that the link layer does not ensure that all nodes receive >> > multicasts is not a problem for ND.  In WiFi too some times >> packets are lost, despite being in mode 'associated', yet ND works >> ok there too. >> >> And DAD? >> >> Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> From nobody Sat Jun 16 18:47:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7776131175; Sat, 16 Jun 2018 18:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyFQgFradVZ2; Sat, 16 Jun 2018 18:47:14 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 CAB72130EFD; Sat, 16 Jun 2018 18:47:14 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id b17-v6so6553372pfi.0; Sat, 16 Jun 2018 18:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rCybMBM4iuaLZVB5s73fcfj2K3yQhuwENRWhSXLOguA=; b=M8M1fhRTIDXmedVNJBs8cV4p20VTYBeAxcomPY3fwXWAExcPmfYnsx3us33wOxISm6 d99fXxiVXr4baplur1NlGi6SOgL6jsCAK8UyLLEqY+oE2KZWmgn8jN71prQigreD7v41 nvbn+rG1c0eKcqBNpslaK549EW4ouF16e30yYN4k8obAvK5bnj67Eqmic3Z3Ig0mql4M xq3htYFkN6vx8uTavPlG017ywsP+o5IYutyGtDcgHuqTpyk6a/KE9r1MJDuQI1LYHC4P 6/n8Uny3TVzJBHKoIB1EdVyEBTr8rBvFByq3T2W/yUGXdHDcWGjc+n3yBSFAomhx+0Qe 9GFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rCybMBM4iuaLZVB5s73fcfj2K3yQhuwENRWhSXLOguA=; b=hf5A3/B6aQdpiKEg8ytwrVDp4yZepKC/hZ1HMvm2ImXGJCGdRfMWWOGlia8DU/kdBu qxNKEt4eEIPgxgx3rJQnNwH0wSw0xD4g7br1Oqlkk01XiBrmbhwFcMc14ddDwo79SIWH WtksJ5UZMfFaIDw3Z0jidtZInk/Su2YqlCSvFF2rB5y/lejSic0PkkzqVIOWUQls1JBx VQbRrp2NsE1CzUiOnhgBV9t8F3AZeHcWFpCGuZ/fzsOguPI3luYKRN/bufupMRDhcyRP y9cz5LsoEf30p4xFgumIoD6qfWDMp9s4P+p2wvwBEW4aegTpm45MxeGuXinPXNdTI2dM AptA== X-Gm-Message-State: APt69E156OePXFk+IDkXZdL2xtABU3TLSfkKHVvDBGtqG8kbuFA/Vewm O16ERlSQJhRnrRruTKEX9ecxAw== X-Google-Smtp-Source: ADUXVKIK7f9Kc9xZVTrz+lc/BPCy4fbxuNghU61xARKdpKsYkbTgscqwi+wCp5i5XUmaywRECkn4ag== X-Received: by 2002:a65:6397:: with SMTP id h23-v6mr6576167pgv.380.1529200033967; Sat, 16 Jun 2018 18:47:13 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id i127-v6sm18515819pfc.154.2018.06.16.18.47.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Jun 2018 18:47:13 -0700 (PDT) To: Alexandre Petrescu , Ole Troan , Nabil Benamar Cc: "ipv6@ietf.org" , "its@ietf.org" References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> <79F20E22-B2A5-48B3-9993-860DF47DC4A8@employees.org> <2eb1370a-54ed-a65f-25a2-2372f420e8e4@gmail.com> From: Brian E Carpenter Message-ID: <2f8ab184-bbe0-5eb5-6891-3fe9f846e15c@gmail.com> Date: Sun, 17 Jun 2018 13:47:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2eb1370a-54ed-a65f-25a2-2372f420e8e4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 01:47:25 -0000 On 17/06/2018 00:23, Alexandre Petrescu wrote: >=20 >=20 > Le 16/06/2018 =C3=A0 12:40, Ole Troan a =C3=A9crit=C2=A0: >> >> >> On 16 Jun 2018, at 12:08, Nabil Benamar > > wrote: >> >>> What we have said about ND is applicable for DAD! >> >> How so, given that DAD depends on reliable multicast delivery to all=20 >> nodes to function? >=20 > Is DAD working on WiFi? Only to the extent that WiFi implements multicast (which is also true for switched Ethernet). The underlying question here is how does OCB implement multicast, given that nodes are unregistered and that radio-frequency barriers between nodes may be normal. Brian =20 > Alex >=20 >> >> Cheers >> Ole >> >> >>> >>> >>> Best regards >>> Nabil Benamar >>> ------------------- >>> =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan >> > wrote: >>> >>> >>> >>> > On 16 Jun 2018, at 11:42, Alexandre Petrescu >>> >> > wrote: >>> > >>> > ND assumes that IPv6 multicast addresses are implemented, but >>> does not >>> > assume that nodes always receive multicasts.=C2=A0 ND is more l= ike >>> UDP rather than like TCP.=C2=A0 ND has this NUD procedure when >>> something may go wrong. ND implementations often send 2 or 3 >>> redundant messages of same content, >>> > just to be sure. >>> > >>> > The fact that the link layer does not ensure that all nodes rec= eive >>> > multicasts is not a problem for ND.=C2=A0 In WiFi too some time= s >>> packets are lost, despite being in mode 'associated', yet ND work= s >>> ok there too. >>> >>> And DAD? >>> >>> Ole >>> -----------------------------------------------------------------= --- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 >>> -----------------------------------------------------------------= --- >>> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sun Jun 17 01:28:54 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F41130DC6; Sun, 17 Jun 2018 01:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ1imTF4xUad; Sun, 17 Jun 2018 01:28:45 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AABA130DC4; Sun, 17 Jun 2018 01:28:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5H8SV4Z025097; Sun, 17 Jun 2018 10:28:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E1CF3200DCF; Sun, 17 Jun 2018 10:28:31 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CD025200DA3; Sun, 17 Jun 2018 10:28:31 +0200 (CEST) Received: from [132.166.84.55] ([132.166.84.55]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5H8SU3f025820; Sun, 17 Jun 2018 10:28:31 +0200 To: Brian E Carpenter , Ole Troan , Nabil Benamar Cc: "ipv6@ietf.org" , "its@ietf.org" References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> <79F20E22-B2A5-48B3-9993-860DF47DC4A8@employees.org> <2eb1370a-54ed-a65f-25a2-2372f420e8e4@gmail.com> <2f8ab184-bbe0-5eb5-6891-3fe9f846e15c@gmail.com> From: Alexandre Petrescu Message-ID: Date: Sun, 17 Jun 2018 10:28:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2f8ab184-bbe0-5eb5-6891-3fe9f846e15c@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 08:28:47 -0000 Le 17/06/2018 à 03:47, Brian E Carpenter a écrit : > On 17/06/2018 00:23, Alexandre Petrescu wrote: >> >> >> Le 16/06/2018 à 12:40, Ole Troan a écrit : >>> >>> >>> On 16 Jun 2018, at 12:08, Nabil Benamar >> > wrote: >>> >>>> What we have said about ND is applicable for DAD! >>> >>> How so, given that DAD depends on reliable multicast delivery to >>> all nodes to function? >> >> Is DAD working on WiFi? > > Only to the extent that WiFi implements multicast (which is also true > for switched Ethernet). OCB implements multicast as WiFi and Ethernet does: it offers link-layer multicast addresses. I am not aware of some WiFi that does implement link-layer multicast, and other WiFi that does not implement multicast? I am aware of some WiFi which, at some point, did not implement link-layer multicast addressing. YEt, most WiFi I work with recently did implement link-layer multicast addressing. > The underlying question here is how does OCB implement multicast, > given that nodes are unregistered and that radio-frequency barriers > between nodes may be normal. That is a good question. At this time, I think that in OCB all messages sent to 33:33::1 (a link-layer multicast address signifying "all nodes") are sent to all nodes that are on the same channel, without necessarily being associated. In OCB mode, I did not see a need for making distinction between groups of nodes on the same link (like IPv6 'all-nodes' vs 'all-hosts' vs 'all-routers'). I did set up OCB links in vehicle-to-vehicle mode (group of IP Routers on same OCB link), and also OCB links in vehicles-to-Road-Side-Unit mode (group of IP Hosts and one IP Router on same OCB link). At the same time, I do agree that whereas there are link-layer specific multicast addresses (e.g. 33:33::1) there are no link-layer specific messages (e.g. a link layer equivalent of IP MLD Report message). But that lack of link-layer multicast functionality (no link-layer multicast messages) is also present in WiFi, Ethernet and in OCB mode. When IEEE makes these messages, IP-over-OCB will take advantage of it. I do not think that this latter lack of link-layer multicast messages is a hurdle in making IPv6 work on OCB links today. Alex > > Brian > >> Alex >> >>> >>> Cheers Ole >>> >>> >>>> >>>> >>>> Best regards Nabil Benamar ------------------- نبيل بنعمرو >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan >>>> > wrote: >>>> >>>> >>>> >>>>> On 16 Jun 2018, at 11:42, Alexandre Petrescu >>>> >>> > wrote: >>>>> >>>>> ND assumes that IPv6 multicast addresses are implemented, >>>>> but >>>> does not >>>>> assume that nodes always receive multicasts. ND is more >>>>> like >>>> UDP rather than like TCP. ND has this NUD procedure when >>>> something may go wrong. ND implementations often send 2 or 3 >>>> redundant messages of same content, >>>>> just to be sure. >>>>> >>>>> The fact that the link layer does not ensure that all nodes >>>>> receive multicasts is not a problem for ND. In WiFi too some >>>>> times >>>> packets are lost, despite being in mode 'associated', yet ND >>>> works ok there too. >>>> >>>> And DAD? >>>> >>>> Ole >>>> -------------------------------------------------------------------- >>>> >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >> >> >>>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > >> > From nobody Sun Jun 17 05:27:43 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05D9130EE1; Sun, 17 Jun 2018 05:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC4Cs9aun9LC; Sun, 17 Jun 2018 05:27:31 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 4BFB9130DF0; Sun, 17 Jun 2018 05:27:31 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id x34-v6so12997342qtk.5; Sun, 17 Jun 2018 05:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=zfBDzOx8lQrLWNYvQ+w7VkF4OX6xvLSZaNpIw1uX7PA=; b=IQ6a9rnHY1Y2jOTjHlreC9F9dQ5P2nVKZ4yrySuPllEQFqmxch48Dz01BS+QDL4J4U YBoOittbtEC2P62UU/7iFo7wyZ4kn8XE1kIWJT4Ty1hiZ/Th00GBQh7FhHyl35Gd9Db0 G8OJzk8bnmIwKdNDMl48TP6jUQyGPe6bBj+TyD87dBfYHb5i8YAlU8x57aJ7+XGtIQZP O5c/xG+6CmpABiBP/cyqW6Jl44djLGZnNiym4dc+lDSUhI0Of0OfFS49H955570YhZSW AYD0rz7wWu92hriYjme5MUlzbgdla/RYEpkgqsIqy1fIUrGTvsjueLwU3lVnpi5q+qeS COaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=zfBDzOx8lQrLWNYvQ+w7VkF4OX6xvLSZaNpIw1uX7PA=; b=eMC0ewHTogpYjMy9d+pfD8HXJpQWMjdZjLPy8dn4g2+7MG6GioSBCzXj7EC7lwfoD6 0OheUfCguyO1LUcZuQTcLiJ7RzUWijkpbogCRtVB+Ttw4R5HMG6cHlSO5zci1Bb/3ehP NcGFlU1F9XkHpKcq1Rn94aee+eF+hgMYACFBCz49DOPDohyf5UR9WZb6T+M7PFEayMub UGT5lxyrNBXVXeML+NaSc9yb4Ar8WMkMoqyQXwR6u48JarweQmURv0mZsayHgdKrsakY 7FYSsnpGG4fySsFp1/nFoFN2FehYLmR2LiVFMqFgz2pQksxcMqSMoAt1/2KQ6Fo3r/83 awxQ== X-Gm-Message-State: APt69E38iGrpOqFw0RlyP3eQo2st6HwRA6LOE1hWaFzLKKNSifpT0cGs zQGwqNF6zW0k+kodOs2eimM= X-Google-Smtp-Source: ADUXVKJ3fN0LruCt+m6lWvlqtl28FpTmWn9kS8TlmyLyPgDPWFyT1DU0MHx6rUHJw+WCCGB8jwYP7Q== X-Received: by 2002:a0c:a244:: with SMTP id f62-v6mr7436715qva.70.1529238450158; Sun, 17 Jun 2018 05:27:30 -0700 (PDT) Received: from FrancoisPC (pool-96-255-89-226.washdc.fios.verizon.net. [96.255.89.226]) by smtp.gmail.com with ESMTPSA id s128-v6sm8243515qkh.2.2018.06.17.05.27.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jun 2018 05:27:29 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , "'Brian E Carpenter'" , "'Ole Troan'" , "'Nabil Benamar'" Cc: , References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> <79F20E22-B2A5-48B3-9993-860DF47DC4A8@employees.org> <2eb1370a-54ed-a65f-25a2-2372f420e8e4@gmail.com> <2f8ab184-bbe0-5eb5-6891-3fe9f846e15c@gmail.com> In-Reply-To: Date: Sun, 17 Jun 2018 08:27:29 -0400 Message-ID: <000e01d40636$8f9033e0$aeb09ba0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01D40615.0883C400" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIivL2TtjP/XqJkHFaVS1SyPNDdnQKQi3JyAd1jursCKa+VOwJCqQa8Aa87XPAC6bV7yQLRoAv2ASTV7cejO3h0EA== Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 12:27:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000F_01D40615.0883C400 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable "At this time, I think that in OCB all messages sent to 33:33::1 (a = link-layer multicast address signifying "all nodes") are sent to all = nodes that are on the same channel, without necessarily being = associated." Address 1 (Destination) =3D ff ff ff ff ff ff Address 2 (source) =3D random 6 octets Address 3 (BSS ID) =3D ff ff ff ff ff ff Address 4 omitted Fygs -----Original Message----- From: its On Behalf Of Alexandre Petrescu Sent: Sunday, June 17, 2018 4:29 AM To: Brian E Carpenter ; Ole Troan = ; Nabil Benamar Cc: ipv6@ietf.org; its@ietf.org Subject: Re: [ipwave] I-D Action: = draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND Le 17/06/2018 =C3=A0 03:47, Brian E Carpenter a =C3=A9crit : > On 17/06/2018 00:23, Alexandre Petrescu wrote: >>=20 >>=20 >> Le 16/06/2018 =C3=A0 12:40, Ole Troan a =C3=A9crit : >>>=20 >>>=20 >>> On 16 Jun 2018, at 12:08, Nabil Benamar >> > wrote: >>>=20 >>>> What we have said about ND is applicable for DAD! >>>=20 >>> How so, given that DAD depends on reliable multicast delivery to all = >>> nodes to function? >>=20 >> Is DAD working on WiFi? >=20 > Only to the extent that WiFi implements multicast (which is also true=20 > for switched Ethernet). OCB implements multicast as WiFi and Ethernet does: it offers link-layer = multicast addresses. I am not aware of some WiFi that does implement link-layer multicast, = and other WiFi that does not implement multicast? I am aware of some WiFi which, at some point, did not implement = link-layer multicast addressing. YEt, most WiFi I work with recently = did implement link-layer multicast addressing. > The underlying question here is how does OCB implement multicast,=20 > given that nodes are unregistered and that radio-frequency barriers=20 > between nodes may be normal. That is a good question. At this time, I think that in OCB all messages sent to 33:33::1 (a = link-layer multicast address signifying "all nodes") are sent to all = nodes that are on the same channel, without necessarily being = associated. In OCB mode, I did not see a need for making distinction between groups = of nodes on the same link (like IPv6 'all-nodes' vs 'all-hosts' vs = 'all-routers'). I did set up OCB links in vehicle-to-vehicle mode (group of IP Routers = on same OCB link), and also OCB links in vehicles-to-Road-Side-Unit mode = (group of IP Hosts and one IP Router on same OCB link). At the same time, I do agree that whereas there are link-layer specific = multicast addresses (e.g. 33:33::1) there are no link-layer specific = messages (e.g. a link layer equivalent of IP MLD Report message). But = that lack of link-layer multicast functionality (no link-layer multicast messages) is also present in WiFi, Ethernet and in OCB mode. When IEEE = makes these messages, IP-over-OCB will take advantage of it. I do not think that this latter lack of link-layer multicast messages is = a hurdle in making IPv6 work on OCB links today. Alex >=20 > Brian >=20 >> Alex >>=20 >>>=20 >>> Cheers Ole >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Best regards Nabil Benamar ------------------- = =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan >>> > wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On 16 Jun 2018, at 11:42, Alexandre Petrescu >>>> >>> > wrote: >>>>>=20 >>>>> ND assumes that IPv6 multicast addresses are implemented, but >>>> does not >>>>> assume that nodes always receive multicasts. ND is more like >>>> UDP rather than like TCP. ND has this NUD procedure when something = >>>> may go wrong. ND implementations often send 2 or 3 redundant=20 >>>> messages of same content, >>>>> just to be sure. >>>>>=20 >>>>> The fact that the link layer does not ensure that all nodes=20 >>>>> receive multicasts is not a problem for ND. In WiFi too some=20 >>>>> times >>>> packets are lost, despite being in mode 'associated', yet ND works=20 >>>> ok there too. >>>>=20 >>>> And DAD? >>>>=20 >>>> Ole >>>> ------------------------------------------------------------------- >>>> - >>>> >>>>=20 IETF IPv6 working group mailing list >>>> ipv6@ietf.org = Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> ------------------------------------------------------------------- >>>> - >>>> >> >> >>>>=20 -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org = Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > >>=20 >=20 _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_000F_01D40615.0883C400 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] I-D Action: = draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND

"At this time, I think that in OCB all messages sent to = 33:33::1 (a link-layer multicast address signifying "all = nodes") are sent to all nodes that are on the same channel, without = necessarily being associated."

Address 1 = (Destination) =3D ff ff ff ff ff ff

Address 2 = (source) =3D random 6 octets

Address 3 (BSS = ID) =3D ff ff ff ff ff ff

Address 4 = omitted


Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of Alexandre = Petrescu
Sent: Sunday, June 17, 2018 4:29 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>; Ole Troan = <otroan@employees.org>; Nabil Benamar = <benamar73@gmail.com>
Cc: ipv6@ietf.org; its@ietf.org
Subject: Re: [ipwave] I-D Action: = draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND

Le 17/06/2018 = =C3=A0 03:47, Brian E Carpenter a =C3=A9crit :

> On = 17/06/2018 00:23, Alexandre Petrescu wrote:

>> =

>> =

>> Le = 16/06/2018 =C3=A0 12:40, Ole Troan a =C3=A9crit :

>>> =

>>> =

>>> On = 16 Jun 2018, at 12:08, Nabil Benamar <benamar73@gmail.com =

>>> = <mailto:benamar73@gmail.com>> wrote:

>>> =

>>>> What we have said about ND is = applicable for DAD!

>>> =

>>> = How so, given that DAD depends on reliable multicast delivery to all =

>>> = nodes to function?

>> =

>> Is DAD = working on WiFi?

> =

> Only to = the extent that WiFi implements multicast (which is also true =

> for = switched Ethernet).

OCB implements = multicast as WiFi and Ethernet does: it offers link-layer multicast = addresses.

I am not aware = of some WiFi that does implement link-layer multicast, and other WiFi = that does not implement multicast?

I am aware of = some WiFi which, at some point, did not implement link-layer multicast = addressing.  YEt, most WiFi I work with recently did implement = link-layer multicast addressing.

> The = underlying question here is how does OCB implement multicast, =

> given that = nodes are unregistered and that radio-frequency barriers =

> between = nodes may be normal.

That is a good = question.

At this time, I = think that in OCB all messages sent to 33:33::1 (a link-layer multicast = address signifying "all nodes") are sent to all nodes that are = on the same channel, without necessarily being = associated.

In OCB mode, I = did not see a need for making distinction between groups of nodes on the = same link (like IPv6 'all-nodes' vs 'all-hosts' vs = 'all-routers').

I did set up = OCB links in vehicle-to-vehicle mode (group of IP Routers on same OCB = link), and also OCB links in vehicles-to-Road-Side-Unit mode (group of = IP Hosts and one IP Router on same OCB link).

At the same = time, I do agree that whereas there are link-layer specific multicast = addresses (e.g. 33:33::1) there are no link-layer specific messages = (e.g. a link layer equivalent of IP MLD Report message).  But that = lack of link-layer multicast functionality (no link-layer = multicast

messages) is = also present in WiFi, Ethernet and in OCB mode.  When IEEE makes = these messages, IP-over-OCB will take advantage of it.

I do not think = that this latter lack of link-layer multicast messages is a hurdle in = making IPv6 work on OCB links today.

Alex

> =

> = Brian

> =

>> = Alex

>> =

>>> =

>>> = Cheers Ole

>>> =

>>> =

>>>>

>>>>

>>>> Best regards Nabil Benamar = ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>> On Sat, Jun 16, 2018 at 9:55 AM Ole = Troan <otroan@employees.org

>>>> <mailto:otroan@employees.org>> wrote:

>>>>

>>>>

>>>>

>>>>> On 16 Jun 2018, at 11:42, = Alexandre Petrescu

>>>> = <alexandre.petrescu@gmail.com

>>>> <mailto:alexandre.petrescu@gmail.com>> wrote:

>>>>>

>>>>> ND assumes that IPv6 multicast = addresses are implemented, but

>>>> does not

>>>>> assume that nodes always receive = multicasts.  ND is more like

>>>> UDP rather than like TCP.  ND has = this NUD procedure when something

>>>> may go wrong. ND implementations often = send 2 or 3 redundant

>>>> messages of same = content,

>>>>> just to be sure.

>>>>>

>>>>> The fact that the link layer does = not ensure that all nodes

>>>>> receive multicasts is not a = problem for ND.  In WiFi too some

>>>>> times

>>>> packets are lost, despite being in = mode 'associated', yet ND works

>>>> ok there too.

>>>>

>>>> And DAD?

>>>>

>>>> Ole

>>>> = -------------------------------------------------------------------

>>>> -

>>>>

>>>>

IETF IPv6 = working group mailing list

>>>> = ipv6@ietf.org = <mailto:ipv6@ietf.org> Administrative Requests:

>>>> = https://www.ietf.org/mailman/listinfo/ipv6=

>>>> = -------------------------------------------------------------------

>>>> -

>>>>

>>

>>

>>>>

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

>> IETF = IPv6 working group mailing list = ipv6@ietf.org = Administrative

>> = Requests: https://www.ietf.org/mailman/listinfo/ipv6=

>> = --------------------------------------------------------------------

>>

>

>> =

> =

_______________________________________________

its mailing = list

its@ietf.org

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

------=_NextPart_000_000F_01D40615.0883C400-- From nobody Sun Jun 17 08:31:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F192E130E1E; Sun, 17 Jun 2018 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYWtOIF7Byz6; Sun, 17 Jun 2018 08:31:44 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036AD130E04; Sun, 17 Jun 2018 08:31:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5HFVUg0035858; Sun, 17 Jun 2018 17:31:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 54FE6200ECB; Sun, 17 Jun 2018 17:31:30 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3CDCE200DCF; Sun, 17 Jun 2018 17:31:30 +0200 (CEST) Received: from [132.166.84.55] ([132.166.84.55]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5HFVSvg020146; Sun, 17 Jun 2018 17:31:29 +0200 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , "'Brian E Carpenter'" , "'Ole Troan'" , "'Nabil Benamar'" Cc: ipv6@ietf.org, its@ietf.org References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <9948a8c7-fc64-f570-4bff-61eb2aef519f@gmail.com> <99794D73-FDC0-4484-A674-B3F074C8137A@employees.org> <79F20E22-B2A5-48B3-9993-860DF47DC4A8@employees.org> <2eb1370a-54ed-a65f-25a2-2372f420e8e4@gmail.com> <2f8ab184-bbe0-5eb5-6891-3fe9f846e15c@gmail.com> <000e01d40636$8f9033e0$aeb09ba0$@gmail.com> From: Alexandre Petrescu Message-ID: <871f336a-a96c-b3c0-16a5-d6be20954988@gmail.com> Date: Sun, 17 Jun 2018 17:31:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <000e01d40636$8f9033e0$aeb09ba0$@gmail.com> Content-Type: multipart/mixed; boundary="------------CE54CC44558B56B564274F91" Content-Language: fr Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 15:31:47 -0000 This is a multi-part message in MIME format. --------------CE54CC44558B56B564274F91 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 17/06/2018 à 14:27, François Simon a écrit : > "/At this time, I think that in OCB all messages sent to 33:33::1 (a > link-layer multicast address signifying "all nodes") are sent to all > nodes that are on the same channel, without necessarily being > associated.//"/// > > // > > Address 1 (Destination) = ff ff ff ff ff ff > > Address 2 (source) = random 6octets > > Address 3 (BSS ID) = ff ff ff ff ff ff > > Address 4 omitted Thank you for the example. That ffffffffffff is for a message that is not IPv6. I suppose it is extracted from a BSM or other WSM or 1609 message? For a message that is IPv6, e.g. an IPv6 ICMPv6 Router Solicitation, the Destination MAC address and the Receiver MAC address are both 33:33::2 (all-hosts). (see packet capture attached). I dont have a packet capture at hand that shows 33:33::1. This 33:33::2 is the same in OCB mode and in ICB mode if I can say so (ICB: _Inside_ de Context of a BSSID, or otherwise just WiFi). Alex > > > Fygs > > -----Original Message----- > From: its On Behalf Of Alexandre Petrescu > Sent: Sunday, June 17, 2018 4:29 AM > To: Brian E Carpenter ; Ole Troan > ; Nabil Benamar > Cc: ipv6@ietf.org; its@ietf.org > Subject: Re: [ipwave] I-D Action: > draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND > > Le 17/06/2018 à 03:47, Brian E Carpenter a écrit : > >> On 17/06/2018 00:23, Alexandre Petrescu wrote: > >>> > >>> > >>> Le 16/06/2018 à 12:40, Ole Troan a écrit : > >>>> > >>>> > >>>> On 16 Jun 2018, at 12:08, Nabil Benamar >>>> > wrote: > >>>> > >>>>> What we have said about ND is applicable for DAD! > >>>> > >>>> How so, given that DAD depends on reliable multicast delivery to all > >>>> nodes to function? > >>> > >>> Is DAD working on WiFi? > >> > >> Only to the extent that WiFi implements multicast (which is also true > >> for switched Ethernet). > > OCB implements multicast as WiFi and Ethernet does: it offers link-layer > multicast addresses. > > I am not aware of some WiFi that does implement link-layer multicast, > and other WiFi that does not implement multicast? > > I am aware of some WiFi which, at some point, did not implement > link-layer multicast addressing.  YEt, most WiFi I work with recently > did implement link-layer multicast addressing. > >> The underlying question here is how does OCB implement multicast, > >> given that nodes are unregistered and that radio-frequency barriers > >> between nodes may be normal. > > That is a good question. > > At this time, I think that in OCB all messages sent to 33:33::1 (a > link-layer multicast address signifying "all nodes") are sent to all > nodes that are on the same channel, without necessarily being associated. > > In OCB mode, I did not see a need for making distinction between groups > of nodes on the same link (like IPv6 'all-nodes' vs 'all-hosts' vs > 'all-routers'). > > I did set up OCB links in vehicle-to-vehicle mode (group of IP Routers > on same OCB link), and also OCB links in vehicles-to-Road-Side-Unit mode > (group of IP Hosts and one IP Router on same OCB link). > > At the same time, I do agree that whereas there are link-layer specific > multicast addresses (e.g. 33:33::1) there are no link-layer specific > messages (e.g. a link layer equivalent of IP MLD Report message).  But > that lack of link-layer multicast functionality (no link-layer multicast > > messages) is also present in WiFi, Ethernet and in OCB mode.  When IEEE > makes these messages, IP-over-OCB will take advantage of it. > > I do not think that this latter lack of link-layer multicast messages is > a hurdle in making IPv6 work on OCB links today. > > Alex > >> > >> Brian > >> > >>> Alex > >>> > >>>> > >>>> Cheers Ole > >>>> > >>>> > >>>>> > >>>>> > >>>>> Best regards Nabil Benamar -------------------نبيلبنعمرو > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan >>>>> > wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On 16 Jun 2018, at 11:42, Alexandre Petrescu > >>>>> >>>>> > wrote: > >>>>>> > >>>>>> ND assumes that IPv6 multicast addresses are implemented, but > >>>>> does not > >>>>>> assume that nodes always receive multicasts.  ND is more like > >>>>> UDP rather than like TCP.  ND has this NUD procedure when something > >>>>> may go wrong. ND implementations often send 2 or 3 redundant > >>>>> messages of same content, > >>>>>> just to be sure. > >>>>>> > >>>>>> The fact that the link layer does not ensure that all nodes > >>>>>> receive multicasts is not a problem for ND.  In WiFi too some > >>>>>> times > >>>>> packets are lost, despite being in mode 'associated', yet ND works > >>>>> ok there too. > >>>>> > >>>>> And DAD? > >>>>> > >>>>> Ole > >>>>> ------------------------------------------------------------------- > >>>>> - > >>>>> > >>>>> > > IETF IPv6 working group mailing list > >>>>>ipv6@ietf.org Administrative > Requests: > >>>>>https://www.ietf.org/mailman/listinfo/ipv6 > >>>>> ------------------------------------------------------------------- > >>>>> - > >>>>> > >>> > >>> > >>>>> > > -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing listipv6@ietf.orgAdministrative > >>> Requests:https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >> > >>> > >> > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > --------------CE54CC44558B56B564274F91 Content-Type: application/octet-stream; name="captura_cams2.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="captura_cams2.pcap" 1MOyoQIABAAAAAAAAAAAAP//AAB/AAAAX5GHVwBVAACfAAAAnwAAAAAAIgAvSAAAfUJVNgEA AAAQGAwXQAHnAQAAAAAAAAAAAAAIAAAAMzMAAAABMBRK5keZ////////kOyqqgMAAACG3WAA AAAAMREB/oAAAAAAAAAyFEr//uZHmf8CAAAAAAAAAAAAAAAAAAGZ+8NQADH9BgECAAAAFxBg ACmJ2UWtUtIEaLzdoAA291gAdBAAACIBMEqAC6mAD//AcCIO0mCRh1eMRgAAnwAAAJ8AAAAA ACIAL0gAABl1ZDYBAAAAEBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf////// /9DsqqoDAAAAht1gAAAAADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAABiAPD UAAxDv4BAgAAABcQYQApidlFrVLSBGi83aAANvdYAHQQAAAiATBKgAupgA//wMbTbMVgkYdX nvcAAHYAAAB2AAAAAAAiAC9IAABOJmU2AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAA AAIwFErmR5n////////g7KqqAwAAAIbdYAAAAAAIOv8AAAAAAAAAAAAAAAAAAAAA/wIAAAAA AAAAAAAAAAAAAoUAe7gAAAAAyZigI2GRh1cCMAAAnwAAAJ8AAAAAACIAL0gAAMWfczYBAAAA EBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf///////yDtqqoDAAAAht1gAAAA ADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAAB4T7DUAAxtcEBAgAAABcQYgAp idlFrVLSBGi83aAANvdYAHQQAAAiATBKgAupgA//wCMp+uRikYdX8nEAAJ8AAACfAAAAAAAi AC9IAADXIoM2AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAAAAEwFErmR5n///////9g 7aqqAwAAAIbdYAAAAAAxEQH+gAAAAAAAADIUSv/+5keZ/wIAAAAAAAAAAAAAAAAAAbBuw1AA MeZwAQIAAAAXEGMAKYnZRc1S0gRovN2gADb3WAB0EAAAIgEwSoALqYAP/8BOhpOoY5GHVzJk AACfAAAAnwAAAAAAIgAvSAAAN1aSNgEAAAAQGAwXQAHoAQAAAAAAAAAAAAAIAAAAMzMAAAAB MBRK5keZ////////oO2qqgMAAACG3WAAAAAAMREB/oAAAAAAAAAyFEr//uZHmf8CAAAAAAAA AAAAAAAAAAHnH8NQADGv3gECAAAAFxBkACmJ2UWtUtIEaLzdoAA291gAdBAAACIBMEqAC6mA D//ApuOGLmSRh1f8TgAAnwAAAJ8AAAAAACIAL0gAACuCoTYBAAAAEBgMF0AB6AEAAAAAAAAA AAAACAAAADMzAAAAATAUSuZHmf///////+DtqqoDAAAAht1gAAAAADERAf6AAAAAAAAAMhRK //7mR5n/AgAAAAAAAAAAAAAAAAABoCHDUAAx+SIBAgAAABcQZQApidlFrVLSBGkglkAANvdY AHQQAAAcATBKgAupgA//wH84dV9kkYdXyAQBAHYAAAB2AAAAAAAiAC9IAAAGOKI2AQAAABAY DBdAAecBAAAAAAAAAAAAAAgAAAAzMwAAAAIwFErmR5n////////w7aqqAwAAAIbdYAAAAAAI Ov8AAAAAAAAAAAAAAAAAAAAA/wIAAAAAAAAAAAAAAAAAAoUAe7gAAAAAG6ZcTGWRh1fCGw4A nwAAAJ8AAAAAACIAL0gAAOmOvjYBAAAAEBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAU SuZHmf///////1DuqqoDAAAAht1gAAAAADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAA AAAAAAABvUTDUAAx2vkBAgAAABcQZgApidlNLVLSAukglkAANvxYAHQQAAAXATBKgAupgA// wPREXwlmkYdXWm0BAJ8AAACfAAAAAAAiAC9IAACzIsE2AQAAABAYDBdAAegBAAAAAAAAAAAA AAgAAAAzMwAAAAEwFErmR5n///////9w7qqqAwAAAIbdYAAAAAAxEQH+gAAAAAAAADIUSv/+ 5keZ/wIAAAAAAAAAAAAAAAAAAeG7w1AAMa4GAQIAAAAXEGcAKYnZU+1S0gGnpI8AADcAGAB0 EAAAFgEwSoALqYAP/8DRScfLZ5GHVyg8AACfAAAAnwAAAAAAIgAvSAAAozLPNgEAAAAQGAwX QAHoAQAAAAAAAAAAAAAIAAAAMzMAAAABMBRK5keZ////////oO6qqgMAAACG3WAAAAAAMREB /oAAAAAAAAAyFEr//uZHmf8CAAAAAAAAAAAAAAAAAAGDAMNQADHNfwECAAAAFxBoACmJ2VQt UtIBp6SPAAA3AVgAdBAAABUBMEqAC6mAD//A3uqyx2iRh1cOQgAAnwAAAJ8AAAAAACIAL0gA AKV53jYBAAAAEBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf///////+DuqqoD AAAAht1gAAAAADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAAB5DHDUAAxb4YB AgAAABcQaQApidlUDVLSAcdTVkAANwFWAHQQAAAlATBKgAupgA//wFiFZoVokYdXRgkBAHYA AAB2AAAAAAAiAC9IAADsQN82AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAAAAIwFErm R5n///////8A76qqAwAAAIbdYAAAAAAIOv8AAAAAAAAAAAAAAAAAAAAA/wIAAAAAAAAAAAAA AAAAAoUAe7gAAAAAouqN7mmRh1dSZwAAnwAAAJ8AAAAAACIAL0gAAC3g7TYBAAAAEBgMF0AB 5wEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf///////0DvqqoDAAAAht1gAAAAADERAf6A AAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAABxQ3DUAAxfqkBAgAAABcQagApidlULVLS AadTVkAANwFWAHQQAAA1ATBKgAupgA//wLlgN7dqkYdX9mMAAJ8AAACfAAAAAAAiAC9IAADX Hf02AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAAAAEwFErmR5n///////9w76qqAwAA AIbdYAAAAAAxEQH+gAAAAAAAADIUSv/+5keZ/wIAAAAAAAAAAAAAAAAAAcS7w1AAMX76AQIA AAAXEGsAKYnZVC1S0gGnU1ZAADcBVgB0EAAANQEwSoALqYAP/8AeDmdi --------------CE54CC44558B56B564274F91-- From nobody Wed Jun 20 06:26:16 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B38130E98; Wed, 20 Jun 2018 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R9lKg4pPjhD; Wed, 20 Jun 2018 06:26:11 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078A3130E94; Wed, 20 Jun 2018 06:26:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5KDQ8cp005655; Wed, 20 Jun 2018 15:26:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2E5482070E8; Wed, 20 Jun 2018 15:26:08 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1B1F22070E5; Wed, 20 Jun 2018 15:26:08 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5KDQ7wO021553; Wed, 20 Jun 2018 15:26:08 +0200 To: Brian E Carpenter Cc: Nabil Benamar , "ipv6@ietf.org" , "its@ietf.org" References: <152907929345.27341.9756050748596080421@ietfa.amsl.com> <9c3c717c-12cf-d54e-ed65-1b5b0a1e35b3@gmail.com> <5e99d50a-5b67-4b45-a056-172cfaffdcdb@gmail.com> From: Alexandre Petrescu Message-ID: <93e7beb5-94ce-1c11-3780-edc557472e8e@gmail.com> Date: Wed, 20 Jun 2018 15:26:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5e99d50a-5b67-4b45-a056-172cfaffdcdb@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 13:26:15 -0000 Le 16/06/2018 à 01:07, Brian E Carpenter a écrit : > On 16/06/2018 10:16, Nabil Benamar wrote: >> Hi Brian, >> >> Which RFC is now the recommended method of IID formation? Are you >> suggesting to use rfc8064 (still a proposed standard) instead of >> RFC2464? > > Of course. It updates RFC2464 and many other IPv6-over-foo > standards. I am going to put this: > The Interface Identifier for an 802.11-OCB interface is formed using > the same rules as the Interface Identifier for an Ethernet interface; > the RECOMMENDED method for forming stable Interface Identifiers > (IIDs) is described in . The method of > forming IIDs described in section 4 of MAY > be used during transition time. Remark RFC2464's "ff:fe" is MAY, during transition time. Because there are still many kernels in the embedded world doing that. I am afraid ruling out something that is still in widespread use. Alex >> Best regards Nabil Benamar ------------------- نبيل بنعمرو >> >> >> >> >> >> >> >> On Fri, Jun 15, 2018 at 8:46 PM Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> Hi, >>> >>>> The operation of the Neighbor Discovery protocol (ND) over >>>> 802.11-OCB links is different than over 802.11 links. In OCB, >>>> the link layer does not ensure that all associated members >>>> receive all messages, because there is no association >>>> operation. Neighbor Discovery (ND) is used over 802.11-OCB. >>> >>> It's different and not all members receive all multicasts? Since >>> ND assumes that nodes receive multicasts, *how* is it used? Since >>> there is no reference, does ND actually mean RFC4861? If not, >>> where is the appropriate form of ND (that does not rely on >>> multicasts) defined? >>> >>>> 4.5. Stateless Autoconfiguration >>>> >>>> The Interface Identifier for an 802.11-OCB interface is formed >>>> using the same rules as the Interface Identifier for an >>>> Ethernet interface; this is described in section 4 of >>>> [RFC2464]. No changes are needed, but some care must be taken >>>> when considering the use of the Stateless Address >>>> Auto-Configuration procedure. >>> >>> RFC2464 is no longer the recommended method of IID formation. >>> Also, since there is no reference to RFC4862, where is the >>> appropriate form of SLAAC (that does not rely on multicasts) >>> defined? >>> >>> Regards Brian >>> >>> On 16/06/2018 04:14, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts >>> directories. >>>> This draft is a work item of the IP Wireless Access in >>>> Vehicular >>> Environments WG of the IETF. >>>> >>>> Title : Transmission of IPv6 Packets over IEEE >>>> 802.11 >>> Networks operating in mode Outside the Context of a Basic Service >>> Set (IPv6-over-80211-OCB) >>>> Authors : Alexandre Petrescu Nabil Benamar Jerome >>>> Haerri Jong-Hyouk Lee Thierry Ernst Filename : >>>> draft-ietf-ipwave-ipv6-over-80211ocb-24.txt Pages : >>>> 39 Date : 2018-06-15 >>>> >>>> Abstract: In order to transmit IPv6 packets on IEEE 802.11 >>>> networks running outside the context of a basic service set >>>> (OCB, earlier "802.11p") there is a need to define a few >>>> parameters such as the supported Maximum Transmission Unit size >>>> on the 802.11-OCB link, the header format preceding the IPv6 >>>> header, the Type value within it, and others. This document >>>> describes these parameters for IPv6 and IEEE 802.11-OCB >>>> networks; it portrays the layering of IPv6 on 802.11-OCB >>>> similarly to other known 802.11 and Ethernet layers - by using >>>> an Ethernet Adaptation Layer. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ >>>> >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 >>>> >>> >>>> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-24 >>>> >>>> A diff from the previous version is available at: >>>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24 >>>> >>>> >>>> >>> 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 >>>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jun 20 06:39:20 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A03130EA2; Wed, 20 Jun 2018 06:39:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152950195256.11831.9596602089210590764@ietfa.amsl.com> Date: Wed, 20 Jun 2018 06:39:12 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-25.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 13:39:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-25.txt Pages : 40 Date : 2018-06-20 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-25 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 20 06:42:07 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A717130EA2; Wed, 20 Jun 2018 06:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh3ftBQCm7Bg; Wed, 20 Jun 2018 06:41:57 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010FC130E9E; Wed, 20 Jun 2018 06:41:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5KDfsnY037317; Wed, 20 Jun 2018 15:41:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8754D2060B1; Wed, 20 Jun 2018 15:41:54 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7869E206073; Wed, 20 Jun 2018 15:41:54 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5KDfrss025783; Wed, 20 Jun 2018 15:41:54 +0200 References: <152950195278.11831.5872878786542682548.idtracker@ietfa.amsl.com> To: IPv6 Cc: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <152950195278.11831.5872878786542682548.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 20 Jun 2018 15:41:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152950195278.11831.5872878786542682548.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------1C71F963B41D54576285754B" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-25.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 13:42:00 -0000 This is a multi-part message in MIME format. --------------1C71F963B41D54576285754B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, This new version addresses comments from participants in 6MAN WG: - added a reference to 'IEEE Management Information Base', instead   of just 'Management Information Base'; - added ref to further appendices in the introductory phrases; - improved text for IID formation for SLAAC, inserting recommendation for RFC8064 before   RFC2464. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-25.txt Date : Wed, 20 Jun 2018 06:39:12 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-25.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 25 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-06-19 Group: ipwave Pages: 40 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-25.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-25 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-25 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. 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 --------------1C71F963B41D54576285754B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

This new version addresses comments from participants in 6MAN WG:

- added a reference to 'IEEE Management Information Base', instead
  of just 'Management Information Base';

- added ref to further appendices in the introductory phrases;

- improved text for IID formation for SLAAC, inserting recommendation for RFC8064 before
  RFC2464.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-25.txt
Date : Wed, 20 Jun 2018 06:39:12 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr>


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-25.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	25
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-06-19
Group:		ipwave
Pages:		40
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-25.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-25
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-25

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

--------------1C71F963B41D54576285754B-- From nobody Mon Jun 25 04:33:11 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38F0130DD4 for ; Mon, 25 Jun 2018 04:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8swbpEEardhD for ; Mon, 25 Jun 2018 04:33:08 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19B5130DD1 for ; Mon, 25 Jun 2018 04:33:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5PBX73I044669 for ; Mon, 25 Jun 2018 13:33:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 15F0B203E2A for ; Mon, 25 Jun 2018 13:33:07 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0AFC420189E for ; Mon, 25 Jun 2018 13:33:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5PBX6cl000491 for ; Mon, 25 Jun 2018 13:33:06 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <779f0c8b-df09-200d-ae4e-d8c72fb4f499@gmail.com> Date: Mon, 25 Jun 2018 13:33:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------27A91BF38347B37C320DE428" Content-Language: fr Archived-At: Subject: [ipwave] Argument about 'LTE-V2X' term X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 11:33:10 -0000 This is a multi-part message in MIME format. --------------27A91BF38347B37C320DE428 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We had an internal discussion about what means 'LTE-V2X'. I may be very wrong about this, but this is where I am: The term 'LTE-V2X' is not defined. I pretend that 'LTE-V2X' is when a car sends CAM messages over UDP over IPv6 to an IoT platform in the cloud, or to another car via LTE. Is this wrong? Alex --------------27A91BF38347B37C320DE428 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

We had an internal discussion about what means 'LTE-V2X'.

I may be very wrong about this, but this is where I am:

The term 'LTE-V2X' is not defined.

I pretend that 'LTE-V2X' is when a car sends CAM messages over UDP over IPv6 to an IoT platform in the cloud, or to another car via LTE.

Is this wrong?

Alex

--------------27A91BF38347B37C320DE428-- From nobody Mon Jun 25 06:25:25 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292E4130E8F for ; Mon, 25 Jun 2018 06:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2Celo0X2yTV for ; Mon, 25 Jun 2018 06:25:17 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7912130DED for ; Mon, 25 Jun 2018 06:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3647; q=dns/txt; s=iport; t=1529933117; x=1531142717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/ffR48KTXU6DY27dKgj6m1hey4AiMTQGVmCrSamvJ84=; b=aaNMVxMhbJJTvdoZMKOfVwQDA/6jm6frb+KrOhWLZYXwReopK0vtf/y2 6zieOoARE8E1Mxpc0zKZQEXzkvm56DyHD0EElBsCFcL1jISVxN4SBKF6C iVi7Qf2p35pc2pbkAmGbIo+8/F8jrQ7jJXrB6ZSbO4xhC80RePOThqfI4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgD+6zBb/51dJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8og3mURIFjiEuHXoQKgQ2BZgsYAQqESQIXgnMhNxU?= =?us-ascii?q?BAgEBAQEBAQJtHAyFKQIEAQEhSwsQAgEIBDsDAgICHwYLFBECBA4FgyUBgRt?= =?us-ascii?q?MAxUPqnOCHIRbgi0NgSx9BYhsgVY/gQ8nDIJcglZCAQGBJIM9MYIkApkDLAk?= =?us-ascii?q?CjAaDCYFAhnCFGYpxhlUCERMBgSQzIoFScBU7KgGCPosThT5vjkkBAQ?= X-IronPort-AV: E=Sophos;i="5.51,270,1526342400"; d="scan'208,217";a="133753743" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2018 13:25:16 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w5PDPGrh025789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2018 13:25:16 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Jun 2018 08:25:16 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Mon, 25 Jun 2018 08:25:16 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "its@ietf.org" Thread-Topic: [ipwave] Argument about 'LTE-V2X' term Thread-Index: AQHUDHhSro4k4uKRXUazX3KEsQ+llaRw9vhv Date: Mon, 25 Jun 2018 13:25:16 +0000 Message-ID: References: <779f0c8b-df09-200d-ae4e-d8c72fb4f499@gmail.com> In-Reply-To: <779f0c8b-df09-200d-ae4e-d8c72fb4f499@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_B63BD0E3AD1D420E834082121A4FDB69ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Argument about 'LTE-V2X' term X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 13:25:24 -0000 --_000_B63BD0E3AD1D420E834082121A4FDB69ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IEkgd291bGQgcmVhZCB0aGlzIHRlcm0gYXMsIFYyWCBjb21tdW5pY2F0aW9uIGJhc2VkIG9uIDNH UFAgTFRFIGluZnJhc3RydWN0dXJlLiBJdHMgbm90IG9ubHkgYWJvdXQgQ0FNIG1lc3NhZ2VzLCBi dXQgYW55IHNhZmV0eSByZWxhdGVkIFYyVi9WMkkvVjJQIGNvbW11bmljYXRpb25zIG92ZXIgTFRF IGluZnJhLCBhcyBvcHBvc2VkIHRvIERTUkMuDQoNCk9uIEp1biAyNSwgMjAxOCwgYXQgNDozMyBB TSwgQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPG1haWx0 bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KV2UgaGFkIGFuIGlu dGVybmFsIGRpc2N1c3Npb24gYWJvdXQgd2hhdCBtZWFucyAnTFRFLVYyWCcuDQoNCkkgbWF5IGJl IHZlcnkgd3JvbmcgYWJvdXQgdGhpcywgYnV0IHRoaXMgaXMgd2hlcmUgSSBhbToNCg0KVGhlIHRl cm0gJ0xURS1WMlgnIGlzIG5vdCBkZWZpbmVkLg0KDQpJIHByZXRlbmQgdGhhdCAnTFRFLVYyWCcg aXMgd2hlbiBhIGNhciBzZW5kcyBDQU0gbWVzc2FnZXMgb3ZlciBVRFAgb3ZlciBJUHY2IHRvIGFu IElvVCBwbGF0Zm9ybSBpbiB0aGUgY2xvdWQsIG9yIHRvIGFub3RoZXIgY2FyIHZpYSBMVEUuDQoN CklzIHRoaXMgd3Jvbmc/DQoNCkFsZXgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCml0cyBtYWlsaW5nIGxpc3QNCml0c0BpZXRmLm9yZzxtYWlsdG86 aXRzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMN Cg== --_000_B63BD0E3AD1D420E834082121A4FDB69ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj4mbmJzcDtJIHdvdWxkIHJlYWQgdGhpcyB0ZXJtIGFzLCBWMlggY29t bXVuaWNhdGlvbiBiYXNlZCBvbiAzR1BQIExURSBpbmZyYXN0cnVjdHVyZS4gSXRzIG5vdCBvbmx5 IGFib3V0IENBTSBtZXNzYWdlcywgYnV0IGFueSBzYWZldHkgcmVsYXRlZCBWMlYvVjJJL1YyUCBj b21tdW5pY2F0aW9ucyBvdmVyIExURSBpbmZyYSwgYXMgb3Bwb3NlZCB0byBEU1JDLiZuYnNwOzwv ZGl2Pg0KPGRpdj48YnI+DQpPbiBKdW4gMjUsIDIwMTgsIGF0IDQ6MzMgQU0sIEFsZXhhbmRyZSBQ ZXRyZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20i PmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxwPjxmb250IHNpemU9Ii0x Ij48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+V2UgaGFkIGFuIGludGVybmFsIGRpc2N1c3Npb24g YWJvdXQgd2hhdCBtZWFucyAnTFRFLVYyWCcuPC9mb250PjwvZm9udD48L3A+DQo8cD48Zm9udCBz aXplPSItMSI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPkkgbWF5IGJlIHZlcnkgd3JvbmcgYWJv dXQgdGhpcywgYnV0IHRoaXMgaXMgd2hlcmUgSSBhbTo8L2ZvbnQ+PC9mb250PjwvcD4NCjxwPjxm b250IHNpemU9Ii0xIj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+VGhlIHRlcm0gJ0xURS1WMlgn IGlzIG5vdCBkZWZpbmVkLjwvZm9udD48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iLTEiPjxm b250IGZhY2U9IkNvdXJpZXIgTmV3Ij5JIHByZXRlbmQgdGhhdCAnTFRFLVYyWCcgaXMgd2hlbiBh IGNhciBzZW5kcyBDQU0gbWVzc2FnZXMgb3ZlciBVRFAgb3ZlciBJUHY2IHRvIGFuIElvVCBwbGF0 Zm9ybSBpbiB0aGUgY2xvdWQsIG9yIHRvIGFub3RoZXIgY2FyIHZpYSBMVEUuPGJyPg0KPC9mb250 PjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSItMSI+PGZvbnQgZmFjZT0iQ291cmllciBOZXci PklzIHRoaXMgd3Jvbmc/PGJyPg0KPC9mb250PjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIt MSI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPkFsZXg8YnI+DQo8L2ZvbnQ+PC9mb250PjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pjxz cGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu Pjxicj4NCjxzcGFuPml0cyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0i bWFpbHRvOml0c0BpZXRmLm9yZyI+aXRzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHM8L2E+PC9zcGFuPjxicj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B63BD0E3AD1D420E834082121A4FDB69ciscocom_-- From nobody Mon Jun 25 07:17:31 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD6130EA4 for ; Mon, 25 Jun 2018 07:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN1e6mtFx1v6 for ; Mon, 25 Jun 2018 07:17:27 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D3130EA1 for ; Mon, 25 Jun 2018 07:17:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,270,1526335200"; d="scan'208,217";a="9452319" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 25 Jun 2018 16:17:25 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 1DD3D2C6C; Mon, 25 Jun 2018 16:17:25 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Sri Gundavelli \(sgundave\)'" , "'Alexandre Petrescu'" Cc: References: <779f0c8b-df09-200d-ae4e-d8c72fb4f499@gmail.com> In-Reply-To: Date: Mon, 25 Jun 2018 16:17:24 +0200 Organization: EURECOM Message-ID: <006e01d40c8f$3d71ecc0$b855c640$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01D40CA0.00FF77B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH9R+PfaWGhEscn7Hiom2AI/t8MnwITT9WUpA3m2eA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] Argument about 'LTE-V2X' term X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 14:17:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006F_01D40CA0.00FF77B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable HI Alex, Sri, =20 The =E2=80=98V2X=E2=80=99 is a =E2=80=98function=E2=80=99 part of the = 3GPP specification. And LTE means =E2=80=98not 5G=E2=80=99=E2=80=A6(just = to avoid confusion with future 5G-V2X)=E2=80=A6so, LTE-V2X actually = means: 3GPP rel.14 V2X communication.=20 =20 The 3GPP rel.14 V2X specification does not say anything about what type = of message and under which =E2=80=98pipe=E2=80=99 (IP or non-IP), not = even the frequency band (yes, LTE-V2X PC5 is restricted to 5.9Ghz, but = not LTE-V2X Uu).=20 =20 The only thing that the 3GPP rel.14 V2X provides is the availability of = a non-IP packet format for the negotiation of the radio bearers (unlike = LTE D2D, which only allows IPv4 and IPv6), as well as semi-persistent = scheduling opportunities (which LTE-D2D does not offer)..and = additionally, the fact that you bypass the Discovery phase of the = LTE-D2D (another limitation of the rel.14 version..).=20 =20 What LTE-V2X also does not say is the type of V2X. You would need to add = mode 3 (D2D infrastructure) or mode 4 (D2D ad-hoc) to be complete. And = you would also have the LTE-V2X Uu, which is actually the = V2I=E2=80=A6and indeed, in that case, I assume (but did not formally = check) that it is IP (I would even guess IPv4 and IPv6).=20 =20 And we also need to specify the level of the 3GPP LTE-V2X. so far, I = only mentioned the Access Stratum, but you also have LTE-V2X functions = at the NAS (non-access stratum)=E2=80=A6 =20 In both cases, nothing is said about the type of message, for a simple = reason that a message is only seen by the LTE-V2X = =E2=80=98stack=E2=80=99 as a Logical Channels (and Radio Bearers)... =20 So, the term =E2=80=98LTE-V2X=E2=80=99 is actually specified by 3GPP as = one ProSe (Proximity Service) function (a bit like Public Safety or = Device-to-Device)=E2=80=A6maybe to make an analogy, it could be seem = similarly to the OCB in IEEE=E2=80=A6OCB is a tag to modify the behavior = of a standard to reflex a type of communication=E2=80=A6 =20 So, LTE-V2X by itself, it does not mean much. We need to add further = details: - V2V: LTE-V2X mode 3 (or mode 4) under IPv6 (or under = geonet/WSM) transmitting CAM (with this, we have no doubt on what and = under which frequency) - V2V: LTE-V2X mode 4 (or mode 3) under WSM transmitting CAM - V2I: LTE-V2X Uu under IPv6 transmitting HD-Maps =20 So, summarizing, LTE-V2X means (by shortcutting the 3GPP rel.14 in = front) the V2X functions, but if we want to be absolutely clear (and = usually we need J), just saying: we use LTE-V2X is indeed not = sufficiently defined !! =20 @Alex: now for your statement, it is a bit confusing=E2=80=A6you should = differentiate the communication type: CAM being sent over UDP / IP to an = IoT platform would then be a *LTE-V2X Uu sent on the 3.4GHz frequency = band* (as I do not think it is allowed to transmit V2X messages over the = Uu interface at 5.9Ghz). And CAM being sent over UDP/IP to another car = is the *LTE-V2X PC5 sent over the 5.9Ghz*. As you can see, both means = fully different things=E2=80=A6 =20 And as I am sure you will mention this=E2=80=A6yes, you can transmit CAM = over IPv6 in both PC5 or Uu J =E2=80=A6at least from 3GPP = perspective=E2=80=A6, but I am sure that either IEEE WAVE or ETSI ITS = might but the same restrictions at ITS-G5 J=20 =20 BR, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Sri Gundavelli = (sgundave) Sent: Monday 25 June 2018 15:25 To: Alexandre Petrescu Cc: its@ietf.org Subject: Re: [ipwave] Argument about 'LTE-V2X' term =20 I would read this term as, V2X communication based on 3GPP LTE = infrastructure. Its not only about CAM messages, but any safety related = V2V/V2I/V2P communications over LTE infra, as opposed to DSRC.=20 On Jun 25, 2018, at 4:33 AM, Alexandre Petrescu = wrote: We had an internal discussion about what means 'LTE-V2X'. I may be very wrong about this, but this is where I am: The term 'LTE-V2X' is not defined. I pretend that 'LTE-V2X' is when a car sends CAM messages over UDP over = IPv6 to an IoT platform in the cloud, or to another car via LTE. Is this wrong? Alex _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_006F_01D40CA0.00FF77B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

HI Alex, =C2=A0Sri,

 

The =E2=80=98V2X=E2=80=99 is a =E2=80=98function=E2=80=99 part of the = 3GPP specification. And LTE means =E2=80=98not 5G=E2=80=99=E2=80=A6(just = to avoid confusion with future 5G-V2X)=E2=80=A6so, LTE-V2X actually = means: 3GPP rel.14 V2X communication.

 

The 3GPP rel.14 V2X specification does not say anything about what = type of message and under which =E2=80=98pipe=E2=80=99 (IP or non-IP), = not even the frequency band (yes, LTE-V2X PC5 is restricted to 5.9Ghz, = but not LTE-V2X Uu).

 

The only thing that the 3GPP rel.14 V2X provides is the availability = of a non-IP packet format for the negotiation of the radio bearers = (unlike LTE D2D, which only allows IPv4 and IPv6), as well as = semi-persistent scheduling opportunities (which LTE-D2D does not = offer)..and additionally, the fact that you bypass the Discovery phase = of the LTE-D2D (another limitation of the rel.14 version..). =

 

What LTE-V2X also does not say is the type of V2X. You would need to = add mode 3 (D2D infrastructure) or mode 4 (D2D ad-hoc) to be complete. = And you would also have the LTE-V2X Uu, which is actually the = V2I=E2=80=A6and indeed, in that case, I assume (but did not formally = check) that it is IP (I would even guess IPv4 and IPv6). =

 

And we also need to specify the level of the 3GPP LTE-V2X. so far, I = only mentioned the Access Stratum, but you also have LTE-V2X functions = at the NAS (non-access stratum)=E2=80=A6

 

In both cases, nothing is said about the type of message, for a = simple reason that a message is only seen by the LTE-V2X = =E2=80=98stack=E2=80=99 as a Logical Channels (and Radio = Bearers)...

 

So, the term =E2=80=98LTE-V2X=E2=80=99 is actually specified by 3GPP = as one ProSe (Proximity Service) function (a bit like Public Safety or = Device-to-Device)=E2=80=A6maybe to make an analogy, it could be seem = similarly to the OCB in IEEE=E2=80=A6OCB is a tag to modify the behavior = of a standard to reflex a type of = communication=E2=80=A6

 

So, LTE-V2X by itself, it does not mean much. We need to add further = details:

-          = V2V: LTE-V2X mode 3 (or mode 4) under IPv6 (or under geonet/WSM) = transmitting CAM (with this, we have no doubt on what and under which = frequency)

-          = V2V: LTE-V2X mode 4 (or mode 3) under WSM transmitting = CAM

-          = V2I: LTE-V2X Uu under IPv6 transmitting = HD-Maps

 

So, summarizing, LTE-V2X means (by shortcutting the 3GPP rel.14 in = front) the V2X functions, but if we want to be absolutely clear (and = usually we need J), just saying: we use LTE-V2X is indeed not sufficiently defined = !!

 

@Alex: now for your statement, it is a bit confusing=E2=80=A6you = should differentiate the communication type: CAM being sent over UDP / = IP to an IoT platform would then be a *LTE-V2X Uu sent on the 3.4GHz = frequency band* (as I do not think it is allowed to transmit V2X = messages over the Uu interface at 5.9Ghz). And CAM being sent over = UDP/IP to another car is the *LTE-V2X PC5 sent over the 5.9Ghz*. = As you can see, both means fully different = things=E2=80=A6

 

And as I am sure you will mention this=E2=80=A6yes, you can transmit = CAM over IPv6 in both PC5 or Uu J =E2=80=A6at least from 3GPP perspective=E2=80=A6, but I am sure that = either IEEE WAVE or ETSI ITS might but the same restrictions at ITS-G5 = J

 

BR,

 

J=C3=A9r=C3=B4me

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Sri Gundavelli = (sgundave)
Sent: Monday 25 June 2018 15:25
To: = Alexandre Petrescu
Cc: its@ietf.org
Subject: Re: = [ipwave] Argument about 'LTE-V2X' = term

 

 I = would read this term as, V2X communication based on 3GPP LTE = infrastructure. Its not only about CAM messages, but any safety related = V2V/V2I/V2P communications over LTE infra, as opposed to = DSRC. 


On Jun 25, 2018, at 4:33 AM, = Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:

We had an internal = discussion about what means 'LTE-V2X'.

I may be very wrong = about this, but this is where I am:

The term 'LTE-V2X' = is not defined.

I pretend that = 'LTE-V2X' is when a car sends CAM messages over UDP over IPv6 to an IoT = platform in the cloud, or to another car via = LTE.

Is this = wrong?

Alex

_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/m= ailman/listinfo/its

------=_NextPart_000_006F_01D40CA0.00FF77B0-- From nobody Mon Jun 25 08:01:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8585A130EA9 for ; Mon, 25 Jun 2018 08:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0idKwF4ERghT for ; Mon, 25 Jun 2018 08:01:03 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BD3130EDD for ; Mon, 25 Jun 2018 08:01:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5PF0vqc046450; Mon, 25 Jun 2018 17:00:57 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 715192040CB; Mon, 25 Jun 2018 17:00:57 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 60F69205094; Mon, 25 Jun 2018 17:00:57 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5PF0vwF001924; Mon, 25 Jun 2018 17:00:57 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Sri Gundavelli (sgundave)'" Cc: its@ietf.org References: <779f0c8b-df09-200d-ae4e-d8c72fb4f499@gmail.com> <006e01d40c8f$3d71ecc0$b855c640$@eurecom.fr> From: Alexandre Petrescu Message-ID: <8ae79eb0-018b-af13-9a17-523cb019199e@gmail.com> Date: Mon, 25 Jun 2018 17:00:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <006e01d40c8f$3d71ecc0$b855c640$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Argument about 'LTE-V2X' term X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 15:01:19 -0000 Le 25/06/2018 à 16:17, Jérôme Härri a écrit : [...]> So, summarizing, LTE-V2X means (by shortcutting the 3GPP rel.14 in > front) the V2X functions, but if we want to be absolutely clear (and > usually we need J), just saying: we use LTE-V2X is indeed not > sufficiently defined !! In private we tried to find a 3GPP document that defines the term 'LTE-V2X' but we couldnt. We did find a 5GAA document that uses 'LTE-V2X' throughout. Yet 5GAA is not 3GPP. If one has a 3GPP document that defines the term 'LTE-V2X' then I would be grateful. > @Alex: now for your statement, it is a bit confusing…you should > differentiate the communication type: CAM being sent over UDP / IP to an > IoT platform would then be a **LTE-V2X Uu sent on the 3.4GHz frequency > band** (as I do not think it is allowed to transmit V2X messages over > the Uu interface at 5.9Ghz). And CAM being sent over UDP/IP to another > car is the **LTE-V2X PC5 sent over the 5.9Ghz**. As you can see, both > means fully different things… I agree with the clarification. I would first need to understand whether or not 3GPP defines the term 'LTE-V2X'. For the other distinction (Uu to cloud, PC5 to car) - it is indeed a right distinction. But you could also have a car that sends a CAM/IP up an Uu and down another Uu to reach a car: V-Uu-Uu-V. No? Alex > > And as I am sure you will mention this…yes, you can transmit CAM over > IPv6 in both PC5 or Uu J…at least from 3GPP perspective…, but I am sure > that either IEEE WAVE or ETSI ITS might but the same restrictions at > ITS-G5 J > > BR, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Sri Gundavelli > (sgundave) > *Sent:* Monday 25 June 2018 15:25 > *To:* Alexandre Petrescu > *Cc:* its@ietf.org > *Subject:* Re: [ipwave] Argument about 'LTE-V2X' term > >  I would read this term as, V2X communication based on 3GPP LTE > infrastructure. Its not only about CAM messages, but any safety related > V2V/V2I/V2P communications over LTE infra, as opposed to DSRC. > > > On Jun 25, 2018, at 4:33 AM, Alexandre Petrescu > > wrote: > > We had an internal discussion about what means 'LTE-V2X'. > > I may be very wrong about this, but this is where I am: > > The term 'LTE-V2X' is not defined. > > I pretend that 'LTE-V2X' is when a car sends CAM messages over UDP > over IPv6 to an IoT platform in the cloud, or to another car via LTE. > > Is this wrong? > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Tue Jun 26 02:06:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2210A130934 for ; Tue, 26 Jun 2018 02:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li4_kBiv2yDQ for ; Tue, 26 Jun 2018 02:06:30 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E681130F80 for ; Tue, 26 Jun 2018 02:06:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5Q96Pgu047499; Tue, 26 Jun 2018 11:06:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6157F202A04; Tue, 26 Jun 2018 11:06:25 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4F2582025CF; Tue, 26 Jun 2018 11:06:25 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5Q96PxZ012032; Tue, 26 Jun 2018 11:06:25 +0200 To: langziwumingzhimi@sina.com, =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Sri Gundavelli (sgundave)'" Cc: its References: <20180626013223.5C7DCAC00C1@webmail.sinamail.sina.com.cn> From: Alexandre Petrescu Message-ID: Date: Tue, 26 Jun 2018 11:06:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180626013223.5C7DCAC00C1@webmail.sinamail.sina.com.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] =?utf-8?b?5Zue5aSN77yaUmU6ICBBcmd1bWVudCBhYm91dCAnTFRF?= =?utf-8?q?-V2X=27_term?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 09:06:32 -0000 Hello Minpeng, Thank you for the references. Le 26/06/2018 à 03:32, langziwumingzhimi@sina.com a écrit : > You can find V2X abbreviation definition in 3GPP TS 22.185. That > specification is used to define requirement of LTE V2X: "... provides > 3GPP support for V2X service requirements to be supported by LTE transport." I downloaded the document. It does not seem to define the term 'LTE-V2X'. It does however define formally, in its Definitions and Abbreviations sections, other terms like 'Road Side Unit','Pseudonimity' and 'V2X'. For 'V2X', it says 'Vehicle-to-Everything'. This definition in particular could be further discussed. Because some people use 'V2X' to mean _one_ of 'V2V' or 'V2P' (like in classical computing: 'X' is a variable and could have a single value which could be 'V' or 'P', but not the two at the same time like in quantum computing). And 'Everything' means everything at the same time, like when sending a datagram to everyone else in multicast mode. But back to my need of 'LTE-V2X'. At this point, I strongly believe that whenever we hear 'LTE-V2X' it is a colloquial term common in conversation. It is not a formally defined term. It is a little bit like the term 'core network'. The advantage of such term defined in a colloquial manner is that it can mean whatever the speaker wants it to mean. If I designate 'LTE-V2X' to mean CAM-as-XER-over-UDP-over-IP from a car to another car, now I dont think I am incorrect. Unless, of course, some people oppose it, or prefer a more refined definition to cover also, e.g., BSM or DENM or SPAT; and maybe not just XER but also JSON. And so on. But really, at this time, there is no formal definition of 'LTE-V2X'. This does not mean 'LTE-V2X' does not exist: there are multiple demonstrated prototypes that send CAMs over LTE, but just the term definition does not exist. > There are series technical reports and specifications related to LTE > V2X. TS22.185, TS23.185, TS 33.185 are specifications for system > requirements, architecture and security part. For radio specification, > V2X will be a feature and be defined in several TSs, such as TS > 36.21x(x=1,2,3,4,6), TS 36.321, TS 36.331, etc. Thank you for references. > @alex, for your last question, yes there are two ways for V2V/V2I/V2P > communication. One way is directly communication, i.e. through PC5 > interface. And the other is through LTE-Uu interface, which is usually > be called (unofficially) as V2N2V, V2N2I, V2N2P. Related definition can > be found in TS22.185 "Such 3GPP transport includes the transport between > UEs directly and/or, due to the limited direct communication range, the > transport between UEs via infrastructure supporting V2X communication, > e.g., RSU, application server, etc." Thank you, I looked. It is as you say; but just not defining 'V2N2V'. It is a term that you may use in a colloquial manner with other people. And you may understand each other correctly. But it is not formally defined. In particular, I dont understand you :-) Alex > > BRs, > Minpeng > > ----- 原始邮件 ----- > 发件人:Alexandre Petrescu > 收件人:Jérôme Härri , "'Sri Gundavelli > (sgundave)'" > 抄送人:its@ietf.org > 主题:Re: [ipwave] Argument about 'LTE-V2X' term > 日期:2018年06月25日 23点01分 > > > Le 25/06/2018 à 16:17, Jérôme Härri a écrit : > [...]> So, summarizing, LTE-V2X means (by shortcutting the 3GPP rel.14 in > > front) the V2X functions, but if we want to be absolutely clear (and > > usually we need J), just saying: we use LTE-V2X is indeed not > > sufficiently defined !! > In private we tried to find a 3GPP document that defines the term > 'LTE-V2X' but we couldnt. We did find a 5GAA document that uses > 'LTE-V2X' throughout. Yet 5GAA is not 3GPP. > If one has a 3GPP document that defines the term 'LTE-V2X' then I would > be grateful. > > @Alex: now for your statement, it is a bit confusing…you should > > differentiate the communication type: CAM being sent over UDP / IP to an > > IoT platform would then be a **LTE-V2X Uu sent on the 3.4GHz frequency > > band** (as I do not think it is allowed to transmit V2X messages over > > the Uu interface at 5.9Ghz). And CAM being sent over UDP/IP to another > > car is the **LTE-V2X PC5 sent over the 5.9Ghz**. As you can see, both > > means fully different things… > I agree with the clarification. > I would first need to understand whether or not 3GPP defines the term > 'LTE-V2X'. > For the other distinction (Uu to cloud, PC5 to car) - it is indeed a > right distinction. But you could also have a car that sends a CAM/IP up > an Uu and down another Uu to reach a car: V-Uu-Uu-V. No? > Alex > > > > And as I am sure you will mention this…yes, you can transmit CAM over > > IPv6 in both PC5 or Uu J…at least from 3GPP perspective…, but I am sure > > that either IEEE WAVE or ETSI ITS might but the same restrictions at > > ITS-G5 J > > > > BR, > > > > Jérôme > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Sri Gundavelli > > (sgundave) > > *Sent:* Monday 25 June 2018 15:25 > > *To:* Alexandre Petrescu > > *Cc:* its@ietf.org > > *Subject:* Re: [ipwave] Argument about 'LTE-V2X' term > > > >  I would read this term as, V2X communication based on 3GPP LTE > > infrastructure. Its not only about CAM messages, but any safety related > > V2V/V2I/V2P communications over LTE infra, as opposed to DSRC. > > > > > > On Jun 25, 2018, at 4:33 AM, Alexandre Petrescu > > > > wrote: > > > > We had an internal discussion about what means 'LTE-V2X'. > > > > I may be very wrong about this, but this is where I am: > > > > The term 'LTE-V2X' is not defined. > > > > I pretend that 'LTE-V2X' is when a car sends CAM messages over UDP > > over IPv6 to an IoT platform in the cloud, or to another car via LTE. > > > > Is this wrong? > > > > Alex > > > > _______________________________________________ > > 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 Tue Jun 26 02:08:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A601130EC4 for ; Tue, 26 Jun 2018 02:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.267 X-Spam-Level: X-Spam-Status: No, score=0.267 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJfdsEHjPJR9 for ; Tue, 26 Jun 2018 02:08:13 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429EE130934 for ; Tue, 26 Jun 2018 02:08:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5Q988l9044265; Tue, 26 Jun 2018 11:08:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9DB27202A8E; Tue, 26 Jun 2018 11:08:08 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 817A5201531; Tue, 26 Jun 2018 11:08:08 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5Q988EQ013453; Tue, 26 Jun 2018 11:08:08 +0200 To: langziwumingzhimi@sina.com, =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Sri Gundavelli (sgundave)'" Cc: its References: <20180626024746.BED144C0CB5@webmail.sinamail.sina.com.cn> From: Alexandre Petrescu Message-ID: Date: Tue, 26 Jun 2018 11:08:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180626024746.BED144C0CB5@webmail.sinamail.sina.com.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] =?utf-8?b?5Zue5aSN77ya5Zue5aSN77yaUmU6ICBBcmd1bWVudCBh?= =?utf-8?q?bout_=27LTE-V2X=27_term?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 09:08:15 -0000 Le 26/06/2018 à 04:47, langziwumingzhimi@sina.com a écrit : > TS 23.285 Thank you. It does not define 'LTE-V2X'. Alex From nobody Tue Jun 26 05:10:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0876130DCD for ; Tue, 26 Jun 2018 05:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpHEfLVEmP5D for ; Tue, 26 Jun 2018 05:10:22 -0700 (PDT) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id DA603130DC2 for ; Tue, 26 Jun 2018 05:10:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,274,1526335200"; d="scan'208,217";a="7661248" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 26 Jun 2018 14:10:18 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 8F892D0A; Tue, 26 Jun 2018 14:10:18 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , , "'Sri Gundavelli \(sgundave\)'" Cc: "'its'" References: <20180626013223.5C7DCAC00C1@webmail.sinamail.sina.com.cn> In-Reply-To: Date: Tue, 26 Jun 2018 14:10:18 +0200 Organization: EURECOM Message-ID: <012b01d40d46$a6147f60$f23d7e20$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012C_01D40D57.69A23160" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJnGVvGjz+1sIzPfeUJTEiwPs2rqQI4JXDJozqLkNA= Archived-At: Subject: Re: [ipwave] =?utf-8?b?5Zue5aSN77yaUmU6ICBBcmd1bWVudCBhYm91dCAnTFRF?= =?utf-8?q?-V2X=27_term?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 12:10:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012C_01D40D57.69A23160 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Alex, =20 For once, I think we should not seek too complex answers. From a 3GPP = perspective, LTE-V2X does not need to be defined because it kind of = is...by default (in the 3GPP community).=20 =20 So, in one line answer: LTE means '4G' and V2X means = 'Vehicle-to-Everything'. So, LTE-V2X is 4G technology for = Vehicle-to-Everything...period. And as what is above PDCP is IP, then = whatever is higher than PDCP (kind of L2++) does not need to be = specified...then you no specification on what/how to use it...(for once = a nice Layer Separation :-) ) =20 Now, for more details...As you mentioned, the 'V2X' term means what 3GPP = defined as Vehicle-to-Everything and this, from a 'service perspective' = (Proximity Service, which is the heard of the V2X/Sidelink/PC5 = enhancements). So, it truly does not matter if it goes direct, over eNB, = over a MEC, if you use a CAM, smoke signals or even morse code...etc.. =20 Yet, 3GPP uses V2X as a mean of a specific operation of the traditional = cellular system...as I said, it is very similar to saying OCB (and you = have all variations of OCB)..So, you will see 'V2X functions', 'V2X = Services', etc.. everywhere in 3GPP, as it simply means that as V2X = requires the cellular system to operate differently, we need specific = functions or 'code' to let people know we deal with a different = operation (another example is Public Safety (PS)..similar meaning).=20 =20 So, you are right...LTE-V2X means various things, and you are correct, = you can use it for your various use cases...all are correct...but it = might make your life a bit harder, as now, you will need to define it = yourself (explaining on which pipe, which frequency, which interface = (PC5, Uu), which mode, ... =20 But let's take a different approach...what does it 'not' mean: =20 - it DOES NOT mean anything related to 3GPP 5G rel.15 and up on = 'ANYTHING' in these specs...(this is particularly important when = considering the V2X 'scheduler', which is limited LTE-V2X but will be = improved in 5G-V2X). As I said, although never written in 3GPP, the LTE = actually refers to the 4G system..it is kind of a naming type, nothing = else. =20 - it DOES NOT apply for autonomous driving, platooning or safety of = vulnerable road users. As the definitions of the phases, LTE-V2X applies = to DAY ONE applications (safety) and 5G-V2X will apply to DAY 2 (you can = see that on the various 5G documents, like TS 22.186 (rel. 15)). = Actually, you may use LTE-V2X for Day2, but the chip manufacturers = acknowledged a limited capacity and delay that can only be solved by = 5G-V2X. =20 - it DOES NOT allow D2D Service Discovery (but 5G-V2X might)...the V2X = function is assumed to be 'the' service. So, the whole Sidelink = processes only rely on SL-control, SL-data (and SL-broadcast for = synchronization) =20 - it DOES NOT allow D2D Unicast communication (but 5G-V2X might) =20 - it DOES NOT assume anything above PDCP...(you basically get an IP or a = WSM/Geonet interface on your linux system)....so, as IP is 'de facto = standard', anything that can go on IP is good for LTE-V2X...So, you can = use JSON, XML, XER...and also CAM or anything else...it does not matter, = as long as the PDCP (and RRC) can get a LC and a RB. Even if in theory, = you could do IPv6-over-PC5 (so LTE-V2V using IP), the process to = configure the IP address considering only broadcast communication = is...'complicated'...that is why 3GPP allowed a non-IP stack to = configure the PC5 link (btw, if this an IPv6 =E2=80=98link=E2=80=99 = configuration only relying on broadcast communication=E2=80=A6so a = broadcast IP link=E2=80=A6) specification would need to be defined, and = it would certainly NOT be done by 3GPP but by IETF=E2=80=A6). =20 - it DOES NOT only apply to 5.9GHz and WILL NOT be free for everything. = The LTE-V2X Uu is rather expected to rely on 3.4Ghz, and this will be a = commercial band...so, any LTE-V2X-Uu will most likely need to be 'paid' = for by one way or another. This comes from the 5.9Ghz V2V restrictions = provided in both EU and US regulations (the spectrum is provided for = direct V2V communication). But maybe 5GAA has a better marketing way of = describing this... =20 Maybe another aspect. The LTE-V2X has the V2X communication profile = defined: LTE-V2X PC5 is on 5.9Ghz and LTE-V2X Uu is on 3.4-3.7Ghz. = Considering your target application, you seems to be using Uu, then you = might not have to bother (and even need to discuss) with the ITS guys, = as Uu is not meant for 5.9Ghz...so, no issue about what to do or what to = transmit (IP or not IP...)..that is the nice aspect...now, the less nice = aspect is it is really not clear when, who and how the 3.4-3.7Ghz will = be made available by the operators...But if you want to transmit CAM = with IP over the PC5 interface, it is =E2=80=98very=E2=80=99 highly = likely that this will be restricted in one wat or another again by US or = EU regulations=E2=80=A6(exactly as ITS-G5). =20 But one question that you might want to get answered, is what Cellular = V2X (C-V2X) actually mean...as for mode 4, there is no cellular, no SIM = card, no concept of eNB and even the scheduler is standardized and = collision-prone...far from a typical cellular technology. Considering = this is the deployed V2X for critical V2V communication, I think this US = naming is awkward... =20 Alternatively, LTE-V is also weird to me as it looks like a 'vehicular = LTE', which might not always be the case...(you can have LTE-V for = pedestrian...or even for trains). =20 BR, =20 J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Tuesday 26 June 2018 11:06 To: langziwumingzhimi@sina.com; J=C3=A9r=C3=B4me H=C3=A4rri; 'Sri = Gundavelli (sgundave)' Cc: its Subject: Re: =E5=9B=9E=E5=A4=8D=EF=BC=9ARe: [ipwave] Argument about = 'LTE-V2X' term =20 Hello Minpeng, =20 Thank you for the references. =20 Le 26/06/2018 =C3=A0 03:32, = langziwumingzhimi@sina.com a =C3=A9crit : > You can find V2X abbreviation definition in 3GPP TS 22.185. That=20 > specification is used to define requirement of LTE V2X: "... provides=20 > 3GPP support for V2X service requirements to be supported by LTE = transport." =20 I downloaded the document. It does not seem to define the term = 'LTE-V2X'. It does however define formally, in its Definitions and = Abbreviations sections, other terms like 'Road Side Unit','Pseudonimity' = and 'V2X'. =20 For 'V2X', it says 'Vehicle-to-Everything'. This definition in = particular could be further discussed. Because some people use 'V2X' to = mean _one_ of 'V2V' or 'V2P' (like in classical computing: 'X' is a = variable and could have a single value which could be 'V' or 'P', but = not the two at the same time like in quantum computing). And = 'Everything' means everything at the same time, like when sending a = datagram to everyone else in multicast mode. =20 But back to my need of 'LTE-V2X'. =20 At this point, I strongly believe that whenever we hear 'LTE-V2X' it is = a colloquial term common in conversation. It is not a formally defined = term. It is a little bit like the term 'core network'. =20 The advantage of such term defined in a colloquial manner is that it can = mean whatever the speaker wants it to mean. =20 If I designate 'LTE-V2X' to mean CAM-as-XER-over-UDP-over-IP from a car = to another car, now I dont think I am incorrect. Unless, of course, = some people oppose it, or prefer a more refined definition to cover = also, e.g., BSM or DENM or SPAT; and maybe not just XER but also JSON.=20 And so on. =20 But really, at this time, there is no formal definition of 'LTE-V2X'. =20 This does not mean 'LTE-V2X' does not exist: there are multiple = demonstrated prototypes that send CAMs over LTE, but just the term = definition does not exist. =20 > There are series technical reports and specifications related to LTE=20 > V2X. TS22.185, TS23.185, TS 33.185 are specifications for system=20 > requirements, architecture and security part. For radio specification, = > V2X will be a feature and be defined in several TSs, such as TS=20 > 36.21x(x=3D1,2,3,4,6), TS 36.321, TS 36.331, etc. =20 Thank you for references. =20 > @alex, for your last question, yes there are two ways for V2V/V2I/V2P=20 > communication. One way is directly communication, i.e. through PC5=20 > interface. And the other is through LTE-Uu interface, which is usually = > be called (unofficially) as V2N2V, V2N2I, V2N2P. Related definition=20 > can be found in TS22.185 "Such 3GPP transport includes the transport=20 > between UEs directly and/or, due to the limited direct communication=20 > range, the transport between UEs via infrastructure supporting V2X=20 > communication, e.g., RSU, application server, etc." =20 Thank you, I looked. It is as you say; but just not defining 'V2N2V'.=20 It is a term that you may use in a colloquial manner with other people.=20 And you may understand each other correctly. But it is not formally = defined. In particular, I dont understand you :-) =20 Alex =20 >=20 > BRs, > Minpeng >=20 > ----- =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 ----- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AAlexandre Petrescu < = alexandre.petrescu@gmail.com> > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AJ=C3=A9r=C3=B4me H=C3=A4rri < = jerome.haerri@eurecom.fr>, "'Sri = Gundavelli=20 > (sgundave)'" < = sgundave=3D40cisco.com@dmarc.ietf.org> > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9A = its@ietf.org > =E4=B8=BB=E9=A2=98=EF=BC=9ARe: [ipwave] Argument about 'LTE-V2X' term > =E6=97=A5=E6=9C=9F=EF=BC=9A2018=E5=B9=B406=E6=9C=8825=E6=97=A5 = 23=E7=82=B901=E5=88=86 >=20 >=20 > Le 25/06/2018 =C3=A0 16:17, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > [...]> So, summarizing, LTE-V2X means (by shortcutting the 3GPP rel.14 = > in > front) the V2X functions, but if we want to be absolutely clear=20 > (and > usually we need J), just saying: we use LTE-V2X is indeed not = > > sufficiently defined !! > In private we tried to find a 3GPP document that defines the term=20 > 'LTE-V2X' but we couldnt. We did find a 5GAA document that uses=20 > 'LTE-V2X' throughout. Yet 5GAA is not 3GPP. > If one has a 3GPP document that defines the term 'LTE-V2X' then I=20 > would be grateful. > > @Alex: now for your statement, it is a bit confusing=E2=80=A6you = should >=20 > differentiate the communication type: CAM being sent over UDP / IP to=20 > an > IoT platform would then be a **LTE-V2X Uu sent on the 3.4GHz=20 > frequency > band** (as I do not think it is allowed to transmit V2X=20 > messages over > the Uu interface at 5.9Ghz). And CAM being sent over=20 > UDP/IP to another > car is the **LTE-V2X PC5 sent over the 5.9Ghz**.=20 > As you can see, both > means fully different things=E2=80=A6 I agree = with the=20 > clarification. > I would first need to understand whether or not 3GPP defines the term=20 > 'LTE-V2X'. > For the other distinction (Uu to cloud, PC5 to car) - it is indeed a=20 > right distinction. But you could also have a car that sends a CAM/IP=20 > up an Uu and down another Uu to reach a car: V-Uu-Uu-V. No? > Alex > > > > And as I am sure you will mention this=E2=80=A6yes, you can = transmit CAM=20 > over > IPv6 in both PC5 or Uu J=E2=80=A6at least from 3GPP = perspective=E2=80=A6, but=20 > I am sure > that either IEEE WAVE or ETSI ITS might but the same=20 > restrictions at > ITS-G5 J > > BR, > > J=C3=A9r=C3=B4me > > = *From:*its=20 > [ mailto:its-bounces@ietf.org] *On = Behalf Of *Sri Gundavelli >=20 > (sgundave) > *Sent:* Monday 25 June 2018 15:25 > *To:* Alexandre=20 > Petrescu > *Cc:* its@ietf.org > *Subject:* = Re: [ipwave] Argument=20 > about 'LTE-V2X' term > > I would read this term as, V2X=20 > communication based on 3GPP LTE > infrastructure. Its not only about=20 > CAM messages, but any safety related > V2V/V2I/V2P communications=20 > over LTE infra, as opposed to DSRC. > > > > > > On Jun 25, 2018, at 4:33 AM, Alexandre Petrescu >=20 > < = alexandre.petrescu@gmail.com = > > wrote: > > > > We had an internal discussion about what means 'LTE-V2X'. > > > > I may be very wrong about this, but this is where I am: > > > > The term 'LTE-V2X' is not defined. > > > > I pretend that 'LTE-V2X' is when a car sends CAM messages over UDP = > > over IPv6 to an IoT platform in the cloud, or to another car via = LTE. > > > > Is this wrong? > > > > Alex > > > > _______________________________________________ > > its mailing list > > its@ietf.org < = mailto:its@ietf.org> > > = https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ > its mailing list > its@ietf.org > = https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_012C_01D40D57.69A23160 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello = Alex,

 

For once, I think we should not seek too complex = answers. From a 3GPP perspective, LTE-V2X does not need to be defined = because it kind of is...by default (in the 3GPP community). =

 

So, in one line answer: LTE means '4G' and V2X = means 'Vehicle-to-Everything'. So, LTE-V2X is 4G technology for = Vehicle-to-Everything...period. And as what is above PDCP is IP, then = whatever is higher than PDCP (kind of L2++) does not need to be = specified...then you no specification on what/how to use it...(for once = a nice Layer Separation :-) )

 

Now, = for more details...As you mentioned, the 'V2X' term means what 3GPP = defined as Vehicle-to-Everything and this, from a 'service perspective' = (Proximity Service, which is the heard of the V2X/Sidelink/PC5 = enhancements). So, it truly does not matter if it goes direct, over eNB, = over a MEC, if you use a CAM, smoke signals or even morse = code...etc..

 

Yet, = 3GPP uses V2X as a mean of a specific operation of the traditional = cellular system...as I said, it is very similar to saying OCB (and you = have all variations of OCB)..So, you will see 'V2X functions', 'V2X = Services', etc.. everywhere in 3GPP, as it simply means that as V2X = requires the cellular system to operate differently, we need specific = functions or 'code' to let people know we deal with a different = operation (another example is Public Safety (PS)..similar meaning). =

 

So, you are right...LTE-V2X means various things, = and you are correct, you can use it for your various use cases...all are = correct...but it might make your life a bit harder, as now, you will = need to define it yourself (explaining on which pipe, which frequency, = which interface (PC5, Uu), which mode, ...

 

But = let's take a different approach...what does it 'not' = mean:

 

- it DOES NOT mean anything related to 3GPP 5G = rel.15 and up on 'ANYTHING' in these specs...(this is particularly = important when considering the V2X 'scheduler', which is limited LTE-V2X = but will be improved in 5G-V2X). As I said, although never written in = 3GPP, the LTE actually refers to the 4G system..it is kind of a naming = type, nothing else.

 

- it = DOES NOT apply for autonomous driving, platooning or safety of = vulnerable road users. As the definitions of the phases, LTE-V2X = applies to DAY ONE applications (safety) and 5G-V2X will apply to DAY 2 = (you can see that on the various 5G documents, like =C2=A0TS 22.186 = (rel. 15)). Actually, you may use LTE-V2X for Day2, but the chip = manufacturers acknowledged a limited capacity and delay that can only be = solved by 5G-V2X.

 

- it = DOES NOT allow D2D Service Discovery (but 5G-V2X might)...the V2X = function is assumed to be 'the' service. So, the whole Sidelink = processes only rely on SL-control, SL-data (and SL-broadcast for = synchronization)

 

- it = DOES NOT allow D2D Unicast communication (but 5G-V2X = might)

 

- it DOES NOT assume anything above PDCP...(you = basically get an IP or a WSM/Geonet interface on your linux = system)....so, as IP is 'de facto standard', anything that can go on IP = is good for LTE-V2X...So, you can use JSON, XML, XER...and also CAM or = anything else...it does not matter, as long as the PDCP (and RRC) can = get a LC and a RB. Even if in theory, you could do IPv6-over-PC5 (so = LTE-V2V using IP), the process to configure the IP address considering = only broadcast communication is...'complicated'...that is why 3GPP = allowed a non-IP stack to configure the PC5 link (btw, if this an IPv6 = =E2=80=98link=E2=80=99 configuration only relying on broadcast = communication=E2=80=A6so a broadcast IP link=E2=80=A6) specification = would need to be defined, and it would certainly NOT be done by 3GPP but = by IETF=E2=80=A6).

 

- it = DOES NOT only apply to 5.9GHz and WILL NOT=C2=A0 be free for everything. = The LTE-V2X Uu is rather expected to rely on 3.4Ghz, and this will be a = commercial band...so, any LTE-V2X-Uu will most likely need to be 'paid' = for by one way or another. This comes from the 5.9Ghz V2V restrictions = provided in both EU and US regulations (the spectrum is provided for = direct V2V communication). But maybe 5GAA has a better marketing way of = describing this...

 

Maybe = another aspect. The LTE-V2X has the V2X communication profile defined: = LTE-V2X PC5 is on 5.9Ghz and LTE-V2X Uu is on 3.4-3.7Ghz. Considering = your target application, you seems to be using Uu, then you might not = have to bother (and even need to discuss) with the ITS guys, as Uu is = not meant for 5.9Ghz...so, no issue about what to do or what to transmit = (IP or not IP...)..that is the nice aspect...now, the less nice aspect = is it is really not clear when, who and how the 3.4-3.7Ghz will be made = available by the operators...But if you want to transmit CAM with IP = over the PC5 interface, it is =E2=80=98very=E2=80=99 highly likely that = this will be restricted in one wat or another again by US or EU = regulations=E2=80=A6(exactly as ITS-G5).

 

But = one question that you might want to get answered, is what Cellular V2X = (C-V2X) actually mean...as for mode 4, there is no cellular, no SIM = card, no concept of eNB and even the scheduler is standardized and = collision-prone...far from a typical cellular technology. Considering = this is the deployed V2X for critical V2V communication, I think this US = naming is awkward...

 

Alternatively, LTE-V is also weird to me as it = looks like a 'vehicular LTE', which might not always be the case...(you = can have LTE-V for pedestrian...or even for trains).

 

BR,

 

J=C3=A9r=C3=B4me

-----Original Message-----
From: Alexandre = Petrescu [mailto:alexandre.petrescu@gmail.com]
Sent: Tuesday 26 June = 2018 11:06
To: langziwumingzhimi@sina.com; J=C3=A9r=C3=B4me = H=C3=A4rri; 'Sri Gundavelli (sgundave)'
Cc: its
Subject: Re: =E5=9B=9E=E5=A4=8D=EF=BC=9ARe: = [ipwave] Argument about 'LTE-V2X' term

 

Hello = Minpeng,

 

Thank you for the references.

 

Le = 26/06/2018 =C3=A0 03:32, langziwumingzhimi@sina.co= m a =C3=A9crit :

> You can find V2X abbreviation definition in = 3GPP TS 22.185. That

> = specification is used to define requirement of LTE V2X: "... = provides

> 3GPP support for = V2X service requirements to be supported by LTE = transport."

 

I = downloaded the document.=C2=A0 It does not seem to define the term = 'LTE-V2X'.=C2=A0 It does however define formally, in its Definitions and = Abbreviations sections, other terms like 'Road Side Unit','Pseudonimity' =

and 'V2X'.

 

For = 'V2X', it says 'Vehicle-to-Everything'.=C2=A0 This definition in = particular could be further discussed.=C2=A0 Because some people use = 'V2X' to mean _one_ of 'V2V' or 'V2P' (like in classical computing: 'X' = is a variable and could have a single value which could be 'V' or 'P', = but not the two at the same time like in quantum computing).=C2=A0 And = 'Everything' means everything at the same time, like=C2=A0 when sending = a datagram to everyone else in multicast mode.

 

But = back to my need of 'LTE-V2X'.

 

At = this point, I strongly believe that whenever we hear 'LTE-V2X' it is a = colloquial term common in conversation.=C2=A0 It is not a formally = defined term. It is a little bit like the term 'core = network'.

 

The advantage of such term defined in a colloquial = manner is that it can mean whatever the speaker wants it to = mean.

 

If I designate 'LTE-V2X' to mean = CAM-as-XER-over-UDP-over-IP from a car to another car, now I dont think = I am incorrect.=C2=A0 Unless, of course, some people oppose it, or = prefer a more refined definition to cover also, e.g., BSM or DENM or = SPAT; and maybe not just XER but also JSON.

And so on.

 

But = really, at this time, there is no formal definition of = 'LTE-V2X'.

 

This does not mean 'LTE-V2X' does not exist: there = are multiple demonstrated prototypes that send CAMs over LTE, but just = the term definition does not exist.

 

> = There are series technical reports and specifications related to LTE =

> V2X. TS22.185, TS23.185, TS = 33.185 are specifications for system

> requirements, architecture and security part. = For radio specification,

> V2X = will be a feature and be defined in several TSs, such as TS =

> 36.21x(x=3D1,2,3,4,6), TS = 36.321, TS 36.331, etc.

 

Thank = you for references.

 

> = @alex, for your last question, yes there are two ways for V2V/V2I/V2P =

> communication. One way is = directly communication, i.e. through PC5

> interface. And the other is through LTE-Uu = interface, which is usually

> = be called (unofficially) as V2N2V, V2N2I, V2N2P. Related definition =

> can be found in TS22.185 = "Such 3GPP transport includes the transport

> between UEs directly and/or, due to the = limited direct communication

> = range, the transport between UEs via infrastructure supporting V2X =

> communication, e.g., RSU, = application server, etc."

 

Thank = you, I looked.=C2=A0 It is as you say; but just not defining 'V2N2V'. =

It is a term that you may use in = a colloquial manner with other people.

And you may understand each other correctly.=C2=A0 = But it is not formally defined.=C2=A0 In particular, I dont understand = you :-)

 

Alex

 

> =

> BRs,

> Minpeng

>

> = ----- =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 = -----

> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A= Alexandre Petrescu <alexandre.petrescu@gmail.= com>

> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AJ=C3=A9r=C3=B4me = H=C3=A4rri <jerome.haerri@eurecom.fr<= /span>>, "'Sri Gundavelli

> (sgundave)'" <sgundave=3D40cisco.com@dm= arc.ietf.org>

> = =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Aits@ietf.org

> =E4=B8=BB=E9=A2=98=EF=BC=9ARe: [ipwave] = Argument about 'LTE-V2X' term

> = =E6=97=A5=E6=9C=9F=EF=BC=9A2018=E5=B9=B406=E6=9C=8825=E6=97=A5 23=E7=82=B901=E5=88=86

>

> =

> Le 25/06/2018 =C3=A0 16:17, = J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit :

> [...]> So, summarizing, LTE-V2X means (by = shortcutting the 3GPP rel.14

> = in=C2=A0 > front) the V2X functions, but if we want to be absolutely = clear

> (and=C2=A0 > = usually we need J), just saying: we use LTE-V2X is indeed not=C2=A0 =

> > sufficiently defined = !!

> In private we tried to = find a 3GPP document that defines the term

> 'LTE-V2X' but we couldnt. We did find a 5GAA = document that uses

> 'LTE-V2X' = throughout. Yet 5GAA is not 3GPP.

> If one has a 3GPP document that defines the = term 'LTE-V2X' then I

> would = be grateful.

>=C2=A0 > = @Alex: now for your statement, it is a bit confusing=E2=80=A6you = should=C2=A0 >

> = differentiate the communication type: CAM being sent over UDP / IP to =

> an=C2=A0 > IoT platform = would then be a **LTE-V2X Uu sent on the 3.4GHz

> frequency=C2=A0 > band** (as I do not think = it is allowed to transmit V2X

> messages over=C2=A0 > the Uu interface at = 5.9Ghz). And CAM being sent over

> UDP/IP to another=C2=A0 > car is the = **LTE-V2X PC5 sent over the 5.9Ghz**.

> As you can see, both=C2=A0 > means fully = different things=E2=80=A6 I agree with the

> clarification.

> I would first need to understand whether or = not 3GPP defines the term

> = 'LTE-V2X'.

> For the other = distinction (Uu to cloud, PC5 to car) - it is indeed a

> right distinction. But you could also have a = car that sends a CAM/IP

> up = an Uu and down another Uu to reach a car: V-Uu-Uu-V. = No?

> Alex

>=C2=A0 >

>=C2=A0 > And as I am sure you will mention = this=E2=80=A6yes, you can transmit CAM

> over=C2=A0 > IPv6 in both PC5 or Uu = J=E2=80=A6at least from 3GPP perspective=E2=80=A6, but

> I am sure=C2=A0 > that either IEEE WAVE or = ETSI ITS might but the same

> = restrictions at=C2=A0 > ITS-G5 J=C2=A0 >=C2=A0 > BR,=C2=A0 = >=C2=A0 > J=C3=A9r=C3=B4me=C2=A0 >=C2=A0 > *From:*its =

> [mailto:its-bounces@ietf.o= rg] *On Behalf Of *Sri Gundavelli=C2=A0 > =

> (sgundave)=C2=A0 > = *Sent:* Monday 25 June 2018 15:25=C2=A0 > *To:* Alexandre =

> Petrescu=C2=A0 > *Cc:* its@ietf.org=C2= =A0 > *Subject:* Re: [ipwave] Argument

> about 'LTE-V2X' term=C2=A0 >=C2=A0 > =  I would read this term as, V2X

> communication based on 3GPP LTE=C2=A0 > = infrastructure. Its not only about

> CAM messages, but any safety related=C2=A0 = > V2V/V2I/V2P communications

> over LTE infra, as opposed to = DSRC.

>=C2=A0 = >

>=C2=A0 = >

>=C2=A0 > On Jun 25, = 2018, at 4:33 AM, Alexandre Petrescu=C2=A0 >

> <alexandre.petrescu@gmail.= com = <mailto:alexandre.petrescu@gmail.com>>

=

> wrote:

>=C2=A0 >

>=C2=A0 > We had an internal discussion about = what means 'LTE-V2X'.

>=C2=A0 = >

>=C2=A0 > I may be very = wrong about this, but this is where I am:

>=C2=A0 >

>=C2=A0 > The term 'LTE-V2X' is not = defined.

>=C2=A0 = >

>=C2=A0 > I pretend = that 'LTE-V2X' is when a car sends CAM messages over UDP=C2=A0 =

> > over IPv6 to an IoT = platform in the cloud, or to another car via LTE.

>=C2=A0 >

>=C2=A0 > Is this wrong?

>=C2=A0 >

>=C2=A0 > Alex

>=C2=A0 >

>=C2=A0 > = _______________________________________________

> =C2=A0> its mailing list

>=C2=A0 > its@ietf.org = <mailto:its@ietf.org>

>=C2=A0 > https://www.ietf.org/mail= man/listinfo/its

>=C2=A0 >

> = _______________________________________________

> its mailing list

> its@ietf.org

> https://www.ietf.org/mail= man/listinfo/its

------=_NextPart_000_012C_01D40D57.69A23160--