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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you very much, Pascal

-éric

-----Original Message-----
From: Pascal Thubert via Datatracker <[e-mail]>
Reply-To: Pascal Thubert <[e-mail]>
Date: Friday, 18 June 2021 at 09:42
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Intdir last call review of draft-ietf-ipwave-vehicular-networking-20
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, Eric Vyncke <[e-mail]>
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