idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Nov 2, 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VMI' is mentioned on line 555, but not defined == Missing Reference: 'ARO' is mentioned on line 657, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-19 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'ID-IPWAVE-PS') ** Downref: Normative reference to an Informational RFC: RFC 5889 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-09 == Outdated reference: A later version (-11) exists of draft-jeong-ipwave-vehicular-mobility-management-04 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong 3 Internet-Draft Y. Shen 4 Intended status: Standards Track Z. Xiang 5 Expires: May 6, 2021 Sungkyunkwan University 6 S. Cespedes 7 NIC Chile Research Labs 8 Nov 2, 2020 10 Vehicular Neighbor Discovery for IP-Based Vehicular Networks 11 draft-jeong-ipwave-vehicular-neighbor-discovery-10 13 Abstract 15 This document specifies a Vehicular Neighbor Discovery (VND) as an 16 extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular 17 networks. An optimized Address Registration and a multihop Duplicate 18 Address Detection (DAD) mechanism are performed for having operation 19 efficiency and also saving both wireless bandwidth and vehicle 20 energy. In addition, three new ND options for prefix discovery, 21 service discovery, and mobility information report are defined to 22 announce the network prefixes and services inside a vehicle (i.e., a 23 vehicle's internal network). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 6, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. ND Optimization . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Vehicular Network Architecture . . . . . . . . . . . . . . . 6 67 6. ND Extension for Prefix and Service Discovery . . . . . . . . 8 68 6.1. Vehicular Prefix Information Option . . . . . . . . . . . 8 69 6.2. Vehicular Service Information Option . . . . . . . . . . 9 70 6.3. Vehicular Mobility Information Option . . . . . . . . . . 10 71 6.4. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 11 72 6.5. Message Exchange Procedure for V2I Networking . . . . . . 12 73 7. Address Registration and Duplicate Address Detection . . . . 13 74 7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 14 75 7.2. Address Registration . . . . . . . . . . . . . . . . . . 14 76 7.3. Multihop Duplicate Address Detection . . . . . . . . . . 15 77 7.3.1. DAD without Intermediate Vehicle . . . . . . . . . . 15 78 7.3.2. DAD with one Intermediate Vehicle . . . . . . . . . . 17 79 7.3.3. DAD with multiple Intermediate Vehicles . . . . . . . 18 80 7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 19 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 85 10.2. Informative References . . . . . . . . . . . . . . . . . 21 86 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 87 discovery-09 . . . . . . . . . . . . . . . . . . . . 23 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 Vehicular Ad Hoc Networks (VANET) have been researched for 93 Intelligent Transportation System (ITS) such as driving safety, 94 efficient driving and entertainment. Considering the high-speed 95 mobility of vehicular network based on Dedicated Short-Range 96 Communications (DSRC) [DSRC-WAVE], IEEE has standardized IEEE 802.11p 98 [IEEE-802.11p] as a MAC protocol for vehicles in Wireless Access in 99 Vehicular Environments (WAVE). IEEE 802.11p was renamed IEEE 802.11 100 Outside the Context of a Basic Service Set (OCB) [IEEE-802.11-OCB] in 101 2012. IEEE has standardized a family standard suite of WAVE as IEEE 102 1609. This IEEE 1609 is considered as a key component in ITS. IEEE 103 1609 standards include IEEE 1609.0 [WAVE-1609.0], 1609.2 104 [WAVE-1609.2], 1609.3 [WAVE-1609.3], and 1609.4 [WAVE-1609.4] to 105 provide a low-latency and alternative network for vehicular 106 communications. What is more, IP-based vehicular networks 107 specialized as IP Wireless Access in Vehicular Environments (IPWAVE) 108 [ID-IPWAVE-PS] can enable many use cases over vehicle-to-vehicle 109 (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything 110 (V2X) communications. IETF has standardized an IPv6 packet delivery 111 protocol over IEEE 802.11-OCB [RFC8691]. 113 VANET features high mobility dynamics, asymmetric and lossy 114 connections, and moderate power constraint (e.g., electric cars and 115 unmanned aerial vehicles). Links among hosts and routers in VANET 116 can be considered as undetermined connectivities with constantly 117 changing neighbors described in [RFC5889]. IPv6 [RFC8200] is 118 selected as the network-layer protocol for Internet applications by 119 IEEE 1609.0 and 1609.3. However, the relatively long-time Neighbor 120 Discovery (ND) process in IPv6 [RFC4861] is not suitable in VANET 121 scenarios. 123 To support the interaction between vehicles or between vehicles and 124 Rode-Side Units (RSUs), this document specifies a Vehicular Neighbor 125 Discovery (VND) procedure as an extension of IPv6 ND for IP-based 126 vehicular networks. VND provides vehicles with an optimized Address 127 Registration and a multihop Duplicate Address Detection (DAD) 128 mechanism. In addition, an efficient mobility management scheme is 129 specified to support efficient V2V, V2I, and V2X communications. 130 Detailed statements of the mobility management are addressed in 131 [ID-IPWAVE-VMM] . 133 2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Terminology 141 This document uses the terminology described in [RFC4861], [RFC4862], 142 [RFC6775], and [RFC8691]. In addition, the following new terms are 143 defined as below: 145 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 146 [WAVE-1609.0]. 148 o Mobility Anchor (MA): A node that maintains IP addresses and 149 mobility information of vehicles in a road network to support the 150 address autoconfiguration and mobility management of them. It has 151 end-to-end connections with RSUs under its control. It maintains 152 a DAD Table recording the IP addresses of vehicles moving within 153 the communication coverage of its RSUs. 155 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 156 including compute nodes, storage nodes, and network nodes. 158 o Traffic Control Center (TCC): A node that maintains road 159 infrastructure information (e.g., RSUs, traffic signals, and loop 160 detectors), vehicular traffic statistics (e.g., average vehicle 161 speed and vehicle inter-arrival time per road segment), and 162 vehicle information (e.g., a vehicle's identifier, position, 163 direction, speed, and trajectory as a navigation path). TCC is 164 included in a vehicular cloud for vehicular networks and has MAs 165 under its management. 167 4. Overview 169 This document proposes an optimized ND with a more adaptive structure 170 for vehicular networks compared to [RFC4861] by considering dynamic 171 vehicle mobility and overhead of control message traffic in wireless 172 environments. Furthermore, prefix and service discovery can be 173 implemented as part of the ND's process along with an efficient 174 Address Registration procedure and a DAD mechanism for moving 175 vehicles. This document specifies a set of behaviors between 176 vehicles and RSUs to accomplish these goals. 178 4.1. Link Model 180 There is a relationship between a link and a network prefix along 181 with reachability scopes, such as link-local and global scopes. The 182 legacy IPv6 ND protocol [RFC4861] has the following link model. All 183 IPv6 nodes in the same on-link subnet, which use the same subnet 184 prefix with the on-link bit set, are reachable with each other by 185 one-hop links. The symmetry of the connectivity among the nodes is 186 assumed, that is, bidirectional connectivity between two on-link 187 nodes. However, a link model in vehicular networks (called vehicular 188 link model) should consider the asymmetry of the connectivity that 189 unidirectional links can exist due to interference in wireless 190 channels and the different levels of transmission power employed by 191 wireless network interfaces. 193 The on-link subnet can be constructed by one link (as a basic service 194 set) or multiple links (as an extended service set) called a multi- 195 link subnet [RFC6775]. In this multi-link subnet, an all-node- 196 multicasted packet is copied and related to other links by an ND 197 proxy. On the other hand, in vehicular networks having fast moving 198 vehicles, multiple links can share the same subnet prefix for 199 operation efficiency. For example, if two wireless links under two 200 adjacent RSUs are in the same subnet, a vehicle as an IPv6 host does 201 not need to reconfigure its IPv6 address during handover between 202 those RSUs. However, the packet relay by an RSU as an ND proxy is 203 not required because such a relay can cause a broadcast storm in the 204 extended subnet. Thus, in the multi-link subnet, all-node- 205 multicasting needs to be well-calibrated to either being confined to 206 multicasting in the current link or being disseminated to other links 207 in the same subnet. 209 In a connected multihop VANET, for efficient communication, vehicles 210 in the same link of an RSU can communicate directly with each other, 211 not through the serving RSU. This direct wireless communication is 212 similar to the direct wired communication in an on-link subnet using 213 Ethernet as a wired network. The vehicular link model needs to 214 accommodate both the ad-hoc communication between vehicles and 215 infrastructure communication between a vehicle and an RSU in an 216 efficient and flexible way. Therefore, the IPv6 ND should be 217 extended to accommodate the concept of a new IPv6 link model in 218 vehicular networks. 220 To support multi-link subnet, this specification employs the Shared- 221 Prefix model for prefix assignments. A Shared-Prefix model refers to 222 an addressing model where the prefix(es) are shared by more than one 223 node. In this document, we assume that in a specified subnet, all 224 interfaces of RSUs responding for prefix assignments to vehicles hold 225 the same prefix, which ensure vehicles obtain and maintain the same 226 prefix in this subnet scope. 228 4.2. ND Optimization 230 This document takes advantage of the optimized ND for Low-Power 231 Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular 232 environments have common parts with 6LoWPAN, such as the reduction of 233 unnecessary wireless traffic by multicasting and the energy saving in 234 battery. Note that vehicles tend to be electric vehicles whose 235 energy source is from their battery. 237 In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are 238 assumed to be asymmetric and unidirectional because of changing radio 239 environment and loss signal. The authors proposed an optimized IPv6 240 ND which greatly eliminates link-scope multicast to save energy by 241 constructing new options and a new scheme for address configurations. 242 Similarly, this document proposes an improved IPv6 ND by eliminating 243 many link-scope-multicast-based ND operations, such as DAD for IPv6 244 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Thus, this 245 document suggests an extension of IPv6 ND as vehicular ND tailored 246 for vehicular networks along with new ND options (e.g., prefix 247 discovery, service discovery, and mobility information options). 249 4.3. Design Goals 251 The vehicular ND in this document has the following design goals: 253 o To perform prefix and service discovery through ND procedure; 255 o To implement host-initiated refresh of Router Advertisement (RA) 256 and remove the necessity for routers to use periodic or 257 unsolicited multicast RA to find hosts; 259 o To replace Neighbor Unreachable Detection(NUD), create Neighbor 260 Cache Entries (NCE) for all registered vehicles in RSUs and MA by 261 appending Address Registration Option (ARO) in Neighbor 262 Solicitation (NS), Neighbor Advertisement (NA) messages; 264 o To support a multihop DAD by conveying ND messages received from 265 vehicles to MA to eliminate multicast storms and save energy; and 267 o To support multi-hop communication for vehicles outside the 268 coverage of RSUs to communicate with the serving RSU via a relay 269 neighbor. 271 5. Vehicular Network Architecture 273 A vehicular network architecture for V2I and V2V is illustrated in 274 Figure 1. Three RSUs are deployed along roadsides and are connected 275 to an MA through wired links. There are two subnets such as Subnet1 276 and Subnet2. The wireless links of RSU1 and RSU2 belong to the same 277 subnet named Subnet1, but the wireless link of RSU3 belongs to 278 another subnet named Subnet2. Vehicle2 is wirelessly connected to 279 RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 and RSU3, 280 respectively. Vehicles can directly communicate with each other 281 through V2V connection (e.g., Vehicle1 and Vehicle2) to share driving 282 information. In addition, vehicles not in the range of any RSU may 283 connect with RSU in multi-hop connection via relay vehicle (e.g., 284 Vehicle1 can contact RSU1 via Vehicle2). Vehicles are assumed to 285 start the connection to an RSU when they entered the coverage of the 286 RSU. 288 The document recommends a multi-link subnet involving multiple RSUs 289 as shown in Figure 1. This recommendation aims at the reduction of 290 the frequency with which vehicles have to change their IP address 291 during handover between two adjacent RSUs. To construct this multi- 292 link subnet, a Shared-Prefix model is proposed. That is, for RSUs in 293 the same subnet, the interfaces responsible for prefix assignment for 294 vehicles should hold the same prefix in their global address. This 295 also promises vehicles achieve the same prefix in this scope. When 296 they pass through RSUs in the same subnet, vehicles do not need to 297 perform the Address Registration and DAD again because they can use 298 their current IP address in the wireless coverage of the next RSU. 299 Moreover, this proposal accords with the assumption that nodes 300 belonging to the same IP prefix domain are able to communicate with 301 each other directly without the intervention of RSUs if they are 302 within the wireless communication range of each other. On the other 303 hand, if vehicles enter the wireless coverage of an RSU belonging to 304 another subnet with a different prefix, they repeat the Address 305 Registration and DAD procedure to update their IP address with the 306 new prefix. 308 In Figure 1, RSU1 and RSU2 are deployed in a multi-link subnet with 309 the same prefix address in their interfaces responding for connection 310 with vehicles. When vehicle2 leaves the coverage of RSU1 and enters 311 RSU2, it maintains its address configuration and ignores Address 312 Registration and DAD steps. If vehicle2 moves into the coverage of 313 RSU3, since RSU3 belongs to another subnet and holds a different 314 prefix from RSU1 and RSU2, so vehicle2 must do Address Registration 315 and DAD just as connecting to a new RSU. Note that vehicles and RSUs 316 have their internal networks including in-vehicle devices and 317 servers, respectively. The structures of the internal networks are 318 described in [ID-IPWAVE-PS]. 320 Traffic Control Center in Vehicular Cloud 321 *-----------------------------------------* 322 * * 323 * +----------------+ * 324 * | Mobility Anchor| * 325 * +----------------+ * 326 * ^ * 327 * | * 328 *------------------v----------------------* 329 ^ ^ ^ 330 | | | 331 | | | 332 v v v 333 +--------+ Ethernet +--------+ +--------+ 334 | RSU1 |<-------->| RSU2 |<---------->| RSU3 | 335 +--------+ +--------+ +--------+ 336 ^ ^ ^ 337 : : : 338 +-------------------------------------+ +-----------------+ 339 | : V2I V2I : | | V2I : | 340 | v v | | v | 341 +--------+ | +--------+ +--------+ | | +--------+ | 342 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 343 | |<...>| |<........>| | | | | | | 344 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 345 | | | | 346 +-------------------------------------+ +-----------------+ 347 Subnet1 Subnet2 349 <----> Wired Link <....> Wireless Link ===> Moving Direction 351 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 353 6. ND Extension for Prefix and Service Discovery 355 This section specifies an IPv6 ND extension for vehicle-to-vehicle 356 (V2V) or vehicle-to-infrastructure (V2I) networking. This section 357 also defines three new ND options for prefix discovery, service 358 discovery, and mobility information report: (i) Vehicular Prefix 359 Information (VPI) option, (ii) Vehicular Service Information (VSI) 360 option, and (iii) Vehicular Mobility Information (VMI) option. It 361 also describes the procedure of the ND protocol with those options. 363 6.1. Vehicular Prefix Information Option 365 The VPI option contains IPv6 prefix informations in the internal 366 network. Figure 2 shows the format of the VPI option. 368 0 1 2 3 369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Length | Prefix Length | Distance | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Reserved | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | 376 : Prefix : 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 2: Vehicular Prefix Information (VPI) Option Format 382 Fields: 383 Type 8-bit identifier of the VPI option type as assigned 384 by the IANA: TBD 386 Length 8-bit unsigned integer. The length of the option 387 (including the Type and Length fields) is in units of 388 8 octets. The value is 3. 390 Prefix Length 8-bit unsigned integer. The number of leading bits 391 in the Prefix that are valid. The value ranges 392 from 0 to 128. 394 Distance 8-bit unsigned integer. The distance between the 395 subnet announcing this prefix and the subnet 396 corresponding to this prefix in terms of the number 397 of hops. 399 Reserved This field is unused. It MUST be initialized to 400 zero by the sender and MUST be ignored by the 401 receiver. 403 Prefix An IP address or a prefix of an IP address. The 404 Prefix Length field contains the number of valid 405 leading bits in the prefix. The bits in the prefix 406 after the prefix length are reserved and MUST be 407 initialized to zero by the sender and ignored by 408 the receiver. 410 6.2. Vehicular Service Information Option 412 The VSI option contains vehicular service information in the internal 413 network. Figure 3 shows the format of the VSI option. 415 0 1 2 3 416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Length | Reserved1 | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Protocol | Reserved2 | Port Number | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 : Node Address : 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 3: Vehicular Service Information (VSI) Option Format 429 Fields: 430 Type 8-bit identifier of the VSI option type as assigned 431 by the IANA: TBD 433 Length 8-bit unsigned integer. The length of the option 434 (including the Type and Length fields) is in units of 435 8 octets. The value is 3. 437 Reserved1 This field is unused. It MUST be initialized to 438 zero by the sender and MUST be ignored by the 439 receiver. 441 Protocol 8-bit unsigned integer to indicate the upper-layer 442 protocol, such as transport-layer protocol (e.g., 443 TCP, UDP, and SCTP). 445 Reserved2 This field is unused. It MUST be initialized to 446 zero by the sender and MUST be ignored by the 447 receiver. 449 Port Number 16-bit unsigned integer to indicate the port number 450 for this protocol. 452 Service Address 453 128-bit IPv6 address of a node providing this vehicular 454 service. 456 6.3. Vehicular Mobility Information Option 458 The VMI option contains one vehicular mobility information of a 459 vehicle or an RSU. Figure 4 shows the format of the VMI option. 461 0 1 2 3 462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | Reserved1 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Reserved2 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 : Mobility Information : 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 4: Vehicular Mobility Information (VMI) Option Format 475 Fields: 476 Type 8-bit identifier of the VMI option type as assigned 477 by the IANA: TBD 479 Length 8-bit unsigned integer. The length of the option 480 (including the Type and Length fields) is in units of 481 8 octets. The value is 3. 483 Reserved1 This field is unused. It MUST be initialized to 484 zero by the sender and MUST be ignored by the 485 receiver. 487 Reserved2 This field is unused. It MUST be initialized to 488 zero by the sender and MUST be ignored by the 489 receiver. 491 Mobility Information 492 128-bit mobility information, such as position, 493 speed, acceleration/deceleration, and direction. 495 6.4. Vehicular Neighbor Discovery 497 Prefix discovery enables hosts (e.g., vehicles and in-vehicle 498 devices) to distinguish destinations on the same link from those only 499 reachable via RSUs. A vehicle (or its in-vehicle devices) can 500 directly communicate with on-link vehicles (or their in-vehicle 501 devices) without the relay of an RSU, but through V2V communications 502 along with VPI ND option. This VPI option contains IPv6 prefixes in 503 a vehicle's internal network. 505 Vehicles announce services in their internal networks to other 506 vehicles through an VSI ND option. The VSI option contains a list of 507 vehicular services in a vehicle's or an RSU's internal network. 509 A vehicle periodically announces an NS message containing VPI and VSI 510 options with its prefixes and services in all-nodes multicast address 511 to reach all neighboring nodes. When it receives this NS message, 512 another neighboring node responds to this NS message by sending an NA 513 message containing the VPI and VSI options with its prefixes and 514 services via unicast towards the NS-originating node. 516 Therefore, prefix and service discovery can be achieved via ND 517 messages (e.g., NS and NA) by vehicular ND with VPI and VSI options. 518 This VND-based discovery eliminates an additional prefix and service 519 discovery scheme, such as DNS-based Service Discovery [RFC6763] 520 (e.g., Multicast DNS (mDNS) [RFC6762] and DNSNA [ID-DNSNA]), other 521 than ND. That is, vehicles and RSUs can rapidly discover the network 522 prefixes and services of the other party without any additional 523 service discovery protocol. 525 6.5. Message Exchange Procedure for V2I Networking 527 This subsection explains a message exchange procedure for VND in V2I 528 networking, where a vehicle communicates with its corresponding node 529 in the Internet via an RSU. 531 Figure 5 shows an example of message exchange procedure in V2I 532 networking. Detailed steps of the procedure are explained in 533 Section 7. The mobility management part is described in 534 [ID-IPWAVE-VMM]. 536 Note that a vehicle could also perform the prefix and service 537 discovery simultaneously along with Address Registration procedure, 538 as shown in Figure 7. 540 This document specified that RSUs as routers do not transmit 541 periodical and unsolicited multicast RA messages including a prefix 542 for energy saving in vehicular networks. Vehicles as hosts 543 periodically initiate an RS message according to a time interval 544 (considering its position and an RSU's coverage). Since they have a 545 digital road map with the information of RSUs (e.g., position and 546 communication coverage), vehicles can know when they will go out of 547 the communication range of an RSU along with the signal strength 548 (e.g., Received Channel Power Indicator (RCPI) [VIP-WAVE]) from the 549 RSU. RSUs replies with a solicited RA in unicast only when they 550 receive an RS message. 552 Vehicle RSU MA 553 | | | 554 |-RS with Mobility Info->| | 555 | [VMI] | | 556 | | | 557 | |-----------PBU--------->| 558 | | | 559 | | | 560 | |<----------PBA----------| 561 | | | 562 | | | 563 | |======Bi-Dir Tunnel=====| 564 | | | 565 | | | 566 |<----RA with prefix-----| | 567 | | | 568 | | | 569 | | | 570 |--NS with Address Reg-->| | 571 | [ARO+VPI+VSI] | | 572 | | | 573 | |---Forward NS for DAD-->| 574 | | | 575 | | | 576 | |<--NA with DAD result---| 577 | | [ARO+VPI+VSI] | 578 |<------Forward NA-------| | 579 | | | 581 Figure 5: Message Interaction for Vehicular Neighbor Discovery 583 7. Address Registration and Duplicate Address Detection 585 This section explains address configuration, consisting of IP Address 586 Autoconfiguration, Address Registration, and multihop DAD via V2I or 587 V2V. 589 This document recommends a new Address Registration and DAD scheme in 590 order to avoid multicast flooding and decrease link-scope multicast 591 for energy and wireless channel conservation on a large-scale 592 vehicular network. Host-initiated refresh of RA removes the 593 necessity for routers to use frequent and unsolicited multicast RAs 594 to accommodate hosts. This also enables the same IPv6 address 595 prefix(es) to be used across a subnet. 597 There are three scenarios feasible in Address Registration scheme: 599 1. Vehicle enters the subnet for the first time or the current RSU 600 belongs to another subnet: Vehicles need to perform the Address 601 Registration and multihop DAD as described in the following 602 subsections. 604 2. Vehicle has already configured its IP addresses with prefix 605 obtained from the previous RSU, and the current RSU located in 606 the same subnet: This means RSUs have the same prefix and the 607 vehicle has no need to repeat the Address Registration and 608 multihop DAD. 610 3. Vehicle is not in the coverage of RSU but has a neighbor 611 registered in RSU: This document proposes a new V2V scenario for 612 vehicles which are currently not in the range of the RSU. If a 613 user vehicle failed to find an on-link RSU, it starts to look for 614 adjacent vehicle neighbors which can work as a relay neighbor to 615 share the prefix obtained from RSU and undertake DAD of the user 616 vehicle by forwarding DAD messages to RSU. 618 7.1. Address Autoconfiguration 620 A vehicle as an IPv6 host creates its link-local IPv6 address and 621 global IPv6 address as follows [RFC4862]. When they receive RS 622 messages from vehicles, RSUs send back RA messages containing prefix 623 information. The vehicle makes its global IPv6 addresses by 624 combining the prefix for its current link and its link-layer address. 626 The address autoconfiguration does not perform the legacy DAD as 627 defined in [RFC4862]. Instead, a new multihop DAD is performed in 628 Section 7.3. 630 7.2. Address Registration 632 After its IP tentative address autoconfiguration with the known 633 prefix from an RSU and its link-layer address, a vehicle starts to 634 register its IP address to the serving RSU along with multihop DAD. 635 Address Register Option (ARO) is used in this step and its format is 636 defined in [RFC6775]. 638 ARO is always host-initiated by vehicles. Information such as 639 registration time and registration status contained in ARO are 640 applied to indicate the registration duration and result. ARO will 641 also be forwarded to MA together with NS by RSUs. 643 An example message exchange procedure of Address Registration is 644 presented in Figure 6. Since Address Registration is performed 645 simultaneously with the multihop DAD, the specific procedure is 646 together described with the DAD mechanism in Section 7.3. 648 Vehicle RSU 649 | | 650 | | 651 1. |----NS with Address Reg--->| 652 | [ARO] | 653 | | 654 | | 655 | | 656 2. |<---NA with Address Reg----| 657 | [ARO] | 659 Figure 6: Neighbor Discovery Address Registration 661 7.3. Multihop Duplicate Address Detection 663 Before it can exchange data, a node should determine whether its IP 664 address is already used by another node or not. In the legacy IPv6 665 ND, hosts multicast NS messages to all nodes in the same on-link 666 subnet for DAD. Instead of this, an optimized multihop DAD is 667 designed to eliminate multicast messages for energy-saving purpose. 668 For this multihop DAD, Neighbor Cache and DAD Table are maintained by 669 each RSU and an MA, respectively, for the duplicate address 670 inspection during the multihop DAD process. That is, each RSU makes 671 Neighbor Cache Entries (NCE) of all the on-link hosts in its Neighbor 672 Cache. Similarly, the MA stores all the NCEs reported by the RSUs in 673 its DAD Table. 675 With the multihop DAD, a vehicle can skip the multicast-based DAD in 676 its current wireless link whenever it enters the coverage of another 677 RSU in the same subset, leading to the reduction of traffic overhead 678 in vehicular wireless links. 680 For the multihop DAD, we take advantage of the procedure of [RFC6775] 681 but simplified the message flows by canceling the two new ICMPv6 682 message types such as Duplicate Address Request (DAR) and the 683 Duplicate Address Confirmation (DAC). Instead, NS and NA containing 684 ARO are directly forwarded between RSU and MA. This idea is raised 685 because DAR and DAC 687 7.3.1. DAD without Intermediate Vehicle 689 Figure 7 presents the procedure of Address Registration and multihop 690 DAD. The detailed steps are explained as follows. 692 Vehicle RSU MA 693 | | | 694 | | | 695 1. |--NS with Address Reg-->| | 696 | [ARO+VPI+VSI] | | 697 | | | 698 2. | |----Forward NS--->| 699 | | | 700 | | | 701 3. | |<---Forward NA----| 702 | | | 703 | | | 704 4. |<--NA with Address Reg--| | 705 | [ARO+VPI+VSI] | | 707 Figure 7: Neighbor Discovery Address Registration with Multihop DAD 709 1. A vehicle sends an NS message to the current RSU in unicast, 710 containing the ARO to register its address. 712 2. The RSU receives the NS message, and then inspects its Neighbor 713 Cache to check whether it is duplicate or not. If there is no 714 duplicate NCE, a tentative NCE is created for this address, and 715 then the RSU forward the NS message containing the ARO to the MA 716 for the multihop DAD. 718 3. When the MA receives NS from an RSU, it checks whether the 719 register-requested address exists in its DAD Table or not. If an 720 entry with the same address exists in the DAD Table, which means 721 that the address is considered "Duplicate Address", then MA 722 returns a NA message containing the registration status in ARO to 723 notify the RSU of the address duplication. If no entry with the 724 same address exists in the DAD Table, which means that an entry 725 for the address is created, then MA replies a NA message to the 726 RSU to confirm the uniqueness of the register-requested address 727 to the RSU. 729 4. If the address duplication is notified by the MA, the RSU deletes 730 the tentative NCE, and forward NA with to the address- 731 registration vehicle to notify the registration failure. 732 Otherwise, the RSU changes the tentative NCE into a registered 733 NCE in its Neighbor Cache, and then forward NA to the vehicle to 734 notify the registration success. 736 Thus, the multihop DAD is processed simultaneously with the Address 737 Registration. Note that the tentative address is not considered 738 assigned to the vehicle until the MA confirms the uniqueness of the 739 register-requested address in the multihop DAD. 741 7.3.2. DAD with one Intermediate Vehicle 743 If a vehicle failed to register a default router, it triggers 744 neighbor discovery to look for vehicle neighbors which can provide 745 relay service using multi-hop communication. In this specification, 746 we assumed vehicles would not emulate V2V communication and trigger 747 relay scenario only if Router Discovery(RD) failed. 749 User Vehicle Relay Vehicle RSU MA 750 | | | | 751 |------------------------| | | 752 | RD failed | | | 753 |------------------------| | | 754 | | | | 755 | | | | 756 |-----------NS---------->| | | 757 | | | | 758 |<--NA with Prefix Info--| | | 759 | | | | 760 | | | | 761 |--NS with Address Reg-->| | | 762 | [ARO+VPI+VSI] | | | 763 | |----- Forward NS ----->| | 764 | | | | 765 | | |-----------------| 766 | | | Same as Figure 9| 767 | | |-----------------| 768 | | | | 769 | |<--NA with Address Reg-| | 770 | | [ARO+VPI+VSI] | | 771 |<------ Forward NA -----| | | 772 | | | | 774 Figure 8: Address Registration and Multihop DAD via V2V Relay 776 Since vehicles have a digital road map with the information of RSUs 777 (e.g., position and communication coverage), they can determine if 778 they are available to serve as a relay vehicle. Only vehicles with 779 the ability to serve as temporary relays will take action when they 780 receive relay service requests. The user vehicle can process global 781 address configuration, Address Registration and DAD through its relay 782 vehicle before it enters the coverage of RSUs. See Figure 8. 784 When a user vehicle failed to directly register to an RSU, it 785 initiates neighbor discovery to detect vehicle neighbors through V2V 786 communication. Vehicle sends NS messages to connect with neighbors 787 in range. If neighbor can provide relay service, it creates a NCE 788 for user vehicle, setting its own address as relay address, and sends 789 back NA with prefix information received from RSU. 791 To guarantee vehicles could find the nearest neighbor from multiple 792 neighbors which can act as relay vehicles, a new time-out mechanism 793 is presented to select the nearest neighbor by hop distance parameter 794 carried in Prefix Information Option. That is, a user vehicle 795 multicast NS messages to look for relay vehicles after RD failed and 796 wait for 1.5 seconds to receive all NA replies from neighbors. Each 797 NA carries its own global prefix(es) and the hop distance(s) in 798 Prefix Information Option. The user vehicle preserves every NA reply 799 in a temporary router list and select the one with least hop counts 800 as its relay vehicle after time out. 802 With receipt of NA, user vehicle configures its global address with 803 prefix information as mentioned in Section 7.1. After this, user 804 vehicle takes up to initiate the Address Registration along with DAD 805 process via relay vehicle. NS message is configured as specified in 806 Section 7.2 but indicate the relay vehicle's address as next-hop to 807 reach the RSU. In such a case, when relay vehicle receives relay 808 request message, it will forward NS message to RSU. The procedure 809 sets up on the rails except MA will include the relay vehicle's 810 address as relay address in NCE to indicate that at this moment, it 811 is not a directly attached vehicle, and sets the relay address as 812 next-hop address. Relay vehicle forwards DAD result information 813 message to user vehicle as soon as it received. 815 7.3.3. DAD with multiple Intermediate Vehicles 817 This document supports multihop communications (e.g., multihop DAD 818 and UDP/TCP transmission) for remote vehicles through multiple relay 819 vehicles. Vehicles which have already finished DAD process can serve 820 as temporary routers and forward packets for remote vehicles. 822 A new routing mechanism is specified to accomplish route selections 823 among user vehicles and serving RSUs when multiple vehicles act as 824 relay vehicles. Taking advantage of the Destination-Sequenced 825 Distance-Vector routing protocol (DSDV) [DSDV], this new routing 826 approach supposes that each vehicle holds a Neighbor Routing 827 Table which integrates the neighbor information in Neighbor Cache and 828 forwarding records for remote vehicles. Each vehicle which acts as a 829 relay vehicle for this remote vehicle will make records in its 830 Neighbor Routing Table. 832 Figure 9 specifies an example of parameters in Neighbor Routing 833 Table when more than one vehicle work as intermediate relay vehicles. 835 In Figure 9, Vehicle3 connects RSU1 indirectly via Vehicle2 and 836 Vehicle1. When Vehicle1 and Vehicle2 forward messages for Vehicle3, 837 they make records in its Neighbor Routing Table including the next- 838 hop node to indicate the route to Vehicle3. This can ensure that the 839 packets from a source vehicle can be successfully transmitted to an 840 RSU as well as the reverse packet path exists from the RSU to the 841 source vehicle. 843 +--------+ +--------+ +--------+ +--------+ 844 |Vehicle3|<......>|Vehicle2|<........>|Vehicle1|<.......> | RSU1 | 845 | (V3) | V2V | (V2) | V2V | (V1) | V2I | | 846 +--------+ +--------+ +--------+ +--------+ 848 +------------+ +------------+ +------------+ +------------+ 849 |Node|NextHop| |Node|NextHop| |Node|NextHop| |Node|NextHop| 850 +------------+ +------------+ +------------+ +------------+ 851 | V2 | V2 | | V1 | V1 | |RSU1| RSU1 | | V1 | V1 | 852 +------------+ | V3 | V3 | | V2 | V2 | | V2 | V1 | 853 +------------+ | V3 | V2 | | V3 | V1 | 854 +------------+ +------------+ 856 Figure 9: An Example of Neighbor Routing Table when multiple Vehicles 857 act as Relay Vehicles 859 7.4. Pseudonym Handling 861 Considering the privacy protection of a vehicle, a pseudonym 862 mechanism for its link-layer address is requested. This mechanism 863 periodically modifies the link-layer address, leading to the update 864 of the corresponding IP address. A random MAC Address Generation 865 mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by 866 generating the 46 remaining bits of MAC address using a random number 867 generator. When it changes its MAC address, a vehicle should ask the 868 serving RSU to update its own NCE, and to register its IP address 869 into the MA again. 871 8. Security Considerations 873 This document shares all the security issues of the neighbor 874 discovery protocol and 6LoWPAN protocol. This document can get 875 benefits from secure neighbor discovery (SEND) [RFC3971] in order to 876 protect ND from possible security attacks. 878 9. Acknowledgments 880 This work was supported by Basic Science Research Program through the 881 National Research Foundation of Korea (NRF) funded by the Ministry of 882 Education (2017R1D1A1B03035885). 884 This work was supported in part by Institute of Information & 885 Communications Technology Planning & Evaluation (IITP) grant funded 886 by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, 887 Cloud based Security Intelligence Technology Development for the 888 Customized Security Service Provisioning). 890 This work was supported in part by the MSIT under the ITRC 891 (Information Technology Research Center) support program (IITP- 892 2020-2017-0-01633) supervised by the IITP. 894 10. References 896 10.1. Normative References 898 [ID-IPWAVE-PS] 899 Jeong, J., Ed., "IPv6 Wireless Access in Vehicular 900 Environments (IPWAVE): Problem Statement and Use Cases", 901 draft-ietf-ipwave-vehicular-networking-19 (work in 902 progress), July 2020. 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, March 1997. 907 [RFC3971] Arkko, J., "SEcure Neighbor Discovery (SEND)", RFC 3971, 908 March 2005. 910 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 911 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 912 September 2007. 914 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 915 Address Autoconfiguration", RFC 4862, September 2007. 917 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 918 Hoc Networks", RFC 5889, September 2010. 920 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 921 February 2013. 923 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 924 Discovery", RFC 6763, February 2013. 926 [RFC6775] Shelby, Z., Ed., "Neighbor Discovery Optimization for IPv6 927 over Low-Power Wireless Personal Area Networks 928 (6LoWPANs)", RFC 6775, November 2012. 930 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 931 (IPv6) Specification", RFC 8200, July 2017. 933 [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 934 Support for IPv6 Networks Operating Outside the Context of 935 a Basic Service Set over IEEE Std 802.11", RFC 8691, 936 December 2019. 938 10.2. Informative References 940 [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 941 Sequenced Distance-Vector Routing (DSDV) for Mobile 942 Computers", ACM SIGCOMM, August 1994. 944 [DSRC-WAVE] 945 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 946 Architecture, Design, and Characteristics", 947 IEEE Communications Surveys & Tutorials, 12(4), 2012. 949 [ID-DNSNA] 950 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 951 Autoconfiguration for Internet-of-Things Devices in IP- 952 Based Vehicular Networks", draft-jeong-ipwave-iot-dns- 953 autoconf-09 (work in progress), October 2020. 955 [ID-IPWAVE-VMM] 956 Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular 957 Mobility Management for IP-Based Vehicular Networks", 958 draft-jeong-ipwave-vehicular-mobility-management-04 (work 959 in progress), October 2020. 961 [IEEE-802.11-OCB] 962 "Part 11: Wireless LAN Medium Access Control (MAC) and 963 Physical Layer (PHY) Specifications", IEEE Std 964 802.11-2016, December 2016. 966 [IEEE-802.11p] 967 "Part 11: Wireless LAN Medium Access Control (MAC) and 968 Physical Layer (PHY) Specifications Amendment 6: Wireless 969 Access in Vehicular Environments", June 2010. 971 [VIP-WAVE] 972 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 973 Feasibility of IP Communications in 802.11p Vehicular 974 Networks", IEEE Transactions on Intelligent Transportation 975 Systems, vol. 14, no. 1, March 2013. 977 [WAVE-1609.0] 978 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 979 in Vehicular Environments (WAVE) - Architecture", IEEE Std 980 1609.0-2013, March 2014. 982 [WAVE-1609.2] 983 IEEE 1609 Working Group, "IEEE Standard for Wireless 984 Access in Vehicular Environments - Security Services for 985 Applications and Management Messages", IEEE Std 986 1609.2-2016, March 2016. 988 [WAVE-1609.3] 989 IEEE 1609 Working Group, "IEEE Standard for Wireless 990 Access in Vehicular Environments (WAVE) - Networking 991 Services", IEEE Std 1609.3-2016, April 2016. 993 [WAVE-1609.4] 994 IEEE 1609 Working Group, "IEEE Standard for Wireless 995 Access in Vehicular Environments (WAVE) - Multi-Channel 996 Operation", IEEE Std 1609.4-2016, March 2016. 998 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 999 discovery-09 1001 The following changes are made from draft-jeong-ipwave-vehicular- 1002 neighbor-discovery-09: 1004 o This version updates the version numbers of the referenced drafts. 1006 o The abstract is updated to smooth the description. 1008 o In Section 1, the reference [DSRC-WAVE] for DSRC is moved to the 1009 initial appeared place. 1011 o In the last paragraph of Section 1, the first sentence is updated 1012 by adding "procedure" to "a Vehicular Neighbor Discovery (VND)" as 1013 "a Vehicular Neighbor Discovery (VND) procedure". 1015 o In Section 3, the reference [RFC8691] is added, and the terms and 1016 definitions of RSU and OBU are deleted due to duplicated 1017 definitions in [RFC8691]. 1019 o In Section 4, the description is updated. 1021 o The uncited normative reference RFC8106 is deleted. 1023 Authors' Addresses 1025 Jaehoon Paul Jeong 1026 Department of Computer Science and Engineering 1027 Sungkyunkwan University 1028 2066 Seobu-Ro, Jangan-Gu 1029 Suwon, Gyeonggi-Do 16419 1030 Republic of Korea 1032 Phone: +82 31 299 4957 1033 Fax: +82 31 290 7996 1034 EMail: pauljeong@skku.edu 1035 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1036 Yiwen Chris Shen 1037 Department of Electrical and Computer Engineering 1038 Sungkyunkwan University 1039 2066 Seobu-Ro, Jangan-Gu 1040 Suwon, Gyeonggi-Do 16419 1041 Republic of Korea 1043 Phone: +82 31 299 4106 1044 Fax: +82 31 290 7996 1045 EMail: chrisshen@skku.edu 1047 Zhong Xiang 1048 Department of Electrical and Computer Engineering 1049 Sungkyunkwan University 1050 2066 Seobu-Ro, Jangan-Gu 1051 Suwon, Gyeonggi-Do 16419 1052 Republic of Korea 1054 Phone: +82 10 9895 1211 1055 Fax: +82 31 290 7996 1056 EMail: xz618@skku.edu 1058 Sandra Cespedes 1059 NIC Chile Research Labs 1060 Universidad de Chile 1061 Av. Blanco Encalada 1975 1062 Santiago 1063 Chile 1065 Phone: +56 2 29784093 1066 EMail: scespede@niclabs.cl