idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-06.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.) ** There are 11 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1872 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 966, but not defined == Missing Reference: 'ARO' is mentioned on line 798, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 5889 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-05 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-08 Summary: 4 errors (**), 0 flaws (~~), 5 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: September 12, 2019 Sungkyunkwan University 6 March 11, 2019 8 IPv6 Neighbor Discovery for IP-Based Vehicular Networks 9 draft-jeong-ipwave-vehicular-neighbor-discovery-06 11 Abstract 13 This document specifies a Vehicular Neighbor Discovery (VND) as an 14 extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular 15 networks. An optimized Address Registration and a multihop Duplicate 16 Address Detection (DAD) mechanism are performed for having operation 17 efficiency and also saving both wireless bandwidth and vehicle 18 energy. Also, three new ND options for prefix discovery, service 19 discovery, and mobility information report are defined to announce 20 the network prefixes and services inside a vehicle (i.e., a vehicle's 21 internal network). Finally, a mobility management scheme is proposed 22 for moving vehicles in vehicular environments to support seamless 23 communication for the continuity of transport-layer sessions (e.g., 24 TCP connections). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. ND Optimization . . . . . . . . . . . . . . . . . . . . . 6 66 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Vehicular Network Architecture . . . . . . . . . . . . . . . 7 68 5.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 7 69 5.2. V2I Internetworking . . . . . . . . . . . . . . . . . . . 9 70 5.3. V2V Internetworking . . . . . . . . . . . . . . . . . . . 10 71 6. ND Extension for Prefix and Service Discovery . . . . . . . . 11 72 6.1. Vehicular Prefix Information Option . . . . . . . . . . . 11 73 6.2. Vehicular Service Information Option . . . . . . . . . . 12 74 6.3. Vehicular Mobility Information Option . . . . . . . . . . 13 75 6.4. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 14 76 6.5. Message Exchange Procedure for V2I Networking . . . . . . 15 77 7. Address Registration and Duplicate Address Detection . . . . 16 78 7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 17 79 7.2. Address Registration . . . . . . . . . . . . . . . . . . 17 80 7.3. Multihop Duplicate Address Detection . . . . . . . . . . 18 81 7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 21 82 8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 21 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 86 10.2. Informative References . . . . . . . . . . . . . . . . . 25 87 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 88 discovery-05 . . . . . . . . . . . . . . . . . . . . 27 89 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 27 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 92 1. Introduction 94 Vehicular Ad Hoc Networks (VANET) have been researched for 95 Intelligent Transportation System (ITS) such as driving safety, 96 efficient driving and entertainment. Considering the high-speed 97 mobility of vehicular network based on Dedicated Short-Range 98 Communications (DSRC), IEEE 802.11p [IEEE-802.11p] has been 99 specialized and was renamed IEEE 802.11 Outside the Context of a 100 Basic Service Set (OCB) [IEEE-802.11-OCB] in 2012. IEEE has 101 standardized Wireless Access in Vehicular Environments (WAVE) 102 [DSRC-WAVE] standard which is considered as a key component in ITS. 103 The IEEE 1609 standards such as IEEE 1609.0 [WAVE-1609.0], 1609.2 104 [WAVE-1609.2], 1609.3 [WAVE-1609.3], 1609.4 [WAVE-1609.4] provide a 105 low-latency and alternative network for vehicular communications. 106 What is more, IP-based vehicular networks specialized as IP Wireless 107 Access in Vehicular Environments (IPWAVE) [IPWAVE-PS] can enable many 108 use cases over vehicle-to-vehicle (V2V), vehicle-to-infrastructure 109 (V2I), and vehicle-to-everything (V2X) communications. 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) as an extension of IPv6 ND for IP-based vehicular 124 networks. VND provides vehicles with an optimized Address 125 Registration, a multihop Duplicate Address Detection (DAD), and an 126 efficient mobility management scheme to support efficient V2V, V2I, 127 and V2X communications. 129 2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 3. Terminology 137 This document uses the terminology described in [RFC4861], [RFC4862], 138 and [RFC6775]. In addition, the following new terms are defined as 139 below: 141 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 142 [WAVE-1609.0]. 144 o Road-Side Unit (RSU): A node that has physical communication 145 devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE- 146 V2X, etc.) for wireless communications with vehicles and is also 147 connected to the Internet as a router or switch for packet 148 forwarding. An RSU is typically deployed on the road 149 infrastructure, either at an intersection or in a road segment, 150 but may also be located in car parking area. 152 o On-Board Unit (OBU): A node that has a DSRC device for wireless 153 communications with other OBUs and RSUs, and may be connected to 154 in-vehicle devices or networks. An OBU is mounted on a vehicle. 155 It is assumed that a radio navigation receiver (e.g., Global 156 Positioning System (GPS)) is included in a vehicle with an OBU for 157 efficient navigation. 159 o Mobility Anchor (MA): A node that maintains IP addresses and 160 mobility information of vehicles in a road network to support the 161 address autoconfiguration and mobility management of them. It has 162 end-to-end connections with RSUs under its control. It maintains 163 a DAD table having the IP addresses of the vehicles moving within 164 the communication coverage of its RSUs. 166 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 167 having compute nodes, storage nodes, and network nodes. 169 o Traffic Control Center (TCC): A node that maintains road 170 infrastructure information (e.g., RSUs, traffic signals, and loop 171 detectors), vehicular traffic statistics (e.g., average vehicle 172 speed and vehicle inter-arrival time per road segment), and 173 vehicle information (e.g., a vehicle's identifier, position, 174 direction, speed, and trajectory as a navigation path). TCC is 175 included in a vehicular cloud for vehicular networks and has MAs 176 under its management. 178 4. Overview 180 This document proposes an optimized ND with a more adaptive structure 181 for vehicular networks considering fast vehicle mobility and wireless 182 control traffic overhead related to the legacy ND. Further more, 183 prefix and service discovery can be implemented as part of the ND's 184 process along with an efficient Address Registration procedure and 185 DAD mechanism for moving vehicles. This document specifies a set of 186 behaviors between vehicles and RSUs to accomplish these goals. 188 4.1. Link Model 190 There is a relationship between a link and a network prefix along 191 with reachability scopes, such as link-local and global scopes. The 192 legacy IPv6 ND protocol [RFC4861] has the following link model. All 193 IPv6 nodes in the same on-link subnet, which use the same subnet 194 prefix with on-link bit set, are reachable with each other by one-hop 195 link. The symmetry of the connectivity among the nodes is preserved, 196 that is, bidirectional connectivity among two on-link nodes. 197 However, a link model in vehicular networks (called vehicular link 198 model) should consider the asymmetry of the connectivity that 199 unidirectional links can exist due to interference in wireless 200 channels and the different levels of transmission power in wireless 201 network interfaces. 203 The on-link subnet can be constructed by one link (as a basic service 204 set) or multiple links (as an extended service set) called a multi- 205 link subnet [RFC6775]. In the legacy multi-link subnet, an all-node- 206 multicasted packet is copied and related to other links by an ND 207 proxy. On the other hand, in vehicular networks having fast moving 208 vehicles, multiple links can share the same subnet prefix for 209 operation efficiency. For example, if two wireless links under two 210 adjacent RSUs are in the same subnet, a vehicle as an IPv6 host does 211 not need to reconfigure its IPv6 address during handover between 212 those RSUs. However, the packet relay by an RSU as an ND proxy is 213 not required because such a relay can cause a broadcast storm in the 214 extended subnet. Thus, in the multi-link subnet, all-node- 215 multicasting needs to be well-calibrated to either being confined to 216 multicasting in the current link or being disseminated to other links 217 in the same subnet. 219 In a connected multihop VANET, for the efficient communication, 220 vehicles in the same link of an RSU can communicate directly with 221 each other, not through the serving RSU. This direct wireless 222 communication is similar to the direct wired communication in an on- 223 link subnet using Ethernet as a wired network. The vehicular link 224 model needs to accommodate both the ad-hoc communication between 225 vehicles and infrastructure communication between a vehicle and an 226 RSU in an efficient and flexible way. Therefore, the IPv6 ND should 227 be extended to accommodate the concept of a new IPv6 link model in 228 vehicular networks. 230 To support multi-link subnet, this specification employs the Shared- 231 Prefix model for prefix assignments. Shared-Prefix model refer to an 232 addressing model where the prefix(es) are shared by more than one 233 node. In this document, we assume that in a specified subnet, all 234 interfaces of RSUs responding for prefix assignments to vehicles hold 235 same prefix, which ensure vehicles obtain and maintain same prefix in 236 this subnet scope. 238 4.2. ND Optimization 240 This document takes advantage of the optimized ND for Low-Power 241 Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular 242 environments have common parts with 6LoWPAN, such as the reduction of 243 unnecessary wireless traffic by multicasting and the energy saving in 244 battery. Note that vehicles tend to be electric vehicles whose 245 energy source is from their battery. 247 In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are 248 assumed to be asymmetric and unidirectional because of changing radio 249 environment and loss signal. The authors proposed an improved IPv6 250 ND which greatly eliminates link-scope multicast to save energy by 251 constructing new options and a new scheme for address configurations. 252 Similarly, this document proposes an improved IPv6 ND by eliminating 253 many link-scope-multicast-based ND operations, such as DAD for IPv6 254 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Thus, this 255 document suggests an extension of IPv6 ND as vehicular ND tailored 256 for vehicular networks along with new ND options (e.g., prefix 257 discovery, service discovery, and mobility information options). 259 4.3. Design Goals 261 The vehicular ND in this document has the following design goals: 263 o To perform prefix and service discovery through ND procedure; 265 o To implement host-initiated refresh of Router Advertisement (RA) 266 and remove the necessity for routers to use periodic or 267 unsolicited multicast RA to find hosts; 269 o To replace Neighbor Unreachable Detection(NUD), create Neighbor 270 Cache Entries (NCE) for all registered vehicles in RSUs and MA by 271 appending Address Registration Option (ARO) in Neighbor 272 Solicitation (NS), Neighbor Advertisement (NA) messages; 274 o To support a multihop DAD with two new ICMPv6 messages called 275 Duplicate Address Request(DAR) and Duplicate Address 276 Confirmation(DAC) to eliminate multicast storm and save energy; 278 o To support multi-hop communication for vehicles outside the 279 coverage of RSUs to communicate with the serving RSU via a relay 280 neighbor; and 282 o To provide a mobility management mechanism for seamless 283 communication during a vehicle's travel in subnets via RSUs. 285 5. Vehicular Network Architecture 287 This section describes a vehicular network architecture for V2V and 288 V2I communication. A vehicle and an RSU have their internal networks 289 including in-vehicle devices or servers, respectively. 291 5.1. Vehicular Network 293 A vehicular network architecture for V2I and V2V is illustrated in 294 Figure 1. Three RSUs are deployed along roadside and are connected 295 to an MA through wired links. There are two subnets such as Subnet1 296 and Subnet2. The wireless links of RSU1 and RSU2 belong to the same 297 subnet named Subnet1, but the wireless link of RSU3 belongs to 298 another subnet named Subnet2. Vehicle2 is wirelessly connected to 299 RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 and RSU3, 300 respectively. Vehicles can directly communicate with each other 301 through V2V connection (e.g., Vehicle1 and Vehicle2) to share driving 302 information. In addition, vehicles not in range of any RSU may 303 connect with RSU in multi-hop connection via relay vehicle (e.g., 304 Vehicle1 can contact RSU1 via Vehicle2). Vehicles are assumed to 305 start the connection to an RSU when they entered the coverage of the 306 RSU. 308 The document recommends a multi-link subnet involving multiple RSUs 309 as shown in Figure 1. This recommendation aims at the reduction of 310 the frequency with which vehicles have to change their IP address 311 during handover between two adjacent RSUs. To construct this multi- 312 link subnet, shared-prefix model is proposed. That is, for RSUs in 313 the same subnet, the interfaces responsible for prefix assignment for 314 vehicles should hold the same prefix in their global address. This 315 also promises vehicles achieve same prefix in this scope. When they 316 pass through RSUs in the same subnet, vehicles do not need to perform 317 the Address Registration and DAD again because they can use their 318 current IP address in the wireless coverage of the next RSU. 319 Moreover, this proposal accord with the assumption that noes 320 belonging to the same IP prefix are able to communicate with each 321 other directly. On the other hand, if vehicles enter the wireless 322 coverage of an RSU belonging to another subnet with a different 323 prefix, they repeat the Address Registration and DAD procedure to 324 update their IP address with the new prefix. 326 Traffic Control Center in Vehicular Cloud 327 *-----------------------------------------* 328 * * 329 * +----------------+ * 330 * | Mobility Anchor| * 331 * +----------------+ * 332 * ^ * 333 * | * 334 *--------------------v--------------------* 335 ^ ^ ^ 336 | | | 337 | | | 338 v v v 339 +--------+ ethernet +--------+ +--------+ 340 | RSU1 |<-------->| RSU2 |<---------->| RSU3 | 341 +--------+ +--------+ +--------+ 342 ^ ^ ^ 343 : : : 344 +--------------------------------------+ +------------------+ 345 | : V2I V2I : | | V2I : | 346 | v v | | v | 347 +--------+ | +--------+ +--------+ | | +--------+ | 348 |Vehicle1|=======>|Vehicle2|=========>|Vehicle3|====>| | |Vehicle4|===>| 349 | |<......>| |<........>| | | | | | | 350 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 351 | | | | 352 +--------------------------------------+ +------------------+ 353 Subnet1 Subnet2 355 <----> Wired Link <....> Wireless Link ===> Moving Direction 357 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 359 In Figure 1, RSU1 and RSU2 are deployed in a multi-link subnet with 360 the same prefix address in their interfaces responding for connection 361 with vehicles. When vehicle2 leaves the coverage of RSU1 and enters 362 RSU2, it maintains its address configuration and ignores Address 363 Registration and DAD steps. If vehicle2 moves into the coverage of 364 RSU3, since RSU3 belongs to another subnet and holds a different 365 prefix from RSU1 and RSU2, so vehicle2 must do Address Registration 366 and DAD just as connecting to a new RSU. Note that vehicles and RSUs 367 have their internal networks including in-vehicle devices and 368 servers, respectively. The structures of the internal networks are 369 described in [IPWAVE-PS]. 371 5.2. V2I Internetworking 373 This subsection explains V2I internteworking between vehicle network 374 and RSU network where vehicle network is an internal network in a 375 vehicle, and RSU network is an internal network in an RSU, as shown 376 in Figure 2. 378 +-----------------+ 379 (*)<........>(*) +----->| Vehicular Cloud | 380 2001:DB8:1:1::/64 | | | +-----------------+ 381 +------------------------------+ +---------------------------------+ 382 | v | | v v | 383 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 384 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 385 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 386 | ^ ^ ^ | | ^ ^ ^ | 387 | | | | | | | | | | 388 | v v v | | v v v | 389 | ---------------------------- | | ------------------------------- | 390 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 391 | | | | | | 392 | v | | v | 393 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 394 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 395 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 396 | ^ ^ | | ^ ^ ^ | 397 | | | | | | | | | 398 | v v | | v v v | 399 | ---------------------------- | | ------------------------------- | 400 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 401 +------------------------------+ +---------------------------------+ 402 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 404 <----> Wired Link <....> Wireless Link (*) Antenna 406 Figure 2: Internetworking between Vehicle Network and RSU Network 408 Figure 2 shows the V2I networking of a vehicle and an RSU whose 409 internal networks are Moving Network1 and Fixed Network1, 410 respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts 411 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 412 has the DNS Server (RDNSS3), one host (Host5), the two routers 413 (Router5 and Router6). 415 It is assumed that RSU1 has a collection of servers (Server1 to 416 ServerN) for various services in the road networks, such as road 417 emergency notification and navigation services. Vehicle1's Router1 418 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., 419 DSRC) for I2V networking for various vehicular services. The 420 vehicular applications, such as road emergency notification and 421 navigation services, can be registered into the DNS Server (i.e., 422 RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS 423 options in [RFC8106]. 425 Vehicle1's Router1 and RSU1's Router5 can know what vehicular 426 applications exist in their internal network by referring to their 427 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 428 what network prefixes exist in their internal network through an 429 intra-domain routing protocoli, such as OSFP. Each vehicle and each 430 RSU announce their network prefixes and services through ND options 431 defined in Section 6. 433 5.3. V2V Internetworking 435 This subsection explains V2V internteworking between vehicle 436 networks, which are internal networks in vehicles, as shown in 437 Figure 3. 439 (*)<..........>(*) 440 2001:DB8:1:1::/64 | | 441 +------------------------------+ +------------------------------+ 442 | v | | v | 443 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 444 | | Host1 | |RDNSS1| |Router1| | | |Router5| |RDNSS3| | Host4 | | 445 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 446 | ^ ^ ^ | | ^ ^ ^ | 447 | | | | | | | | | | 448 | v v v | | v v v | 449 | ---------------------------- | | ---------------------------- | 450 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 451 | | | | | | 452 | v | | v | 453 | +-------+ +-------+ | | +-------+ +-------+ | 454 | | Host2 | |Router2| | | |Router6| | Host5 | | 455 | +-------+ +-------+ | | +-------+ +-------+ | 456 | ^ ^ | | ^ ^ | 457 | | | | | | | | 458 | v v | | v v | 459 | ---------------------------- | | ---------------------------- | 460 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 461 +------------------------------+ +------------------------------+ 462 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 464 <----> Wired Link <....> Wireless Link (*) Antenna 466 Figure 3: Internetworking between Vehicle Networks 468 Figure 3 shows the V2V networking of two vehicles whose internal 469 networks are Moving Network1 and Moving Network2, respectively. 470 Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and 471 Host2), and the two routers (Router1 and Router2). Vehicle2 has the 472 DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two 473 routers (Router3 and Router4). 475 It is assumed that Host1 and Host3 are running a Cooperative Adaptive 476 Cruise Control (C-ACC) program for physical collision avoidance. 477 Also, it is assumed that Host2 and Host4 are running a Cooperative 478 On-board Camera Sharing (C-OCS) program for sharing road hazards or 479 obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's 480 Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 481 V2V networking for various vehicular services. The vehicular 482 applications, such as C-ACC and C-BCS, can be registered into the DNS 483 Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with 484 IPv6 ND DNS options in [RFC8106]. 486 Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular 487 applications exist in their internal network by referring to their 488 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 489 what network prefixes exist in their internal network through an 490 intra-domain routing protocoli, such as OSFP. Each vehicle announces 491 its network prefixes and services through ND options defined in 492 Section 6. 494 6. ND Extension for Prefix and Service Discovery 496 This section specifies an IPv6 ND extension for vehicle-to-vehicle 497 (V2V) or vehicle-to-infrastructure (V2I) networking. This section 498 also defines three new ND options for prefix discovery, service 499 discovery, and mobility information report: (i) Vehicular Prefix 500 Information (VPI) option, (ii) Vehicular Service Information (VSI) 501 option, and (iii) Vehicular Mobility Information (VMI) option. It 502 also describes the procedure of the ND protocol with those options. 504 6.1. Vehicular Prefix Information Option 506 The VPI option contains IPv6 prefix information in the internal 507 network. Figure 4 shows the format of the VPI option. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | Prefix Length | Distance | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Reserved | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 : Prefix : 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 4: Vehicular Prefix Information (VPI) Option Format 523 Fields: 524 Type 8-bit identifier of the VPI option type as assigned 525 by the IANA: TBD 527 Length 8-bit unsigned integer. The length of the option 528 (including the Type and Length fields) is in units of 529 8 octets. The value is 3. 531 Prefix Length 8-bit unsigned integer. The number of leading bits 532 in the Prefix that are valid. The value ranges 533 from 0 to 128. 535 Distance 8-bit unsigned integer. The distance between the 536 subnet announcing this prefix and the subnet 537 corresponding to this prefix in terms of the number 538 of hops. 540 Reserved This field is unused. It MUST be initialized to 541 zero by the sender and MUST be ignored by the 542 receiver. 544 Prefix An IP address or a prefix of an IP address. The 545 Prefix Length field contains the number of valid 546 leading bits in the prefix. The bits in the prefix 547 after the prefix length are reserved and MUST be 548 initialized to zero by the sender and ignored by 549 the receiver. 551 6.2. Vehicular Service Information Option 553 The VSI option contains vehicular service information in the internal 554 network. Figure 5 shows the format of the VSI option. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type | Length | Reserved1 | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Protocol | Reserved2 | Port Number | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | 564 : Node Address : 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 5: Vehicular Service Information (VSI) Option Format 570 Fields: 571 Type 8-bit identifier of the VSI option type as assigned 572 by the IANA: TBD 574 Length 8-bit unsigned integer. The length of the option 575 (including the Type and Length fields) is in units of 576 8 octets. The value is 3. 578 Reserved1 This field is unused. It MUST be initialized to 579 zero by the sender and MUST be ignored by the 580 receiver. 582 Protocol 8-bit unsigned integer to indicate the upper-layer 583 protocol, such as transport-layer protocol (e.g., 584 TCP, UDP, and SCTP). 586 Reserved2 This field is unused. It MUST be initialized to 587 zero by the sender and MUST be ignored by the 588 receiver. 590 Port Number 16-bit unsigned integer to indicate the port number 591 for the protocol. 593 Service Address 594 128-bit IPv6 address of a node proving this vehicular 595 service. 597 6.3. Vehicular Mobility Information Option 599 The VMI option contains one vehicular mobility information of a 600 vehicle or an RSU. Figure 6 shows the format of the VMI option. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Type | Length | Reserved1 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Reserved2 | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | | 610 : Mobility Information : 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 6: Vehicular Mobility Information (VMI) Option Format 616 Fields: 617 Type 8-bit identifier of the VMI option type as assigned 618 by the IANA: TBD 620 Length 8-bit unsigned integer. The length of the option 621 (including the Type and Length fields) is in units of 622 8 octets. The value is 3. 624 Reserved1 This field is unused. It MUST be initialized to 625 zero by the sender and MUST be ignored by the 626 receiver. 628 Reserved2 This field is unused. It MUST be initialized to 629 zero by the sender and MUST be ignored by the 630 receiver. 632 Mobility Information 633 128-bit mobility information, such as position, 634 speed, and direction. 636 6.4. Vehicular Neighbor Discovery 638 Prefix discovery enables hosts (e.g., vehicles and in-vehicle 639 devices) to distinguish destinations on the same link from those only 640 reachable via RSUs. A vehicle (or its in-vehicle devices) can 641 directly communicate with on-link vehicles (or their in-vehicle 642 devices) without the relay of an RSU, but through V2V communications 643 along with VPI ND option. This VPI option contains IPv6 prefixes in 644 a vehicle's internal network. 646 Vehicles announce services in their internal networks to other 647 vehicles through an VSI ND option. The VSI option contains a list of 648 vehicular services in a vehicle's or an RSU's internal network. 650 A vehicle periodically announces an NS message containing VPI and VSI 651 options with its prefixes and services in all-nodes multicast address 652 to reach all neighboring nodes. When it receives this NS message, 653 another neighboring node responds to this NS message by sending an NA 654 message containing the VPI and VSI options with its prefixes and 655 services via unicast towards the NS-originating node. 657 Therefore, prefix and service discovery can be achieved via ND 658 messages (e.g., NS and NA) by vehicular ND with VPI and VSI options. 659 This VND-based discovery eliminates an additional prefix and service 660 discovery scheme, such as DNS-based Service Discovery [RFC6763] 661 (e.g., Multicast DNS (mDNS) [RFC6762] and DNSNA [ID-DNSNA]), other 662 than ND. That is, vehicles and RSUs can rapidly discover the network 663 prefixes and services of the other party without any additional 664 service discovery protocol. 666 6.5. Message Exchange Procedure for V2I Networking 668 This subsection explains a message exchange procedure for vehicular 669 neighbor discovery in V2I networking, where a vehicle communicates 670 with its correponding node in the Internet via an RSU. 672 Figure 7 shows an example of message exchange procedure in V2I 673 networking. Detailed steps of the procedure are explained in 674 Section 7 and Section 8. 676 Note that a vehicle could also perform the prefix and service 677 discovery simultaneously along with Address Registration procedure, 678 as shown in Figure 9. 680 This document specified that RSUs as routers do not transmit 681 periodical and unsolicited multicast RA messages including a prefix 682 for energy saving in vehicular networks. Vehicles as hosts 683 periodically initiate an RS message according to a time interval 684 (considering its position and an RSU's coverage). Since they have a 685 digital road map with the information of RSUs (e.g., position and 686 communication coverage), vehicles can know when they will go out of 687 the communication range of an RSU along with the signal strength 688 (e.g., Received Channel Power Indicator (RCPI) [VIP-WAVE]) from the 689 RSU. RSUs replies with a solicited RA in unicast only when they 690 receive an RS message. 692 Vehicle RSU Mobility Anchor 693 | | | 694 |-RS with Mobility Info->| | 695 | [VMI] | | 696 | | | 697 | |--------PBU------>| 698 | | | 699 | | | 700 | |<-------PBA-------| 701 | | | 702 | | | 703 | |===Bi-Dir Tunnel==| 704 | | | 705 | | | 706 |<----RA with prefix-----| | 707 | | | 708 | | | 709 | | | 710 |--NS with Address Reg-->| | 711 | [ARO+VPI+VSI] | | 712 | | | 713 | |--------DAR------>| 714 | | | 715 | | | 716 | |<-------DAC-------| 717 | | | 718 | | | 719 |<--NA with Address Reg--| | 720 | [ARO+VPI+VSI] | | 722 Figure 7: Message Interaction for Vehicular Neighbor Discovery 724 7. Address Registration and Duplicate Address Detection 726 This section explains address configuration, consisting of IP Address 727 Autoconfiguration, Address Registration, and multihop DAD via V2I or 728 V2V. 730 This document recommends a new Address Registration and DAD scheme in 731 order to avoid multicast flooding and decrease link-scope multicast 732 for energy and wireless channel conservation on a large-scale 733 vehicular network. Host-initiated refresh of RA removes the 734 necessity for routers to use frequent and unsolicited multicast RAs 735 to accommodate hosts. This also enables the same IPv6 address 736 prefix(es) to be used across a subnet. 738 There are three scenarios feasible in Address Registration scheme: 740 1. Vehicle enters the subnet for the first time or the current RSU 741 belongs to another subnet: Vehicles need to perform the Address 742 Registration and multihop DAD in the following subsections. 744 2. Vehicle has already configured its IP addresses with prefix 745 obtained from the previous RSU, and the current RSU located in 746 the same subnet: This means RSUs have the same prefix and the 747 vehicle has no need to repeat the Address Registration and 748 multihop DAD. 750 3. Vehicle is not in the coverage of RSU but has a neighbor 751 registered in RSU: This document proposes a new V2V scenario for 752 vehicles which are currently not in the range of the RSU. If a 753 user vehicle failed to find an on-link RSU, it starts to look for 754 adjacent vehicle neighbors which can work as relay neighbor to 755 share the prefix obtained from RSU and undertake the DAD of the 756 user vehicle by forwarding DAD messages to RSU. 758 7.1. Address Autoconfiguration 760 A vehicle as an IPv6 host creates its link-local IPv6 address and 761 global IPv6 address as follows [RFC4862]. When they receive RS 762 messages from vehicles, RSUs send back RA messages containing prefix 763 information. The vehicle makes its global IPv6 addresses by 764 combining the prefix for its current link and its link-layer address. 766 The address autoconfiguration does not perform the legacy DAD as 767 defined in [RFC4862]. Instead, a new multihop DAD is performed in 768 Section 7.3. 770 7.2. Address Registration 772 After its IP tentative address autoconfiguration with the known 773 prefix from an RSU and its link-layer address, a vehicle starts to 774 register its IP address to the serving RSU along with multihop DAD. 775 Address Register Option (ARO) is used in this step and its format is 776 defined in [RFC6775]. 778 ARO is always host-initiated by vehicles. Information such as 779 registration time and registration status contained in ARO is also 780 included in multihop Duplicate Address Request (DAR) and Duplicate 781 Address Confirmation (DAC) messages used between RSU and MA, but ARO 782 is not directly used in these two messages. 784 An example message exchange procedure of Address Registration is 785 presented in Figure 8. Since Address Registration is performed 786 simultaneously with the multihop DAD, the specific procedure is 787 together described with the DAD mechanism in Section 7.3. 789 Vehicle RSU 790 | | 791 | | 792 1. |----NS with Address Reg--->| 793 | [ARO] | 794 | | 795 | | 796 | | 797 2. |<---NA with Address Reg----| 798 | [ARO] | 800 Figure 8: Neighbor Discovery Address Registration 802 7.3. Multihop Duplicate Address Detection 804 Before it can exchange data, a node should determine whether its IP 805 address is already used by another node or not. In the legacy IPv6 806 ND, hosts multicast NS messages to all nodes in the same on-link 807 subnet for DAD. Instead of this, an optimized multihop DAD is 808 designed to eliminate multicast messages for energy-saving purpose. 809 For this multihop DAD, Neighbor Cache and DAD Table are maintained by 810 each RSU and an MA, respectively, for the duplicate address 811 inspection during the multihop DAD process. That is, each RSU makes 812 Neighbor Cache Entries (NCE) of all the on-link hosts in its Neighbor 813 Cache. Similarly, the MA stores all the NCEs reported by the RSUs in 814 its DAD Table. 816 With the multihop DAD, a vehicle can skip the multicast-based DAD in 817 its current wireless link whenever it enters the coverage of another 818 RSU in the same subset, leading to the reduction of traffic overhead 819 in vehicular wireless links. 821 For the multihop DAD, two new ICMPv6 message types are defined in 822 [RFC6775], such as Duplicate Address Request (DAR) and the Duplicate 823 Address Confirmation (DAC). Information carried by ARO options are 824 copied into these two messages for the multihop DAD in the MA. 826 Vehicle RSU Mobility Anchor 827 | | | 828 | | | 829 1. |--NS with Address Reg-->| | 830 | [ARO+VPI+VSI] | | 831 | | | 832 | | | 833 2. | | -------DAR------>| 834 | | | 835 | | | 836 3. | |<-------DAC-------| 837 | | | 838 | | | 839 | | | 840 4. |<--NA with Address Reg--| | 841 | [ARO+VPI+VSI] | | 843 Figure 9: Neighbor Discovery Address Registration with Multihop DAD 845 Figure 9 presents the procedure of Address Registration and multihop 846 DAD. The detailed steps are explained as follows. 848 1. A vehicle sends an NS message to the current RSU in unicast, 849 containing the ARO to RSU to register its address. 851 2. The RSU receives the NS message, and then inspects its Neighbor 852 Cache to check whether it is duplicate or not. If there is no 853 duplicate NCE, a tentative NCE is created for this address, and 854 then the RSU sends a DAR to the MA for the multicast DAD. 856 3. When the MA receives a DAR from an RSU, it checks whether the 857 register-requested address exists in its DAD Table or not. If an 858 entry with the same address exists in the DAD Table, which means 859 that the address is considered "Duplicate Address", then MA 860 returns a DAC message to notify the RSU of the address 861 duplication. If no entry with the same address exists in the DAD 862 Table, which means that an entry for the address is created, then 863 MA replies a DAC message to the RSU to confirm the uniqueness of 864 the register-requested address to the RSU. 866 4. If the address duplication is notified by the MA, the RSU deletes 867 the tentative NCE, and sends back an NS to the address- 868 registration vehicle to notify the registration failure. 869 Otherwise, the RSU changes the tentative NCE into a registered 870 NCE in its Neighbor Cache, and then send back an NS to the 871 vehicle to notify the registration success. 873 Thus, the multihop DAD is processed simultaneously with the Address 874 Registration. Note that the tentative address is not considered 875 assigned to the vehicle until the MA confirms the uniqueness of the 876 register-requested address in the multihop DAD. 878 User Vehicle Relay Vehicle RSU Mobility Anchor 879 | | | | 880 |------------------------| | | 881 | RD failed | | | 882 |------------------------| | | 883 | | | | 884 | | | | 885 |-----------NS---------->| | | 886 | | | | 887 |<--NA with Prefix Info--| | | 888 | | | | 889 | | | | 890 |--NS with Address Reg-->| | | 891 | [ARO+VPI+VSI] | | | 892 | |----- Forward NS ----->| | 893 | | | | 894 | | |-----------------| 895 | | | Same as Figure 9| 896 | | |-----------------| 897 | | | | 898 | |<--NA with Address Reg-| | 899 | | [ARO+VPI+VSI] | | 900 |<------ Forward NA -----| | | 901 | | | | 903 Figure 10: Address Registration and Multihop DAD via V2V Relay 905 If a vehicle failed to register a default router, it triggers 906 neighbor discovery to look for vehicle neighbors which can provide 907 relay service using multi-hop communication. In this specification, 908 we assumed vehicles would not emulate V2V communication and trigger 909 relay scenario only if Router Discovery(RD) failed. On the other 910 hand, at most one intermediate vehicle acts as a relay for another 911 vehicle to communicate with the RSU. 913 Since vehicles have a digital road map with the information of RSUs 914 (e.g., position and communication coverage), they can determine if 915 they are available to serve as relay vehicle. Only vehicles with 916 ability to serve as temporary relays will take action when they 917 receive relay service requests. The user vehicle can process global 918 address configuration, Address Registration and DAD through relay 919 vehicle before it enters the coverage of RSUs. See Figure 10. 921 When a user vehicle failed to directly register with a RSU, it 922 initiates neighbor discovery to detect vehicle neighbors through V2V 923 communication. Vehicle sends NS messages to connect with neighbors 924 in range. If neighbor can provide relay service, it creates a NCE 925 for user vehicle, setting its own address as relay address, and sends 926 back NA with prefix information received from RSU. 928 With receipt of NA, user vehicle configures its global address with 929 prefix information as mentioned in Section 7.1. After this, user 930 vehicle takes up to initiate the Address Registration along with DAD 931 process via relay vehicle. NS message is configured as specified in 932 Section 7.2 but indicate the relay vehicle's address as next-hop for 933 reaching the RSU. In such a case, when relay vehicle receives relay 934 request message, it will forward NS message to RSU. The procedure 935 set up on the rails except MA will include the relay vehicle's 936 address as relay address in NCE to indicate that at this moment it is 937 not a directly attached vehicle, and set the relay address as next- 938 hop address. Relay vehicle forwards DAD result information message 939 to user vehicle as soon as it received. 941 7.4. Pseudonym Handling 943 Considering the privacy protection of a vehicle, a pseudonym 944 mechanism for its link-layer address is requested. This mechanism 945 periodically modifies the link-layer address, leading to the update 946 of the corresponding IP address. A random MAC Address Generation 947 mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by 948 generating the 46 remaining bits of MAC address using a random number 949 generator. When it changes its MAC address, a vehicle should ask the 950 serving RSU to update its own NCE, and to register its IP address 951 into the MA again. 953 8. Mobility Management 955 A mobility management is required for the seamless communication of 956 vehicles moving between the RSUs. When a vehicle moves into the 957 coverage of another RSU, a different IP address is assigned to the 958 vehicle, resulting in the reconfiguration of transport-layer session 959 information (i.e., end-point IP address) to avoid service disruption. 960 Considering this issue, this document proposes a handover mechanism 961 for seamless communication. 963 Vehicle RSU Mobility Anchor 964 | | | 965 |-RS with Mobility Info->| | 966 | [VMI] | | 967 | | | 968 | |--------PBU------>| 969 | | | 970 | | | 971 | |<-------PBA-------| 972 | | | 973 | | | 974 | |===Bi-Dir Tunnel==| 975 | | | 976 | | | 977 |<----RA with prefix-----| | 978 | | | 980 Figure 11: Message Interaction for Vehicle Attachment 982 In [VIP-WAVE], the authors constructed a network-based mobility 983 management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which 984 is highly suitable to vehicular networks. This document uses a 985 mobility management procedure similar to PMIPv6 along with prefix 986 discovery. 988 Figure 11 shows the binding update flow when a vehicle entered the 989 subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined 990 in [VIP-WAVE]. When it receives RS messages from a vehicle 991 containing its mobility information (e.g., position, speed, and 992 direction), an RSU sends its MA a Proxy Binding Update (PBU) message 993 [RFC5213][RFC3775], which contains a Mobility Option for the 994 vehicle's mobility information. The MA receives the PBU and sets up 995 a Binding Cache Entry (BCE) as well as a bi-directional tunnel 996 (denoted as Bi-Dir Tunnel in Figure 11) between the serving RSU and 997 itself. Through this tunnel, all traffic packets to the vehicle are 998 encapsulated toward the RSU. Simultaneously, the MA sends back a 999 Proxy Binding Acknowledgment (PBA) message to the serving RSU. This 1000 serving RSU receives the PBA and sets up a bi-directional tunnel with 1001 the MA. After this binding update, the RSU sends back an RA message 1002 to the vehicle including its own prefix for the address 1003 autoconfiguration. 1005 Vehicle c-RSU Mobility Anchor n-RSU 1006 | | | | 1007 | |===Bi-Dir Tunnel==| | 1008 | | | | 1009 | | | | 1010 | |----DeReg PBU---->| | 1011 | | | | 1012 | | | | 1013 | |<-------PBA-------| | 1014 | | | | 1015 | | | | 1016 | | | | 1017 | | | | 1018 | | | | 1019 |---------------------------RS-------------------------->| 1020 | | 1021 | Registration step as shown in Figure 5 | 1022 | | 1023 | | |===Bi-Dir Tunnel==| 1024 | | 1025 |<--------------------------RA---------------------------| 1026 | | 1028 Figure 12: Message Interaction for Vehicle Handoff 1030 When the vehicle changes its location, the MA has to change the end- 1031 point of the tunnel for the vehicle into the new RSU's IP address. 1032 As shown in Figure 12, when the MA receives a new PBU from the new 1033 RSU, it changes the tunnel's end-point from the current RSU (c-RSU) 1034 to the new RSU (n-RSU). If there is ongoing IP packets toward the 1035 vehicle, the MA encapsulates the packets and then forwards them 1036 towards n-RSU. Through this network-based mobility management, the 1037 vehicle is not aware of any changes at its network layer and can 1038 maintain its transport-layer sessions without any disruption. 1040 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 1041 specified routes with fixed RSU allocation, the procedure can be 1042 simplified by constructing bidirectional tunnel directly between them 1043 (cancel the intervention of MA) to alleviate the traffic flow in MA 1044 as well as reduce handover delay. See Figure 13. 1046 Vehicle c-RSU n-RSU 1047 | | | 1048 |---------------------| | 1049 |c-RSU detects leaving| | 1050 |---------------------| | 1051 | |--------PBU------>| 1052 | | | 1053 | |===Bi-Dir Tunnel==| 1054 | | | 1055 | |<-------PBA-------| 1056 | | | 1057 | | | 1058 |(-------------------RS---------------->)| 1059 | | 1060 | | 1061 |<-------------------RA------------------| 1062 | | 1064 Figure 13: Vehicle Handoff between Adjacent RSUs 1066 Since RSUs are in charge of detecting when a node joins or moves 1067 through its domain, if c-RSU detects the vehicle is going to leave 1068 its coverage and enter the area of adjacent RSU, it sends a PBU 1069 message to inform n-RSU about the handover of vehicle and update its 1070 mobility information. n-RSU receives the request and construct a 1071 bidirectional tunnel between c-RSU and itself, then send back PBA 1072 message for acknowledgment. If there are ongoing IP packets, c-RSU 1073 encapsulates the packets and then forwards them to n-RSU. When n-RSU 1074 detects the entrance of the vehicle, it directly sends RA mesage to 1075 vehicle for connection establishment (or replies solicited RA if 1076 vehicle sends request RS message first). 1078 9. Security Considerations 1080 This document shares all the security issues of the neighbor 1081 discovery protocol and 6LoWPAN protocol. This document can get 1082 benefits from secure neighbor discovery (SEND) [RFC3971] in order to 1083 protect ND from possible security attacks. 1085 10. References 1087 10.1. Normative References 1089 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1090 Requirement Levels", BCP 14, RFC 2119, March 1997. 1092 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1093 in IPv6", RFC 3775, June 2004. 1095 [RFC3971] Arkko, J., "SEcure Neighbor Discovery (SEND)", RFC 3971, 1096 March 2005. 1098 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1099 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1100 September 2007. 1102 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1103 Address Autoconfiguration", RFC 4862, September 2007. 1105 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., and K. 1106 Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008. 1108 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1109 Hoc Networks", RFC 5889, September 2010. 1111 [RFC6775] Shelby, Z., Ed., "Neighbor Discovery Optimization for IPv6 1112 over Low-Power Wireless Personal Area Networks 1113 (6LoWPANs)", RFC 6775, November 2012. 1115 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1116 "IPv6 Router Advertisement Options for DNS Configuration", 1117 RFC 8106, March 2017. 1119 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1120 (IPv6) Specification", RFC 8200, July 2017. 1122 10.2. Informative References 1124 [DSRC-WAVE] 1125 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 1126 Architecture, Design, and Characteristics", 1127 IEEE Communications Surveys & Tutorials, 12(4), 2012. 1129 [ID-DNSNA] 1130 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 1131 Autoconfiguration for Internet of Things Devices", draft- 1132 jeong-ipwave-iot-dns-autoconf-05 (work in progress), March 1133 2019. 1135 [IEEE-802.11-OCB] 1136 "Part 11: Wireless LAN Medium Access Control (MAC) and 1137 Physical Layer (PHY) Specifications", IEEE Std 1138 802.11-2016, December 2016. 1140 [IEEE-802.11p] 1141 "Part 11: Wireless LAN Medium Access Control (MAC) and 1142 Physical Layer (PHY) Specifications Amendment 6: Wireless 1143 Access in Vehicular Environments", June 2010. 1145 [IPWAVE-PS] 1146 Jeong, J., Ed., "IP Wireless Access in Vehicular 1147 Environments (IPWAVE): Problem Statement and Use Cases", 1148 draft-ietf-ipwave-vehicular-networking-08 (work in 1149 progress), March 2019. 1151 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1152 February 2013. 1154 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1155 Discovery", RFC 6763, February 2013. 1157 [VIP-WAVE] 1158 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1159 Feasibility of IP Communications in 802.11p Vehicular 1160 Networks", IEEE Transactions on Intelligent Transportation 1161 Systems, vol. 14, no. 1, March 2013. 1163 [WAVE-1609.0] 1164 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1165 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1166 1609.0-2013, March 2014. 1168 [WAVE-1609.2] 1169 IEEE 1609 Working Group, "IEEE Standard for Wireless 1170 Access in Vehicular Environments - Security Services for 1171 Applications and Management Messages", IEEE Std 1172 1609.2-2016, March 2016. 1174 [WAVE-1609.3] 1175 IEEE 1609 Working Group, "IEEE Standard for Wireless 1176 Access in Vehicular Environments (WAVE) - Networking 1177 Services", IEEE Std 1609.3-2016, April 2016. 1179 [WAVE-1609.4] 1180 IEEE 1609 Working Group, "IEEE Standard for Wireless 1181 Access in Vehicular Environments (WAVE) - Multi-Channel 1182 Operation", IEEE Std 1609.4-2016, March 2016. 1184 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 1185 discovery-05 1187 The following changes are made from draft-jeong-ipwave-vehicular- 1188 neighbor-discovery-05: 1190 o In Section 4.1, a Shared-Prefix model is introduced for prefix 1191 assignment specified in this document. 1193 o In Section 4.3, design goals are refined including the 1194 cancellation of Neighbor Unreachable Detection, and also the 1195 support of multi-hop communication for vehicles not in the 1196 coverage of RSUs. 1198 o In Section 5.1, the Vehicular Network Architecture is updated on 1199 subnet division and V2V communication. 1201 o In Section 7, a new scenario is added to facilitate vehicles 1202 outside the coverage of RSU to do Address Registration and DAD via 1203 relay vehicle. 1205 o In Section 8, a simplified mobility management in vehicle handoff 1206 for adjacent RSUs is supplemented based on the original proposal. 1208 Appendix B. Acknowledgments 1210 This work was supported by Basic Science Research Program through the 1211 National Research Foundation of Korea (NRF) funded by the Ministry of 1212 Education (2017R1D1A1B03035885). 1214 This work was supported in part by Global Research Laboratory Program 1215 through the NRF funded by the Ministry of Science and ICT (MSIT) 1216 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 1217 (18-EE-01). 1219 Authors' Addresses 1221 Jaehoon Paul Jeong 1222 Department of Software 1223 Sungkyunkwan University 1224 2066 Seobu-Ro, Jangan-Gu 1225 Suwon, Gyeonggi-Do 16419 1226 Republic of Korea 1228 Phone: +82 31 299 4957 1229 Fax: +82 31 290 7996 1230 EMail: pauljeong@skku.edu 1231 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1232 Yiwen Chris Shen 1233 Department of Electrical and Computer Engineering 1234 Sungkyunkwan University 1235 2066 Seobu-Ro, Jangan-Gu 1236 Suwon, Gyeonggi-Do 16419 1237 Republic of Korea 1239 Phone: +82 31 299 4106 1240 Fax: +82 31 290 7996 1241 EMail: chrisshen@skku.edu 1243 Zhong Xiang 1244 Department of Electrical and Computer Engineering 1245 Sungkyunkwan University 1246 2066 Seobu-Ro, Jangan-Gu 1247 Suwon, Gyeonggi-Do 16419 1248 Republic of Korea 1250 Phone: +82 10 9895 1211 1251 Fax: +82 31 290 7996 1252 EMail: xz618@skku.edu