draft-ietf-ipwave-vehicular-networking-10.txt   draft-ietf-ipwave-vehicular-networking-11.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 8, 2019 Intended status: Informational July 20, 2019
Expires: January 9, 2020 Expires: January 21, 2020
IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement
and Use Cases and Use Cases
draft-ietf-ipwave-vehicular-networking-10 draft-ietf-ipwave-vehicular-networking-11
Abstract Abstract
This document discusses the problem statement and use cases of IP- This document discusses the problem statement and use cases of IP-
based vehicular networking for Intelligent Transportation Systems based vehicular networking for Intelligent Transportation Systems
(ITS). The main scenarios of vehicular communications are vehicle- (ITS). The main scenarios of vehicular communications are vehicle-
to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to- to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-
everything (V2X) communications. First, this document explains use everything (V2X) communications. First, this document explains use
cases using V2V, V2I, and V2X networking. Next, it makes a problem cases using V2V, V2I, and V2X networking. Next, it makes a problem
statement about key aspects in IP-based vehicular networking, such as statement about key aspects in IP-based vehicular networking, such as
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 January 9, 2020. This Internet-Draft will expire on January 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 7 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 7
4.1. Vehicular Network Architecture . . . . . . . . . . . . . 8 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 8
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 10 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 9
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 12 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 11
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 13 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 13 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 13
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 16 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 16
5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 16 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 16
5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 17 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 17
5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 18 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . 20 7. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes from draft-ietf-ipwave-vehicular- Appendix A. Changes from draft-ietf-ipwave-vehicular-
networking-09 . . . . . . . . . . . . . . . . . . . 26 networking-10 . . . . . . . . . . . . . . . . . . . 25
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 25
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 27 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
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),
vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X)
networking. Also, the European Union (EU) passed a decision to networking. The European Union (EU) allocated radio spectrum for
allocate a radio spectrum for safety-related and non-safety-related safety-related and non-safety-related applications of ITS with the
applications of ITS with the frequency band of 5.875 - 5.905 GHz, frequency band of 5.875 - 5.905 GHz, as part of the Commission
which is called Commission Decision 2008/671/EC [EU-2008-671-EC]. Decision 2008/671/EC [EU-2008-671-EC].
For direct inter-vehicular wireless connectivity, IEEE has amended For direct inter-vehicular wireless connectivity, IEEE has amended
WiFi standard 802.11 to enable driving safety services based on the WiFi standard 802.11 to enable driving safety services based on DSRC
DSRC in terms of standards for the Wireless Access in Vehicular for the Wireless Access in Vehicular Environments (WAVE) system. The
Environments (WAVE) system. The Physical Layer (L1) and Data Link Physical Layer (L1) and Data Link Layer (L2) issues are addressed in
Layer (L2) issues are addressed in IEEE 802.11p [IEEE-802.11p] for IEEE 802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while
the PHY and MAC of the DSRC, while IEEE 1609.2 [WAVE-1609.2] covers IEEE 1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3
security aspects, IEEE 1609.3 [WAVE-1609.3] defines related services [WAVE-1609.3] defines related services at network and transport
at network and transport layers, and IEEE 1609.4 [WAVE-1609.4] layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel
specifies the multi-channel operation. Note that IEEE 802.11p was a operation. IEEE 802.11p was first a separate amendment, but was
separate standard, but was later enrolled into the base 802.11 later rolled into the base 802.11 standard (IEEE 802.11-2012) as IEEE
standard (IEEE 802.11-2012) as IEEE 802.11 Outside the Context of a 802.11 Outside the Context of a Basic Service Set (OCB) in 2012
Basic Service Set in 2012 [IEEE-802.11-OCB]. [IEEE-802.11-OCB].
Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP
protocols (e.g., MIPv4 [RFC5944], MIPv6 [RFC6275], and Proxy MIPv6 protocols (e.g., MIPv4 [RFC5944], MIPv6 [RFC6275], and Proxy MIPv6
(PMIPv6) [RFC5213][RFC5844]) can be applied (or easily modified) to (PMIPv6) [RFC5213][RFC5844]) can be applied to vehicular networks.
vehicular networks. In Europe, ETSI has standardized a GeoNetworking In Europe, ETSI has standardized a GeoNetworking (GN) protocol
(GN) protocol [ETSI-GeoNetworking] and a protocol adaptation sub- [ETSI-GeoNetworking] and a protocol adaptation sub-layer from
layer from GeoNetworking to IPv6 [ETSI-GeoNetwork-IP]. Note that a GeoNetworking to IPv6 [ETSI-GeoNetwork-IP]. GN protocols are useful
GN protocol is useful to route an event or notification message to to route an event or notification message to vehicles around a
vehicles around a geographic position, such as an acciendent area in geographic position, such as an accident area in a roadway. In
a roadway. In addition, ISO has approved a standard specifying the addition, ISO has approved a standard specifying the IPv6 network
IPv6 network protocols and services to be used for Communications protocols and services to be used for Communications Access for Land
Access for Land Mobiles (CALM) [ISO-ITS-IPv6]. Mobiles (CALM) [ISO-ITS-IPv6].
This document explains use cases and a problem statement about IP- This document describes use cases and a problem statement about IP-
based vehicular networking for ITS, which is named IP Wireless Access based vehicular networking for ITS, which is named IP Wireless Access
in Vehicular Environments (IPWAVE). First, it introduces the use in Vehicular Environments (IPWAVE). First, it introduces the use
cases for using V2V, V2I, and V2X networking in the ITS. Next, it cases for using V2V, V2I, and V2X networking in ITS. Next, it makes
makes a problem statement about key aspects in IPWAVE, such as IPv6 a problem statement about key aspects in IPWAVE, namely, IPv6
Neighbor Discovery, Mobility Management, and Security & Privacy. For Neighbor Discovery, Mobility Management, and Security & Privacy. For
each key aspect of the problem statement, this document specifies each key aspect of the problem statement, this document specifies
requirements in IP-based vehicular networking, and proposes the requirements in IP-based vehicular networking, and proposes the
direction of solutions fulfilling those requirements. Therefore, direction of solutions fulfilling those requirements. This document
with the problem statement, this document will open a door to develop is intended to motivate development of key protocols for IPWAVE.
key protocols for IPWAVE that will be essential to IP-based vehicular
networks in near future.
2. Terminology 2. Terminology
This document uses the following definitions: This document uses the following definitions:
o DMM: Acronym for "Distributed Mobility Management" o LiDAR: "Light Detection and Ranging". It is a scanning device to
[RFC7333][RFC7429]. measure a distance to an object by emitting pulsed laser light and
measuring the reflected pulsed light.
o LiDAR: Acronym for "Light Detection and Ranging". It is a
scanning device to measure a distance to an object by emitting
pulsed laser light and measuring the reflected pulsed light.
o Mobility Anchor (MA): A node that maintains IP addresses and o Mobility Anchor (MA): A node that maintains IP addresses and
mobility information of vehicles in a road network to support mobility information of vehicles in a road network to support
their address autoconfiguration and mobility management with a their address autoconfiguration and mobility management with a
binding table. It has end-to-end connections with RSUs under its binding table. An MA has end-to-end connections with RSUs under
control. its control.
o On-Board Unit (OBU): A node that has physical communication o On-Board Unit (OBU): A node that has physical communication
devices (e.g., IEEE 802.11-OCB and Cellular V2X (C-V2X) devices (e.g., IEEE 802.11-OCB and Cellular V2X (C-V2X)
[TS-23.285-3GPP]) for wireless communications with other OBUs and [TS-23.285-3GPP]) for wireless communications with other OBUs and
RSUs, and may be connected to in-vehicle devices or networks. An RSUs, and may be connected to in-vehicle devices or networks. An
OBU is mounted on a vehicle. OBU is mounted on a vehicle.
o OCB: Acronym for "Outside the Context of a Basic Service Set" o OCB: "Outside the Context of a Basic Service Set"
[IEEE-802.11-OCB]. [IEEE-802.11-OCB].
o Road-Side Unit (RSU): A node that has physical communication o Road-Side Unit (RSU): A node that has physical communication
devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless
communications with vehicles and is also connected to the Internet communications with vehicles and is also connected to the Internet
as a router or switch for packet forwarding. An RSU is typically as a router or switch for packet forwarding. An RSU is typically
deployed on the road infrastructure, either at an intersection or deployed on the road infrastructure, either at an intersection or
in a road segment, but may also be located in car parking area. in a road segment, but may also be located in a car parking area.
o Traffic Control Center (TCC): A node that maintains road o Traffic Control Center (TCC): A node that maintains road
infrastructure information (e.g., RSUs, traffic signals, and loop infrastructure information (e.g., RSUs, traffic signals, and loop
detectors), vehicular traffic statistics (e.g., average vehicle detectors), vehicular traffic statistics (e.g., average vehicle
speed and vehicle inter-arrival time per road segment), and speed and vehicle inter-arrival time per road segment), and
vehicle information (e.g., a vehicle's identifier, position, vehicle information (e.g., a vehicle's identifier, position,
direction, speed, and trajectory as a navigation path). TCC is direction, speed, and trajectory as a navigation path). TCC is
included in a vehicular cloud for vehicular networks. included in a vehicular cloud for vehicular networks.
o Vehicle: A node that has an OBU for wireless communication with o Vehicle: A Vehicle in this document is a node that has an OBU for
other vehicles and RSUs. It has a radio navigation receiver of wireless communication with other vehicles and RSUs. It has a
Global Positioning System (GPS) for efficient navigation. radio navigation receiver of Global Positioning System (GPS) for
efficient navigation.
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. Since VANET is vehicles interconnected by wireless communication. Two vehicles
a connected network component, two vehicles in a VANET can in a VANET can communicate with each other using other vehicles as
communicate with each other through ad hoc routing via other relays even where they are out of one-hop wireless communication
vehicles as relays even where they are out of one-hop wireless range.
communication 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 nodes. having compute nodes, storage nodes, and network forwarding
elements (e.g., switch and router).
o Vehicle Detection Loop (i.e., Loop Detector): An inductive device o Vehicle Detection Loop (i.e., Loop Detector): An inductive device
used for detecting vehicles passing or arriving at a certain used for detecting vehicles passing or arriving at a certain
point, for instance, at an intersection with traffic lights or at point, for instance, at an intersection with traffic lights or at
a ramp toward a highway. The relatively crude nature of the a ramp toward a highway. The relatively crude nature of the
loop's structure means that only metal masses above a certain size loop's structure means that only metal masses above a certain size
are capable of triggering the detection. are capable of triggering the detection.
o V2I2P: Acronym for "Vehicle to Infrastructure to Pedestrian". o V2I2P: "Vehicle to Infrastructure to Pedestrian".
o V2I2V: Acronym for "Vehicle to Infrastructure to Vehicle". o V2I2V: "Vehicle to Infrastructure to Vehicle".
o WAVE: Acronym for "Wireless Access in Vehicular Environments" o WAVE: "Wireless Access in Vehicular Environments" [WAVE-1609.0].
[WAVE-1609.0].
3. Use Cases 3. Use Cases
This section explains use cases of V2V, V2I, and V2X networking. The This section explains use cases of V2V, V2I, and V2X networking. The
use cases of the V2X networking exclude the ones of the V2V and V2I use cases of the V2X networking exclude the ones of the V2V and V2I
networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to-
Device (V2D). Device (V2D).
3.1. V2V 3.1. V2V
skipping to change at page 5, line 43 skipping to change at page 5, line 38
o Cooperative adaptive cruise control in an urban roadway; o Cooperative adaptive cruise control in an urban roadway;
o Platooning in a highway; o Platooning in a highway;
o Cooperative environment sensing. o Cooperative environment sensing.
These four techniques will be important elements for self-driving These four techniques will be important elements for self-driving
vehicles. vehicles.
Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
to drive safely by letting the drivers recognize dangerous obstacles to drive safely by alerting the drivers about dangerous obstacles and
and situations. That is, CASD navigator displays obstables or situations. That is, CASD navigator displays obstables 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
automatic safety action plan, which considers three situations, such automatic safety action plan, which considers three situations,
as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe
situations. This action plan can be performed among vehicles through situations. This action plan can be put into action among multiple
V2V networking. vehicles using V2V networking.
Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps
vehicles to adapt their speed autonomously through V2V communication vehicles to adapt their speed autonomously through V2V communication
among vehicles according to the mobility of their predecessor and among vehicles according to the mobility of their predecessor and
successor vehicles in an urban roadway or a highway. Thus, CACC can successor vehicles in an urban roadway or a highway. Thus, CACC can
help adjacent vehicles to efficiently adjust their speed in an help adjacent vehicles to efficiently adjust their speed in an
interactive way through V2V networking in order to avoid collision. interactive way through V2V networking in order to avoid collision.
Platooning [Truck-Platooning] allows a series of vehicles (e.g., Platooning [Truck-Platooning] allows a series of vehicles (e.g.,
trucks) to move together with a very short inter-distance. Trucks trucks) to follow each other very closely. Trucks can use V2V
can use V2V communication in addition to forward sensors in order to communication in addition to forward sensors in order to maintain
maintain constant clearance between two consecutive vehicles at very constant clearance between two consecutive vehicles at very short
short gaps (from 3 meters to 10 meters). This platooning can gaps (from 3 meters to 10 meters). Platooning can maximize the
maximize the throughput of vehicular traffic in a highway and reduce throughput of vehicular traffic in a highway and reduce the gas
the gas consumption because the leading vehicle can help the consumption because the leading vehicle can help the following
following vehicles to experience less air resistance. vehicles to experience less air resistance.
Cooperative-environment-sensing use cases suggest that vehicles can Cooperative-environment-sensing use cases suggest that vehicles can
share environmental information from various vehicle-mounted sensors, share environmental information from various vehicle-mounted sensors,
such as radars, LiDARs, and cameras with other vehicles and such as radars, LiDARs, and cameras with other vehicles and
pedestrians. [Automotive-Sensing] introduces a millimeter-wave pedestrians. [Automotive-Sensing] introduces a millimeter-wave
vehicular communication for massive automotive sensing. Data vehicular communication for massive automotive sensing. A lot of
generated by those sensors can be substantially large, and these data data can be generated by those sensors, and these data typically need
shall be routed to different destinations. In addition, from the to be routed to different destinations. In addition, from the
perspective of driverless vehicles, it is expected that driverless perspective of driverless vehicles, it is expected that driverless
vehicles can be mixed with driver-operated vehicles. Through the vehicles can be mixed with driver-operated vehicles. Through the
cooperative environment sensing, driver-operated vehicles can use cooperative environment sensing, driver-operated vehicles can use
environmental information sensed by driverless vehicles for better environmental information sensed by driverless vehicles for better
interaction with the context. interaction with the other vehicles and environment.
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;
o Energy-efficient speed recommendation service; o Energy-efficient speed recommendation service;
o Accident notification service. o Accident notification service.
A navigation service, such as the Self-Adaptive Interactive A navigation service, for example, the Self-Adaptive Interactive
Navigation Tool (called SAINT) [SAINT], using V2I networking Navigation Tool (SAINT) [SAINT], using V2I networking interacts with
interacts with TCC for the large-scale/long-range road traffic TCC for the large-scale/long-range road traffic optimization and can
optimization and can guide individual vehicles for appropriate guide individual vehicles for appropriate navigation paths in real
navigation paths in real time. The enhanced version of SAINT time. The enhanced version of SAINT [SAINTplus] can give fast moving
[SAINTplus] can give the fast moving paths to emergency vehicles paths to emergency vehicles (e.g., ambulance and fire engine) to let
(e.g., ambulance and fire engine) to let them reach an accident spot them reach an accident spot while redirecting other vehicles near the
while providing other vehicles near the accident spot with efficient accident spot into efficient detour paths.
detour paths.
A TCC can recommend an energy-efficient speed to a vehicle driving in A TCC can recommend an energy-efficient speed to a vehicle that
different traffic environments. [Fuel-Efficient] studies fuel- depends on its traffic environment. [Fuel-Efficient] studies fuel-
efficient route and speed plans for platooned trucks. efficient route and speed plans for platooned trucks.
The emergency communication between accident vehicles (or emergency The emergency communication between accident vehicles (or emergency
vehicles) and TCC can be performed via either RSU or 4G-LTE networks. vehicles) and TCC can be performed via either RSU or 4G-LTE networks.
The First Responder Network Authority (FirstNet) [FirstNet] is The First Responder Network Authority (FirstNet) [FirstNet] is
provided by the US government to establish, operate, and maintain an provided by the US government to establish, operate, and maintain an
interoperable public safety broadband network for safety and security interoperable public safety broadband network for safety and security
network services, such as emergency calls. The construction of the network services, e.g., emergency calls. The construction of the
nationwide FirstNet network requires each state in the US to have a nationwide FirstNet network requires each state in the US to have a
Radio Access Network (RAN) that will connect to the FirstNet's Radio Access Network (RAN) that will connect to the FirstNet's
network core. The current RAN is mainly constructed by 4G-LTE for network core. The current RAN is mainly constructed by 4G-LTE for
the communication between a vehicle and an infrastructure node (i.e., the communication between a vehicle and an infrastructure node (i.e.,
V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular
networks [DSRC] will be available for V2I and V2V in near future. networks [DSRC] will be available for V2I and V2V in near future.
3.3. V2X 3.3. V2X
The use case of V2X networking discussed in this section is The use case of V2X networking discussed in this section is
pedestrian protection service. pedestrian protection service.
A pedestrian protection service, such as Safety-Aware Navigation A pedestrian protection service, such as Safety-Aware Navigation
Application (called SANA) [SANA], using V2I2P networking can reduce Application (SANA) [SANA], using V2I2P networking can reduce the
the collision of a vehicle and a pedestrian carrying a smartphone collision of a vehicle and a pedestrian carrying a smartphone
equipped with a network device for wireless communication (e.g., equipped with a network device for wireless communication (e.g.,
WiFi) with an RSU. Vehicles and pedestrians can also communicate WiFi) with an RSU. Vehicles and pedestrians can also communicate
with each other via an RSU that delivers scheduling information for with each other via an RSU that delivers scheduling information for
wireless communication in order to save the smartphones' battery wireless communication in order to save the smartphones' battery
through sleeping mode. through sleeping mode.
For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's
smartphone can directly communicate with each other via V2X without smartphone can directly communicate with each other via V2X without
the relaying of an RSU as in the V2V scenario that the pedestrian's the relaying of an RSU as in the V2V scenario that the pedestrian's
smartphone is regarded as a vehicle with a wireless media interface smartphone is regarded as a vehicle with a wireless media interface
to be able to communicate with another vehicle. In Vehicle-to-Device to be able to communicate with another vehicle. There are light-
(V2D), a device can be a mobile node such as bicycle and motorcycle, weight mobile nodes such as bicycle and motorcycle, and they can
and can communicate directly with a vehicle for collision avoidance. communicate directly with a vehicle for collision avoidance using
V2V.
4. Vehicular Networks 4. Vehicular Networks
This section describes a vehicular network architecture supporting This section describes a vehicular network architecture supporting
V2V, V2I, and V2X communications in vehicular networks. Also, it V2V, V2I, and V2X communications in vehicular networks. Also, it
describes an internal network within a vehicle or RSU, and the describes an internal network within a vehicle or RSU, and the
internetworking between the internal networks via DSRC links. internetworking between the internal networks via DSRC links.
Traffic Control Center in Vehicular Cloud Traffic Control Center in Vehicular Cloud
*-----------------------------------------* *-----------------------------------------*
* * * *
* +----------------+ * * +-----------------+ *
* | Mobility Anchor| * * | Mobility Anchor | *
* +----------------+ * * +-----------------+ *
* ^ * * ^ *
* | * * | *
*--------------------v--------------------* *--------------------v--------------------*
^ ^ ^ ^ ^ ^
| | | | | |
| | | | | |
v v v v v v
+--------+ Ethernet +--------+ +--------+ +--------+ Ethernet +--------+ +--------+
| RSU1 |<-------->| RSU2 |<---------->| RSU3 | | RSU1 |<-------->| RSU2 |<---------->| RSU3 |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
skipping to change at page 8, line 42 skipping to change at page 8, line 42
Subnet1 Subnet2 Subnet3 Subnet1 Subnet2 Subnet3
<----> Wired Link <....> Wireless Link ===> Moving Direction <----> Wired Link <....> Wireless Link ===> Moving Direction
Figure 1: A Vehicular Network Architecture for V2I and V2V Networking Figure 1: A Vehicular Network Architecture for V2I and V2V Networking
4.1. Vehicular Network Architecture 4.1. Vehicular Network Architecture
Figure 1 shows an architecture for V2I and V2V networking in a road Figure 1 shows an architecture for V2I and V2V networking in a road
network. As shown in this figure, RSUs as routers and vehicles with network. As shown in this figure, RSUs as routers and vehicles with
OBU have wireless media interfaces for VANET. Also, it is assumed OBU have wireless media interfaces for VANET. Furthermore, the
that such the wireless media interfaces are autoconfigured with a wireless media interfaces are autoconfigured with a global IPv6
global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and V2I
V2I networking. Note that 2001:DB8::/32 is a documentation prefix networking. Note that 2001:DB8::/32 is a documentation prefix
[RFC3849] for example prefixes in this document, and also that any [RFC3849] for example prefixes in this document, and also that any
routable IPv6 address needs to be routable in a VANET and a vehicular routable IPv6 address needs to be routable in a VANET and a vehicular
network including RSUs. network including RSUs.
Especially, for IPv6 packets transporting over IEEE 802.11-OCB, For IPv6 packets transported over IEEE 802.11-OCB,
[IPv6-over-802.11-OCB] specifies several details, such as Maximum [IPv6-over-802.11-OCB] specifies several details, including Maximum
Transmission Unit (MTU), frame format, link-local address, address Transmission Unit (MTU), frame format, link-local address, address
mapping for unicast and multicast, stateless autoconfiguration, and mapping for unicast and multicast, stateless autoconfiguration, and
subnet structure. Especially, an Ethernet Adaptation (EA) layer is subnet structure. An Ethernet Adaptation (EA) layer is in charge of
in charge of transforming some parameters between IEEE 802.11 MAC transforming some parameters between IEEE 802.11 MAC layer and IPv6
layer and IPv6 network layer, which is located between IEEE network layer, which is located between IEEE 802.11-OCB's logical
802.11-OCB's logical link control layer and IPv6 network layer. This link control layer and IPv6 network layer. This IPv6 over 802.11-OCB
IPv6 over 802.11-OCB can be used for both V2V and V2I in IP-based can be used for both V2V and V2I in IP-based vehicular networks.
vehicular networks.
In Figure 1, three RSUs (RSU1, RSU2, and RSU3) are deployed in the In Figure 1, three RSUs (RSU1, RSU2, and RSU3) are deployed in the
road network and are connected to a Vehicular Cloud through the road network and are connected to a Vehicular Cloud through the
Internet. A Traffic Control Center (TCC) is connected to the Internet. A Traffic Control Center (TCC) is connected to the
Vehicular Cloud for the management of RSUs and vehicles in the road Vehicular Cloud for the management of RSUs and vehicles in the road
network. A Mobility Anchor (MA) is located in the TCC as its key network. A Mobility Anchor (MA) is located in the TCC as its key
component for the mobility management of vehicles. Two vehicles component for the mobility management of vehicles. Two vehicles
(Vehicle1 and Vehicle2) are wirelessly connected to RSU1, and one (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, and one
vehicle (Vehicle3) is wirelessly connected to RSU2. The wireless vehicle (Vehicle3) is wirelessly connected to RSU2. The wireless
networks of RSU1 and RSU2 belong to two different subnets (denoted as networks of RSU1 and RSU2 belong to two different subnets (Subnet1
Subnet1 and Subnet2), respectively. Also, another vehicle (Vehicle4) and Subnet2), respectively. Another vehicle (Vehicle4) belonging to
is wireless connected to RSU3, belonging to another subnet (denoted another subnet (Subnet3) is wirelessly connected to RSU3.
as Subnet3).
In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2 In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2
in Figure 1), vehicles can construct a connected VANET (with an in Figure 1), vehicles can construct a connected VANET (with an
arbitrary graph topology) and can communicate with each other via V2V arbitrary graph topology) and can communicate with each other via V2V
communication. Vehicle1 can communicate with Vehicle2 via V2V communication. Vehicle1 can communicate with Vehicle2 via V2V
communication, and Vehicle2 can communicate with Vehicle3 via V2V communication, and Vehicle2 can communicate with Vehicle3 via V2V
communication because they are within the wireless communication communication because they are within the wireless communication
range for each other. On the other hand, Vehicle3 can communicate range for each other. On the other hand, Vehicle3 can communicate
with Vehicle4 via the vehicular infrastructure (i.e., RSU2 and RSU3) with Vehicle4 via the vehicular infrastructure (i.e., RSU2 and RSU3)
by employing V2I (i.e., V2I2V) communication because they are not by employing V2I (i.e., V2I2V) communication because they are not
within the wireless communication range for each other. within the wireless communication range for each other.
In vehicular networks, unidirectional links exist and must be In vehicular networks, asymmetric links sometimes exist and must be
considered for wireless communications. Also, in the vehicular considered for wireless communications. In vehicular networks, the
networks, control plane can be separated from data plane for control plane can be separated from the data plane for efficient
efficient mobility management and data forwarding using Software- mobility management and data forwarding. The mobility information of
Defined Networking (SDN) [SDN-DMM]. The mobility information of a a GPS receiver mounted in its vehicle (e.g., position, speed, and
GPS receiver mounted in its vehicle (e.g., trajectory, position, direction) can be used to accommodate mobility-aware proactive
speed, and direction) can be used for the accommodation of mobility- protocols. Vehicles can use the TCC as their Home Network having a
aware proactive protocols. Vehicles can use the TCC as their Home home agent for mobility management as in MIPv6 [RFC6275] and PMIPv6
Network having a home agent for mobility management as in MIPv6 [RFC5213], so the TCC maintains the mobility information of vehicles
[RFC6275] and PMIPv6 [RFC5213], so the TCC maintains the mobility for location management. IP tunneling over the wireless link should
information of vehicles for location management. Also, IP tunneling be avoided for performance efficiency.
over the wireless link should be avoided for performance efficiency.
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 RSU's internal network internal network (i.e., moving network) and an RSU's internal network
(i.e., fixed network) via V2I communication. (i.e., fixed network) via V2I communication.
+-----------------+ +-----------------+
(*)<........>(*) +----->| Vehicular Cloud | (*)<........>(*) +----->| Vehicular Cloud |
2001:DB8:1:1::/64 | | | +-----------------+ 2001:DB8:1:1::/64 | | | +-----------------+
skipping to change at page 10, line 47 skipping to change at page 10, line 41
<----> Wired Link <....> Wireless Link (*) Antenna <----> Wired Link <....> Wireless Link (*) Antenna
Figure 2: Internetworking between Vehicle Network and RSU Network Figure 2: Internetworking between Vehicle Network and RSU Network
Nowadays, a vehicle's internal network tends to be Ethernet to Nowadays, a vehicle's internal network tends to be Ethernet to
interconnect electronic control units in a vehicle. It can also interconnect electronic control units in a vehicle. It can also
support WiFi and Bluetooth to accommodate a driver's and passenger's support WiFi and Bluetooth to accommodate a driver's and passenger's
mobile devices (e.g., smartphone and tablet). In this trend, it is mobile devices (e.g., smartphone and tablet). In this trend, it is
reasonable to consider a vehicle's internal network (i.e., moving reasonable to consider a vehicle's internal network (i.e., moving
network) and also the interaction between the internal network and an network) and also the interaction between the internal network and an
external network within another vehicle or RSU. external network within another vehicle or RSU. A vehicle's internal
network often uses Ethernet to interconnect control units in the
vehicle. The internal network also supports WiFi and Bluetooth to
accommodate a driver's and passenger's mobile devices (e.g.,
smartphone or tablet). It is reasonable to consider the interaction
between the internal network and an external network within another
vehicle or RSU.
As shown in Figure 2, the vehicle's moving network and the RSU's As shown in Figure 2, the vehicle's moving network and the RSU's
fixed network are self-contained networks having multiple subnets and fixed network are self-contained networks having multiple subnets and
having an edge router for the communication with another vehicle or having an edge router for the communication with another vehicle or
RSU. Internetworking between two internal networks via V2I RSU. Internetworking between two internal networks via V2I
communication requires an exchange of network prefix and other communication requires an exchange of network prefix and other
parameters through a prefix discovery mechanism, such as ND-based parameters through a prefix discovery mechanism, such as ND-based
prefix discovery [ID-Vehicular-ND]. For the ND-based prefix prefix discovery [ID-Vehicular-ND]. For ND-based prefix discovery,
discovery, network prefixs and parameters should be registered into a network prefixes and parameters should be registered with a vehicle's
vehicle's router and an RSU router with an external network interface router and an RSU router with an external network interface in
in advance. advance.
The network parameter discovery collects networking information for For an IP communication between a vehicle and an RSU or between two
an IP communication between a vehicle and an RSU or between two neighboring vehicles, the network parameter discovery collects
neighboring vehicles, such as link layer, MAC layer, and IP layer information relevant to the link layer, MAC layer, and IP layer. The
information. The link layer information includes wireless link layer link layer information includes wireless link layer parameters and
parameters, such as wireless media (e.g., IEEE 802.11-OCB and LTE- transmission power level. The MAC layer information includes the MAC
V2X) and a transmission power level. The MAC layer information address of an external network interface for the internetworking with
includes the MAC address of an external network interface for the another vehicle or RSU. The IP layer information includes the IP
internetworking with another vehicle or RSU. The IP layer address and prefix of an external network interface for the
information includes the IP address and prefix of an external network internetworking with another vehicle or RSU.
interface for the internetworking with another vehicle or RSU.
Once the network parameter discovery and prefix exchange operations Once the network parameter discovery and prefix exchange operations
have been performed, packets can be transmitted between the vehicle's have been performed, packets can be transmitted between the vehicle's
moving network and the RSU's fixed network. A DNS service should be moving network and the RSU's fixed network. A DNS service should be
supported for the DNS name resolution of in-vehicle devices within a supported for the DNS name resolution of in-vehicle devices within a
vehicle's internal network as well as for the DNS name resolution of vehicle's internal network as well as for the DNS name resolution of
those devices from a remote host in the Internet for on-line those devices from a remote host in the Internet for on-line
diagnosis (e.g., an automotive service center server). It is assumed diagnosis (e.g., an automotive service center server). The DNS names
that the DNS names of in-vehicle devices and their service names are of in-vehicle devices and their service names can be registered with
registered into a DNS server in a vehicle or an RSU, as shown in a DNS server in a vehicle or an RSU, as shown in Figure 2.
Figure 2.
Figure 2 shows internetworking between the vehicle's moving network Figure 2 also shows internetworking between the vehicle's moving
and the RSU's fixed network. There exists an internal network network and the RSU's fixed network. There exists an internal
(Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server network (Moving Network1) inside Vehicle1. Vehicle1 has the DNS
(DNS1), the two hosts (Host1 and Host2), and the two routers (Router1 Server (DNS1), the two hosts (Host1 and Host2), and the two routers
and Router2). There exists another internal network (Fixed Network1) (Router1 and Router2). There exists another internal network (Fixed
inside RSU1. RSU1 has the DNS Server (DNS2), one host (Host3), the Network1) inside RSU1. RSU1 has the DNS Server (DNS2), one host
two routers (Router3 and Router4), and the collection of servers (Host3), the two routers (Router3 and Router4), and the collection of
(Server1 to ServerN) for various services in the road networks, such servers (Server1 to ServerN) for various services in the road
as the emergency notification and navigation. Vehicle1's Router1 networks, such as the emergency notification and navigation.
(called mobile router) and RSU1's Router3 (called fixed router) use Vehicle1's Router1 (a mobile router) and RSU1's Router3 (a fixed
2001:DB8:1:1::/64 for an external link (e.g., DSRC) for I2V router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
networking. Thus, one host (Host1) in Vehicle1 can communicate with V2I networking. Thus, one host (Host1) in Vehicle1 can communicate
one server (Server1) in RSU1 for a vehicular service through with one server (Server1) in RSU1 for a vehicular service through
Vehicle1's moving network, a wireless link between Vehicle1 and RSU1, Vehicle1's moving network, a wireless link between Vehicle1 and RSU1,
and RSU1's fixed network. and RSU1's fixed network.
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 | |
skipping to change at page 12, line 46 skipping to change at page 12, line 41
Figure 3: Internetworking between Two Vehicle Networks Figure 3: Internetworking between Two Vehicle Networks
Figure 3 shows internetworking between the moving networks of two Figure 3 shows internetworking between the moving networks of two
neighboring vehicles. There exists an internal network (Moving neighboring vehicles. There exists an internal network (Moving
Network1) inside Vehicle1. Vehicle1 has the DNS Server (DNS1), the Network1) inside Vehicle1. Vehicle1 has the DNS Server (DNS1), the
two hosts (Host1 and Host2), and the two routers (Router1 and two hosts (Host1 and Host2), and the two routers (Router1 and
Router2). There exists another internal network (Moving Network2) Router2). There exists another internal network (Moving Network2)
inside Vehicle2. Vehicle2 has the DNS Server (DNS3), the two hosts inside Vehicle2. Vehicle2 has the DNS Server (DNS3), the two hosts
(Host4 and Host5), and the two routers (Router5 and Router6). (Host4 and Host5), and the two routers (Router5 and Router6).
Vehicle1's Router1 (called mobile router) and Vehicle2's Router5 Vehicle1's Router1 (a mobile router) and Vehicle2's Router5 (a mobile
(called mobile router) use 2001:DB8:1:1::/64 for an external link router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
(e.g., DSRC) for V2V networking. Thus, one host (Host1) in Vehicle1 V2V networking. Thus, one host (Host1) in Vehicle1 can communicate
can communicate with one host (Host4) in Vehicle1 for a vehicular with one host (Host4) in Vehicle1 for a vehicular service through
service through Vehicle1's moving network, a wireless link between Vehicle1's moving network, a wireless link between Vehicle1 and
Vehicle1 and Vehicle2, and Vehicle2's moving network. Vehicle2, and Vehicle2's moving network.
(*)<..................>(*)<..................>(*) (*)<..................>(*)<..................>(*)
| | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | | | | | |
| +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ |
| |Router1| | | |Router5| | | |Router7| | | |Router1| | | |Router5| | | |Router7| |
| +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ |
| | | | | | | | | | | |
| +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ |
skipping to change at page 13, line 32 skipping to change at page 13, line 32
Figure 4: Multihop Internetworking between Two Vehicle Networks Figure 4: Multihop Internetworking between Two Vehicle Networks
Figure 4 shows multihop internetworking between the moving networks Figure 4 shows multihop internetworking between the moving networks
of two vehicles in the same VANET. For example, Host1 in Vehicle1 of two vehicles in the same VANET. For example, Host1 in Vehicle1
can communicate with Host6 in Vehicle3 via Router 5 in Vehicle2 that can communicate with Host6 in Vehicle3 via Router 5 in Vehicle2 that
is an intermediate vehicle being connected to Vehicle1 and Vehicle3 is an intermediate vehicle being connected to Vehicle1 and Vehicle3
in a linear topology as shown in the figure. in a linear topology as shown in the figure.
5. Problem Statement 5. Problem Statement
This section makes a problem statement about key topics for IPWAVE This section presents key topics such as neighbor discovery, mobility
WG, such as neighbor discovery, mobility management, and security & management, and security & privacy.
privacy.
5.1. Neighbor Discovery 5.1. Neighbor Discovery
IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] is a core part IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] is a core part
of the IPv6 protocol suite. IPv6 ND is designed for point-to-point of the IPv6 protocol suite. IPv6 ND is designed for point-to-point
links and transit links (e.g., Ethernet). It assumes an efficient links and transit links (e.g., Ethernet). It assumes an efficient
and reliable support of multicast from the link layer for various and reliable support of multicast from the link layer for various
network operations such as MAC Address Resolution (AR) and Duplicate network operations such as MAC Address Resolution (AR) and Duplicate
Address Detection (DAD). Address Detection (DAD).
IPv6 ND needs to be extended to vehicular networking (e.g., V2V, V2I, DAD and ND-related parameters (e.g., Router Lifetime) need to be
and V2X) in terms of DAD and ND-related parameters (e.g., Router extended to vehicular networking (e.g., V2V, V2I, and V2X). Vehicles
Lifetime). The vehicles are moving fast within the communication move quickly within the communication coverage of any particular
coverage of a vehicular node (e.g., vehicle and RSU). Before the vehicle or RSU. Before the vehicles can exchange application
vehicles can exchange application messages with each other, they need messages with each other, they need to be configured with a link-
to be configured with a link-local IPv6 address or a global IPv6 local IPv6 address or a global IPv6 address, and run IPv6 ND.
address, and recognize each other in the aspect of IPv6 ND.
The legacy DAD assumes that a node with an IPv6 address can reach any The legacy DAD assumes that a node with an IPv6 address can reach any
other node with the scope of its address at the time it claims its other node with the scope of its address at the time it claims its
address, and can hear any future claim for that address by another address, and can hear any future claim for that address by another
party within the scope of its address for the duration of the address party within the scope of its address for the duration of the address
ownership. However, the partioning and merging of VANETs makes this ownership. However, the partioning and merging of VANETs makes this
assumption frequently invalid in vehicular networks. assumption frequently invalid in vehicular networks.
The vehicular networks need to support a vehicular-network-wide DAD The vehicular networks need to support a vehicular-network-wide DAD
by defining a scope that is compatible with the legacy DAD, and two by defining a scope that is compatible with the legacy DAD, and two
vehicles can communicate with each other when there exists a vehicles can communicate with each other when there exists a
communication path over VANET or a combination of VANETs and RSUs, as communication path over VANET or a combination of VANETs and RSUs, as
shown in Figure 1. By using the vehicular-network-wide DAD, vehicles shown in Figure 1. By using the vehicular-network-wide DAD, vehicles
can assure that their IPv6 addresses are unique in the vehicular can assure that their IPv6 addresses are unique in the vehicular
network whenever they are connected to the vehicular infrastructure network whenever they are connected to the vehicular infrastructure
or become disconnected from it in the form of VANET. Even though a or become disconnected from it in the form of VANET. A vehicular
unique IPv6 address can be derived from a globally unique MAC infrastructure having RSUs and an MA can participate in the
address, this derivation yields a privacy issue of a vehicle as an vehicular-network-wide DAD for the sake of vehicles [RFC6775]. For
IPv6 node. The vehicular infrastructure having RSUs and an MA can the vehicle as an IPv6 node, deriving a unique IPv6 address from a
participate in the vehicular-network-wide DAD for the sake of globally unique MAC address creates a privacy issue. Refer to
vehicles [RFC6775][RFC8505]. Section 5.3 for the discussion about such a privacy issue.
ND time-related parameters such as router lifetime and Neighbor ND time-related parameters such as router lifetime and Neighbor
Advertisement (NA) interval should be adjusted for high-speed Advertisement (NA) interval should be adjusted for high-speed
vehicles and vehicle density. As vehicles move faster, the NA vehicles and vehicle density. As vehicles move faster, the NA
interval should decrease (e.g., from 1 sec to 0.5 sec) for the NA interval should decrease (e.g., from 1 sec to 0.5 sec) for the NA
messages to reach the neighboring vehicles promptly. Also, as messages to reach the neighboring vehicles promptly. Also, as
vehicle density is higher, the NA interval should increase (e.g., vehicle density is higher, the NA interval should increase (e.g.,
from 0.5 sec to 1 sec) for the NA messages to reduce collision from 0.5 sec to 1 sec) for the NA messages to reduce collision
probability with other NA messages. probability with other NA messages.
According to a report from the National Highway Traffic Safety According to a report from the National Highway Traffic Safety
Administration (NHTSA) [NHTSA-ACAS-Report], an extra 0.5 second of Administration (NHTSA) [NHTSA-ACAS-Report], an extra 0.5 second of
warning time can prevent about 60% of the collisions of vehicles warning time can prevent about 60% of the collisions of vehicles
moving closely in a roadway. A warning message should be exchanged moving closely in a roadway. A warning message should be exchanged
every 0.5 seconds. Thus, if the ND messages (e.g., NS and NA) are every 0.5 second. Thus, if the ND messages (e.g., NS and NA) are
used as warning messages, they should be exchanged every 0.5 second. used as warning messages, they should be exchanged every 0.5 second.
For IP-based safety applications (e.g., context-aware navigation, For IP-based safety applications (e.g., context-aware navigation,
adaptive cruise control, and platooning) in vehicular network, this adaptive cruise control, and platooning) in vehicular network, this
bounded data delivery is critical. The real implementations for such bounded data delivery is critical. Implementations for such
applications are not available yet. Thus, ND needs to appropriately applications are not available yet. ND needs work to support IP-
operate to support IP-based safety applications. based safety applications.
5.1.1. Link Model 5.1.1. Link Model
IPv6 protocols work under certain assumptions for the link model that IPv6 protocols work under certain assumptions for the link model that
do not necessarily hold in a vehicular wireless link [VIP-WAVE] do not necessarily hold in a vehicular wireless link [VIP-WAVE]
[RFC5889]. For instance, some IPv6 protocols assume symmetry in the [RFC5889]. For instance, some IPv6 protocols assume symmetry in the
connectivity among neighboring interfaces. However, interference and connectivity among neighboring interfaces [RFC6250]. However,
different levels of transmission power may cause unidirectional links interference and different levels of transmission power may cause
to appear in vehicular wireless links. As a result, a new vehicular asymmetric links to appear in vehicular wireless links. As a result,
link model is required for a dynamically changing vehicular wireless a new vehicular link model is required for a dynamically changing
link. vehicular wireless link.
There is a relationship between a link and prefix, besides the There is a relationship between a link and prefix, besides the
different scopes that are expected from the link-local and global different scopes that are expected from the link-local and global
types of IPv6 addresses. In an IPv6 link, it is assumed that all types of IPv6 addresses. In an IPv6 link, it is assumed that all
interfaces which are configured with the same subnet prefix and with interfaces which are configured with the same subnet prefix and with
on-link bit set can communicate with each other on an IP link. on-link bit set can communicate with each other on an IP link.
A VANET can have multiple links between pairs of vehicles within A VANET can have multiple links between pairs of vehicles within
wireless communication range, as shown in Figure 4. When two wireless communication range, as shown in Figure 4. When two
vehicles belong to the same VANET, but they are out of wireless vehicles belong to the same VANET, but they are out of wireless
communication range, they cannot communicate directly with each communication range, they cannot communicate directly with each
other. Assume that a global-scope IPv6 prefix is assigned to VANETs other. Suppose that a global-scope IPv6 prefix is assigned to VANETs
in vehicular networks. Even though two vehicles in the same VANET in vehicular networks. Even though two vehicles in the same VANET
configure their IPv6 addresses with the same IPv6 prefix, they may configure their IPv6 addresses with the same IPv6 prefix, they may
not communicate with each other not in a one hop in the same VANET not communicate with each other not in a one hop in the same VANET
because of the multihop network connectivity. Thus, in this case, because of the multihop network connectivity. Thus, in this case,
the concept of a on-link IPv6 prefix does not hold because two the concept of an on-link IPv6 prefix does not hold because two
vehicles with the same on-link IPv6 prefix cannot communicate vehicles with the same on-link IPv6 prefix cannot communicate
directly with each other. Also, when two vehicles are located in two directly with each other. Also, when two vehicles are located in two
different VANETs with the same IPv6 prefix, they cannot communicate different VANETs with the same IPv6 prefix, they cannot communicate
with each other. When these two VANETs are converged into one VANET, with each other. When these two VANETs are converged into one VANET,
the two vehicles can communicate with each other in a multihop the two vehicles can communicate with each other in a multihop
fashion. Therefore, a vehicular link model should consider the fashion. Therefore, a vehicular link model should consider the
frequent partitioning and merging of VANETs due to vehicle mobility. frequent partitioning and merging of VANETs due to vehicle mobility.
The vehicular link model needs to support the multihop routing in a The vehicular link model needs to support the multihop routing in a
connected VANET where the vehicles with the same global-scope IPv6 connected VANET where the vehicles with the same global-scope IPv6
prefix are connected in one hop or multiple hops. It also needs to prefix are connected in one hop or multiple hops. It also needs to
support the multhop routing in multiple connected VANETs via an RSU support the multihop routing in multiple connected VANETs via an RSU
that has the wireless connectivity with each VANET. For example, that has the wireless connectivity with each VANET. For example, in
assume that Vehicle1, Vehicle 2, and Vehicle3 are configured with Figure 1, suppose that Vehicle1, Vehicle2, and Vehicle3 are
their IPv6 addresses based on the same global-scope IPv6 prefix. configured with their IPv6 addresses based on the same global-scope
Vehicle1 and Vehicle3 can also communicate with each other via either IPv6 prefix. Vehicle1 and Vehicle3 can also communicate with each
multi-hop V2V or multi-hop V2I2V. When two vehicles (e.g., Vehicle1 other via either multi-hop V2V or multi-hop V2I2V. When two vehicles
and Vehicle3 in Figure 1) are connected in a VANET, it will be more of Vehicle1 and Vehicle3 are connected in a VANET, it will be more
efficient for them to communicate with each other via VANET rather efficient for them to communicate with each other via VANET rather
than RSUs. On the other hand, when two vehicles (e.g., Vehicle1 and than RSUs. On the other hand, when the two vehicles of Vehicle1 and
Vehicle3) are far away from the communication range in separate Vehicle3 are far away from the communication range in separate VANETs
VANETs and under two different RSUs, they can communicate with each and under two different RSUs, they can communicate with each other
other through the relay of RSUs via V2I2V. Thus, two separate VANETs through the relay of RSUs via V2I2V. Thus, two separate VANETs can
can merge into one network via RSU(s). Also, newly arriving vehicles merge into one network via RSU(s). Also, newly arriving vehicles can
can merge two separate VANETs into one VANET if they can play a role merge two separate VANETs into one VANET if they can play a role of a
of a relay node for those VANETs. relay node for those VANETs.
5.1.2. MAC Address Pseudonym 5.1.2. MAC Address Pseudonym
For the protection of drivers' privacy, the pseudonym of a MAC For the protection of drivers' privacy, a pseudonym of a MAC address
address of a vehicle's network interface should be used, with the of a vehicle's network interface should be used, so that the MAC
help of which the MAC address can be changed periodically. The address can be changed periodically. The pseudonym of a MAC address
pseudonym of a MAC address affects an IPv6 address based on the MAC affects an IPv6 address based on the MAC address, and a transport-
address, and a transport-layer (e.g., TCP) session with an IPv6 layer (e.g., TCP) session with an IPv6 address pair. However, the
address pair. However, the pseudonym handling is not implemented and pseudonym handling is not implemented and tested yet for applications
tested yet for applications on IP-based vehicular networking. on IP-based vehicular 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
should be updated, and the uniqueness of the address should be should be updated, and the uniqueness of the address should be
performed through the DAD procedure. For vehicular networks with performed through the DAD procedure. For vehicular networks with
high-mobility, this DAD should be performed efficiently with minimum high mobility and density, this DAD should be performed efficiently
overhead. with minimum overhead so that the vehicles can exchange warning
messages with each other every 0.5 second [NHTSA-ACAS-Report].
For the continuity of an end-to-end (E2E) transport-layer (e.g., TCP, For the continuity of an end-to-end (E2E) transport-layer (e.g., TCP,
UDP, and SCTP) session, with a mobility management scheme (e.g., UDP, and SCTP) session, with a mobility management scheme (e.g.,
MIPv6 and PMIPv6), the new IP address for the transport-layer session MIPv6 and PMIPv6), the new IP address for the transport-layer session
can be notified to an appropriate end point, and the packets of the can be notified to an appropriate end point, and the packets of the
session should be forwarded to their destinations with the changed session should be forwarded to their destinations with the changed
network interface identifier and IPv6 address. This mobiliy network interface identifier and IPv6 address. This mobiliy
management overhead for pseudonyms should be minimized for efficient management overhead for pseudonyms should be minimized for efficient
operations in vehicular networks having lots of vehicles. operations in vehicular networks having lots of vehicles.
5.1.3. Prefix Dissemination/Exchange 5.1.3. Prefix Dissemination/Exchange
A vehicle and an RSU can have their internal network, as shown in A vehicle and an RSU can have their internal network, as shown in
Figure 2 and Figure 3. In this case, nodes in within the internal Figure 2 and Figure 3. In this case, nodes within the internal
networks of two vehicular nodes (e.g., vehicle and RSU) want to networks of two vehicles (or within the internal networks of a
communicate with each other. For this communication on the wireless vehicle and an RSU) want to communicate with each other. For this
link, the network prefix dissemination or exchange is required. It communication on the wireless link, the network prefix dissemination
is assumed that a vehicular node has an external network interface or exchange is required. Either a vehicle or an RSU needs an
and its internal network, as shown in Figure 2 and Figure 3. The external network interface for its internal network, as shown in
vehicular ND (VND) [ID-Vehicular-ND] can support the communication Figure 2 and Figure 3. The vehicular ND (VND) [ID-Vehicular-ND] can
between the internal-network nodes (e.g., an in-vehicle device in a support the communication between the internal-network nodes (e.g.,
vehicle and a server in an RSU) of vehicular nodes with a vehicular an in-vehicle device in a vehicle and a server in an RSU) with a
prefix information option. Thus, this ND extension for routing vehicular prefix information option. Thus, this ND extension for
functionality can reduce control traffic for routing in vehicular routing functionality can reduce control traffic for routing in
networks without a vehicular ad hoc routing protocol (e.g., AODV vehicular networks without a vehicular ad hoc routing protocol (e.g.,
[RFC3561] and OLSRv2 [RFC7181]). AODV [RFC3561] or OLSRv2 [RFC7181]).
5.1.4. Routing 5.1.4. Routing
For multihop V2V communications in a VANET (or a multi-link subnet), For multihop V2V communications in either a VANET or VANETs via RSUs,
a vehicular ad hoc routing protocol (e.g., AODV and OLSRv2) may be a vehicular ad hoc routing protocol (e.g., AODV and OLSRv2) may be
required to support both unicast and multicast in the links of the 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]. As a feasible control traffic overhead [ID-Multicast-Problems].
approach, Vehicular ND can be extended to accommodate routing
functionality with a prefix discovery option. In this case, there is
no need to run a separate vehicular ad hoc routing protocol in
VANETs. The ND extension can allow vehicles to exchange their
prefixes in a multihop fashion [ID-Vehicular-ND]. With the exchanged
prefixes, they can compute their routing table (or IPv6 ND's neighbor
cache) for the multi-link subnet with a distance-vector algorithm
[Intro-to-Algorithms].
Also, an efficient, rapid DAD needs to be supported in a vehicular Vehicular ND can be extended to accommodate routing functionality
network having multiple VANETs (or a multi-link subnet) to prevent or with a prefix discovery option. The ND extension can allow vehicles
reduce IPv6 address conflicts in such a subnet. A feasible approach to exchange their prefixes in a multihop fashion [ID-Vehicular-ND].
is to use a multi-hop DAD optimization for the efficient vehicular- With the exchanged prefixes, they can compute their routing table (or
network-wide DAD [RFC6775][RFC8505]. IPv6 ND's neighbor cache) for the VANETs with a distance-vector
algorithm [Intro-to-Algorithms].
5.2. Mobility Management 5.2. Mobility Management
The seamless connectivity and timely data exchange between two end The seamless connectivity and timely data exchange between two end
points requires an efficient mobility management including location points requires an efficient mobility management including location
management and handover. Most of vehicles are equipped with a GPS management and handover. Most of vehicles are equipped with a GPS
receiver as part of a dedicated navigation system or a corresponding receiver as part of a dedicated navigation system or a corresponding
smartphone App. The GPS receiver may not provide vehicles with smartphone App. The GPS receiver may not provide vehicles with
accurate location information in adverse, local environments such as accurate location information in adverse, local environments such as
building area and tunnel. The location precision can be improved by building area and tunnel. The location precision can be improved by
skipping to change at page 18, line 5 skipping to change at page 17, line 46
infrastructure (having RSUs and an MA in TCC) [ID-Vehicular-MM]. infrastructure (having RSUs and an MA in TCC) [ID-Vehicular-MM].
This vehicular infrastructure can predict the future positions of the This vehicular infrastructure can predict the future positions of the
vehicles with their mobility information (i.e., the current position, vehicles with their mobility information (i.e., the current position,
speed, direction, and trajectory) for the efficient mobility speed, direction, and trajectory) for the efficient mobility
management (e.g., proactive handover). For a better proactive management (e.g., proactive handover). For a better proactive
handover, link-layer parameters, such as the signal strength of a handover, link-layer parameters, such as the signal strength of a
link-layer frame (e.g., Received Channel Power Indicator (RCPI) link-layer frame (e.g., Received Channel Power Indicator (RCPI)
[VIP-WAVE]), can be used to determine the moment of a handover [VIP-WAVE]), can be used to determine the moment of a handover
between RSUs along with mobility information. between RSUs along with mobility information.
With the prediction of the vehicle mobility, the vehicular By predicting a vehicle's mobility, the vehicular infrastructure can
infrastructure needs to support RSUs to perform efficient DAD, data better support RSUs to perform efficient DAD, data packet routing,
packet routing, horizontal handover (i.e., handover in wireless links horizontal handover (i.e., handover in wireless links using a
using a homogeneous radio technology), and vertical handover (i.e., homogeneous radio technology), and vertical handover (i.e., handover
handover in wireless links using heterogeneous radio technologies) in in wireless links using heterogeneous radio technologies) in advance
a proactive manner [ID-Vehicular-MM]. For example, when a vehicle is along with the movement of the vehicle [ID-Vehicular-MM]. For
moving into the wireless link under another RSU belonging to a example, when a vehicle is moving into the wireless link under
different subnet, the RSU can proactively perform the DAD for the another RSU belonging to a different subnet, the RSU can proactively
sake of the vehicle, reducing IPv6 control traffic overhead in the perform the DAD for the sake of the vehicle, reducing IPv6 control
wireless link. To prevent a hacker from impersonating RSUs as bogus traffic overhead in the wireless link. To prevent a hacker from
RSUs, RSUs and MA in the vehicular infrastructure need to have secure impersonating RSUs as bogus RSUs, RSUs and MA in the vehicular
channels via IPsec. infrastructure need to have secure channels via IPsec.
Therefore, with a proactive handover and a multihop DAD in vehicular Therefore, with a proactive handover and a multihop DAD in vehicular
networks, RSUs needs to efficiently forward data packets from the networks, RSUs needs to efficiently forward data packets from the
wired network (or the wireless network) to a moving destination wired network (or the wireless network) to a moving destination
vehicle along its trajectory. As a result, a moving vehicle can vehicle along its trajectory.
communicate with its corresponding vehicle in the vehicular network
or a host/server in the Internet along its trajectory.
5.3. Security and Privacy 5.3. Security and Privacy
Strong security measures shall protect vehicles roaming in road Strong security measures shall protect vehicles roaming in road
networks from the attacks of malicious nodes, which are controlled by networks from the attacks of malicious nodes, which are controlled by
hackers. For safety applications, the cooperation among vehicles is hackers. For safety applications, the cooperation among vehicles is
assumed. Malicious nodes may disseminate wrong driving information assumed. Malicious nodes may disseminate wrong driving information
(e.g., location, speed, and direction) to make driving be unsafe. (e.g., location, speed, and direction) to make driving be unsafe.
Sybil attack, which tries to illude a vehicle with multiple false Sybil attack, which tries to confuse a vehicle with multiple false
identities, disturbs a vehicle in taking a safe maneuver. This sybil identities, disturbs a vehicle in taking a safe maneuver. This sybil
attack should be prevented through the cooperation between good attack should be prevented through the cooperation between good
vehicles and RSUs. Note that good vehicles are ones with valid vehicles and RSUs. Note that good vehicles are ones with valid
certificates that are determined by the authentication process with certificates that are determined by the authentication process with
an authentication server in the vehicular network. Applications on an authentication server in the vehicular network. Applications on
IP-based vehicular networking, which are resilient to such a sybil IP-based vehicular networking, which are resilient to such a sybil
attack, are not developed and tested yet. attack, are not developed and tested yet.
Security and privacy are paramount in the V2I, V2V, and V2X Security and privacy are paramount in the V2I, V2V, and V2X
networking in vehicular networks. Only authorized vehicles should be networking in vehicular networks. Only authorized vehicles should be
skipping to change at page 19, line 19 skipping to change at page 19, line 10
established, as shown in Figure 2. Also, for secure V2V established, as shown in Figure 2. Also, for secure V2V
communication, a secure channel between a mobile router in a vehicle communication, a secure channel between a mobile router in a vehicle
and a mobile router in another vehicle should be established, as and a mobile router in another vehicle should be established, as
shown in Figure 3. shown in Figure 3.
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, MAC address pseudonym should be provided to the or IPv6 address, MAC address pseudonym should be provided to the
vehicle; that is, each vehicle should periodically update its MAC vehicle; that is, each vehicle should periodically update its MAC
address and the corresponding IPv6 address as suggested in address and the corresponding IPv6 address as suggested in
[RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses
should not interrupt the E2E communications between two vehicular should not interrupt the E2E communications between two vehicles (or
nodes (e.g., vehicle and RSU) in terms of transport layer for a long- between a vehicle and an RSU) in terms of transport layer for a long-
living higher-layer session. However, if this pseudonym is performed living higher-layer session. However, if this pseudonym is performed
without strong E2E confidentiality, there will be no privacy benefit without strong E2E confidentiality, there will be no privacy benefit
from changing MAC and IP addresses, because an adversary can see the from changing MAC and IP addresses, because an adversary can see the
change of the MAC and IP addresses and track the vehicle with those change of the MAC and IP addresses and track the vehicle with those
addresses. addresses.
For the IPv6 ND, the vehicular-network-wide DAD is required for the For the IPv6 ND, the vehicular-network-wide DAD is required for the
uniqueness of the IPv6 address of a vehicle's wireless interface. uniqueness of the IPv6 address of a vehicle's wireless interface.
This DAD can be used as a flooding attack that makes the DAD-related This DAD can be used as a flooding attack that makes the DAD-related
ND packets are disseminated over the VANET and vehicular network ND packets are disseminated over the VANET and vehicular network
including the RSU and the MA. The vehicles and RSUs need to filter including the RSUs and the MA. The vehicles and RSUs need to filter
out suspicious ND traffic in advance. out suspicious ND traffic in advance.
For the mobility management, a malicious vehicle constructs multiple For the mobility management, a malicious vehicle can construct
virtual bogus vehicles, and register them with the RSU and the MA. multiple virtual bogus vehicles, and register them with the RSU and
This registration makes the RSU and MA waste their resources. The the MA. This registration makes the RSU and MA waste their
RSU and MA need to determine whether a vehicle is genuine or bogus in resources. The RSU and MA need to determine whether a vehicle is
the mobility management. genuine or bogus in the mobility management.
6. Security Considerations 6. Security Considerations
This document discussed security and privacy for IP-based vehicular This document discussed security and privacy for IP-based vehicular
networking. networking.
The security and privacy for key components in IP-based vehicular The security and privacy for key components in IP-based vehicular
networking, such as neighbor discovery and mobility management, need networking, such as neighbor discovery and mobility management, need
to be analyzed in depth. to be analyzed in depth.
skipping to change at page 23, line 25 skipping to change at page 23, line 14
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010. Mobile IPv6", RFC 5844, May 2010.
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
Hoc Networks", RFC 5889, September 2010. Hoc Networks", RFC 5889, September 2010.
[RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised", [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised",
RFC 5944, November 2010. RFC 5944, November 2010.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May
2011.
[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.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[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, April 2014.
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management",
RFC 7333, August 2014.
[RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429, January 2015.
[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.
[RFC8505] Thubert, P., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, November 2018.
[SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT:
Self-Adaptive Interactive Navigation Tool for Cloud-Based Self-Adaptive Interactive Navigation Tool for Cloud-Based
Vehicular Traffic Optimization", IEEE Transactions on Vehicular Traffic Optimization", IEEE Transactions on
Vehicular Technology, Vol. 65, No. 6, June 2016. Vehicular Technology, Vol. 65, No. 6, June 2016.
[SAINTplus] [SAINTplus]
Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D.
Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+
for Emergency Service Delivery Optimization", for Emergency Service Delivery Optimization",
IEEE Transactions on Intelligent Transportation Systems, IEEE Transactions on Intelligent Transportation Systems,
June 2017. June 2017.
[SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation
Application for Pedestrian Protection in Vehicular Application for Pedestrian Protection in Vehicular
Networks", Springer Lecture Notes in Computer Science Networks", Springer Lecture Notes in Computer Science
(LNCS), Vol. 9502, December 2015. (LNCS), Vol. 9502, December 2015.
[SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based
Distributed Mobility Management for 5G Networks",
IEEE Wireless Communications and Networking Conference,
April 2016.
[Truck-Platooning] [Truck-Platooning]
California Partners for Advanced Transportation Technology California Partners for Advanced Transportation Technology
(PATH), "Automated Truck Platooning", [Online] Available: (PATH), "Automated Truck Platooning", [Online] Available:
http://www.path.berkeley.edu/research/automated-and- http://www.path.berkeley.edu/research/automated-and-
connected-vehicles/truck-platooning, 2017. connected-vehicles/truck-platooning, 2017.
[TS-23.285-3GPP] [TS-23.285-3GPP]
3GPP, "Architecture Enhancements for V2X Services", 3GPP 3GPP, "Architecture Enhancements for V2X Services", 3GPP
TS 23.285, June 2018. TS 23.285, June 2018.
skipping to change at page 26, line 5 skipping to change at page 25, line 5
[WAVE-1609.3] [WAVE-1609.3]
IEEE 1609 Working Group, "IEEE Standard for Wireless IEEE 1609 Working Group, "IEEE Standard for Wireless
Access in Vehicular Environments (WAVE) - Networking Access in Vehicular Environments (WAVE) - Networking
Services", IEEE Std 1609.3-2016, April 2016. Services", IEEE Std 1609.3-2016, April 2016.
[WAVE-1609.4] [WAVE-1609.4]
IEEE 1609 Working Group, "IEEE Standard for Wireless IEEE 1609 Working Group, "IEEE Standard for Wireless
Access in Vehicular Environments (WAVE) - Multi-Channel Access in Vehicular Environments (WAVE) - Multi-Channel
Operation", IEEE Std 1609.4-2016, March 2016. Operation", IEEE Std 1609.4-2016, March 2016.
Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-09 Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-10
The following changes are made from draft-ietf-ipwave-vehicular- The following changes are made from draft-ietf-ipwave-vehicular-
networking-09: networking-10:
o This version is revised based on the comments from Charlie
Perkins.
o For the question on the preference on a multi-link subnet model,
the revision does not suggest the multi-link subnet model as a
possible solution, focusing on the characteristics and
requirements for a vehicular link model.
o The motivation about DNS in a vehicle network is addressed
clearly.
o The timing importance of ND is addressed with a reference to
[NHTSA-ACAS-Report].
o The Security Considerations are expanded with cross references to
other parts of the document such as IPv6 ND and mobility
management.
o 2001:DB8::/32 is a reserved prefix for use in documentation o This version is revised based on the comments from Charlie Perkins
[RFC3849]. Any routable IPv6 address needs to be routable in a and Sri Gundavelli.
VANET and a vehicular network including RSUs.
o With an example in Figure 1, it is suggested that two separate o Many editorial comments and questions from Charlie Perkins are
VANETs can merge into one network. addressed in this document.
o A suggestion is made about how to distinguish good nodes from bad o According to Sri Gundavelli's comments, the solution text and RFC
nodes with an authentication process. 8505 reference for the vehicular ND are deleted from Section 5.1
in this document.
Appendix B. Acknowledgments Appendix B. Acknowledgments
This work was supported by Basic Science Research Program through the This work was supported by Basic Science Research Program through the
National Research Foundation of Korea (NRF) funded by the Ministry of National Research Foundation of Korea (NRF) funded by the Ministry of
Education (2017R1D1A1B03035885). Education (2017R1D1A1B03035885).
This work was supported in part by the MSIT (Ministry of Science and This work was supported in part by the MSIT (Ministry of Science and
ICT), Korea, under the ITRC (Information Technology Research Center) ICT), Korea, under the ITRC (Information Technology Research Center)
support program (IITP-2019-2017-0-01633) supervised by the IITP support program (IITP-2019-2017-0-01633) supervised by the IITP
skipping to change at page 29, line 4 skipping to change at page 27, line 32
Department of Computer Science & Engineering Department of Computer Science & 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 4106 Phone: +82 31 299 4106
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: chrisshen@skku.edu EMail: chrisshen@skku.edu
URI: http://iotlab.skku.edu/people-chris-shen.php URI: http://iotlab.skku.edu/people-chris-shen.php
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 Software 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. 78 change blocks. 
317 lines changed or deleted 270 lines changed or added

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