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

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

Great! Thanks,

Carlos

On Sun, 20 Jun 2021 at 09:44, Mr. Jaehoon Paul Jeong <[e-mail]>
wrote:

> Hi Carlos and Pascal,
> I am working on the revision with Pascal's comments.
>
> Thanks.
>
> Best Regards,
> Paul
>
> 2021년 6월 19일 (토) 오후 6:42, CARLOS JESUS BERNARDOS CANO <[e-mail]>님이
> 작성:
>
>> Authors, please check carefully and address the comments from the very
>> good review from Pascal. Include the IPWAVE list when responding to the
>> review.
>>
>> And huge thanks Pascal for this terrific review!
>>
>> Carlos
>>
>> ---------- Forwarded message ---------
>> From: Pascal Thubert via Datatracker <[e-mail]>
>> Date: Fri, Jun 18, 2021 at 9:42 AM
>> Subject: Intdir last call review of
>> draft-ietf-ipwave-vehicular-networking-20
>> To: <[e-mail]>
>> Cc: <[e-mail]>, <[e-mail]>,
>> <[e-mail]>
>>
>>
>> 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
>
>
>> --
> ===========================
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Associate Professor
> Department Head
> Department of Computer Science and Engineering
> Sungkyunkwan University
> Office: [phone]
> Email: [e-mail], [e-mail]
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
-- 
Sent from a mobile device, please excuse any brevity or typing errors.