idnits 2.17.1 draft-jeong-ipwave-vehicular-mobility-management-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 28, 2019) is 1856 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 485, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 7333 ** Downref: Normative reference to an Informational RFC: RFC 7429 == Outdated reference: A later version (-06) exists of draft-ietf-dmm-pmipv6-dlif-04 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-08 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-06 Summary: 4 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: September 29, 2019 Sungkyunkwan University 6 March 28, 2019 8 Vehicular Mobility Management for IP-Based Vehicular Networks 9 draft-jeong-ipwave-vehicular-mobility-management-00 11 Abstract 13 This document specifies a vehicular mobility management scheme for 14 IP-based vehicular networks. The vehicular mobility management 15 scheme takes advantage of a vehicular link model based on a multi- 16 link subnet. With a vehicle's mobility information (e.g., position, 17 speed, and direction) and navigation path (i.e., trajectory), it can 18 provide a moving vehicle with proactive and seamless handoff along 19 with its trajectory. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 29, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Vehicular Network Architecture . . . . . . . . . . . . . . . 4 59 4.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 4 60 5. Mobility Management . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Network Attachment of a Vehicle . . . . . . . . . . . . . 6 62 5.2. Handoff within One Prefix Domain . . . . . . . . . . . . 8 63 5.3. Handoff between Multiple Prefix Domains . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 67 7.2. Informative References . . . . . . . . . . . . . . . . . 12 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 This document proposes a mobility management scheme for IP-based 74 vehicular networks, which is called vehicular mobility management 75 (VMM). This vehicular mobility management is tailored for a 76 vehicular network architecture and a vehicular link model described 77 in IPWAVE problem statement document [I-D.IPWAVE-PS]. 79 To support the interaction between vehicles or between vehicles and 80 Rode-Side Units (RSUs), Vehicular Neighbor Discovery (VND) is 81 proposed as an enhanced IPv6 Neighbor Discovery (ND) for IP-based 82 vehicular networks [I-D.IPWAVE-VND]. For an efficient IPv6 Stateless 83 Address Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized 84 Address Registration using a multihop Duplicate Address Detection 85 (DAD). This multihop DAD enables a vehicle to have a unique IP 86 address in a multi-link subnet that consists of multiple wireless 87 subnets with the same IP prefix, which corresponds to wireless 88 coverage of multiple Road-Side Units (RSUs). Also, VND supports IP 89 packet routing via a connected Vehicular Ad Hoc Network (VANET) by 90 letting vehicles exchange the prefixes of their internal networks 91 through their external wireless interface. 93 The mobility management in this multi-link subnet needs a new 94 approach from the legacy mobility management schemes. This document 95 aims at an efficient mobility management scheme called vehicular 96 mobility management called VMM to support efficient V2V, V2I, and V2X 97 communications in a road network. The VMM takes advantage of the 98 mobility information (e.g., a vehicle's speed, direction, and 99 position) and trajectory (i.e., navigation path) of each vehicle 100 registered into a Traffic Control Center (TCC) in the vehicular 101 cloud. 103 2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Terminology 111 This document uses the terminology described in [RFC4861] and 112 [RFC4862]. In addition, the following new terms are defined as 113 below: 115 o DMM: Acronym for "Distributed Mobility Management" 116 [RFC7333][RFC7429]. 118 o Mobility Anchor (MA): A node that maintains IP addresses and 119 mobility information of vehicles in a road network to support 120 their address autoconfiguration and mobility management with a 121 binding table. It has end-to-end connections with RSUs under its 122 control. 124 o On-Board Unit (OBU): A node that has a network interface (e.g., 125 IEEE 802.11-OCB and Cellular V2X (C-V2X) [TS-23.285-3GPP]) for 126 wireless communications with other OBUs and RSUs, and may be 127 connected to in-vehicle devices or networks. An OBU is mounted on 128 a vehicle. It is assumed that a radio navigation receiver (e.g., 129 Global Positioning System (GPS)) is included in a vehicle with an 130 OBU for efficient navigation. 132 o OCB: Acronym for "Outside the Context of a Basic Service Set" 133 [IEEE-802.11-OCB]. 135 o Road-Side Unit (RSU): A node that has physical communication 136 devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless 137 communications with vehicles and is also connected to the Internet 138 as a router or switch for packet forwarding. An RSU is typically 139 deployed on the road infrastructure, either at an intersection or 140 in a road segment, but may also be located in car parking areas. 142 o Traffic Control Center (TCC): A node that maintains road 143 infrastructure information (e.g., RSUs, traffic signals, and loop 144 detectors), vehicular traffic statistics (e.g., average vehicle 145 speed and vehicle inter-arrival time per road segment), and 146 vehicle information (e.g., a vehicle's identifier, position, 147 direction, speed, and trajectory as a navigation path). TCC is 148 included in a vehicular cloud for vehicular networks. 150 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 151 having compute nodes, storage nodes, and network nodes. 153 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 154 [WAVE-1609.0]. 156 4. Vehicular Network Architecture 158 This section describes a vehicular network architecture for V2V and 159 V2I communication. A vehicle and an RSU have their internal networks 160 including in-vehicle devices or servers, respectively. 162 4.1. Vehicular Network 164 A vehicular network architecture for V2I and V2V is illustrated in 165 Figure 1. In this figure, there is a vehicular cloud having a 166 Traffic Control Center (TCC). The TCC has Mobility Anchors (MAs) for 167 the mobility management of vehicles under its control. Each MA is in 168 charge of the mobility management of vehicles under its prefix 169 domain, which is a multi-link subnet of RSUs sharing the same prefix 170 [I-D.IPWAVE-PS]. A vehicular network is a wireless network 171 consisting of RSUs and vehicles. RSUs are interconnected with each 172 other through a wired network, and vehicles can construct Vehicular 173 Ad Hoc Networks (VANET). 175 *-----------------------------------------* 176 * TCC in Vehicular Cloud * 177 * +-------------------------------------+ * 178 +--------+ * | +---------+ +---------+ | * 179 | CN1 |<---->* | | MA1 |<------->| MA2 | | * 180 +--------+ * | +---------+ +---------+ | * 181 * +-------------------------------------+ * 182 * ^ ^ * 183 * | INTERNET | * 184 *---------v--------------------v----------* 185 ^ ^ ^ 186 | Ethernet | | 187 | | | 188 v v v 189 +--------+ Ethernet +--------+ Ethernet +--------+ 190 | RSU1 |<-------->| RSU2 |<-------->| RSU3 | 191 +--------+ +--------+ +--------+ 192 ^ ^ ^ 193 : : : 194 +-----------------------------------+ +-----------------+ 195 | : V2I V2I : | | V2I : | 196 | v v | | v | 197 +--------+ | +--------+ +--------+ | | +--------+ | 198 |Vehicle1|======>|Vehicle2|======>|Vehicle3|====>| | |Vehicle4|====>| 199 | |<.....>| |<.....>| | | | | | | 200 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 201 | | | | 202 +-----------------------------------+ +-----------------+ 203 Subnet1 Subnet2 205 <----> Wired Link <....> Wireless Link ===> Moving Direction 207 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 209 In Figure 1, three RSUs are deployed either at intersections or along 210 roadways. They are connected to an MA through wired networks. In 211 the vehicular network, there are two subnets such as Subnet1 and 212 Subnet2. Subnet1 is a multi-link subnet consisting of multiple 213 wireless coverage areas of multiple RSUs, and those areas share the 214 same IPv6 prefix to construct a single logical subnet 215 [I-D.IPWAVE-PS]. That is, the wireless links of RSU1 and RSU2 belong 216 to Subnet1. Thus, since Vehicle2 and Vehicle2 use the same prefix 217 for Subnet1 and they are within the wireless communication range, 218 they can communicate directly with each other. Note that in a multi- 219 link subnet, a vehicle (e.g., Vehicle1 and Vehicle2 in Figure 1) can 220 configure its global IPv6 address through an address registration 221 procedure including a multihop Duplicate Address Detection (DAD), 222 which is specified in Vehicular Neighbor Discovery (VND) 223 [I-D.IPWAVE-VND]. 225 On the other hand, Subnet2 uses a prefix different from Subnet1's. 226 Vehicle4 residing in Subnet2 cannot talk to Vehicle3 directly because 227 they belong to different subnets. Vehicles can construct a connected 228 VANET, so they can communicate with each other without the relaying 229 of an RSU, but the forwarding over the VANET. In the case where two 230 vehicles belong to the same multi-link subnet, but they are not 231 connected in the same VANET, they can use RSUs. In Figure 1, even 232 though Vehicle2 are disconnected from Vehicle3, they can communicate 233 indirectly with each other through RSUs such as RSU1 and RSU2. 235 In Figure 1, it is assumed that Vehicle2 communicates with the 236 corresponding node denoted as CN1 where Vehicle2 is moving in the 237 wireless coverage of RSU1. When Vehicle2 moves out of the coverage 238 of RSU1 and moves into the coverage of RSU2 where RSU1 and RSU2 239 shares the same prefix, the packets sent by CN1 should be routed 240 toward Vehicle2. Also, when Vehicle2 moves out of the coverage of 241 RSU2 and moves into the coverage of RSU3 where RSU2 and RSU3 use two 242 different prefixes, the packets of CN1 should be delivered to 243 Vehicle2. With a handoff procedure, a sender's packets can be 244 delivered to a destination vehicle which the destination vehicle is 245 moving in the wireless coverage areas. Thus, this document specifies 246 a mobility management scheme in the vehicular network architecture, 247 as shown in Figure 1. 249 5. Mobility Management 251 This section explains the detailed procedure of mobility management 252 of a vehicle in a vehicular network as shown in Figure 1. 254 5.1. Network Attachment of a Vehicle 256 A mobility management is required for the seamless communication of 257 vehicles moving between the RSUs. When a vehicle moves into the 258 coverage of another RSU, a different IP address is assigned to the 259 vehicle, resulting in the reconfiguration of transport-layer session 260 information (i.e., an end-point's IP address) to avoid service 261 disruption. Considering this issue, this document proposes a handoff 262 mechanism for seamless communication. 264 In [VIP-WAVE], the authors constructed a network-based mobility 265 management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which 266 is highly suitable to vehicular networks. This document uses a 267 mobility management procedure similar to PMIPv6 along with prefix 268 discovery. 270 Vehicle RSU Mobility Anchor 271 | | | 272 |-RS with Mobility Info->| | 273 | [VMI] | | 274 | | | 275 | |--------PBU------>| 276 | | | 277 | | | 278 | |<-------PBA-------| 279 | | | 280 | | | 281 | |===Bi-Dir Tunnel==| 282 | | | 283 | | | 284 |<----RA with prefix-----| | 285 | | | 287 Figure 2: Message Interaction for a Vehicle's Network Attachment 289 Figure 2 shows the binding update flow when a vehicle entered the 290 subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined 291 in [VIP-WAVE]. When it receives an RS message from a vehicle 292 containing its mobility information (e.g., position, speed, and 293 direction), an RSU sends its MA a Proxy Binding Update (PBU) message 294 [RFC5213][RFC3775], which contains a Mobility Option for the 295 vehicle's mobility information. The MA receives the PBU and sets up 296 a Binding Cache Entry (BCE) as well as a bi-directional tunnel 297 (denoted as Bi-Dir Tunnel in Figure 2) between the serving RSU and 298 itself. Through this tunnel, all traffic packets to the vehicle are 299 encapsulated toward the RSU. Simultaneously, the MA sends back a 300 Proxy Binding Acknowledgment (PBA) message to the serving RSU. This 301 serving RSU receives the PBA and sets up a bi-directional tunnel with 302 the MA. After this binding update, the RSU sends back an RA message 303 to the vehicle, which includes the RSU's prefix for the address 304 autoconfiguration of the vehicle. 306 When the vehicle receives the RA message, it performs the address 307 registration procedure including a multihop DAD for its global IP 308 address based on the prefix announced by the RA message according to 309 the VND [I-D.IPWAVE-VND]. 311 In PMIPv6, a unique prefix is allocated to each vehicle by an MA 312 (i.e., LMA), but in this document, a unique IP address is allocated 313 to each vehicle by an MA through the multihop-DAD-based address 314 registration. This unique IP address allocation can reduce the waste 315 of IP prefixes by the legacy PMIPv6 because vehicles in a multi-link 316 is allocated with a unique IP address based on the same prefix. 318 5.2. Handoff within One Prefix Domain 320 When the vehicle changes its location and its current RSU (denoted as 321 c-RSU) detects that the vehicles moves out of its coverage, c-RSU 322 needs to report the movement of the vehicle into the coverage of 323 another RSU to the MA. 325 Vehicle c-RSU Mobility Anchor n-RSU 326 | | | | 327 | |===Bi-Dir Tunnel==| | 328 | | | | 329 | | | | 330 | |----DeReg PBU---->| | 331 | | | | 332 | | | | 333 | |<-------PBA-------| | 334 | | | | 335 | | | | 336 | | | | 337 | | | | 338 | | | | 339 |(------------------RS with Mobility Info-------------->)| 340 | [VMI] | | 341 | |<-------PBU-------| 342 | | | 343 | | | 344 | |--------PBA------>| 345 | | | 346 | | | 347 | |===Bi-Dir Tunnel==| 348 | | | 349 | | | 350 |<--------------------RA with prefix---------------------| 351 | | 353 Figure 3: Handoff of a Vehicle within One Prefix Domain with PMIPv6 355 With this report, the MA can change the end-point of the tunnel for 356 the vehicle into the new RSU's IP address. 358 Figure 3 shows the handoff of a vehicle within one prefix domain 359 (i.e., a multi-link subnet) with PMIPv6. As shown in the figure, 360 when the MA receives a new PBU from the new RSU, it changes the 361 tunnel's end-point from the current RSU (c-RSU) to the new RSU 362 (n-RSU). If there is ongoing IP packets toward the vehicle, the MA 363 encapsulates the packets and then forwards them towards n-RSU. 364 Through this network-based mobility management, the vehicle is not 365 aware of any changes at its network layer and can maintain its 366 transport-layer sessions without any disruption. 368 Vehicle c-RSU n-RSU 369 | | | 370 |---------------------| | 371 |c-RSU detects leaving| | 372 |---------------------| | 373 | |--------PBU------>| 374 | | | 375 | |===Bi-Dir Tunnel==| 376 | | | 377 | |<-------PBA-------| 378 | | | 379 | | | 380 |(--------RS with Mobility Info-------->)| 381 | [VMI] | 382 | | 383 |<------------RA with prefix-------------| 384 | | 386 Figure 4: Handoff of a Vehicle within One Prefix Domain with DMM 388 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 389 specified routes with fixed RSU allocation, the procedure can be 390 simplified by constructing bidirectional tunnel directly between them 391 (cancel the intervention of MA) to alleviate the traffic flow in MA 392 as well as reduce handoff delay. 394 Figure 4 shows the handoff of a vehicle within one prefix domain (as 395 a multi-link subnet) with DMM [I-D.DMM-PMIPv6]. RSUs are in charge 396 of detecting when a node joins or moves through its domain. If c-RSU 397 detects that the vehicle is going to leave its coverage and to enter 398 the area of an adjacent RSU, it sends a PBU message to inform n-RSU 399 of the handoff of vehicle. If n-RSU receives the PBU message, it 400 constructs a bidirectional tunnel between c-RSU and itself, and then 401 sends back a PBA message as an acknowledgment to c-RSU. If there are 402 ongoing IP packets toward the vehicle, c-RSU encapsulates the packets 403 and then forwards them to n-RSU. When n-RSU detects the entrance of 404 the vehicle, it directly sends an RA message to the vehicle so that 405 the vehicle can assure that it is still connected to a router for its 406 current prefix. If the vehicle sends an RS message to n-RSU, n-RSU 407 responds to the RA message by sending an RA to the vehicle. 409 5.3. Handoff between Multiple Prefix Domains 411 When the vehicle moves from a prefix domain to another prefix domain, 412 a handoff between multiple prefix domains is required. As shown in 413 Figure 1, when Vehicle3 moves from the subnet of RSU2 (i.e., Subnet1) 414 to the subnet of RSU3 (i.e., Subnet2), a multiple domain handoff is 415 performed through the cooperation of RSU2, RSU3, MA1 and MA2. 417 Vehicle c-RSU MA1 MA2 n-RSU 418 | | | | | 419 | |==Bi-Dir Tunnel==| | | 420 | | | | | 421 | | | | | 422 | |---DeReg PBU---->| | | 423 | | |-------PBU----->| | 424 | | | | | 425 | |<------PBA-------| |-------PBA------>| 426 | | | | | 427 | | | |==Bi-Dir Tunnel==| 428 | | | | | 429 | | | | | 430 |(----------------------RS with Mobility Info------------------->)| 431 | | |[VMI] | | 432 | | | | | 433 | | | | | 434 |<----------------------RA with prefix1 (c-RSU)-------------------| 435 | | | | | 436 |<----------------------RA with prefix2 (n-RSU)-------------------| 437 | | | | | 439 Figure 5: Handoff of a Vehicle between Multiple Prefix Domains with 440 PMIPv6 442 Figure 5 shows the handoff of a vehicle between two prefix domains 443 (i.e., two multi-link subnets) with PMIPv6. When the vehicle moves 444 out of its current RSU (denoted as c-RSU) belonging to Subnet1, and 445 moves into the next RSU (n-RSU) belonging to Subnet2, c-RSU detects 446 that the vehicles moves out of its coverage. c-RSU reports the 447 movement of the vehicle into the coverage of another RSU (n-RSU) to 448 MA1. MA1 sends MA2 a PBU message to inform MA2 that the vehicle will 449 enter the coverage of n-RSU belonging to MA2. MA2 send n-RSU a PBA 450 message to inform n-RSU that the vehicle will enter the coverage of 451 n-RSU along with handoff context such as c-RSU's context information 452 (e.g., c-RSU's link-local address and prefix called prefix1), and the 453 vehicle's context information (e.g., the vehicle's global IP address 454 and MAC address). After n-RSU receives the PBA message including the 455 handoff context from MA2, it sets up a bi-directional tunnel with 456 MA2, and generates RA messages with c-RSU's context information. 458 That is, n-RSU pretents to be a router belonging to Subnet1. When 459 the vehicle receives the RA from n-RSU, it can maintain its 460 connection with its corresponding node (i.e., CN1). Note that n-RSU 461 also sends RA messages with its domain prefix called prefix2. The 462 vehicle configures another global IP address with prefix2, and can 463 use it for the communication with neighboring vehicles under the 464 coverage of n-RSU. 466 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 467 specified routes with fixed RSU allocation, the procedure can be 468 simplified by constructing bidirectional tunnel directly between them 469 (cancel the intervention of MA) to alleviate the traffic flow in MA 470 as well as reduce handoff delay. 472 Vehicle c-RSU n-RSU 473 | | | 474 |---------------------| | 475 |c-RSU detects leaving| | 476 |---------------------| | 477 | |--------PBU------>| 478 | | | 479 | |===Bi-Dir Tunnel==| 480 | | | 481 | |<-------PBA-------| 482 | | | 483 | | | 484 |(--------RS with Mobility Info-------->)| 485 | [VMI] | 486 | | 487 |<--------RA with prefix1 (c-RSU)--------| 488 | | 489 |<--------RA with prefix2 (n-RSU)--------| 490 | | 492 Figure 6: Handoff of a Vehicle within Multiple Prefix Domains with 493 DMM 495 Figure 6 shows the handoff of a vehicle within two prefix domains (as 496 two multi-link subnets) with DMM [I-D.DMM-PMIPv6]. If c-RSU detects 497 that the vehicle is going to leave its coverage and to enter the area 498 of an adjacent RSU (n-RSU) belonging to a different prefix domain, it 499 sends a PBU message to inform n-RSU that the vehicle will enter the 500 coverage of n-RSU along with handoff context such as c-RSU's context 501 information (e.g., c-RSU's link-local address and prefix called 502 prefix1), and the vehicle's context information (e.g., the vehicle's 503 global IP address and MAC address). After n-RSU receives the PBA 504 message including the handoff context from c-RSU, it sets up a bi- 505 directional tunnel with c-RSU, and generates RA messages with c-RSU's 506 context information. That is, n-RSU pretends to be a router 507 belonging to Subnet1. When the vehicle receives the RA from n-RSU, 508 it can maintain its connection with its corresponding node (i.e., 509 CN1). Note that n-RSU also sends RA messages with its domain prefix 510 called prefix2. The vehicle configures another global IP address 511 with prefix2, and can use it for the communication with neighboring 512 vehicles under the coverage of n-RSU. 514 6. Security Considerations 516 This document shares all the security issues of Vehicular ND 517 [I-D.IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM 518 [RFC7333][RFC7429][I-D.DMM-PMIPv6]. 520 7. References 522 7.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 528 in IPv6", RFC 3775, June 2004. 530 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 531 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 532 September 2007. 534 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 535 Address Autoconfiguration", RFC 4862, September 2007. 537 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., and K. 538 Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008. 540 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 541 "Requirements for Distributed Mobility Management", 542 RFC 7333, August 2014. 544 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 545 Bernardos, "Distributed Mobility Management: Current 546 Practices and Gap Analysis", RFC 7429, January 2015. 548 7.2. Informative References 550 [I-D.DMM-PMIPv6] 551 Bernardos, CJ., Oliva, A., Giust, F., Zuniga, JC., and A. 552 Mourad, "Proxy Mobile IPv6 extensions for Distributed 553 Mobility Management", draft-ietf-dmm-pmipv6-dlif-04 (work 554 in progress), January 2019. 556 [I-D.IPWAVE-PS] 557 Jeong, J., Ed., "IP Wireless Access in Vehicular 558 Environments (IPWAVE): Problem Statement and Use Cases", 559 draft-ietf-ipwave-vehicular-networking-08 (work in 560 progress), March 2019. 562 [I-D.IPWAVE-VND] 563 Jeong, J., Ed., Shen, Y., and Z. Xiang, "IPv6 Neighbor 564 Discovery for IP-Based Vehicular Networks", draft-jeong- 565 ipwave-vehicular-neighbor-discovery-06 (work in progress), 566 March 2019. 568 [IEEE-802.11-OCB] 569 "Part 11: Wireless LAN Medium Access Control (MAC) and 570 Physical Layer (PHY) Specifications", IEEE Std 571 802.11-2016, December 2016. 573 [TS-23.285-3GPP] 574 3GPP, "Architecture Enhancements for V2X Services", 3GPP 575 TS 23.285, June 2018. 577 [VIP-WAVE] 578 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 579 Feasibility of IP Communications in 802.11p Vehicular 580 Networks", IEEE Transactions on Intelligent Transportation 581 Systems, vol. 14, no. 1, March 2013. 583 [WAVE-1609.0] 584 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 585 in Vehicular Environments (WAVE) - Architecture", IEEE Std 586 1609.0-2013, March 2014. 588 Appendix A. Acknowledgments 590 This work was supported by Basic Science Research Program through the 591 National Research Foundation of Korea (NRF) funded by the Ministry of 592 Education (2017R1D1A1B03035885). 594 Authors' Addresses 596 Jaehoon Paul Jeong 597 Department of Software 598 Sungkyunkwan University 599 2066 Seobu-Ro, Jangan-Gu 600 Suwon, Gyeonggi-Do 16419 601 Republic of Korea 603 Phone: +82 31 299 4957 604 Fax: +82 31 290 7996 605 EMail: pauljeong@skku.edu 606 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 608 Yiwen Chris Shen 609 Department of Electrical and Computer Engineering 610 Sungkyunkwan University 611 2066 Seobu-Ro, Jangan-Gu 612 Suwon, Gyeonggi-Do 16419 613 Republic of Korea 615 Phone: +82 31 299 4106 616 Fax: +82 31 290 7996 617 EMail: chrisshen@skku.edu 619 Zhong Xiang 620 Department of Electrical and Computer Engineering 621 Sungkyunkwan University 622 2066 Seobu-Ro, Jangan-Gu 623 Suwon, Gyeonggi-Do 16419 624 Republic of Korea 626 Phone: +82 10 9895 1211 627 Fax: +82 31 290 7996 628 EMail: xz618@skku.edu