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