draft-ietf-ipwave-vehicular-networking-19.txt   draft-ietf-ipwave-vehicular-networking-20.txt 
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational July 29, 2020 Intended status: Informational March 18, 2021
Expires: January 30, 2021 Expires: September 19, 2021
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-19 draft-ietf-ipwave-vehicular-networking-20
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
IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
and Security & Privacy), and then lists up requirements for the and Security & Privacy), and then enumerates requirements for the
extensions of those IPv6 protocols for IPv6-based vehicular extensions of those IPv6 protocols for IPv6-based vehicular
networking. networking.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 30, 2021. This Internet-Draft will expire on September 19, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 13 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 13
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 17 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 17
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 20
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 21 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 22 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 22
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 23 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 23
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 25 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 25
5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 26 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Informative References . . . . . . . . . . . . . . . . . . . 30 8. Informative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 37 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 38
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
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 42 skipping to change at page 3, line 42
approved a standard specifying the IPv6 network protocols and approved a standard specifying the IPv6 network protocols and
services to be used for Communications Access for Land Mobiles (CALM) services to be used for Communications Access for Land Mobiles (CALM)
[ISO-ITS-IPv6] [ISO-ITS-IPv6-AMD1]. [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 lists up 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
development of key protocols for IPWAVE. development of key protocols for IPWAVE.
2. Terminology 2. Terminology
This document uses the terminology described in [RFC8691]. In This document uses the terminology described in [RFC8691]. In
addition, the following terms are defined below: addition, the following terms are defined below:
o Class-Based Safety Plan: A vehicle can make a safety plan by o Class-Based Safety Plan: A vehicle can make a safety plan by
skipping to change at page 5, line 46 skipping to change at page 5, line 46
(e.g., average vehicle speed and vehicle inter-arrival time per (e.g., average vehicle speed and vehicle inter-arrival time per
road segment) and vehicle information (e.g., a vehicle's road segment) and vehicle information (e.g., a vehicle's
identifier, position, direction, speed, and trajectory as a identifier, position, direction, speed, and trajectory as a
navigation path). TCC is part of a vehicular cloud for vehicular navigation path). TCC is part of a vehicular cloud for vehicular
networks. networks.
o Vehicle: A Vehicle in this document is a node that has an IP-OBU o Vehicle: A Vehicle in this document is a node that has an IP-OBU
for wireless communication with other vehicles and IP-RSUs. It for wireless communication with other vehicles and IP-RSUs. It
has a GPS radio navigation receiver for efficient navigation. Any has a GPS radio navigation receiver for efficient navigation. Any
device having an IP-OBU and a GPS receiver (e.g., smartphone and device having an IP-OBU and a GPS receiver (e.g., smartphone and
table PC) can be regarded as a vehicle in this document. tablet PC) can be regarded as a vehicle in this document.
o Vehicular Ad Hoc Network (VANET): A network that consists of o Vehicular Ad Hoc Network (VANET): A network that consists of
vehicles interconnected by wireless communication. Two vehicles vehicles interconnected by wireless communication. Two vehicles
in a VANET can communicate with each other using other vehicles as in a VANET can communicate with each other using other vehicles as
relays even where they are out of one-hop wireless communication relays even where they are out of one-hop wireless communication
range. range.
o Vehicular Cloud: A cloud infrastructure for vehicular networks, o Vehicular Cloud: A cloud infrastructure for vehicular networks,
having compute nodes, storage nodes, and network forwarding having compute nodes, storage nodes, and network forwarding
elements (e.g., switch and router). elements (e.g., switch and router).
skipping to change at page 7, line 17 skipping to change at page 7, line 17
safe, secure, privacy-preserving way. safe, secure, privacy-preserving way.
The use cases presented in this section serve as the description and The use cases presented in this section serve as the description and
motivation for the need to extend IPv6 and its protocols to motivation for the need to extend IPv6 and its protocols to
facilitate "Vehicular IPv6". Section 5 summarizes the overall facilitate "Vehicular IPv6". Section 5 summarizes the overall
problem statement and IPv6 requirements. Note that the adjective problem statement and IPv6 requirements. Note that the adjective
"Vehicular" in this document is used to represent extensions of "Vehicular" in this document is used to represent extensions of
existing protocols such as IPv6 Neighbor Discovery, IPv6 Mobility existing protocols such as IPv6 Neighbor Discovery, IPv6 Mobility
Management (e.g., PMIPv6 [RFC5213] and DMM [RFC7429]), and IPv6 Management (e.g., PMIPv6 [RFC5213] and DMM [RFC7429]), and IPv6
Security and Privacy Mechanisms rather than new "vehicular-specific" Security and Privacy Mechanisms rather than new "vehicular-specific"
functions. Refer to Section 5 for the problem statement of the functions.
requirements of vehicular IPv6.
3.1. V2V 3.1. V2V
The use cases of V2V networking discussed in this section include The use cases of V2V networking discussed in this section include
o Context-aware navigation for safe driving and collision avoidance; o Context-aware navigation for safe driving and collision avoidance;
o Cooperative adaptive cruise control in a roadway; o Cooperative adaptive cruise control in a roadway;
o Platooning in a highway; o Platooning in a highway;
skipping to change at page 9, line 15 skipping to change at page 9, line 12
To encourage more vehicles to participate in this cooperative To encourage more vehicles to participate in this cooperative
environmental sensing, a reward system will be needed. Sensing environmental sensing, a reward system will be needed. Sensing
activities of each vehicle need to be logged in either a central way activities of each vehicle need to be logged in either a central way
through a logging server (e.g., TCC) in the vehicular cloud or a through a logging server (e.g., TCC) in the vehicular cloud or a
distributed way (e.g., blockchain [Bitcoin]) through other vehicles distributed way (e.g., blockchain [Bitcoin]) through other vehicles
or infrastructure. In the case of a blockchain, each sensing message or infrastructure. In the case of a blockchain, each sensing message
from a vehicle can be treated as a transaction and the neighboring 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 vehicles can play the role of peers in a consensus method of a
blockchain [Bitcoin][Vehicular-BlockChain]. blockchain [Bitcoin][Vehicular-BlockChain].
The existing IPv6 protocol must be augmented through the addition of Although a Layer-2 solution can provide a support for multihop
an Overlay Multilink Network (OMNI) Interface [OMNI] and/or protocol communications in vehicular networks, the scalability issue related
changes in order to support wireless single-hop V2V communications as to multihop forwarding still remains when vehicles need to
well as wireless multihop V2V communications. Thus, the IPv6 needs disseminate or forward packets toward multihop-away destinations. In
to support both single-hop and multihop communications in a wireless addition, the IPv6-based approach for V2V as a network layer protocol
medium so that vehicles can communicate with each other by V2V can accommodate multiple radio technologies as MAC protocols, such as
communications to share either an emergency situation or road hazard 5G V2X and DSRC. Therefore, the existing IPv6 protocol can be
in a highway. 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.
To support applications of these V2V use cases, the functions of IPv6 To support applications of these V2V use cases, the functions of IPv6
such as VND and VSP are prerequisites for IPv6-based packet exchange such as VND and VSP are prerequisites for IPv6-based packet exchange
and secure, safe communication between two vehicles. and secure, safe communication between two vehicles.
3.2. V2I 3.2. V2I
The use cases of V2I networking discussed in this section include The use cases of V2I networking discussed in this section include
o Navigation service; o Navigation service;
skipping to change at page 10, line 27 skipping to change at page 10, line 32
and maintain an interoperable public safety broadband network for and maintain an interoperable public safety broadband network for
safety and security network services, e.g., emergency calls. The safety and security network services, e.g., emergency calls. The
construction of the nationwide FirstNet network requires each state construction of the nationwide FirstNet network requires each state
in the US to have a Radio Access Network (RAN) that will connect to in the US to have a Radio Access Network (RAN) that will connect to
the FirstNet's network core. The current RAN is mainly constructed the FirstNet's network core. The current RAN is mainly constructed
using 4G-LTE for the communication between a vehicle and an using 4G-LTE for the communication between a vehicle and an
infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected
that DSRC-based vehicular networks [DSRC] will be available for V2I that DSRC-based vehicular networks [DSRC] will be available for V2I
and V2V in the near future. and V2V in the near future.
An EV charging service with V2I can facilitates the efficient battery An EV charging service with V2I can facilitate the efficient battery
charging of EVs. In the case where an EV charging station is charging of EVs. In the case where an EV charging station is
connected to an IP-RSU, an EV can be guided toward the deck of the EV connected to an IP-RSU, an EV can be guided toward the deck of the EV
charging station through a battery charging server connected to the charging station through a battery charging server connected to the
IP-RSU. In addition to this EV charging service, other value-added IP-RSU. In addition to this EV charging service, other value-added
services (e.g., air firmware/software update and media streaming) can services (e.g., air firmware/software update and media streaming) can
be provided to an EV while it is charging its battery at the EV be provided to an EV while it is charging its battery at the EV
charging station. charging station.
A UAM navigation service with efficient battery charging can make the A UAM navigation service with efficient battery charging can plan the
battery charging schedule of UAM end systems (e.g., drone) for long- battery charging schedule of UAM end systems (e.g., drone) for long-
distance flying [CBDN]. For this battery charging schedule, a UAM distance flying [CBDN]. For this battery charging schedule, a UAM
end system can communicate with an infrastructure node (e.g., IP-RSU) end system can communicate with an infrastructure node (e.g., IP-RSU)
toward a cloud server via V2I communications. This cloud server can toward a cloud server via V2I communications. This cloud server can
coordinate the battery charging schedules of multiple UAM end systems coordinate the battery charging schedules of multiple UAM end systems
for their efficient navigation path, considering flight time from for their efficient navigation path, considering flight time from
their current position to a battery charging station, waiting time in their current position to a battery charging station, waiting time in
a waiting queue at the station, and battery charging time at the a waiting queue at the station, and battery charging time at the
station. station.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
Center (TCC) is connected to the Vehicular Cloud for the management Center (TCC) is connected to the Vehicular Cloud for the management
of IP-RSUs and vehicles in the road network. A Mobility Anchor (MA) of IP-RSUs and vehicles in the road network. A Mobility Anchor (MA)
may be located in the TCC as a mobility management controller. may be located in the TCC as a mobility management controller.
Vehicle2, Vehicle3, and Vehicle4 are wirelessly connected to IP-RSU1, Vehicle2, Vehicle3, and Vehicle4 are wirelessly connected to IP-RSU1,
IP-RSU2, and IP-RSU3, respectively. The three wireless networks of IP-RSU2, and IP-RSU3, respectively. The three wireless networks of
IP-RSU1, IP-RSU2, and IP-RSU3 can belong to three different subnets IP-RSU1, IP-RSU2, and IP-RSU3 can belong to three different subnets
(i.e., Subnet1, Subnet2, and Subnet3), respectively. Those three (i.e., Subnet1, Subnet2, and Subnet3), respectively. Those three
subnets use three different prefixes (i.e., Prefix1, Prefix2, and subnets use three different prefixes (i.e., Prefix1, Prefix2, and
Prefix3). Prefix3).
Multiple vehicles under the coverage of an RSU share a prefix such Multiple vehicles under the coverage of an RSU share a prefix just as
that mobile nodes share a prefix of a Wi-Fi access point in a mobile nodes share a prefix of a Wi-Fi access point in a wireless
wireless LAN. This is a natural characteristic in infrastructure- LAN. This is a natural characteristic in infrastructure-based
based wireless networks. For example, in Figure 1, two vehicles wireless networks. For example, in Figure 1, two vehicles (i.e.,
(i.e., Vehicle2, and Vehicle5) can use Prefix 1 to configure their Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6
IPv6 global addresses for V2I communication. Alternatively, mobile global addresses for V2I communication. Alternatively, mobile nodes
nodes can employ an OMNI interface and use their own IPv6 Unique can employ an OMNI interface and use their own IPv6 Unique Local
Local Addresses (ULAs) [RFC4193] over the wireless network without Addresses (ULAs) [RFC4193] over the wireless network without
requiring the messaging of IPv6 Stateless Address Autoconfiguration requiring the messaging of IPv6 Stateless Address Autoconfiguration
(SLAAC) [RFC4862], which uses an on-link prefix provided by the (SLAAC) [RFC4862], which uses an on-link prefix provided by the
(visited) wireless LAN; this technique is known as "Bring-Your-Own- (visited) wireless LAN; this technique is known as "Bring-Your-Own-
Addresses". Addresses".
A single subnet prefix announced by an RSU can span multiple vehicles A single subnet prefix announced by an RSU can span multiple vehicles
in VANET. For example, in Figure 1, for Prefix 1, three vehicles in VANET. For example, in Figure 1, for Prefix 1, three vehicles
(i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected (i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected
VANET. Also, for Prefix 2, two vehicles (i.e., Vehicle3 and VANET. Also, for Prefix 2, two vehicles (i.e., Vehicle3 and
Vehicle6) can construct another connected VANET, and for Prefix 3, Vehicle6) can construct another connected VANET, and for Prefix 3,
skipping to change at page 19, line 39 skipping to change at page 19, line 39
the wireless link interfaces for IP-OBU and IP-RSU can be either 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 global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be
routed within vehicular networks [OMNI]. When global IPv6 addresses routed within vehicular networks [OMNI]. When global IPv6 addresses
are used, wireless interface configuration and control overhead for are used, wireless interface configuration and control overhead for
Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener
Discovery (MLD) [RFC2710][RFC3810] should be minimized to support V2I Discovery (MLD) [RFC2710][RFC3810] should be minimized to support V2I
and V2X communications for vehicles moving fast along roadways; when and V2X communications for vehicles moving fast along roadways; when
ULAs and the OMNI interface are used, no DAD nor MLD messaging is ULAs and the OMNI interface are used, no DAD nor MLD messaging is
needed. needed.
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.
4.3. V2V-based Internetworking 4.3. V2V-based Internetworking
This section discusses the internetworking between the moving This section discusses the internetworking between the moving
networks of two neighboring vehicles via V2V communication. networks of two neighboring vehicles via V2V communication.
(*)<..........>(*) (*)<..........>(*)
(2001:DB8:1:1::/64) | | (2001:DB8:1:1::/64) | |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
| v | | v | | v | | v |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
skipping to change at page 25, line 49 skipping to change at page 26, line 6
an IPv6 address pair. However, the pseudonym handling is not an IPv6 address pair. However, the pseudonym handling is not
implemented and tested yet for applications on IP-based vehicular implemented and tested yet for applications on IP-based vehicular
networking. networking.
In the ETSI standards, for the sake of security and privacy, an ITS In the ETSI standards, for the sake of security and privacy, an ITS
station (e.g., vehicle) can use pseudonyms for its network interface station (e.g., vehicle) can use pseudonyms for its network interface
identities (e.g., MAC address) and the corresponding IPv6 addresses identities (e.g., MAC address) and the corresponding IPv6 addresses
[Identity-Management]. Whenever the network interface identifier [Identity-Management]. Whenever the network interface identifier
changes, the IPv6 address based on the network interface identifier changes, the IPv6 address based on the network interface identifier
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. For vehicular networks with high checked through the DAD procedure.
mobility and density, this DAD needs to be performed efficiently with
minimum overhead so that the vehicles can exchange application For vehicular networks with high mobility and density, the DAD needs
messages (e.g., collision avoidance and accident notification) with to be performed efficiently with minimum overhead so that the
each other with a short interval (e.g., 0.5 second) vehicles can exchange a driving safety message (e.g., collision
[NHTSA-ACAS-Report]. 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.
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 [ID-Multicast-Problems].
skipping to change at page 27, line 27 skipping to change at page 27, line 39
vehicular-network-wide DAD is required. If DHCPv6 is used to assign vehicular-network-wide DAD is required. If DHCPv6 is used to assign
a unique IPv6 address to each vehicle in this shared link, the DAD is a unique IPv6 address to each vehicle in this shared link, the DAD is
not required. On the other hand, for a mobility management scheme not required. On the other hand, for a mobility management scheme
with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213] and OMNI 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 [OMNI]), DAD is not required because the IPv6 address of a vehicle's
external wireless interface is guaranteed to be unique. There is a external wireless interface is guaranteed to be unique. There is a
tradeoff between the prefix usage efficiency and DAD overhead. Thus, tradeoff between the prefix usage efficiency and DAD overhead. Thus,
the IPv6 address autoconfiguration for vehicular networks needs to the IPv6 address autoconfiguration for vehicular networks needs to
consider this tradeoff to support efficient mobility management. consider this tradeoff to support efficient mobility management.
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.
Therefore, for the proactive and seamless IPv6 mobility of vehicles, Therefore, for the proactive and seamless IPv6 mobility of vehicles,
the vehicular infrastructure (including IP-RSUs and MA) needs to the vehicular infrastructure (including IP-RSUs and MA) needs to
efficiently perform the mobility management of the vehicles with efficiently perform the mobility management of the vehicles with
their mobility information and link-layer information. Also, in their mobility information and link-layer information. Also, in
IPv6-based vehicular networking, IPv6 mobility management should have IPv6-based vehicular networking, IPv6 mobility management should have
minimum changes for the interoperability with the legacy IPv6 minimum changes for the interoperability with the legacy IPv6
mobility management schemes such as PMIPv6, DMM, LISP, and AERO. mobility management schemes such as PMIPv6, DMM, LISP, and AERO.
6. Security Considerations 6. Security Considerations
skipping to change at page 29, line 17 skipping to change at page 29, line 33
IP-RSU) in an EN needs to be established, as shown in Figure 3 IP-RSU) in an EN needs to be established, as shown in Figure 3
[RFC4301][RFC4302][RFC4303][RFC4308][RFC7296]. Also, for secure V2V [RFC4301][RFC4302][RFC4303][RFC4308][RFC7296]. Also, for secure V2V
communication, a secure channel (e.g., IPsec) between a mobile router communication, a secure channel (e.g., IPsec) between a mobile router
(i.e., IP-OBU) in a vehicle and a mobile router (i.e., IP-OBU) in (i.e., IP-OBU) in a vehicle and a mobile router (i.e., IP-OBU) in
another vehicle needs to be established, as shown in Figure 4. For another vehicle needs to be established, as shown in Figure 4. For
secure communication, an element in a vehicle (e.g., an in-vehicle secure communication, an element in a vehicle (e.g., an in-vehicle
device and a driver/passenger's mobile device) needs to establish a device and a driver/passenger's mobile device) needs to establish a
secure connection (e.g., TLS) with another element in another vehicle secure connection (e.g., TLS) with another element in another vehicle
or another element in a vehicular cloud (e.g., a server). Even or another element in a vehicular cloud (e.g., a server). Even
though IEEE 1609.2 [WAVE-1609.2] specifies security services for though IEEE 1609.2 [WAVE-1609.2] specifies security services for
applications and management messages. This WAVE specification is applications and management messages, this WAVE specification is
optional, so if WAVE does not support the security of a WAVE frame, optional. Thus, if WAVE does not support the security of a WAVE
either the network layer or the transport layer needs to support frame, either the network layer or the transport layer needs to
security services for the WAVE frames. support security services for the WAVE frames.
For the setup of a secure channel over IPsec or TLS, the multihop V2I For the setup of a secure channel over IPsec or TLS, the multihop V2I
communications over DSRC is required in a highway for the communications over DSRC is required in a highway for the
authentication by involving multiple intermediate vehicles as relay authentication by involving multiple intermediate vehicles as relay
nodes toward an IP-RSU connected to an authentication server in the nodes toward an IP-RSU connected to an authentication server in the
vehicular cloud. The V2I communications over 5G V2X (or LTE V2X) is vehicular cloud. The V2I communications over 5G V2X (or LTE V2X) is
required to allow a vehicle to communicate directly with a gNodeB (or required to allow a vehicle to communicate directly with a gNodeB (or
eNodeB) connected to an authentication server in the vehicular cloud. eNodeB) connected to an authentication server in the vehicular cloud.
To prevent an adversary from tracking a vehicle with its MAC address To prevent an adversary from tracking a vehicle with its MAC address
skipping to change at page 29, line 49 skipping to change at page 30, line 18
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.
For the IPv6 ND, the DAD is required to ensure the uniqueness of the For the IPv6 ND, the DAD is required to ensure the uniqueness of the
IPv6 address of a vehicle's wireless interface. This DAD can be used IPv6 address of a vehicle's wireless interface. This DAD can be used
as a flooding attack that uses the DAD-related ND packets as a flooding attack that uses the DAD-related ND packets
disseminated over the VANET or vehicular networks. Thus, the disseminated over the VANET or vehicular networks. This possibility
vehicles and IP-RSUs need to filter out suspicious ND traffic in indicates that the vehicles and IP-RSUs need to filter out suspicious
advance. 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.
For mobility management, a malicious vehicle can construct multiple For mobility management, a malicious vehicle can construct multiple
virtual bogus vehicles, and register them with IP-RSUs and MA. This virtual bogus vehicles, and register them with IP-RSUs and MA. This
registration makes the IP-RSUs and MA waste their resources. The IP- registration makes the IP-RSUs and MA waste their resources. The IP-
RSUs and MA need to determine whether a vehicle is genuine or bogus RSUs and MA need to determine whether a vehicle is genuine or bogus
in mobility management. Also, the confidentiality of control packets in mobility management. Also, the confidentiality of control packets
and data packets among IP-RSUs and MA, the E2E paths (e.g., tunnels) and data packets among IP-RSUs and MA, the E2E paths (e.g., tunnels)
need to be protected by secure communication channels. In addition, need to be protected by secure communication channels. In addition,
to prevent bogus IP-RSUs and MA from interfering with the IPv6 to prevent bogus IP-RSUs and MA from interfering with the IPv6
mobility of vehicles, mutual authentication among them needs to be mobility of vehicles, mutual authentication among them needs to be
skipping to change at page 30, line 50 skipping to change at page 31, line 33
Networks", International Workshop on Device Centric Cloud Networks", International Workshop on Device Centric Cloud
(DC2), March 2016. (DC2), March 2016.
[CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T. [CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T.
Kim, "CBDN: Cloud-Based Drone Navigation for Efficient Kim, "CBDN: Cloud-Based Drone Navigation for Efficient
Battery Charging in Drone Networks", IEEE Transactions on Battery Charging in Drone Networks", IEEE Transactions on
Intelligent Transportation Systems, November 2019. Intelligent Transportation Systems, November 2019.
[DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., [DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Moses, D., and C. Perkins, "Protocol for Forwarding Policy
Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-14
(work in progress), March 2020. (work in progress), September 2020.
[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 31, line 38 skipping to change at page 32, line 24
[Fuel-Efficient] [Fuel-Efficient]
van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas,
"Fuel-Efficient En Route Formation of Truck Platoons", "Fuel-Efficient En Route Formation of Truck Platoons",
IEEE Transactions on Intelligent Transportation Systems, IEEE Transactions on Intelligent Transportation Systems,
January 2018. January 2018.
[ID-Multicast-Problems] [ID-Multicast-Problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-11 (work Media", draft-ietf-mboned-ieee802-mcast-problems-13 (work
in progress), December 2019. in progress), February 2021.
[Identity-Management] [Identity-Management]
Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer
Identities Management in ITS Stations", The 10th Identities Management in ITS Stations", The 10th
International Conference on ITS Telecommunications, International Conference on ITS Telecommunications,
November 2010. November 2010.
[IEEE-802.11-OCB] [IEEE-802.11-OCB]
"Part 11: Wireless LAN Medium Access Control (MAC) and "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Std Physical Layer (PHY) Specifications", IEEE Std
skipping to change at page 32, line 35 skipping to change at page 33, line 23
Networking - Amendment 1", ISO 21210:2012/AMD 1:2017, Networking - Amendment 1", ISO 21210:2012/AMD 1:2017,
September 2017. September 2017.
[NHTSA-ACAS-Report] [NHTSA-ACAS-Report]
National Highway Traffic Safety Administration (NHTSA), National Highway Traffic Safety Administration (NHTSA),
"Final Report of Automotive Collision Avoidance Systems "Final Report of Automotive Collision Avoidance Systems
(ACAS) Program", DOT HS 809 080, August 2000. (ACAS) Program", DOT HS 809 080, August 2000.
[OMNI] Templin, F. and A. Whyman, "Transmission of IPv6 Packets [OMNI] Templin, F. and A. Whyman, "Transmission of IPv6 Packets
over Overlay Multilink Network (OMNI) Interfaces", draft- over Overlay Multilink Network (OMNI) Interfaces", draft-
templin-6man-omni-interface-27 (work in progress), July templin-6man-omni-interface-97 (work in progress), March
2020. 2021.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
1999. 1999.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004. Reserved for Documentation", RFC 3849, July 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", RFC 4086, June "Randomness Requirements for Security", RFC 4086, June
2005. 2005.
[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, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
skipping to change at page 34, line 14 skipping to change at page 35, line 6
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011. Support in IPv6", RFC 6275, July 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6706BIS] [RFC6706BIS]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Automatic Extended Route Optimization
(AERO)", draft-templin-intarea-6706bis-58 (work in (AERO)", draft-templin-intarea-6706bis-95 (work in
progress), June 2020. progress), March 2021.
[RFC6830BIS] [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)",
draft-ietf-lisp-rfc6830bis-32 (work in progress), March draft-ietf-lisp-rfc6830bis-36 (work in progress), November
2020. 2020.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014. Environment", RFC 7149, March 2014.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7296, October 2014. (IKEv2)", RFC 7296, October 2014.
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", "Requirements for Distributed Mobility Management",
RFC 7333, August 2014. RFC 7333, August 2014.
[RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
Bernardos, "Distributed Mobility Management: Current Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429, January 2015. Practices and Gap Analysis", RFC 7429, January 2015.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028, November 2016.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, July 2017. (IPv6) Specification", RFC 8200, July 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018. Version 1.3", RFC 8446, August 2018.
[RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic
Support for IPv6 Networks Operating Outside the Context of Support for IPv6 Networks Operating Outside the Context of
a Basic Service Set over IEEE Std 802.11", RFC 8691, a Basic Service Set over IEEE Std 802.11", RFC 8691,
December 2019. December 2019.
skipping to change at page 36, line 7 skipping to change at page 36, line 50
3GPP, "Architecture Enhancements for V2X Services", 3GPP 3GPP, "Architecture Enhancements for V2X Services", 3GPP
TS 23.285/Version 16.2.0, December 2019. TS 23.285/Version 16.2.0, December 2019.
[TS-23.287-3GPP] [TS-23.287-3GPP]
3GPP, "Architecture Enhancements for 5G System (5GS) to 3GPP, "Architecture Enhancements for 5G System (5GS) to
Support Vehicle-to-Everything (V2X) Services", 3GPP Support Vehicle-to-Everything (V2X) Services", 3GPP
TS 23.287/Version 16.2.0, March 2020. TS 23.287/Version 16.2.0, March 2020.
[UAM-ITS] Templin, F., "Urban Air Mobility Implications for [UAM-ITS] Templin, F., "Urban Air Mobility Implications for
Intelligent Transportation Systems", draft-templin-ipwave- Intelligent Transportation Systems", draft-templin-ipwave-
uam-its-03 (work in progress), July 2020. uam-its-04 (work in progress), January 2021.
[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.
[VIP-WAVE] [VIP-WAVE]
Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
Feasibility of IP Communications in 802.11p Vehicular Feasibility of IP Communications in 802.11p Vehicular
skipping to change at page 37, line 13 skipping to change at page 38, line 13
Operation", IEEE Std 1609.4-2016, March 2016. Operation", IEEE Std 1609.4-2016, March 2016.
Appendix A. Acknowledgments Appendix A. 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 (Ministry of Science and This work was supported in part by the MSIT, Korea, under the ITRC
ICT), Korea, under the ITRC (Information Technology Research Center) (Information Technology Research Center) support program (IITP-
support program (IITP-2019-2017-0-01633) supervised by the IITP 2020-2017-0-01633) supervised by the IITP.
(Institute for Information & communications Technology Promotion).
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).
Appendix B. Contributors Appendix B. Contributors
This document is a group work of IPWAVE working group, greatly This document is a group work of IPWAVE working group, greatly
benefiting from inputs and texts by Rex Buddenberg (Naval benefiting from inputs and texts by Rex Buddenberg (Naval
Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest
University of Technology and Economics), Jose Santa Lozanoi University of Technology and Economics), Jose Santa Lozanoi
(Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot),
Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche
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), and Peter E. University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), Peter E. Yee
Yee (Akayla). The authors sincerely appreciate their contributions. (Akayla), and Erik Kline. The authors sincerely appreciate their
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 Department of Computer Sciences
High School of Technology of Meknes High School of Technology of Meknes
Moulay Ismail University Moulay Ismail University
Morocco Morocco
Phone: +212 6 70 83 22 36 Phone: +212 6 70 83 22 36
skipping to change at page 39, line 35 skipping to change at page 40, line 35
Michelle Wetterwald Michelle Wetterwald
FBConsulting FBConsulting
21, Route de Luxembourg 21, Route de Luxembourg
Wasserbillig, Luxembourg L-6633 Wasserbillig, Luxembourg L-6633
Luxembourg Luxembourg
EMail: Michelle.Wetterwald@gmail.com 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
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
 End of changes. 31 change blocks. 
64 lines changed or deleted 108 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/