< draft-ietf-ipwave-vehicular-networking-24.txt   draft-ietf-ipwave-vehicular-networking-25.txt >
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational 9 October 2021 Intended status: Informational 13 February 2022
Expires: 12 April 2022 Expires: 17 August 2022
IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem
Statement and Use Cases Statement and Use Cases
draft-ietf-ipwave-vehicular-networking-24 draft-ietf-ipwave-vehicular-networking-25
Abstract Abstract
This document discusses the problem statement and use cases of This document discusses the problem statement and use cases of
IPv6-based vehicular networking for Intelligent Transportation IPv6-based vehicular networking for Intelligent Transportation
Systems (ITS). The main scenarios of vehicular communications are Systems (ITS). The main scenarios of vehicular communications are
vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
vehicle-to-everything (V2X) communications. First, this document vehicle-to-everything (V2X) communications. First, this document
explains use cases using V2V, V2I, and V2X networking. Next, for explains use cases using V2V, V2I, and V2X networking. Next, for
IPv6-based vehicular networks, it makes a gap analysis of current IPv6-based vehicular networks, it makes a gap analysis of current
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 April 2022. This Internet-Draft will expire on 17 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12
4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 13
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 17
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 22
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 24
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 26
5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 29 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 31
6.2. Security Threats in Mobility Management . . . . . . . . . 33 6.2. Security Threats in Mobility Management . . . . . . . . . 32
6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Support of Multiple Radio Technologies for V2V . . . 44 Appendix A. Support of Multiple Radio Technologies for V2V . . . 44
Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45 Appendix B. Support of Multihop V2X Networking . . . . . . . . . 44
Appendix C. Support of Mobility Management for V2I . . . . . . . 47 Appendix C. Support of Mobility Management for V2I . . . . . . . 46
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 48 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 47
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 48 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
Vehicular networking studies have mainly focused on improving safety Vehicular networking studies have mainly focused on improving safety
and efficiency, and also enabling entertainment in vehicular and efficiency, and also enabling entertainment in vehicular
networks. The Federal Communications Commission (FCC) in the US networks. The Federal Communications Commission (FCC) in the US
allocated wireless channels for Dedicated Short-Range Communications allocated wireless channels for Dedicated Short-Range Communications
(DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with
the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC-
based wireless communications can support vehicle-to-vehicle (V2V), based wireless communications can support vehicle-to-vehicle (V2V),
skipping to change at page 3, line 46 skipping to change at page 3, line 46
[TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly [TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly
communicate with each other without relay nodes (e.g., eNodeB in LTE communicate with each other without relay nodes (e.g., eNodeB in LTE
and gNodeB in 5G). and gNodeB in 5G).
Along with these WAVE standards and C-V2X standards, regardless of a Along with these WAVE standards and C-V2X standards, regardless of a
wireless access technology under the IP stack of a vehicle, vehicular wireless access technology under the IP stack of a vehicle, vehicular
networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6
protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6)
[RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network
Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP) Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP)
[RFC6830BIS], and Automatic Extended Route Optimization (AERO) [I-D.ietf-lisp-rfc6830bis], and Asymmetric Extended Route
[AERO]). In addition, ISO has approved a standard specifying the Optimization (AERO) [I-D.templin-6man-aero]). In addition, ISO has
IPv6 network protocols and services to be used for Communications approved a standard specifying the IPv6 network protocols and
Access for Land Mobiles (CALM) [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1]. services to be used for Communications Access for Land Mobiles (CALM)
[ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1].
This document describes use cases and a problem statement about This document describes use cases and a problem statement about
IPv6-based vehicular networking for ITS, which is named IPv6 Wireless IPv6-based vehicular networking for ITS, which is named IPv6 Wireless
Access in Vehicular Environments (IPWAVE). First, it introduces the Access in Vehicular Environments (IPWAVE). First, it introduces the
use cases for using V2V, V2I, and V2X networking in ITS. Next, for 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-based vehicular networks, it makes a gap analysis of current
IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
and Security & Privacy), and then enumerates requirements for the and Security & Privacy), and then enumerates requirements for the
extensions of those IPv6 protocols, which are tailored to IPv6-based extensions of those IPv6 protocols, which are tailored to IPv6-based
vehicular networking. Thus, this document is intended to motivate vehicular networking. Thus, this document is intended to motivate
skipping to change at page 7, line 51 skipping to change at page 7, line 51
* Context-aware navigation for safe driving and collision avoidance; * Context-aware navigation for safe driving and collision avoidance;
* Cooperative adaptive cruise control in a roadway; * Cooperative adaptive cruise control in a roadway;
* Platooning in a highway; * Platooning in a highway;
* Cooperative environment sensing; * Cooperative environment sensing;
* Collision avoidance service of end systems of Urban Air Mobility * Collision avoidance service of end systems of Urban Air Mobility
(UAM) [UAM-ITS]. (UAM) [I-D.templin-ipwave-uam-its].
These five techniques will be important elements for autonomous These five techniques will be important elements for autonomous
vehicles, which may be either terrestrial vehicles or UAM end vehicles, which may be either terrestrial vehicles or UAM end
systems. systems.
Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
to drive safely by alerting them to dangerous obstacles and to drive safely by alerting them to dangerous obstacles and
situations. That is, a CASD navigator displays obstacles or situations. That is, a CASD navigator displays obstacles or
neighboring vehicles relevant to possible collisions in real-time neighboring vehicles relevant to possible collisions in real-time
through V2V networking. CASD provides vehicles with a class-based through V2V networking. CASD provides vehicles with a class-based
skipping to change at page 14, line 19 skipping to change at page 14, line 9
vehicles (including IP-OBU), IP-RSUs, Mobility Anchor, Traffic vehicles (including IP-OBU), IP-RSUs, Mobility Anchor, Traffic
Control Center, and Vehicular Cloud as components. These components Control Center, and Vehicular Cloud as components. These components
are not mandatory, and they can be deployed into vehicular networks are not mandatory, and they can be deployed into vehicular networks
in various ways. Some of them (e.g., Mobility Anchor, Traffic in various ways. Some of them (e.g., Mobility Anchor, Traffic
Control Center, and Vehicular Cloud) may not be needed for the Control Center, and Vehicular Cloud) may not be needed for the
vehicular networks according to target use cases in Section 3. vehicular networks according to target use cases in Section 3.
Existing network architectures, such as the network architectures of Existing network architectures, such as the network architectures of
PMIPv6 [RFC5213], RPL (IPv6 Routing Protocol for Low-Power and Lossy PMIPv6 [RFC5213], RPL (IPv6 Routing Protocol for Low-Power and Lossy
Networks) [RFC6550], and OMNI (Overlay Multilink Network Interface) Networks) [RFC6550], and OMNI (Overlay Multilink Network Interface)
[OMNI], can be extended to a vehicular network architecture for [I-D.templin-6man-omni], can be extended to a vehicular network
multihop V2V, V2I, and V2X, as shown in Figure 1. Refer to architecture for multihop V2V, V2I, and V2X, as shown in Figure 1.
Appendix B for the detailed discussion on multihop V2X networking by Refer to Appendix B for the detailed discussion on multihop V2X
RPL and OMNI. networking by RPL and OMNI.
As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU
have wireless media interfaces for VANET. Furthermore, the wireless have wireless media interfaces for VANET. Furthermore, the wireless
media interfaces are autoconfigured with a global IPv6 prefix (e.g., media interfaces are autoconfigured with a global IPv6 prefix (e.g.,
2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that
2001:DB8::/32 is a documentation prefix [RFC3849] for example 2001:DB8::/32 is a documentation prefix [RFC3849] for example
prefixes in this document, and also that any routable IPv6 address prefixes in this document, and also that any routable IPv6 address
needs to be routable in a VANET and a vehicular network including IP- needs to be routable in a VANET and a vehicular network including IP-
RSUs. RSUs.
skipping to change at page 15, line 37 skipping to change at page 15, line 28
communication continuity in vehicular networks so that a vehicle's communication continuity in vehicular networks so that a vehicle's
TCP session can be continued, or UDP packets can be delivered to a 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 vehicle as a destination without loss while it moves from an IP-RSU's
wireless coverage to another IP-RSU's wireless coverage. In wireless coverage to another IP-RSU's wireless coverage. In
Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session) Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session)
with a corresponding node in the vehicular cloud, Vehicle2 can move with a corresponding node in the vehicular cloud, Vehicle2 can move
from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In 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 this case, a handover for Vehicle2 needs to be performed by either a
host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a
network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and
AERO [AERO]). This document describes issues in mobility management AERO [I-D.templin-6man-aero]). This document describes issues in
for vehicular networks in Section 5.2. mobility management for vehicular networks in Section 5.2.
4.2. V2I-based Internetworking 4.2. V2I-based Internetworking
This section discusses the internetworking between a vehicle's This section discusses the internetworking between a vehicle's
internal network (i.e., moving network) and an EN's internal network internal network (i.e., moving network) and an EN's internal network
(i.e., fixed network) via V2I communication. The internal network of (i.e., fixed network) via V2I communication. The internal network of
a vehicle is nowadays constructed with Ethernet by many automotive a vehicle is nowadays constructed with Ethernet by many automotive
vendors [In-Car-Network]. Note that an EN can accommodate multiple vendors [In-Car-Network]. Note that an EN can accommodate multiple
routers (or switches) and servers (e.g., ECDs, navigation server, and routers (or switches) and servers (e.g., ECDs, navigation server, and
DNS server) in its internal network. DNS server) in its internal network.
skipping to change at page 24, line 11 skipping to change at page 23, line 11
VANET may make vehicles with the same prefix be physically VANET may make vehicles with the same prefix be physically
unreachable. An address lookup operation may be conducted by an MA unreachable. An address lookup operation may be conducted by an MA
or IP-RSU (as Registrar in RPL) to check the existence of a vehicle or IP-RSU (as Registrar in RPL) to check the existence of a vehicle
under the network coverage of the MA or IP-RSU as NUD. Thus, SLAAC under the network coverage of the MA or IP-RSU as NUD. Thus, SLAAC
needs to prevent IPv6 address duplication due to the merging of needs to prevent IPv6 address duplication due to the merging of
VANETs, and IPv6 ND needs to detect unreachable neighboring vehicles VANETs, and IPv6 ND needs to detect unreachable neighboring vehicles
due to the partitioning of a VANET. According to the merging and due to the partitioning of a VANET. According to the merging and
partitioning, a destination vehicle (as an IPv6 host) needs to be partitioning, a destination vehicle (as an IPv6 host) needs to be
distinguished as either an on-link host or an off-link host even distinguished as either an on-link host or an off-link host even
though the source vehicle can use the same prefix as the destination though the source vehicle can use the same prefix as the destination
vehicle [ID-IPPL]. vehicle [I-D.ietf-intarea-ippl].
To efficiently prevent IPv6 address duplication due to the VANET To efficiently prevent IPv6 address duplication due to the VANET
partitioning and merging from happening in vehicular networks, the partitioning and merging from happening in vehicular networks, the
vehicular networks need to support a vehicular-network-wide DAD by vehicular networks need to support a vehicular-network-wide DAD by
defining a scope that is compatible with the legacy DAD. In this defining a scope that is compatible with the legacy DAD. In this
case, two vehicles can communicate with each other when there exists case, two vehicles can communicate with each other when there exists
a communication path over VANET or a combination of VANETs and IP- 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, RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD,
vehicles can assure that their IPv6 addresses are unique in the vehicles can assure that their IPv6 addresses are unique in the
vehicular network whenever they are connected to the vehicular vehicular network whenever they are connected to the vehicular
skipping to change at page 25, line 26 skipping to change at page 24, line 26
use the standard IPv6 network settings. use the standard IPv6 network settings.
5.1.1. Link Model 5.1.1. Link Model
A subnet model for a vehicular network needs to facilitate the A subnet model for a vehicular network needs to facilitate the
communication between two vehicles with the same prefix regardless of communication between two vehicles with the same prefix regardless of
the vehicular network topology as long as there exist bidirectional the vehicular network topology as long as there exist bidirectional
E2E paths between them in the vehicular network including VANETs and E2E paths between them in the vehicular network including VANETs and
IP-RSUs. This subnet model allows vehicles with the same prefix to IP-RSUs. This subnet model allows vehicles with the same prefix to
communicate with each other via a combination of multihop V2V and communicate with each other via a combination of multihop V2V and
multihop V2I with VANETs and IP-RSUs. [IPoWIRELESS] introduces other multihop V2I with VANETs and IP-RSUs.
issues in an IPv6 subnet model. [I-D.thubert-6man-ipv6-over-wireless] introduces other issues in an
IPv6 subnet model.
IPv6 protocols work under certain assumptions that do not necessarily IPv6 protocols work under certain assumptions that do not necessarily
hold for vehicular wireless access link types [VIP-WAVE][RFC5889]. hold for vehicular wireless access link types [VIP-WAVE][RFC5889].
For instance, some IPv6 protocols assume symmetry in the connectivity For instance, some IPv6 protocols assume symmetry in the connectivity
among neighboring interfaces [RFC6250]. However, radio interference among neighboring interfaces [RFC6250]. However, radio interference
and different levels of transmission power may cause asymmetric links and different levels of transmission power may cause asymmetric links
to appear in vehicular wireless links. As a result, a new vehicular to appear in vehicular wireless links. As a result, a new vehicular
link model needs to consider the asymmetry of dynamically changing link model needs to consider the asymmetry of dynamically changing
vehicular wireless links. vehicular wireless links.
skipping to change at page 27, line 40 skipping to change at page 26, line 40
needs to be updated, and the uniqueness of the address needs to be needs to be updated, and the uniqueness of the address needs to be
checked through the DAD procedure. checked through the DAD procedure.
5.1.3. Routing 5.1.3. Routing
For multihop V2V communications in either a VANET or VANETs via IP- For multihop V2V communications in either a VANET or VANETs via IP-
RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may
be required to support both unicast and multicast in the links of the 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 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 both vehicular ND and a vehicular ad hoc routing protocol in terms of
control traffic overhead [ID-Multicast-Problems]. control traffic overhead [RFC9119].
A routing protocol for a VANET may cause redundant wireless frames in A routing protocol for a VANET may cause redundant wireless frames in
the air to check the neighborhood of each vehicle and compute the the air to check the neighborhood of each vehicle and compute the
routing information in a VANET with a dynamic network topology routing information in a VANET with a dynamic network topology
because the IPv6 ND is used to check the neighborhood of each because the IPv6 ND is used to check the neighborhood of each
vehicle. Thus, the vehicular routing needs to take advantage of the vehicle. Thus, the vehicular routing needs to take advantage of the
IPv6 ND to minimize its control overhead. IPv6 ND to minimize its control overhead.
RPL [RFC6550] defines a routing protocol for low-power and lossy RPL [RFC6550] defines a routing protocol for low-power and lossy
networks, which constructs and maintains Destination-Oriented networks, which constructs and maintains Destination-Oriented
skipping to change at page 34, line 36 skipping to change at page 33, line 36
[Bitcoin] [Vehicular-BlockChain]. For a blockchain's efficient [Bitcoin] [Vehicular-BlockChain]. For a blockchain's efficient
consensus in vehicular networks having fast moving vehicles, a new consensus in vehicular networks having fast moving vehicles, a new
consensus algorithm needs to be developed or an existing consensus consensus algorithm needs to be developed or an existing consensus
algorithm needs to be enhanced. algorithm needs to be enhanced.
To prevent an adversary from tracking a vehicle with its MAC address To prevent an adversary from tracking a vehicle with its MAC address
or IPv6 address, especially for a long-living transport-layer session or IPv6 address, especially for a long-living transport-layer session
(e.g., voice call over IP and video streaming service), a MAC address (e.g., voice call over IP and video streaming service), a MAC address
pseudonym needs to be provided to each vehicle; that is, each vehicle pseudonym needs to be provided to each vehicle; that is, each vehicle
periodically updates its MAC address and its IPv6 address needs to be periodically updates its MAC address and its IPv6 address needs to be
updated accordingly by the MAC address change [RFC4086][RFC4941]. updated accordingly by the MAC address change [RFC4086][RFC8981].
Such an update of the MAC and IPv6 addresses should not interrupt the Such an update of the MAC and IPv6 addresses should not interrupt the
E2E communications between two vehicles (or between a vehicle and an E2E communications between two vehicles (or between a vehicle and an
IP-RSU) for a long-living transport-layer session. However, if this IP-RSU) for a long-living transport-layer session. However, if this
pseudonym is performed without strong E2E confidentiality (using pseudonym is performed without strong E2E confidentiality (using
either IPsec or TLS), there will be no privacy benefit from changing either IPsec or TLS), there will be no privacy benefit from changing
MAC and IPv6 addresses, because an adversary can observe the change MAC and IPv6 addresses, because an adversary can observe the change
of the MAC and IPv6 addresses and track the vehicle with those of the MAC and IPv6 addresses and track the vehicle with those
addresses. Thus, the MAC address pseudonym and the IPv6 address addresses. Thus, the MAC address pseudonym and the IPv6 address
update should be performed with strong E2E confidentiality. update should be performed with strong E2E confidentiality.
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Support for IPv6 Networks Operating Outside the Context of Listener Discovery (MLD) for IPv6", RFC 2710,
a Basic Service Set over IEEE Std 802.11", RFC 8691, DOI 10.17487/RFC2710, October 1999,
December 2019, <https://www.rfc-editor.org/rfc/rfc8691>. <https://www.rfc-editor.org/info/rfc2710>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
Support in IPv6", RFC 6275, July 2011, State Routing Protocol (OLSR)", RFC 3626,
<https://www.rfc-editor.org/rfc/rfc6275>. DOI 10.17487/RFC3626, October 2003,
<https://www.rfc-editor.org/info/rfc3626>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
RFC 5213, August 2008, <https://www.rfc-editor.org/info/rfc3753>.
<https://www.rfc-editor.org/rfc/rfc5213>.
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
"Requirements for Distributed Mobility Management", Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
RFC 7333, August 2014, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/rfc/rfc7333>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Bernardos, "Distributed Mobility Management: Current Reserved for Documentation", RFC 3849,
Practices and Gap Analysis", RFC 7429, January 2015, DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/rfc/rfc7429>. <https://www.rfc-editor.org/info/rfc3849>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005, RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/rfc/rfc3963>. <https://www.rfc-editor.org/info/rfc3963>.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012,
<https://www.rfc-editor.org/rfc/rfc6550>.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004,
<https://www.rfc-editor.org/rfc/rfc3753>.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009,
<https://www.rfc-editor.org/rfc/rfc5415>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014,
<https://www.rfc-editor.org/rfc/rfc7149>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, "SEcure Neighbor Discovery (SEND)", RFC 3971,
September 2007, <https://www.rfc-editor.org/rfc/rfc4861>. DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
Address Autoconfiguration", RFC 4862, September 2007, "Randomness Requirements for Security", BCP 106, RFC 4086,
<https://www.rfc-editor.org/rfc/rfc4862>. DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/rfc/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999, <https://www.rfc-editor.org/rfc/rfc2710>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
<https://www.rfc-editor.org/rfc/rfc3810>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
Hoc Networks", RFC 5889, September 2010, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/rfc/rfc5889>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
"Randomness Requirements for Security", RFC 4086, June RFC 4303, DOI 10.17487/RFC4303, December 2005,
2005, <https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
Extensions for Stateless Address Autoconfiguration in DOI 10.17487/RFC4308, December 2005,
IPv6", RFC 4941, September 2007, <https://www.rfc-editor.org/info/rfc4308>.
<https://www.rfc-editor.org/rfc/rfc4941>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Reserved for Documentation", RFC 3849, July 2004, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
<https://www.rfc-editor.org/rfc/rfc3849>. DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
2011, <https://www.rfc-editor.org/rfc/rfc6250>. Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Version 1.3", RFC 8446, August 2018, Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
<https://www.rfc-editor.org/rfc/rfc8446>. RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<https://www.rfc-editor.org/rfc/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005, <https://www.rfc-editor.org/rfc/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005,
<https://www.rfc-editor.org/rfc/rfc4303>.
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
December 2005, <https://www.rfc-editor.org/rfc/rfc4308>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Kivinen, "Internet Key Exchange Protocol Version 2 Ed., "Control And Provisioning of Wireless Access Points
(IKEv2)", RFC 7296, October 2014, (CAPWAP) Protocol Specification", RFC 5415,
<https://www.rfc-editor.org/rfc/rfc7296>. DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
Hosts in a Multi-Prefix Network", RFC 8028, November 2016, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
<https://www.rfc-editor.org/rfc/rfc8028>. DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
Neighbor Discovery (SEND)", RFC 3971, March 2005, Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
<https://www.rfc-editor.org/rfc/rfc3971>. September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC8505] Thubert, P., Nordmark, E., Chakrabarti, S., and C. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Perkins, "Registration Extensions for IPv6 over Low-Power Network (MANET) Neighborhood Discovery Protocol (NHDP)",
Wireless Personal Area Network (6LoWPAN) Neighbor RFC 6130, DOI 10.17487/RFC6130, April 2011,
Discovery", RFC 8505, November 2018, <https://www.rfc-editor.org/info/rfc6130>.
<https://www.rfc-editor.org/rfc/rfc8505>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250,
"Neighbor Discovery Optimization for IPv6 over Low-Power DOI 10.17487/RFC6250, May 2011,
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, <https://www.rfc-editor.org/info/rfc6250>.
November 2012, <https://www.rfc-editor.org/rfc/rfc6775>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2010, <https://www.rfc-editor.org/rfc/rfc5881>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
RFC 6130, April 2011, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
<https://www.rfc-editor.org/rfc/rfc6130>. Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012, Neighbor Discovery Problems", RFC 6583,
<https://www.rfc-editor.org/rfc/rfc6583>. DOI 10.17487/RFC6583, March 2012,
<https://www.rfc-editor.org/info/rfc6583>.
[RFC8928] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
"Address-Protected Neighbor Discovery for Low-Power and Bormann, "Neighbor Discovery Optimization for IPv6 over
Lossy Networks", RFC 8928, November 2020, Low-Power Wireless Personal Area Networks (6LoWPANs)",
<https://www.rfc-editor.org/rfc/rfc8928>. RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Protocol (OLSR)", RFC 3626, October 2003, Networking: A Perspective from within a Service Provider
<https://www.rfc-editor.org/rfc/rfc3626>. Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", "The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014, RFC 7181, DOI 10.17487/RFC7181, April 2014,
<https://www.rfc-editor.org/rfc/rfc7181>. <https://www.rfc-editor.org/info/rfc7181>.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol Version 2 (OLSRv2) and MANET Neighborhood Protocol Version 2 (OLSRv2) and MANET Neighborhood
Discovery Protocol (NHDP) Extension TLVs", RFC 7188, April Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
2014, <https://www.rfc-editor.org/rfc/rfc7188>. DOI 10.17487/RFC7188, April 2014,
<https://www.rfc-editor.org/info/rfc7188>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<https://www.rfc-editor.org/info/rfc7333>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015,
<https://www.rfc-editor.org/info/rfc7429>.
[RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the
Mobile Ad Hoc Network (MANET) Neighborhood Discovery
Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March
2015, <https://www.rfc-editor.org/info/rfc7466>.
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for
the Optimized Link State Routing Protocol Version 2 the Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7722, December 2015, (OLSRv2)", RFC 7722, DOI 10.17487/RFC7722, December 2015,
<https://www.rfc-editor.org/rfc/rfc7722>. <https://www.rfc-editor.org/info/rfc7722>.
[RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric
Based on Packet Sequence Numbers for Optimized Link State Based on Packet Sequence Numbers for Optimized Link State
Routing Version 2 (OLSRv2)", RFC 7779, April 2016, Routing Version 2 (OLSRv2)", RFC 7779,
<https://www.rfc-editor.org/rfc/rfc7779>. DOI 10.17487/RFC7779, April 2016,
<https://www.rfc-editor.org/info/rfc7779>.
[RFC8218] Yi, J. and B. Parrein, "Multipath Extension for the [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Optimized Link State Routing Protocol Version 2 (OLSRv2)", Hosts in a Multi-Prefix Network", RFC 8028,
RFC 8218, August 2017, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/rfc/rfc8218>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
June 2017, <https://www.rfc-editor.org/rfc/rfc8175>. DOI 10.17487/RFC8175, June 2017,
<https://www.rfc-editor.org/info/rfc8175>.
[RFC8629] Cheng, B. and L. Berger, "Dynamic Link Exchange Protocol [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(DLEP) Multi-Hop Forwarding Extension", RFC 8629, July (IPv6) Specification", STD 86, RFC 8200,
2019, <https://www.rfc-editor.org/rfc/rfc8629>. DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8651] Cheng, B., Wiggins, D., and L. Berger, "Dynamic Link [RFC8218] Yi, J. and B. Parrein, "Multipath Extension for the
Optimized Link State Routing Protocol Version 2 (OLSRv2)",
RFC 8218, DOI 10.17487/RFC8218, August 2017,
<https://www.rfc-editor.org/info/rfc8218>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8629] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange
Protocol (DLEP) Multi-Hop Forwarding Extension", RFC 8629,
DOI 10.17487/RFC8629, July 2019,
<https://www.rfc-editor.org/info/rfc8629>.
[RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link
Exchange Protocol (DLEP) Control-Plane-Based Pause Exchange Protocol (DLEP) Control-Plane-Based Pause
Extension", RFC 8651, October 2019, Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019,
<https://www.rfc-editor.org/rfc/rfc8651>. <https://www.rfc-editor.org/info/rfc8651>.
[RFC8691] Benamar, N., Härri, J., Lee, J., and T. Ernst, "Basic
Support for IPv6 Networks Operating Outside the Context of
a Basic Service Set over IEEE Std 802.11", RFC 8691,
DOI 10.17487/RFC8691, December 2019,
<https://www.rfc-editor.org/info/rfc8691>.
[RFC8703] Taylor, R. and S. Ratliff, "Dynamic Link Exchange Protocol [RFC8703] Taylor, R. and S. Ratliff, "Dynamic Link Exchange Protocol
(DLEP) Link Identifier Extension", RFC 8703, February (DLEP) Link Identifier Extension", RFC 8703,
2020, <https://www.rfc-editor.org/rfc/rfc8703>. DOI 10.17487/RFC8703, February 2020,
<https://www.rfc-editor.org/info/rfc8703>.
[RFC8757] Cheng, B. and L. Berger, "Dynamic Link Exchange Protocol [RFC8757] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange
(DLEP) Latency Range Extension", RFC 8757, March 2020, Protocol (DLEP) Latency Range Extension", RFC 8757,
<https://www.rfc-editor.org/rfc/rfc8757>. DOI 10.17487/RFC8757, March 2020,
<https://www.rfc-editor.org/info/rfc8757>.
[RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
Mobile Ad Hoc Network (MANET) Neighborhood Discovery "Address-Protected Neighbor Discovery for Low-Power and
Protocol (NHDP)", RFC 7466, March 2015, Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
<https://www.rfc-editor.org/rfc/rfc7466>. 2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
Zúñiga, "Multicast Considerations over IEEE 802 Wireless
Media", RFC 9119, DOI 10.17487/RFC9119, October 2021,
<https://www.rfc-editor.org/info/rfc9119>.
8.2. Informative References 8.2. Informative References
[ID-IPPL] Nordmark, E., "IP over Intentionally Partially Partitioned [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959,
DOI 10.17487/RFC6959, May 2013,
<https://www.rfc-editor.org/info/rfc6959>.
[I-D.ietf-intarea-ippl]
Nordmark, E., "IP over Intentionally Partially Partitioned
Links", Work in Progress, Internet-Draft, draft-ietf- Links", Work in Progress, Internet-Draft, draft-ietf-
intarea-ippl-00, March 2017, intarea-ippl-00, 30 March 2017,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea- <https://www.ietf.org/archive/id/draft-ietf-intarea-ippl-
ippl-00>. 00.txt>.
[RFC6830BIS] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, "The Locator/ID Separation Protocol (LISP)", Cabellos, "The Locator/ID Separation Protocol (LISP)",
Work in Progress, Internet-Draft, draft-ietf-lisp- Work in Progress, Internet-Draft, draft-ietf-lisp-
rfc6830bis-36, November 2020, rfc6830bis-36, 18 November 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp- <https://www.ietf.org/archive/id/draft-ietf-lisp-
rfc6830bis-36>. rfc6830bis-36.txt>.
[AERO] Templin, F., "Automatic Extended Route Optimization [I-D.templin-6man-aero]
Templin, F. L., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin- (AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero-34, September 2021, 6man-aero-38, 31 December 2021,
<https://datatracker.ietf.org/doc/html/draft-templin-6man- <https://www.ietf.org/archive/id/draft-templin-6man-aero-
aero-34>. 38.txt>.
[OMNI] Templin, F. and A. Whyman, "Transmission of IP Packets [I-D.templin-6man-omni]
Templin, F. L. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", Work in over Overlay Multilink Network (OMNI) Interfaces", Work in
Progress, Internet-Draft, draft-templin-6man-omni-47, Progress, Internet-Draft, draft-templin-6man-omni-52, 31
September 2021, <https://datatracker.ietf.org/doc/html/ December 2021, <https://www.ietf.org/archive/id/draft-
draft-templin-6man-omni-47>. templin-6man-omni-52.txt>.
[UAM-ITS] Templin, F., "Urban Air Mobility Implications for [I-D.templin-ipwave-uam-its]
Templin, F. L., "Urban Air Mobility Implications for
Intelligent Transportation Systems", Work in Progress, Intelligent Transportation Systems", Work in Progress,
Internet-Draft, draft-templin-ipwave-uam-its-04, January Internet-Draft, draft-templin-ipwave-uam-its-04, 4 January
2021, <https://datatracker.ietf.org/doc/html/draft- 2021, <https://www.ietf.org/archive/id/draft-templin-
templin-ipwave-uam-its-04>. ipwave-uam-its-04.txt>.
[DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., [I-D.ietf-dmm-fpc-cpdp]
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Configuration (FPC) in DMM", Work in Progress, Internet- Moses, D., and C. E. Perkins, "Protocol for Forwarding
Draft, draft-ietf-dmm-fpc-cpdp-14, September 2020, Policy Configuration (FPC) in DMM", Work in Progress,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-fpc- Internet-Draft, draft-ietf-dmm-fpc-cpdp-14, 22 September
cpdp-14>. 2020, <https://www.ietf.org/archive/id/draft-ietf-dmm-fpc-
cpdp-14.txt>.
[ID-Multicast-Problems] [I-D.thubert-6man-ipv6-over-wireless]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. Thubert, P., "IPv6 Neighbor Discovery on Wireless
Zuniga, "Multicast Considerations over IEEE 802 Wireless Networks", Work in Progress, Internet-Draft, draft-
Media", Work in Progress, Internet-Draft, draft-ietf- thubert-6man-ipv6-over-wireless-11, 15 December 2021,
mboned-ieee802-mcast-problems-15, July 2021, <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-
<https://datatracker.ietf.org/doc/html/draft-ietf-mboned- over-wireless-11.txt>.
ieee802-mcast-problems-15>.
[DSRC] ASTM International, "Standard Specification for [DSRC] ASTM International, "Standard Specification for
Telecommunications and Information Exchange Between Telecommunications and Information Exchange Between
Roadside and Vehicle Systems - 5 GHz Band Dedicated Short Roadside and Vehicle Systems - 5 GHz Band Dedicated Short
Range Communications (DSRC) Medium Access Control (MAC) Range Communications (DSRC) Medium Access Control (MAC)
and Physical Layer (PHY) Specifications", and Physical Layer (PHY) Specifications",
ASTM E2213-03(2010), October 2010. ASTM E2213-03(2010), October 2010.
[EU-2008-671-EC] [EU-2008-671-EC]
European Union, "Commission Decision of 5 August 2008 on European Union, "Commission Decision of 5 August 2008 on
skipping to change at page 42, line 50 skipping to change at page 42, line 41
(LNCS), Vol. 9502, December 2015. (LNCS), Vol. 9502, December 2015.
[CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A
Framework of Context-Awareness Safety Driving in Vehicular Framework of Context-Awareness Safety Driving in Vehicular
Networks", International Workshop on Device Centric Cloud Networks", International Workshop on Device Centric Cloud
(DC2), March 2016. (DC2), March 2016.
[CA-Cruise-Control] [CA-Cruise-Control]
California Partners for Advanced Transportation Technology California Partners for Advanced Transportation Technology
(PATH), "Cooperative Adaptive Cruise Control", Available: (PATH), "Cooperative Adaptive Cruise Control", Available:
http://www.path.berkeley.edu/research/automated-and- https://path.berkeley.edu/research/connected-and-
connected-vehicles/cooperative-adaptive-cruise-control, automated-vehicles/cooperative-adaptive-cruise-control,
2017. 2022.
[Truck-Platooning] [Truck-Platooning]
California Partners for Advanced Transportation Technology California Partners for Advanced Transportation Technology
(PATH), "Automated Truck Platooning", Available: (PATH), "Automated Truck Platooning", Available:
http://www.path.berkeley.edu/research/automated-and- https://path.berkeley.edu/research/connected-and-
connected-vehicles/truck-platooning, 2017. automated-vehicles/truck-platooning, 2022.
[FirstNet] U.S. National Telecommunications and Information [FirstNet] U.S. National Telecommunications and Information
Administration (NTIA), "First Responder Network Authority Administration (NTIA), "First Responder Network Authority
(FirstNet)", Available: https://www.firstnet.gov/, 2012. (FirstNet)", Available: https://www.firstnet.gov/, 2022.
[FirstNet-Report] [FirstNet-Report]
First Responder Network Authority, "FY 2017: ANNUAL REPORT First Responder Network Authority, "FY 2017: ANNUAL REPORT
TO CONGRESS, Advancing Public Safety Broadband TO CONGRESS, Advancing Public Safety Broadband
Communications", FirstNet FY 2017, December 2017. Communications", FirstNet FY 2017, December 2017.
[SignalGuru] [SignalGuru]
Koukoumidis, E., Peh, L., and M. Martonosi, "SignalGuru: Koukoumidis, E., Peh, L., and M. Martonosi, "SignalGuru:
Leveraging Mobile Phones for Collaborative Traffic Signal Leveraging Mobile Phones for Collaborative Traffic Signal
Schedule Advisory", ACM MobiSys, June 2011. Schedule Advisory", ACM MobiSys, June 2011.
skipping to change at page 44, line 21 skipping to change at page 44, line 14
[Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. System", URL: https://bitcoin.org/bitcoin.pdf, May 2009.
[Vehicular-BlockChain] [Vehicular-BlockChain]
Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, Dorri, A., Steger, M., Kanhere, S., and R. Jurdak,
"BlockChain: A Distributed Solution to Automotive Security "BlockChain: A Distributed Solution to Automotive Security
and Privacy", IEEE Communications Magazine, Vol. 55, No. and Privacy", IEEE Communications Magazine, Vol. 55, No.
12, December 2017. 12, December 2017.
[IPoWIRELESS]
Thubert, P., "IPv6 Neighbor Discovery on Wireless
Networks", Work in Progress, Internet-Draft, draft-
thubert-6man-ipv6-over-wireless-09, May 2021,
<https://datatracker.ietf.org/doc/html/draft-thubert-6man-
ipv6-over-wireless-09>.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959, May
2013, <https://www.rfc-editor.org/rfc/rfc6959>.
Appendix A. Support of Multiple Radio Technologies for V2V Appendix A. Support of Multiple Radio Technologies for V2V
Vehicular networks may consist of multiple radio technologies such as Vehicular networks may consist of multiple radio technologies such as
DSRC and 5G V2X. Although a Layer-2 solution can provide a support DSRC and 5G V2X. Although a Layer-2 solution can provide a support
for multihop communications in vehicular networks, the scalability for multihop communications in vehicular networks, the scalability
issue related to multihop forwarding still remains when vehicles need issue related to multihop forwarding still remains when vehicles need
to disseminate or forward packets toward multihop-away destinations. to disseminate or forward packets toward multihop-away destinations.
In addition, the IPv6-based approach for V2V as a network layer In addition, the IPv6-based approach for V2V as a network layer
protocol can accommodate multiple radio technologies as MAC protocol can accommodate multiple radio technologies as MAC
protocols, such as DSRC and 5G V2X. Therefore, the existing IPv6 protocols, such as DSRC and 5G V2X. Therefore, the existing IPv6
protocol can be augmented through the addition of a virtual interface protocol can be augmented through the addition of a virtual interface
(e.g., Overlay Multilink Network (OMNI) Interface [OMNI]) and/or (e.g., Overlay Multilink Network (OMNI) Interface
protocol changes in order to support both wireless single-hop/ [I-D.templin-6man-omni]) and/or protocol changes in order to support
multihop V2V communications and multiple radio technologies in both wireless single-hop/multihop V2V communications and multiple
vehicular networks. In such a way, vehicles can communicate with radio technologies in vehicular networks. In such a way, vehicles
each other by V2V communications to share either an emergency can communicate with each other by V2V communications to share either
situation or road hazard information in a highway having multiple an emergency situation or road hazard information in a highway having
kinds of radio technologies. multiple kinds of radio technologies.
Appendix B. Support of Multihop V2X Networking Appendix B. Support of Multihop V2X Networking
The multihop V2X networking can be supported by RPL (IPv6 Routing The multihop V2X networking can be supported by RPL (IPv6 Routing
Protocol for Low-Power and Lossy Networks) [RFC6550] and AERO Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay
(Automatic Extended Route Optimization) [AERO] over OMNI (Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni].
Multilink Network Interface) [OMNI].
RPL defines an IPv6 routing protocol for low-power and lossy networks RPL defines an IPv6 routing protocol for low-power and lossy networks
(LLN), mostly designed for home automation routing, building (LLN), mostly designed for home automation routing, building
automation routing, industrial routing, and urban LLN routing. It automation routing, industrial routing, and urban LLN routing. It
uses a Destination-Oriented Directed Acyclic Graph (DODAG) to uses a Destination-Oriented Directed Acyclic Graph (DODAG) to
construct routing paths for hosts (e.g., IoT devices) in a network. construct routing paths for hosts (e.g., IoT devices) in a network.
The DODAG uses an objective function (OF) for route selection and The DODAG uses an objective function (OF) for route selection and
optimization within the network. A user can use different routing optimization within the network. A user can use different routing
metrics to define an OF for a specific scenario. RPL supports metrics to define an OF for a specific scenario. RPL supports
multipoint-to-point, point-to-multipoint, and point-to-point traffic, multipoint-to-point, point-to-multipoint, and point-to-point traffic,
skipping to change at page 45, line 38 skipping to change at page 45, line 31
RPL is primarily designed to minimize the control plane activity, RPL is primarily designed to minimize the control plane activity,
which is the relative amount of routing protocol exchanges versus which is the relative amount of routing protocol exchanges versus
data traffic; this approach is beneficial for situations where the data traffic; this approach is beneficial for situations where the
power and bandwidth are scarce (e.g., an IoT LLN where RPL is power and bandwidth are scarce (e.g., an IoT LLN where RPL is
typically used today), but also in situations of high relative typically used today), but also in situations of high relative
mobility between the nodes in the network (also known as swarming, mobility between the nodes in the network (also known as swarming,
e.g., within a variable set of vehicles with a similar global motion, e.g., within a variable set of vehicles with a similar global motion,
or a variable set of drones flying toward the same direction). or a variable set of drones flying toward the same direction).
To reduce the routing exchanges, RPL leverages a DV approach, which To reduce the routing exchanges, RPL leverages a Distance Vector (DV)
does not need a global knowledge of the topology, and only optimizes approach, which does not need a global knowledge of the topology, and
the routes to and from the root, allowing P2P paths to be stretched. only optimizes the routes to and from the root, allowing Peer-to-Peer
Although RPL installs its routes proactively, it only maintains them (P2P) paths to be stretched. Although RPL installs its routes
lazily, that is, in reaction to actual traffic, or as a slow proactively, it only maintains them lazily, that is, in reaction to
background activity. Additionally, RPL leverages the concept of an actual traffic, or as a slow background activity. Additionally, RPL
objective function (called OF), which allows to adapt the activity of leverages the concept of an objective function (called OF), which
the routing protocol to use cases, e.g., type, speed, and quality of allows to adapt the activity of the routing protocol to use cases,
the radios. RPL does not need converge, and provides connectivity to e.g., type, speed, and quality of the radios. RPL does not need
most nodes most of the time. The default route toward the root is converge, and provides connectivity to most nodes most of the time.
maintained aggressively and may change while a packet progresses The default route toward the root is maintained aggressively and may
without causing loops, so the packet will still reach the root. change while a packet progresses without causing loops, so the packet
There are two modes for routing in RPL such as non-storing mode and will still reach the root. There are two modes for routing in RPL
storing mode. In non-storing mode, a node inside the mesh/swarm that such as non-storing mode and storing mode. In non-storing mode, a
changes its point(s) of attachment to the graph informs the root with node inside the mesh/swarm that changes its point(s) of attachment to
a single unicast packet flowing along the default route, and the the graph informs the root with a single unicast packet flowing along
connectivity is restored immediately; this mode is preferable for use the default route, and the connectivity is restored immediately; this
cases where Internet connectivity is dominant. On the other hand, in mode is preferable for use cases where Internet connectivity is
storing mode, the routing stretch is reduced, for a better P2P dominant. On the other hand, in storing mode, the routing stretch is
connectivity, while the Internet connectivity is restored more reduced, for a better P2P connectivity, while the Internet
slowly, during the time for the DV operation to operate hop-by-hop. connectivity is restored more slowly, during the time for the DV
While an RPL topology can quickly scale up and down and fits the operation to operate hop-by-hop. While an RPL topology can quickly
needs of mobility of vehicles, the total performance of the system scale up and down and fits the needs of mobility of vehicles, the
will also depend on how quickly a node can form an address, join the total performance of the system will also depend on how quickly a
mesh (including Authentication, Authorization, and Accounting (AAA)), node can form an address, join the mesh (including Authentication,
and manage its global mobility to become reachable from another node Authorization, and Accounting (AAA)), and manage its global mobility
outside the mesh. to become reachable from another node outside the mesh.
AERO and OMNI together securely and efficiently address the following
6 M's of Modern Internetworking for mobile V2V, V2I and V2X Clients:
1. Multilink: A Client's ability to coordinate multiple diverse
underlying data links as a single logical unit (i.e., the OMNI
interface) to achieve the required communications performance and
reliability objectives.
2. Multinet: The ability to span the OMNI link over a segment
routing topology with multiple diverse administrative domain
network segments while maintaining seamless E2E communications
between mobile Clients and correspondents such as air traffic
controllers and fleet administrators.
3. Mobility: A Client's ability to change network points of
attachment (e.g., moving between wireless base stations) which
may result in an underlying interface address change without
disruptions to ongoing communication sessions with peers over the
OMNI link.
4. Multicast: The ability to send a single network transmission that
reaches multiple Clients belonging to the same interest group
without disturbing other Clients not subscribed to the interest
group.
5. Multihop: A mobile Client's V2V relaying capability useful when
multiple forwarding hops between vehicles may be necessary to
reach back to an infrastructure access point connection to the
OMNI link.
6. MTU Assurance: The ability to deliver packets of various robust OMNI defines a protocol for the transmission of IPv6 packets over
sizes between peers without loss due to a link size restriction, Overlay Multilink Network Interfaces that are virtual interfaces
and to dynamically adjust packet sizes in order to achieve the governing multiple physical network interfaces. OMNI supports
optimal performance for each independent traffic flow. multihop V2V communication between vehicles in multiple forwarding
hops via intermediate vehicles with OMNI links. It also supports
multihop V2I communication between a vehicle and an infrastructure
access point by multihop V2V communication. 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.
Appendix C. Support of Mobility Management for V2I Appendix C. Support of Mobility Management for V2I
The seamless application communication between two vehicles or The seamless application communication between two vehicles or
between a vehicle and an infrastructure node requires mobility between a vehicle and an infrastructure node requires mobility
management in vehicular networks. The mobility management schemes management in vehicular networks. The mobility management schemes
include a host-based mobility scheme, network-based mobility scheme, include a host-based mobility scheme, network-based mobility scheme,
and software-defined networking scheme. and software-defined networking scheme.
In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a
skipping to change at page 47, line 45 skipping to change at page 47, line 13
network-based mobility scheme. All these mobility approaches (i.e., network-based mobility scheme. All these mobility approaches (i.e.,
a host-based mobility scheme, network-based mobility scheme, and a host-based mobility scheme, network-based mobility scheme, and
distributed mobility scheme) and a hybrid approach of a combination distributed mobility scheme) and a hybrid approach of a combination
of them need to provide an efficient mobility service to vehicles of them need to provide an efficient mobility service to vehicles
moving fast and moving along with the relatively predictable moving fast and moving along with the relatively predictable
trajectories along the roadways. trajectories along the roadways.
In vehicular networks, the control plane can be separated from the In vehicular networks, the control plane can be separated from the
data plane for efficient mobility management and data forwarding by data plane for efficient mobility management and data forwarding by
using the concept of Software-Defined Networking (SDN) using the concept of Software-Defined Networking (SDN)
[RFC7149][DMM-FPC]. Note that Forwarding Policy Configuration (FPC) [RFC7149][I-D.ietf-dmm-fpc-cpdp]. Note that Forwarding Policy
in [DMM-FPC], which is a flexible mobility management system, can Configuration (FPC) in [I-D.ietf-dmm-fpc-cpdp], which is a flexible
manage the separation of data-plane and control-plane in DMM. In mobility management system, can manage the separation of data-plane
SDN, the control plane and data plane are separated for the efficient and control-plane in DMM. In SDN, the control plane and data plane
management of forwarding elements (e.g., switches and routers) where are separated for the efficient management of forwarding elements
an SDN controller configures the forwarding elements in a centralized (e.g., switches and routers) where an SDN controller configures the
way and they perform packet forwarding according to their forwarding forwarding elements in a centralized way and they perform packet
tables that are configured by the SDN controller. An MA as an SDN forwarding according to their forwarding tables that are configured
controller needs to efficiently configure and monitor its IP-RSUs and by the SDN controller. An MA as an SDN controller needs to
vehicles for mobility management, location management, and security efficiently configure and monitor its IP-RSUs and vehicles for
services. mobility management, location management, and security services.
Appendix D. Acknowledgments Appendix D. Acknowledgments
This work was supported by Institute of Information & Communications This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
Security Intelligence Technology Development for the Customized Security Intelligence Technology Development for the Customized
Security Service Provisioning). Security Service Provisioning).
This work was supported in part by the MSIT, Korea, under the ITRC This work was supported in part by the MSIT, Korea, under the ITRC
(Information Technology Research Center) support program (IITP- (Information Technology Research Center) support program (IITP-
2021-2017-0-01633) supervised by the IITP. 2021-2017-0-01633) supervised by the IITP.
This work was supported in part by the IITP grant funded by the MSIT This work was supported in part by the IITP (2020-0-00395, Standard
(2020-0-00395, Standard Development of Blockchain based Network Development of Blockchain based Network Management Automation
Management Automation Technology). Technology).
This work was supported in part by the French research project This work was supported in part by the French research project
DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded
by the European Commission I (636537-H2020). by the European Commission I (636537-H2020).
This work was supported in part by the Cisco University Research This work was supported in part by the Cisco University Research
Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal
Project FB0008. Project FB0008.
Appendix E. Contributors Appendix E. Contributors
skipping to change at page 48, line 50 skipping to change at page 48, line 23
Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ
Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget
(Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI), (Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI),
Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil
University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), Peter E. Yee University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), Peter E. Yee
(Akayla), and Erik Kline. The authors sincerely appreciate their (Akayla), and Erik Kline. The authors sincerely appreciate their
contributions. contributions.
The following are co-authors of this document: The following are co-authors of this document:
Nabil Benamar Nabil Benamar -
Department of Computer Sciences, High School of Technology of Meknes, Department of Computer Sciences, High School of Technology of Meknes,
Moulay Ismail University, Morocco, Phone: +212 6 70 83 22 36, EMail: Moulay Ismail University, Morocco, Phone: +212 6 70 83 22 36, EMail:
benamar73@gmail.com benamar73@gmail.com
Sandra Cespedes Sandra Cespedes -
NIC Chile Research Labs, Universidad de Chile, Av. Blanco Encalada NIC Chile Research Labs, Universidad de Chile, Av. Blanco Encalada
1975, Santiago, Chile, Phone: +56 2 29784093, EMail: 1975, Santiago, Chile, Phone: +56 2 29784093, EMail:
scespede@niclabs.cl scespede@niclabs.cl
Jerome Haerri Jerome Haerri -
Communication Systems Department, EURECOM, Sophia-Antipolis, France, Communication Systems Department, EURECOM, Sophia-Antipolis, France,
Phone: +33 4 93 00 81 34, EMail: jerome.haerri@eurecom.fr Phone: +33 4 93 00 81 34, EMail: jerome.haerri@eurecom.fr
Dapeng Liu Dapeng Liu -
Alibaba, Beijing, Beijing 100022, China, Phone: +86 13911788933, Alibaba, Beijing, Beijing 100022, China, Phone: +86 13911788933,
EMail: max.ldp@alibaba-inc.com EMail: max.ldp@alibaba-inc.com
Tae (Tom) Oh Tae (Tom) Oh -
Department of Information Sciences and Technologies, Rochester Department of Information Sciences and Technologies, Rochester
Institute of Technology, One Lomb Memorial Drive, Rochester, NY Institute of Technology, One Lomb Memorial Drive, Rochester, NY
14623-5603, USA, Phone: +1 585 475 7642, EMail: Tom.Oh@rit.edu 14623-5603, USA, Phone: +1 585 475 7642, EMail: Tom.Oh@rit.edu
Charles E. Perkins Charles E. Perkins -
Futurewei Inc., 2330 Central Expressway, Santa Clara, CA 95050, USA, Futurewei Inc., 2330 Central Expressway, Santa Clara, CA 95050, USA,
Phone: +1 408 330 4586, EMail: charliep@computer.org Phone: +1 408 330 4586, EMail: charliep@computer.org
Alexandre Petrescu Alexandre Petrescu -
CEA, LIST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France, CEA, LIST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France,
Phone: +33169089223, EMail: Alexandre.Petrescu@cea.fr Phone: +33169089223, EMail: Alexandre.Petrescu@cea.fr
Yiwen Chris Shen Yiwen Chris Shen -
Department of Computer Science & Engineering, Sungkyunkwan Department of Computer Science & Engineering, Sungkyunkwan
University, 2066 Seobu-Ro, Jangan-Gu, Suwon, Gyeonggi-Do 16419, University, 2066 Seobu-Ro, Jangan-Gu, Suwon, Gyeonggi-Do 16419,
Republic of Korea, Phone: +82 31 299 4106, Fax: +82 31 290 7996, Republic of Korea, Phone: +82 31 299 4106, Fax: +82 31 290 7996,
EMail: chrisshen@skku.edu, URI: https://chrisshen.github.io EMail: chrisshen@skku.edu, URI: https://chrisshen.github.io
Michelle Wetterwald Michelle Wetterwald -
FBConsulting, 21, Route de Luxembourg, Wasserbillig, Luxembourg FBConsulting, 21, Route de Luxembourg, Wasserbillig, Luxembourg
L-6633, Luxembourg, EMail: Michelle.Wetterwald@gmail.com L-6633, Luxembourg, EMail: Michelle.Wetterwald@gmail.com
Author's Address Author's Address
Jaehoon (Paul) Jeong (editor) Jaehoon (Paul) Jeong (editor)
Department of Computer Science and Engineering Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
 End of changes. 87 change blocks. 
345 lines changed or deleted 352 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/