draft-ietf-ipwave-vehicular-networking-16.txt   draft-ietf-ipwave-vehicular-networking-17.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 7, 2020 Intended status: Informational July 28, 2020
Expires: January 8, 2021 Expires: January 29, 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-16 draft-ietf-ipwave-vehicular-networking-17
Abstract Abstract
This document discusses the problem statement and use cases of This document discusses the problem statement and use cases of
IPv6-based vehicular networking for Intelligent Transportation IPv6-based vehicular networking for Intelligent Transportation
Systems (ITS). The main scenarios of vehicular communications are Systems (ITS). The main scenarios of vehicular communications are
vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
vehicle-to-everything (V2X) communications. First, this document vehicle-to-everything (V2X) communications. First, this document
explains use cases using V2V, V2I, and V2X networking. Next, for explains use cases using V2V, V2I, and V2X networking. Next, for
IPv6-based vehicular networks, it makes a gap analysis of current IPv6-based vehicular networks, it makes a gap analysis of current
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2021. This Internet-Draft will expire on January 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . 11 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12
4.1. Vehicular Network Architecture . . . . . . . . . . . . . 12 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 13
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 16 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 17
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 20 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 21 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 22
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 22 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 23
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 24 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 25
5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 25 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Informative References . . . . . . . . . . . . . . . . . . . 29 7. Informative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. Changes from draft-ietf-ipwave-vehicular- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 38
networking-15 . . . . . . . . . . . . . . . . . . . 36 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
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 7, line 33 skipping to change at page 7, line 33
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;
o Cooperative environment sensing; o Cooperative environment sensing;
o Collision avoidance service of end systems of Urban Air Mobility o Collision avoidance service of end systems of Urban Air Mobility
(UAM). (UAM) [UAM-ITS].
These five techniques will be important elements for autonomous These five techniques will be important elements for autonomous
vehicles, which may be either terrestrial vehicles or UAM end vehicles, which may be either terrestrial vehicles or UAM end
systems. systems.
Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
to drive safely by alerting them to dangerous obstacles and to drive safely by alerting them to dangerous obstacles and
situations. That is, a CASD navigator displays obstacles or situations. That is, a CASD navigator displays obstacles or
neighboring vehicles relevant to possible collisions in real-time neighboring vehicles relevant to possible collisions in real-time
through V2V networking. CASD provides vehicles with a class-based through V2V networking. CASD provides vehicles with a class-based
skipping to change at page 9, line 15 skipping to change at page 9, line 15
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 does not support wireless single-hop V2V The existing IPv6 protocol must be augmented through the addition of
communications as well as wireless multihop V2V communications. an Overlay Multilink Network (OMNI) Interface [OMNI] and/or protocol
Thus, the IPv6 needs to support both single-hop and multihop changes in order to support wireless single-hop V2V communications as
communications in a wireless medium so that vehicles can communicate well as wireless multihop V2V communications. Thus, the IPv6 needs
with each other by V2V communications to share either an emergency to support both single-hop and multihop communications in a wireless
situation or road hazard in a highway. medium so that vehicles can communicate with each other by V2V
communications to share either an emergency situation or road hazard
in a highway.
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 45 skipping to change at page 10, line 47
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.
The existing IPv6 protocol does not support wireless multihop V2I The existing IPv6 protocol must be augmented through the addition of
communications in a highway where RSUs are sparsely deployed, so a an OMNI interface and/or protocol changes in order to support
vehicle can reach the wireless coverage of an RSU through the wireless multihop V2I communications in a highway where RSUs are
multihop data forwarding of intermediate vehicles. Thus, IPv6 needs sparsely deployed, so a vehicle can reach the wireless coverage of an
to be extended for multihop V2I communications. RSU through the multihop data forwarding of intermediate vehicles.
Thus, IPv6 needs to be extended for multihop V2I communications.
To support applications of these V2I use cases, the functions of IPv6 To support applications of these V2I use cases, the functions of IPv6
such as VND, VMM, and VSP are prerequisites for IPv6-based packet such as VND, VMM, and VSP are prerequisites for IPv6-based packet
exchange, transport-layer session continuity, and secure, safe exchange, transport-layer session continuity, and secure, safe
communication between a vehicle and a server in the vehicular cloud. communication between a vehicle and a server in the vehicular cloud.
3.3. V2X 3.3. V2X
The use case of V2X networking discussed in this section is for a The use case of V2X networking discussed in this section is for a
pedestrian protection service. pedestrian protection service.
skipping to change at page 11, line 32 skipping to change at page 11, line 34
pedestrians, compute wireless communication scheduling for the sake pedestrians, compute wireless communication scheduling for the sake
of them. This scheduling can save the battery of each pedestrian's of them. This scheduling can save the battery of each pedestrian's
smartphone by allowing it to work in sleeping mode before the smartphone by allowing it to work in sleeping mode before the
communication with vehicles, considering their mobility. communication with vehicles, considering their mobility.
For Vehicle-to-Pedestrian (V2P), a vehicle can directly communicate For Vehicle-to-Pedestrian (V2P), a vehicle can directly communicate
with a pedestrian's smartphone by V2X without IP-RSU relaying. with a pedestrian's smartphone by V2X without IP-RSU relaying.
Light-weight mobile nodes such as bicycles may also communicate Light-weight mobile nodes such as bicycles may also communicate
directly with a vehicle for collision avoidance using V2V. directly with a vehicle for collision avoidance using V2V.
The existing IPv6 protocol does not support wireless multihop V2X (or The existing IPv6 protocol must be augmented through the addition of
V2I2X) communications in an urban road network where RSUs are an OMNI interface and/or protocol changes in order to support
deployed at intersections, so a vehicle (or a pedestrian's wireless multihop V2X (or V2I2X) communications in an urban road
smartphone) can reach the wireless coverage of an RSU through the network where RSUs are deployed at intersections, so a vehicle (or a
multihop data forwarding of intermediate vehicles (or pedestrians' pedestrian's smartphone) can reach the wireless coverage of an RSU
smartphones). Thus, IPv6 needs to be extended for multihop V2X (or through the multihop data forwarding of intermediate vehicles (or
V2I2X) communications. pedestrians' smartphones). Thus, IPv6 needs to be extended for
multihop V2X (or V2I2X) communications.
To support applications of these V2X use cases, the functions of IPv6 To support applications of these V2X use cases, the functions of IPv6
such as VND, VMM, and VSP are prerequisites for IPv6-based packet such as VND, VMM, and VSP are prerequisites for IPv6-based packet
exchange, transport-layer session continuity, and secure, safe exchange, transport-layer session continuity, and secure, safe
communication between a vehicle and a pedestrian either directly or communication between a vehicle and a pedestrian either directly or
indirectly via an IP-RSU. indirectly via an IP-RSU.
4. Vehicular Networks 4. Vehicular Networks
This section describes an example vehicular network architecture This section describes an example vehicular network architecture
skipping to change at page 12, line 49 skipping to change at page 13, line 8
Subnet1 Subnet2 Subnet3 Subnet1 Subnet2 Subnet3
(Prefix1) (Prefix2) (Prefix3) (Prefix1) (Prefix2) (Prefix3)
<----> Wired Link <....> Wireless Link ===> Moving Direction <----> Wired Link <....> Wireless Link ===> Moving Direction
Figure 1: An Example Vehicular Network Architecture for V2I and V2V Figure 1: An Example Vehicular Network Architecture for V2I and V2V
4.1. Vehicular Network Architecture 4.1. Vehicular Network Architecture
Figure 1 shows an example vehicular network architecture for V2I and Figure 1 shows an example vehicular network architecture for V2I and
V2V in a road network [OMNI-Interface]. The vehicular network V2V in a road network [OMNI]. The vehicular network architecture
architecture contains vehicles (including IP-OBU), IP-RSUs, Mobility contains vehicles (including IP-OBU), IP-RSUs, Mobility Anchor,
Anchor, Traffic Control Center, and Vehicular Cloud as components. Traffic Control Center, and Vehicular Cloud as components. Note that
the components of the vehicular network architecture can be mapped to
Note that the components of the vehicular network architecture can be those of an IP-based aeronautical network architecture in [OMNI], as
mapped to those of an IP-based aeronautical network architecture in shown in Figure 2.
[OMNI-Interface], as shown in Figure 2.
+-------------------+------------------------------------+ +-------------------+------------------------------------+
| Vehicular Network | Aeronautical Network | | Vehicular Network | Aeronautical Network |
+===================+====================================+ +===================+====================================+
| IP-RSU | Access Router (AR) | | IP-RSU | Access Router (AR) |
+-------------------+------------------------------------+ +-------------------+------------------------------------+
| Vehicle (IP-OBU) | Mobile Node (MN) | | Vehicle (IP-OBU) | Mobile Node (MN) |
+-------------------+------------------------------------+ +-------------------+------------------------------------+
| Moving Network | End User Network (EUN) | | Moving Network | End User Network (EUN) |
+-------------------+------------------------------------+ +-------------------+------------------------------------+
skipping to change at page 13, line 33 skipping to change at page 13, line 39
Figure 2: Mapping between Vehicular Network Components and Figure 2: Mapping between Vehicular Network Components and
Aeronautical Network Components Aeronautical Network Components
These components are not mandatory, and they can be deployed into These components are not mandatory, and they can be deployed into
vehicular networks in various ways. Some of them (e.g., Mobility vehicular networks in various ways. Some of them (e.g., Mobility
Anchor, Traffic Control Center, and Vehicular Cloud) may not be Anchor, Traffic Control Center, and Vehicular Cloud) may not be
needed for the vehicular networks according to target use cases in needed for the vehicular networks according to target use cases in
Section 3. Section 3.
An existing network architecture (e.g., an IP-based aeronautical An existing network architecture (e.g., an IP-based aeronautical
network architecture [OMNI-Interface][UAM-ITS], a network network architecture [OMNI][UAM-ITS], a network architecture of
architecture of PMIPv6 [RFC5213], and a low-power and lossy network PMIPv6 [RFC5213], and a low-power and lossy network architecture
architecture [RFC6550]) can be extended to a vehicular network [RFC6550]) can be extended to a vehicular network architecture for
architecture for multihop V2V, V2I, and V2X, as shown in Figure 1. multihop V2V, V2I, and V2X, as shown in Figure 1. In a highway
In a highway scenario, a vehicle may not access an RSU directly scenario, a vehicle may not access an RSU directly because of the
because of the distance of the DSRC coverage (up to 1 km). For distance of the DSRC coverage (up to 1 km). For example, the OMNI
example, RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) interface and/or RPL (IPv6 Routing Protocol for Low-Power and Lossy
[RFC6550] can be extended to support a multihop V2I since a vehicle Networks) [RFC6550] can be extended to support a multihop V2I since a
can take advantage of other vehicles as relay nodes to reach the RSU. vehicle can take advantage of other vehicles as relay nodes to reach
Also, RPL can be extended to support both multihop V2V and V2X in the the RSU. Also, RPL can be extended to support both multihop V2V and
similar way. V2X in the similar way.
Wireless communications needs to be considered for end systems for Wireless communications needs to be considered for end systems for
Urban Air Mobility (UAM) such as flying cars and taxis [UAM-ITS]. Urban Air Mobility (UAM) such as flying cars and taxis [UAM-ITS].
These UAM end systems may have multiple wireless transmission media These UAM end systems may have multiple wireless transmission media
interfaces (e.g., cellular, communications satellite (SATCOM), short- interfaces (e.g., cellular, communications satellite (SATCOM), short-
range omni-directional interfaces), which are offered by different range omni-directional interfaces), which are offered by different
data link service providers. To support not only the mobility data link service providers. To support not only the mobility
management of the UAM end systems, but also the multihop and management of the UAM end systems, but also the multihop and
multilink communications of the UAM interfaces, the UAM end systems multilink communications of the UAM interfaces, the UAM end systems
can employ an Overlay Multilink Network (OMNI) interface can employ an Overlay Multilink Network (OMNI) interface [OMNI] as a
[OMNI-Interface] as a virtual Non-Broadcast Multiple Access (NBMA) virtual Non-Broadcast Multiple Access (NBMA) connection to a serving
connection to a serving ground domain infrastructure. This ground domain infrastructure. This infrastructure can be configured
infrastructure can be configured over the underlying data links. The over the underlying data links. The OMNI interface and its link
OMNI interface and its link model provide a means of multilink, model provide a means of multilink, multihop and mobility
multihop and mobility coordination to the legacy IPv6 ND messaging coordination to the legacy IPv6 ND messaging [RFC4861] according to
[RFC4861] according to the NBMA principle. Thus, the OMNI link model the NBMA principle. Thus, the OMNI link model can support efficient
can support efficient UAM internetworking services without additional UAM internetworking services without additional mobility messaging,
mobility messaging, and without any modification to the IPv6 ND and without any modification to the IPv6 ND messaging services or
messaging services or link model. link model.
As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU
have wireless media interfaces for VANET. Furthermore, the wireless have wireless media interfaces for VANET. Furthermore, the wireless
media interfaces are autoconfigured with a global IPv6 prefix (e.g., media interfaces are autoconfigured with a global IPv6 prefix (e.g.,
2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that
2001:DB8::/32 is a documentation prefix [RFC3849] for example 2001:DB8::/32 is a documentation prefix [RFC3849] for example
prefixes in this document, and also that any routable IPv6 address prefixes in this document, and also that any routable IPv6 address
needs to be routable in a VANET and a vehicular network including IP- needs to be routable in a VANET and a vehicular network including IP-
RSUs. RSUs.
skipping to change at page 14, line 42 skipping to change at page 14, line 49
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 such
that mobile nodes share a prefix of a Wi-Fi access point in a that mobile nodes share a prefix of a Wi-Fi access point in a
wireless LAN. This is a natural characteristic in infrastructure- wireless LAN. This is a natural characteristic in infrastructure-
based wireless networks. For example, in Figure 1, two vehicles based wireless networks. For example, in Figure 1, two vehicles
(i.e., Vehicle2, and Vehicle5) can use Prefix 1 to configure their (i.e., Vehicle2, and Vehicle5) can use Prefix 1 to configure their
IPv6 global addresses for V2I communication. IPv6 global addresses for V2I communication. Alternatively, mobile
nodes can employ an OMNI interface and use their own IPv6 Unique
Local Addresses (ULAs) [RFC4193] over the wireless network without
requiring the messaging of IPv6 Stateless Address Autoconfiguration
(SLAAC) [RFC4862], which uses an on-link prefix provided by the
(visited) wireless LAN; this technique is known as "Bring-Your-Own-
Addresses".
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,
two vehicles (i.e., Vehicle4 and Vehicle7) can construct another two vehicles (i.e., Vehicle4 and Vehicle7) can construct another
connected VANET. connected VANET. Alternatively, each vehicle could employ an OMNI
interface with their own ULAs such that no topologically-oriented
subnet prefixes need be announced by the RSU.
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 of each other. On the other hand, Vehicle3 can communicate range of each other. On the other hand, Vehicle3 can communicate
with Vehicle4 via the vehicular infrastructure (i.e., IP-RSU2 and IP- with Vehicle4 via the vehicular infrastructure (i.e., IP-RSU2 and IP-
RSU3) by employing V2I (i.e., V2I2V) communication because they are RSU3) by employing V2I (i.e., V2I2V) communication because they are
skipping to change at page 15, line 36 skipping to change at page 15, line 49
An IPv6 mobility solution is needed for the guarantee of An IPv6 mobility solution is needed for the guarantee of
communication continuity in vehicular networks so that a vehicle's communication continuity in vehicular networks so that a vehicle's
TCP session can be continued, or UDP packets can be delivered to a TCP session can be continued, or UDP packets can be delivered to a
vehicle as a destination without loss while it moves from an IP-RSU's vehicle as a destination without loss while it moves from an IP-RSU's
wireless coverage to another IP-RSU's wireless coverage. In wireless coverage to another IP-RSU's wireless coverage. In
Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session) Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session)
with a corresponding node in the vehicular cloud, Vehicle2 can move with a corresponding node in the vehicular cloud, Vehicle2 can move
from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In
this case, a handover for Vehicle2 needs to be performed by either a this case, a handover for Vehicle2 needs to be performed by either a
host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a
network-based mobility management scheme (e.g., PMIPv6 [RFC5213]). network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and
AERO [RFC6706BIS]).
In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a
role of a home agent. On the other hand, in the network-based role of a home agent. On the other hand, in the network-based
mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility
management controller such as a Local Mobility Anchor (LMA) in management controller such as a Local Mobility Anchor (LMA) in
PMIPv6, which also serves vehicles as a home agent, and an IP-RSU PMIPv6, which also serves vehicles as a home agent, and an IP-RSU
plays a role of an access router such as a Mobile Access Gateway plays a role of an access router such as a Mobile Access Gateway
(MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs (MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs
client functionality in IPv6 stack of a vehicle as a mobile node for client functionality in IPv6 stack of a vehicle as a mobile node for
mobility signaling message exchange between the vehicle and home mobility signaling message exchange between the vehicle and home
skipping to change at page 17, line 20 skipping to change at page 18, line 7
Electronic Control Units (ECUs) in the vehicle. The internal network Electronic Control Units (ECUs) in the vehicle. The internal network
can support Wi-Fi and Bluetooth to accommodate a driver's and can support Wi-Fi and Bluetooth to accommodate a driver's and
passenger's mobile devices (e.g., smartphone or tablet). The network passenger's mobile devices (e.g., smartphone or tablet). The network
topology and subnetting depend on each vendor's network configuration topology and subnetting depend on each vendor's network configuration
for a vehicle and an EN. It is reasonable to consider the for a vehicle and an EN. It is reasonable to consider the
interaction between the internal network and an external network interaction between the internal network and an external network
within another vehicle or an EN. within another vehicle or an EN.
+-----------------+ +-----------------+
(*)<........>(*) +----->| Vehicular Cloud | (*)<........>(*) +----->| Vehicular Cloud |
2001:DB8:1:1::/64 | | | +-----------------+ (2001:DB8:1:1::/64) | | | +-----------------+
+------------------------------+ +---------------------------------+ +------------------------------+ +---------------------------------+
| v | | v v | | v | | v v |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | | | | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| | | | | | | | | | | | | | | |
| v v | | v v | | v v | | v v |
| ---------------------------- | | ------------------------------- | | ---------------------------- | | ------------------------------- |
| 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 |
skipping to change at page 18, line 10 skipping to change at page 18, line 45
As shown in Figure 3, as internal networks, a vehicle's moving As shown in Figure 3, as internal networks, a vehicle's moving
network and an EN's fixed network are self-contained networks having network and an EN's fixed network are self-contained networks having
multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU)
for the communication with another vehicle or another EN. The for the communication with another vehicle or another EN. The
internetworking between two internal networks via V2I communication internetworking between two internal networks via V2I communication
requires the exchange of the network parameters and the network requires the exchange of the network parameters and the network
prefixes of the internal networks. For the efficiency, the network prefixes of the internal networks. For the efficiency, the network
prefixes of the internal networks (as a moving network) in a vehicle prefixes of the internal networks (as a moving network) in a vehicle
need to be delegated and configured automatically. Note that a need to be delegated and configured automatically. Note that a
moving network's network prefix can be called a Mobile Network Prefix moving network's network prefix can be called a Mobile Network Prefix
(MNP) [OMNI-Interface]. (MNP) [OMNI].
Figure 3 also shows the internetworking between the vehicle's moving Figure 3 also shows the internetworking between the vehicle's moving
network and the EN's fixed network. There exists an internal network network and the EN's fixed network. There exists an internal network
(Moving Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and (Moving Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and
Host2), and two routers (IP-OBU1 and Router1). There exists another Host2), and two routers (IP-OBU1 and Router1). There exists another
internal network (Fixed Network1) inside EN1. EN1 has one host internal network (Fixed Network1) inside EN1. EN1 has one host
(Host3), two routers (IP-RSU1 and Router2), and the collection of (Host3), two routers (IP-RSU1 and Router2), and the collection of
servers (Server1 to ServerN) for various services in the road servers (Server1 to ServerN) for various services in the road
networks, such as the emergency notification and navigation. networks, such as the emergency notification and navigation.
Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed
skipping to change at page 18, line 42 skipping to change at page 19, line 28
the internetworking with another IP-OBU or IP-RSU. The IPv6 layer the internetworking with another IP-OBU or IP-RSU. The IPv6 layer
information includes the IPv6 address and network prefix of an information includes the IPv6 address and network prefix of an
external network interface for the internetworking with another IP- external network interface for the internetworking with another IP-
OBU or IP-RSU. OBU or IP-RSU.
Through the mutual knowledge of the network parameters of internal Through the mutual knowledge of the network parameters of internal
networks, packets can be transmitted between the vehicle's moving networks, packets can be transmitted between the vehicle's moving
network and the EN's fixed network. Thus, V2I requires an efficient network and the EN's fixed network. Thus, V2I requires an efficient
protocol for the mutual knowledge of network parameters. protocol for the mutual knowledge of network parameters.
As shown in Figure 3, global IPv6 addresses are used for the wireless As shown in Figure 3, the addresses used for IPv6 transmissions over
link interfaces for IP-OBU and IP-RSU, but IPv6 Unique Local the wireless link interfaces for IP-OBU and IP-RSU can be either
Addresses (ULAs) [RFC4193] can also be used for those wireless link global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be
interfaces as long as IPv6 packets can be routed to them in the routed within vehicular networks [OMNI]. When global IPv6 addresses
vehicular networks [OMNI-Interface]. For the guarantee of the are used, wireless interface configuration and control overhead for
uniqueness of an IPv6 address, the configuration and control overhead Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener
of the DAD of the wireless link interfaces should be minimized to Discovery (MLD) [RFC2710][RFC3810] should be minimized to support V2I
support the V2I and V2X communications of vehicles moving fast along and V2X communications for vehicles moving fast along roadways; when
roadways. ULAs and the OMNI interface are used, no DAD nor MLD messaging is
needed.
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 |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | | | | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| | | | | | | | | | | | | | | |
| v v | | v v | | v v | | v v |
| ---------------------------- | | ---------------------------- | | ---------------------------- | | ---------------------------- |
| 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 |
skipping to change at page 19, line 47 skipping to change at page 20, line 42
Figure 4: Internetworking between Two Vehicles Figure 4: Internetworking between Two Vehicles
Figure 4 shows the internetworking between the moving networks of two Figure 4 shows the 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 two hosts (Host1 and Host2), Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2),
and two routers (IP-OBU1 and Router1). There exists another internal and two routers (IP-OBU1 and Router1). There exists another internal
network (Moving Network2) inside Vehicle2. Vehicle2 has two hosts network (Moving Network2) inside Vehicle2. Vehicle2 has two hosts
(Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's (Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's
IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile
router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
V2V networking. Thus, a host (Host1) in Vehicle1 can communicate V2V networking. Alternatively, Vehicle1 and Vehicle2 employ an OMNI
with another host (Host3) in Vehicle2 for a vehicular service through interface and use IPv6 ULAs for V2V networking. Thus, a host (Host1)
Vehicle1's moving network, a wireless link between IP-OBU1 and IP- in Vehicle1 can communicate with another host (Host3) in Vehicle2 for
OBU2, and Vehicle2's moving network. a vehicular service through Vehicle1's moving network, a wireless
link between IP-OBU1 and IP-OBU2, and Vehicle2's moving network.
As a V2V use case in Section 3.1, Figure 5 shows the linear network As a V2V use case in Section 3.1, Figure 5 shows the linear network
topology of platooning vehicles for V2V communications where Vehicle3 topology of platooning vehicles for V2V communications where Vehicle3
is the leading vehicle with a driver, and Vehicle2 and Vehicle1 are is the leading vehicle with a driver, and Vehicle2 and Vehicle1 are
the following vehicles without drivers. the following vehicles without drivers.
(*)<..................>(*)<..................>(*) (*)<..................>(*)<..................>(*)
| | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | | | | | |
skipping to change at page 21, line 21 skipping to change at page 22, line 16
IPv6 Neighbor Discovery (ND). Mobility Management (MM) is also IPv6 Neighbor Discovery (ND). Mobility Management (MM) is also
vulnerable to disconnections that occur before the completion of vulnerable to disconnections that occur before the completion of
identity verification and tunnel management. This is especially true identity verification and tunnel management. This is especially true
given the unreliable nature of wireless communication. This section given the unreliable nature of wireless communication. This section
presents key topics such as neighbor discovery and mobility presents key topics such as neighbor discovery and mobility
management. management.
5.1. Neighbor Discovery 5.1. Neighbor Discovery
IPv6 ND [RFC4861][RFC4862] is a core part of the IPv6 protocol suite. IPv6 ND [RFC4861][RFC4862] is a core part of the IPv6 protocol suite.
IPv6 ND is designed for point-to-point links and transit links (e.g., IPv6 ND is designed for link types including point-to-point,
Ethernet). It assumes the efficient and reliable support of multicast-capable (e.g., Ethernet) and Non-Broadcast Multiple Access
multicast and unicast from the link layer for various network (NBMA). It assumes the efficient and reliable support of multicast
operations such as MAC Address Resolution (AR), Duplicate Address and unicast from the link layer for various network operations such
Detection (DAD), and Neighbor Unreachability Detection (NUD). as MAC Address Resolution (AR), DAD, MLD and Neighbor Unreachability
Detection (NUD).
Vehicles move quickly within the communication coverage of any Vehicles move quickly within the communication coverage of any
particular vehicle or IP-RSU. Before the vehicles can exchange particular vehicle or IP-RSU. Before the vehicles can exchange
application messages with each other, they need to be configured with application messages with each other, they need to be configured with
a link-local IPv6 address or a global IPv6 address, and run IPv6 ND. a link-local IPv6 address or a global IPv6 address, and run IPv6 ND.
The requirements for IPv6 ND for vehicular networks are efficient DAD The requirements for IPv6 ND for vehicular networks are efficient DAD
and NUD operations. An efficient DAD is required to reduce the and NUD operations. An efficient DAD is required to reduce the
overhead of the DAD packets during a vehicle's travel in a road overhead of the DAD packets during a vehicle's travel in a road
network, which guaranteeing the uniqueness of a vehicle's global IPv6 network, which guaranteeing the uniqueness of a vehicle's global IPv6
skipping to change at page 22, line 47 skipping to change at page 23, line 43
Internet, including the DAD and NUD operations. Internet, including the DAD and NUD operations.
5.1.1. Link Model 5.1.1. Link Model
A prefix model for a vehicular network needs to facilitate the A prefix model for a vehicular network needs to facilitate the
communication between two vehicles with the same prefix regardless of communication between two vehicles with the same prefix regardless of
the vehicular network topology as long as there exist bidirectional the vehicular network topology as long as there exist bidirectional
E2E paths between them in the vehicular network including VANETs and E2E paths between them in the vehicular network including VANETs and
IP-RSUs. This prefix model allows vehicles with the same prefix to IP-RSUs. This prefix model allows vehicles with the same prefix to
communicate with each other via a combination of multihop V2V and communicate with each other via a combination of multihop V2V and
multihop V2I with VANETs and IP-RSUs. Note that the OMNI link model multihop V2I with VANETs and IP-RSUs. Note that the OMNI interface
supports these multihop V2V and V2I through an OMNI multilink service supports an NBMA link model where multihop V2V and V2I communications
[OMNI-Interface]. use each mobile node's ULAs without need for any DAD or MLD
messaging.
IPv6 protocols work under certain assumptions for the link model that IPv6 protocols work under certain assumptions that do not necessarily
do not necessarily hold in a vehicular wireless link hold for vehicular wireless access link types other than OMNI/NBMA
[VIP-WAVE][RFC5889]. For instance, some IPv6 protocols assume [VIP-WAVE][RFC5889]; the rest of this section discusses implications
symmetry in the connectivity among neighboring interfaces [RFC6250]. for those link types that do not apply when the OMNI/NBMA link model
However, radio interference and different levels of transmission is used. For instance, some IPv6 protocols assume symmetry in the
power may cause asymmetric links to appear in vehicular wireless connectivity among neighboring interfaces [RFC6250]. However, radio
links. As a result, a new vehicular link model needs to consider the interference and different levels of transmission power may cause
asymmetry of dynamically changing vehicular wireless links. asymmetric links to appear in vehicular wireless links. As a result,
a new vehicular link model needs to consider the asymmetry of
dynamically changing vehicular wireless links.
There is a relationship between a link and a prefix, besides the There is a relationship between a link and a 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 IPv6 link. on-link bit set can communicate with each other on an IPv6 link.
However, the vehicular link model needs to define the relationship However, the vehicular link model needs to define the relationship
between a link and a prefix, considering the dynamics of wireless between a link and a prefix, considering the dynamics of wireless
links and the characteristics of VANET. links and the characteristics of VANET.
skipping to change at page 24, line 26 skipping to change at page 25, line 23
to communicate with each other directly via VANET rather than to communicate with each other directly via VANET rather than
indirectly via IP-RSUs. On the other hand, when Vehicle1 and indirectly via IP-RSUs. On the other hand, when Vehicle1 and
Vehicle3 are far away from direct communication range in separate Vehicle3 are far away from direct communication range in separate
VANETs and under two different IP-RSUs, they can communicate with VANETs and under two different IP-RSUs, they can communicate with
each other through the relay of IP-RSUs via V2I2V. Thus, two each other through the relay of IP-RSUs via V2I2V. Thus, two
separate VANETs can merge into one network via IP-RSU(s). Also, separate VANETs can merge into one network via IP-RSU(s). Also,
newly arriving vehicles can merge two separate VANETs into one VANET newly arriving vehicles can merge two separate VANETs into one VANET
if they can play the role of a relay node for those VANETs. if they can play the role of a relay node for those VANETs.
Thus, in IPv6-based vehicular networking, the vehicular link model Thus, in IPv6-based vehicular networking, the vehicular link model
should have minimum changes for the interoperability with the legacy should have minimum changes for interoperability with standard IPv6
IPv6 link model in an efficient fashion to support the IPv6 DAD and links in an efficient fashion to support IPv6 DAD, MLD and NUD
NUD operations. operations. When the OMNI NBMA link model is used, there are no link
model changes nor DAD/MLD messaging required.
5.1.2. MAC Address Pseudonym 5.1.2. MAC Address Pseudonym
For the protection of drivers' privacy, a pseudonym of a MAC address For the protection of drivers' privacy, a pseudonym of a MAC address
of a vehicle's network interface should be used, so that the MAC of a vehicle's network interface should be used, so that the MAC
address can be changed periodically. However, although such a address can be changed periodically. However, although such a
pseudonym of a MAC address can protect to some extent the privacy of pseudonym of a MAC address can protect to some extent the privacy of
a vehicle, it may not be able to resist attacks on vehicle a vehicle, it may not be able to resist attacks on vehicle
identification by other fingerprint information, for example, the identification by other fingerprint information, for example, the
scrambler seed embedded in IEEE 802.11-OCB frames [Scrambler-Attack]. scrambler seed embedded in IEEE 802.11-OCB frames [Scrambler-Attack].
skipping to change at page 25, line 12 skipping to change at page 26, line 11
checked through the DAD procedure. For vehicular networks with high checked through the DAD procedure. For vehicular networks with high
mobility and density, this DAD needs to be performed efficiently with mobility and density, this DAD needs to be performed efficiently with
minimum overhead so that the vehicles can exchange application minimum overhead so that the vehicles can exchange application
messages (e.g., collision avoidance and accident notification) with messages (e.g., collision avoidance and accident notification) with
each other with a short interval (e.g., 0.5 second) each other with a short interval (e.g., 0.5 second)
[NHTSA-ACAS-Report]. [NHTSA-ACAS-Report].
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 ad hoc routing protocol (e.g., AODV or OLSRv2) 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].
A routing protocol for a VANET may cause redundant wireless frames in A routing protocol for a VANET may cause redundant wireless frames in
the air to check the neighborhood of each vehicle and compute the the air to check the neighborhood of each vehicle and compute the
routing information in a VANET with a dynamic network topology routing information in a VANET with a dynamic network topology
because the IPv6 ND is used to check the neighborhood of each because the IPv6 ND is used to check the neighborhood of each
vehicle. Thus, the vehicular routing needs to take advantage of the vehicle. Thus, the vehicular routing needs to take advantage of the
skipping to change at page 26, line 22 skipping to change at page 27, line 21
subnet, the IP-RSUs can proactively support the IPv6 mobility of the subnet, the IP-RSUs can proactively support the IPv6 mobility of the
vehicle, while performing the SLAAC, data forwarding, and handover vehicle, while performing the SLAAC, data forwarding, and handover
for the sake of the vehicle. for the sake of the vehicle.
For a mobility management scheme in a shared link, where the wireless For a mobility management scheme in a shared link, where the wireless
subnets of multiple IP-RSUs share the same prefix, an efficient subnets of multiple IP-RSUs share the same prefix, an efficient
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-Interface]), DAD is not required because the IPv6 address of a [OMNI]), DAD is not required because the IPv6 address of a vehicle's
vehicle's external wireless interface is guaranteed to be unique. external wireless interface is guaranteed to be unique. There is a
There is a tradeoff between the prefix usage efficiency and DAD tradeoff between the prefix usage efficiency and DAD overhead. Thus,
overhead. Thus, the IPv6 address autoconfiguration for vehicular the IPv6 address autoconfiguration for vehicular networks needs to
networks needs to consider this tradeoff to support efficient consider this tradeoff to support efficient mobility management.
mobility management.
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 31, line 33 skipping to change at page 32, line 33
ISO/TC 204, "Intelligent Transport Systems - ISO/TC 204, "Intelligent Transport Systems -
Communications Access for Land Mobiles (CALM) - IPv6 Communications Access for Land Mobiles (CALM) - IPv6
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-Interface] [OMNI] Templin, F. and A. Whyman, "Transmission of IPv6 Packets
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-24 (work in progress), June templin-6man-omni-interface-24 (work in progress), June
2020. 2020.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, July Demand Distance Vector (AODV) Routing", RFC 3561, July
2003. 2003.
[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
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.
[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.
skipping to change at page 36, line 5 skipping to change at page 38, 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-15 Appendix A. Acknowledgments
The following changes are made from draft-ietf-ipwave-vehicular-
networking-15:
o This version is revised based on the further comments from the
following reviewers: Fred L. Templin (The Boeing Company) and
YongJoon Joe (LSware).
o According to the comments from Fred L. Templin, in Section 3.1
and Section 3.2, UAM (Urban Air Mobility) end systems are
considered for new V2V and V2I use cases.
o According to the comments from YongJoon Joe, in Section 3.1 and
Section 6, the text about a consensus method of a blockchain in
vehicular networks is revised such that a consensus algorithm
needs to be efficient for fast moving vehicles.
Appendix B. 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 (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
(Institute for Information & communications Technology Promotion). (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 C. 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),
 End of changes. 32 change blocks. 
134 lines changed or deleted 139 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/