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