| < draft-ietf-ipwave-vehicular-networking-27.txt | draft-ietf-ipwave-vehicular-networking-28.txt > | |||
|---|---|---|---|---|
| IPWAVE Working Group J. Jeong, Ed. | IPWAVE Working Group J. Jeong, Ed. | |||
| Internet-Draft Sungkyunkwan University | Internet-Draft Sungkyunkwan University | |||
| Intended status: Informational 22 February 2022 | Intended status: Informational 30 March 2022 | |||
| Expires: 26 August 2022 | Expires: 1 October 2022 | |||
| IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem | IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem | |||
| Statement and Use Cases | Statement and Use Cases | |||
| draft-ietf-ipwave-vehicular-networking-27 | draft-ietf-ipwave-vehicular-networking-28 | |||
| 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 26 August 2022. | This Internet-Draft will expire on 1 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12 | 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 13 | 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14 | |||
| 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15 | 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 16 | |||
| 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 | 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19 | |||
| 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 | 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 | 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 | |||
| 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25 | 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 | 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 | |||
| 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27 | 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 29 | 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 29 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
| 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32 | 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32 | |||
| 6.2. Security Threats in Mobility Management . . . . . . . . . 33 | 6.2. Security Threats in Mobility Management . . . . . . . . . 33 | |||
| 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33 | 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 40 | 8.2. Informative References . . . . . . . . . . . . . . . . . 40 | |||
| Appendix A. Support of Multiple Radio Technologies for V2V . . . 45 | Appendix A. Support of Multiple Radio Technologies for V2V . . . 46 | |||
| Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45 | Appendix B. Support of Multihop V2X Networking . . . . . . . . . 46 | |||
| Appendix C. Support of Mobility Management for V2I . . . . . . . 47 | Appendix C. Support of Mobility Management for V2I . . . . . . . 48 | |||
| Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 48 | Appendix D. Support of MTU Diversity for IP-based Vehicular | |||
| Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 49 | Networks . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 | Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 50 | |||
| Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 51 | ||||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 | ||||
| 1. Introduction | 1. Introduction | |||
| Vehicular networking studies have mainly focused on improving safety | Vehicular networking studies have mainly focused on improving safety | |||
| and efficiency, and also enabling entertainment in vehicular | and efficiency, and also enabling entertainment in vehicular | |||
| networks. The Federal Communications Commission (FCC) in the US | networks. The Federal Communications Commission (FCC) in the US | |||
| allocated wireless channels for Dedicated Short-Range Communications | allocated wireless channels for Dedicated Short-Range Communications | |||
| (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with | (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with | |||
| the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- | the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- | |||
| based wireless communications can support vehicle-to-vehicle (V2V), | based wireless communications can support vehicle-to-vehicle (V2V), | |||
| vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) | vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) | |||
| networking. The European Union (EU) allocated radio spectrum for | networking. The European Union (EU) allocated radio spectrum for | |||
| safety-related and non-safety-related applications of ITS with the | safety-related and non-safety-related applications of ITS with the | |||
| frequency band of 5.875 - 5.905 GHz, as part of the Commission | frequency band of 5.875 - 5.905 GHz, as part of the Commission | |||
| Decision 2008/671/EC [EU-2008-671-EC]. | Decision 2008/671/EC [EU-2008-671-EC]. Most countries and regions in | |||
| the world have adopted the same frequency allocation for vehicular | ||||
| networks. | ||||
| For direct inter-vehicular wireless connectivity, IEEE has amended | For direct inter-vehicular wireless connectivity, IEEE has amended | |||
| standard 802.11 (commonly known as Wi-Fi) to enable safe driving | standard 802.11 (commonly known as Wi-Fi) to enable safe driving | |||
| services based on DSRC for the Wireless Access in Vehicular | services based on DSRC for the Wireless Access in Vehicular | |||
| Environments (WAVE) system. The Physical Layer (L1) and Data Link | Environments (WAVE) system. The Physical Layer (L1) and Data Link | |||
| Layer (L2) issues are addressed in IEEE 802.11p [IEEE-802.11p] for | Layer (L2) issues are addressed in IEEE 802.11p [IEEE-802.11p] for | |||
| the PHY and MAC of the DSRC, while IEEE 1609.2 [WAVE-1609.2] covers | the PHY and MAC of the DSRC, while IEEE 1609.2 [WAVE-1609.2] covers | |||
| security aspects, IEEE 1609.3 [WAVE-1609.3] defines related services | security aspects, IEEE 1609.3 [WAVE-1609.3] defines related services | |||
| at network and transport layers, and IEEE 1609.4 [WAVE-1609.4] | at network and transport layers, and IEEE 1609.4 [WAVE-1609.4] | |||
| specifies the multi-channel operation. IEEE 802.11p was first a | specifies the multi-channel operation. IEEE 802.11p was first a | |||
| skipping to change at page 3, line 47 ¶ | skipping to change at page 4, line 12 ¶ | |||
| communicate with each other without relay nodes (e.g., eNodeB in LTE | communicate with each other without relay nodes (e.g., eNodeB in LTE | |||
| and gNodeB in 5G). | and gNodeB in 5G). | |||
| Along with these WAVE standards and C-V2X standards, regardless of a | Along with these WAVE standards and C-V2X standards, regardless of a | |||
| wireless access technology under the IP stack of a vehicle, vehicular | wireless access technology under the IP stack of a vehicle, vehicular | |||
| networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 | networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 | |||
| protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) | protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) | |||
| [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network | [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network | |||
| Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP) | Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP) | |||
| [I-D.ietf-lisp-rfc6830bis], and Automatic Extended Route Optimization | [I-D.ietf-lisp-rfc6830bis], and Automatic Extended Route Optimization | |||
| (AERO) [I-D.templin-6man-aero]). In addition, ISO has approved a | based on the Overlay Multilink Network Interface (AERO/OMNI) | |||
| standard specifying the IPv6 network protocols and services to be | [I-D.templin-6man-aero] [I-D.templin-6man-omni]). In addition, ISO | |||
| used for Communications Access for Land Mobiles (CALM) | has approved a standard specifying the IPv6 network protocols and | |||
| services to be used for Communications Access for Land Mobiles (CALM) | ||||
| [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1]. | [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1]. | |||
| This document describes use cases and a problem statement about | This document describes use cases and a problem statement about | |||
| IPv6-based vehicular networking for ITS, which is named IPv6 Wireless | IPv6-based vehicular networking for ITS, which is named IPv6 Wireless | |||
| Access in Vehicular Environments (IPWAVE). First, it introduces the | Access in Vehicular Environments (IPWAVE). First, it introduces the | |||
| use cases for using V2V, V2I, and V2X networking in ITS. Next, for | use cases for using V2V, V2I, and V2X networking in ITS. Next, for | |||
| IPv6-based vehicular networks, it makes a gap analysis of current | IPv6-based vehicular networks, it makes a gap analysis of current | |||
| IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, | IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, | |||
| and Security & Privacy), and then enumerates requirements for the | and Security & Privacy), and then enumerates requirements for the | |||
| extensions of those IPv6 protocols, which are tailored to IPv6-based | extensions of those IPv6 protocols, which are tailored to IPv6-based | |||
| skipping to change at page 4, line 50 ¶ | skipping to change at page 5, line 14 ¶ | |||
| * Edge Network (EN): It is an access network that has an IP-RSU for | * Edge Network (EN): It is an access network that has an IP-RSU for | |||
| wireless communication with other vehicles having an IP-OBU and | wireless communication with other vehicles having an IP-OBU and | |||
| wired communication with other network devices (e.g., routers, IP- | wired communication with other network devices (e.g., routers, IP- | |||
| RSUs, ECDs, servers, and MA). It may have a Global Positioning | RSUs, ECDs, servers, and MA). It may have a Global Positioning | |||
| System (GPS) radio receiver for its position recognition and the | System (GPS) radio receiver for its position recognition and the | |||
| localization service for the sake of vehicles. | localization service for the sake of vehicles. | |||
| * IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a | * IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a | |||
| computer situated in a vehicle (e.g., car, bicycle, autobike, | computer situated in a vehicle (e.g., car, bicycle, autobike, | |||
| motor cycle, and a similar one) and a device (e.g., smartphone and | motorcycle, and a similar one). It has at least one IP interface | |||
| Internet-of-Things (IoT) device). It has at least one IP | that runs in IEEE 802.11-OCB and has an "OBU" transceiver. Also, | |||
| interface that runs in IEEE 802.11-OCB and has an "OBU" | it may have an IP interface that runs in Cellular V2X (C-V2X) | |||
| transceiver. Also, it may have an IP interface that runs in | [TS-23.285-3GPP] [TR-22.886-3GPP][TS-23.287-3GPP]. It can play a | |||
| Cellular V2X (C-V2X) [TS-23.285-3GPP] | role of a router connecting multiple computers (or in-vehicle | |||
| [TR-22.886-3GPP][TS-23.287-3GPP]. It can play a role of a router | devices) inside a vehicle. See the definition of the term "OBU" | |||
| connecting multiple computers (or in-vehicle devices) inside a | in [RFC8691]. | |||
| vehicle. See the definition of the term "OBU" in [RFC8691]. | ||||
| * IP-RSU: "IP Roadside Unit": An IP-RSU is situated along the road. | * IP-RSU: "IP Roadside Unit": An IP-RSU is situated along the road. | |||
| It has at least two distinct IP-enabled interfaces. The wireless | It has at least two distinct IP-enabled interfaces. The wireless | |||
| PHY/MAC layer of at least one of its IP-enabled interfaces is | PHY/MAC layer of at least one of its IP-enabled interfaces is | |||
| configured to operate in 802.11-OCB mode. An IP-RSU communicates | configured to operate in 802.11-OCB mode. An IP-RSU communicates | |||
| with the IP-OBU over an 802.11 wireless link operating in OCB | with the IP-OBU over an 802.11 wireless link operating in OCB | |||
| mode. Also, it may have an IP interface that runs in C-V2X along | mode. Also, it may have the third IP-enabled wireless interface | |||
| with an "RSU" transceiver. An IP-RSU is similar to an Access | running in 3GPP C-V2X in addition to the IP-RSU defined in | |||
| Network Router (ANR), defined in [RFC3753], and a Wireless | [RFC8691]. An IP-RSU is similar to an Access Network Router | |||
| Termination Point (WTP), defined in [RFC5415]. See the definition | (ANR), defined in [RFC3753], and a Wireless Termination Point | |||
| of the term "RSU" in [RFC8691]. | (WTP), defined in [RFC5415]. See the definition of the term "RSU" | |||
| in [RFC8691]. | ||||
| * LiDAR: "Light Detection and Ranging". It is a scanning device to | * LiDAR: "Light Detection and Ranging". It is a scanning device to | |||
| measure a distance to an object by emitting pulsed laser light and | measure a distance to an object by emitting pulsed laser light and | |||
| measuring the reflected pulsed light. | measuring the reflected pulsed light. | |||
| * Mobility Anchor (MA): A node that maintains IPv6 addresses and | * Mobility Anchor (MA): A node that maintains IPv6 addresses and | |||
| mobility information of vehicles in a road network to support | mobility information of vehicles in a road network to support | |||
| their IPv6 address autoconfiguration and mobility management with | their IPv6 address autoconfiguration and mobility management with | |||
| a binding table. An MA has End-to-End (E2E) connections (e.g., | a binding table. An MA has End-to-End (E2E) connections (e.g., | |||
| tunnels) with IP-RSUs under its control for the address | tunnels) with IP-RSUs under its control for the address | |||
| skipping to change at page 7, line 9 ¶ | skipping to change at page 7, line 24 ¶ | |||
| * VIP: "Vehicular Internet Protocol". It is an IPv6 extension for | * VIP: "Vehicular Internet Protocol". It is an IPv6 extension for | |||
| vehicular networks including V2V, V2I, and V2X. | vehicular networks including V2V, V2I, and V2X. | |||
| * VMM: "Vehicular Mobility Management". It is an IPv6-based | * VMM: "Vehicular Mobility Management". It is an IPv6-based | |||
| mobility management for vehicular networks. | mobility management for vehicular networks. | |||
| * VND: "Vehicular Neighbor Discovery". It is an IPv6 ND extension | * VND: "Vehicular Neighbor Discovery". It is an IPv6 ND extension | |||
| for vehicular networks. | for vehicular networks. | |||
| * VSP: "Vehicular Security and Privacy". It is an IPv6-based | * VSP: "Vehicular Security and Privacy". It is an IPv6-based | |||
| security and privacy for vehicular networks. | security and privacy term for vehicular networks. | |||
| * WAVE: "Wireless Access in Vehicular Environments" [WAVE-1609.0]. | * WAVE: "Wireless Access in Vehicular Environments" [WAVE-1609.0]. | |||
| 3. Use Cases | 3. Use Cases | |||
| This section explains use cases of V2V, V2I, and V2X networking. The | This section explains use cases of V2V, V2I, and V2X networking. The | |||
| use cases of the V2X networking exclude the ones of the V2V and V2I | use cases of the V2X networking exclude the ones of the V2V and V2I | |||
| networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- | networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- | |||
| Device (V2D). | Device (V2D). | |||
| IP is widely used among popular end-user devices (e.g., smartphone | IP is widely used among popular end-user devices (e.g., smartphone | |||
| and tablet) in the Internet. Applications (e.g., navigator | and tablet) in the Internet. Applications (e.g., navigator | |||
| application) for those devices can be extended such that the V2V use | application) for those devices can be extended such that the V2V use | |||
| cases in this section can work with IPv6 as a network layer protocol | cases in this section can work with IPv6 as a network layer protocol | |||
| and IEEE 802.11-OCB as a link layer protocol. In addition, IPv6 | and IEEE 802.11-OCB as a link layer protocol. In addition, IPv6 | |||
| security needs to be extended to support those V2V use cases in a | security needs to be extended to support those V2V use cases in a | |||
| safe, secure, privacy-preserving way. | safe, secure, privacy-preserving way. | |||
| The use cases presented in this section serve as the description and | The use cases presented in this section serve as the description and | |||
| motivation for the need to extend IPv6 and its protocols to | motivation for the need to augment IPv6 and its protocols to | |||
| facilitate "Vehicular IPv6". Section 5 summarizes the overall | facilitate "Vehicular IPv6". Section 5 summarizes the overall | |||
| problem statement and IPv6 requirements. Note that the adjective | problem statement and IPv6 requirements. Note that the adjective | |||
| "Vehicular" in this document is used to represent extensions of | "Vehicular" in this document is used to represent extensions of | |||
| existing protocols such as IPv6 Neighbor Discovery, IPv6 Mobility | existing protocols such as IPv6 Neighbor Discovery, IPv6 Mobility | |||
| Management (e.g., PMIPv6 [RFC5213] and DMM [RFC7429]), and IPv6 | Management (e.g., PMIPv6 [RFC5213] and DMM [RFC7429]), and IPv6 | |||
| Security and Privacy Mechanisms rather than new "vehicular-specific" | Security and Privacy Mechanisms rather than new "vehicular-specific" | |||
| functions. | functions. | |||
| 3.1. V2V | 3.1. V2V | |||
| skipping to change at page 7, line 51 ¶ | skipping to change at page 8, line 18 ¶ | |||
| * Context-aware navigation for safe driving and collision avoidance; | * Context-aware navigation for safe driving and collision avoidance; | |||
| * Cooperative adaptive cruise control in a roadway; | * Cooperative adaptive cruise control in a roadway; | |||
| * Platooning in a highway; | * Platooning in a highway; | |||
| * Cooperative environment sensing; | * Cooperative environment sensing; | |||
| * Collision avoidance service of end systems of Urban Air Mobility | * Collision avoidance service of end systems of Urban Air Mobility | |||
| (UAM) [I-D.templin-ipwave-uam-its]. | (UAM). | |||
| 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 9 ¶ | skipping to change at page 9, line 27 ¶ | |||
| use environmental information sensed by driverless vehicles for | use environmental information sensed by driverless vehicles for | |||
| better interaction with the other vehicles and environment. Vehicles | better interaction with the other vehicles and environment. Vehicles | |||
| can also share their intended maneuvering information (e.g., lane | can also share their intended maneuvering information (e.g., lane | |||
| change, speed change, ramp in-and-out, cut-in, and abrupt braking) | change, speed change, ramp in-and-out, cut-in, and abrupt braking) | |||
| with neighboring vehicles. Thus, this information sharing can help | with neighboring vehicles. Thus, this information sharing can help | |||
| the vehicles behave as more efficient traffic flows and minimize | the vehicles behave as more efficient traffic flows and minimize | |||
| unnecessary acceleration and deceleration to achieve the best ride | unnecessary acceleration and deceleration to achieve the best ride | |||
| comfort. | comfort. | |||
| A collision avoidance service of UAM end systems in air can be | A collision avoidance service of UAM end systems in air can be | |||
| envisioned as a use case in air vehicular environments. This use | envisioned as a use case in air vehicular environments | |||
| case is similar to the context-aware navigator for terrestrial | [I-D.templin-ipwave-uam-its]. This use case is similar to the | |||
| vehicles. Through V2V coordination, those UAM end systems (e.g., | context-aware navigator for terrestrial vehicles. Through V2V | |||
| drones) can avoid a dangerous situation (e.g., collision) in three- | coordination, those UAM end systems (e.g., drones) can avoid a | |||
| dimensional space rather than two-dimensional space for terrestrial | dangerous situation (e.g., collision) in three-dimensional space | |||
| vehicles. Also, UAM end systems (e.g., flying car) with only a few | rather than two-dimensional space for terrestrial vehicles. Also, | |||
| meters off the ground can communicate with terrestrial vehicles with | UAM end systems (e.g., flying car) with only a few meters off the | |||
| wireless communication technologies (e.g., DSRC, LTE, and C-V2X). | ground can communicate with terrestrial vehicles with wireless | |||
| Thus, V2V means any vehicle to any vehicle, whether the vehicles are | communication technologies (e.g., DSRC, LTE, and C-V2X). Thus, V2V | |||
| ground-level or not. | means any vehicle to any vehicle, whether the vehicles are ground- | |||
| level or not. | ||||
| 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]. | |||
| skipping to change at page 10, line 37 ¶ | skipping to change at page 11, line 8 ¶ | |||
| networks. The First Responder Network Authority (FirstNet) | networks. The First Responder Network Authority (FirstNet) | |||
| [FirstNet] is provided by the US government to establish, operate, | [FirstNet] is provided by the US government to establish, operate, | |||
| and maintain an interoperable public safety broadband network for | and maintain an interoperable public safety broadband network for | |||
| safety and security network services, e.g., emergency calls. The | safety and security network services, e.g., emergency calls. The | |||
| construction of the nationwide FirstNet network requires each state | construction of the nationwide FirstNet network requires each state | |||
| in the US to have a Radio Access Network (RAN) that will connect to | in the US to have a Radio Access Network (RAN) that will connect to | |||
| the FirstNet's network core. The current RAN is mainly constructed | the FirstNet's network core. The current RAN is mainly constructed | |||
| using 4G-LTE for the communication between a vehicle and an | using 4G-LTE for the communication between a vehicle and an | |||
| infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected | infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected | |||
| that DSRC-based vehicular networks [DSRC] will be available for V2I | that DSRC-based vehicular networks [DSRC] will be available for V2I | |||
| and V2V in the near future. | and V2V in the near future. An equivalent project in Europe is | |||
| called Public Safety Communications Europe (PSCE) [PSCE], which is | ||||
| developing a network for emergency communications. | ||||
| An EV charging service with V2I can facilitate the efficient battery | An EV charging service with V2I can facilitate the efficient battery | |||
| charging of EVs. In the case where an EV charging station is | charging of EVs. In the case where an EV charging station is | |||
| connected to an IP-RSU, an EV can be guided toward the deck of the EV | connected to an IP-RSU, an EV can be guided toward the deck of the EV | |||
| charging station through a battery charging server connected to the | charging station or be notified that the charging station is out of | |||
| IP-RSU. In addition to this EV charging service, other value-added | service through a battery charging server connected to the IP-RSU. | |||
| services (e.g., air firmware/software update and media streaming) can | In addition to this EV charging service, other value-added services | |||
| be provided to an EV while it is charging its battery at the EV | (e.g., air firmware/software update and media streaming) can be | |||
| charging station. | provided to an EV while it is charging its battery at the EV charging | |||
| station. | ||||
| A UAM navigation service with efficient battery charging can plan the | A UAM navigation service with efficient battery charging can plan the | |||
| battery charging schedule of UAM end systems (e.g., drone) for long- | battery charging schedule of UAM end systems (e.g., drone) for long- | |||
| distance flying [CBDN]. For this battery charging schedule, a UAM | distance flying [CBDN]. For this battery charging schedule, a UAM | |||
| end system can communicate with an infrastructure node (e.g., IP-RSU) | end system can communicate with an infrastructure node (e.g., IP-RSU) | |||
| toward a cloud server via V2I communications. This cloud server can | toward a cloud server via V2I communications. This cloud server can | |||
| coordinate the battery charging schedules of multiple UAM end systems | coordinate the battery charging schedules of multiple UAM end systems | |||
| for their efficient navigation path, considering flight time from | for their efficient navigation path, considering flight time from | |||
| their current position to a battery charging station, waiting time in | their current position to a battery charging station, waiting time in | |||
| a waiting queue at the station, and battery charging time at the | a waiting queue at the station, and battery charging time at the | |||
| station. | station. | |||
| The existing IPv6 protocol must be augmented through protocol changes | In some scenarios such as vehicles moving in highways or staying in | |||
| in order to support wireless multihop V2I communications in a highway | parking lots, a V2V2I network is necessary for vehicles to access the | |||
| where RSUs are sparsely deployed, so a vehicle can reach the wireless | Internet since some vehicles may not be covered by an RSU. For those | |||
| coverage of an RSU through the multihop data forwarding of | vehicles, a few relay vehicles can help to build the Internet access. | |||
| intermediate vehicles. Thus, IPv6 needs to be extended for multihop | For the nested NEMO described in [RFC4888], hosts inside a vehicle | |||
| V2I communications. | shown in Figure 3 for the case of V2V2I may have the same issue in | |||
| the nested NEMO scenario. | ||||
| To better support these use cases, the existing IPv6 protocol must be | ||||
| augmented either through protocol changes or by including a new | ||||
| adaptation layer in the architecture that efficiently maps IPv6 to a | ||||
| diversity of link layer technologies. Augmentation is necessary to | ||||
| support wireless multihop V2I communications in a highway where RSUs | ||||
| are sparsely deployed, so a vehicle can reach the wireless coverage | ||||
| of an RSU through the multihop data forwarding of intermediate | ||||
| vehicles as packet forwarders. Thus, IPv6 needs to be extended for | ||||
| multihop V2I communications. | ||||
| To support applications of these V2I use cases, the required | To support applications of these V2I use cases, the required | |||
| functions of IPv6 include IPv6-based packet exchange, transport-layer | functions of IPv6 include IPv6 communication enablement with | |||
| session continuity, and secure, safe communication between a vehicle | neighborhood discovery and IPv6 address management, reachability with | |||
| and an infrastructure node (e.g., IP-RSU) in the vehicular network. | adapted network models and routing methods, transport-layer session | |||
| continuity, and secure, safe communication between a vehicle and an | ||||
| infrastructure node (e.g., IP-RSU) in the vehicular network. | ||||
| 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. | |||
| A pedestrian protection service, such as Safety-Aware Navigation | A pedestrian protection service, such as Safety-Aware Navigation | |||
| Application (SANA) [SANA], using V2I2P networking can reduce the | Application (SANA) [SANA], using V2I2P networking can reduce the | |||
| collision of a vehicle and a pedestrian carrying a smartphone | collision of a vehicle and a pedestrian carrying a smartphone | |||
| equipped with a network device for wireless communication (e.g., Wi- | equipped with a network device for wireless communication (e.g., Wi- | |||
| skipping to change at page 11, line 42 ¶ | skipping to change at page 12, line 32 ¶ | |||
| with each other via an IP-RSU. An edge computing device behind the | with each other via an IP-RSU. An edge computing device behind the | |||
| IP-RSU can collect the mobility information from vehicles and | IP-RSU can collect the mobility information from vehicles and | |||
| 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. Note that | |||
| it is true that a pedestrian or a cyclist may have a higher risk of | ||||
| being hit by a vehicle if they are not with a smartphone in the | ||||
| current setting. For this case, other human sensing technologies | ||||
| (e.g., moving object detection in images and wireless signal-based | ||||
| human movement detection [LIFS] [DFC]) can be used to provide the | ||||
| motion information of them to vehicles. A vehicle by V2V2I | ||||
| networking can obtain the motion information of a vulnerable road | ||||
| user via an IP-RSU that either employs or connects to a human sensing | ||||
| technology. | ||||
| The existing IPv6 protocol must be augmented through protocol changes | The existing IPv6 protocol must be augmented through protocol changes | |||
| in order to support wireless multihop V2X or V2I2X communications in | in order to support wireless multihop V2X or V2I2X communications in | |||
| an urban road network where RSUs are deployed at intersections, so a | an urban road network where RSUs are deployed at intersections, so a | |||
| vehicle (or a pedestrian's smartphone) can reach the wireless | vehicle (or a pedestrian's smartphone) can reach the wireless | |||
| coverage of an RSU through the multihop data forwarding of | coverage of an RSU through the multihop data forwarding of | |||
| intermediate vehicles (or pedestrians' smartphones) as packet | intermediate vehicles (or pedestrians' smartphones) as packet | |||
| forwarders. Thus, IPv6 needs to be extended for multihop V2X or | forwarders. Thus, IPv6 needs to be extended for multihop V2X or | |||
| V2I2X communications. | V2I2X communications. | |||
| skipping to change at page 13, line 8 ¶ | skipping to change at page 14, line 8 ¶ | |||
| This section describes the context for vehicular networks supporting | This section describes the context for vehicular networks supporting | |||
| V2V, V2I, and V2X communications. It describes an internal network | V2V, V2I, and V2X communications. It describes an internal network | |||
| within a vehicle or an edge network (called EN). It explains not | within a vehicle or an edge network (called EN). It explains not | |||
| only the internetworking between the internal networks of a vehicle | only the internetworking between the internal networks of a vehicle | |||
| and an EN via wireless links, but also the internetworking between | and an EN via wireless links, but also the internetworking between | |||
| the internal networks of two vehicles via wireless links. | the internal networks of two vehicles via wireless links. | |||
| Traffic Control Center in Vehicular Cloud | Traffic Control Center in Vehicular Cloud | |||
| ******************************************* | ******************************************* | |||
| +-------------+ * * | +-------------+ * * | |||
| |Corresponding| * +-----------------+ * | |Correspondent| * +-----------------+ * | |||
| | Node |<->* | Mobility Anchor | * | | Node |<->* | Mobility Anchor | * | |||
| +-------------+ * +-----------------+ * | +-------------+ * +-----------------+ * | |||
| * ^ * | * ^ * | |||
| * | * | * | * | |||
| * v * | * v * | |||
| ******************************************* | ******************************************* | |||
| ^ ^ ^ | ^ ^ ^ | |||
| | | | | | | | | |||
| | | | | | | | | |||
| v v v | v v v | |||
| skipping to change at page 14, line 8 ¶ | skipping to change at page 15, line 8 ¶ | |||
| V2V in a road network. The vehicular network architecture contains | V2V in a road network. The vehicular network architecture contains | |||
| vehicles (including IP-OBU), IP-RSUs, Mobility Anchor, Traffic | vehicles (including IP-OBU), IP-RSUs, Mobility Anchor, Traffic | |||
| Control Center, and Vehicular Cloud as components. These components | Control Center, and Vehicular Cloud as components. These components | |||
| are not mandatory, and they can be deployed into vehicular networks | are not mandatory, and they can be deployed into vehicular networks | |||
| in various ways. Some of them (e.g., Mobility Anchor, Traffic | in various ways. Some of them (e.g., Mobility Anchor, Traffic | |||
| Control Center, and Vehicular Cloud) may not be needed for the | Control Center, and Vehicular Cloud) may not be needed for the | |||
| vehicular networks according to target use cases in Section 3. | vehicular networks according to target use cases in Section 3. | |||
| Existing network architectures, such as the network architectures of | Existing network architectures, such as the network architectures of | |||
| PMIPv6 [RFC5213], RPL (IPv6 Routing Protocol for Low-Power and Lossy | PMIPv6 [RFC5213], RPL (IPv6 Routing Protocol for Low-Power and Lossy | |||
| Networks) [RFC6550], and OMNI (Overlay Multilink Network Interface) | Networks) [RFC6550], and AERO/OMNI | |||
| [I-D.templin-6man-omni], can be extended to a vehicular network | [I-D.templin-6man-aero][I-D.templin-6man-omni], can be extended to a | |||
| architecture for multihop V2V, V2I, and V2X, as shown in Figure 1. | vehicular network architecture for multihop V2V, V2I, and V2X, as | |||
| Refer to Appendix B for the detailed discussion on multihop V2X | shown in Figure 1. Refer to Appendix B for the detailed discussion | |||
| networking by RPL and OMNI. Also, refer to Appendix A for the | on multihop V2X networking by RPL and OMNI. Also, refer to | |||
| description of how OMNI can support the use of multiple radio | Appendix A for the description of how OMNI is designed to support the | |||
| technologies in V2X. | use of multiple radio technologies in V2X. | |||
| 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. | |||
| 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 IP- | ||||
| RSUs. | ||||
| In Figure 1, three IP-RSUs (IP-RSU1, IP-RSU2, and IP-RSU3) are | In Figure 1, three IP-RSUs (IP-RSU1, IP-RSU2, and IP-RSU3) are | |||
| deployed in the road network and are connected with each other | deployed in the road network and are connected with each other | |||
| through the wired networks (e.g., Ethernet). A Traffic Control | through the wired networks (e.g., Ethernet). A Traffic Control | |||
| Center (TCC) is connected to the Vehicular Cloud for the management | Center (TCC) is connected to the Vehicular Cloud for the management | |||
| of IP-RSUs and vehicles in the road network. A Mobility Anchor (MA) | of IP-RSUs and vehicles in the road network. A Mobility Anchor (MA) | |||
| may be located in the TCC as a mobility management controller. | may be located in the TCC as a mobility management controller. | |||
| Vehicle2, Vehicle3, and Vehicle4 are wirelessly connected to IP-RSU1, | Vehicle2, Vehicle3, and Vehicle4 are wirelessly connected to IP-RSU1, | |||
| IP-RSU2, and IP-RSU3, respectively. The three wireless networks of | IP-RSU2, and IP-RSU3, respectively. The three wireless networks of | |||
| IP-RSU1, IP-RSU2, and IP-RSU3 can belong to three different subnets | IP-RSU1, IP-RSU2, and IP-RSU3 can belong to three different subnets | |||
| (i.e., Subnet1, Subnet2, and Subnet3), respectively. Those three | (i.e., Subnet1, Subnet2, and Subnet3), respectively. Those three | |||
| subnets use three different prefixes (i.e., Prefix1, Prefix2, and | subnets use three different prefixes (i.e., Prefix1, Prefix2, and | |||
| Prefix3). | Prefix3). | |||
| Multiple vehicles under the coverage of an RSU share a prefix just as | Multiple vehicles under the coverage of an RSU share a prefix just as | |||
| mobile nodes share a prefix of a Wi-Fi access point in a wireless | mobile nodes share a prefix of a Wi-Fi access point in a wireless | |||
| LAN. This is a natural characteristic in infrastructure-based | LAN. This is a natural characteristic in infrastructure-based | |||
| wireless networks. For example, in Figure 1, two vehicles (i.e., | wireless networks. For example, in Figure 1, two vehicles (i.e., | |||
| Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6 | Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6 | |||
| global addresses for V2I communication. Alternatively, mobile nodes | global addresses for V2I communication. Alternatively, mobile nodes | |||
| can employ a "Bring-Your-Own-Addresses (BYOA)" technique using their | can employ a "Bring-Your-Own-Addresses (BYOA)" (or "Bring-Your-Own- | |||
| own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless | Prefix (BYOP)") technique using their own IPv6 Unique Local Addresses | |||
| network, which does not require the messaging (e.g., Duplicate | (ULAs) [RFC4193] over the wireless network, which does not require | |||
| Address Detection (DAD)) of IPv6 Stateless Address Autoconfiguration | the messaging (e.g., Duplicate Address Detection (DAD)) of IPv6 | |||
| (SLAAC) [RFC4862]. | Stateless Address Autoconfiguration (SLAAC) [RFC4862]. | |||
| 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 28 ¶ | skipping to change at page 16, line 21 ¶ | |||
| 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. | subnet structure. | |||
| 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 correspondent node in the vehicular cloud, Vehicle2 can move | |||
| from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In | from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In | |||
| this case, a handover for Vehicle2 needs to be performed by either a | this case, a handover for Vehicle2 needs to be performed by either a | |||
| host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a | host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a | |||
| network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and | network-based mobility management scheme (e.g., PMIPv6 [RFC5213], | |||
| AERO [I-D.templin-6man-aero]). This document describes issues in | NEMO [RFC3963][RFC4885] [RFC4888], and AERO [I-D.templin-6man-aero]). | |||
| mobility management for vehicular networks in Section 5.2. | This document describes issues in mobility management for vehicular | |||
| networks in Section 5.2. | ||||
| 4.2. V2I-based Internetworking | 4.2. V2I-based Internetworking | |||
| This section discusses the internetworking between a vehicle's | This section discusses the internetworking between a vehicle's | |||
| internal network (i.e., moving network) and an EN's internal network | internal network (i.e., mobile network) and an EN's internal network | |||
| (i.e., fixed network) via V2I communication. The internal network of | (i.e., fixed network) via V2I communication. The internal network of | |||
| a vehicle is nowadays constructed with Ethernet by many automotive | a vehicle is nowadays constructed with Ethernet by many automotive | |||
| vendors [In-Car-Network]. Note that an EN can accommodate multiple | vendors [In-Car-Network]. Note that an EN can accommodate multiple | |||
| routers (or switches) and servers (e.g., ECDs, navigation server, and | routers (or switches) and servers (e.g., ECDs, navigation server, and | |||
| DNS server) in its internal network. | DNS server) in its internal network. | |||
| A vehicle's internal network often uses Ethernet to interconnect | A vehicle's internal network often uses Ethernet to interconnect | |||
| 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. Note that it is dangerous if the | |||
| internal network of a vehicle is controlled by a malicious party. To | ||||
| minimize this kind of risk, an reinforced identification and | ||||
| verification protocol shall be implemented. | ||||
| +-----------------+ | +-----------------+ | |||
| (*)<........>(*) +----->| 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 | | | |||
| | +-------+ +-------+ | | +-------+ +-------+ | | | +-------+ +-------+ | | +-------+ +-------+ | | |||
| | ^ ^ | | ^ ^ | | | ^ ^ | | ^ ^ | | |||
| skipping to change at page 16, line 38 ¶ | skipping to change at page 17, line 29 ¶ | |||
| | v | | v | | | v | | v | | |||
| | +-------+ +-------+ | | +-------+ +-------+ +-------+ | | | +-------+ +-------+ | | +-------+ +-------+ +-------+ | | |||
| | | Host2 | |Router1| | | |Router2| |Server1|...|ServerN| | | | | Host2 | |Router1| | | |Router2| |Server1|...|ServerN| | | |||
| | +-------+ +-------+ | | +-------+ +-------+ +-------+ | | | +-------+ +-------+ | | +-------+ +-------+ +-------+ | | |||
| | ^ ^ | | ^ ^ ^ | | | ^ ^ | | ^ ^ ^ | | |||
| | | | | | | | | | | | | | | | | | | | | |||
| | v v | | v v v | | | v v | | v v v | | |||
| | ---------------------------- | | ------------------------------- | | | ---------------------------- | | ------------------------------- | | |||
| | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | | | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | | |||
| +------------------------------+ +---------------------------------+ | +------------------------------+ +---------------------------------+ | |||
| Vehicle1 (Moving Network1) EN1 (Fixed Network1) | Vehicle1 (Mobile Network1) EN1 (Fixed Network1) | |||
| <----> Wired Link <....> Wireless Link (*) Antenna | <----> Wired Link <....> Wireless Link (*) Antenna | |||
| Figure 2: Internetworking between Vehicle and Edge Network | Figure 2: Internetworking between Vehicle and Edge Network | |||
| As shown in Figure 2, as internal networks, a vehicle's moving | As shown in Figure 2, as internal networks, a vehicle's mobile | |||
| 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 mobile 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 | mobile network's network prefix can be called a Mobile Network Prefix | |||
| (MNP) [RFC3963]. | (MNP) [RFC3963]. | |||
| Figure 2 also shows the internetworking between the vehicle's moving | Figure 2 also shows the internetworking between the vehicle's mobile | |||
| 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 | (Mobile 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 | |||
| 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 | |||
| V2I networking. Thus, a host (Host1) in Vehicle1 can communicate | V2I networking. Thus, a host (Host1) in Vehicle1 can communicate | |||
| with a server (Server1) in EN1 for a vehicular service through | with a server (Server1) in EN1 for a vehicular service through | |||
| Vehicle1's moving network, a wireless link between IP-OBU1 and IP- | Vehicle1's moving network, a wireless link between IP-OBU1 and IP- | |||
| skipping to change at page 18, line 13 ¶ | skipping to change at page 18, line 36 ¶ | |||
| protocol for the mutual knowledge of network parameters. | protocol for the mutual knowledge of network parameters. | |||
| As shown in Figure 2, the addresses used for IPv6 transmissions over | As shown in Figure 2, the addresses used for IPv6 transmissions over | |||
| the wireless link interfaces for IP-OBU and IP-RSU can be link-local | the wireless link interfaces for IP-OBU and IP-RSU can be link-local | |||
| IPv6 addresses, ULAs, or global IPv6 addresses. When global IPv6 | IPv6 addresses, ULAs, or global IPv6 addresses. When global IPv6 | |||
| addresses are used, wireless interface configuration and control | addresses are used, wireless interface configuration and control | |||
| overhead for DAD [RFC4862] and Multicast Listener Discovery (MLD) | overhead for DAD [RFC4862] and Multicast Listener Discovery (MLD) | |||
| [RFC2710][RFC3810] should be minimized to support V2I and V2X | [RFC2710][RFC3810] should be minimized to support V2I and V2X | |||
| communications for vehicles moving fast along roadways. | communications for vehicles moving fast along roadways. | |||
| Let us consider the upload/download time of a vehicle when it passes | Let us consider the upload/download time of a ground vehicle when it | |||
| through the wireless communication coverage of an IP-RSU. For a | passes through the wireless communication coverage of an IP-RSU. For | |||
| given typical setting where 1km is the maximum DSRC communication | a given typical setting where 1km is the maximum DSRC communication | |||
| range [DSRC] and 100km/h is the speed limit in highway, the dwelling | range [DSRC] and 100km/h is the speed limit in highway for ground | |||
| time can be calculated to be 72 seconds by dividing the diameter of | vehicles, the dwelling time can be calculated to be 72 seconds by | |||
| the 2km (i.e., two times of DSRC communication range where an IP-RSU | dividing the diameter of the 2km (i.e., two times of DSRC | |||
| is located in the center of the circle of wireless communication) by | communication range where an IP-RSU is located in the center of the | |||
| the speed limit of 100km/h (i.e., about 28m/s). For the 72 seconds, | circle of wireless communication) by the speed limit of 100km/h | |||
| a vehicle passing through the coverage of an IP-RSU can upload and | (i.e., about 28m/s). For the 72 seconds, a vehicle passing through | |||
| download data packets to/from the IP-RSU. | the coverage of an IP-RSU can upload and download data packets to/ | |||
| from the IP-RSU. For special cases such as emergency vehicles moving | ||||
| above the speed limit, the dwelling time is relatively shorter than | ||||
| that of other vehicles. For cases of airborne vehicles, considering | ||||
| a higher flying speed and a higher altitude, the dwelling time can be | ||||
| much shorter. | ||||
| 4.3. V2V-based Internetworking | 4.3. V2V-based Internetworking | |||
| This section discusses the internetworking between the moving | This section discusses the internetworking between the moving | |||
| networks of two neighboring vehicles via V2V communication. | networks of two neighboring vehicles via V2V communication. | |||
| (*)<..........>(*) | (*)<..........>(*) | |||
| (2001:DB8:1:1::/64) | | | (2001:DB8:1:1::/64) | | | |||
| +------------------------------+ +------------------------------+ | +------------------------------+ +------------------------------+ | |||
| | v | | v | | | v | | v | | |||
| skipping to change at page 19, line 28 ¶ | skipping to change at page 19, line 33 ¶ | |||
| | v | | v | | | v | | v | | |||
| | +-------+ +-------+ | | +-------+ +-------+ | | | +-------+ +-------+ | | +-------+ +-------+ | | |||
| | | Host2 | |Router1| | | |Router2| | Host4 | | | | | Host2 | |Router1| | | |Router2| | Host4 | | | |||
| | +-------+ +-------+ | | +-------+ +-------+ | | | +-------+ +-------+ | | +-------+ +-------+ | | |||
| | ^ ^ | | ^ ^ | | | ^ ^ | | ^ ^ | | |||
| | | | | | | | | | | | | | | | | | | |||
| | v v | | v v | | | v v | | v v | | |||
| | ---------------------------- | | ---------------------------- | | | ---------------------------- | | ---------------------------- | | |||
| | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | | | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | | |||
| +------------------------------+ +------------------------------+ | +------------------------------+ +------------------------------+ | |||
| Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) | Vehicle1 (Mobile Network1) Vehicle2 (Mobile Network2) | |||
| <----> Wired Link <....> Wireless Link (*) Antenna | <----> Wired Link <....> Wireless Link (*) Antenna | |||
| Figure 3: Internetworking between Two Vehicles | Figure 3: Internetworking between Two Vehicles | |||
| Figure 3 shows the internetworking between the moving networks of two | Figure 3 shows the internetworking between the mobile networks of two | |||
| neighboring vehicles. There exists an internal network (Moving | neighboring vehicles. There exists an internal network (Mobile | |||
| 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 (Mobile 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. Thus, a host (Host1) in Vehicle1 can communicate | |||
| with another host (Host3) in Vehicle2 for a vehicular service through | with another host (Host3) in Vehicle2 for a vehicular service through | |||
| Vehicle1's moving network, a wireless link between IP-OBU1 and IP- | Vehicle1's mobile network, a wireless link between IP-OBU1 and IP- | |||
| OBU2, and Vehicle2's moving network. | OBU2, and Vehicle2's mobile network. | |||
| As a V2V use case in Section 3.1, Figure 4 shows the linear network | As a V2V use case in Section 3.1, Figure 4 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 20, line 28 ¶ | skipping to change at page 20, line 33 ¶ | |||
| | | | | | | | | | | | | | | |||
| +-----------+ +-----------+ +-----------+ | +-----------+ +-----------+ +-----------+ | |||
| Vehicle1 Vehicle2 Vehicle3 | Vehicle1 Vehicle2 Vehicle3 | |||
| <----> Wired Link <....> Wireless Link ===> Moving Direction | <----> Wired Link <....> Wireless Link ===> Moving Direction | |||
| (*) Antenna | (*) Antenna | |||
| Figure 4: Multihop Internetworking between Two Vehicle Networks | Figure 4: Multihop Internetworking between Two Vehicle Networks | |||
| As shown in Figure 4, multihop internetworking is feasible among the | As shown in Figure 4, multihop internetworking is feasible among the | |||
| moving networks of three vehicles in the same VANET. For example, | mobile networks of three vehicles in the same VANET. For example, | |||
| Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via IP-OBU1 | Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via IP-OBU1 | |||
| in Vehicle1, IP-OBU2 in Vehicle2, and IP-OBU3 in Vehicle3 in the | in Vehicle1, IP-OBU2 in Vehicle2, and IP-OBU3 in Vehicle3 in the | |||
| VANET, as shown in the figure. | VANET, as shown in the figure. | |||
| In this section, the link between two vehicles is assumed to be | In this section, the link between two vehicles is assumed to be | |||
| stable for single-hop wireless communication regardless of the sight | stable for single-hop wireless communication regardless of the sight | |||
| relationship such as line of sight and non-line of sight, as shown in | relationship such as line of sight and non-line of sight, as shown in | |||
| Figure 3. Even in Figure 4, the three vehicles are connected to each | Figure 3. Even in Figure 4, the three vehicles are connected to each | |||
| other with a linear topology, however, multihop V2V communication can | other with a linear topology, however, multihop V2V communication can | |||
| accommodate any network topology (i.e., an arbitrary graph) over | accommodate any network topology (i.e., an arbitrary graph) over | |||
| skipping to change at page 21, line 30 ¶ | skipping to change at page 21, line 30 ¶ | |||
| Vehicle1 EN1 Vehicle3 | Vehicle1 EN1 Vehicle3 | |||
| <----> Wired Link <....> Wireless Link ===> Moving Direction | <----> Wired Link <....> Wireless Link ===> Moving Direction | |||
| (*) Antenna | (*) Antenna | |||
| Figure 5: Multihop Internetworking between Two Vehicle Networks | Figure 5: Multihop Internetworking between Two Vehicle Networks | |||
| via IP-RSU (V2I2V) | via IP-RSU (V2I2V) | |||
| As shown in Figure 5, multihop internetworking between two vehicles | As shown in Figure 5, multihop internetworking between two vehicles | |||
| is feasible via an infrastructure node (i.e., IP-RSU) with wireless | is feasible via an infrastructure node (i.e., IP-RSU) with wireless | |||
| connectivity among the moving networks of two vehicles and the fixed | connectivity among the mobile networks of two vehicles and the fixed | |||
| network of an edge network (denoted as EN1) in the same VANET. For | network of an edge network (denoted as EN1) in the same VANET. For | |||
| example, Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via | example, Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via | |||
| IP-OBU1 in Vehicle1, IP-RSU1 in EN1, and IP-OBU3 in Vehicle3 in the | IP-OBU1 in Vehicle1, IP-RSU1 in EN1, and IP-OBU3 in Vehicle3 in the | |||
| VANET, as shown in the figure. | VANET, as shown in the figure. | |||
| For the reliability required in V2V networking, the ND optimization | For the reliability required in V2V networking, the ND optimization | |||
| defined in MANET [RFC6130] [RFC7466] improves the classical IPv6 ND | defined in MANET [RFC6130] [RFC7466] improves the classical IPv6 ND | |||
| in terms of tracking neighbor information with up to two hops and | in terms of tracking neighbor information with up to two hops and | |||
| introducing several extensible Information Bases, which serves the | introducing several extensible Information Bases, which serves the | |||
| MANET routing protocols such as the difference versions of Optimized | MANET routing protocols such as the different versions of Optimized | |||
| Link State Routing Protocol (OLSR) [RFC3626] [RFC7181] [RFC7188] | Link State Routing Protocol (OLSR) [RFC3626] [RFC7181], Open Shortest | |||
| [RFC7722] [RFC7779] [RFC8218] and the Dynamic Link Exchange Protocol | Path First (OSPF) derivatives (e.g., [RFC5614]), and Dynamic Link | |||
| (DLEP) with its extensions [RFC8175] [RFC8629] [RFC8651] [RFC8703] | Exchange Protocol (DLEP) [RFC8175] with its extensions [RFC8629] | |||
| [RFC8757]. In short, the MANET ND mainly deals with maintaining | [RFC8757]. In short, the MANET ND mainly deals with maintaining | |||
| extended network neighbors. However, an ND protocol in vehicular | extended network neighbors to enhance the link reliability. However, | |||
| networks shall consider more about the geographical mobility | an ND protocol in vehicular networks shall consider more about the | |||
| information of vehicles as an important resource for serving various | geographical mobility information of vehicles as an important | |||
| purposes to improve the reliability, e.g., vehicle driving safety, | resource for serving various purposes to improve the reliability, | |||
| intelligent transportation implementations, and advanced mobility | e.g., vehicle driving safety, intelligent transportation | |||
| services. For a more reliable V2V networking, some redundancy | implementations, and advanced mobility services. For a more reliable | |||
| mechanisms should be provided in L3 in the case of the failure of L2. | V2V networking, some redundancy mechanisms should be provided in L3 | |||
| in cases of the failure of L2. For different use cases, the optimal | ||||
| solution to improve V2V networking reliability may vary. For | ||||
| example, a group of vehicles in platooning may have stabler neighbors | ||||
| than freely moving vehicles, as described in Section 3.1. | ||||
| 5. Problem Statement | 5. Problem Statement | |||
| In order to specify protocols using the architecture mentioned in | In order to specify protocols using the architecture mentioned in | |||
| Section 4.1, IPv6 core protocols have to be adapted to overcome | Section 4.1, IPv6 core protocols have to be adapted to overcome | |||
| certain challenging aspects of vehicular networking. Since the | certain challenging aspects of vehicular networking. Since the | |||
| vehicles are likely to be moving at great speed, protocol exchanges | vehicles are likely to be moving at great speed, protocol exchanges | |||
| need to be completed in a time relatively short compared to the | need to be completed in a relatively short time compared to the | |||
| lifetime of a link between a vehicle and an IP-RSU, or between two | lifetime of a link between a vehicle and an IP-RSU, or between two | |||
| vehicles. | vehicles. | |||
| For safe driving, vehicles need to exchange application messages | For safe driving, vehicles need to exchange application messages | |||
| every 0.5 second [NHTSA-ACAS-Report] to let drivers take an action to | every 0.5 second [NHTSA-ACAS-Report] to let drivers take an action to | |||
| avoid a dangerous situation (e.g., vehicle collision), so IPv6 | avoid a dangerous situation (e.g., vehicle collision), so IPv6 | |||
| protocol exchanges need to support this order of magnitude for | protocol exchanges need to support this order of magnitude for | |||
| application message exchanges. Also, considering the communication | application message exchanges. Also, considering the communication | |||
| range of DSRC (up to 1km) and 100km/h as the speed limit in highway, | range of DSRC (up to 1km) and 100km/h as the speed limit in highway, | |||
| the lifetime of a link between a vehicle and an IP-RSU is 72 seconds, | the lifetime of a link between a vehicle and an IP-RSU is in the | |||
| and the lifetime of a link between two vehicles is 36 seconds. Note | order of a minute (e.g., about 72 seconds), and the lifetime of a | |||
| that if two vehicles are moving in the opposite directions in a | link between two vehicles is about a half minute. Note that if two | |||
| roadway, the relative speed of this case is two times the relative | vehicles are moving in the opposite directions in a roadway, the | |||
| speed of a vehicle passing through an RSU. This relative speed leads | relative speed of this case is two times the relative speed of a | |||
| the half of the link lifetime between the vehicle and the IP-RSU. In | vehicle passing through an RSU. This relative speed leads the half | |||
| reality, the DSRC communication range is around 500m, so the link | of the link lifetime between the vehicle and the IP-RSU. In reality, | |||
| lifetime will be a half of the maximum time. The time constraint of | the DSRC communication range is around 500m, so the link lifetime | |||
| a wireless link between two nodes (e.g., vehicle and IP-RSU) needs to | will be a half of the maximum time. The time constraint of a | |||
| wireless link between two nodes (e.g., vehicle and IP-RSU) needs to | ||||
| be considered because it may affect the lifetime of a session | be considered because it may affect the lifetime of a session | |||
| involving the link. The lifetime of a session varies depending on | involving the link. The lifetime of a session varies depending on | |||
| the session's type such as a web surfing, voice call over IP, DNS | the session's type such as a web surfing, voice call over IP, DNS | |||
| query, and context-aware navigation (in Section 3.1). Regardless of | query, and context-aware navigation (in Section 3.1). Regardless of | |||
| a session's type, to guide all the IPv6 packets to their destination | a session's type, to guide all the IPv6 packets to their destination | |||
| host(s), IP mobility should be supported for the session. In a V2V | host(s), IP mobility should be supported for the session. In a V2V | |||
| scenario (e.g., context-aware navigation), the IPv6 packets of a | scenario (e.g., context-aware navigation), the IPv6 packets of a | |||
| vehicle should be delivered to relevant vehicles in an efficient way | vehicle should be delivered to relevant vehicles in an efficient way | |||
| (e.g., multicasting). With this observation, IPv6 protocol exchanges | (e.g., multicasting). With this observation, IPv6 protocol exchanges | |||
| need to be done as short as possible to support the message exchanges | need to be done as short as possible to support the message exchanges | |||
| skipping to change at page 23, line 23 ¶ | skipping to change at page 23, line 28 ¶ | |||
| 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 link types including point-to-point, | IPv6 ND is designed for link types including point-to-point, | |||
| multicast-capable (e.g., Ethernet) and Non-Broadcast Multiple Access | multicast-capable (e.g., Ethernet) and Non-Broadcast Multiple Access | |||
| (NBMA). It assumes the efficient and reliable support of multicast | (NBMA). It assumes the efficient and reliable support of multicast | |||
| and unicast from the link layer for various network operations such | and unicast from the link layer for various network operations such | |||
| as MAC Address Resolution (AR), DAD, MLD and Neighbor Unreachability | as MAC Address Resolution (AR), DAD, MLD and Neighbor Unreachability | |||
| Detection (NUD). | 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 IPv6 addresses to run | |||
| a link-local IPv6 address or a global IPv6 address, and run IPv6 ND. | 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 DAD packets during a vehicle's travel in a road network, | |||
| network, which can guarantee the uniqueness of a vehicle's global | which can guarantee the uniqueness of a vehicle's global IPv6 | |||
| IPv6 address. An efficient NUD is required to reduce the overhead of | address. An efficient NUD is required to reduce the overhead of the | |||
| the NUD packets during a vehicle's travel in a road network, which | NUD packets during a vehicle's travel in a road network, which can | |||
| can guarantee the accurate neighborhood information of a vehicle in | guarantee the accurate neighborhood information of a vehicle in terms | |||
| terms of adjacent vehicles and RSUs. | of adjacent vehicles and RSUs. | |||
| The legacy DAD assumes that a node with an IPv6 address can reach any | The legacy DAD assumes that a node with an IPv6 address can reach any | |||
| other node with the scope of its address at the time it claims its | other node with the scope of its address at the time it claims its | |||
| address, and can hear any future claim for that address by another | address, and can hear any future claim for that address by another | |||
| party within the scope of its address for the duration of the address | party within the scope of its address for the duration of the address | |||
| ownership. However, the partitioning and merging of VANETs makes | ownership. However, the partitioning and merging of VANETs makes | |||
| this assumption frequently invalid in vehicular networks. The | this assumption frequently invalid in vehicular networks. The | |||
| merging and partitioning of VANETs frequently occurs in vehicular | merging and partitioning of VANETs frequently occurs in vehicular | |||
| networks. This merging and partitioning should be considered for the | networks. This merging and partitioning should be considered for the | |||
| IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) | IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) | |||
| skipping to change at page 24, line 9 ¶ | skipping to change at page 24, line 14 ¶ | |||
| Registrar in RPL) to check the uniqueness of an IPv6 address that | Registrar in RPL) to check the uniqueness of an IPv6 address that | |||
| will be configured by a vehicle as DAD. Also, the partitioning of a | will be configured by a vehicle as DAD. Also, the partitioning of a | |||
| VANET may make vehicles with the same prefix be physically | VANET may make vehicles with the same prefix be physically | |||
| unreachable. An address lookup operation may be conducted by an MA | unreachable. An address lookup operation may be conducted by an MA | |||
| or IP-RSU (as Registrar in RPL) to check the existence of a vehicle | or IP-RSU (as Registrar in RPL) to check the existence of a vehicle | |||
| under the network coverage of the MA or IP-RSU as NUD. Thus, SLAAC | under the network coverage of the MA or IP-RSU as NUD. Thus, SLAAC | |||
| needs to prevent IPv6 address duplication due to the merging of | needs to prevent IPv6 address duplication due to the merging of | |||
| VANETs, and IPv6 ND needs to detect unreachable neighboring vehicles | VANETs, and IPv6 ND needs to detect unreachable neighboring vehicles | |||
| due to the partitioning of a VANET. According to the merging and | due to the partitioning of a VANET. According to the merging and | |||
| partitioning, a destination vehicle (as an IPv6 host) needs to be | partitioning, a destination vehicle (as an IPv6 host) needs to be | |||
| distinguished as either an on-link host or an off-link host even | distinguished as either an on-link host or a not-onlink host even | |||
| though the source vehicle can use the same prefix as the destination | though the source vehicle can use the same prefix as the destination | |||
| vehicle [I-D.ietf-intarea-ippl]. | vehicle [I-D.ietf-intarea-ippl]. | |||
| To efficiently prevent IPv6 address duplication due to the VANET | To efficiently prevent IPv6 address duplication due to the VANET | |||
| partitioning and merging from happening in vehicular networks, the | partitioning and merging from happening in vehicular networks, the | |||
| vehicular networks need to support a vehicular-network-wide DAD by | vehicular networks need to support a vehicular-network-wide DAD by | |||
| defining a scope that is compatible with the legacy DAD. In this | defining a scope that is compatible with the legacy DAD. In this | |||
| case, two vehicles can communicate with each other when there exists | case, two vehicles can communicate with each other when there exists | |||
| a communication path over VANET or a combination of VANETs and IP- | a communication path over VANET or a combination of VANETs and IP- | |||
| RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, | RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, | |||
| vehicles can assure that their IPv6 addresses are unique in the | vehicles can assure that their IPv6 addresses are unique in the | |||
| vehicular network whenever they are connected to the vehicular | vehicular network whenever they are connected to the vehicular | |||
| infrastructure or become disconnected from it in the form of VANET. | infrastructure or become disconnected from it in the form of VANET. | |||
| For vehicular networks with high mobility and density, the DAD needs | For vehicular networks with high mobility and density, DAD needs to | |||
| to be performed efficiently with minimum overhead so that the | be performed efficiently with minimum overhead so that the vehicles | |||
| vehicles can exchange driving safety messages (e.g., collision | can exchange driving safety messages (e.g., collision avoidance and | |||
| avoidance and accident notification) with each other with a short | accident notification) with each other with a short interval | |||
| interval suggested by NHTSA (National Highway Traffic Safety | suggested by NHTSA (National Highway Traffic Safety Administration) | |||
| Administration) [NHTSA-ACAS-Report]. Since the partitioning and | [NHTSA-ACAS-Report]. Since the partitioning and merging of vehicular | |||
| merging of vehicular networks may require re-perform the DAD process | networks may require re-perform DAD process repeatedly, the link | |||
| repeatedly, the link scope of vehicles may be limited to a small | scope of vehicles may be limited to a small area, which may delay the | |||
| area, which may delay the exchange of driving safety messages. | exchange of driving safety messages. Driving safety messages can | |||
| Driving safety messages can include a vehicle's mobility information | include a vehicle's mobility information (i.e., position, speed, | |||
| (i.e., position, speed, direction, and acceleration/deceleration) | direction, and acceleration/deceleration) that is critical to other | |||
| that is critical to other vehicles. The exchange interval of this | vehicles. The exchange interval of this message is recommended to be | |||
| message is recommended to be less than 0.5 second, which is required | less than 0.5 second, which is required for a driver to avoid an | |||
| for a driver to avoid an emergency situation, such as a rear-end | emergency situation, such as a rear-end crash. | |||
| crash. | ||||
| ND time-related parameters such as router lifetime and Neighbor | ND time-related parameters such as router lifetime and Neighbor | |||
| Advertisement (NA) interval need to be adjusted for vehicle speed and | Advertisement (NA) interval need to be adjusted for vehicle speed and | |||
| vehicle density. For example, the NA interval needs to be | vehicle density. For example, the NA interval needs to be | |||
| dynamically adjusted according to a vehicle's speed so that the | dynamically adjusted according to a vehicle's speed so that the | |||
| vehicle can maintain its neighboring vehicles in a stable way, | vehicle can maintain its neighboring vehicles in a stable way, | |||
| considering the collision probability with the NA messages sent by | considering the collision probability with the NA messages sent by | |||
| other vehicles. The ND time-related parameters can be an operational | other vehicles. The ND time-related parameters can be an operational | |||
| setting or an optimization point particularly for vehicular networks. | setting or an optimization point particularly for vehicular networks. | |||
| For IPv6-based safety applications (e.g., context-aware navigation, | For IPv6-based safety applications (e.g., context-aware navigation, | |||
| adaptive cruise control, and platooning) in vehicular networks, the | adaptive cruise control, and platooning) in vehicular networks, the | |||
| delay-bounded data delivery is critical. IPv6 ND needs to work to | delay-bounded data delivery is critical. IPv6 ND needs to work to | |||
| support those IPv6-based safety applications efficiently. | support those IPv6-based safety applications efficiently. | |||
| From the interoperability point of view, in IPv6-based vehicular | From the interoperability point of view, in IPv6-based vehicular | |||
| networking, IPv6 ND should have minimum changes with the legacy IPv6 | networking, IPv6 ND should have minimum changes with the legacy IPv6 | |||
| ND used in the Internet, including the DAD and NUD operations, so | ND used in the Internet, including DAD and NUD operations, so that | |||
| that IPv6-based vehicular networks can be seamlessly connected to | IPv6-based vehicular networks can be seamlessly connected to other | |||
| other intelligent transportation elements (e.g., traffic signals, | intelligent transportation elements (e.g., traffic signals, | |||
| pedestrian wearable devices, electric scooters, and bus stops) that | pedestrian wearable devices, electric scooters, and bus stops) that | |||
| use the standard IPv6 network settings. | use the standard IPv6 network settings. | |||
| 5.1.1. Link Model | 5.1.1. Link Model | |||
| A subnet model for a vehicular network needs to facilitate the | A subnet model for a vehicular network needs to facilitate the | |||
| communication between two vehicles with the same prefix regardless of | communication between two vehicles with the same prefix regardless of | |||
| the vehicular network topology as long as there exist bidirectional | the vehicular network topology as long as there exist bidirectional | |||
| E2E paths between them in the vehicular network including VANETs and | E2E paths between them in the vehicular network including VANETs and | |||
| IP-RSUs. This subnet model allows vehicles with the same prefix to | IP-RSUs. This subnet model allows vehicles with the same prefix to | |||
| skipping to change at page 25, line 40 ¶ | skipping to change at page 25, line 40 ¶ | |||
| IPv6 protocols work under certain assumptions that do not necessarily | IPv6 protocols work under certain assumptions that do not necessarily | |||
| hold for vehicular wireless access link types [VIP-WAVE][RFC5889]. | hold for vehicular wireless access link types [VIP-WAVE][RFC5889]. | |||
| For instance, some IPv6 protocols assume symmetry in the connectivity | For instance, some IPv6 protocols assume symmetry in the connectivity | |||
| among neighboring interfaces [RFC6250]. However, radio interference | among neighboring interfaces [RFC6250]. However, radio interference | |||
| and different levels of transmission power may cause asymmetric links | and different levels of transmission power may cause asymmetric links | |||
| to appear in vehicular wireless links. As a result, a new vehicular | to appear in vehicular wireless links. As a result, a new vehicular | |||
| link model needs to consider the asymmetry of dynamically changing | link model needs to consider the asymmetry of dynamically changing | |||
| vehicular wireless links. | vehicular wireless links. | |||
| 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, unique-local, | |||
| types of IPv6 addresses. In an IPv6 link, it is defined that all | and global types of IPv6 addresses. In an IPv6 link, it is defined | |||
| interfaces which are configured with the same subnet prefix and with | that all interfaces which are configured with the same subnet prefix | |||
| on-link bit set can communicate with each other on an IPv6 link. | and with on-link bit set can communicate with each other on an IPv6 | |||
| However, the vehicular link model needs to define the relationship | link. However, the vehicular link model needs to define the | |||
| between a link and a prefix, considering the dynamics of wireless | relationship between a link and a prefix, considering the dynamics of | |||
| links and the characteristics of VANET. | wireless links and the characteristics of VANET. | |||
| A VANET can have a single link between each vehicle pair within | A VANET can have a single link between each vehicle pair within | |||
| wireless communication range, as shown in Figure 4. When two | wireless communication range, as shown in Figure 4. When two | |||
| vehicles belong to the same VANET, but they are out of wireless | vehicles belong to the same VANET, but they are out of wireless | |||
| communication range, they cannot communicate directly with each | communication range, they cannot communicate directly with each | |||
| other. Suppose that a global-scope IPv6 prefix (or an IPv6 ULA | other. Suppose that a global-scope IPv6 prefix (or an IPv6 ULA | |||
| prefix) is assigned to VANETs in vehicular networks. Even though two | prefix) is assigned to VANETs in vehicular networks. Considering | |||
| vehicles in the same VANET configure their IPv6 addresses with the | that two vehicles in the same VANET configure their IPv6 addresses | |||
| same IPv6 prefix, they may not communicate with each other not in one | with the same IPv6 prefix, if they are not in one hop (that is, they | |||
| hop in the same VANET because of the multihop network connectivity | have the multihop network connectivity between them), then they may | |||
| between them. Thus, in this case, the concept of an on-link IPv6 | not be able to communicate with each other. Thus, in this case, the | |||
| prefix does not hold because two vehicles with the same on-link IPv6 | concept of an on-link IPv6 prefix does not hold because two vehicles | |||
| prefix cannot communicate directly with each other. Also, when two | with the same on-link IPv6 prefix cannot communicate directly with | |||
| vehicles are located in two different VANETs with the same IPv6 | each other. Also, when two vehicles are located in two different | |||
| prefix, they cannot communicate with each other. When these two | VANETs with the same IPv6 prefix, they cannot communicate with each | |||
| VANETs converge to one VANET, the two vehicles can communicate with | other. When these two VANETs converge to one VANET, the two vehicles | |||
| each other in a multihop fashion, for example, when they are Vehicle1 | can communicate with each other in a multihop fashion, for example, | |||
| and Vehicle3, as shown in Figure 4. | when they are Vehicle1 and Vehicle3, as shown in Figure 4. | |||
| From the previous observation, a vehicular link model should consider | From the previous observation, a vehicular link model should consider | |||
| the frequent partitioning and merging of VANETs due to vehicle | the frequent partitioning and merging of VANETs due to vehicle | |||
| mobility. Therefore, the vehicular link model needs to use an on- | mobility. Therefore, the vehicular link model needs to use an on- | |||
| link prefix and off-link prefix according to the network topology of | link prefix and not-onlink prefix according to the network topology | |||
| vehicles such as a one-hop reachable network and a multihop reachable | of vehicles such as a one-hop reachable network and a multihop | |||
| network (or partitioned networks). If the vehicles with the same | reachable network (or partitioned networks). If the vehicles with | |||
| prefix are reachable from each other in one hop, the prefix should be | the same prefix are reachable from each other in one hop, the prefix | |||
| on-link. On the other hand, if some of the vehicles with the same | should be on-link. On the other hand, if some of the vehicles with | |||
| prefix are not reachable from each other in one hop due to either the | the same prefix are not reachable from each other in one hop due to | |||
| multihop topology in the VANET or multiple partitions, the prefix | either the multihop topology in the VANET or multiple partitions, the | |||
| should be off-link. In most cases in vehicular networks, due to the | prefix should be not-onlink. In most cases in vehicular networks, | |||
| partitioning and merging of VANETs, and the multihop network topology | due to the partitioning and merging of VANETs, and the multihop | |||
| of VANETS, off-link prefixes will be used for vehicles as default. | network topology of VANETS, not-onlink prefixes will be used for | |||
| vehicles as default. | ||||
| The vehicular link model needs to support multihop routing in a | The vehicular link model needs to support multihop routing in a | |||
| connected VANET where the vehicles with the same global-scope IPv6 | connected VANET where the vehicles with the same global-scope IPv6 | |||
| prefix (or the same IPv6 ULA prefix) are connected in one hop or | prefix (or the same IPv6 ULA prefix) are connected in one hop or | |||
| multiple hops. It also needs to support the multihop routing in | multiple hops. It also needs to support the multihop routing in | |||
| multiple connected VANETs through infrastructure nodes (e.g., IP-RSU) | multiple connected VANETs through infrastructure nodes (e.g., IP-RSU) | |||
| where they are connected to the infrastructure. For example, in | where they are connected to the infrastructure. For example, in | |||
| Figure 1, suppose that Vehicle1, Vehicle2, and Vehicle3 are | Figure 1, suppose that Vehicle1, Vehicle2, and Vehicle3 are | |||
| configured with their IPv6 addresses based on the same global-scope | configured with their IPv6 addresses based on the same global-scope | |||
| IPv6 prefix. Vehicle1 and Vehicle3 can also communicate with each | IPv6 prefix. Vehicle1 and Vehicle3 can also communicate with each | |||
| skipping to change at page 27, line 31 ¶ | skipping to change at page 27, line 31 ¶ | |||
| an IPv6 address pair. However, the pseudonym handling is not | an IPv6 address pair. However, the pseudonym handling is not | |||
| implemented and tested yet for applications on IP-based vehicular | implemented and tested yet for applications on IP-based vehicular | |||
| networking. | networking. | |||
| In the ETSI standards, for the sake of security and privacy, an ITS | In the ETSI standards, for the sake of security and privacy, an ITS | |||
| station (e.g., vehicle) can use pseudonyms for its network interface | station (e.g., vehicle) can use pseudonyms for its network interface | |||
| identities (e.g., MAC address) and the corresponding IPv6 addresses | identities (e.g., MAC address) and the corresponding IPv6 addresses | |||
| [Identity-Management]. Whenever the network interface identifier | [Identity-Management]. Whenever the network interface identifier | |||
| changes, the IPv6 address based on the network interface identifier | changes, the IPv6 address based on the network interface identifier | |||
| needs to be updated, and the uniqueness of the address needs to be | needs to be updated, and the uniqueness of the address needs to be | |||
| checked through the DAD procedure. | checked through DAD procedure. | |||
| 5.1.3. Routing | 5.1.3. Routing | |||
| For multihop V2V communications in either a VANET or VANETs via IP- | For multihop V2V communications in either a VANET or VANETs via IP- | |||
| RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may | RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may | |||
| be required to support both unicast and multicast in the links of the | be required to support both unicast and multicast in the links of the | |||
| subnet with the same IPv6 prefix. However, it will be costly to run | subnet with the same IPv6 prefix. However, it will be costly to run | |||
| both vehicular ND and a vehicular ad hoc routing protocol in terms of | both vehicular ND and a vehicular ad hoc routing protocol in terms of | |||
| control traffic overhead [RFC9119]. | control traffic overhead [RFC9119]. | |||
| skipping to change at page 30, line 8 ¶ | skipping to change at page 30, line 8 ¶ | |||
| For example, as shown in Figure 1, when a vehicle (e.g., Vehicle2) is | For example, as shown in Figure 1, when a vehicle (e.g., Vehicle2) is | |||
| moving from the coverage of an IP-RSU (e.g., IP-RSU1) into the | moving from the coverage of an IP-RSU (e.g., IP-RSU1) into the | |||
| coverage of another IP-RSU (e.g., IP-RSU2) belonging to a different | coverage of another IP-RSU (e.g., IP-RSU2) belonging to a different | |||
| 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 domain, where the wireless | For a mobility management scheme in a domain, 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, DAD is not | |||
| not required. On the other hand, for a mobility management scheme | required. On the other hand, for a mobility management scheme with a | |||
| with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213]), DAD is | unique prefix per mobile node (e.g., PMIPv6 [RFC5213]), DAD is not | |||
| not required because the IPv6 address of a vehicle's external | required because the IPv6 address of a vehicle's external wireless | |||
| wireless interface is guaranteed to be unique. There is a tradeoff | interface is guaranteed to be unique. There is a tradeoff between | |||
| between the prefix usage efficiency and DAD overhead. Thus, the IPv6 | the prefix usage efficiency and DAD overhead. Thus, the IPv6 address | |||
| address autoconfiguration for vehicular networks needs to consider | autoconfiguration for vehicular networks needs to consider this | |||
| this tradeoff to support efficient mobility management. | tradeoff to support efficient mobility management. | |||
| Even though the SLAAC with classic ND costs a DAD during mobility | Even though the SLAAC with classic ND costs a DAD during mobility | |||
| management, the SLAAC with [RFC8505] does not cost a DAD. SLAAC for | management, the SLAAC with [RFC8505] and/or AERO/OMNI do not cost a | |||
| vehicular networks needs to consider the minimization of the cost of | DAD. SLAAC for vehicular networks needs to consider the minimization | |||
| DAD with the help of an infrastructure node (e.g., IP-RSU and MA). | of the cost of DAD with the help of an infrastructure node (e.g., IP- | |||
| Using an infrastructure prefix over VANET allows direct routability | RSU and MA). Using an infrastructure prefix over VANET allows direct | |||
| to the Internet through the multihop V2I toward an IP-RSU. On the | routability to the Internet through the multihop V2I toward an IP- | |||
| other hand, a BYOA does not allow such direct routability to the | RSU. On the other hand, a BYOA does not allow such direct | |||
| Internet since the BYOA is not topologically correct, that is, not | routability to the Internet since the BYOA is not topologically | |||
| routable in the Internet. In addition, a vehicle configured with a | correct, that is, not routable in the Internet. In addition, a | |||
| BYOA needs a tunnel home (e.g., IP-RSU) connected to the Internet, | vehicle configured with a BYOA needs a tunnel home (e.g., IP-RSU) | |||
| and the vehicle needs to know which neighboring vehicle is reachable | connected to the Internet, and the vehicle needs to know which | |||
| inside the VANET toward the tunnel home. There is nonnegligible | neighboring vehicle is reachable inside the VANET toward the tunnel | |||
| control overhead to set up and maintain routes to such a tunnel home | home. There is nonnegligible control overhead to set up and maintain | |||
| over the VANET. | routes to such a tunnel home [RFC4888] over the VANET. | |||
| For the case of a multihomed network, a vehicle can follow the first- | For the case of a multihomed network, a vehicle can follow the first- | |||
| hop router selection rule described in [RFC8028]. For example, an | hop router selection rule described in [RFC8028]. For example, an | |||
| IP-OBU inside a vehicle may connect to an IP-RSU that has multiple | IP-OBU inside a vehicle may connect to an IP-RSU that has multiple | |||
| routers behind. In this scenario, because the IP-OBU can have | routers behind. In this scenario, because the IP-OBU can have | |||
| multiple prefixes from those routers, the default router selection, | multiple prefixes from those routers, the default router selection, | |||
| source address selection, and packet redirect process should follow | source address selection, and packet redirect process should follow | |||
| the guidelines in [RFC8028]. That is, the vehicle should select its | the guidelines in [RFC8028]. That is, the vehicle should select its | |||
| default router for each prefix by preferring the router that | default router for each prefix by preferring the router that | |||
| advertised the prefix. | advertised the prefix. | |||
| Vehicles can use the TCC as their Home Network having a home agent | Vehicles can use the TCC as their Home Network having a home agent | |||
| for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213], | for mobility management as in MIPv6 [RFC6275], PMIPv6 [RFC5213], and | |||
| so the TCC (or an MA inside the TCC) maintains the mobility | NEMO [RFC3963], so the TCC (or an MA inside the TCC) maintains the | |||
| information of vehicles for location management. IP tunneling over | mobility information of vehicles for location management. Also, in | |||
| the wireless link should be avoided for performance efficiency. | vehicular networks, asymmetric links sometimes exist and must be | |||
| Also, in vehicular networks, asymmetric links sometimes exist and | considered for wireless communications such as V2V and V2I. | |||
| must be considered for wireless communications such as V2V and V2I. | ||||
| 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 30 ¶ | skipping to change at page 31, line 29 ¶ | |||
| only authenticated nodes (i.e., vehicle and infrastructure node) can | only authenticated nodes (i.e., vehicle and infrastructure node) can | |||
| participate in vehicular networks. Also, in-vehicle devices (e.g., | participate in vehicular networks. Also, in-vehicle devices (e.g., | |||
| ECU) and a driver/passenger's mobile devices (e.g., smartphone and | ECU) and a driver/passenger's mobile devices (e.g., smartphone and | |||
| tablet PC) in a vehicle need to communicate with other in-vehicle | tablet PC) in a vehicle need to communicate with other in-vehicle | |||
| devices and another driver/passenger's mobile devices in another | devices and another driver/passenger's mobile devices in another | |||
| vehicle, or other servers behind an IP-RSU in a secure way. Even | vehicle, or other servers behind an IP-RSU in a secure way. Even | |||
| though a vehicle is perfectly authenticated and legitimate, it may be | though a vehicle is perfectly authenticated and legitimate, it may be | |||
| hacked for running malicious applications to track and collect its | hacked for running malicious applications to track and collect its | |||
| and other vehicles' information. In this case, an attack mitigation | and other vehicles' information. In this case, an attack mitigation | |||
| process may be required to reduce the aftermath of malicious | process may be required to reduce the aftermath of malicious | |||
| behaviors. | behaviors. Note that when driver/passenger's mobile devices are | |||
| connected to a vehicle's internal network, the vehicle may be more | ||||
| vulnerable to possible attacks from external networks. | ||||
| For secure V2I communication, a secure channel (e.g., IPsec) between | For secure V2I communication, a secure channel (e.g., IPsec) between | |||
| a mobile router (i.e., IP-OBU) in a vehicle and a fixed router (i.e., | a mobile router (i.e., IP-OBU) in a vehicle and a fixed router (i.e., | |||
| IP-RSU) in an EN needs to be established, as shown in Figure 2 | IP-RSU) in an EN needs to be established, as shown in Figure 2 | |||
| [RFC4301][RFC4302] [RFC4303][RFC4308] [RFC7296]. Also, for secure | [RFC4301][RFC4302] [RFC4303][RFC4308] [RFC7296]. Also, for secure | |||
| V2V communication, a secure channel (e.g., IPsec) between a mobile | V2V communication, a secure channel (e.g., IPsec) between a mobile | |||
| router (i.e., IP-OBU) in a vehicle and a mobile router (i.e., IP-OBU) | router (i.e., IP-OBU) in a vehicle and a mobile router (i.e., IP-OBU) | |||
| in another vehicle needs to be established, as shown in Figure 3. | in another vehicle needs to be established, as shown in Figure 3. | |||
| For secure communication, an element in a vehicle (e.g., an in- | For secure communication, an element in a vehicle (e.g., an in- | |||
| vehicle device and a driver/passenger's mobile device) needs to | vehicle device and a driver/passenger's mobile device) needs to | |||
| establish a secure connection (e.g., TLS) with another element in | establish a secure connection (e.g., TLS) with another element in | |||
| another vehicle or another element in a vehicular cloud (e.g., a | another vehicle or another element in a vehicular cloud (e.g., a | |||
| server). IEEE 1609.2 [WAVE-1609.2] specifies security services for | server). IEEE 1609.2 [WAVE-1609.2] specifies security services for | |||
| applications and management messages, but this WAVE specification is | applications and management messages, but this WAVE specification is | |||
| optional. Thus, if the link layer does not support the security of a | optional. Thus, if the link layer does not support the security of a | |||
| WAVE frame, either the network layer or the transport layer needs to | WAVE frame, either the network layer or the transport layer needs to | |||
| support security services for the WAVE frames. | support security services for the WAVE frames. | |||
| 6.1. Security Threats in Neighbor Discovery | 6.1. Security Threats in Neighbor Discovery | |||
| For the classical IPv6 ND, the DAD is required to ensure the | For the classical IPv6 ND, DAD is required to ensure the uniqueness | |||
| uniqueness of the IPv6 address of a vehicle's wireless interface. | of the IPv6 address of a vehicle's wireless interface. This DAD can | |||
| This DAD can be used as a flooding attack that uses the DAD-related | be used as a flooding attack that uses the DAD-related ND packets | |||
| ND packets disseminated over the VANET or vehicular networks. | disseminated over the VANET or vehicular networks. [RFC6959] | |||
| [RFC6959] introduces threats enabled by IP source address spoofing. | introduces threats enabled by IP source address spoofing. This | |||
| This possibility indicates that vehicles and IP-RSUs need to filter | possibility indicates that vehicles and IP-RSUs need to filter out | |||
| out suspicious ND traffic in advance. [RFC8928] introduces a | suspicious ND traffic in advance. [RFC8928] introduces a mechanism | |||
| mechanism that protects the ownership of an address for 6loWPAN ND | that protects the ownership of an address for 6loWPAN ND from address | |||
| from address theft and impersonation attacks. Based on the SEND | theft and impersonation attacks. Based on the SEND [RFC3971] | |||
| [RFC3971] mechanism, the authentication for routers (i.e., IP-RSUs) | mechanism, the authentication for routers (i.e., IP-RSUs) can be | |||
| can be conducted by only selecting an IP-RSU that has a certification | conducted by only selecting an IP-RSU that has a certification path | |||
| path toward trusted parties. For authenticating other vehicles, the | toward trusted parties. For authenticating other vehicles, the | |||
| cryptographically generated address (CGA) can be used to verify the | cryptographically generated address (CGA) can be used to verify the | |||
| true owner of a received ND message, which requires to use the CGA ND | true owner of a received ND message, which requires to use the CGA ND | |||
| option in the ND protocols. For a general protection of the ND | option in the ND protocols. For a general protection of the ND | |||
| mechanism, the RSA Signature ND option can also be used to protect | mechanism, the RSA Signature ND option can also be used to protect | |||
| the integrity of the messages by public key signatures. For a more | the integrity of the messages by public key signatures. For a more | |||
| advanced authentication mechanism, a distributed blockchain-based | advanced authentication mechanism, a distributed blockchain-based | |||
| approach [Vehicular-BlockChain] can be used. However, for a scenario | approach [Vehicular-BlockChain] can be used. However, for a scenario | |||
| where a trustable router or an authentication path cannot be | where a trustable router or an authentication path cannot be | |||
| obtained, it is desirable to find a solution in which vehicles and | obtained, it is desirable to find a solution in which vehicles and | |||
| infrastructures can authenticate each other without any support from | infrastructures can authenticate each other without any support from | |||
| skipping to change at page 33, line 7 ¶ | skipping to change at page 33, line 7 ¶ | |||
| 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 safe driving applications (e.g., context-aware | hackers. For safe driving applications (e.g., context-aware | |||
| navigation, cooperative adaptive cruise control, and platooning), as | navigation, cooperative adaptive cruise control, and platooning), as | |||
| explained in Section 3.1, the cooperative action among vehicles is | explained in Section 3.1, the cooperative action 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) for disturbing safe driving. | (e.g., location, speed, and direction) for disturbing safe driving. | |||
| For example, a Sybil attack, which tries to confuse a vehicle with | For example, a Sybil attack, which tries to confuse a vehicle with | |||
| multiple false identities, may disturb a vehicle from taking a safe | multiple false identities, may disturb a vehicle from taking a safe | |||
| maneuver. | maneuver. Since cyber security issues in vehicular networks may | |||
| cause physical vehicle safety issues, it may be necessary to consider | ||||
| those physical security concerns when designing protocols in IPWAVE. | ||||
| To identify malicious vehicles among vehicles, an authentication | To identify malicious vehicles among vehicles, an authentication | |||
| method may be required. A Vehicle Identification Number (VIN) and a | method may be required. A Vehicle Identification Number (VIN) and a | |||
| user certificate (e.g., X.509 certificate [RFC5280]) along with an | user certificate (e.g., X.509 certificate [RFC5280]) along with an | |||
| in-vehicle device's identifier generation can be used to efficiently | in-vehicle device's identifier generation can be used to efficiently | |||
| authenticate a vehicle or its driver (having a user certificate) | authenticate a vehicle or its driver (having a user certificate) | |||
| through a road infrastructure node (e.g., IP-RSU) connected to an | through a road infrastructure node (e.g., IP-RSU) connected to an | |||
| authentication server in the vehicular cloud. This authentication | authentication server in the vehicular cloud. This authentication | |||
| can be used to identify the vehicle that will communicate with an | can be used to identify the vehicle that will communicate with an | |||
| infrastructure node or another vehicle. In the case where a vehicle | infrastructure node or another vehicle. In the case where a vehicle | |||
| skipping to change at page 34, line 45 ¶ | skipping to change at page 35, line 19 ¶ | |||
| periodically updates its MAC address and its IPv6 address needs to be | periodically updates its MAC address and its IPv6 address needs to be | |||
| updated accordingly by the MAC address change [RFC4086][RFC8981]. | updated accordingly by the MAC address change [RFC4086][RFC8981]. | |||
| Such an update of the MAC and IPv6 addresses should not interrupt the | Such an update of the MAC and IPv6 addresses should not interrupt the | |||
| E2E communications between two vehicles (or between a vehicle and an | E2E communications between two vehicles (or between a vehicle and an | |||
| IP-RSU) for a long-living transport-layer session. However, if this | IP-RSU) for a long-living transport-layer session. However, if this | |||
| pseudonym is performed without strong E2E confidentiality (using | pseudonym is performed without strong E2E confidentiality (using | |||
| either IPsec or TLS), there will be no privacy benefit from changing | either IPsec or TLS), there will be no privacy benefit from changing | |||
| MAC and IPv6 addresses, because an adversary can observe the change | MAC and IPv6 addresses, because an adversary can observe the change | |||
| of the MAC and IPv6 addresses and track the vehicle with those | of the MAC and IPv6 addresses and track the vehicle with those | |||
| addresses. Thus, the MAC address pseudonym and the IPv6 address | addresses. Thus, the MAC address pseudonym and the IPv6 address | |||
| update should be performed with strong E2E confidentiality. | update should be performed with strong E2E confidentiality. Privacy | |||
| concerns for excessively collecting vehicle activities from roadway | ||||
| operators such as public transportation administrators and private | ||||
| contractors may also pose threats on violating privacy rights of | ||||
| vehicles. It might be interesting to find a solution from a | ||||
| technology point of view along with public policy development for the | ||||
| issue. | ||||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This document does not require any IANA actions. | This document does not require any IANA actions. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast | [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast | |||
| Listener Discovery (MLD) for IPv6", RFC 2710, | Listener Discovery (MLD) for IPv6", RFC 2710, | |||
| DOI 10.17487/RFC2710, October 1999, | DOI 10.17487/RFC2710, October 1999, | |||
| <https://www.rfc-editor.org/info/rfc2710>. | <https://www.rfc-editor.org/info/rfc2710>. | |||
| [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link | [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link | |||
| State Routing Protocol (OLSR)", RFC 3626, | State Routing Protocol (OLSR)", RFC 3626, | |||
| DOI 10.17487/RFC3626, October 2003, | DOI 10.17487/RFC3626, October 2003, | |||
| skipping to change at page 36, line 27 ¶ | skipping to change at page 37, line 10 ¶ | |||
| [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, | |||
| DOI 10.17487/RFC4861, September 2007, | DOI 10.17487/RFC4861, September 2007, | |||
| <https://www.rfc-editor.org/info/rfc4861>. | <https://www.rfc-editor.org/info/rfc4861>. | |||
| [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | |||
| Address Autoconfiguration", RFC 4862, | Address Autoconfiguration", RFC 4862, | |||
| DOI 10.17487/RFC4862, September 2007, | DOI 10.17487/RFC4862, September 2007, | |||
| <https://www.rfc-editor.org/info/rfc4862>. | <https://www.rfc-editor.org/info/rfc4862>. | |||
| [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support | ||||
| Terminology", RFC 4885, DOI 10.17487/RFC4885, July 2007, | ||||
| <https://www.rfc-editor.org/info/rfc4885>. | ||||
| [RFC4888] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network | ||||
| Mobility Route Optimization Problem Statement", RFC 4888, | ||||
| DOI 10.17487/RFC4888, July 2007, | ||||
| <https://www.rfc-editor.org/info/rfc4888>. | ||||
| [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., | [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., | |||
| Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", | Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", | |||
| RFC 5213, DOI 10.17487/RFC5213, August 2008, | RFC 5213, DOI 10.17487/RFC5213, August 2008, | |||
| <https://www.rfc-editor.org/info/rfc5213>. | <https://www.rfc-editor.org/info/rfc5213>. | |||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
| Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
| Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
| (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | |||
| <https://www.rfc-editor.org/info/rfc5280>. | <https://www.rfc-editor.org/info/rfc5280>. | |||
| [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, | [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, | |||
| Ed., "Control And Provisioning of Wireless Access Points | Ed., "Control And Provisioning of Wireless Access Points | |||
| (CAPWAP) Protocol Specification", RFC 5415, | (CAPWAP) Protocol Specification", RFC 5415, | |||
| DOI 10.17487/RFC5415, March 2009, | DOI 10.17487/RFC5415, March 2009, | |||
| <https://www.rfc-editor.org/info/rfc5415>. | <https://www.rfc-editor.org/info/rfc5415>. | |||
| [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) | ||||
| Extension of OSPF Using Connected Dominating Set (CDS) | ||||
| Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, | ||||
| <https://www.rfc-editor.org/info/rfc5614>. | ||||
| [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
| (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, | (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, | |||
| DOI 10.17487/RFC5881, June 2010, | DOI 10.17487/RFC5881, June 2010, | |||
| <https://www.rfc-editor.org/info/rfc5881>. | <https://www.rfc-editor.org/info/rfc5881>. | |||
| [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing | [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing | |||
| Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, | Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, | |||
| September 2010, <https://www.rfc-editor.org/info/rfc5889>. | September 2010, <https://www.rfc-editor.org/info/rfc5889>. | |||
| [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc | [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc | |||
| skipping to change at page 37, line 46 ¶ | skipping to change at page 38, line 46 ¶ | |||
| [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined | [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined | |||
| Networking: A Perspective from within a Service Provider | Networking: A Perspective from within a Service Provider | |||
| Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, | Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, | |||
| <https://www.rfc-editor.org/info/rfc7149>. | <https://www.rfc-editor.org/info/rfc7149>. | |||
| [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, | [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, | |||
| "The Optimized Link State Routing Protocol Version 2", | "The Optimized Link State Routing Protocol Version 2", | |||
| RFC 7181, DOI 10.17487/RFC7181, April 2014, | RFC 7181, DOI 10.17487/RFC7181, April 2014, | |||
| <https://www.rfc-editor.org/info/rfc7181>. | <https://www.rfc-editor.org/info/rfc7181>. | |||
| [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing | ||||
| Protocol Version 2 (OLSRv2) and MANET Neighborhood | ||||
| Discovery Protocol (NHDP) Extension TLVs", RFC 7188, | ||||
| DOI 10.17487/RFC7188, April 2014, | ||||
| <https://www.rfc-editor.org/info/rfc7188>. | ||||
| [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
| Kivinen, "Internet Key Exchange Protocol Version 2 | Kivinen, "Internet Key Exchange Protocol Version 2 | |||
| (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | |||
| 2014, <https://www.rfc-editor.org/info/rfc7296>. | 2014, <https://www.rfc-editor.org/info/rfc7296>. | |||
| [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. | [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. | |||
| Korhonen, "Requirements for Distributed Mobility | Korhonen, "Requirements for Distributed Mobility | |||
| Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, | Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, | |||
| <https://www.rfc-editor.org/info/rfc7333>. | <https://www.rfc-editor.org/info/rfc7333>. | |||
| skipping to change at page 38, line 26 ¶ | skipping to change at page 39, line 21 ¶ | |||
| CJ. Bernardos, "Distributed Mobility Management: Current | CJ. Bernardos, "Distributed Mobility Management: Current | |||
| Practices and Gap Analysis", RFC 7429, | Practices and Gap Analysis", RFC 7429, | |||
| DOI 10.17487/RFC7429, January 2015, | DOI 10.17487/RFC7429, January 2015, | |||
| <https://www.rfc-editor.org/info/rfc7429>. | <https://www.rfc-editor.org/info/rfc7429>. | |||
| [RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the | [RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the | |||
| Mobile Ad Hoc Network (MANET) Neighborhood Discovery | Mobile Ad Hoc Network (MANET) Neighborhood Discovery | |||
| Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March | Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March | |||
| 2015, <https://www.rfc-editor.org/info/rfc7466>. | 2015, <https://www.rfc-editor.org/info/rfc7466>. | |||
| [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for | ||||
| the Optimized Link State Routing Protocol Version 2 | ||||
| (OLSRv2)", RFC 7722, DOI 10.17487/RFC7722, December 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7722>. | ||||
| [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric | ||||
| Based on Packet Sequence Numbers for Optimized Link State | ||||
| Routing Version 2 (OLSRv2)", RFC 7779, | ||||
| DOI 10.17487/RFC7779, April 2016, | ||||
| <https://www.rfc-editor.org/info/rfc7779>. | ||||
| [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by | [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by | |||
| Hosts in a Multi-Prefix Network", RFC 8028, | Hosts in a Multi-Prefix Network", RFC 8028, | |||
| DOI 10.17487/RFC8028, November 2016, | DOI 10.17487/RFC8028, November 2016, | |||
| <https://www.rfc-editor.org/info/rfc8028>. | <https://www.rfc-editor.org/info/rfc8028>. | |||
| [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. | [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. | |||
| Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, | Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, | |||
| DOI 10.17487/RFC8175, June 2017, | DOI 10.17487/RFC8175, June 2017, | |||
| <https://www.rfc-editor.org/info/rfc8175>. | <https://www.rfc-editor.org/info/rfc8175>. | |||
| [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", STD 86, RFC 8200, | (IPv6) Specification", STD 86, RFC 8200, | |||
| DOI 10.17487/RFC8200, July 2017, | DOI 10.17487/RFC8200, July 2017, | |||
| <https://www.rfc-editor.org/info/rfc8200>. | <https://www.rfc-editor.org/info/rfc8200>. | |||
| [RFC8218] Yi, J. and B. Parrein, "Multipath Extension for the | ||||
| Optimized Link State Routing Protocol Version 2 (OLSRv2)", | ||||
| RFC 8218, DOI 10.17487/RFC8218, August 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8218>. | ||||
| [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
| <https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
| [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. | [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. | |||
| Perkins, "Registration Extensions for IPv6 over Low-Power | Perkins, "Registration Extensions for IPv6 over Low-Power | |||
| Wireless Personal Area Network (6LoWPAN) Neighbor | Wireless Personal Area Network (6LoWPAN) Neighbor | |||
| Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, | Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, | |||
| <https://www.rfc-editor.org/info/rfc8505>. | <https://www.rfc-editor.org/info/rfc8505>. | |||
| [RFC8629] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange | [RFC8629] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange | |||
| Protocol (DLEP) Multi-Hop Forwarding Extension", RFC 8629, | Protocol (DLEP) Multi-Hop Forwarding Extension", RFC 8629, | |||
| DOI 10.17487/RFC8629, July 2019, | DOI 10.17487/RFC8629, July 2019, | |||
| <https://www.rfc-editor.org/info/rfc8629>. | <https://www.rfc-editor.org/info/rfc8629>. | |||
| [RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link | ||||
| Exchange Protocol (DLEP) Control-Plane-Based Pause | ||||
| Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019, | ||||
| <https://www.rfc-editor.org/info/rfc8651>. | ||||
| [RFC8691] Benamar, N., Härri, J., Lee, J., and T. Ernst, "Basic | [RFC8691] Benamar, N., Härri, J., Lee, J., and T. Ernst, "Basic | |||
| Support for IPv6 Networks Operating Outside the Context of | Support for IPv6 Networks Operating Outside the Context of | |||
| a Basic Service Set over IEEE Std 802.11", RFC 8691, | a Basic Service Set over IEEE Std 802.11", RFC 8691, | |||
| DOI 10.17487/RFC8691, December 2019, | DOI 10.17487/RFC8691, December 2019, | |||
| <https://www.rfc-editor.org/info/rfc8691>. | <https://www.rfc-editor.org/info/rfc8691>. | |||
| [RFC8703] Taylor, R. and S. Ratliff, "Dynamic Link Exchange Protocol | ||||
| (DLEP) Link Identifier Extension", RFC 8703, | ||||
| DOI 10.17487/RFC8703, February 2020, | ||||
| <https://www.rfc-editor.org/info/rfc8703>. | ||||
| [RFC8757] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange | [RFC8757] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange | |||
| Protocol (DLEP) Latency Range Extension", RFC 8757, | Protocol (DLEP) Latency Range Extension", RFC 8757, | |||
| DOI 10.17487/RFC8757, March 2020, | DOI 10.17487/RFC8757, March 2020, | |||
| <https://www.rfc-editor.org/info/rfc8757>. | <https://www.rfc-editor.org/info/rfc8757>. | |||
| [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, | [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, | |||
| "Address-Protected Neighbor Discovery for Low-Power and | "Address-Protected Neighbor Discovery for Low-Power and | |||
| Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November | Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November | |||
| 2020, <https://www.rfc-editor.org/info/rfc8928>. | 2020, <https://www.rfc-editor.org/info/rfc8928>. | |||
| skipping to change at page 40, line 18 ¶ | skipping to change at page 40, line 34 ¶ | |||
| DOI 10.17487/RFC8981, February 2021, | DOI 10.17487/RFC8981, February 2021, | |||
| <https://www.rfc-editor.org/info/rfc8981>. | <https://www.rfc-editor.org/info/rfc8981>. | |||
| [RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. | [RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. | |||
| Zúñiga, "Multicast Considerations over IEEE 802 Wireless | Zúñiga, "Multicast Considerations over IEEE 802 Wireless | |||
| Media", RFC 9119, DOI 10.17487/RFC9119, October 2021, | Media", RFC 9119, DOI 10.17487/RFC9119, October 2021, | |||
| <https://www.rfc-editor.org/info/rfc9119>. | <https://www.rfc-editor.org/info/rfc9119>. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | ||||
| Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, | ||||
| <https://www.rfc-editor.org/info/rfc4821>. | ||||
| [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address | [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address | |||
| Validation Improvement (SAVI) Threat Scope", RFC 6959, | Validation Improvement (SAVI) Threat Scope", RFC 6959, | |||
| DOI 10.17487/RFC6959, May 2013, | DOI 10.17487/RFC6959, May 2013, | |||
| <https://www.rfc-editor.org/info/rfc6959>. | <https://www.rfc-editor.org/info/rfc6959>. | |||
| [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. | ||||
| Völker, "Packetization Layer Path MTU Discovery for | ||||
| Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, | ||||
| September 2020, <https://www.rfc-editor.org/info/rfc8899>. | ||||
| [I-D.ietf-intarea-ippl] | [I-D.ietf-intarea-ippl] | |||
| Nordmark, E., "IP over Intentionally Partially Partitioned | Nordmark, E., "IP over Intentionally Partially Partitioned | |||
| Links", Work in Progress, Internet-Draft, draft-ietf- | Links", Work in Progress, Internet-Draft, draft-ietf- | |||
| intarea-ippl-00, 30 March 2017, | intarea-ippl-00, 30 March 2017, | |||
| <https://www.ietf.org/archive/id/draft-ietf-intarea-ippl- | <https://www.ietf.org/archive/id/draft-ietf-intarea-ippl- | |||
| 00.txt>. | 00.txt>. | |||
| [I-D.ietf-lisp-rfc6830bis] | [I-D.ietf-lisp-rfc6830bis] | |||
| Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | |||
| Cabellos, "The Locator/ID Separation Protocol (LISP)", | Cabellos, "The Locator/ID Separation Protocol (LISP)", | |||
| Work in Progress, Internet-Draft, draft-ietf-lisp- | Work in Progress, Internet-Draft, draft-ietf-lisp- | |||
| rfc6830bis-36, 18 November 2020, | rfc6830bis-36, 18 November 2020, | |||
| <https://www.ietf.org/archive/id/draft-ietf-lisp- | <https://www.ietf.org/archive/id/draft-ietf-lisp- | |||
| rfc6830bis-36.txt>. | rfc6830bis-36.txt>. | |||
| [I-D.templin-6man-aero] | [I-D.templin-6man-aero] | |||
| Templin, F. L., "Automatic Extended Route Optimization | Templin, F. L., "Automatic Extended Route Optimization | |||
| (AERO)", Work in Progress, Internet-Draft, draft-templin- | (AERO)", Work in Progress, Internet-Draft, draft-templin- | |||
| 6man-aero-38, 31 December 2021, | 6man-aero-40, 7 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-templin-6man-aero- | <https://www.ietf.org/archive/id/draft-templin-6man-aero- | |||
| 38.txt>. | 40.txt>. | |||
| [I-D.templin-6man-omni] | [I-D.templin-6man-omni] | |||
| Templin, F. L. and T. Whyman, "Transmission of IP Packets | Templin, F. L., "Transmission of IP Packets over Overlay | |||
| over Overlay Multilink Network (OMNI) Interfaces", Work in | Multilink Network (OMNI) Interfaces", Work in Progress, | |||
| Progress, Internet-Draft, draft-templin-6man-omni-52, 31 | Internet-Draft, draft-templin-6man-omni-55, 7 March 2022, | |||
| December 2021, <https://www.ietf.org/archive/id/draft- | <https://www.ietf.org/archive/id/draft-templin-6man-omni- | |||
| templin-6man-omni-52.txt>. | 55.txt>. | |||
| [I-D.templin-ipwave-uam-its] | [I-D.templin-ipwave-uam-its] | |||
| Templin, F. L., "Urban Air Mobility Implications for | Templin, F. L., "Urban Air Mobility Implications for | |||
| Intelligent Transportation Systems", Work in Progress, | Intelligent Transportation Systems", Work in Progress, | |||
| Internet-Draft, draft-templin-ipwave-uam-its-04, 4 January | Internet-Draft, draft-templin-ipwave-uam-its-04, 4 January | |||
| 2021, <https://www.ietf.org/archive/id/draft-templin- | 2021, <https://www.ietf.org/archive/id/draft-templin- | |||
| ipwave-uam-its-04.txt>. | ipwave-uam-its-04.txt>. | |||
| [I-D.templin-intarea-parcels] | ||||
| Templin, F. L., "IP Parcels", Work in Progress, Internet- | ||||
| Draft, draft-templin-intarea-parcels-09, 10 February 2022, | ||||
| <https://www.ietf.org/archive/id/draft-templin-intarea- | ||||
| parcels-09.txt>. | ||||
| [I-D.ietf-dmm-fpc-cpdp] | [I-D.ietf-dmm-fpc-cpdp] | |||
| Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., | Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., | |||
| Moses, D., and C. E. Perkins, "Protocol for Forwarding | Moses, D., and C. E. Perkins, "Protocol for Forwarding | |||
| Policy Configuration (FPC) in DMM", Work in Progress, | Policy Configuration (FPC) in DMM", Work in Progress, | |||
| Internet-Draft, draft-ietf-dmm-fpc-cpdp-14, 22 September | Internet-Draft, draft-ietf-dmm-fpc-cpdp-14, 22 September | |||
| 2020, <https://www.ietf.org/archive/id/draft-ietf-dmm-fpc- | 2020, <https://www.ietf.org/archive/id/draft-ietf-dmm-fpc- | |||
| cpdp-14.txt>. | cpdp-14.txt>. | |||
| [I-D.thubert-6man-ipv6-over-wireless] | [I-D.thubert-6man-ipv6-over-wireless] | |||
| Thubert, P., "IPv6 Neighbor Discovery on Wireless | Thubert, P., "IPv6 Neighbor Discovery on Wireless | |||
| skipping to change at page 44, line 9 ¶ | skipping to change at page 44, line 50 ¶ | |||
| [Truck-Platooning] | [Truck-Platooning] | |||
| California Partners for Advanced Transportation Technology | California Partners for Advanced Transportation Technology | |||
| (PATH), "Automated Truck Platooning", Available: | (PATH), "Automated Truck Platooning", Available: | |||
| https://path.berkeley.edu/research/connected-and- | https://path.berkeley.edu/research/connected-and- | |||
| automated-vehicles/truck-platooning, 2022. | automated-vehicles/truck-platooning, 2022. | |||
| [FirstNet] U.S. National Telecommunications and Information | [FirstNet] U.S. National Telecommunications and Information | |||
| Administration (NTIA), "First Responder Network Authority | Administration (NTIA), "First Responder Network Authority | |||
| (FirstNet)", Available: https://www.firstnet.gov/, 2022. | (FirstNet)", Available: https://www.firstnet.gov/, 2022. | |||
| [PSCE] European Commission, "Public Safety Communications Europe | ||||
| (PSCE)", Available: https://www.psc-europe.eu/, 2022. | ||||
| [FirstNet-Report] | [FirstNet-Report] | |||
| First Responder Network Authority, "FY 2017: ANNUAL REPORT | First Responder Network Authority, "FY 2017: ANNUAL REPORT | |||
| TO CONGRESS, Advancing Public Safety Broadband | TO CONGRESS, Advancing Public Safety Broadband | |||
| Communications", FirstNet FY 2017, December 2017. | Communications", FirstNet FY 2017, December 2017. | |||
| [SignalGuru] | [SignalGuru] | |||
| Koukoumidis, E., Peh, L., and M. Martonosi, "SignalGuru: | Koukoumidis, E., Peh, L., and M. Martonosi, "SignalGuru: | |||
| Leveraging Mobile Phones for Collaborative Traffic Signal | Leveraging Mobile Phones for Collaborative Traffic Signal | |||
| Schedule Advisory", ACM MobiSys, June 2011. | Schedule Advisory", ACM MobiSys, June 2011. | |||
| skipping to change at page 44, line 41 ¶ | skipping to change at page 45, line 37 ¶ | |||
| [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. | |||
| [CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T. | [CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T. | |||
| Kim, "CBDN: Cloud-Based Drone Navigation for Efficient | Kim, "CBDN: Cloud-Based Drone Navigation for Efficient | |||
| Battery Charging in Drone Networks", IEEE Transactions on | Battery Charging in Drone Networks", IEEE Transactions on | |||
| Intelligent Transportation Systems, November 2019. | Intelligent Transportation Systems, November 2019. | |||
| [LIFS] Wang, J., Xiong, J., Jiang, H., Jamieson, K., Chen, X., | ||||
| Fang, D., and C. Wang, "Low Human-Effort, Device-Free | ||||
| Localization with Fine-Grained Subcarrier Information", | ||||
| IEEE Transactions on Mobile Computing, November 2018. | ||||
| [DFC] Jeong, J., Shen, Y., Kim, S., Choe, D., Lee, K., and Y. | ||||
| Kim, "DFC: Device-free human counting through WiFi fine- | ||||
| grained subcarrier information", IET Communications, | ||||
| January 2021. | ||||
| [In-Car-Network] | [In-Car-Network] | |||
| Lim, H., Volker, L., and D. Herrscher, "Challenges in a | Lim, H., Volker, L., and D. Herrscher, "Challenges in a | |||
| Future IP/Ethernet-based In-Car Network for Real-Time | Future IP/Ethernet-based In-Car Network for Real-Time | |||
| Applications", ACM/EDAC/IEEE Design Automation Conference | Applications", ACM/EDAC/IEEE Design Automation Conference | |||
| (DAC), June 2011. | (DAC), June 2011. | |||
| [Scrambler-Attack] | [Scrambler-Attack] | |||
| Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff, | Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff, | |||
| "The Scrambler Attack: A Robust Physical Layer Attack on | "The Scrambler Attack: A Robust Physical Layer Attack on | |||
| Location Privacy in Vehicular Networks", IEEE 2015 | Location Privacy in Vehicular Networks", IEEE 2015 | |||
| skipping to change at page 45, line 17 ¶ | skipping to change at page 46, line 24 ¶ | |||
| [Vehicular-BlockChain] | [Vehicular-BlockChain] | |||
| Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, | Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, | |||
| "BlockChain: A Distributed Solution to Automotive Security | "BlockChain: A Distributed Solution to Automotive Security | |||
| and Privacy", IEEE Communications Magazine, Vol. 55, No. | and Privacy", IEEE Communications Magazine, Vol. 55, No. | |||
| 12, December 2017. | 12, December 2017. | |||
| Appendix A. Support of Multiple Radio Technologies for V2V | Appendix A. Support of Multiple Radio Technologies for V2V | |||
| Vehicular networks may consist of multiple radio technologies such as | Vehicular networks may consist of multiple radio technologies such as | |||
| DSRC and 5G V2X. Although a Layer-2 solution can provide a support | DSRC and 5G V2X. Although a Layer-2 solution can provide support for | |||
| for multihop communications in vehicular networks, the scalability | multihop communications in vehicular networks, the scalability issue | |||
| issue related to multihop forwarding still remains when vehicles need | related to multihop forwarding still remains when vehicles need to | |||
| to disseminate or forward packets toward multihop-away destinations. | disseminate or forward packets toward multihop-away destinations. In | |||
| In addition, the IPv6-based approach for V2V as a network layer | addition, the IPv6-based approach for V2V as a network layer protocol | |||
| protocol can accommodate multiple radio technologies as MAC | can accommodate multiple radio technologies as MAC protocols, such as | |||
| protocols, such as DSRC and 5G V2X. Therefore, the existing IPv6 | DSRC and 5G V2X. Therefore, the existing IPv6 protocol can be | |||
| protocol can be augmented through the addition of a virtual interface | augmented through the addition of a virtual interface (e.g., OMNI | |||
| (e.g., Overlay Multilink Network (OMNI) Interface | [I-D.templin-6man-omni] and DLEP [RFC8175]) and/or protocol changes | |||
| [I-D.templin-6man-omni]) and/or protocol changes in order to support | in order to support both wireless single-hop/multihop V2V | |||
| both wireless single-hop/multihop V2V communications and multiple | communications and multiple radio technologies in vehicular networks. | |||
| radio technologies in vehicular networks. In such a way, vehicles | In such a way, vehicles can communicate with each other by V2V | |||
| can communicate with each other by V2V communications to share either | communications to share either an emergency situation or road hazard | |||
| an emergency situation or road hazard information in a highway having | information in a highway having multiple kinds of radio technologies. | |||
| multiple kinds of radio technologies. | ||||
| Appendix B. Support of Multihop V2X Networking | Appendix B. Support of Multihop V2X Networking | |||
| The multihop V2X networking can be supported by RPL (IPv6 Routing | The multihop V2X networking can be supported by RPL (IPv6 Routing | |||
| Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay | Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay | |||
| Multilink Network Interface (OMNI) [I-D.templin-6man-omni]. | Multilink Network Interface (OMNI) [I-D.templin-6man-omni]. | |||
| RPL defines an IPv6 routing protocol for low-power and lossy networks | RPL defines an IPv6 routing protocol for low-power and lossy networks | |||
| (LLN), mostly designed for home automation routing, building | (LLN), mostly designed for home automation routing, building | |||
| automation routing, industrial routing, and urban LLN routing. It | automation routing, industrial routing, and urban LLN routing. It | |||
| skipping to change at page 47, line 21 ¶ | skipping to change at page 48, line 16 ¶ | |||
| Overlay Multilink Network Interfaces that are virtual interfaces | Overlay Multilink Network Interfaces that are virtual interfaces | |||
| governing multiple physical network interfaces. OMNI supports | governing multiple physical network interfaces. OMNI supports | |||
| multihop V2V communication between vehicles in multiple forwarding | multihop V2V communication between vehicles in multiple forwarding | |||
| hops via intermediate vehicles with OMNI links. It also supports | hops via intermediate vehicles with OMNI links. It also supports | |||
| multihop V2I communication between a vehicle and an infrastructure | multihop V2I communication between a vehicle and an infrastructure | |||
| access point by multihop V2V communication. The OMNI interface | access point by multihop V2V communication. The OMNI interface | |||
| supports an NBMA link model where multihop V2V and V2I communications | supports an NBMA link model where multihop V2V and V2I communications | |||
| use each mobile node's ULAs without need for any DAD or MLD | use each mobile node's ULAs without need for any DAD or MLD | |||
| Messaging. | Messaging. | |||
| In OMNI protocol, each wireless media interface is configured with an | ||||
| IPv6 Unique Local Address (ULA) [RFC4193] that is assured unique | ||||
| within the vehicular network according to AERO/OMNI and [RFC5889]. | ||||
| The ULA supports both V2V and V2I multihop forwarding within the | ||||
| vehicular network (e.g., via a VANET routing protocol) while each | ||||
| vehicle can communicate with Internet correspondents using global | ||||
| IPv6 addresses via OMNI interface encapsulation over the wireless | ||||
| interface. | ||||
| For the control traffic overhead for running both vehicular ND and a | ||||
| VANET routing protocol, the AERO/OMNI approach may avoid this issue | ||||
| by using MANET routing protocols only (i.e., no multicast of IPv6 ND | ||||
| messaging) in the wireless underlay network while applying efficient | ||||
| unicast IPv6 ND messaging in the OMNI overlay on an as-needed basis | ||||
| for router discovery and NUD. This greatly reduces the overhead for | ||||
| VANET-wide multicasting while providing agile accommodation for | ||||
| dynamic topology changes. | ||||
| Appendix C. Support of Mobility Management for V2I | Appendix C. Support of Mobility Management for V2I | |||
| The seamless application communication between two vehicles or | The seamless application communication between two vehicles or | |||
| between a vehicle and an infrastructure node requires mobility | between a vehicle and an infrastructure node requires mobility | |||
| management in vehicular networks. The mobility management schemes | management in vehicular networks. The mobility management schemes | |||
| include a host-based mobility scheme, network-based mobility scheme, | include a host-based mobility scheme, network-based mobility scheme, | |||
| and software-defined networking scheme. | and software-defined networking scheme. | |||
| In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a | In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a | |||
| 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 | |||
| skipping to change at page 48, line 25 ¶ | skipping to change at page 49, line 37 ¶ | |||
| mobility management system, can manage the separation of data-plane | mobility management system, can manage the separation of data-plane | |||
| and control-plane in DMM. In SDN, the control plane and data plane | and control-plane in DMM. In SDN, the control plane and data plane | |||
| are separated for the efficient management of forwarding elements | are separated for the efficient management of forwarding elements | |||
| (e.g., switches and routers) where an SDN controller configures the | (e.g., switches and routers) where an SDN controller configures the | |||
| forwarding elements in a centralized way and they perform packet | forwarding elements in a centralized way and they perform packet | |||
| forwarding according to their forwarding tables that are configured | forwarding according to their forwarding tables that are configured | |||
| by the SDN controller. An MA as an SDN controller needs to | by the SDN controller. An MA as an SDN controller needs to | |||
| efficiently configure and monitor its IP-RSUs and vehicles for | efficiently configure and monitor its IP-RSUs and vehicles for | |||
| mobility management, location management, and security services. | mobility management, location management, and security services. | |||
| Appendix D. Acknowledgments | Appendix D. Support of MTU Diversity for IP-based Vehicular Networks | |||
| The wireless and/or wired-line links in paths between both mobile | ||||
| nodes and fixed network correspondents may configure a variety of | ||||
| Maximum Transmission Units (MTUs), where all IPv6 links are required | ||||
| to support a minimum MTU of 1280 octets and may support larger MTUs. | ||||
| Unfortunately, determining the path MTU (i.e., the minimum link MTU | ||||
| in the path) has proven to be inefficient and unreliable due to the | ||||
| uncertain nature of the loss-oriented ICMPv6 messaging service used | ||||
| for path MTU discovery. Recent developments have produced a more | ||||
| reliable path MTU determination service for TCP [RFC4821] and UDP | ||||
| [RFC8899] however the MTUs discovered are always limited by the most | ||||
| restrictive link MTU in the path (often 1500 octets or smaller). | ||||
| The AERO/OMNI service addresses the MTU issue by introducing a new | ||||
| layer in the Internet architecture known as the "OMNI Adaptation | ||||
| Layer (OAL)". The OAL allows end systems that configure an OMNI | ||||
| interface to utilize a full 65535 octet MTU by leveraging the IPv6 | ||||
| fragmentation and reassembly service during encapsulation to produce | ||||
| fragment sizes that are assured of traversing the path without loss | ||||
| due to a size restriction. (This allows end systems to send packets | ||||
| that are often much larger than the actual path MTU.) | ||||
| Performance studies over the course of many decades have proven that | ||||
| applications will see greater performance by sending smaller numbers | ||||
| of large packets (as opposed to larger numbers of small packets) even | ||||
| if fragmentation is needed. The OAL further supports even larger | ||||
| packet sizes through the IP Parcels construct | ||||
| [I-D.templin-intarea-parcels] which provides "packets-in-packet" | ||||
| encapsulation for a total size up to 4MB. Together, the OAL and IP | ||||
| Parcels will provide a revolutionary new capability for greater | ||||
| efficiency in both mobile and fixed networks. | ||||
| Appendix E. Acknowledgments | ||||
| This work was supported by Institute of Information & Communications | This work was supported by Institute of Information & Communications | |||
| Technology Planning & Evaluation (IITP) grant funded by the Korea | Technology Planning & Evaluation (IITP) grant funded by the Korea | |||
| MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based | MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based | |||
| Security Intelligence Technology Development for the Customized | Security Intelligence Technology Development for the Customized | |||
| Security Service Provisioning). | Security Service Provisioning). | |||
| This work was supported in part by the MSIT, Korea, under the ITRC | This work was supported in part by the MSIT, Korea, under the ITRC | |||
| (Information Technology Research Center) support program (IITP- | (Information Technology Research Center) support program (IITP- | |||
| 2021-2017-0-01633) supervised by the IITP. | 2021-2017-0-01633) supervised by the IITP. | |||
| skipping to change at page 49, line 5 ¶ | skipping to change at page 51, line 5 ¶ | |||
| Technology). | Technology). | |||
| This work was supported in part by the French research project | This work was supported in part by the French research project | |||
| DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded | DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded | |||
| by the European Commission I (636537-H2020). | by the European Commission I (636537-H2020). | |||
| This work was supported in part by the Cisco University Research | This work was supported in part by the Cisco University Research | |||
| Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal | Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal | |||
| Project FB0008. | Project FB0008. | |||
| Appendix E. Contributors | Appendix F. 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. 80 change blocks. | ||||
| 289 lines changed or deleted | 400 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||