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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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
>