draft-ietf-ipwave-vehicular-networking-09.txt   draft-ietf-ipwave-vehicular-networking-10.txt 
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational May 24, 2019 Intended status: Informational July 8, 2019
Expires: November 25, 2019 Expires: January 9, 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-09 draft-ietf-ipwave-vehicular-networking-10
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 November 25, 2019. This Internet-Draft will expire on January 9, 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 . . . . . . . . . . . . . . . . 9 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 10
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 11 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 19 7. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Changes from draft-ietf-ipwave-vehicular- Appendix A. Changes from draft-ietf-ipwave-vehicular-
networking-08 . . . . . . . . . . . . . . . . . . . 25 networking-09 . . . . . . . . . . . . . . . . . . . 26
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 25 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 25 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
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 8, line 45 skipping to change at page 8, line 45
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. Also, it is assumed
that such the wireless media interfaces are autoconfigured with a that such the wireless media interfaces are autoconfigured with a
global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and
V2I networking. V2I networking. Note that 2001:DB8::/32 is a documentation prefix
[RFC3849] for example prefixes in this document, and also that any
routable IPv6 address needs to be routable in a VANET and a vehicular
network including RSUs.
Especially, for IPv6 packets transporting over IEEE 802.11-OCB, Especially, for IPv6 packets transporting over IEEE 802.11-OCB,
[IPv6-over-802.11-OCB] specifies several details, such as Maximum [IPv6-over-802.11-OCB] specifies several details, such as 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. Especially, an Ethernet Adaptation (EA) layer is
in charge of transforming some parameters between IEEE 802.11 MAC in charge of transforming some parameters between IEEE 802.11 MAC
layer and IPv6 network layer, which is located between IEEE layer and IPv6 network layer, which is located between IEEE
802.11-OCB's logical link control layer and IPv6 network layer. This 802.11-OCB's logical link control layer and IPv6 network layer. This
IPv6 over 802.11-OCB can be used for both V2V and V2I in IP-based IPv6 over 802.11-OCB can be used for both V2V and V2I in IP-based
skipping to change at page 11, line 18 skipping to change at page 11, line 24
information. The link layer information includes wireless link layer information. The link layer information includes wireless link layer
parameters, such as wireless media (e.g., IEEE 802.11-OCB and LTE- parameters, such as wireless media (e.g., IEEE 802.11-OCB and LTE-
V2X) and a transmission power level. The MAC layer information V2X) and a transmission power level. The MAC layer information
includes the MAC address of an external network interface for the includes the MAC address of an external network interface for the
internetworking with another vehicle or RSU. The IP layer internetworking with another vehicle or RSU. The IP layer
information includes the IP address and prefix of an external network information includes the IP address and prefix of an external network
interface for the 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. DNS services should be moving network and the RSU's fixed network. A DNS service should be
supported to enable name resolution for hosts or servers residing supported for the DNS name resolution of in-vehicle devices within a
either in the vehicle's moving network or the RSU's fixed network. vehicle's internal network as well as for the DNS name resolution of
It is assumed that the DNS names of in-vehicle devices and their those devices from a remote host in the Internet for on-line
service names are registered into a DNS server in a vehicle or an diagnosis (e.g., an automotive service center server). It is assumed
RSU, as shown in Figure 2. that the DNS names of in-vehicle devices and their service names are
registered into a DNS server in a vehicle or an RSU, as shown in
Figure 2.
Figure 2 shows internetworking between the vehicle's moving network Figure 2 shows internetworking between the vehicle's moving network
and the RSU's fixed network. There exists an internal network and the RSU's fixed network. There exists an internal network
(Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server
(DNS1), the two hosts (Host1 and Host2), and the two routers (Router1 (DNS1), the two hosts (Host1 and Host2), and the two routers (Router1
and Router2). There exists another internal network (Fixed Network1) and Router2). There exists another internal network (Fixed Network1)
inside RSU1. RSU1 has the DNS Server (DNS2), one host (Host3), the inside RSU1. RSU1 has the DNS Server (DNS2), one host (Host3), the
two routers (Router3 and Router4), and the collection of servers two routers (Router3 and Router4), and the collection of servers
(Server1 to ServerN) for various services in the road networks, such (Server1 to ServerN) for various services in the road networks, such
as the emergency notification and navigation. Vehicle1's Router1 as the emergency notification and navigation. Vehicle1's Router1
skipping to change at page 14, line 35 skipping to change at page 14, line 35
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.
When ND is used in vehicular networks, the communication delay (i.e., According to a report from the National Highway Traffic Safety
latency) between two vehicles should be bounded to a certain Administration (NHTSA) [NHTSA-ACAS-Report], an extra 0.5 second of
threshold (e.g., 500 ms) for collision-avoidance message exchange warning time can prevent about 60% of the collisions of vehicles
[CASD]. For IP-based safety applications (e.g., context-aware moving closely in a roadway. A warning message should be exchanged
navigation, adaptive cruise control, and platooning) in vehicular every 0.5 seconds. Thus, if the ND messages (e.g., NS and NA) are
network, this bounded data delivery is critical. The real used as warning messages, they should be exchanged every 0.5 second.
implementations for such applications are not available yet. Thus,
ND needs to appropriately operate to support IP-based safety For IP-based safety applications (e.g., context-aware navigation,
applications. adaptive cruise control, and platooning) in vehicular network, this
bounded data delivery is critical. The real implementations for such
applications are not available yet. Thus, ND needs to appropriately
operate to support IP-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. However, interference and
different levels of transmission power may cause unidirectional links different levels of transmission power may cause unidirectional links
to appear in vehicular wireless links. As a result, a new vehicular to appear in vehicular wireless links. As a result, a new vehicular
link model is required for a dynamically changing vehicular wireless link model is required for a dynamically changing vehicular wireless
skipping to change at page 15, line 31 skipping to change at page 15, line 34
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 a 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.
An IPv6 prefix can be used in a multi-link subnet as an extended The vehicular link model needs to support the multihop routing in a
subnet. IPv6 Stateless Address Autoconfiguration (SLAAC) needs to be connected VANET where the vehicles with the same global-scope IPv6
performed even in the multiple links where all of the links are prefix are connected in one hop or multiple hops. It also needs to
configured with the same subnet prefix [RFC4861][RFC4862]. Thus, a support the multhop routing in multiple connected VANETs via an RSU
vehicular link model can consider a multi-hop V2V (or V2I) over a that has the wireless connectivity with each VANET. For example,
multi-link subnet in a vehicular network having multiple VANETs and assume that Vehicle1, Vehicle 2, and Vehicle3 are configured with
RSUs, as shown in Figure 1. For example, in this figure, vehicles their IPv6 addresses based on the same global-scope IPv6 prefix.
(i.e., Vehicle1, Vehicle2, and Vehicle3) in Subnet1 and Subnet2 Vehicle1 and Vehicle3 can also communicate with each other via either
having RSU1 and RSU2, respectively, construct a multi-link subnet multi-hop V2V or multi-hop V2I2V. When two vehicles (e.g., Vehicle1
with VANETs and RSUs. Vehicle1 and Vehicle3 can also communicate and Vehicle3 in Figure 1) are connected in a VANET, it will be more
with each other via either multi-hop V2V or multi-hop V2I2V. When efficient for them to communicate with each other via VANET rather
two vehicles (e.g., Vehicle1 and Vehicle3 in Figure 1) are connected than RSUs. On the other hand, when two vehicles (e.g., Vehicle1 and
in a VANET, it will be more efficient for them to communicate with Vehicle3) are far away from the communication range in separate
each other via VANET rather than RSUs. On the other hand, when two VANETs and under two different RSUs, they can communicate with each
vehicles (e.g., Vehicle1 and Vehicle3) are far away from the other through the relay of RSUs via V2I2V. Thus, two separate VANETs
communication range in separate VANETs and under two different RSUs, can merge into one network via RSU(s). Also, newly arriving vehicles
they can communicate with each other through the relay of RSUs via can merge two separate VANETs into one VANET if they can play a role
V2I2V. of a relay node for those VANETs.
Therefore, IPv6 ND needs to be extended for an efficient Vehicular
Neighbor Discovey (VND) to support the concept of an IPv6 link
corresponding to an IPv6 prefix even in a multi-link subnet
consisting of multiple vehicles and RSUs [ID-Vehicular-ND].
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, the pseudonym of a MAC
address of a vehicle's network interface should be used, with the address of a vehicle's network interface should be used, with the
help of which the MAC address can be changed periodically. The help of which the MAC address can be changed periodically. The
pseudonym of a MAC address affects an IPv6 address based on the MAC pseudonym of a MAC address affects an IPv6 address based on the MAC
address, and a transport-layer (e.g., TCP) session with an IPv6 address, and a transport-layer (e.g., TCP) session with an IPv6
address pair. However, the pseudonym handling is not implemented and address pair. However, the pseudonym handling is not implemented and
tested yet for applications on IP-based vehicular networking. tested yet for applications on IP-based vehicular networking.
skipping to change at page 17, line 12 skipping to change at page 17, line 12
networks without a vehicular ad hoc routing protocol (e.g., AODV networks without a vehicular ad hoc routing protocol (e.g., AODV
[RFC3561] and OLSRv2 [RFC7181]). [RFC3561] and 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 a VANET (or a multi-link subnet),
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. As a feasible approach, Vehicular ND can control traffic overhead [ID-Multicast-Problems]. As a feasible
be extended to accommodate routing functionality with a prefix approach, Vehicular ND can be extended to accommodate routing
discovery option. In this case, there is no need to run a separate functionality with a prefix discovery option. In this case, there is
vehicular ad hoc routing protocol in VANETs. The ND extension can no need to run a separate vehicular ad hoc routing protocol in
allow vehicles to exchange their prefixes in a multihop fashion VANETs. The ND extension can allow vehicles to exchange their
[ID-Vehicular-ND]. With the exchanged prefixes, they can compute prefixes in a multihop fashion [ID-Vehicular-ND]. With the exchanged
their routing table (or IPv6 ND's neighbor cache) for the multi-link prefixes, they can compute their routing table (or IPv6 ND's neighbor
subnet with a distance-vector algorithm [Intro-to-Algorithms]. 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 Also, an efficient, rapid DAD needs to be supported in a vehicular
network having multiple VANETs (or a multi-link subnet) to prevent or network having multiple VANETs (or a multi-link subnet) to prevent or
reduce IPv6 address conflicts in such a subnet. A feasible approach reduce IPv6 address conflicts in such a subnet. A feasible approach
is to use a multi-hop DAD optimization for the efficient vehicular- is to use a multi-hop DAD optimization for the efficient vehicular-
network-wide DAD [RFC6775][RFC8505]. network-wide DAD [RFC6775][RFC8505].
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
skipping to change at page 18, line 35 skipping to change at page 18, line 35
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 illude 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. Applications on IP-based vehicular networking, vehicles and RSUs. Note that good vehicles are ones with valid
which are resilient to such a sybil attack, are not developed and certificates that are determined by the authentication process with
tested yet. an authentication server in the vehicular network. Applications on
IP-based vehicular networking, which are resilient to such a sybil
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
allowed to use vehicular networking. Also, in-vehicle devices and allowed to use vehicular networking. Also, in-vehicle devices and
mobile devices in a vehicle need to communicate with other in-vehicle mobile devices in a vehicle need to communicate with other in-vehicle
devices and mobile devices in another vehicle, and other servers in devices and mobile devices in another vehicle, and other servers in
an RSU in a secure way. an RSU in a secure way.
A Vehicle Identification Number (VIN) and a user certificate along A Vehicle Identification Number (VIN) and a user certificate along
with in-vehicle device's identifier generation can be used to with in-vehicle device's identifier generation can be used to
skipping to change at page 19, line 25 skipping to change at page 19, line 27
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 vehicular
nodes (e.g., vehicle and RSU) in terms of transport layer for a long- nodes (e.g., vehicle and 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
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
ND packets are disseminated over the VANET and vehicular network
including the RSU and the MA. The vehicles and RSUs need to filter
out suspicious ND traffic in advance.
For the mobility management, a malicious vehicle constructs multiple
virtual bogus vehicles, and register them with the RSU and the MA.
This registration makes the RSU and MA waste their resources. The
RSU and MA need to determine whether a vehicle is 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.
7. Informative References 7. Informative References
skipping to change at page 21, line 11 skipping to change at page 21, line 29
First Responder Network Authority, "FY 2017: ANNUAL REPORT First Responder Network Authority, "FY 2017: ANNUAL REPORT
TO CONGRESS, Advancing Public Safety Broadband TO CONGRESS, Advancing Public Safety Broadband
Communications", FirstNet FY 2017, December 2017. Communications", FirstNet FY 2017, December 2017.
[Fuel-Efficient] [Fuel-Efficient]
van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas,
"Fuel-Efficient En Route Formation of Truck Platoons", "Fuel-Efficient En Route Formation of Truck Platoons",
IEEE Transactions on Intelligent Transportation Systems, IEEE Transactions on Intelligent Transportation Systems,
January 2018. January 2018.
[ID-Multicast-Problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-06 (work
in progress), July 2019.
[ID-Vehicular-MM] [ID-Vehicular-MM]
Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular
Mobility Management for IP-Based Vehicular Networks", Mobility Management for IP-Based Vehicular Networks",
draft-jeong-ipwave-vehicular-mobility-management-00 (work draft-jeong-ipwave-vehicular-mobility-management-01 (work
in progress), March 2019. in progress), July 2019.
[ID-Vehicular-ND] [ID-Vehicular-ND]
Jeong, J., Ed., Shen, Y., and Z. Xiang, "IPv6 Neighbor Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular
Discovery for IP-Based Vehicular Networks", draft-jeong- Neighbor Discovery for IP-Based Vehicular Networks",
ipwave-vehicular-neighbor-discovery-06 (work in progress), draft-jeong-ipwave-vehicular-neighbor-discovery-07 (work
March 2019. in progress), July 2019.
[Identity-Management] [Identity-Management]
Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer
Identities Management in ITS Stations", The 10th Identities Management in ITS Stations", The 10th
International Conference on ITS Telecommunications, International Conference on ITS Telecommunications,
November 2010. November 2010.
[IEEE-802.11-OCB] [IEEE-802.11-OCB]
"Part 11: Wireless LAN Medium Access Control (MAC) and "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Std Physical Layer (PHY) Specifications", IEEE Std
skipping to change at page 21, line 46 skipping to change at page 22, line 22
Physical Layer (PHY) Specifications - Amendment 6: Physical Layer (PHY) Specifications - Amendment 6:
Wireless Access in Vehicular Environments", IEEE Std Wireless Access in Vehicular Environments", IEEE Std
802.11p-2010, June 2010. 802.11p-2010, June 2010.
[Intro-to-Algorithms] [Intro-to-Algorithms]
H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C. H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C.
Stein, "Introduction to Algorithms, 3rd ed.", The Stein, "Introduction to Algorithms, 3rd ed.", The
MIT Press, July 2009. MIT Press, July 2009.
[IPv6-over-802.11-OCB] [IPv6-over-802.11-OCB]
Benamar, N., Haerri, J., Lee, J., and T. Ernst, Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic
"Transmission of IPv6 Packets over IEEE 802.11 Networks Support for IPv6 over IEEE Std 802.11 Networks Operating
operating in mode Outside the Context of a Basic Service Outside the Context of a Basic Service Set (IPv6-over-
Set (IPv6-over-80211-OCB)", draft-ietf-ipwave-ipv6-over- 80211-OCB)", draft-ietf-ipwave-ipv6-over-80211ocb-49 (work
80211ocb-45 (work in progress), April 2019. in progress), July 2019.
[ISO-ITS-IPv6] [ISO-ITS-IPv6]
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", ISO 21210:2012, June 2012. Networking", ISO 21210:2012, June 2012.
[NHTSA-ACAS-Report]
National Highway Traffic Safety Administration (NHTSA),
"Final Report of Automotive Collision Avoidance Systems
(ACAS) Program", DOT HS 809 080, August 2000.
[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.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
skipping to change at page 25, line 5 skipping to change at page 26, 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-08 Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-09
The following changes are made from draft-ietf-ipwave-vehicular- The following changes are made from draft-ietf-ipwave-vehicular-
networking-08: networking-09:
o This version is revised based on the comments from Charlie Perkins o This version is revised based on the comments from Charlie
and Sri Gundavelli. Perkins.
o This version focuses on the problem statement about IP-based o For the question on the preference on a multi-link subnet model,
vehicular networking, such as IPv6 neighbor discovery, mobility the revision does not suggest the multi-link subnet model as a
management, and security & privacy. 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
[RFC3849]. Any routable IPv6 address needs to be routable in a
VANET and a vehicular network including RSUs.
o With an example in Figure 1, it is suggested that two separate
VANETs can merge into one network.
o A suggestion is made about how to distinguish good nodes from bad
nodes with an authentication process.
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
 End of changes. 23 change blocks. 
79 lines changed or deleted 133 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/