Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Fri, 03 September 2021 03:22 UTC
Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F2A3A07DB; Thu, 2 Sep 2021 20:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=0.542, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 9AJexVApFeFx; Thu, 2 Sep 2021 20:21:56 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 695533A07DA; Thu, 2 Sep 2021 20:21:55 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id m4so7384892ljq.8; Thu, 02 Sep 2021 20:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=61/Yg/CXA4PWjrpFiSrEKISAakX+Pc7+F+p2Oi9kmtY=; b=EF7xGZuFsvurbuttctlYV9g1mNuaZhi7o/joDjGK+3+ipeG+mOxH6qlLU0XdcPvr2j 8NsWq5GcDcnMSB5JD9AM+10+DWg3zyikuXNI8UUHLZeFu02AeXk//9b7HQbidTE47bPs 1Kr/cgCEYrrltG4tMWw7U4pZEk01ozt/ja2ydg1i4b8REilL/LBSUmXF7pYqWjwfQ61f G7CX3UWM9Q16wwhGlvCkuqNHqoij3JM6NcSFwce9Ar19tfl+7N2KfJsXAkw/KMV6QwRs EAg9n68XaATCucHhz5LRhlgtLs2ZW5vBE/ni/3DC1Jl+FD5V2Z4xukZ/GwF7flM68Wui ElgA==
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=61/Yg/CXA4PWjrpFiSrEKISAakX+Pc7+F+p2Oi9kmtY=; b=C7N9dZRFQoqGMlnfF6nlnyHflPe5QqkBGW/Fk7LKDoTnuoV466Dy5sqX5kOr4lsyqu c2BC7d/ZiZ9Y3rZJy8ebFy448XVg5bfjwz0veIYBVszkbFXUlSlLG/kzsLIxE2CUNLYr 05Th11PLVFypE4AnzCw4PK9MhqUtRfA2qtPndxqd/6pF2hbJTjDFDaxM3Or+6dZJFrta k0nlEo9NX4DgOwX6lDQVuo0ESKlQflOHf5tSx5wgiyv+Bvnqwg34qg0akqbUUspteE3D 1ZBUd40orFlFyExeO4RYz3oWn1BF7qTVz6P/tLpgKN1b8pMdiybs/M9z5rHZhWdhmNDJ HtWg==
X-Gm-Message-State: AOAM53327KojgG12wJ2DvZUm1mU66kJi13rBARpWDj63n6UpSCnDZPmv 5S58E24YHqTLd3B4/yH9ha6hEpZyGebi4jZ3j0U=
X-Google-Smtp-Source: ABdhPJx3BPbPBuv+oL2f1a1HW4pCUppELk20JNnjhceEb0tbeJDSCnN6iL6s5qjZ6/1gf9WFXdDvkNFrvbqIZTH7eso=
X-Received: by 2002:a2e:9205:: with SMTP id k5mr1191824ljg.26.1630639310783; Thu, 02 Sep 2021 20:21:50 -0700 (PDT)
MIME-Version: 1.0
References: <162400216663.17839.1738900015320888640@ietfa.amsl.com> <CAPK2DezN9benfLS9VQw1uS9cEXMQFjrs_m-jJu+3JtgCrfBWWQ@mail.gmail.com> <CO1PR11MB48811753BC5EC02469400262D8CE9@CO1PR11MB4881.namprd11.prod.outlook.com> <CAPK2Dewx-SVgA_DmGyL1ZwSLR+FxrF6q4iSyugOTEA5Xp=evGA@mail.gmail.com> <CO1PR11MB488133C0462CE5AE29F40082D8CE9@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488133C0462CE5AE29F40082D8CE9@CO1PR11MB4881.namprd11.prod.outlook.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Fri, 03 Sep 2021 12:21:14 +0900
Message-ID: <CAPK2DewwA65oywBP0SpQ10jLME39LJbVL_2aa=sXmV7DxkUGtw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>, Erik Kline <ek.ietf@gmail.com>
Cc: "int-dir@ietf.org" <int-dir@ietf.org>, Last Call <last-call@ietf.org>, "its@ietf.org" <its@ietf.org>, Russ Housley <housley@vigilsec.com>, Chris Shen <shenyiwen7@gmail.com>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e04a5805cb0ecc73"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/PPeapuk18ZAVlJFIQ-ICoEWiOG4>
X-Mailman-Approved-At: Thu, 02 Sep 2021 23:54:48 -0700
Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2021 03:22:08 -0000
Hi Pascal, Thanks for your help to improve this draft significantly. I have included your suggested text in the revision (-23) as follows: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-23 ---------------------------------------------------------------------------------------------------------------------------------------- Section 5.1.3. Routing ... RPL [RFC6550] defines a routing protocol for low-power and lossy networks, which constructs and maintains Destination-Oriented Directed Acyclic Graphs (DODAGs) optimized by an Objective Function (OF). A defined OF provides route selection and optimization within an RPL topology. A node in a DODAG discovers and maintains the upward routes toward the root node of the DODAG. RPL uses a Distance Vector (DV) approach, with lazy maintenance and stretched anisotropic routing. It is well-designed to reduce the topological knowledge and routing state that needs to be exchanged. As a result, the routing protocol overhead is minimized, which allows either highly constrained stable networks or less constrained, highly dynamic networks. Refer to Appendix B for the detailed description of RPL for multihop V2X networking. An address registration extension for 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) in [RFC8505] can support light-weight mobility for nodes moving through different parents. [RFC8505], as opposed to [RFC4861], is stateful and proactively installs the ND cache entries, which saves broadcasts and provides a deterministic presence information for IPv6 addresses. Mainly it updates the Address Registration Option (ARO) of ND defined in [RFC6775] to include a status field that can indicate the movement of a node and optionally a Transaction ID (TID) field, i.e., a sequence number that can be used to determine the most recent location of a node. Thus, RPL can use the information provided by the Extended ARO (EARO) defined in [RFC8505] to deal with a certain level of node mobility. When a leaf node moves to the coverage of another parent node, it should de-register its addresses to the previous parent node and register itself with a new parent node along with an incremented TID. ---------------------------------------------------------------------------------------------------------------------------------------- If you are satisfied with this revision, could you update the status of INTDIR Last Call Review into Ready? https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ Carlos and Erik, If Pascal confirms the readiness of this draft, let's move it out to the next step. Thanks. Best Regards, Paul On Fri, Sep 3, 2021 at 12:50 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > You did well Paul, but I wonder if the reader of section 5.1 really cares > about the guts of the protocols (DIO messages, who cares?) vs. what the > protocol is optimized for. > > > > I had the same feeling about the next paragraph where you describe 8505. > While what you are saying is correct is that of interest for the reader? > > > > The interesting piece IMHO is that 8505, as opposed to 4861, is stateful > and proactively installs the ND cache entries, which saves broadcasts and > provides a deterministic presence information for IPv6 addresses”. This is > what I’d like to see written there. For the RPL piece, if you want to > summarize my text, please insist on the fact that it’s “DV, with lazy > maintenance and stretched anisotropic routing, all designed to reduce the > topological knowledge and routing state that needs to be exchanged. As a > result, the routing protocol overhead is minimized, which allows either > highly constrained stable networks or less constrained highly dynamic > networks”. > > > > *From:* Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > *Sent:* jeudi 2 septembre 2021 17:30 > *To:* Pascal Thubert (pthubert) <pthubert@cisco.com> > *Cc:* int-dir@ietf.org; Last Call <last-call@ietf.org>; its@ietf.org; > Russ Housley <housley@vigilsec.com>; CARLOS JESUS BERNARDOS CANO < > cjbc@it.uc3m.es>; Chris Shen <shenyiwen7@gmail.com>; Mr. Jaehoon Paul > Jeong <jaehoon.paul@gmail.com> > *Subject:* Re: [ipwave] Intdir last call review of > draft-ietf-ipwave-vehicular-networking-20 > > > > Hi Pascal, > > I have reflected your comments on the revision: > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22 > > > > Though the text provided by you is excellent, it is long, so I place it on > Appendix B: > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22#appendix-B > > > > In Section 5.1.3. Routing, I explain RPL concisely along with pros and > cons: > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22#section-5.1.3 > > > > The changes with my some editings look like the following: > > > ---------------------------------------------------------------------------------------------------------------------- > > 5.1.3. Routing > ... > RPL [RFC6550] defines a routing protocol for low-power and lossy networks, > which constructs and > > maintains DODAGs optimized by an Objective Function (OF). A defined OF > provides route selection > > and optimization within an RPL topology. A node in a DODAG uses DODAG > Information Objects (DIOs) > > messages to discover and maintain the upward routes toward the root node. > Refer to Appendix B for > > the detailed description of RPL for multihop V2X networking. > ... > ---------- > Appendix B. Support of Multihop V2X Networking > ... > RPL is primarily designed to minimize the control plane activity, which is > the relative amount of routing > > protocol exchanges versus data traffic; this approach is beneficial for > situations where the power and > > bandwidth are scarce (e.g., an IoT LLN where RPL is typically used today), > but also in situations of > > high relative mobility between the nodes in the network (also known as > swarming, e.g., within a > > variable set of vehicles with a similar global motion, or a variable set > of drones flying toward the same > > direction). > > To reduce the routing exchanges, RPL leverages a Distance Vector approach, > which does not need a > > global knowledge of the topology, and only optimizes the routes to and > from the root, allowing > > Peer-to-Peer (P2P) paths to be stretched. Although RPL installs its routes > proactively, it only maintains > > them lazily, that is, in reaction to actual traffic, or as a slow > background activity. Additionally, RPL > > leverages the concept of an objective function (called OF), which allows > to adapt the activity of the > > routing protocol to use cases, e.g., type, speed, and quality of the > radios. RPL does not need converge, > > and provides connectivity to most nodes most of the time. The default > route toward the root is > > maintained aggressively and may change while a packet progresses without > causing loops, so the > > packet will still reach the root. There are two modes for routing in RPL > such as non-storing mode and > > storing mode. In non-storing mode, a node inside the mesh/swarm that > changes its point(s) of > > attachment to the graph informs the root with a single unicast packet > flowing along the default route, > > and the connectivity is restored immediately; this mode is preferable for > use cases where Internet > > connectivity is dominant. On the other hand, in storing mode, the routing > stretch is reduced, for a > > better P2P connectivity, while the Internet connectivity is restored more > slowly, during the time for > > the DV operation to operate hop-by-hop. While an RPL topology can quickly > scale up and down and > > fits the needs of mobility of vehicles, the total performance of the > system will also depend on how > > quickly a node can form an address, join the mesh (including > Authentication, Authorization, and > > Accounting (AAA)), and manage its global mobility to become reachable from > another node outside > > the mesh. > ... > > > ---------------------------------------------------------------------------------------------------------------------- > > > > If you have further comments, please let me know. > > > > Thanks. > > > > Best Regards, > > Paul > > > > On Thu, Sep 2, 2021 at 3:49 PM Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > > Hello Paul > > > > This is absolutely excellent. I’m very happy will all the changes and your > attached pdf made my life as a reviewer a lot simpler. > > > > This is really a great way of progressing together. Many thanks for that! > > > > I’m all good but for a little snippet in the new text which is actually > incorrect, and denotes a usual misunderstanding of RPL that your doc may > help correct for the future: > > > > “ > > Although RPL can be used in IPv6-based vehicular networks, it is primarily > designed for lossy > > networks, which puts energy efficiency first. In addition, the topology it > considers may not > > quickly scale up and down for IPv6-based vehicular networks, since the > mobility of vehicles is > > much more diverse with a high speed, so it can frequently alter a > tree-like topology formed by > > RPL, which may cause network fragmentation and merging with more control > traffic > > “ > > > > > > The roots of my contribution to RPL are in vehicular networks, exactly the > use case you describe. Based on that experience (including some actual test > with NASA) I’d change the text above with: > > > > > > “ > > RPL is primarily designed to minimize the control plane activity, that is > the relative amount of routing protocol exchanges vs. data traffic; this > approach is beneficial for situations where the power and bandwidth are > scarce (e.g., an IoT LLN where RPL is typically used today), but also in > situations of high relative mobility between the nodes in the network (aka > swarming, e.g., within a variable set of vehicles with a similar global > motion, or a toon of drones). > > To reduce the routing exchanges, RPL leverages a Distance Vector approach, > which does not need a global knowledge of the topology, and only optimizes > the routes to and from the root, allowing P2P paths to be stretched. > Although RPL installs its routes proactively, it only maintains them > lazily, in reaction to actual traffic, or as a slow background activity. > Additionally, RPL leverages the concept of an objective function, which > allows to adapt the activity of the routing protocol to the use case, e.g., > type, speed, and quality of the radios. RPL does not need converge, and > provides connectivity to most nodes most of the time. The default route > towards the Root is maintained aggressively and may change while a packet > progresses without causing loops, so the packet will still reach the root. > In non-storing mode, a node inside the mesh/swarm that changes its point(s) > of attachment to the graph informs the root with a single unicast packet > the flows along the default route, and the connectivity is restored > immediately; this mode is preferable for use cases where internet > connectivity is dominant. OTOH, in storing mode, the routing stretch is > reduced, for a better P2P connectivity, while the internet connectivity is > restored more slowly, time for the DV operation to operate hop-by-hop. > While a RPL topology can quickly scale up and down and fits the needs of > mobility of vehicles, the total performance of the system will also depend > on how quickly a node can form an address, join the mesh (including AAA), > and manage its global mobility to become reachable from outside the mesh. > > “ > > > > Otherwise, all good! > > > > Take care, > > > > Pascal > > > > > > *From:* Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > *Sent:* lundi 30 août 2021 15:12 > *To:* Pascal Thubert (pthubert) <pthubert@cisco.com> > *Cc:* int-dir@ietf.org; Last Call <last-call@ietf.org>; > draft-ietf-ipwave-vehicular-networking.all@ietf.org; its@ietf.org; Russ > Housley <housley@vigilsec.com>; CARLOS JESUS BERNARDOS CANO < > cjbc@it.uc3m.es>; skku-iotlab-members < > skku-iotlab-members@googlegroups.com>; Chris Shen <shenyiwen7@gmail.com>; > Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > *Subject:* Re: [ipwave] Intdir last call review of > draft-ietf-ipwave-vehicular-networking-20 > > > > Hi Pascal, > > Here is the revision (-21) of IPWAVE PS Draft: > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-21 > > > > I attach the revision letter to show how I have addressed your comments on > the revision. > > > > Chris and I have worked for this revision together. > > > > If you have further comments, please let me know. > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > > > On Fri, Jun 18, 2021 at 4:42 PM Pascal Thubert via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Pascal Thubert > Review result: Not Ready > > Dear authors > > In summary: > > I read a number of very good drafts collated in one, from the use cases > that > very complete and ready to publish, to the architecture and protocol > solution > in section 4 that would require more work for completeness. > > There are multiple instances in the use cases where protocols are listed > coming > out of the blue, e.g., the references to OMNI that seem artificially spread > regardless of the context of the section. OMNI is used throughout, both as > an > open ended toolbox, and as a carpet under which all problems can be hidden. > > Reading this doc, OMNI shows as an interface to a software mobile router, > with > multiple of the device physical interfaces connected to the mobile router. > This > makes the stack very simple as the complexity moves to the router. But now > you > have to implement the router. Presented as that, the OMNI router deserves > its > name, it’s indeed very rich; it seems to cover all forms of MANET (many to > choose from) and NEMO (and all the MIP protocol family across address > families), all the possible radio interfaces on which the ND problems go > away > by magic, and whatever else you want to put in there. Is that the > intention? > > Instead of referring to OMNI for virtually anything, the doc should refer > to > MANET for MANET things (like BYOD), NEMO for NEMO things (like MNP), > draft-nordmark-intarea-ippl for split subnets, and > draft-thubert-6man-ipv6-over-wireless for P2MP/NBMA link and subnet > models. And > then you can say that all those components can be plugged in the OMNI > router, > and you can discuss which MANET and which MIP you want, including using > OMNI’s > built in mobility. > > Note that my objections are not against the OMNI design, it might be the > perfect thing and I am already aware of use cases that could be served by a > P2MP interface like OMNI in conjunction with RFC8505 on the P2P > subinterfaces > (recycling the high level design we’ve been shipping for IPv4 / frame > relay for > the last 30 years). My objection is of the way the draft uses [OMNI] as the > magic wand that solves all the problems when what you really do is throw > them > over the fence. I’d rather you focus on problems and use cases, for which > there’s excellent text, and indicate what needs to be done without making > assumption on how the needful things will be solved. > > In agreement with a discussion on the 6MAN list, I’d suggest to split, > keep all > that’s use case and problem description and ship it, remove references to > protocols envisioned in the solution, and start the work on architecture > of the > solution and the protocol applicability statements separately. An alternate > would be to centralize the discussion on protocols to annex, and explain > that > protocol A or B could be envisioned in solution space because to over this > gap > or implement that function. > > In any fashion, the current text is not ready for publication as > applicability > statement, architecture and or/solution, so the related work should be > removed > from the main text. But I find it mostly ready for use case and problem > statement, more below. > > Review: > > Abstract > > This document discusses the problem statement and use cases of > IPv6-based vehicular networking for Intelligent Transportation > Systems (ITS). > > >>> The document goes beyond that; there was actually a thread at 6MAN > where > Bob Hinden said “ This document says it is a problem statement, but then > becomes a solution document. Might be better to cut it down to only the > problem statement part. “ >>> Would you consider doing this? If not, why? > Note: > you may want to respond on 6MAN as well. >>> >>>I would have thought that > the > traditional steps of problem statement and applicability statement of > existing > work could be expected from IPWAVE too. >>> Please clarify the steps that > you > intend to follow next with this work. > > <snip> > > 1. Introduction > > >>> Very readable and informative section, many thanks! > > Along with these WAVE standards and C-V2X standards, regardless of a > wireless access technology under the IP stack of a vehicle, vehicular > networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 > protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) > [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Locator/ > ID Separation Protocol (LISP) [RFC6830BIS], and Asymmetric Extended > Route Optimization (AERO) [RFC6706BIS]). > > >>> NEMO (RFC 3963) is not cited. Any reason why the vehicle would not > transport a network? > > <snip> > > This document describes use cases and a problem statement about > IPv6-based vehicular networking for ITS, which is named IPv6 Wireless > Access in Vehicular Environments (IPWAVE). First, it introduces the > use cases for using V2V, V2I, and V2X networking in ITS. Next, for > IPv6-based vehicular networks, it makes a gap analysis of current > IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, > and Security & Privacy), and then enumerates requirements for the > extensions of those IPv6 protocols, which are tailored to IPv6-based > vehicular networking. Thus, this document is intended to motivate > development of key protocols for IPWAVE. > > >>> > > <snip> > > 2. Terminology > > >>> > > <snip> > > o IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a > computer situated in a vehicle (e.g., car, bicycle, autobike, > motor cycle, and a similar one) and a device (e.g., smartphone and > IoT device). It has at least one IP interface that runs in IEEE > 802.11-OCB and has an "OBU" transceiver. Also, it may have an IP > interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP] > [TR-22.886-3GPP][TS-23.287-3GPP]. See the definition of the term > "OBU" in [RFC8691]. > > >>> Can that be a router connecting multiple computers? > > <snip> > > 3. Use Cases > > >>> This is another great read and an enlightening section. Maybe mention > in > the abstract that the doc also covers use cases? > > <snip> > > Although a Layer-2 solution can provide a support for multihop > communications in vehicular networks, the scalability issue related > to multihop forwarding still remains when vehicles need to > disseminate or forward packets toward multihop-away destinations. In > addition, the IPv6-based approach for V2V as a network layer protocol > can accommodate multiple radio technologies as MAC protocols, such as > 5G V2X and DSRC. Therefore, the existing IPv6 protocol can be > augmented through the addition of an Overlay Multilink Network (OMNI) > Interface [OMNI] and/or protocol changes in order to support both > wireless single-hop/multihop V2V communications and multiple radio > technologies in vehicular networks. In such a way, vehicles can > communicate with each other by V2V communications to share either an > emergency situation or road hazard in a highway having multiple kinds > of radio technologies, such as 5G V2X and DSRC. > > >>> This text appears in the middle of high level use case, with a crude > list > of protocols; this is not a place for it > > >>> On a 6MAN Thread, Brian Carpenter said that the above: > “ > is of concern regardless of the mention of OMNI. Does it mean "can be" or > "needs to be"? This paragraph seems like a very short summary of a big > problem > area. At the end of page 13 there is some related discussion, which > mentions > RPL as part of the solution (good choice, IMHO) but again seems to depend > on > OMNI. I don't think the fix of simply removing references to OMNI works, > because it would leave a gap. In an informational document, that is not a > formal problem but as far as this draft describes architecture, I don't > think > that big a gap is reasonable. "OMNI" is mentioned more than 20 times in the > document. There are also several references to AERO, which is strongly > associated with OMNI. “ >>> I agree with Brian. Here the document seems to > be > mixing solution with problem and putting the cart before the horse. My > recommendation is to stick to what needs to be done that IPv6 does not do > yet > -the reqs and gaps-; but the doc should not step in the how things will be > done > unless the group already decided to do it. The logical next steps to a PS > are > an applicability statement of existing work, and if the gaps cannot be > filled, > there may be one or more WG chartered to fill those gaps. > > >>> I’d still be happy to see an annex with leads on where the solution > might > come from like RFC 8691 does. > > <snip> > > The existing IPv6 protocol must be augmented through the addition of > an OMNI interface and/or protocol changes in order to support > wireless multihop V2I communications in a highway where RSUs are > sparsely deployed, so a vehicle can reach the wireless coverage of an > RSU through the multihop data forwarding of intermediate vehicles. > Thus, IPv6 needs to be extended for multihop V2I communications. > > >>> Note that I have no clue on how well OMNI applies in that space, maybe > it > does very well; but here it comes out of the blue with no justification. > If you > mention OMNI you need to detail what it is and which of the V2V problems > you > expect it to solve. But then, that’s beyond the scope of a PS. > > <snip> > > The existing IPv6 protocol must be augmented through the addition of > an OMNI interface and/or protocol changes in order to support > wireless multihop V2X (or V2I2X) communications in an urban road > network where RSUs are deployed at intersections, so a vehicle (or a > pedestrian's smartphone) can reach the wireless coverage of an RSU > through the multihop data forwarding of intermediate vehicles (or > pedestrians' smartphones). Thus, IPv6 needs to be extended for > multihop V2X (or V2I2X) communications. > > >>> Please be more specific on what the missing functions are and whether > they > are missing from the stack development standpoint or if there’s work needed > from the IETF. 1) If something is really missing in our specs, the > text to > prove from the use case above is missing 2) how OMNI serves the use > case > could be elaborated in an applicability statement of OMNI for V2xyz, but > it is > a bit blunt to present it as panacea when the problems to be solved are not > listed. 3) If you look at it, OMNI seems like a software mobile router > within a bump in the stack. Can that become too big? > > >>> my view is that the text above and the similar occasions should be > replaced > by something like : > > The existing IPv6 protocol must be augmented to provide the following > functions: 1) … > > >>> and / or something like: > > In addition to the IPv6 node requirements [RFC 8504], the IPv6 protocol > stack for use in a vehicle must support 1) RFC blah, 2) … > > <snip> > > To support applications of these V2X use cases, the functions of IPv6 > such as VND, VMM, and VSP are prerequisites for IPv6-based packet > exchange, transport-layer session continuity, and secure, safe > communication between a vehicle and a pedestrian either directly or > indirectly via an IP-RSU. > > >>> “the functions of IPv6 such as VND, VMM, and VSP” does not parse. > There’s > no IPv6 reference that provides those functions. If the intention is to say > that there’s stuff to add to IPv6 to support, like, say, VND, then this > document fails to define how an IPv6 VND should behave, though it’s > precisely > what I’d expect from a problem statement. > > <snip> > > 4. Vehicular Networks > > >>> What is the purpose of section 4 as a whole, problem statement or > applicability statement of the listed protocols? In the former case what’s > the > problem? In the latter case it is incomplete and needs to be exported to an > applicability statement doc with all the possible technologies evaluated. > > This section describes an example vehicular network architecture > supporting V2V, V2I, and V2X communications in vehicular networks. > > >>> I read this as presenting a context to explain what the problems are > instead of presenting the IPVAWE “architecture”. Maybe using the term > “Architecture” here is misleading and led to Bob’s comment. > > <snip> > > 4.1. Vehicular Network Architecture > > Figure 1 shows an example vehicular network architecture for V2I and > V2V in a road network [OMNI]. > > a. Is using OMNI a decision that the WG made for the future work ? > what > does it do and what does it not do? b. Is there work left to be done? > Who > will do that work? Or is it the expectation that OMNI has it all defined > already? > > <snip> > > An existing network architecture (e.g., an IP-based aeronautical > network architecture [OMNI][UAM-ITS], a network architecture of > PMIPv6 [RFC5213], and a low-power and lossy network architecture > [RFC6550]) can be extended to a vehicular network architecture for > multihop V2V, V2I, and V2X, as shown in Figure 1. In a highway > scenario, a vehicle may not access an RSU directly because of the > distance of the DSRC coverage (up to 1 km). For example, the OMNI > interface and/or RPL (IPv6 Routing Protocol for Low-Power and Lossy > Networks) [RFC6550] can be extended to support a multihop V2I since a > vehicle can take advantage of other vehicles as relay nodes to reach > the RSU. Also, RPL can be extended to support both multihop V2V and > V2X in the similar way. > > >>> all this could fit well in annex; anyway you need to explain what you > expect the protocols to do and which extension is needed. In the case of > RPL at > least you indicate that it would do routing, but not why you cannot use it > of > the shelf; for OMNI, what you expect is less clear, though there’s text > elsewhere about the many radio interfaces that could be used for the > purpose, > and the text in the UAM below that is enlightening. > > <snip> > > To support not only the mobility > management of the UAM end systems, but also the multihop and > multilink communications of the UAM interfaces, the UAM end systems > can employ an Overlay Multilink Network (OMNI) interface [OMNI] as a > virtual Non-Broadcast Multiple Access (NBMA) connection to a serving > ground domain infrastructure. > > >>> Again, what is the expectation for OMNI? As an overlay it requires an > underlay; when connecting to a MANET it needs support for that MANET. The > text > above seems to imply that is solves everything in V2xyz like magic; > reminds me > of the IPv6 multicast abstraction that was supposed to solve the broadcast > problem and ended up worsening it. > > <snip> > > This infrastructure can be configured > over the underlying data links. The OMNI interface and its link > model provide a means of multilink, multihop and mobility > coordination to the legacy IPv6 ND messaging [RFC4861] according to > the NBMA principle. Thus, the OMNI link model can support efficient > UAM internetworking services without additional mobility messaging, > and without any modification to the IPv6 ND messaging services or > link model. > > >>> Again, what is the expectation for OMNI? As an overlay it requires an > underlay; the text above seems to imply that is solves everything in V2xyz > like > magic; that would be a stretch, that reminds me of IPv6 multicast that was > supposed to solve the broadcast problem and ended up worsening it. > > <snip> > > Multiple vehicles under the coverage of an RSU share a prefix just as > mobile nodes share a prefix of a Wi-Fi access point in a wireless > LAN. This is a natural characteristic in infrastructure-based > wireless networks. For example, in Figure 1, two vehicles (i.e., > Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6 > global addresses for V2I communication. Alternatively, mobile nodes > can employ an OMNI interface and use their own IPv6 Unique Local > Addresses (ULAs) [RFC4193] over the wireless network without > requiring the messaging of IPv6 Stateless Address Autoconfiguration > (SLAAC) [RFC4862], which uses an on-link prefix provided by the > (visited) wireless LAN; this technique is known as "Bring-Your-Own- > Addresses". > > >>> Is OMNI the only way to "Bring-Your-Own-Addresses”? Else the text > could be > more generic, at least use e.g., like the ref to AERO later. >>> What are > the > implications / limitations of doing that – like they can do line of sight > V2V > but not reach the internet, or the need of a local MANET / RPL that will > accept to route those addresses, or the security / address ownership > validation > issues ? > > <snip> > > A single subnet prefix announced by an RSU can span multiple vehicles > in VANET. For example, in Figure 1, for Prefix 1, three vehicles > (i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected > VANET. Also, for Prefix 2, two vehicles (i.e., Vehicle3 and > Vehicle6) can construct another connected VANET, and for Prefix 3, > two vehicles (i.e., Vehicle4 and Vehicle7) can construct another > connected VANET. Alternatively, each vehicle could employ an OMNI > interface with their own ULAs such that no topologically-oriented > subnet prefixes need be announced by the RSU. > > >>> same as above. This seems to restate the same thing, derive an address > from a topologically correct prefix or use your own with limitations to be > described. > > <snip> > > For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691] > specifies several details, including Maximum Transmission Unit (MTU), > frame format, link-local address, address mapping for unicast and > multicast, stateless autoconfiguration, and subnet structure. An > Ethernet Adaptation (EA) layer is in charge of transforming some > parameters between the IEEE 802.11 MAC layer and the IPv6 network > layer, which is located between the IEEE 802.11-OCB's logical link > control layer and the IPv6 network layer. This IPv6 over 802.11-OCB > can be used for both V2V and V2I in IPv6-based vehicular networks. > > >>> solution space. > > <snip> > > An IPv6 mobility solution is needed for the guarantee of > communication continuity in vehicular networks so that a vehicle's > TCP session can be continued, or UDP packets can be delivered to a > vehicle as a destination without loss while it moves from an IP-RSU's > wireless coverage to another IP-RSU's wireless coverage. In > Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session) > with a corresponding node in the vehicular cloud, Vehicle2 can move > from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In > this case, a handover for Vehicle2 needs to be performed by either a > host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a > network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and > AERO [RFC6706BIS]). > > In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a > role of a home agent. On the other hand, in the network-based > mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility > management controller such as a Local Mobility Anchor (LMA) in > PMIPv6, which also serves vehicles as a home agent, and an IP-RSU > plays a role of an access router such as a Mobile Access Gateway > (MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs > client functionality in IPv6 stack of a vehicle as a mobile node for > mobility signaling message exchange between the vehicle and home > agent. On the other hand, the network-based mobility scheme does not > need such a client functionality for a vehicle because the network > infrastructure node (e.g., MAG in PMIPv6) as a proxy mobility agent > handles the mobility signaling message exchange with the home agent > (e.g., LMA in PMIPv6) for the sake of the vehicle. > > There are a scalability issue and a route optimization issue in the > network-based mobility scheme (e.g., PMIPv6) when an MA covers a > large vehicular network governing many IP-RSUs. In this case, a > distributed mobility scheme (e.g., DMM [RFC7429]) can mitigate the > scalability issue by distributing multiple MAs in the vehicular > network such that they are positioned closer to vehicles for route > optimization and bottleneck mitigation in a central MA in the > network-based mobility scheme. All these mobility approaches (i.e., > a host-based mobility scheme, network-based mobility scheme, and > distributed mobility scheme) and a hybrid approach of a combination > of them need to provide an efficient mobility service to vehicles > moving fast and moving along with the relatively predictable > trajectories along the roadways. > > In vehicular networks, the control plane can be separated from the > data plane for efficient mobility management and data forwarding by > using the concept of Software-Defined Networking (SDN) > [RFC7149][DMM-FPC]. Note that Forwarding Policy Configuration (FPC) > in [DMM-FPC], which is a flexible mobility management system, can > manage the separation of data-plane and control-plane in DMM. In > SDN, the control plane and data plane are separated for the efficient > management of forwarding elements (e.g., switches and routers) where > an SDN controller configures the forwarding elements in a centralized > way and they perform packet forwarding according to their forwarding > tables that are configured by the SDN controller. An MA as an SDN > controller needs to efficiently configure and monitor its IP-RSUs and > vehicles for mobility management, location management, and security > services. > > The mobility information of a GPS receiver mounted in its vehicle > (e.g., position, speed, and direction) can be used to accommodate > mobility-aware proactive handover schemes, which can perform the > handover of a vehicle according to its mobility and the wireless > signal strength of a vehicle and an IP-RSU in a proactive way. > > Vehicles can use the TCC as their Home Network having a home agent > for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213], > so the TCC (or an MA inside the TCC) maintains the mobility > information of vehicles for location management. IP tunneling over > the wireless link should be avoided for performance efficiency. > Also, in vehicular networks, asymmetric links sometimes exist and > must be considered for wireless communications such as V2V and V2I. > > >>> This is all very informative text but does not state a problem. Is > there a > problem is left to be solved or are we assessing the applicability of > protocols? Could it for instance, forward point to issues discussed in > section > 5? > > <snip> > > As shown in Figure 3, as internal networks, a vehicle's moving > network and an EN's fixed network are self-contained networks having > multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) > for the communication with another vehicle or another EN. The > internetworking between two internal networks via V2I communication > requires the exchange of the network parameters and the network > prefixes of the internal networks. For the efficiency, the network > prefixes of the internal networks (as a moving network) in a vehicle > need to be delegated and configured automatically. Note that a > moving network's network prefix can be called a Mobile Network Prefix > (MNP) [OMNI]. > > >>> Then again you’re overselling OMNI. MNP is originally defined here > https://datatracker.ietf.org/doc/html/rfc3963#section-2 and that’s a > reference > you can use normatively. > > <snip> > > As shown in Figure 3, the addresses used for IPv6 transmissions over > the wireless link interfaces for IP-OBU and IP-RSU can be either > global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be > routed within vehicular networks [OMNI]. > > >>> Then again you’re overselling OMNI. There needs to be a routing > protocol > like a MANET that will accept to carry the > MNPs, and that must be implemented by the infra and both cars. The OMNI > spec > is clear on that. This is why at first glance I see OMNI as a full mobile > router in a bump in the stack. Now what is the problem behind this? No > such > protocol at IETF? Too many to choose from? No deployment? > <snip> > > When global IPv6 addresses > are used, wireless interface configuration and control overhead for > Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener > Discovery (MLD) [RFC2710][RFC3810] should be minimized to support V2I > and V2X communications for vehicles moving fast along roadways; when > ULAs and the OMNI interface are used, no DAD nor MLD messaging is > needed. > > >>> Then again you’re overselling OMNI. Isn’t it the no dad needed a > property > of injecting a BYOA in the fabric for an GUA MIP Home Address which is > known to > be unique at home? >>> OTOH, autoconf’ing a random ULA “FD…”prefix has > lesser > DAD properties than autoconf’ing a random 64bit IID in a classical subnet. > So > who says DAD isn’t required for OMNI ULA? >>> note that IMHO DAD on > wireless is > a lot more harm than good, and I agree that with a good pseudo random > generator > the ULA has no chance to collision in the real world, as OMNI claims. It’s > just > that your argument here plays the other way, because there are less random > bits > (56) in the ULA prefix than in the IID (62), and if one starts using more > prefix bits to be non-random, there will be a time when DAD on prefix is > needed. > > <snip> > > Let us consider the upload/download time of a vehicle when it passes > through the wireless communication coverage of an IP-RSU. For a > given typical setting where 1km is the maximum DSRC communication > range [DSRC] and 100km/h is the speed limit in highway, the dwelling > time can be calculated to be 72 seconds by dividing the diameter of > the 2km (i.e., two times of DSRC communication range where an IP-RSU > is located in the center of the circle of wireless communication) by > the speed limit of 100km/h (i.e., about 28m/s). For the 72 seconds, > a vehicle passing through the coverage of an IP-RSU can upload and > download data packets to/from the IP-RSU. > > <snip> > > 4.3. V2V-based Internetworking > > >>> In this section it looks like the cars are in a stable line of sight > relationship. Which is probably fine for a platoon, but when you drive > along > with friends in different cars, you realize that the line of sight > assumption > does not stand over time. Soon enough, other cars meddle in, and possibly > one > of the cars drives faster and too far ahead so you need the infra to relay, > possibly over multiple infra hops. > > >>> so in this section, I’d expect to see a Vehicle communicating with > another > one and using either line of sight or V2V relaying but also using relay > via V2I > (multihop I2I not just hub and spoke V2I2V ), alternatively to together for > redundancy. Is that part of the problem? > > >>> reading deeper section 5 I found excellent text on routing via V and > via I. > This tells that section 4 does not play a good role at justifying section > 5. > Maybe keep section 4 for another doc? > > >>> What kind or reliability is required in a V2V use case? Do you think > ND can > handle it? Or MANET? What would be the assumption on L2 (roaming time, > unicast > vs P2MP) and on L3 (reliability ala DetNet/RAW). Should we have some L3 > redundancy? > > <snip> > > 5. Problem Statement > > <snip> > > In order to specify protocols using the architecture mentioned in > Section 4.1, IPv6 core protocols have to be adapted to overcome > certain challenging aspects of vehicular networking. Since the > vehicles are likely to be moving at great speed, protocol exchanges > need to be completed in a time relatively short compared to the > lifetime of a link between a vehicle and an IP-RSU, or between two > vehicles. > > >>> Any order of magnitude? > >>> Can you indicate whether this already rules out certain procedures, > e.g. > DAD ? > > The lifetime of a session varies depending on the session's type such > as a web surfing, voice call over IP, and DNS query. Regardless of a > session's type, to guide all the IPv6 packets to their destination > host, IP mobility should be supported for the session. > > >>> this seems to be for unicast when you know who to talk to. Is there a > need > some multicast groups like anybody around interested in topic blah like I > could > be multicasting the speed of vehicles coming the other way that I crossed > recently, for use of vehicles that I’m crossing now, so they can see a > slowdown > on advance > > Thus, the time constraint of a wireless link has a major impact on > IPv6 Neighbor Discovery (ND). Mobility Management (MM) is also > vulnerable to disconnections that occur before the completion of > identity verification and tunnel management. This is especially true > given the unreliable nature of wireless communication. This section > presents key topics such as neighbor discovery and mobility > management. > > >>> Only ND? What about the MANET? > >>> how fast should ND be to be suitable? > >>> is there also a bandwidth check? You can make things much faster if you > dedicate a lot of spectrum to it. But that can also be a waste. > > 5.1. Neighbor Discovery > > <snip> > > The requirements for IPv6 ND for vehicular networks are efficient DAD > and NUD operations. > > >>> Not lookup? Is it the intention to use IP unicast over MAC broadcast, > which > is a good idea in my book? > > <snip> > > This merging and partitioning should be considered for the > IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) > [RFC4862]. > > >>> Not lookup? Is it the intention to use IP unicast over MAC broadcast, > which > is a good idea in my book? > > <snip> > > Also, the partitioning of a VANET may make vehicles with the same > prefix be physically unreachable. Also, SLAAC needs to prevent IPv6 > address duplication due to the merging of VANETs. According to the > merging and partitioning, a destination vehicle (as an IPv6 host) > needs to be distinguished as either an on-link host or an off-link > host even though the source vehicle uses the same prefix as the > destination vehicle. > > >>> should reference to draft-nordmark-intarea-ippl > > To efficiently prevent IPv6 address duplication due to the VANET > partitioning and merging from happening in vehicular networks, the > vehicular networks need to support a vehicular-network-wide DAD by > defining a scope that is compatible with the legacy DAD. In this > case, two vehicles can communicate with each other when there exists > a communication path over VANET or a combination of VANETs and IP- > RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, > vehicles can assure that their IPv6 addresses are unique in the > vehicular network whenever they are connected to the vehicular > infrastructure or become disconnected from it in the form of VANET. > > >>> Excellent > > ND time-related parameters such as router lifetime and Neighbor > Advertisement (NA) interval need to be adjusted for vehicle speed and > vehicle density. For example, the NA interval needs to be > dynamically adjusted according to a vehicle's speed so that the > vehicle can maintain its neighboring vehicles in a stable way, > considering the collision probability with the NA messages sent by > other vehicles. > > >>> Is that a problem or just an operational setting that needs to be > found? > >>> Do we need to reconsider the concepts of those timers? > > <snip> > > Thus, in IPv6-based vehicular networking, IPv6 ND should have minimum > changes for the interoperability with the legacy IPv6 ND used in the > Internet, including the DAD and NUD operations. > > >>> I do not find the logical link with the text before, why is this a > “thus”? > >>> why should the ND inside the VANET be constrained to be interoperable? > This > may place constraints on the solution. > > 5.1.1. Link Model > > A prefix model for a vehicular network needs to facilitate the > > >>> Do you mean a “subnet model” as opposed to “prefix model”. > >>> it would make this piece and the next should refer to > draft-thubert-6man-ipv6-over-wireless for IPv6 over P2MP /NBMA, for both > link > and subnet issues. The general ideas are the same, but the gory details > here > are slightly incorrect, like this notion of prefix model than comes out of > the > blue. The model is really the subnet model for the subnet associated to > P2MP. > > communication between two vehicles with the same prefix regardless of > the vehicular network topology as long as there exist bidirectional > E2E paths between them in the vehicular network including VANETs and > IP-RSUs. This prefix model allows vehicles with the same prefix to > communicate with each other via a combination of multihop V2V and > multihop V2I with VANETs and IP-RSUs. Note that the OMNI interface > supports an NBMA link model where multihop V2V and V2I communications > use each mobile node's ULAs without need for any DAD or MLD > messaging. > > >>> again overselling OMNI. > >>> I kinda agree about the OMNI interface model, nothing against that. > But you > must see that there needs a lot more than what the OMNI interface to get > packets across V and I hops to the destination. Like routing ala MANET, > redundancy handling ala DetNet because it will be very lossy, path > management > ala RAW to optimize delivery vs. spectrum… And OMNI ignores ND so it does > not > solve the ND problems above. > > IPv6 protocols work under certain assumptions that do not necessarily > hold for vehicular wireless access link types other than OMNI/NBMA > [VIP-WAVE][RFC5889]; the rest of this section discusses implications > for those link types that do not apply when the OMNI/NBMA link model > > >>> again overselling OMNI. > >>> The keyword here is P2MP / NBMA, and OMNI is one interface that accepts > that. There are others. IBM’s IPv4 over Frame relay was already P2MP / > NBMA, > using routing to complete the partial mesh in P2MP. The text seems to imply > that OMNI is the only way to do that and that’s wrong. Also OMNI is loaded > with > other stuff than a plain P2MP capable interface. And ND over P2MP is not > done > by OMNI, OMNI only makes classical ND worse and only works in a full mesh. > OTOH > RFC 8505, which is designed to do ND for P2MP /NBMA would indeed work very > well > within an OMNI interface and solve those problems. >>> My point is that you > need to tell the full story or refrain from entering solution space in > this doc > > <snip> > > There is a relationship between a link and a prefix, besides the > different scopes that are expected from the link-local and global > types of IPv6 addresses. In an IPv6 link, it is assumed that all > interfaces which are configured with the same subnet prefix and with > on-link bit set can communicate with each other on an IPv6 link. > > >>> not assumed; that’s what the onlink but set tells. The conclusion > should be > that the VANET cannot set the O bit. > > However, the vehicular link model needs to define the relationship > between a link and a prefix, considering the dynamics of wireless > links and the characteristics of VANET. > > <snip> > > From the previous observation, a vehicular link model should consider > the frequent partitioning and merging of VANETs due to vehicle > mobility. Therefore, the vehicular link model needs to use an on- > link prefix and off-link prefix according to the network topology of > vehicles such as a one-hop reachable network and a multihop reachable > > >>> No, the once a node saw a O bit set that sticks even if it sees other > advertisements of the PIO with the O bit not set. >>> This is a global and > intrinsic property of the prefix (and an attack vector that could be > mentioned > in the sec section). >>> the VANET prefix must never come with the O bit > set. > > <snip> > > network (or partitioned networks). If the vehicles with the same > prefix are reachable from each other in one hop, the prefix should be > on-link. > > >>>> No, see above; but the router may redirect though it is really risky > unless this is a stable situation like a parking place. > > Thus, in IPv6-based vehicular networking, the vehicular link model > should have minimum changes for interoperability with standard IPv6 > links in an efficient fashion to support IPv6 DAD, MLD and NUD > operations. When the OMNI NBMA link model is used, there are no link > model changes nor DAD/MLD messaging required. > > >>>> again overselling OMNI. > >>>> You need a good P2MP subnet model with routing support when the mesh > is > partial. My company alone has been shipping million of nodes that build > subnets > of thousands, and that was done using IETF standards. > > <snip> > > For vehicular networks with high mobility and density, the DAD needs > to be performed efficiently with minimum overhead so that the > vehicles can exchange a driving safety message (e.g., collision > avoidance and accident notification) with each other with a short > interval (e.g., 0.5 second) by a technical report from NHTSA > (National Highway Traffic Safety Administration) [NHTSA-ACAS-Report]. > Such a driving safety message may include a vehicle's mobility > information (i.e., position, speed, direction, and acceleration/ > deceleration). The exchange interval of this message is 0.5 second, > which is required to allow a driver to avoid a rear-end crash from > another vehicle. > > >>> IPv6 over broadcast MAC (used to be called internet 0, 10+ years ago) > solves that MAC issue since there is no MAC. > > 5.1.3. Routing > > For multihop V2V communications in either a VANET or VANETs via IP- > RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may > be required to support both unicast and multicast in the links of the > subnet with the same IPv6 prefix. However, it will be costly to run > both vehicular ND and a vehicular ad hoc routing protocol in terms of > control traffic overhead [ID-Multicast-Problems]. > > >>> we do that with IETF standards on battery operated devices already. > Using > RFC 8505 for the UNI and RPL for the NNI. It is scalable (we’ve seen 30 > hops in > meshes of thousands in the real world though it’s not the normal > operational > model, but can happen to maintain connectivity during the reboot of a > root) and > does not use broadcast. RPL was initially designed as a V2V2V protocol but > found its market on the IoT. I’m sure the protocol would gladly come back > to > its roots. > > A routing protocol for a VANET may cause redundant wireless frames in > the air to check the neighborhood of each vehicle and compute the > routing information in a VANET with a dynamic network topology > because the IPv6 ND is used to check the neighborhood of each > vehicle. Thus, the vehicular routing needs to take advantage of the > IPv6 ND to minimize its control overhead. > > >>> A clean description of the interaction of RPL and RFC 8505 in our IoT > networks. Note that the speed of the PHY in VANET balanced the instability > of > the topology, and RPL still applies. Note also that RPL uses DV with a > routing > stretch in order to minimize the topology awareness that’s needed in each > node, > which results in minimal signaling. > > 5.2. Mobility Management > > <snip> > > For a mobility management scheme in a shared link, where the wireless > subnets of multiple IP-RSUs share the same prefix, an efficient > vehicular-network-wide DAD is required. If DHCPv6 is used to assign > a unique IPv6 address to each vehicle in this shared link, > > >>> I would not use the term link, or shared. Maybe shared link -> domain? > <snip> > > the DAD is > not required. On the other hand, for a mobility management scheme > with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213] and OMNI > [OMNI]), DAD is not required because the IPv6 address of a vehicle's > external wireless interface is guaranteed to be unique. > > >>> again overselling OMNI > >>> As I said earlier, this is wring there are (64*) more chances of a > collision in OMNI prefixes than in IPv6 IIDs. >>> OMNI prefixes can > collision, > home addresses that are unique on a home network cannot. >>> Now if both > the > OMNI prefix and the IID are good randoms, then obviously, the chances of > collisions round up to 0. >>> Collision is certainly not my worst fear. > > There is a > tradeoff between the prefix usage efficiency and DAD overhead. Thus, > the IPv6 address autoconfiguration for vehicular networks needs to > consider this tradeoff to support efficient mobility management. > > >>> This is way too superficial and hides the reality of things. > - Using a VANET Infra prefix allows direct routability to the internet > which > BYOA does not since the BYOA is not topologically correct. Yes, it costs a > DAD > with classic ND, but it does not with RCF8505 and the draft fails to > mention > that. - A BYOA needs a tunnel home, and the node needs to know who is > reachable > inside the VANET and what is not to decide to tunnel or not; this is a > difficult problem (vs. control place overhead) that is not discussed here. > > <snip> > > For the case of a multihomed network, a vehicle can follow the first- > hop router selection rule described in [RFC8028]. That is, the > vehicle should select its default router for each prefix by > preferring the router that advertised the prefix. > > >>> Still router discovery (in and out) must be very fast. Thing of the RA > intervale in MIPv6. Is that sufficient? Too expensive? > > <snip> > > 6. Security Considerations > >>> Any discussion on the security of classical ND and other operational > issues > (rfc6583) ? > > <snip> > > Security and privacy are paramount in V2I, V2V, and V2X networking. > Vehicles and infrastructure must be authenticated in order to > participate in vehicular networking. Also, in-vehicle devices (e.g., > ECU) and a driver/passenger's mobile devices (e.g., smartphone and > tablet PC) in a vehicle need to communicate with other in-vehicle > devices and another driver/passenger's mobile devices in another > vehicle, or other servers behind an IP-RSU in a secure way. Even > though a vehicle is perfectly authenticated and legitimate, it may be > hacked for running malicious applications to track and collect its > and other vehicles' information. In this case, an attack mitigation > process may be required to reduce the aftermath of malicious > behaviors. > > >>> The section should mention that both with classical ND and BYOA, > addresses > can be impersonated, and RFC 8928 protects against that in both cases while > maintaining privacy. > > Even though vehicles can be authenticated with valid certificates by > an authentication server in the vehicular cloud, the authenticated > > >>> Is PKI feasible (deploying it in every car?). Is it fast enough? Is it > really what IPWAVE thinks vehicle should use????? >>> e.g. why would one > need > to authenticate to a V2I network? >>> from the text earlier in the doc, it > seemed that what you really want is access that is fast to join, capable of > offering the reachability you want, anonymous, and innocuous (cars can not > harm > one another). > > vehicles may harm other vehicles, so their communication activities > need to be logged in either a central way through a logging server > (e.g., TCC) in the vehicular cloud or a distributed way (e.g., > blockchain [Bitcoin]) along with other vehicles or infrastructure. > For the non-repudiation of the harmful activities of malicious nodes, > a blockchain technology can be used [Bitcoin]. Each message from a > vehicle can be treated as a transaction and the neighboring vehicles > can play the role of peers in a consensus method of a blockchain > [Bitcoin][Vehicular-BlockChain]. For a blockchain's efficient > consensus in vehicular networks having fast moving vehicles, a new > consensus algorithm needs to be developed or an existing consensus > algorithm needs to be enhanced. > > >>> solution space; better express the security needs since this is a PS. > > <snip> > > To identify malicious vehicles among vehicles, an authentication > method is required. > > >>> No. As said earlier a vehicle can be infected. You need > innocuousness.which > can come from things like isolation, zerotrust, and protocols that are > difficult to hack around. Classical IPv6 ND is open bar. RFC 8505/8928 is > protected by construction, anonymous, and fast. > > <snip> > > For the setup of a secure channel over IPsec or TLS, the multihop V2I > communications over DSRC is required in a highway for the > authentication by involving multiple intermediate vehicles as relay > nodes toward an IP-RSU connected to an authentication server in the > vehicular cloud. The V2I communications over 5G V2X (or LTE V2X) is > required to allow a vehicle to communicate directly with a gNodeB (or > eNodeB) connected to an authentication server in the vehicular cloud. > > >>> solution space. Instead, you could mention that setting up secured > channels > between cars that cross one another might not complete in time to > establish the > communication channel, and that the innocuousness must come from zerotrust > in > the transactions between the cars. > For the IPv6 ND, the DAD is required to ensure the uniqueness of the > IPv6 address of a vehicle's wireless interface. > > >>> for classical ND (SLAAC) that’s true. That is not with RFC 8505, since > the > infra maintains a table of all addresses in use in the prefix and blocks > duplicates without the RFC 4862 DAD method. The stateful autoconf address > grant > is immediate. > > This DAD can be used > as a flooding attack that uses the DAD-related ND packets > disseminated over the VANET or vehicular networks. > > >>> also for DOS attacks. You can block a owner from using an address. A > reference to rfc6959 is much needed here. > > <snip> > > This possibility > indicates that the vehicles and IP-RSUs need to filter out suspicious > ND traffic in advance. Based on the SEND [RFC3971] mechanism, the > authentication for routers (i.e., IP-RSUs) can be conducted by only > selecting an IP-RSU that has a certification path toward trusted > parties. For authenticating other vehicles, the cryptographically > generated address (CGA) can be used to verify the true owner of a > received ND message, which requires to use the CGA ND option in the > ND protocols. For a general protection of the ND mechanism, the RSA > Signature ND option can also be used to protect the integrity of the > messages by public key signatures. For a more advanced > authentication mechanism, a distributed blockchain-based mechanism > [Vehicular-BlockChain] can be used. > > >>> solution space. Again, the draft should focus on problems and needs. > The > problem here is that SEND is complex, and not implemented in the major > stack. > It relies on PKI for trusting the router. The V2I need is a zerotrust model > where one V, the other local Vs, and the I, can help each other > anonymously and > harmlessly. <snip> > > 8. Informative References > > >>> no normative reference? > > >>> no normative reference? > > <snip> > > Voila! > > Keep safe; > > Pascal > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >
- [ipwave] Intdir last call review of draft-ietf-ip… Pascal Thubert via Datatracker
- Re: [ipwave] Intdir last call review of draft-iet… Eric Vyncke (evyncke)
- Re: [ipwave] Intdir last call review of draft-iet… Erik Kline
- [ipwave] Fwd: Intdir last call review of draft-ie… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Fwd: Intdir last call review of draf… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Fwd: Intdir last call review of draf… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Intdir last call review of draft-iet… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Intdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [ipwave] [Int-dir] Intdir last call review of… Eric Vyncke (evyncke)
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Intdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir last call review of draft-iet… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Intdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Intdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Intdir last call review of draft-iet… Alexandre Petrescu
- Re: [ipwave] Intdir last call review of draft-iet… Alexandre Petrescu
- Re: [ipwave] Intdir last call review of draft-iet… Michael Richardson
- Re: [ipwave] Intdir last call review of draft-iet… Abdussalam Baryun
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] [EXTERNAL] Re: Intdir last call revi… Templin (US), Fred L
- Re: [ipwave] Intdir last call review of draft-iet… Abdussalam Baryun
- Re: [ipwave] [EXTERNAL] Re: Intdir last call revi… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Intdir last call review of draft-iet… Mr. Jaehoon Paul Jeong
- [ipwave] Platooning comments on draft-ietf-ipwave… Alexandre Petrescu
- Re: [ipwave] Platooning comments on draft-ietf-ip… Abdussalam Baryun
- Re: [ipwave] Intdir last call review of draft-iet… Erik Kline
- Re: [ipwave] [EXTERNAL] Re: Intdir last call revi… Templin (US), Fred L