idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-07.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 (July 8, 2019) is 1752 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 695, but not defined == Missing Reference: 'ARO' is mentioned on line 798, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5889 == Outdated reference: A later version (-11) exists of draft-jeong-ipwave-vehicular-mobility-management-01 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-06 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-09 Summary: 2 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: January 9, 2020 Sungkyunkwan University 6 July 8, 2019 8 Vehicular Neighbor Discovery for IP-Based Vehicular Networks 9 draft-jeong-ipwave-vehicular-neighbor-discovery-07 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). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. ND Optimization . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Vehicular Network Architecture . . . . . . . . . . . . . . . 7 65 5.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 7 66 5.2. V2I Internetworking . . . . . . . . . . . . . . . . . . . 9 67 5.3. V2V Internetworking . . . . . . . . . . . . . . . . . . . 10 68 6. ND Extension for Prefix and Service Discovery . . . . . . . . 11 69 6.1. Vehicular Prefix Information Option . . . . . . . . . . . 11 70 6.2. Vehicular Service Information Option . . . . . . . . . . 12 71 6.3. Vehicular Mobility Information Option . . . . . . . . . . 13 72 6.4. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 14 73 6.5. Message Exchange Procedure for V2I Networking . . . . . . 15 74 7. Address Registration and Duplicate Address Detection . . . . 16 75 7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 17 76 7.2. Address Registration . . . . . . . . . . . . . . . . . . 17 77 7.3. Multihop Duplicate Address Detection . . . . . . . . . . 18 78 7.3.1. DAD without Intermediate Vehicle . . . . . . . . . . 18 79 7.3.2. DAD with one Intermediate Vehicle . . . . . . . . . . 20 80 7.3.3. DAD with multiple Intermediate Vehicles . . . . . . . 21 81 7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 22 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 85 9.2. Informative References . . . . . . . . . . . . . . . . . 23 86 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 87 discovery-06 . . . . . . . . . . . . . . . . . . . . 26 88 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 91 1. Introduction 93 Vehicular Ad Hoc Networks (VANET) have been researched for 94 Intelligent Transportation System (ITS) such as driving safety, 95 efficient driving and entertainment. Considering the high-speed 96 mobility of vehicular network based on Dedicated Short-Range 97 Communications (DSRC), IEEE 802.11p [IEEE-802.11p] has been 98 specialized and was renamed IEEE 802.11 Outside the Context of a 99 Basic Service Set (OCB) [IEEE-802.11-OCB] in 2012. IEEE has 100 standardized Wireless Access in Vehicular Environments (WAVE) 101 [DSRC-WAVE] standard which is considered as a key component in ITS. 102 IEEE 1609 standards such as IEEE 1609.0 [WAVE-1609.0], 1609.2 103 [WAVE-1609.2], 1609.3 [WAVE-1609.3], 1609.4 [WAVE-1609.4] provide a 104 low-latency and alternative network for vehicular communications. 105 What is more, IP-based vehicular networks specialized as IP Wireless 106 Access in Vehicular Environments (IPWAVE) [IPWAVE-PS] can enable many 107 use cases over vehicle-to-vehicle (V2V), vehicle-to-infrastructure 108 (V2I), and vehicle-to-everything (V2X) communications. 110 VANET features high mobility dynamics, asymmetric and lossy 111 connections, and moderate power constraint (e.g., electric cars and 112 unmanned aerial vehicles). Links among hosts and routers in VANET 113 can be considered as undetermined connectivities with constantly 114 changing neighbors described in [RFC5889]. IPv6 [RFC8200] is 115 selected as the network-layer protocol for Internet applications by 116 IEEE 1609.0 and 1609.3. However, the relatively long-time Neighbor 117 Discovery (ND) process in IPv6 [RFC4861] is not suitable in VANET 118 scenarios. 120 To support the interaction between vehicles or between vehicles and 121 Rode-Side Units (RSUs), this document specifies a Vehicular Neighbor 122 Discovery (VND) as an extension of IPv6 ND for IP-based vehicular 123 networks. VND provides vehicles with an optimized Address 124 Registration and a multihop Duplicate Address Detection (DAD) 125 mechanism. In addition, an efficient mobility management scheme is 126 proposed to support efficient V2V, V2I, and V2X communications. 127 Detailed statements of the mobility management are addressed in 128 [I-D.IPWAVE-VMM] . 130 2. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 3. Terminology 138 This document uses the terminology described in [RFC4861], [RFC4862], 139 and [RFC6775]. In addition, the following new terms are defined as 140 below: 142 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 143 [WAVE-1609.0]. 145 o Road-Side Unit (RSU): A node that has physical communication 146 devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE- 147 V2X, etc.) for wireless communications with vehicles and is also 148 connected to the Internet as a router or switch for packet 149 forwarding. An RSU is typically deployed on the road 150 infrastructure, either at an intersection or in a road segment, 151 but may also be located in car parking areas. 153 o On-Board Unit (OBU): A node that has a DSRC device for wireless 154 communications with other OBUs and RSUs, and may be connected to 155 in-vehicle devices or networks. An OBU is mounted on a vehicle. 156 It is assumed that a radio navigation receiver (e.g., Global 157 Positioning System (GPS)) is included in a vehicle with an OBU for 158 efficient navigation. 160 o Mobility Anchor (MA): A node that maintains IP addresses and 161 mobility information of vehicles in a road network to support the 162 address autoconfiguration and mobility management of them. It has 163 end-to-end connections with RSUs under its control. It maintains 164 a DAD Table recording the IP addresses of vehicles moving within 165 the communication coverage of its RSUs. 167 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 168 including compute nodes, storage nodes, and network nodes. 170 o Traffic Control Center (TCC): A node that maintains road 171 infrastructure information (e.g., RSUs, traffic signals, and loop 172 detectors), vehicular traffic statistics (e.g., average vehicle 173 speed and vehicle inter-arrival time per road segment), and 174 vehicle information (e.g., a vehicle's identifier, position, 175 direction, speed, and trajectory as a navigation path). TCC is 176 included in a vehicular cloud for vehicular networks and has MAs 177 under its management. 179 4. Overview 181 This document proposes an optimized ND with a more adaptive structure 182 for vehicular networks considering fast vehicle mobility and wireless 183 control traffic overhead related to the legacy ND. Furthermore, 184 prefix and service discovery can be implemented as part of the ND's 185 process along with an efficient Address Registration procedure and 186 DAD mechanism for moving vehicles. This document specifies a set of 187 behaviors between vehicles and RSUs to accomplish these goals. 189 4.1. Link Model 191 There is a relationship between a link and a network prefix along 192 with reachability scopes, such as link-local and global scopes. The 193 legacy IPv6 ND protocol [RFC4861] has the following link model. All 194 IPv6 nodes in the same on-link subnet, which use the same subnet 195 prefix with the on-link bit set, are reachable with each other by 196 one-hop links. The symmetry of the connectivity among the nodes is 197 preserved, that is, bidirectional connectivity among two on-link 198 nodes. However, a link model in vehicular networks (called vehicular 199 link model) should consider the asymmetry of the connectivity that 200 unidirectional links can exist due to interference in wireless 201 channels and the different levels of transmission power in wireless 202 network interfaces. 204 The on-link subnet can be constructed by one link (as a basic service 205 set) or multiple links (as an extended service set) called a multi- 206 link subnet [RFC6775]. In the legacy multi-link subnet, an all-node- 207 multicasted packet is copied and related to other links by an ND 208 proxy. On the other hand, in vehicular networks having fast moving 209 vehicles, multiple links can share the same subnet prefix for 210 operation efficiency. For example, if two wireless links under two 211 adjacent RSUs are in the same subnet, a vehicle as an IPv6 host does 212 not need to reconfigure its IPv6 address during handover between 213 those RSUs. However, the packet relay by an RSU as an ND proxy is 214 not required because such a relay can cause a broadcast storm in the 215 extended subnet. Thus, in the multi-link subnet, all-node- 216 multicasting needs to be well-calibrated to either being confined to 217 multicasting in the current link or being disseminated to other links 218 in the same subnet. 220 In a connected multihop VANET, for efficient communication, vehicles 221 in the same link of an RSU can communicate directly with each other, 222 not through the serving RSU. This direct wireless communication is 223 similar to the direct wired communication in an on-link subnet using 224 Ethernet as a wired network. The vehicular link model needs to 225 accommodate both the ad-hoc communication between vehicles and 226 infrastructure communication between a vehicle and an RSU in an 227 efficient and flexible way. Therefore, the IPv6 ND should be 228 extended to accommodate the concept of a new IPv6 link model in 229 vehicular networks. 231 To support multi-link subnet, this specification employs the Shared- 232 Prefix model for prefix assignments. A Shared-Prefix model refers to 233 an addressing model where the prefix(es) are shared by more than one 234 node. In this document, we assume that in a specified subnet, all 235 interfaces of RSUs responding for prefix assignments to vehicles hold 236 the same prefix, which ensure vehicles obtain and maintain the same 237 prefix in this subnet scope. 239 4.2. ND Optimization 241 This document takes advantage of the optimized ND for Low-Power 242 Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular 243 environments have common parts with 6LoWPAN, such as the reduction of 244 unnecessary wireless traffic by multicasting and the energy saving in 245 battery. Note that vehicles tend to be electric vehicles whose 246 energy source is from their battery. 248 In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are 249 assumed to be asymmetric and unidirectional because of changing radio 250 environment and loss signal. The authors proposed an optimized IPv6 251 ND which greatly eliminates link-scope multicast to save energy by 252 constructing new options and a new scheme for address configurations. 253 Similarly, this document proposes an improved IPv6 ND by eliminating 254 many link-scope-multicast-based ND operations, such as DAD for IPv6 255 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Thus, this 256 document suggests an extension of IPv6 ND as vehicular ND tailored 257 for vehicular networks along with new ND options (e.g., prefix 258 discovery, service discovery, and mobility information options). 260 4.3. Design Goals 262 The vehicular ND in this document has the following design goals: 264 o To perform prefix and service discovery through ND procedure; 266 o To implement host-initiated refresh of Router Advertisement (RA) 267 and remove the necessity for routers to use periodic or 268 unsolicited multicast RA to find hosts; 270 o To replace Neighbor Unreachable Detection(NUD), create Neighbor 271 Cache Entries (NCE) for all registered vehicles in RSUs and MA by 272 appending Address Registration Option (ARO) in Neighbor 273 Solicitation (NS), Neighbor Advertisement (NA) messages; 275 o To support a multihop DAD with two new ICMPv6 messages called 276 Duplicate Address Request(DAR) and Duplicate Address 277 Confirmation(DAC) to eliminate multicast storms and save energy; 278 and 280 o To support multi-hop communication for vehicles outside the 281 coverage of RSUs to communicate with the serving RSU via a relay 282 neighbor. 284 5. Vehicular Network Architecture 286 This section describes a vehicular network architecture for V2V and 287 V2I communication. A vehicle and an RSU have their internal networks 288 including in-vehicle devices or servers, respectively. 290 5.1. Vehicular Network 292 A vehicular network architecture for V2I and V2V is illustrated in 293 Figure 1. Three RSUs are deployed along roadsides and are connected 294 to an MA through wired links. There are two subnets such as Subnet1 295 and Subnet2. The wireless links of RSU1 and RSU2 belong to the same 296 subnet named Subnet1, but the wireless link of RSU3 belongs to 297 another subnet named Subnet2. Vehicle2 is wirelessly connected to 298 RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 and RSU3, 299 respectively. Vehicles can directly communicate with each other 300 through V2V connection (e.g., Vehicle1 and Vehicle2) to share driving 301 information. In addition, vehicles not in the range of any RSU may 302 connect with RSU in multi-hop connection via relay vehicle (e.g., 303 Vehicle1 can contact RSU1 via Vehicle2). Vehicles are assumed to 304 start the connection to an RSU when they entered the coverage of the 305 RSU. 307 The document recommends a multi-link subnet involving multiple RSUs 308 as shown in Figure 1. This recommendation aims at the reduction of 309 the frequency with which vehicles have to change their IP address 310 during handover between two adjacent RSUs. To construct this multi- 311 link subnet, a Shared-Prefix model is proposed. That is, for RSUs in 312 the same subnet, the interfaces responsible for prefix assignment for 313 vehicles should hold the same prefix in their global address. This 314 also promises vehicles achieve the same prefix in this scope. When 315 they pass through RSUs in the same subnet, vehicles do not need to 316 perform the Address Registration and DAD again because they can use 317 their current IP address in the wireless coverage of the next RSU. 318 Moreover, this proposal accord with the assumption that noes 319 belonging to the same IP prefix are able to communicate with each 320 other directly. On the other hand, if vehicles enter the wireless 321 coverage of an RSU belonging to another subnet with a different 322 prefix, they repeat the Address Registration and DAD procedure to 323 update their IP address with the new prefix. 325 Traffic Control Center in Vehicular Cloud 326 *-----------------------------------------* 327 * * 328 * +----------------+ * 329 * | Mobility Anchor| * 330 * +----------------+ * 331 * ^ * 332 * | * 333 *--------------------v--------------------* 334 ^ ^ ^ 335 | | | 336 | | | 337 v v v 338 +--------+ Ethernet +--------+ +--------+ 339 | RSU1 |<-------->| RSU2 |<---------->| RSU3 | 340 +--------+ +--------+ +--------+ 341 ^ ^ ^ 342 : : : 343 +-------------------------------------+ +-----------------+ 344 | : V2I V2I : | | V2I : | 345 | v v | | v | 346 +--------+ | +--------+ +--------+ | | +--------+ | 347 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 348 | |<...>| |<........>| | | | | | | 349 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 350 | | | | 351 +-------------------------------------+ +-----------------+ 352 Subnet1 Subnet2 354 <----> Wired Link <....> Wireless Link ===> Moving Direction 356 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 358 In Figure 1, RSU1 and RSU2 are deployed in a multi-link subnet with 359 the same prefix address in their interfaces responding for connection 360 with vehicles. When vehicle2 leaves the coverage of RSU1 and enters 361 RSU2, it maintains its address configuration and ignores Address 362 Registration and DAD steps. If vehicle2 moves into the coverage of 363 RSU3, since RSU3 belongs to another subnet and holds a different 364 prefix from RSU1 and RSU2, so vehicle2 must do Address Registration 365 and DAD just as connecting to a new RSU. Note that vehicles and RSUs 366 have their internal networks including in-vehicle devices and 367 servers, respectively. The structures of the internal networks are 368 described in Section 5.2. 370 5.2. V2I Internetworking 372 This subsection explains V2I internteworking between a vehicle 373 network and a RSU network where the vehicle network is an internal 374 network in a vehicle, and the RSU network is an internal network in 375 an RSU, as shown in Figure 2. 377 +-----------------+ 378 (*)<........>(*) +----->| Vehicular Cloud | 379 2001:DB8:1:1::/64 | | | +-----------------+ 380 +------------------------------+ +---------------------------------+ 381 | v | | v v | 382 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 383 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 384 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 385 | ^ ^ ^ | | ^ ^ ^ | 386 | | | | | | | | | | 387 | v v v | | v v v | 388 | ---------------------------- | | ------------------------------- | 389 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 390 | | | | | | 391 | v | | v | 392 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 393 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 394 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 395 | ^ ^ | | ^ ^ ^ | 396 | | | | | | | | | 397 | v v | | v v v | 398 | ---------------------------- | | ------------------------------- | 399 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 400 +------------------------------+ +---------------------------------+ 401 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 403 <----> Wired Link <....> Wireless Link (*) Antenna 405 Figure 2: Internetworking between Vehicle Network and RSU Network 407 Figure 2 shows the V2I networking of a vehicle and an RSU whose 408 internal networks are Moving Network1 and Fixed Network1, 409 respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts 410 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 411 has the DNS Server (RDNSS3), one host (Host5), the two routers 412 (Router5 and Router6). 414 It is assumed that RSU1 has a collection of servers (Server1 to 415 ServerN) for various services in the road networks, such as road 416 emergency notification and navigation services. Vehicle1's Router1 417 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., 418 DSRC) for I2V networking for various vehicular services. Vehicular 419 applications, such as road emergency notification and navigation 420 services, can be registered into the DNS Server (i.e., RDNSS) through 421 DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS options in 422 [RFC8106]. 424 Vehicle1's Router1 and RSU1's Router5 can know what vehicular 425 applications exist in their internal network by referring to their 426 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 427 what network prefixes exist in their internal network through an 428 intra-domain routing protocol, such as OSFP. Each vehicle and each 429 RSU announce their network prefixes and services through ND options 430 defined in Section 6. 432 5.3. V2V Internetworking 434 This subsection explains V2V internteworking between vehicle 435 networks, which are internal networks in vehicles, as shown in 436 Figure 3. 438 (*)<..........>(*) 439 2001:DB8:1:1::/64 | | 440 +------------------------------+ +------------------------------+ 441 | v | | v | 442 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 443 | | Host1 | |RDNSS1| |Router1| | | |Router5| |RDNSS3| | Host4 | | 444 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 445 | ^ ^ ^ | | ^ ^ ^ | 446 | | | | | | | | | | 447 | v v v | | v v v | 448 | ---------------------------- | | ---------------------------- | 449 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 450 | | | | | | 451 | v | | v | 452 | +-------+ +-------+ | | +-------+ +-------+ | 453 | | Host2 | |Router2| | | |Router6| | Host5 | | 454 | +-------+ +-------+ | | +-------+ +-------+ | 455 | ^ ^ | | ^ ^ | 456 | | | | | | | | 457 | v v | | v v | 458 | ---------------------------- | | ---------------------------- | 459 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 460 +------------------------------+ +------------------------------+ 461 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 463 <----> Wired Link <....> Wireless Link (*) Antenna 465 Figure 3: Internetworking between Vehicle Networks 467 Figure 3 shows the V2V networking of two vehicles whose internal 468 networks are Moving Network1 and Moving Network2, respectively. 469 Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and 470 Host2), and the two routers (Router1 and Router2). Vehicle2 has the 471 DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two 472 routers (Router3 and Router4). 474 It is assumed that Host1 and Host3 are running a Cooperative Adaptive 475 Cruise Control (C-ACC) program for physical collision avoidance. 476 Also, it is assumed that Host2 and Host4 are running a Cooperative 477 On-board Camera Sharing (C-OCS) program for sharing road hazards or 478 obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's 479 Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 480 V2V networking for various vehicular services. Vehicular 481 applications, such as C-ACC and C-BCS, can be registered into the DNS 482 Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with 483 IPv6 ND DNS options in [RFC8106]. 485 Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular 486 applications exist in their internal network by referring to their 487 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 488 what network prefixes exist in their internal network through an 489 intra-domain routing protocol, such as OSFP. Each vehicle announces 490 its network prefixes and services through ND options defined in 491 Section 6. 493 6. ND Extension for Prefix and Service Discovery 495 This section specifies an IPv6 ND extension for vehicle-to-vehicle 496 (V2V) or vehicle-to-infrastructure (V2I) networking. This section 497 also defines three new ND options for prefix discovery, service 498 discovery, and mobility information report: (i) Vehicular Prefix 499 Information (VPI) option, (ii) Vehicular Service Information (VSI) 500 option, and (iii) Vehicular Mobility Information (VMI) option. It 501 also describes the procedure of the ND protocol with those options. 503 6.1. Vehicular Prefix Information Option 505 The VPI option contains IPv6 prefix informations in the internal 506 network. Figure 4 shows the format of the VPI option. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type | Length | Prefix Length | Distance | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Reserved | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | | 516 : Prefix : 517 | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 4: Vehicular Prefix Information (VPI) Option Format 522 Fields: 523 Type 8-bit identifier of the VPI option type as assigned 524 by the IANA: TBD 526 Length 8-bit unsigned integer. The length of the option 527 (including the Type and Length fields) is in units of 528 8 octets. The value is 3. 530 Prefix Length 8-bit unsigned integer. The number of leading bits 531 in the Prefix that are valid. The value ranges 532 from 0 to 128. 534 Distance 8-bit unsigned integer. The distance between the 535 subnet announcing this prefix and the subnet 536 corresponding to this prefix in terms of the number 537 of hops. 539 Reserved This field is unused. It MUST be initialized to 540 zero by the sender and MUST be ignored by the 541 receiver. 543 Prefix An IP address or a prefix of an IP address. The 544 Prefix Length field contains the number of valid 545 leading bits in the prefix. The bits in the prefix 546 after the prefix length are reserved and MUST be 547 initialized to zero by the sender and ignored by 548 the receiver. 550 6.2. Vehicular Service Information Option 552 The VSI option contains vehicular service information in the internal 553 network. Figure 5 shows the format of the VSI option. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length | Reserved1 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Protocol | Reserved2 | Port Number | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 : Node Address : 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 5: Vehicular Service Information (VSI) Option Format 569 Fields: 570 Type 8-bit identifier of the VSI option type as assigned 571 by the IANA: TBD 573 Length 8-bit unsigned integer. The length of the option 574 (including the Type and Length fields) is in units of 575 8 octets. The value is 3. 577 Reserved1 This field is unused. It MUST be initialized to 578 zero by the sender and MUST be ignored by the 579 receiver. 581 Protocol 8-bit unsigned integer to indicate the upper-layer 582 protocol, such as transport-layer protocol (e.g., 583 TCP, UDP, and SCTP). 585 Reserved2 This field is unused. It MUST be initialized to 586 zero by the sender and MUST be ignored by the 587 receiver. 589 Port Number 16-bit unsigned integer to indicate the port number 590 for this protocol. 592 Service Address 593 128-bit IPv6 address of a node proving this vehicular 594 service. 596 6.3. Vehicular Mobility Information Option 598 The VMI option contains one vehicular mobility information of a 599 vehicle or an RSU. Figure 6 shows the format of the VMI option. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type | Length | Reserved1 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Reserved2 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | 609 : Mobility Information : 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 6: Vehicular Mobility Information (VMI) Option Format 615 Fields: 616 Type 8-bit identifier of the VMI option type as assigned 617 by the IANA: TBD 619 Length 8-bit unsigned integer. The length of the option 620 (including the Type and Length fields) is in units of 621 8 octets. The value is 3. 623 Reserved1 This field is unused. It MUST be initialized to 624 zero by the sender and MUST be ignored by the 625 receiver. 627 Reserved2 This field is unused. It MUST be initialized to 628 zero by the sender and MUST be ignored by the 629 receiver. 631 Mobility Information 632 128-bit mobility information, such as position, 633 speed, and direction. 635 6.4. Vehicular Neighbor Discovery 637 Prefix discovery enables hosts (e.g., vehicles and in-vehicle 638 devices) to distinguish destinations on the same link from those only 639 reachable via RSUs. A vehicle (or its in-vehicle devices) can 640 directly communicate with on-link vehicles (or their in-vehicle 641 devices) without the relay of an RSU, but through V2V communications 642 along with VPI ND option. This VPI option contains IPv6 prefixes in 643 a vehicle's internal network. 645 Vehicles announce services in their internal networks to other 646 vehicles through an VSI ND option. The VSI option contains a list of 647 vehicular services in a vehicle's or an RSU's internal network. 649 A vehicle periodically announces an NS message containing VPI and VSI 650 options with its prefixes and services in all-nodes multicast address 651 to reach all neighboring nodes. When it receives this NS message, 652 another neighboring node responds to this NS message by sending an NA 653 message containing the VPI and VSI options with its prefixes and 654 services via unicast towards the NS-originating node. 656 Therefore, prefix and service discovery can be achieved via ND 657 messages (e.g., NS and NA) by vehicular ND with VPI and VSI options. 658 This VND-based discovery eliminates an additional prefix and service 659 discovery scheme, such as DNS-based Service Discovery [RFC6763] 660 (e.g., Multicast DNS (mDNS) [RFC6762] and DNSNA [ID-DNSNA]), other 661 than ND. That is, vehicles and RSUs can rapidly discover the network 662 prefixes and services of the other party without any additional 663 service discovery protocol. 665 6.5. Message Exchange Procedure for V2I Networking 667 This subsection explains a message exchange procedure for VND in V2I 668 networking, where a vehicle communicates with its corresponding node 669 in the Internet via an RSU. 671 Figure 7 shows an example of message exchange procedure in V2I 672 networking. Detailed steps of the procedure are explained in 673 Section 7. The mobility management part is described in 674 [I-D.IPWAVE-VMM]. 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 MA 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 a relay neighbor to 755 share the prefix obtained from RSU and undertake DAD of the user 756 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 7.3.1. DAD without Intermediate Vehicle 828 Figure 9 presents the procedure of Address Registration and multihop 829 DAD. The detailed steps are explained as follows. 831 Vehicle RSU MA 832 | | | 833 | | | 834 1. |--NS with Address Reg-->| | 835 | [ARO+VPI+VSI] | | 836 | | | 837 | | | 838 2. | | -------DAR------>| 839 | | | 840 | | | 841 3. | |<-------DAC-------| 842 | | | 843 | | | 844 | | | 845 4. |<--NA with Address Reg--| | 846 | [ARO+VPI+VSI] | | 848 Figure 9: Neighbor Discovery Address Registration with Multihop DAD 850 1. A vehicle sends an NS message to the current RSU in unicast, 851 containing the ARO to RSU to register its address. 853 2. The RSU receives the NS message, and then inspects its Neighbor 854 Cache to check whether it is duplicate or not. If there is no 855 duplicate NCE, a tentative NCE is created for this address, and 856 then the RSU sends DAR to the MA for the multihop DAD. 858 3. When the MA receives DAR from an RSU, it checks whether the 859 register-requested address exists in its DAD Table or not. If an 860 entry with the same address exists in the DAD Table, which means 861 that the address is considered "Duplicate Address", then MA 862 returns a DAC message to notify the RSU of the address 863 duplication. If no entry with the same address exists in the DAD 864 Table, which means that an entry for the address is created, then 865 MA replies a DAC message to the RSU to confirm the uniqueness of 866 the register-requested address to the RSU. 868 4. If the address duplication is notified by the MA, the RSU deletes 869 the tentative NCE, and sends back an NS to the address- 870 registration vehicle to notify the registration failure. 871 Otherwise, the RSU changes the tentative NCE into a registered 872 NCE in its Neighbor Cache, and then send back an NS to the 873 vehicle to notify the registration success. 875 Thus, the multihop DAD is processed simultaneously with the Address 876 Registration. Note that the tentative address is not considered 877 assigned to the vehicle until the MA confirms the uniqueness of the 878 register-requested address in the multihop DAD. 880 7.3.2. DAD with one Intermediate Vehicle 882 If a vehicle failed to register a default router, it triggers 883 neighbor discovery to look for vehicle neighbors which can provide 884 relay service using multi-hop communication. In this specification, 885 we assumed vehicles would not emulate V2V communication and trigger 886 relay scenario only if Router Discovery(RD) failed. 888 User Vehicle Relay Vehicle RSU MA 889 | | | | 890 |------------------------| | | 891 | RD failed | | | 892 |------------------------| | | 893 | | | | 894 | | | | 895 |-----------NS---------->| | | 896 | | | | 897 |<--NA with Prefix Info--| | | 898 | | | | 899 | | | | 900 |--NS with Address Reg-->| | | 901 | [ARO+VPI+VSI] | | | 902 | |----- Forward NS ----->| | 903 | | | | 904 | | |-----------------| 905 | | | Same as Figure 9| 906 | | |-----------------| 907 | | | | 908 | |<--NA with Address Reg-| | 909 | | [ARO+VPI+VSI] | | 910 |<------ Forward NA -----| | | 911 | | | | 913 Figure 10: Address Registration and Multihop DAD via V2V Relay 915 Since vehicles have a digital road map with the information of RSUs 916 (e.g., position and communication coverage), they can determine if 917 they are available to serve as a relay vehicle. Only vehicles with 918 the ability to serve as temporary relays will take action when they 919 receive relay service requests. The user vehicle can process global 920 address configuration, Address Registration and DAD through its relay 921 vehicle before it enters the coverage of RSUs. See Figure 10. 923 When a user vehicle failed to directly register to an RSU, it 924 initiates neighbor discovery to detect vehicle neighbors through V2V 925 communication. Vehicle sends NS messages to connect with neighbors 926 in range. If neighbor can provide relay service, it creates a NCE 927 for user vehicle, setting its own address as relay address, and sends 928 back NA with prefix information received from RSU. 930 To guarantee vehicles could find the nearest neighbor from multiple 931 neighbors which can act as relay vehicles, a new time-out mechanism 932 is presented to select the nearest neighbor by hop distance parameter 933 carried in Prefix Information Option. That is, a user vehicle 934 multicast NS messages to look for relay vehicles after RD failed and 935 wait for 1.5 seconds to receive all NA replies from neighbors. Each 936 NA carries its own global prefix(es) and the hop distance(s) in 937 Prefix Information Option. The user vehicle preserves every NA reply 938 in a temporary router list and select the one with least hop counts 939 as its relay vehicle after time out. 941 With receipt of NA, user vehicle configures its global address with 942 prefix information as mentioned in Section 7.1. After this, user 943 vehicle takes up to initiate the Address Registration along with DAD 944 process via relay vehicle. NS message is configured as specified in 945 Section 7.2 but indicate the relay vehicle's address as next-hop to 946 reach the RSU. In such a case, when relay vehicle receives relay 947 request message, it will forward NS message to RSU. The procedure 948 set up on the rails except MA will include the relay vehicle's 949 address as relay address in NCE to indicate that at this moment, it 950 is not a directly attached vehicle, and set the relay address as 951 next-hop address. Relay vehicle forwards DAD result information 952 message to user vehicle as soon as it received. 954 7.3.3. DAD with multiple Intermediate Vehicles 956 This document supports multihop communications (e.g., multihop DAD 957 and UDP transmission) for remote vehicles through multiple relay 958 vehicles. Vehicles which have already finished DAD process can serve 959 as temporary routers and forward packets for remote vehicles. 961 A new routing mechanism is specified to accomplish route selections 962 among user vehicles and serving RSUs when multiple vehicles act as 963 relay vehicles. Taking advantage of the Destination-Sequenced 964 Distance-Vector routing protocol (DSDV) [DSDV], this new routing 965 approach supposes that each vehicle holds a Neighbor Routing 966 Table which integrates the neighbor information in Neighbor Cache and 967 forwarding records for remote vehicles. Each vehicle which acts as a 968 relay vehicle for this remote vehicle will make records in its 969 Neighbor Routing Table. 971 Figure 11 specifies an example of parameters in Neighbor Routing 972 Table when more than one vehicle work as intermediate relay vehicles. 974 In Figure 11, Vehicle3 connects RSU1 indirectly via Vehicle2 and 975 Vehicle3. When Vehicle2 and Vehicle3 forward messages for Vehicle1, 976 they make records in its Neighbor Routing Table including the next- 977 hop node to indicate the route to Vehicle3. This can ensure that the 978 packete from a source vehicle can be successfully transmitted to an 979 RSU as well as the reverse packet path exists from the RSU to the 980 source vehicle. 982 +--------+ +--------+ +--------+ +--------+ 983 |Vehicle3|<......>|Vehicle2|<........>|Vehicle1|<.......> | RSU1 | 984 | (V3) | V2V | (V2) | V2V | (V1) | V2I | | 985 +--------+ +--------+ +--------+ +--------+ 987 +------------+ +------------+ +------------+ +------------+ 988 |Node|NextHop| |Node|NextHop| |Node|NextHop| |Node|NextHop| 989 +------------+ +------------+ +------------+ +------------+ 990 | V2 | V2 | | V1 | V1 | |RSU1| RSU1 | | V1 | V1 | 991 +------------+ | V3 | V3 | | V2 | V2 | | V2 | V1 | 992 +------------+ | V3 | V2 | | V3 | V1 | 993 +------------+ +------------+ 995 Figure 11: An Exmaple of Neighbor Routing Table when multiple 996 Vehicles act as Relay Vehicles 998 7.4. Pseudonym Handling 1000 Considering the privacy protection of a vehicle, a pseudonym 1001 mechanism for its link-layer address is requested. This mechanism 1002 periodically modifies the link-layer address, leading to the update 1003 of the corresponding IP address. A random MAC Address Generation 1004 mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by 1005 generating the 46 remaining bits of MAC address using a random number 1006 generator. When it changes its MAC address, a vehicle should ask the 1007 serving RSU to update its own NCE, and to register its IP address 1008 into the MA again. 1010 8. Security Considerations 1012 This document shares all the security issues of the neighbor 1013 discovery protocol and 6LoWPAN protocol. This document can get 1014 benefits from secure neighbor discovery (SEND) [RFC3971] in order to 1015 protect ND from possible security attacks. 1017 9. References 1019 9.1. Normative References 1021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", BCP 14, RFC 2119, March 1997. 1024 [RFC3971] Arkko, J., "SEcure Neighbor Discovery (SEND)", RFC 3971, 1025 March 2005. 1027 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1028 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1029 September 2007. 1031 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1032 Address Autoconfiguration", RFC 4862, September 2007. 1034 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1035 Hoc Networks", RFC 5889, September 2010. 1037 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1038 February 2013. 1040 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1041 Discovery", RFC 6763, February 2013. 1043 [RFC6775] Shelby, Z., Ed., "Neighbor Discovery Optimization for IPv6 1044 over Low-Power Wireless Personal Area Networks 1045 (6LoWPANs)", RFC 6775, November 2012. 1047 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1048 "IPv6 Router Advertisement Options for DNS Configuration", 1049 RFC 8106, March 2017. 1051 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1052 (IPv6) Specification", RFC 8200, July 2017. 1054 9.2. Informative References 1056 [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 1057 Sequenced Distance-Vector Routing (DSDV) for Mobile 1058 Computers", ACM SIGCOMM, August 1994. 1060 [DSRC-WAVE] 1061 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 1062 Architecture, Design, and Characteristics", 1063 IEEE Communications Surveys & Tutorials, 12(4), 2012. 1065 [I-D.IPWAVE-VMM] 1066 Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular 1067 Mobility Management for IP-Based Vehicular Networks", 1068 draft-jeong-ipwave-vehicular-mobility-management-01 (work 1069 in progress), July 2019. 1071 [ID-DNSNA] 1072 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 1073 Autoconfiguration for Internet of Things Devices", draft- 1074 jeong-ipwave-iot-dns-autoconf-06 (work in progress), July 1075 2019. 1077 [IEEE-802.11-OCB] 1078 "Part 11: Wireless LAN Medium Access Control (MAC) and 1079 Physical Layer (PHY) Specifications", IEEE Std 1080 802.11-2016, December 2016. 1082 [IEEE-802.11p] 1083 "Part 11: Wireless LAN Medium Access Control (MAC) and 1084 Physical Layer (PHY) Specifications Amendment 6: Wireless 1085 Access in Vehicular Environments", June 2010. 1087 [IPWAVE-PS] 1088 Jeong, J., Ed., "IP Wireless Access in Vehicular 1089 Environments (IPWAVE): Problem Statement and Use Cases", 1090 draft-ietf-ipwave-vehicular-networking-09 (work in 1091 progress), May 2019. 1093 [VIP-WAVE] 1094 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1095 Feasibility of IP Communications in 802.11p Vehicular 1096 Networks", IEEE Transactions on Intelligent Transportation 1097 Systems, vol. 14, no. 1, March 2013. 1099 [WAVE-1609.0] 1100 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1101 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1102 1609.0-2013, March 2014. 1104 [WAVE-1609.2] 1105 IEEE 1609 Working Group, "IEEE Standard for Wireless 1106 Access in Vehicular Environments - Security Services for 1107 Applications and Management Messages", IEEE Std 1108 1609.2-2016, March 2016. 1110 [WAVE-1609.3] 1111 IEEE 1609 Working Group, "IEEE Standard for Wireless 1112 Access in Vehicular Environments (WAVE) - Networking 1113 Services", IEEE Std 1609.3-2016, April 2016. 1115 [WAVE-1609.4] 1116 IEEE 1609 Working Group, "IEEE Standard for Wireless 1117 Access in Vehicular Environments (WAVE) - Multi-Channel 1118 Operation", IEEE Std 1609.4-2016, March 2016. 1120 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 1121 discovery-06 1123 The following changes are made from draft-jeong-ipwave-vehicular- 1124 neighbor-discovery-06: 1126 o The Mobility Management Section is removed and moved to 1127 [I-D.IPWAVE-VMM]. 1129 o In Section 7.3, an arbitrary number of intermediate vehicles can 1130 be used between source vehicles and RSUs for the address 1131 registration along with multihop DAD. 1133 o In Section 7.3.2, a new waiting mechanism is defined to guarantee 1134 vehicles to find a neighbor vehicle (as a relay node) closest to 1135 an RSU in order to connect to the RSU. 1137 o In Section 7.3.3, a new routing mechanism is proposed to extend 1138 the IPv6 neighbor discovery protocol for routing among vehicles 1139 and RSUs. An example of Neighbor Routing Table is specialized to 1140 explain the routing service. 1142 Appendix B. Acknowledgments 1144 This work was supported by Basic Science Research Program through the 1145 National Research Foundation of Korea (NRF) funded by the Ministry of 1146 Education (2017R1D1A1B03035885). 1148 This work was supported by the MSIT (Ministry of Science and ICT), 1149 Korea, under the ITRC (Information Technology Research Center) 1150 support program (IITP-2019-2017-0-01633) supervised by the IITP 1151 (Institute for Information & communications Technology Promotion). 1153 Authors' Addresses 1155 Jaehoon Paul Jeong 1156 Department of Computer Science and Engineering 1157 Sungkyunkwan University 1158 2066 Seobu-Ro, Jangan-Gu 1159 Suwon, Gyeonggi-Do 16419 1160 Republic of Korea 1162 Phone: +82 31 299 4957 1163 Fax: +82 31 290 7996 1164 EMail: pauljeong@skku.edu 1165 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1166 Yiwen Chris Shen 1167 Department of Electrical and Computer Engineering 1168 Sungkyunkwan University 1169 2066 Seobu-Ro, Jangan-Gu 1170 Suwon, Gyeonggi-Do 16419 1171 Republic of Korea 1173 Phone: +82 31 299 4106 1174 Fax: +82 31 290 7996 1175 EMail: chrisshen@skku.edu 1177 Zhong Xiang 1178 Department of Electrical and Computer Engineering 1179 Sungkyunkwan University 1180 2066 Seobu-Ro, Jangan-Gu 1181 Suwon, Gyeonggi-Do 16419 1182 Republic of Korea 1184 Phone: +82 10 9895 1211 1185 Fax: +82 31 290 7996 1186 EMail: xz618@skku.edu