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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Thanks a lot Pascal! This is extremely helpful.

Carlos

On Wed, Sep 1, 2021 at 10:09 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Hello Carlos
>
> Will do ASAP 😀
>
>
> Regards,
>
> Pascal
>
> Le 1 sept. 2021 à 20:49, CARLOS JESUS BERNARDOS CANO <[e-mail]> a
> écrit :
>
> 
> Thanks Paul for the review!
>
> Pascal, would it be possible for you to take a look and comment if you are
> happy with the new version?
>
> Thanks!
>
> Carlos
>
> On Mon, Aug 30, 2021 at 3:13 PM Mr. Jaehoon Paul Jeong <
> [e-mail]> wrote:
>
>> Hi Pascal,
>> Here is the revision (-21) of IPWAVE PS Draft:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-21
>>
>> I attach the revision letter to show how I have addressed your comments
>> on the revision.
>>
>> Chris and I have worked for this revision together.
>>
>> If you have further comments, please let me know.
>>
>> Thanks.
>>
>> Best Regards,
>> Paul
>>
>>
>>
>> On Fri, Jun 18, 2021 at 4:42 PM Pascal Thubert via Datatracker <
>> [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 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]
>>> https://www.ietf.org/mailman/listinfo/its
>>>
>>