idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-05.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 (November 8, 2018) is 1996 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 856, but not defined == Missing Reference: 'ARO' is mentioned on line 761, 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-04 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-07 Summary: 3 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: May 12, 2019 Sungkyunkwan University 6 November 8, 2018 8 IPv6 Neighbor Discovery for IP-Based Vehicular Networks 9 draft-jeong-ipwave-vehicular-neighbor-discovery-05 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 established for both operation 17 efficiency and the saving of wireless bandwidth and vehicle energy. 18 Also, the three new ND options for prefix discovery, service 19 discovery, and mobility information report are used to announce the 20 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 May 12, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 5 66 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Vehicular Network Architecture . . . . . . . . . . . . . . . 6 68 5.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 6 69 5.2. V2I Internetworking . . . . . . . . . . . . . . . . . . . 9 70 5.3. V2V Internetworking . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . 14 77 7. Address Registration and Duplicate Address Detection . . . . 16 78 7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 16 79 7.2. Address Registration . . . . . . . . . . . . . . . . . . 16 80 7.3. Multihop Duplicate Address Detection . . . . . . . . . . 17 81 7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 19 82 8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 19 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 86 10.2. Informative References . . . . . . . . . . . . . . . . . 22 87 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 88 discovery-04 . . . . . . . . . . . . . . . . . . . . 24 89 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 Unit (RSU), 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, which has a more adaptive 181 structure for vehicular networks considering fast vehicle mobility 182 and wireless control traffic overhead related to the ND. Further 183 more, prefix and service discovery can be implemented as part of the 184 ND's process along with an efficient Address Registration procedure 185 and DAD mechanism for moving vehicles. This document specifies a set 186 of 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. On the 197 other hand, 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 relay of the 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 4.2. ND Optimization 232 This document takes advantage of the optimized ND for Low-Power 233 Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular 234 environments have common parts with 6LoWPAN, such as the reduction of 235 unnecessary wireless traffic by multicasting and the energy saving in 236 battery. Note that vehicles tend to be electric vehicles whose 237 energy source is from their battery. 239 In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are 240 assumed to be asymmetric and unidirectional because of changing radio 241 environment and loss signal. The authors proposed an improved IPv6 242 ND which greatly eliminates link-scope multicast to save energy by 243 constructing new options and a new scheme for address configurations. 244 Similarly, this document proposes an improved IPv6 ND by eliminating 245 many link-scope-multicast-based ND operations, such as DAD for IPv6 246 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Thus, this 247 document suggests an extension of IPv6 ND as vehicular ND tailored 248 for vehicular networks along with new ND options (e.g., prefix 249 discovery, service discovery, and mobility information options). 251 4.3. Design Goals 253 The vehicular ND in this document has the following design goals: 255 o To perform prefix and service discovery through ND procedure; 257 o To implement host-initiated refresh of Router Advertisement (RA) 258 and remove the need for routers to use periodic or unsolicited 259 multicast RA to find hosts; 261 o To create Neighbor Cache Entries (NCE) for all registered vehicles 262 in RSUs by adding Address Registration Option (ARO) in Neighbor 263 Solicitation (NS), Neighbor Advertisement (NA) messages; 265 o To support a multihop DAD with two new ICMPv6 messages called 266 Duplicate Address Request(DAR) and Duplicate Address 267 Confirmation(DAC) to eliminate multicast storm and save energy; 268 and 270 o To provide a mobility management mechanism for seamless 271 communication during a vehicle's travel in subnets via RSUs. 273 5. Vehicular Network Architecture 275 This section describes a vehicular network architecture for V2V and 276 V2I communication. A vehicle and an RSU have their internal networks 277 having in-vehicle devices or servers, respectively. 279 5.1. Vehicular Network 281 A vehicular network architecture for V2I and V2V is illustrated in 282 Figure 1. Three RSUs are deployed along roadside and are connected 283 to an MA through wired links. There are two subnets such as Subnet1 284 and Subnet2. The wireless links of RSU1 and RSU2 belong to the same 285 subnet named Subnet1, but the wireless link of RSU3 belongs to 286 another subnet named Subnet2. Vehicle1 and Vehicle2 are wirelessly 287 connected to RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 288 and RSU3, respectively. Vehicles can directly communicate with each 289 other through V2V connection (e.g., Vehicle1 and Vehicle2) to share 290 driving information. Vehicles are assumed to start the connection to 291 an RSU when they entered the coverage of the RSU. 293 Traffic Control Center in Vehicular Cloud 294 *-----------------------------------------* 295 * * 296 * +----------------+ * 297 * | Mobility Anchor| * 298 * +----------------+ * 299 * ^ * 300 * | * 301 *--------------------v--------------------* 302 ^ ^ ^ 303 | | | 304 +------------------ | -------------|-------------+ +------------------+ 305 | v v | | v | 306 | +--------+ Ethernet +--------+ | | +--------+ | 307 | | RSU1 |<----------->| RSU2 |<---------->| RSU3 | | 308 | +--------+ +--------+ | | +--------+ | 309 | ^ ^ ^ | | ^ | 310 | : : : | | : | 311 | V2I : : V2I V2I : | | V2I : | 312 | v v v | | v | 313 | +--------+ +--------+ +--------+ | | +--------+ | 314 | |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 315 | | |<....>| |<....>| | | | | | | 316 | +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 317 | | | | 318 +-------------------------------------------------+ +------------------+ 319 Subnet1 Subnet2 321 <----> Wired Link <....> Wireless Link ===> Moving Direction 323 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 325 The document recommends a multi-link subnet involving multiple RSUs, 326 as shown in Figure 1. This recommendation aims at the reduction of 327 the frequency with which vehicles have to change their IP address 328 during handover between two adjacent RSUs. When they pass through 329 RSUs in the same subnet, vehicles do not need to perform the Address 330 Registration and DAD again because they can use their current IP 331 address in the wireless coverage of the next RSU, belonging to the 332 same subnet. On the other hand, if they enter the wireless coverage 333 of an RSU belonging to another subnet with a different prefix, 334 vehicles repeat the Address Registration and DAD procedure to update 335 their IP address with the new prefix. 337 In Figure 1, RSU1 and RSU2 are deployed in the a multi-link subnet 338 with the same prefix in their address. When vehicle1 leaves the 339 coverage of RSU1 and enters RSU2, it maintains its address and 340 ignores Address Registration and DAD steps. If vehicle1 moves into 341 the coverage of RSU3, since RSU3 belongs to another subnet and holds 342 a different prefix from RSU1 and RSU2, so vehicles must do Address 343 Registration and DAD just as connecting to a new RSU. Note that 344 vehicles and RSUs have their internal networks having in-vehicle 345 devices and servers, respectively. The structures of the internal 346 networks are described in [IPWAVE-PS]. 348 +-----------------+ 349 (*)<........>(*) +----->| Vehicular Cloud | 350 2001:DB8:1:1::/64 | | | +-----------------+ 351 +------------------------------+ +---------------------------------+ 352 | v | | v v | 353 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 354 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 355 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 356 | ^ ^ ^ | | ^ ^ ^ | 357 | | | | | | | | | | 358 | v v v | | v v v | 359 | ---------------------------- | | ------------------------------- | 360 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 361 | | | | | | 362 | v | | v | 363 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 364 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 365 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 366 | ^ ^ | | ^ ^ ^ | 367 | | | | | | | | | 368 | v v | | v v v | 369 | ---------------------------- | | ------------------------------- | 370 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 371 +------------------------------+ +---------------------------------+ 372 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 374 <----> Wired Link <....> Wireless Link (*) Antenna 376 Figure 2: Internetworking between Vehicle Network and RSU Network 378 5.2. V2I Internetworking 380 This subsection explains V2I internteworking between vehicle network 381 and RSU network where vehicle network is an internal network in a 382 vehicle, and RSU network is an internal network in an RSU, as shown 383 in Figure 2. 385 Figure 2 shows the V2I networking of a vehicle and an RSU whose 386 internal networks are Moving Network1 and Fixed Network1, 387 respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts 388 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 389 has the DNS Server (RDNSS3), one host (Host5), the two routers 390 (Router5 and Router6). 392 It is assumed that RSU1 has a collection of servers (Server1 to 393 ServerN) for various services in the road networks, such as road 394 emergency notification and navigation services. Vehicle1's Router1 395 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., 396 DSRC) for I2V networking for various vehicular services. The 397 vehicular applications, such as road emergency notification and 398 navigation services, can be registered into the DNS Server (i.e., 399 RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS 400 options in [RFC8106]. 402 Vehicle1's Router1 and RSU1's Router5 can know what vehicular 403 applications exist in their internal network by referring to their 404 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 405 what network prefixes exist in their internal network through an 406 intra-domain routing protocoli, such as OSFP. Each vehicle and each 407 RSU announce their network prefixes and services through ND options 408 defined in Section 6. 410 5.3. V2V Internetworking 412 This subsection explains V2V internteworking between vehicle 413 networks, which are internal networks in vehicles, as shown in 414 Figure 3. 416 (*)<..........>(*) 417 2001:DB8:1:1::/64 | | 418 +------------------------------+ +------------------------------+ 419 | v | | v | 420 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 421 | | Host1 | |RDNSS1| |Router1| | | |Router5| |RDNSS3| | Host4 | | 422 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 423 | ^ ^ ^ | | ^ ^ ^ | 424 | | | | | | | | | | 425 | v v v | | v v v | 426 | ---------------------------- | | ---------------------------- | 427 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 428 | | | | | | 429 | v | | v | 430 | +-------+ +-------+ | | +-------+ +-------+ | 431 | | Host2 | |Router2| | | |Router6| | Host5 | | 432 | +-------+ +-------+ | | +-------+ +-------+ | 433 | ^ ^ | | ^ ^ | 434 | | | | | | | | 435 | v v | | v v | 436 | ---------------------------- | | ---------------------------- | 437 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 438 +------------------------------+ +------------------------------+ 439 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 441 <----> Wired Link <....> Wireless Link (*) Antenna 443 Figure 3: Internetworking between Vehicle Networks 445 Figure 3 shows the V2V networking of two vehicles whose internal 446 networks are Moving Network1 and Moving Network2, respectively. 447 Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and 448 Host2), and the two routers (Router1 and Router2). Vehicle2 has the 449 DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two 450 routers (Router3 and Router4). 452 It is assumed that Host1 and Host3 are running a Cooperative Adaptive 453 Cruise Control (C-ACC) program for physical collision avoidance. 454 Also, it is assumed that Host2 and Host4 are running a Cooperative 455 On-board Camera Sharing (C-OCS) program for sharing road hazards or 456 obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's 457 Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 458 V2V networking for various vehicular services. The vehicular 459 applications, such as C-ACC and C-BCS, can be registered into the DNS 460 Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with 461 IPv6 ND DNS options in [RFC8106]. 463 Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular 464 applications exist in their internal network by referring to their 465 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 466 what network prefixes exist in their internal network through an 467 intra-domain routing protocoli, such as OSFP. Each vehicle announces 468 its network prefixes and services through ND options defined in 469 Section 6. 471 6. ND Extension for Prefix and Service Discovery 473 This section specifies an IPv6 ND extension for vehicle-to-vehicle 474 (V2V) or vehicle-to-infrastructure (V2I) networking. This section 475 also defines three new ND options for prefix discovery, service 476 discovery, and mobility information report: (i) Vehicular Prefix 477 Information (VPI) option, (ii) Vehicular Service Information (VSI) 478 option, and (iii) Vehicular Mobility Information (VMI) option. It 479 also describes the procedure of the ND protocol with those options. 481 6.1. Vehicular Prefix Information Option 483 The VPI option contains IPv6 prefix information in the internal 484 network. Figure 4 shows the format of the VPI option. 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type | Length | Prefix Length | Distance | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Reserved | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | 494 : Prefix : 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 4: Vehicular Prefix Information (VPI) Option Format 500 Fields: 501 Type 8-bit identifier of the VPI option type as assigned 502 by the IANA: TBD 504 Length 8-bit unsigned integer. The length of the option 505 (including the Type and Length fields) is in units of 506 8 octets. The value is 3. 508 Prefix Length 8-bit unsigned integer. The number of leading bits 509 in the Prefix that are valid. The value ranges 510 from 0 to 128. 512 Distance 8-bit unsigned integer. The distance between the 513 subnet announcing this prefix and the subnet 514 corresponding to this prefix in terms of the number 515 of hops. 517 Reserved This field is unused. It MUST be initialized to 518 zero by the sender and MUST be ignored by the 519 receiver. 521 Prefix An IP address or a prefix of an IP address. The 522 Prefix Length field contains the number of valid 523 leading bits in the prefix. The bits in the prefix 524 after the prefix length are reserved and MUST be 525 initialized to zero by the sender and ignored by 526 the receiver. 528 6.2. Vehicular Service Information Option 530 The VSI option contains vehicular service information in the internal 531 network. Figure 5 shows the format of the VSI option. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type | Length | Reserved1 | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Protocol | Reserved2 | Port Number | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 : Node Address : 542 | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 5: Vehicular Service Information (VSI) Option Format 547 Fields: 548 Type 8-bit identifier of the VSI option type as assigned 549 by the IANA: TBD 551 Length 8-bit unsigned integer. The length of the option 552 (including the Type and Length fields) is in units of 553 8 octets. The value is 3. 555 Reserved1 This field is unused. It MUST be initialized to 556 zero by the sender and MUST be ignored by the 557 receiver. 559 Protocol 8-bit unsigned integer to indicate the upper-layer 560 protocol, such as transport-layer protocol (e.g., 561 TCP, UDP, and SCTP). 563 Reserved2 This field is unused. It MUST be initialized to 564 zero by the sender and MUST be ignored by the 565 receiver. 567 Port Number 16-bit unsigned integer to indicate the port number 568 for the protocol. 570 Service Address 571 128-bit IPv6 address of a node proving this vehicular 572 service. 574 6.3. Vehicular Mobility Information Option 576 The VMI option contains one vehicular mobility information of a 577 vehicle or an RSU. Figure 6 shows the format of the VMI option. 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Type | Length | Reserved1 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Reserved2 | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | | 587 : Mobility Information : 588 | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 6: Vehicular Mobility Information (VMI) Option Format 593 Fields: 594 Type 8-bit identifier of the VMI option type as assigned 595 by the IANA: TBD 597 Length 8-bit unsigned integer. The length of the option 598 (including the Type and Length fields) is in units of 599 8 octets. The value is 3. 601 Reserved1 This field is unused. It MUST be initialized to 602 zero by the sender and MUST be ignored by the 603 receiver. 605 Reserved2 This field is unused. It MUST be initialized to 606 zero by the sender and MUST be ignored by the 607 receiver. 609 Mobility Information 610 128-bit mobility information, such as position, 611 speed, and direction. 613 6.4. Vehicular Neighbor Discovery 615 Prefix discovery enables hosts (e.g., vehicles and in-vehicle 616 devices) to distinguish destinations on the same link from those only 617 reachable via RSUs. A vehicle (or its in-vehicle devices) can 618 directly communicate with on-link vehicles (or their in-vehicle 619 devices) without the relay of an RSU, but through V2V communications 620 along with VPI ND option. This VPI option contains IPv6 prefixes in 621 a vehicle's internal network. 623 Vehicles announce services in their internal networks to other 624 vehicles through an VSI ND option. The VSI option contains a list of 625 vehicular services in a vehicle's or an RSU's internal network. 627 A vehicle periodically announces an NS message containing VPI and VSI 628 options with its prefixes and services in all-nodes multicast address 629 to reach all neighboring nodes. When it receives this NS message, 630 another neighboring node responds to this NS message by sending an NA 631 message containing the VPI and VSI options with its prefixes and 632 services via unicast towards the NS-originating node. 634 Therefore, prefix and service discovery can be achieved via ND 635 messages (e.g., NS and NA) by vehicular ND with VPI and VSI options. 636 This VND-based discovery eliminates an additional prefix and service 637 discovery scheme, such as DNS-based Service Discovery [RFC6763] 638 (e.g., Multicast DNS (mDNS) [RFC6762] and DNSNA [ID-DNSNA]), other 639 than ND. That is, vehicles and RSUs can rapidly discover the network 640 prefixes and services of the other party without any additional 641 service discovery protocol. 643 6.5. Message Exchange Procedure for V2I Networking 645 This subsection explains a message exchange procedure for vehicular 646 neighbor discovery in V2I networking, where a vehicle communicates 647 with its correponding node in the Internet via an RSU. 649 Figure 7 shows an example of message exchange procedure in V2I 650 networkging. The detailed steps of the procedure are explained in 651 Section 7 and Section 8. 653 Vehicle RSU Mobility Anchor 654 | | | 655 |-RS with Mobility Info->| | 656 | [VMI] | | 657 | | | 658 | |--------PBU------>| 659 | | | 660 | | | 661 | |<-------PBA-------| 662 | | | 663 | | | 664 | |===Bi-Dir Tunnel==| 665 | | | 666 | | | 667 |<----RA with prefix-----| | 668 | | | 669 | | | 670 | | | 671 |--NS with Address Reg-->| | 672 | [ARO+VPI+VSI] | | 673 | | | 674 | |--------DAR------>| 675 | | | 676 | | | 677 | |<-------DAC-------| 678 | | | 679 | | | 680 |<--NA with Address Reg--| | 681 | [ARO+VPI+VSI] | | 683 Figure 7: Message Interaction for Vehicular Neighbor Discovery 685 Note that a vehicle could also perform the prefix and service 686 discovery simultaneously along with Address Registration procedure, 687 as shown in Figure 9. 689 Note that RSUs as routers do not transmit periodical and unsolicited 690 multicast RA messages including a prefix for energy saving in 691 vehicular networks. Vehicles as hosts periodically initiate an RS 692 message according to a time interval (considering its position and an 693 RSU's coverage). Note that since they have a digital road map with 694 the information of RSUs (e.g., position and communication coverage), 695 vehicles can know when they will go out of the communication range of 696 an RSU along with the signal strength (e.g., Received Channel Power 697 Indicator (RCPI) [VIP-WAVE]) from the RSU. RSUs replies with a 698 solicited RA in unicast only when they receive an RS message. 700 7. Address Registration and Duplicate Address Detection 702 This section explains address configuration, consisting of IP Address 703 Autoconfiguration, Address Registration, and multihop DAD. 705 This document recommends a new Address Registration and DAD scheme in 706 order to avoid multicast flooding and decrease link-scope multicast 707 for energy and wireless channel conservation on a large-scale 708 vehicular network. Host-initiated refresh of RA removes the need for 709 routers to use periodic and unsolicited multicast RAs to accommodate 710 hosts. This also enables the same IPv6 address prefix(es) to be used 711 across a subnet. 713 There are two scenarios about Address Registration part. If they 714 have already configured their IP addresses with the prefix obtained 715 from the previous RSU, and the current RSU located in the same subnet 716 as the previous RSU, which means that they have the same prefix, then 717 vehicles have no need to repeat the Address Registration and multihop 718 DAD. However, if the current RSU belongs to another subnet, vehicles 719 need to perform the Address Registration and multihop DAD in the 720 following subsections. 722 7.1. Address Autoconfiguration 724 A vehicle as an IPv6 host creates its link-local IPv6 address and 725 global IPv6 address as follows [RFC4862]. When they receive RS 726 messages from vehicles, RSUs send back RA messages containing prefix 727 information. The vehicle makes its global IPv6 addresses by 728 combining the prefix for its current link and its link-layer address. 730 The address autoconfiguration does not perform the legacy DAD as 731 defined in [RFC4862]. Instead, a new multihop DAD is performed in 732 Section 7.3. 734 7.2. Address Registration 736 After its IP tentative address autoconfiguration with the known 737 prefix from an RSU and its link-layer address, a vehicle starts to 738 register its IP address to the serving RSU along with multihop DAD. 739 Address Register Option (ARO) is used in this step and its format is 740 defined in [RFC6775]. 742 ARO is always host-initiated by vehicles. The information contained 743 in ARO becomes included in multihop Duplicate Address Request (DAR) 744 and Duplicate Address Confirmation (DAC) messages used between RSU 745 and MA, but ARO is not directly used in these two messages. 747 An example message exchange procedure of Address Registration is 748 presented in Figure 8. Since Address Registration is performed 749 simultaneously with the multihop DAD, the specific procedure is 750 together described with the DAD mechanism in Section 7.3. 752 Vehicle RSU 753 | | 754 | | 755 1. |----NS with Address Reg--->| 756 | [ARO] | 757 | | 758 | | 759 | | 760 2. |<---NA with Address Reg----| 761 | [ARO] | 763 Figure 8: Neighbor Discovery Address Registration 765 7.3. Multihop Duplicate Address Detection 767 Before it can exchange data, a node should determine whether its IP 768 address is already used by another node or not. In the legacy IPv6 769 ND, hosts multicast NS messages to all nodes in the same on-link 770 subnet for DAD. Instead of this, an optimized multihop DAD is 771 designed to eliminate multicast messages for energy-saving purpose. 772 For this multihop DAD, Neighbor Cache and DAD Table are maintained by 773 each RSU and an MA, respectively, for the duplicate address 774 inspection during the multihop DAD process. That is, each RSU makes 775 Neighbor Cache Entries (NCE) of all the on-link hosts in its Neighbor 776 Cache. Similarly, the MA stores all the NCEs reported by the RSUs in 777 its DAD Table. 779 With the multihop DAD, a vehicle can skip the multicast-based DAD in 780 its current wireless link whenever it enters the coverage of another 781 RSU in the same subset, leading to the reduction of traffic overhead 782 in vehicular wireless links. 784 For the multihop DAD, two new ICMPv6 message types are defined in 785 [RFC6775], such as Duplicate Address Request (DAR) and the Duplicate 786 Address Confirmation (DAC). Information carried by ARO options are 787 copied into these two messages for the multihop DAD in the MA. 789 Vehicle RSU Mobility Anchor 790 | | | 791 | | | 792 1. |--NS with Address Reg-->| | 793 | [ARO+VPI+VSI] | | 794 | | | 795 | | | 796 2. | | -------DAR------>| 797 | | | 798 | | | 799 3. | |<-------DAC-------| 800 | | | 801 | | | 802 | | | 803 4. |<--NA with Address Reg--| | 804 | [ARO+VPI+VSI] | | 806 Figure 9: Neighbor Discovery Address Registration with Multihop DAD 808 Figure 9 presents the procedure of Address Registration and multihop 809 DAD. The detailed steps are explained as follows. 811 1. A vehicle sends an NS message to the current RSU in unicast, 812 containing the ARO to RSU to register its address. 814 2. The RSU receives the NS message, and then inspects its Neighbor 815 Cache to check whether it is duplicate or not. If there is no 816 duplicate NCE, a tentative NCE is created for this address, and 817 then the RSU sends a DAR to the MA for the multicast DAD. 819 3. When the MA receives a DAR from an RSU, it checks whether the 820 register-requested address exists in its DAD Table or not. If an 821 entry with the same address exists in the DAD Table, which means 822 that the address is considered "Duplicate Address", then MA 823 returns a DAC message to notify the RSU of the address 824 duplication. If no entry with the same address exists in the DAD 825 Table, which means that an entry for the address is created, then 826 MA replies a DAC message to the RSU to confirm the uniqueness of 827 the register-requested address to the RSU. 829 4. If the address duplication is notified by the MA, the RSU deletes 830 the tentative NCE, and sends back an NS to the address- 831 registration vehicle to notify the registration failure. 832 Otherwise, the RSU changes the tentative NCE into a registered 833 NCE in its Neighbor Cache, and then send back an NS to the 834 vehicle to notify the registration success. 836 Thus, the multihop DAD is processed simultaneously with the Address 837 Registration. Note that the tentative address is not considered 838 assigned to the vehicle until the MA confirms the uniqueness of the 839 register-requested address in the multihop DAD. 841 7.4. Pseudonym Handling 843 Considering the privacy protection of a vehicle, a pseudonym 844 mechanism for its link-layer address is requested. This mechanism 845 periodically modifies the link-layer address, leading to the update 846 of the corresponding IP address. A random MAC Address Generation 847 mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by 848 generating the 46 remaining bits of MAC address using a random number 849 generator. When it changes its MAC address, a vehicle should ask the 850 serving RSU to update its own NCE, and to register its IP address 851 into the MA again. 853 Vehicle RSU Mobility Anchor 854 | | | 855 |-RS with Mobility Info->| | 856 | [VMI] | | 857 | | | 858 | |--------PBU------>| 859 | | | 860 | | | 861 | |<-------PBA-------| 862 | | | 863 | | | 864 | |===Bi-Dir Tunnel==| 865 | | | 866 | | | 867 |<----RA with prefix-----| | 868 | | | 870 Figure 10: Message Interaction for Vehicle Attachment 872 8. Mobility Management 874 A mobility management is required for the seamless communication of 875 vehicles moving between the RSUs. When a vehicle moves into the 876 coverage of another RSU, a different IP address is assigned to the 877 vehicle, resulting in the reconfiguration of transport-layer session 878 information (i.e., end-point IP address) to avoid service disruption. 879 Considering this issue, this document proposes a handover mechanism 880 for seamless communication. 882 In [VIP-WAVE], the authors constructed a network-based mobility 883 management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which 884 is highly suitable to vehicular networks. This document uses a 885 mobility management procedure similar to PMIPv6 along with prefix 886 discovery. 888 Vehicle c-RSU Mobility Anchor n-RSU 889 | | | | 890 | |===Bi-Dir Tunnel==| | 891 | | | | 892 | | | | 893 | |----DeReg PBU---->| | 894 | | | | 895 | | | | 896 | |<-------PBA-------| | 897 | | | | 898 | | | | 899 | | | | 900 | | | | 901 | | | | 902 |---------------------------RS-------------------------->| 903 | | 904 | Registration step as shown in Figure 5 | 905 | | 906 | | |===Bi-Dir Tunnel==| 907 | | 908 |<--------------------------RA---------------------------| 909 | | 911 Figure 11: Message Interaction for Vehicle Handoff 913 Figure 10 shows the binding update flow when a vehicle entered the 914 subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined 915 in [VIP-WAVE]. When it receives RS messages from a vehicle 916 containing its mobility information (e.g., position, speed, and 917 direction), an RSU sends its MA a Proxy Binding Update (PBU) message 918 [RFC5213][RFC3775], which contains a Mobility Option for the 919 vehicle's mobility information. The MA receives the PBU and sets up 920 a Binding Cache Entry (BCE) as well as a bi-directional tunnel 921 (denoted as Bi-Dir Tunnel in Figure 10) between the serving RSU and 922 itself. Through this tunnel, all traffic packets to the vehicle are 923 encapsulated toward the RSU. Simultaneously, the MA sends back a 924 Proxy Binding Acknowledgment (PBA) message to the serving RSU. This 925 serving RSU receives the PBA and sets up a bi-directional tunnel with 926 the MA. After this binding update, the RSU sends back an RA message 927 to the vehicle including its own prefix for the address 928 autoconfiguration. 930 When the vehicle changes its location, the MA has to change the end- 931 point of the tunnel for the vehicle into the new RSU's IP address. 932 As shown in Figure 11, when the MA receives a new PBU from the new 933 RSU, it changes the tunnel's end-point from the current RSU (c-RSU) 934 to the new RSU (n-RSU). If there is ongoing IP packets toward the 935 vehicle, the MA encapsulates the packets and then forwards them 936 towards the new RSU. Through this network-based mobility management, 937 the vehicle is not aware of any changes at its network layer and can 938 maintain its transport-layer sessions without any disruption. 940 9. Security Considerations 942 This document shares all the security issues of the neighbor 943 discovery protocol and 6LoWPAN protocol. This document can get 944 benefits from secure neighbor discovery (SEND) [RFC3971] in order to 945 protect ND from possible security attacks. 947 10. References 949 10.1. Normative References 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, March 1997. 954 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 955 in IPv6", RFC 3775, June 2004. 957 [RFC3971] Arkko, J., "SEcure Neighbor Discovery (SEND)", RFC 3971, 958 March 2005. 960 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 961 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 962 September 2007. 964 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 965 Address Autoconfiguration", RFC 4862, September 2007. 967 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., and K. 968 Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008. 970 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 971 Hoc Networks", RFC 5889, September 2010. 973 [RFC6775] Shelby, Z., Ed., "Neighbor Discovery Optimization for IPv6 974 over Low-Power Wireless Personal Area Networks 975 (6LoWPANs)", RFC 6775, November 2012. 977 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 978 "IPv6 Router Advertisement Options for DNS Configuration", 979 RFC 8106, March 2017. 981 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 982 (IPv6) Specification", RFC 8200, July 2017. 984 10.2. Informative References 986 [DSRC-WAVE] 987 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 988 Architecture, Design, and Characteristics", 989 IEEE Communications Surveys & Tutorials, 12(4), 2012. 991 [ID-DNSNA] 992 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 993 Autoconfiguration for Internet of Things Devices", draft- 994 jeong-ipwave-iot-dns-autoconf-04 (work in progress), 995 October 2018. 997 [IEEE-802.11-OCB] 998 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 999 Access Control (MAC) and Physical Layer (PHY) 1000 Specifications", IEEE Std 802.11-2016, December 2016. 1002 [IEEE-802.11p] 1003 IEEE Std 802.11p, "Part 11: Wireless LAN Medium Access 1004 Control (MAC) and Physical Layer (PHY) Specifications 1005 Amendment 6: Wireless Access in Vehicular Environments", 1006 June 2010. 1008 [IPWAVE-PS] 1009 Jeong, J., Ed., "IP Wireless Access in Vehicular 1010 Environments (IPWAVE): Problem Statement and Use Cases", 1011 draft-ietf-ipwave-vehicular-networking-07 (work in 1012 progress), November 2018. 1014 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1015 February 2013. 1017 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1018 Discovery", RFC 6763, February 2013. 1020 [VIP-WAVE] 1021 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1022 Feasibility of IP Communications in 802.11p Vehicular 1023 Networks", IEEE Transactions on Intelligent Transportation 1024 Systems, vol. 14, no. 1, March 2013. 1026 [WAVE-1609.0] 1027 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1028 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1029 1609.0-2013, March 2014. 1031 [WAVE-1609.2] 1032 IEEE 1609 Working Group, "IEEE Standard for Wireless 1033 Access in Vehicular Environments - Security Services for 1034 Applications and Management Messages", IEEE Std 1035 1609.2-2016, March 2016. 1037 [WAVE-1609.3] 1038 IEEE 1609 Working Group, "IEEE Standard for Wireless 1039 Access in Vehicular Environments (WAVE) - Networking 1040 Services", IEEE Std 1609.3-2016, April 2016. 1042 [WAVE-1609.4] 1043 IEEE 1609 Working Group, "IEEE Standard for Wireless 1044 Access in Vehicular Environments (WAVE) - Multi-Channel 1045 Operation", IEEE Std 1609.4-2016, March 2016. 1047 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 1048 discovery-04 1050 The following changes are made from draft-jeong-ipwave-vehicular- 1051 neighbor-discovery-04: 1053 o This version includes the contents of the IPv6 vehicular neighbor 1054 discovery in draft-xiang-ipwave-vehicular-neighbor-discovery-00 1055 for IP-based vehicular networks. 1057 o In Section 6.3, a Vehicular Mobility Information (VMI) option is 1058 defined to report the mobility information of a vehicle or an RSU. 1060 Appendix B. Acknowledgments 1062 This work was supported by Basic Science Research Program through the 1063 National Research Foundation of Korea (NRF) funded by the Ministry of 1064 Education (2017R1D1A1B03035885). 1066 This work was supported in part by Global Research Laboratory Program 1067 through the NRF funded by the Ministry of Science and ICT (MSIT) 1068 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 1069 (18-EE-01). 1071 Authors' Addresses 1073 Jaehoon Paul Jeong 1074 Department of Software 1075 Sungkyunkwan University 1076 2066 Seobu-Ro, Jangan-Gu 1077 Suwon, Gyeonggi-Do 16419 1078 Republic of Korea 1080 Phone: +82 31 299 4957 1081 Fax: +82 31 290 7996 1082 EMail: pauljeong@skku.edu 1083 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1084 Yiwen Chris Shen 1085 Department of Electrical and Computer Engineering 1086 Sungkyunkwan University 1087 2066 Seobu-Ro, Jangan-Gu 1088 Suwon, Gyeonggi-Do 16419 1089 Republic of Korea 1091 Phone: +82 31 299 4106 1092 Fax: +82 31 290 7996 1093 EMail: chrisshen@skku.edu 1095 Zhong Xiang 1096 Department of Electrical and Computer Engineering 1097 Sungkyunkwan University 1098 2066 Seobu-Ro, Jangan-Gu 1099 Suwon, Gyeonggi-Do 16419 1100 Republic of Korea 1102 Phone: +82 10 9895 1211 1103 Fax: +82 31 290 7996 1104 EMail: xz618@skku.edu