idnits 2.17.1 draft-jeong-ipwave-vehicular-mobility-management-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 21, 2021) is 1157 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 487, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-19 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'ID-IPWAVE-PS') ** 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 ** Downref: Normative reference to an Experimental RFC: RFC 8885 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-11 Summary: 6 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 B. Mugabarigira 4 Intended status: Standards Track Y. Shen 5 Expires: August 25, 2021 Z. Xiang 6 Sungkyunkwan University 7 February 21, 2021 9 Vehicular Mobility Management for IP-Based Vehicular Networks 10 draft-jeong-ipwave-vehicular-mobility-management-05 12 Abstract 14 This document specifies a Vehicular Mobility Management (VMM) scheme 15 for IP-based vehicular networks. The VMM scheme takes advantage of a 16 vehicular link model based on a multi-link subnet. With a vehicle's 17 mobility information (e.g., position, speed, acceleration/ 18 deceleration, and direction) and navigation path (i.e., trajectory), 19 it can provide a moving vehicle with proactive and seamless handoff 20 along with its trajectory. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 25, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Vehicular Network Architecture . . . . . . . . . . . . . . . 4 60 4.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 4 61 5. Mobility Management . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Network Attachment of a Vehicle . . . . . . . . . . . . . 6 63 5.2. Handoff within One Prefix Domain . . . . . . . . . . . . 8 64 5.3. Handoff between Multiple Prefix Domains . . . . . . . . . 10 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 8.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility- 71 management-04 . . . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 This document proposes a mobility management scheme for IP-based 77 vehicular networks, called Vehicular Mobility Management (VMM). The 78 VMM is tailored for a vehicular network architecture and a vehicular 79 link model described in the IPWAVE problem statement document 80 [ID-IPWAVE-PS]. 82 Vehicle Neighbor Discovery (VND) is proposed as Extended IPv6 83 Neighbor Discovery (ND) for IP-based vehicle networks [ID-IPWAVE-VND] 84 to support the vehicle-to-vehicle or the vehicle to Road-Side Unit 85 (RSU) interactions. For an efficient IPv6 Stateless Address 86 Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized Address 87 Registration using a multihop Duplicate Address Detection (DAD). 88 This multihop DAD enables a vehicle to have a unique IP address in a 89 multi-link subnet consisting of multiple wireless subnets with the 90 same IP prefix, which corresponds to wireless coverage of multiple 91 RSUs. VND also supports IP packet routing over a connected Vehicular 92 Ad Hoc Network (VANET) by allowing vehicles to exchange the prefixes 93 of their internal networks through their external wireless interface. 95 The mobility management in this multi-link subnet needs a new 96 approach from the legacy mobility management schemes. This document 97 aims at an efficient mobility management scheme called VMM to support 98 efficient V2V, V2I, and V2X communications in a road network. The 99 VMM takes advantage of the mobility information (e.g.,a vehicle's 100 speed, direction, and position) and trajectory (i.e., navigation 101 path) of each vehicle registered in the Traffic Control Center (TCC) 102 of the vehicular cloud. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 3. Terminology 112 This document uses the terminology described in [RFC4861] and 113 [RFC4862]. In addition, the following new terms are defined as 114 below: 116 o DMM: Acronym for "Distributed Mobility Management" 117 [RFC7333][RFC7429]. 119 o Mobility Anchor (MA): A node that maintains the IP addresses and 120 mobility information of vehicles in a road network to support 121 their address autoconfiguration and mobility management with a 122 binding table. It has end-to-end connections with RSUs under its 123 control. 125 o On-Board Unit (OBU): A node that with a network interface (e.g., 126 IEEE 802.11-OCB and Cellular V2X (C-V2X) [TS-23.285-3GPP]) for 127 wireless communications with other OBUs and RSUs, and may be 128 connected to in-vehicle devices or networks. An OBU is mounted on 129 a vehicle. It is assumed that a radio navigation receiver (e.g., 130 Global Positioning System (GPS)) is included in a vehicle with an 131 OBU for efficient navigation. 133 o OCB: Acronym for "Outside the Context of a Basic Service Set" 134 [IEEE-802.11-OCB]. 136 o Road-Side Unit (RSU): A node that has physical communication 137 devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless 138 communication with vehicles and is also connected to the Internet 139 as a router or switch for packet forwarding. An RSU is typically 140 deployed on the road infrastructure, either at an intersection or 141 in a road segment, but may also be located in cars parking areas. 143 o Traffic Control Center (TCC): A node that maintains road 144 infrastructure information (e.g., RSUs, traffic signals, and loop 145 detectors), vehicular traffic statistics (e.g., average vehicle 146 speed and vehicle inter-arrival time per road segment), and 147 vehicle information (e.g., a vehicle's identifier, position, 148 direction, speed, and trajectory as a navigation path). TCC is 149 included in a vehicular cloud for vehicular networks. 151 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 152 having compute nodes, storage nodes, and network nodes. 154 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 155 [WAVE-1609.0]. 157 4. Vehicular Network Architecture 159 This section describes a vehicular network architecture for V2V and 160 V2I communication. A vehicle and an RSU have their internal networks 161 including in-vehicle devices or servers, respectively. 163 4.1. Vehicular Network 165 A vehicular network architecture for V2I and V2V is illustrated in 166 Figure 1. In this figure, there is a vehicular cloud containing a 167 TCC. The TCC has Mobility Anchors (MAs) responsible for the vehicles 168 mobility management. Each MA is in charge of the mobility management 169 of vehicles under its prefix domain, which is a multi-link subnet of 170 RSUs sharing the same prefix [ID-IPWAVE-PS]. A vehicular network is 171 a wireless network consisting of RSUs and vehicles. The RSUs are 172 interconnected via a wired network, allowing vehicles to build VANETs 173 via V2V and V2I communications. 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. The 211 vehicular network has two subnets, such as Subnet1 and Subnet2. 212 Subnet1 is a multi-link subnet consisting of multiple wireless 213 coverage areas of multiple RSUs, which share the same IPv6 prefix to 214 construct a single logical subnet [ID-IPWAVE-PS]. That is, the RSU1 215 and RSU2 wireless links belong to Subnet1. Thus, since Vehicle2 and 216 Vehicle3 use the same prefix for Subnet1 and they are within the 217 wireless communication range, they can communicate directly with each 218 other. Note that in a multi-link subnet, a vehicle (e.g., Vehicle2 219 and Vehicle3 in Figure 1) can configure its global IPv6 address 220 through an address registration procedure that includes the multihop 221 DAD specified in VND [ID-IPWAVE-VND]. 223 Subnet2 on the other hand, uses a different prefix than Subnet1. 224 Vehicle4 residing in Subnet2 cannot communicate directly to Vehicle3 225 because it belongs to a different subnet. Vehicles can construct a 226 connected VANET so they can communicate with each other without the 227 relaying on RSU, but the forwarding over the VANET. In the case 228 where two vehicles belong to the same multi-link subnet, but they are 229 not connected in the same VANET, they can use RSUs. In Figure 1, 230 even though Vehicle1 is disconnected from Vehicle3, they can 231 communicate indirectly with each other through RSUs such as RSU1 and 232 RSU2. 234 This document specifies a mobility management scheme for the 235 vehicular network architecture, as shown in Figure 1. Vehicle2 is 236 supposed to communicates with the corresponding node denoted as CN1, 237 and Vehicle2 is moving in the wireless coverage of RSU1. When 238 Vehicle2 moves out of the coverage of RSU1 and moves into the 239 coverage of RSU2 where RSU1 and RSU2 share the same prefix, packets 240 sent by CN1 should be routed through RSU2 to Vehicle2. Also, when 241 Vehicle2 moves out of the coverage of RSU2 and moves into the 242 coverage of RSU3 where RSU2 and RSU3 use two different prefixes, the 243 CN1 packets should be delivered to Vehicle2 via RSU3. A handoff 244 procedure allows a sender's packets to be delivered to a destination 245 vehicle which is moving within the wireless coverage areas. 247 5. Mobility Management 249 This section explains the detailed procedure of mobility management 250 of a vehicle in a road network as shown in Figure 1. 252 5.1. Network Attachment of a Vehicle 254 A mobility management is required for the seamless communication of 255 vehicles moving between the RSUs. When a vehicle moves into the 256 coverage of another RSU, a different IP address is assigned to the 257 vehicle, the transport-layersession information (i.e., an end-point's 258 IP address) is reconfigured to avoid service disruption. Considering 259 this issue, this document proposes a handoff mechanism for seamless 260 communication. 262 In [VIP-WAVE], the authors constructed a network-based mobility 263 management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which 264 is highly suitable for vehicular networks. This document uses a 265 mobility management procedure similar to PMIPv6, but uses a newly 266 proposed Shared-Prefix model in which vehicles in the same subnet 267 share the same prefix. 269 Vehicle RSU MA 270 | | | 271 |-RS with Mobility Info->| | 272 | [VMI] | | 273 | | | 274 | |--------PBU------>| 275 | | | 276 | | | 277 | |<-------PBA-------| 278 | | | 279 | | | 280 | |===Bi-Dir Tunnel==| 281 | | | 282 | | | 283 |<----RA with prefix-----| | 284 | | | 286 Figure 2: Message Interaction for a Vehicle's Network Attachment 288 Figure 2 shows the binding update flow when a vehicle entered the RSU 289 subnet. The RSUs act as Mobility Anchor Gateway (MAG) defined in 290 [VIP-WAVE]. When it receives an RS message from a vehicle containing 291 its mobility information (e.g., position, speed, and direction), an 292 RSU sends a Proxy Binding Update (PBU) message to its MA 293 [RFC5213][RFC3775]. This contains a Mobility Option including the 294 vehicle's mobility information. The MA receives the PBU and sets up 295 a Binding Cache Entry (BCE) as well as a bi-directional tunnel 296 (denoted as Bi-Dir Tunnel in Figure 2) between the serving RSU and 297 itself. Through this tunnel, all traffic packets to the vehicle are 298 encapsulated toward the RSU. Simultaneously, the MA sends back a 299 Proxy Binding Acknowledgment (PBA) message to the serving RSU. This 300 serving RSU receives the PBA and sets up a bi-directional tunnel with 301 the MA. After this binding update, the RSU sends back an RA message 302 to the vehicle. This message includes the RSU's prefix for the 303 address autoconfiguration of the vehicle. 305 When the vehicle receives the RA message, it performs the address 306 registration procedure including a multihop DAD for its global IP 307 address based on the prefix announced by the RA message according to 308 the VND [ID-IPWAVE-VND]. 310 In PMIPv6, an MA (i.e., LMA) allocates a unique prefix to each 311 vehicle to guarantee the uniqueness of each address, but in this 312 document, an MA allocates in its domain a unique IP address to each 313 vehicle with the same prefix through the multihop-DAD-based address 314 registration. This unique IP address allocation ensures that 315 vehicles own unique IP addresses in a multi-link subnet and can 316 reduce the waste of IP prefixes in legacy PMIPv6. 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 vehicle is moving out of its coverage, the 322 c-RSU reports the leaving of the vehicle to the MA and de-register 323 the binding via PBU. 325 Vehicle c-RSU MA 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 will send back a PBA to notice the de- 356 register to c-RSU, and get ready to detect new binding requests. If 357 MA can figure out the new RSU (denoted as n-RSU) based on the 358 vehicle's trajectory, it will directly change the end-point of the 359 tunnel into n-RSU's IP address for the vehicle. 361 Figure 3 shows the handoff of a vehicle within one prefix domain 362 (i.e., a multi-link subnet) with PMIPv6. As shown in the figure, 363 when the MA receives a new PBU from the n-RSU, it changes the 364 tunnel's end-point from the c-RSU to n-RSU. If there are ongoing IP 365 packets toward the vehicle, the MA encapsulates the packets and then 366 forwards them towards n-RSU. Through this network-based mobility 367 management, the vehicle is not aware of any changes at its network 368 layer and can maintain its transport-layer sessions without any 369 disruption. 371 Vehicle c-RSU n-RSU 372 | | | 373 |---------------------| | 374 |c-RSU detects leaving| | 375 |---------------------| | 376 | |--------PBU------>| 377 | | | 378 | |===Bi-Dir Tunnel==| 379 | | | 380 | |<-------PBA-------| 381 | | | 382 | | | 383 |(--------RS with Mobility Info-------->)| 384 | [VMI] | 385 | | 386 |<------------RA with prefix-------------| 387 | | 389 Figure 4: Handoff of a Vehicle within One Prefix Domain with DMM 391 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 392 specified routes with fixed RSU allocation, the procedure can be 393 simplified by constructing the bidirectional tunnel directly between 394 them (cancel the intervention of MA) to alleviate the traffic flow in 395 MA as well as reduce handoff delay. 397 Figure 4 shows a vehicle handoff within one prefix domain (as a 398 multi-link subnet) with DMM [RFC8885]. The RSUs are in charge of 399 detecting when a node joins or moves to its domain. If the c-RSU 400 detects that the vehicle is going to leave its coverage and to enter 401 the area of an adjacent RSU, it sends a PBU message to inform n-RSU 402 of the vehicle's handoff. If n-RSU receives the PBU message, it 403 constructs a bidirectional tunnel between c-RSU and itself, and then 404 sends back a PBA message as an acknowledgment to c-RSU. If there are 405 ongoing IP packets toward the vehicle, c-RSU encapsulates the packets 406 and then forwards them to n-RSU. When n-RSU detects the entrance of 407 the vehicle, it directly sends an RA message to the vehicle so that 408 the vehicle can assure that it is still connected to a router with 409 its current prefix. If the vehicle sends an RS message to n-RSU, 410 n-RSU responds to the RS message by replying to the vehicle with an 411 RA . 413 5.3. Handoff between Multiple Prefix Domains 415 When the vehicle moves from a prefix domain to another prefix domain, 416 a handoff between multiple prefix domains is required. As shown in 417 Figure 1, when Vehicle3 moves from the subnet of RSU2 (i.e., Subnet1) 418 to the subnet of RSU3 (i.e., Subnet2), a multiple domain handoff is 419 performed through the cooperation of RSU2, RSU3, MA1 and MA2. 421 Vehicle c-RSU MA1 MA2 n-RSU 422 | | | | | 423 | |==Bi-Dir Tunnel==| | | 424 | | | | | 425 | | | | | 426 | |---DeReg PBU---->| | | 427 | | |-------PBU----->| | 428 | | | | | 429 | |<------PBA-------| |-------PBA------>| 430 | | | | | 431 | | | |==Bi-Dir Tunnel==| 432 | | | | | 433 | | | | | 434 |(----------------------RS with Mobility Info------------------->)| 435 | | [VMI] | | 436 | | | | | 437 | | | | | 438 |<----------------------RA with prefix1 (c-RSU)-------------------| 439 | | | | | 440 |<----------------------RA with prefix2 (n-RSU)-------------------| 441 | | | | | 443 Figure 5: Handoff of a Vehicle between Multiple Prefix Domains with 444 PMIPv6 446 Figure 5 shows the handoff of a vehicle between two prefix domains 447 (i.e., two multi-link subnets) with PMIPv6. When the vehicle moves 448 out of its c-RSU belonging to Subnet1, and moves into the n-RSU 449 belonging to Subnet2, c-RSU detects the vehicle's leaving and reports 450 it to MA1. MA1 figures out that the vehicle will get into the 451 coverage of the n-RSU based on its trajectory and sends MA2 a PBU 452 message to inform MA2 that the vehicle will enter the coverage of 453 n-RSU belonging to MA2. MA2 sends a PBA message to n-RSU to inform 454 that the vehicle will enter the coverage of n-RSU along with handoff 455 context such as c-RSU's context information (e.g., c-RSU's link-local 456 address and prefix called prefix1), and the vehicle's context 457 information (e.g., the vehicle's global IP address and MAC address). 458 After n-RSU receives the PBA message including the handoff context 459 from MA2, it sets up a bi-directional tunnel with MA2, and generates 460 RA messages with c-RSU's context information. That is, n-RSU 461 pretends to be a router belonging to Subnet1. When the vehicle 462 receives RA from n-RSU, it can maintain its connection with its 463 corresponding node (i.e., CN1). Note that n-RSU also sends RA 464 messages with its domain prefix called prefix2. The vehicle 465 configures another global IP address with prefix2, and can use it for 466 communication with neighboring vehicles under the coverage of n-RSU. 468 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 469 specified routes with fixed RSU allocation, the procedure can be 470 simplified by constructing the bidirectional tunnel directly between 471 them (cancel the intervention of MAs) to alleviate the traffic flow 472 in MA as well as reduce handoff delay. 474 Vehicle c-RSU n-RSU 475 | | | 476 |---------------------| | 477 |c-RSU detects leaving| | 478 |---------------------| | 479 | |--------PBU------>| 480 | | | 481 | |===Bi-Dir Tunnel==| 482 | | | 483 | |<-------PBA-------| 484 | | | 485 | | | 486 |(--------RS with Mobility Info-------->)| 487 | [VMI] | 488 | | 489 |<--------RA with prefix1 (c-RSU)--------| 490 | | 491 |<--------RA with prefix2 (n-RSU)--------| 492 | | 494 Figure 6: Handoff of a Vehicle within Multiple Prefix Domains with 495 DMM 497 Figure 6 shows the vehicle handoff within two prefix domains (as two 498 multi-link subnets) with DMM [RFC8885]. If c-RSU detects that the 499 vehicle is going to leave its coverage and to enter the area of an 500 adjacent RSU (n-RSU) belonging to a different prefix domain, it sends 501 a PBU message to inform n-RSU that the vehicle will enter the 502 coverage of n-RSU along with handoff context such as c-RSU's context 503 information (e.g., c-RSU's link-local address and prefix called 504 prefix1), and the vehicle's context information (e.g., the vehicle's 505 global IP address and MAC address). After n-RSU receives the PBA 506 message including the handoff context from c-RSU, it sets up a bi- 507 directional tunnel with c-RSU, and generates RA messages with c-RSU's 508 context information. That is, n-RSU pretends to be a router 509 belonging to Subnet1. When the vehicle receives RA from n-RSU, it 510 can maintain its connection with its corresponding node (i.e., CN1). 511 Note that n-RSU also sends RA messages with its domain prefix called 512 prefix2. The vehicle configures another global IP address with 513 prefix2, and can use it for communication with neighboring vehicles 514 under the coverage of n-RSU. 516 6. Security Considerations 518 This document shares all the security issues of Vehicular ND 519 [ID-IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM 520 [RFC7333][RFC7429][RFC8885]. 522 7. Acknowledgments 524 This work was supported by Basic Science Research Program through the 525 National Research Foundation of Korea (NRF) funded by the Ministry of 526 Education (2017R1D1A1B03035885). 528 This work was supported in part by Institute of Information & 529 Communications Technology Planning & Evaluation (IITP) grant funded 530 by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, 531 Cloud based Security Intelligence Technology Development for the 532 Customized Security Service Provisioning). 534 This work was supported in part by the MSIT under the ITRC 535 (Information Technology Research Center) support program (IITP- 536 2019-2017-0-01633) supervised by the IITP. 538 8. References 540 8.1. Normative References 542 [ID-IPWAVE-PS] 543 Jeong, J., Ed., "IPv6 Wireless Access in Vehicular 544 Environments (IPWAVE): Problem Statement and Use Cases", 545 draft-ietf-ipwave-vehicular-networking-19 (work in 546 progress), July 2020. 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 552 in IPv6", RFC 3775, June 2004. 554 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 555 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 556 September 2007. 558 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 559 Address Autoconfiguration", RFC 4862, September 2007. 561 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., and K. 562 Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008. 564 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 565 "Requirements for Distributed Mobility Management", 566 RFC 7333, August 2014. 568 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 569 Bernardos, "Distributed Mobility Management: Current 570 Practices and Gap Analysis", RFC 7429, January 2015. 572 [RFC8885] Bernardos, CJ., Oliva, A., Giust, F., Zuniga, JC., and A. 573 Mourad, "Proxy Mobile IPv6 Extensions for Distributed 574 Mobility Management", RFC 8885, October 2020. 576 8.2. Informative References 578 [ID-IPWAVE-VND] 579 Jeong, J., Ed., Shen, Y., Xiang, Z., and S. Cespedes, 580 "Vehicular Neighbor Discovery for IP-Based Vehicular 581 Networks", draft-jeong-ipwave-vehicular-neighbor- 582 discovery-11 (work in progress), February 2021. 584 [IEEE-802.11-OCB] 585 "Part 11: Wireless LAN Medium Access Control (MAC) and 586 Physical Layer (PHY) Specifications", IEEE Std 587 802.11-2016, December 2016. 589 [TS-23.285-3GPP] 590 3GPP, "Architecture Enhancements for V2X Services", 3GPP 591 TS 23.285, June 2018. 593 [VIP-WAVE] 594 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 595 Feasibility of IP Communications in 802.11p Vehicular 596 Networks", IEEE Transactions on Intelligent Transportation 597 Systems, vol. 14, no. 1, March 2013. 599 [WAVE-1609.0] 600 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 601 in Vehicular Environments (WAVE) - Architecture", IEEE Std 602 1609.0-2013, March 2014. 604 Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility- 605 management-04 607 The following changes are made from draft-jeong-ipwave-vehicular- 608 mobility-management-04: 610 o This version has a submission date update to maintain the active 611 status of the document. 613 Authors' Addresses 615 Jaehoon (Paul) Jeong 616 Department of Computer Science and Engineering 617 Sungkyunkwan University 618 2066 Seobu-Ro, Jangan-Gu 619 Suwon, Gyeonggi-Do 16419 620 Republic of Korea 622 Phone: +82 31 299 4957 623 Fax: +82 31 290 7996 624 EMail: pauljeong@skku.edu 625 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 627 Bien Aime Mugabarigira 628 Department of Electrical and Computer Engineering 629 Sungkyunkwan University 630 2066 Seobu-Ro, Jangan-Gu 631 Suwon, Gyeonggi-Do 16419 632 Republic of Korea 634 Phone: +82 10 5964 8794 635 Fax: +82 31 290 7996 636 EMail: bienaime@skku.edu 638 Yiwen (Chris) Shen 639 Department of Electrical and Computer Engineering 640 Sungkyunkwan University 641 2066 Seobu-Ro, Jangan-Gu 642 Suwon, Gyeonggi-Do 16419 643 Republic of Korea 645 Phone: +82 31 299 4106 646 Fax: +82 31 290 7996 647 EMail: chrisshen@skku.edu 648 Zhong Xiang 649 Department of Electrical and Computer Engineering 650 Sungkyunkwan University 651 2066 Seobu-Ro, Jangan-Gu 652 Suwon, Gyeonggi-Do 16419 653 Republic of Korea 655 Phone: +82 10 9895 1211 656 Fax: +82 31 290 7996 657 EMail: xz618@skku.edu