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

[Alexandre Petrescu <[e-mail]>]

Le 09/09/2021 à 10:20, Alexandre Petrescu a écrit :
PAscal wrote:
> this approach is beneficial for situations where the power and 
> bandwidth are scarce (e.g., an IoT LLN where RPL is typically used 
> today), but also in situations of high relative mobility between the 
> nodes in the network (aka swarming, e.g., within a variable set of 
> vehicles with a similar global motion, or a toon of drones).


For the 'toon of drones' - we came up with the word 'flightooning' in a 
small group of people I talk to.  These 'flightoons' use a very coherent 
internal structure.  It is 'figé', which means the drones dont  move 
with respect to each other and fly together as a single unit.

These flightoons do move in 3 dimensions, but the relative speed of a 
drone with respect to the other is 0, and the group follows 
pre-determined paths; its altitude parameter does take values between 0 
and 300meters for a length of maybe a few hundred meters).  The 
flightooning use-case is simpler than the sliding lanes of convoys 
(mainly on a 2 dimensional road, and just a small variation in altitidue 
like a few tens of meters along a few kilometers - the 'pente', max. 15 
degrees for most advanced tanks) on the road where there is variable 
speed (ach lane has a different speed).  These parameters are well 
known.  They might constitute what some people consider an 'ODD' (an 
Operational Design Domain), a set of limits within which the respective 
mobile entities are guaranteed a certain level of safety at a certain 
level of automation (L1..L4, SAE).

The communication system in a toon of drones, or a 'flightoon', might 
not need to use RPL, which is designed for electricity counters at home.

Alex

>
> Car networks do not need arbitrary mobility.  Their mobility patterns 
> are very restricted.  It is not brownian movements.
>
> For example, cars move on ways along pre-determined paths.  There 
> might be convoys, and sliding lanes of cars, there might be 
> intersections controlled by traffic lights; human reaction (in the 
> order of 1 or 2 seconds, or more) is what makes for dynamicity in car 
> networks; that time (seconds delay) is very very high compared to the 
> latency of modern wireless media (e.g. 802.11bd with below 
> milli-second latencies).  Generally speaking it is  a very orderly 
> movement.
>
> Yes, we are impressed with the speed of cars, and imagine that for 
> these speeds the communication protocols might not cope with.  But one 
> has to consider _relative_ speeds (e.g. a car following another one is 
> practically stationary with respect to it), and one has to consider 
> the speed of the communication  medium which is the speed of light.
>
> Think that even a launch of a rocket carrying tons of payload at 
> 30.000 km/h vertically still sends live video we can enjoy seeing over 
> the Internet today.  There is no need of new protocol for that kind of 
> mobility, and still the dynamicity aspect (speed) is very very 
> extreme; it is probably the highest speeds one can achieve  on Earth.
>
> Trying to make 'universal' protocols that work well in a a wide range 
> of mobility and dynamicity is a too high objective.  One can try, yes, 
> but does it succeed in deployment?
>
> Alex
>
>
>> To reduce the routing exchanges, RPL leverages a Distance Vector 
>> approach, which does not need a global knowledge of the topology, and 
>> only optimizes the routes to and from the root, allowing P2P paths to 
>> be stretched. Although RPL installs its routes proactively, it only 
>> maintains them lazily, in reaction to actual traffic, or as a slow 
>> background activity. Additionally, RPL leverages the concept of an 
>> objective function, which allows to adapt the activity of the routing 
>> protocol to the use case, e.g., type, speed, and quality of the 
>> radios. RPL does not need converge, and provides connectivity to most 
>> nodes most of the time. The default route towards the Root is 
>> maintained aggressively and may change while a packet progresses 
>> without causing loops, so the packet will still reach the root. In 
>> non-storing mode, a node inside the mesh/swarm that changes its 
>> point(s) of attachment to the graph informs the root with a single 
>> unicast packet the flows along the default route, and the 
>> connectivity is restored immediately; this mode is preferable for use 
>> cases where internet connectivity is dominant. OTOH, in storing mode, 
>> the routing stretch is reduced, for a better P2P connectivity, while 
>> the internet connectivity is restored more slowly, time for the DV 
>> operation to operate hop-by-hop. While a RPL topology can quickly 
>> scale up and down and fits the needs of mobility of vehicles, the 
>> total performance of the system will also depend on how quickly a 
>> node can form an address, join the mesh (including AAA), and manage 
>> its global mobility to become reachable from outside the mesh.
>>
>> “
>>
>> Otherwise, all good!
>>
>> Take care,
>>
>> Pascal
>>
>> *From:* Mr. Jaehoon Paul Jeong <[e-mail]>
>> *Sent:* lundi 30 août 2021 15:12
>> *To:* Pascal Thubert (pthubert) <[e-mail]>
>> *Cc:* [e-mail]; Last Call <[e-mail]>; 
>> [e-mail]; [e-mail]; 
>> Russ Housley <[e-mail]>; CARLOS JESUS BERNARDOS CANO 
>> <[e-mail]>; skku-iotlab-members 
>> <[e-mail]>; Chris Shen 
>> <[e-mail]>; Mr. Jaehoon Paul Jeong <[e-mail]>
>> *Subject:* Re: [ipwave] Intdir last call review of 
>> draft-ietf-ipwave-vehicular-networking-20
>>
>> Hi Pascal,
>>
>> Here is the revision (-21) of IPWAVE PS Draft:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-21 
>> <https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-21>
>>
>> I attach the revision letter to show how I have addressed your 
>> comments on the revision.
>>
>> Chris and I have worked for this revision together.
>>
>> If you have further comments, please let me know.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Paul
>>
>> On Fri, Jun 18, 2021 at 4:42 PM Pascal Thubert via Datatracker 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Reviewer: Pascal Thubert
>>     Review result: Not Ready
>>
>>     Dear authors
>>
>>     In summary:
>>
>>     I read a number of very good drafts collated in one, from the use
>>     cases that
>>     very complete and ready to publish, to the architecture and
>>     protocol solution
>>     in section 4 that would require more work for completeness.
>>
>>     There are multiple instances in the use cases where protocols are
>>     listed coming
>>     out of the blue, e.g., the references to OMNI that seem
>>     artificially spread
>>     regardless of the context of the section. OMNI is used
>>     throughout, both as an
>>     open ended toolbox, and as a carpet under which all problems can
>>     be hidden.
>>
>>     Reading this doc, OMNI shows as an interface to a software mobile
>>     router, with
>>     multiple of the device physical interfaces connected to the
>>     mobile router. This
>>     makes the stack very simple as the complexity moves to the
>>     router. But now you
>>     have to implement the router. Presented as that, the OMNI router
>>     deserves its
>>     name, it’s indeed very rich; it seems to cover all forms of MANET
>>     (many to
>>     choose from) and NEMO (and all the MIP protocol family across address
>>     families), all the possible radio interfaces on which the ND
>>     problems go away
>>     by magic, and whatever else you want to put in there. Is that the
>>     intention?
>>
>>     Instead of referring to OMNI for virtually anything, the doc
>>     should refer to
>>     MANET for MANET things (like BYOD), NEMO for NEMO things (like MNP),
>>     draft-nordmark-intarea-ippl for split subnets, and
>>     draft-thubert-6man-ipv6-over-wireless for P2MP/NBMA link and
>>     subnet models. And
>>     then you can say that all those components can be plugged in the
>>     OMNI router,
>>     and you can discuss which MANET and which MIP you want, including
>>     using OMNI’s
>>     built in mobility.
>>
>>     Note that my objections are not against the OMNI design, it might
>>     be the
>>     perfect thing and I am already aware of use cases that could be
>>     served by a
>>     P2MP interface like OMNI in conjunction with RFC8505 on the P2P
>>     subinterfaces
>>     (recycling the high level design we’ve been shipping for IPv4 /
>>     frame relay for
>>     the last 30 years). My objection is of the way the draft uses
>>     [OMNI] as the
>>     magic wand that solves all the problems when what you really do
>>     is throw them
>>     over the fence. I’d rather you focus on problems and use cases,
>>     for which
>>     there’s excellent text, and indicate what needs to be done
>>     without making
>>     assumption on how the needful things will be solved.
>>
>>     In agreement with a discussion on the 6MAN list, I’d suggest to
>>     split, keep all
>>     that’s use case and problem description and ship it, remove
>>     references to
>>     protocols envisioned in the solution, and start the work on
>>     architecture of the
>>     solution and the protocol applicability statements separately. An
>>     alternate
>>     would be to centralize the discussion on protocols to annex, and
>>     explain that
>>     protocol A or B could be envisioned in solution space because to
>>     over this gap
>>     or implement that function.
>>
>>     In any fashion, the current text is not ready for publication as
>>     applicability
>>     statement, architecture and or/solution, so the related work
>>     should be removed
>>     from the main text. But I find it mostly ready for use case and
>>     problem
>>     statement, more below.
>>
>>     Review:
>>
>>     Abstract
>>
>>        This document discusses the problem statement and use cases of
>>        IPv6-based vehicular networking for Intelligent Transportation
>>        Systems (ITS).
>>
>>     >>> The document goes beyond that; there was actually a thread at
>>     6MAN where
>>     Bob Hinden said “ This document says it is a problem statement,
>>     but then
>>     becomes a solution document.   Might be better to cut it down to
>>     only the
>>     problem statement part. “ >>> Would you consider doing this? If
>>     not, why? Note:
>>     you may want to respond on 6MAN as well. >>> >>>I would have
>>     thought that the
>>     traditional steps of problem statement and applicability
>>     statement of existing
>>     work could be expected from IPWAVE too. >>> Please clarify the
>>     steps that you
>>     intend to follow next with this work.
>>
>>     <snip>
>>
>>     1.  Introduction
>>
>>     >>> Very readable and informative section, many thanks!
>>
>>        Along with these WAVE standards and C-V2X standards,
>>     regardless of a
>>        wireless access technology under the IP stack of a vehicle,
>>     vehicular
>>        networks can operate IP mobility with IPv6 [RFC8200] and
>>     Mobile IPv6
>>        protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6
>>     (PMIPv6)
>>        [RFC5213], Distributed Mobility Management (DMM) [RFC7333],
>>     Locator/
>>        ID Separation Protocol (LISP) [RFC6830BIS], and Asymmetric
>>     Extended
>>        Route Optimization (AERO) [RFC6706BIS]).
>>
>>     >>> NEMO (RFC 3963) is not cited. Any reason why the vehicle
>>     would not
>>     transport a network?
>>
>>     <snip>
>>
>>        This document describes use cases and a problem statement about
>>        IPv6-based vehicular networking for ITS, which is named IPv6
>>     Wireless
>>        Access in Vehicular Environments (IPWAVE). First, it
>>     introduces the
>>        use cases for using V2V, V2I, and V2X networking in ITS. 
>>     Next, for
>>        IPv6-based vehicular networks, it makes a gap analysis of current
>>        IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility
>>     Management,
>>        and Security & Privacy), and then enumerates requirements for the
>>        extensions of those IPv6 protocols, which are tailored to
>>     IPv6-based
>>        vehicular networking.  Thus, this document is intended to motivate
>>        development of key protocols for IPWAVE.
>>
>>     >>>
>>
>>     <snip>
>>
>>     2.  Terminology
>>
>>     >>>
>>
>>     <snip>
>>
>>        o  IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a
>>           computer situated in a vehicle (e.g., car, bicycle, autobike,
>>           motor cycle, and a similar one) and a device (e.g.,
>>     smartphone and
>>           IoT device).  It has at least one IP interface that runs in
>>     IEEE
>>           802.11-OCB and has an "OBU" transceiver. Also, it may have
>>     an IP
>>           interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP]
>>           [TR-22.886-3GPP][TS-23.287-3GPP].  See the definition of
>>     the term
>>           "OBU" in [RFC8691].
>>
>>     >>> Can that be a router connecting multiple computers?
>>
>>     <snip>
>>
>>     3.  Use Cases
>>
>>     >>> This is another great read and an enlightening section. Maybe
>>     mention in
>>     the abstract that the doc also covers use cases?
>>
>>     <snip>
>>
>>        Although a Layer-2 solution can provide a support for multihop
>>        communications in vehicular networks, the scalability issue
>>     related
>>        to multihop forwarding still remains when vehicles need to
>>        disseminate or forward packets toward multihop-away
>>     destinations.  In
>>        addition, the IPv6-based approach for V2V as a network layer
>>     protocol
>>        can accommodate multiple radio technologies as MAC protocols,
>>     such as
>>        5G V2X and DSRC.  Therefore, the existing IPv6 protocol can be
>>        augmented through the addition of an Overlay Multilink Network
>>     (OMNI)
>>        Interface [OMNI] and/or protocol changes in order to support both
>>        wireless single-hop/multihop V2V communications and multiple radio
>>        technologies in vehicular networks.  In such a way, vehicles can
>>        communicate with each other by V2V communications to share
>>     either an
>>        emergency situation or road hazard in a highway having
>>     multiple kinds
>>        of radio technologies, such as 5G V2X and DSRC.
>>
>>     >>> This text appears in the middle of high level use case, with
>>     a crude list
>>     of protocols; this is not a place for it
>>
>>     >>> On a 6MAN Thread, Brian Carpenter said that the above:
>>     “
>>     is of concern regardless of the mention of OMNI. Does it mean
>>     "can be" or
>>     "needs to be"? This paragraph seems like a very short summary of
>>     a big problem
>>     area. At the end of page 13 there is some related discussion,
>>     which mentions
>>     RPL as part of the solution (good choice, IMHO) but again seems
>>     to depend on
>>     OMNI. I don't think the fix of simply removing references to OMNI
>>     works,
>>     because it would leave a gap. In an informational document, that
>>     is not a
>>     formal problem but as far as this draft describes architecture, I
>>     don't think
>>     that big a gap is reasonable. "OMNI" is mentioned more than 20
>>     times in the
>>     document. There are also several references to AERO, which is
>>     strongly
>>     associated with OMNI. “ >>> I agree with Brian. Here the document
>>     seems to be
>>     mixing solution with problem and putting the cart before the
>>     horse. My
>>     recommendation is to stick to what needs to be done that IPv6
>>     does not do yet
>>     -the reqs and gaps-; but the doc should not step in the how
>>     things will be done
>>     unless the group already decided to do it. The logical next steps
>>     to a PS are
>>     an applicability statement of existing work, and if the gaps
>>     cannot be filled,
>>     there may be one or more WG chartered to fill those gaps.
>>
>>     >>> I’d still be happy to see an annex with leads on where the
>>     solution might
>>     come from like RFC 8691 does.
>>
>>     <snip>
>>
>>        The existing IPv6 protocol must be augmented through the
>>     addition of
>>        an OMNI interface and/or protocol changes in order to support
>>        wireless multihop V2I communications in a highway where RSUs are
>>        sparsely deployed, so a vehicle can reach the wireless
>>     coverage of an
>>        RSU through the multihop data forwarding of intermediate vehicles.
>>        Thus, IPv6 needs to be extended for multihop V2I communications.
>>
>>     >>> Note that I have no clue on how well OMNI applies in that
>>     space, maybe it
>>     does very well; but here it comes out of the blue with no
>>     justification. If you
>>     mention OMNI you need to detail what it is and which of the V2V 
>>     problems you
>>     expect it to solve. But then, that’s beyond the scope of a PS.
>>
>>     <snip>
>>
>>        The existing IPv6 protocol must be augmented through the
>>     addition of
>>        an OMNI interface and/or protocol changes in order to support
>>        wireless multihop V2X (or V2I2X) communications in an urban road
>>        network where RSUs are deployed at intersections, so a vehicle
>>     (or a
>>        pedestrian's smartphone) can reach the wireless coverage of an RSU
>>        through the multihop data forwarding of intermediate vehicles (or
>>        pedestrians' smartphones).  Thus, IPv6 needs to be extended for
>>        multihop V2X (or V2I2X) communications.
>>
>>     >>> Please be more specific on what the missing functions are and
>>     whether they
>>     are missing from the stack development standpoint or if there’s
>>     work needed
>>     from the IETF. 1)      If something is really missing in our
>>     specs, the text to
>>     prove from the use case above is missing 2) how OMNI serves the
>>     use case
>>     could be elaborated in an applicability statement of OMNI for
>>     V2xyz, but it is
>>     a bit blunt to present it as panacea when the problems to be
>>     solved are not
>>     listed. 3)      If you look at it, OMNI seems like a software
>>     mobile router
>>     within a bump in the stack. Can that become too big?
>>
>>     >>> my view is that the text above and the similar occasions
>>     should be replaced
>>     by something like :
>>
>>        The existing IPv6 protocol must be augmented to provide the
>>     following
>>        functions: 1) …
>>
>>     >>> and / or something like:
>>
>>        In addition to the IPv6 node requirements [RFC 8504], the IPv6
>>     protocol
>>        stack for use in a vehicle must support 1) RFC blah, 2) …
>>
>>     <snip>
>>
>>        To support applications of these V2X use cases, the functions
>>     of IPv6
>>        such as VND, VMM, and VSP are prerequisites for IPv6-based packet
>>        exchange, transport-layer session continuity, and secure, safe
>>        communication between a vehicle and a pedestrian either
>>     directly or
>>        indirectly via an IP-RSU.
>>
>>     >>> “the functions of IPv6 such as VND, VMM, and VSP” does not
>>     parse. There’s
>>     no IPv6 reference that provides those functions. If the intention
>>     is to say
>>     that there’s stuff to add to IPv6 to support, like, say,  VND,
>>     then this
>>     document fails to define how an IPv6 VND should behave, though
>>     it’s precisely
>>     what I’d expect from a problem statement.
>>
>>     <snip>
>>
>>     4.  Vehicular Networks
>>
>>     >>> What is the purpose of section 4 as a whole, problem statement or
>>     applicability statement of the listed protocols? In the former
>>     case what’s the
>>     problem? In the latter case it is incomplete and needs to be
>>     exported to an
>>     applicability statement doc with all the possible technologies
>>     evaluated.
>>
>>        This section describes an example vehicular network architecture
>>        supporting V2V, V2I, and V2X communications in vehicular networks.
>>
>>     >>> I read this as presenting a context to explain what the
>>     problems are
>>     instead of presenting the IPVAWE “architecture”. Maybe using the term
>>     “Architecture” here is misleading and led to Bob’s comment.
>>
>>     <snip>
>>
>>     4.1.  Vehicular Network Architecture
>>
>>        Figure 1 shows an example vehicular network architecture for
>>     V2I and
>>        V2V in a road network [OMNI].
>>
>>     a.      Is using OMNI a decision that the WG made for the future
>>     work ? what
>>     does it do and what does it not do? b.      Is there work left to
>>     be done? Who
>>     will do that work? Or is it the expectation that OMNI has it all
>>     defined
>>     already?
>>
>>     <snip>
>>
>>        An existing network architecture (e.g., an IP-based aeronautical
>>        network architecture [OMNI][UAM-ITS], a network architecture of
>>        PMIPv6 [RFC5213], and a low-power and lossy network architecture
>>        [RFC6550]) can be extended to a vehicular network architecture for
>>        multihop V2V, V2I, and V2X, as shown in Figure 1.  In a highway
>>        scenario, a vehicle may not access an RSU directly because of the
>>        distance of the DSRC coverage (up to 1 km). For example, the OMNI
>>        interface and/or RPL (IPv6 Routing Protocol for Low-Power and
>>     Lossy
>>        Networks) [RFC6550] can be extended to support a multihop V2I
>>     since a
>>        vehicle can take advantage of other vehicles as relay nodes to
>>     reach
>>        the RSU.  Also, RPL can be extended to support both multihop
>>     V2V and
>>        V2X in the similar way.
>>
>>     >>> all this could fit well in annex; anyway you need to explain
>>     what you
>>     expect the protocols to do and which extension is needed. In the
>>     case of RPL at
>>     least you indicate that it would do routing, but not why you
>>     cannot use it of
>>     the shelf; for OMNI, what you expect is less clear, though
>>     there’s text
>>     elsewhere about the many radio interfaces that could be used for
>>     the purpose,
>>     and the text in the UAM below that is enlightening.
>>
>>     <snip>
>>
>>                                       To support not only the mobility
>>        management of the UAM end systems, but also the multihop and
>>        multilink communications of the UAM interfaces, the UAM end
>>     systems
>>        can employ an Overlay Multilink Network (OMNI) interface
>>     [OMNI] as a
>>        virtual Non-Broadcast Multiple Access (NBMA) connection to a
>>     serving
>>        ground domain infrastructure.
>>
>>     >>> Again, what is the expectation for OMNI? As an overlay it
>>     requires an
>>     underlay; when connecting to a MANET it needs support for that
>>     MANET. The text
>>     above seems to imply that is solves everything in V2xyz like
>>     magic; reminds me
>>     of the IPv6 multicast abstraction that was supposed to solve the
>>     broadcast
>>     problem and ended up worsening it.
>>
>>     <snip>
>>
>>                                 This infrastructure can be configured
>>        over the underlying data links.  The OMNI interface and its link
>>        model provide a means of multilink, multihop and mobility
>>        coordination to the legacy IPv6 ND messaging [RFC4861]
>>     according to
>>        the NBMA principle.  Thus, the OMNI link model can support
>>     efficient
>>        UAM internetworking services without additional mobility
>>     messaging,
>>        and without any modification to the IPv6 ND messaging services or
>>        link model.
>>
>>     >>> Again, what is the expectation for OMNI? As an overlay it
>>     requires an
>>     underlay; the text above seems to imply that is solves everything
>>     in V2xyz like
>>     magic; that would be a stretch, that reminds me of IPv6 multicast
>>     that was
>>     supposed to solve the broadcast problem and ended up worsening it.
>>
>>     <snip>
>>
>>        Multiple vehicles under the coverage of an RSU share a prefix
>>     just as
>>        mobile nodes share a prefix of a Wi-Fi access point in a wireless
>>        LAN.  This is a natural characteristic in infrastructure-based
>>        wireless networks.  For example, in Figure 1, two vehicles (i.e.,
>>        Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6
>>        global addresses for V2I communication. Alternatively, mobile
>>     nodes
>>        can employ an OMNI interface and use their own IPv6 Unique Local
>>        Addresses (ULAs) [RFC4193] over the wireless network without
>>        requiring the messaging of IPv6 Stateless Address
>>     Autoconfiguration
>>       (SLAAC) [RFC4862], which uses an on-link prefix provided by the
>>        (visited) wireless LAN; this technique is known as
>>     "Bring-Your-Own-
>>        Addresses".
>>
>>     >>>  Is OMNI the only way to "Bring-Your-Own-Addresses”? Else the
>>     text could be
>>     more generic, at least use e.g., like the ref to AERO later. >>>
>>     What are the
>>     implications / limitations of doing that – like they can do line
>>     of sight V2V
>>     but not reach the internet, or the need of  a local MANET / RPL
>>     that will
>>     accept to route those addresses, or the security / address
>>     ownership validation
>>     issues ?
>>
>>     <snip>
>>
>>        A single subnet prefix announced by an RSU can span multiple
>>     vehicles
>>        in VANET.  For example, in Figure 1, for Prefix 1, three vehicles
>>        (i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected
>>        VANET.  Also, for Prefix 2, two vehicles (i.e., Vehicle3 and
>>        Vehicle6) can construct another connected VANET, and for Prefix 3,
>>        two vehicles (i.e., Vehicle4 and Vehicle7) can construct another
>>        connected VANET.  Alternatively, each vehicle could employ an OMNI
>>        interface with their own ULAs such that no topologically-oriented
>>        subnet prefixes need be announced by the RSU.
>>
>>     >>>  same as above. This seems to restate the same thing, derive
>>     an address
>>     from a topologically correct prefix or use your own with
>>     limitations to be
>>     described.
>>
>>     <snip>
>>
>>        For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691]
>>        specifies several details, including Maximum Transmission Unit
>>     (MTU),
>>        frame format, link-local address, address mapping for unicast and
>>        multicast, stateless autoconfiguration, and subnet structure.  An
>>        Ethernet Adaptation (EA) layer is in charge of transforming some
>>        parameters between the IEEE 802.11 MAC layer and the IPv6 network
>>        layer, which is located between the IEEE 802.11-OCB's logical link
>>        control layer and the IPv6 network layer.  This IPv6 over
>>     802.11-OCB
>>        can be used for both V2V and V2I in IPv6-based vehicular networks.
>>
>>     >>>  solution space.
>>
>>     <snip>
>>
>>        An IPv6 mobility solution is needed for the guarantee of
>>        communication continuity in vehicular networks so that a vehicle's
>>        TCP session can be continued, or UDP packets can be delivered to a
>>        vehicle as a destination without loss while it moves from an
>>     IP-RSU's
>>        wireless coverage to another IP-RSU's wireless coverage.  In
>>        Figure 1, assuming that Vehicle2 has a TCP session (or a UDP
>>     session)
>>        with a corresponding node in the vehicular cloud, Vehicle2 can
>>     move
>>        from IP-RSU1's wireless coverage to IP-RSU2's wireless
>>     coverage.  In
>>        this case, a handover for Vehicle2 needs to be performed by
>>     either a
>>        host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a
>>        network-based mobility management scheme (e.g., PMIPv6
>>     [RFC5213] and
>>        AERO [RFC6706BIS]).
>>
>>        In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a
>>        role of a home agent.  On the other hand, in the network-based
>>        mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility
>>        management controller such as a Local Mobility Anchor (LMA) in
>>        PMIPv6, which also serves vehicles as a home agent, and an IP-RSU
>>        plays a role of an access router such as a Mobile Access Gateway
>>        (MAG) in PMIPv6 [RFC5213].  The host-based mobility scheme needs
>>        client functionality in IPv6 stack of a vehicle as a mobile
>>     node for
>>        mobility signaling message exchange between the vehicle and home
>>        agent.  On the other hand, the network-based mobility scheme
>>     does not
>>        need such a client functionality for a vehicle because the network
>>        infrastructure node (e.g., MAG in PMIPv6) as a proxy mobility
>>     agent
>>        handles the mobility signaling message exchange with the home
>>     agent
>>        (e.g., LMA in PMIPv6) for the sake of the vehicle.
>>
>>        There are a scalability issue and a route optimization issue
>>     in the
>>        network-based mobility scheme (e.g., PMIPv6) when an MA covers a
>>        large vehicular network governing many IP-RSUs.  In this case, a
>>        distributed mobility scheme (e.g., DMM [RFC7429]) can mitigate the
>>        scalability issue by distributing multiple MAs in the vehicular
>>        network such that they are positioned closer to vehicles for route
>>        optimization and bottleneck mitigation in a central MA in the
>>        network-based mobility scheme.  All these mobility approaches
>>     (i.e.,
>>        a host-based mobility scheme, network-based mobility scheme, and
>>        distributed mobility scheme) and a hybrid approach of a
>>     combination
>>        of them need to provide an efficient mobility service to vehicles
>>        moving fast and moving along with the relatively predictable
>>        trajectories along the roadways.
>>
>>        In vehicular networks, the control plane can be separated from the
>>        data plane for efficient mobility management and data
>>     forwarding by
>>        using the concept of Software-Defined Networking (SDN)
>>        [RFC7149][DMM-FPC].  Note that Forwarding Policy Configuration
>>     (FPC)
>>        in [DMM-FPC], which is a flexible mobility management system, can
>>        manage the separation of data-plane and control-plane in DMM.  In
>>        SDN, the control plane and data plane are separated for the
>>     efficient
>>        management of forwarding elements (e.g., switches and routers)
>>     where
>>        an SDN controller configures the forwarding elements in a
>>     centralized
>>        way and they perform packet forwarding according to their
>>     forwarding
>>        tables that are configured by the SDN controller.  An MA as an SDN
>>        controller needs to efficiently configure and monitor its
>>     IP-RSUs and
>>        vehicles for mobility management, location management, and
>>     security
>>        services.
>>
>>        The mobility information of a GPS receiver mounted in its vehicle
>>        (e.g., position, speed, and direction) can be used to accommodate
>>        mobility-aware proactive handover schemes, which can perform the
>>        handover of a vehicle according to its mobility and the wireless
>>        signal strength of a vehicle and an IP-RSU in a proactive way.
>>
>>        Vehicles can use the TCC as their Home Network having a home agent
>>        for mobility management as in MIPv6 [RFC6275] and PMIPv6
>>     [RFC5213],
>>        so the TCC (or an MA inside the TCC) maintains the mobility
>>        information of vehicles for location management.  IP tunneling
>>     over
>>        the wireless link should be avoided for performance efficiency.
>>        Also, in vehicular networks, asymmetric links sometimes exist and
>>        must be considered for wireless communications such as V2V and
>>     V2I.
>>
>>     >>>  This is all very informative text but does not state a
>>     problem. Is there a
>>     problem is left to be solved or are we assessing the applicability of
>>     protocols? Could it for instance, forward point to issues
>>     discussed in section
>>     5?
>>
>>     <snip>
>>
>>        As shown in Figure 3, as internal networks, a vehicle's moving
>>        network and an EN's fixed network are self-contained networks
>>     having
>>        multiple subnets and having an edge router (e.g., IP-OBU and
>>     IP-RSU)
>>        for the communication with another vehicle or another EN.  The
>>        internetworking between two internal networks via V2I
>>     communication
>>        requires the exchange of the network parameters and the network
>>        prefixes of the internal networks.  For the efficiency, the
>>     network
>>        prefixes of the internal networks (as a moving network) in a
>>     vehicle
>>        need to be delegated and configured automatically.  Note that a
>>        moving network's network prefix can be called a Mobile Network
>>     Prefix
>>        (MNP) [OMNI].
>>
>>     >>> Then again you’re overselling OMNI. MNP is originally defined
>>     here
>>     https://datatracker.ietf.org/doc/html/rfc3963#section-2
>>     <https://datatracker.ietf.org/doc/html/rfc3963#section-2> and
>>     that’s a reference
>>     you can use normatively.
>>
>>     <snip>
>>
>>        As shown in Figure 3, the addresses used for IPv6
>>     transmissions over
>>        the wireless link interfaces for IP-OBU and IP-RSU can be either
>>        global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be
>>        routed within vehicular networks [OMNI].
>>
>>     >>> Then again you’re overselling OMNI. There needs to  be a
>>     routing protocol
>>     like a MANET that will accept to carry the
>>      MNPs, and that must be implemented by the infra and both cars.
>>     The OMNI spec
>>      is clear on that. This is why at first glance I see OMNI as a
>>     full mobile
>>      router in a bump in the stack. Now what is the problem behind
>>     this? No such
>>      protocol at IETF? Too many to choose from? No deployment?
>>     <snip>
>>
>>     When global IPv6 addresses
>>        are used, wireless interface configuration and control
>>     overhead for
>>        Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener
>>        Discovery (MLD) [RFC2710][RFC3810] should be minimized to
>>     support V2I
>>        and V2X communications for vehicles moving fast along
>>     roadways; when
>>        ULAs and the OMNI interface are used, no DAD nor MLD messaging is
>>        needed.
>>
>>     >>> Then again you’re overselling OMNI. Isn’t it the no dad
>>     needed a property
>>     of injecting a BYOA in the fabric for an GUA MIP Home Address
>>     which is known to
>>     be unique at home? >>> OTOH, autoconf’ing a random ULA
>>     “FD…”prefix has lesser
>>     DAD properties than autoconf’ing a random 64bit IID in a
>>     classical subnet. So
>>     who says DAD isn’t required for OMNI ULA? >>> note that IMHO DAD
>>     on wireless is
>>     a lot more harm than good, and I agree that with a good pseudo
>>     random generator
>>     the ULA has no chance to collision in the real world, as OMNI
>>     claims. It’s just
>>     that your argument here plays the other way, because there are
>>     less random bits
>>     (56)  in the ULA prefix than in the IID (62), and if one starts
>>     using more
>>     prefix bits to be non-random, there will be a time when DAD on
>>     prefix is needed.
>>
>>     <snip>
>>
>>        Let us consider the upload/download time of a vehicle when it
>>     passes
>>        through the wireless communication coverage of an IP-RSU.  For a
>>        given typical setting where 1km is the maximum DSRC communication
>>        range [DSRC] and 100km/h is the speed limit in highway, the
>>     dwelling
>>        time can be calculated to be 72 seconds by dividing the
>>     diameter of
>>        the 2km (i.e., two times of DSRC communication range where an
>>     IP-RSU
>>        is located in the center of the circle of wireless
>>     communication) by
>>        the speed limit of 100km/h (i.e., about 28m/s).  For the 72
>>     seconds,
>>        a vehicle passing through the coverage of an IP-RSU can upload and
>>        download data packets to/from the IP-RSU.
>>
>>     <snip>
>>
>>     4.3.  V2V-based Internetworking
>>
>>     >>> In this section it looks like the cars are in a stable line
>>     of sight
>>     relationship. Which is probably fine for a platoon, but when you
>>     drive along
>>     with friends in different cars, you realize that the line of
>>     sight assumption
>>     does not stand over time. Soon enough, other cars meddle in, and
>>     possibly one
>>     of the cars drives faster and too far ahead so you need the infra
>>     to relay,
>>     possibly over multiple infra hops.
>>
>>     >>> so in this section, I’d expect to see a Vehicle communicating
>>     with another
>>     one and using either line of sight or V2V relaying but also using
>>     relay via V2I
>>     (multihop I2I not just hub and spoke V2I2V ), alternatively to
>>     together for
>>     redundancy. Is that part of the problem?
>>
>>     >>> reading deeper section 5 I found excellent text on routing
>>     via V and via I.
>>     This tells that section 4 does not play a good role at justifying
>>     section 5.
>>     Maybe keep section 4 for another doc?
>>
>>     >>> What kind or reliability is required in a V2V use case? Do
>>     you think ND can
>>     handle it? Or MANET? What would be the assumption on L2 (roaming
>>     time, unicast
>>     vs P2MP) and on L3 (reliability ala DetNet/RAW). Should we have
>>     some L3
>>     redundancy?
>>
>>     <snip>
>>
>>     5.  Problem Statement
>>
>>     <snip>
>>
>>        In order to specify protocols using the architecture mentioned in
>>        Section 4.1, IPv6 core protocols have to be adapted to overcome
>>        certain challenging aspects of vehicular networking.  Since the
>>        vehicles are likely to be moving at great speed, protocol
>>     exchanges
>>        need to be completed in a time relatively short compared to the
>>        lifetime of a link between a vehicle and an IP-RSU, or between two
>>        vehicles.
>>
>>     >>> Any order of magnitude?
>>     >>> Can you indicate whether this already rules out certain
>>     procedures, e.g.
>>     DAD ?
>>
>>        The lifetime of a session varies depending on the session's
>>     type such
>>        as a web surfing, voice call over IP, and DNS query. 
>>     Regardless of a
>>        session's type, to guide all the IPv6 packets to their destination
>>        host, IP mobility should be supported for the session.
>>
>>     >>> this seems to be for unicast when you know who to talk to. Is
>>     there a need
>>     some multicast groups like anybody around interested in topic
>>     blah like I could
>>     be multicasting the speed of vehicles coming the other way that I
>>     crossed
>>     recently, for use of vehicles that I’m crossing now, so they can
>>     see a slowdown
>>     on advance
>>
>>        Thus, the time constraint of a wireless link has a major impact on
>>        IPv6 Neighbor Discovery (ND).  Mobility Management (MM) is also
>>        vulnerable to disconnections that occur before the completion of
>>        identity verification and tunnel management. This is
>>     especially true
>>        given the unreliable nature of wireless communication.  This
>>     section
>>        presents key topics such as neighbor discovery and mobility
>>        management.
>>
>>     >>> Only ND? What about the MANET?
>>     >>> how fast should ND be to be suitable?
>>     >>> is there also a bandwidth check? You can make things much
>>     faster if you
>>     dedicate a lot of spectrum to it. But that can also be a waste.
>>
>>     5.1.  Neighbor Discovery
>>
>>     <snip>
>>
>>        The requirements for IPv6 ND for vehicular networks are
>>     efficient DAD
>>        and NUD operations.
>>
>>     >>> Not lookup? Is it the intention to use IP unicast over MAC
>>     broadcast, which
>>     is a good idea in my book?
>>
>>      <snip>
>>
>>           This merging and partitioning should be considered for the
>>        IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC)
>>        [RFC4862].
>>
>>     >>> Not lookup? Is it the intention to use IP unicast over MAC
>>     broadcast, which
>>     is a good idea in my book?
>>
>>      <snip>
>>
>>        Also, the partitioning of a VANET may make vehicles with the same
>>        prefix be physically unreachable.  Also, SLAAC needs to
>>     prevent IPv6
>>        address duplication due to the merging of VANETs.  According
>>     to the
>>        merging and partitioning, a destination vehicle (as an IPv6 host)
>>        needs to be distinguished as either an on-link host or an off-link
>>        host even though the source vehicle uses the same prefix as the
>>        destination vehicle.
>>
>>     >>> should reference to draft-nordmark-intarea-ippl
>>
>>        To efficiently prevent IPv6 address duplication due to the VANET
>>        partitioning and merging from happening in vehicular networks, the
>>        vehicular networks need to support a vehicular-network-wide DAD by
>>        defining a scope that is compatible with the legacy DAD.  In this
>>        case, two vehicles can communicate with each other when there
>>     exists
>>        a communication path over VANET or a combination of VANETs and IP-
>>        RSUs, as shown in Figure 1.  By using the
>>     vehicular-network-wide DAD,
>>        vehicles can assure that their IPv6 addresses are unique in the
>>        vehicular network whenever they are connected to the vehicular
>>        infrastructure or become disconnected from it in the form of
>>     VANET.
>>
>>     >>> Excellent
>>
>>        ND time-related parameters such as router lifetime and Neighbor
>>        Advertisement (NA) interval need to be adjusted for vehicle
>>     speed and
>>        vehicle density.  For example, the NA interval needs to be
>>        dynamically adjusted according to a vehicle's speed so that the
>>        vehicle can maintain its neighboring vehicles in a stable way,
>>        considering the collision probability with the NA messages sent by
>>        other vehicles.
>>
>>     >>> Is that a problem or just an operational setting that needs
>>     to be found?
>>     >>> Do we need to reconsider the concepts of those timers?
>>
>>     <snip>
>>
>>        Thus, in IPv6-based vehicular networking, IPv6 ND should have
>>     minimum
>>        changes for the interoperability with the legacy IPv6 ND used
>>     in the
>>        Internet, including the DAD and NUD operations.
>>
>>     >>> I do not find the logical link with the text before, why is
>>     this a “thus”?
>>     >>> why should the ND inside the VANET be constrained to be
>>     interoperable? This
>>     may place constraints on the solution.
>>
>>     5.1.1.  Link Model
>>
>>        A prefix model for a vehicular network needs to facilitate the
>>
>>     >>> Do you mean a “subnet model” as opposed to “prefix model”.
>>     >>> it would make this piece and the next should refer to
>>     draft-thubert-6man-ipv6-over-wireless for IPv6 over P2MP /NBMA,
>>     for both link
>>     and subnet issues. The general ideas are the same, but the gory
>>     details here
>>     are slightly incorrect, like this notion of prefix model than
>>     comes out of the
>>     blue. The model is really the subnet model for the subnet
>>     associated to P2MP.
>>
>>        communication between two vehicles with the same prefix
>>     regardless of
>>        the vehicular network topology as long as there exist
>>     bidirectional
>>        E2E paths between them in the vehicular network including
>>     VANETs and
>>        IP-RSUs.  This prefix model allows vehicles with the same
>>     prefix to
>>        communicate with each other via a combination of multihop V2V and
>>        multihop V2I with VANETs and IP-RSUs.  Note that the OMNI
>>     interface
>>        supports an NBMA link model where multihop V2V and V2I
>>     communications
>>        use each mobile node's ULAs without need for any DAD or MLD
>>        messaging.
>>
>>     >>> again overselling OMNI.
>>     >>> I kinda agree about the OMNI interface model, nothing against
>>     that. But you
>>     must see that there needs a lot more than what the OMNI interface
>>     to get
>>     packets across V and I hops to the destination. Like routing ala
>>     MANET,
>>     redundancy handling ala DetNet because it will be very lossy,
>>     path management
>>     ala RAW to optimize delivery vs. spectrum… And OMNI ignores ND so
>>     it does not
>>     solve the ND problems above.
>>
>>        IPv6 protocols work under certain assumptions that do not
>>     necessarily
>>        hold for vehicular wireless access link types other than OMNI/NBMA
>>        [VIP-WAVE][RFC5889]; the rest of this section discusses
>>     implications
>>        for those link types that do not apply when the OMNI/NBMA link
>>     model
>>
>>     >>> again overselling OMNI.
>>     >>> The keyword here is P2MP / NBMA, and OMNI is one interface
>>     that accepts
>>     that. There are others. IBM’s IPv4 over Frame relay was already
>>     P2MP / NBMA,
>>     using routing to complete the partial mesh in P2MP. The text
>>     seems to imply
>>     that OMNI is the only way to do that and that’s wrong. Also OMNI
>>     is loaded with
>>     other stuff than a plain P2MP capable interface. And ND over P2MP
>>     is not done
>>     by OMNI, OMNI only makes classical ND worse and only works in a
>>     full mesh. OTOH
>>     RFC 8505, which is designed to do ND for P2MP /NBMA would indeed
>>     work very well
>>     within an OMNI interface and solve those problems. >>> My point
>>     is that you
>>     need to tell the full story or refrain from entering solution
>>     space in this doc
>>
>>     <snip>
>>
>>        There is a relationship between a link and a prefix, besides the
>>        different scopes that are expected from the link-local and global
>>        types of IPv6 addresses.  In an IPv6 link, it is assumed that all
>>        interfaces which are configured with the same subnet prefix
>>     and with
>>        on-link bit set can communicate with each other on an IPv6 link.
>>
>>     >>> not assumed; that’s what the onlink but set tells. The
>>     conclusion should be
>>     that the VANET cannot set the O bit.
>>
>>        However, the vehicular link model needs to define the relationship
>>        between a link and a prefix, considering the dynamics of wireless
>>        links and the characteristics of VANET.
>>
>>     <snip>
>>
>>        From the previous observation, a vehicular link model should
>>     consider
>>        the frequent partitioning and merging of VANETs due to vehicle
>>        mobility.  Therefore, the vehicular link model needs to use an on-
>>        link prefix and off-link prefix according to the network
>>     topology of
>>        vehicles such as a one-hop reachable network and a multihop
>>     reachable
>>
>>     >>> No, the once a node saw a O bit set that sticks even if it
>>     sees other
>>     advertisements of the PIO with the O bit not set. >>> This is a
>>     global and
>>     intrinsic property of the prefix (and an attack vector that could
>>     be mentioned
>>     in the sec section). >>> the VANET prefix must never come with
>>     the O bit set.
>>
>>     <snip>
>>
>>        network (or partitioned networks).  If the vehicles with the same
>>        prefix are reachable from each other in one hop, the prefix
>>     should be
>>        on-link.
>>
>>     >>>> No, see above; but the router may redirect though it is
>>     really risky
>>     unless this is a stable situation like a parking place.
>>
>>        Thus, in IPv6-based vehicular networking, the vehicular link model
>>        should have minimum changes for interoperability with standard
>>     IPv6
>>        links in an efficient fashion to support IPv6 DAD, MLD and NUD
>>        operations.  When the OMNI NBMA link model is used, there are
>>     no link
>>        model changes nor DAD/MLD messaging required.
>>
>>     >>>> again overselling OMNI.
>>     >>>> You need a good P2MP subnet model with routing support when
>>     the mesh is
>>     partial. My company alone has been shipping million of nodes that
>>     build subnets
>>     of thousands, and that was done using IETF standards.
>>
>>     <snip>
>>
>>        For vehicular networks with high mobility and density, the DAD
>>     needs
>>        to be performed efficiently with minimum overhead so that the
>>        vehicles can exchange a driving safety message (e.g., collision
>>        avoidance and accident notification) with each other with a short
>>        interval (e.g., 0.5 second) by a technical report from NHTSA
>>        (National Highway Traffic Safety Administration)
>>     [NHTSA-ACAS-Report].
>>        Such a driving safety message may include a vehicle's mobility
>>        information (i.e., position, speed, direction, and acceleration/
>>        deceleration).  The exchange interval of this message is 0.5
>>     second,
>>        which is required to allow a driver to avoid a rear-end crash from
>>        another vehicle.
>>
>>     >>> IPv6 over broadcast MAC (used to be called internet 0, 10+
>>     years ago)
>>     solves that MAC issue since there is no MAC.
>>
>>     5.1.3.  Routing
>>
>>        For multihop V2V communications in either a VANET or VANETs
>>     via IP-
>>        RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing
>>     protocol may
>>        be required to support both unicast and multicast in the links
>>     of the
>>        subnet with the same IPv6 prefix.  However, it will be costly
>>     to run
>>        both vehicular ND and a vehicular ad hoc routing protocol in
>>     terms of
>>        control traffic overhead [ID-Multicast-Problems].
>>
>>     >>> we do that with IETF standards on battery operated devices
>>     already. Using
>>     RFC 8505 for the UNI and RPL for the NNI. It is scalable (we’ve
>>     seen 30 hops in
>>     meshes of thousands in the real world though it’s not the normal
>>     operational
>>     model, but can happen to maintain connectivity during the reboot
>>     of a root) and
>>     does not use broadcast. RPL was initially designed as a V2V2V
>>     protocol but
>>     found its market on the IoT. I’m sure the protocol would gladly
>>     come back to
>>     its roots.
>>
>>        A routing protocol for a VANET may cause redundant wireless
>>     frames in
>>        the air to check the neighborhood of each vehicle and compute the
>>        routing information in a VANET with a dynamic network topology
>>        because the IPv6 ND is used to check the neighborhood of each
>>        vehicle.  Thus, the vehicular routing needs to take advantage
>>     of the
>>        IPv6 ND to minimize its control overhead.
>>
>>     >>> A clean description of the interaction of RPL and RFC 8505 in
>>     our IoT
>>     networks. Note that the speed of the PHY in VANET balanced the
>>     instability of
>>     the topology, and RPL still applies. Note also that RPL uses DV
>>     with a routing
>>     stretch in order to minimize the topology awareness that’s needed
>>     in each node,
>>     which results in minimal signaling.
>>
>>     5.2.  Mobility Management
>>
>>     <snip>
>>
>>        For a mobility management scheme in a shared link, where the
>>     wireless
>>        subnets of multiple IP-RSUs share the same prefix, an efficient
>>        vehicular-network-wide DAD is required.  If DHCPv6 is used to
>>     assign
>>        a unique IPv6 address to each vehicle in this shared link,
>>
>>     >>> I would not use the term link, or shared. Maybe shared link
>>     -> domain?
>>     <snip>
>>
>>     the DAD is
>>        not required.  On the other hand, for a mobility management scheme
>>        with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213]
>>     and OMNI
>>        [OMNI]), DAD is not required because the IPv6 address of a
>>     vehicle's
>>        external wireless interface is guaranteed to be unique.
>>
>>     >>> again overselling OMNI
>>     >>> As I said earlier, this is wring there are (64*) more chances
>>     of a
>>     collision in OMNI prefixes than in IPv6 IIDs. >>> OMNI prefixes
>>     can collision,
>>     home addresses that are unique on a home network cannot. >>> Now
>>     if both the
>>     OMNI prefix and the IID are good randoms, then obviously, the
>>     chances of
>>     collisions round up to 0. >>> Collision is certainly not my worst
>>     fear.
>>
>>       There is a
>>        tradeoff between the prefix usage efficiency and DAD
>>     overhead.  Thus,
>>        the IPv6 address autoconfiguration for vehicular networks needs to
>>        consider this tradeoff to support efficient mobility management.
>>
>>     >>> This is way too superficial and hides the reality of things.
>>     - Using a VANET Infra prefix allows direct routability to the
>>     internet which
>>     BYOA does not since the BYOA is not topologically correct. Yes,
>>     it costs a DAD
>>     with classic ND, but it does not with RCF8505 and the draft fails
>>     to mention
>>     that. - A BYOA needs a tunnel home, and the node needs to know
>>     who is reachable
>>     inside the VANET and what is not to decide to tunnel or not; this
>>     is a
>>     difficult problem (vs. control place overhead) that is not
>>     discussed here.
>>
>>     <snip>
>>
>>        For the case of a multihomed network, a vehicle can follow the
>>     first-
>>        hop router selection rule described in [RFC8028].  That is, the
>>        vehicle should select its default router for each prefix by
>>        preferring the router that advertised the prefix.
>>
>>     >>> Still router discovery (in and out) must be very fast. Thing
>>     of the RA
>>     intervale in MIPv6. Is that sufficient? Too expensive?
>>
>>     <snip>
>>
>>     6.  Security Considerations
>>     >>> Any discussion on the security of classical ND and other
>>     operational issues
>>     (rfc6583) ?
>>
>>     <snip>
>>
>>        Security and privacy are paramount in V2I, V2V, and V2X
>>     networking.
>>        Vehicles and infrastructure must be authenticated in order to
>>        participate in vehicular networking.  Also, in-vehicle devices
>>     (e.g.,
>>        ECU) and a driver/passenger's mobile devices (e.g., smartphone and
>>        tablet PC) in a vehicle need to communicate with other in-vehicle
>>        devices and another driver/passenger's mobile devices in another
>>        vehicle, or other servers behind an IP-RSU in a secure way.  Even
>>        though a vehicle is perfectly authenticated and legitimate, it
>>     may be
>>        hacked for running malicious applications to track and collect its
>>        and other vehicles' information.  In this case, an attack
>>     mitigation
>>        process may be required to reduce the aftermath of malicious
>>        behaviors.
>>
>>     >>> The section should mention that both with classical ND and
>>     BYOA, addresses
>>     can be impersonated, and RFC 8928 protects against that in both
>>     cases while
>>     maintaining privacy.
>>
>>        Even though vehicles can be authenticated with valid
>>     certificates by
>>        an authentication server in the vehicular cloud, the authenticated
>>
>>     >>> Is PKI feasible (deploying it in every car?). Is it fast
>>     enough? Is it
>>     really what IPWAVE thinks vehicle should use????? >>> e.g. why
>>     would one need
>>     to authenticate to a V2I network? >>> from the text earlier in
>>     the doc, it
>>     seemed that what you really want is access that is fast to join,
>>     capable of
>>     offering the reachability you want, anonymous, and innocuous
>>     (cars can not harm
>>     one another).
>>
>>        vehicles may harm other vehicles, so their communication
>>     activities
>>        need to be logged in either a central way through a logging server
>>        (e.g., TCC) in the vehicular cloud or a distributed way (e.g.,
>>        blockchain [Bitcoin]) along with other vehicles or infrastructure.
>>        For the non-repudiation of the harmful activities of malicious
>>     nodes,
>>        a blockchain technology can be used [Bitcoin]. Each message from a
>>        vehicle can be treated as a transaction and the neighboring
>>     vehicles
>>        can play the role of peers in a consensus method of a blockchain
>>        [Bitcoin][Vehicular-BlockChain].  For a blockchain's efficient
>>        consensus in vehicular networks having fast moving vehicles, a new
>>        consensus algorithm needs to be developed or an existing consensus
>>        algorithm needs to be enhanced.
>>
>>     >>> solution space; better express the security needs since this
>>     is a PS.
>>
>>     <snip>
>>
>>        To identify malicious vehicles among vehicles, an authentication
>>        method is required.
>>
>>     >>> No. As said earlier a vehicle can be infected. You need
>>     innocuousness.which
>>     can come from things like isolation, zerotrust, and protocols
>>     that are
>>     difficult to hack around. Classical IPv6 ND is open bar. RFC
>>     8505/8928 is
>>     protected by construction, anonymous, and fast.
>>
>>     <snip>
>>
>>        For the setup of a secure channel over IPsec or TLS, the
>>     multihop V2I
>>        communications over DSRC is required in a highway for the
>>        authentication by involving multiple intermediate vehicles as
>>     relay
>>        nodes toward an IP-RSU connected to an authentication server
>>     in the
>>        vehicular cloud.  The V2I communications over 5G V2X (or LTE
>>     V2X) is
>>        required to allow a vehicle to communicate directly with a
>>     gNodeB (or
>>        eNodeB) connected to an authentication server in the vehicular
>>     cloud.
>>
>>     >>> solution space. Instead, you could mention that setting up
>>     secured channels
>>     between cars that cross one another might not complete in time to
>>     establish the
>>     communication channel, and that the innocuousness must come from
>>     zerotrust in
>>     the transactions between the cars.
>>        For the IPv6 ND, the DAD is required to ensure the uniqueness
>>     of the
>>        IPv6 address of a vehicle's wireless interface.
>>
>>     >>> for classical ND (SLAAC) that’s true. That is not with RFC
>>     8505, since the
>>     infra maintains a table of all addresses in use in the prefix and
>>     blocks
>>     duplicates without the RFC 4862 DAD method. The stateful autoconf
>>     address grant
>>     is immediate.
>>
>>                                    This DAD can be used
>>        as a flooding attack that uses the DAD-related ND packets
>>        disseminated over the VANET or vehicular networks.
>>
>>     >>> also for DOS attacks. You can block a owner from using an
>>     address. A
>>     reference to rfc6959 is much needed here.
>>
>>     <snip>
>>
>>      This possibility
>>        indicates that the vehicles and IP-RSUs need to filter out
>>     suspicious
>>        ND traffic in advance.  Based on the SEND [RFC3971] mechanism, the
>>        authentication for routers (i.e., IP-RSUs) can be conducted by
>>     only
>>        selecting an IP-RSU that has a certification path toward trusted
>>        parties.  For authenticating other vehicles, the cryptographically
>>        generated address (CGA) can be used to verify the true owner of a
>>        received ND message, which requires to use the CGA ND option
>>     in the
>>        ND protocols.  For a general protection of the ND mechanism,
>>     the RSA
>>        Signature ND option can also be used to protect the integrity
>>     of the
>>        messages by public key signatures.  For a more advanced
>>        authentication mechanism, a distributed blockchain-based mechanism
>>        [Vehicular-BlockChain] can be used.
>>
>>     >>> solution space. Again, the draft should focus on problems and
>>     needs. The
>>     problem here is that SEND is complex, and not implemented in the
>>     major stack.
>>     It relies on PKI for trusting the router. The V2I need is a
>>     zerotrust model
>>     where one V, the other local Vs, and the I, can help each other
>>     anonymously and
>>     harmlessly. <snip>
>>
>>     8.  Informative References
>>
>>     >>> no normative reference?
>>
>>     >>> no normative reference?
>>
>>     <snip>
>>
>>     Voila!
>>
>>     Keep safe;
>>
>>     Pascal
>>
>>
>>
>>     _______________________________________________
>>     its mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/its
>>     <https://www.ietf.org/mailman/listinfo/its>
>>
>>
>> _______________________________________________
>> its mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its