Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

Erik Kline <ek.ietf@gmail.com> Sat, 19 June 2021 04:20 UTC

Return-Path: <ek.ietf@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 C9B5B3A2092; Fri, 18 Jun 2021 21:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 EOOvx1yLlftl; Fri, 18 Jun 2021 21:20:02 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 857FD3A208F; Fri, 18 Jun 2021 21:19:58 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id w22-20020a0568304116b02904060c6415c7so11791835ott.1; Fri, 18 Jun 2021 21:19:58 -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:content-transfer-encoding; bh=Mnu24OZKpK2F/lpZqL6j6EnKoZS+yOBKWIoQ22+/bgY=; b=QfNL2NIrVB42qC2ZRkV8+Z7IuQbHMh3SfbTrVDA0hDq4vCUUX/M1SnaiI61Zt8K7/n PsxorKalR4b/qhil5jLmc7AjfKs5ytUzxoMugx8nDh7er7RdtQkfILfI1YqfjZSg1k/3 utAde8Jo1xgA7qZEKg8zC/irSxDc3lCGxbhu+SJdQnucTDOgxEaSf4/iXXE2aN9c0k9F qz3b6MzW6Ec9E0mZG1Z7T/+hS03w1ESOtsJacEnPEnZM/Xu8BbeYKs3/RuZ5qiJg7y79 CDdZL+LPfAJVvZ+nRHFbubZ7qnXkfWfyJTm7NFZBrx6Vi4YRtYvRwSQxywuaJyyN2byC SE9g==
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:content-transfer-encoding; bh=Mnu24OZKpK2F/lpZqL6j6EnKoZS+yOBKWIoQ22+/bgY=; b=mOhpd/Zx2Es5Smczh6jSs5RbsP+Jc/aDw6S7p40+snD2bmCweHIt5iiWKsQj/ARzFt Q7AIqIN8Q/kWj0v0SHZ+Eovgxi3n6c6YViIOJK3D/1fx54Y/Z3F0xqZ/orL6tqZ9lwGH erPIHlim+WCc4muoGqq3rf4Rn3N3HfsIb7YGbY1XRAC6XUelhTDq7gyNRKmcadVHGjoZ KhRMg+sr5EX5l7ZUC1bzU8vNCM/4lnC1BQ3cIg9uY6aEQ5sWg43OP3d4I0FDjIxgzERE /rCxDFbEffxySkN7KwjuitWo37fSJ5hMrWpkfQrXawX+F1JqyaghWTb/adRdld70Wuwn CSOw==
X-Gm-Message-State: AOAM532zQWp520y+uq+x7zt0bWPh1Ly3jpBal8+iJq1jzcINVZ0HCppE ytmOTmUJc7doiwMYVMqHn17Wb2lfSN3EFBvlXsE=
X-Google-Smtp-Source: ABdhPJw40VTxbuTG7G+wACBjhG6zMkkVUjZPebToxvAAb6p38zLT46jVgW+ZVqnvZPo0kbPVdHt4CrtswudQavCwRbE=
X-Received: by 2002:a05:6830:1208:: with SMTP id r8mr12132412otp.155.1624076395868; Fri, 18 Jun 2021 21:19:55 -0700 (PDT)
MIME-Version: 1.0
References: <162400216663.17839.1738900015320888640@ietfa.amsl.com> <E8EF116B-14C2-432B-A764-3AB5220FDC20@cisco.com>
In-Reply-To: <E8EF116B-14C2-432B-A764-3AB5220FDC20@cisco.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Fri, 18 Jun 2021 21:19:45 -0700
Message-ID: <CAMGpriXBeygMao_9+qVUXEnvWP5nO+-T5x4QBoijCsC-Eh5D-Q@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-ipwave-vehicular-networking.all@ietf.org" <draft-ietf-ipwave-vehicular-networking.all@ietf.org>, "its@ietf.org" <its@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/XM8isL_ue4bOWjuuPo35aj9SvG0>
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: Sat, 19 Jun 2021 04:20:08 -0000

Oui!

On Fri, Jun 18, 2021 at 2:41 PM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
>
> Thank you very much, Pascal
>
> -éric
>
> -----Original Message-----
> From: Pascal Thubert via Datatracker <noreply@ietf.org>
> Reply-To: Pascal Thubert <pthubert@cisco.com>
> Date: Friday, 18 June 2021 at 09:42
> To: "int-dir@ietf.org" <int-dir@ietf.org>
> Cc: "draft-ietf-ipwave-vehicular-networking.all@ietf.org" <draft-ietf-ipwave-vehicular-networking.all@ietf.org>rg>, "its@ietf.org" <its@ietf.org>rg>, "last-call@ietf.org" <last-call@ietf.org>
> Subject: Intdir last call review of draft-ietf-ipwave-vehicular-networking-20
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: <housley@vigilsec.com>om>, <cjbc@it.uc3m.es>es>, <ek.ietf@gmail.com>om>, <pauljeong@skku.edu>du>, Eric Vyncke <evyncke@cisco.com>
> Resent-Date: Friday, 18 June 2021 at 09:42
>
>     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
>
>
>
>