idnits 2.17.1 draft-jeong-ipwave-vehicular-mobility-management-03.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 (May 7, 2020) is 1448 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 488, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-14 ** 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 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-09 Summary: 5 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: November 8, 2020 Sungkyunkwan University 6 May 7, 2020 8 Vehicular Mobility Management for IP-Based Vehicular Networks 9 draft-jeong-ipwave-vehicular-mobility-management-03 11 Abstract 13 This document specifies a Vehicular Mobility Management (VMM) scheme 14 for IP-based vehicular networks. The VMM scheme takes advantage of a 15 vehicular link model based on a multi-link subnet. With a vehicle's 16 mobility information (e.g., position, speed, acceleration/ 17 deceleration, and direction) and navigation path (i.e., trajectory), 18 it can provide a moving vehicle with proactive and seamless handoff 19 along 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 November 8, 2020. 38 Copyright Notice 40 Copyright (c) 2020 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 8.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility- 70 management-02 . . . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 This document proposes a mobility management scheme for IP-based 76 vehicular networks, which is called Vehicular Mobility Management 77 (VMM). The VMM is tailored for a vehicular network architecture and 78 a vehicular link model described in the IPWAVE problem statement 79 document [ID-IPWAVE-PS]. 81 To support the interaction between vehicles or between vehicles and 82 Rode-Side Units (RSUs), Vehicular Neighbor Discovery (VND) is 83 proposed as an enhanced IPv6 Neighbor Discovery (ND) for IP-based 84 vehicular networks [ID-IPWAVE-VND]. For an efficient IPv6 Stateless 85 Address Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized 86 Address Registration using a multihop Duplicate Address Detection 87 (DAD). This multihop DAD enables a vehicle to have a unique IP 88 address in a multi-link subnet that consists of multiple wireless 89 subnets with the same IP prefix, which corresponds to wireless 90 coverage of multiple RSUs. Also, VND supports IP packet routing via 91 a connected Vehicular Ad Hoc Network (VANET) by letting vehicles 92 exchange the prefixes of their internal networks through their 93 external wireless interface. 95 The mobility management in this multi-link subnet needs a new 96 approach from legacy mobility management schemes. This document aims 97 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 into a Traffic Control Center (TCC) 102 in 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 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 has 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 communications 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 car 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) which are responsible for 168 the mobility management of vehicles. Each MA is in charge of the 169 mobility management of vehicles under its prefix domain, which is a 170 multi-link subnet of RSUs sharing the same prefix [ID-IPWAVE-PS]. A 171 vehicular network is a wireless network consisting of RSUs and 172 vehicles. RSUs are interconnected with each other through a wired 173 network, and vehicles can construct VANETs via V2V and V2I 174 communications. 176 *-----------------------------------------* 177 * TCC in Vehicular Cloud * 178 * +-------------------------------------+ * 179 +--------+ * | +---------+ +---------+ | * 180 | CN1 |<---->* | | MA1 |<------->| MA2 | | * 181 +--------+ * | +---------+ +---------+ | * 182 * +-------------------------------------+ * 183 * ^ ^ * 184 * | INTERNET | * 185 *---------v--------------------v----------* 186 ^ ^ ^ 187 | Ethernet | | 188 | | | 189 v v v 190 +--------+ Ethernet +--------+ Ethernet +--------+ 191 | RSU1 |<-------->| RSU2 |<-------->| RSU3 | 192 +--------+ +--------+ +--------+ 193 ^ ^ ^ 194 : : : 195 +-----------------------------------+ +-----------------+ 196 | : V2I V2I : | | V2I : | 197 | v v | | v | 198 +--------+ | +--------+ +--------+ | | +--------+ | 199 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===> | | |Vehicle4|===> | 200 | |<.....>| |<.....>| | | | | | | 201 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 202 | | | | 203 +-----------------------------------+ +-----------------+ 204 Subnet1 Subnet2 206 <----> Wired Link <....> Wireless Link ===> Moving Direction 208 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 210 In Figure 1, three RSUs are deployed either at intersections or along 211 roadways. They are connected to an MA through wired networks. In 212 the vehicular network, there are two subnets such as Subnet1 and 213 Subnet2. Subnet1 is a multi-link subnet consisting of multiple 214 wireless coverage areas of multiple RSUs, and those areas share the 215 same IPv6 prefix to construct a single logical subnet [ID-IPWAVE-PS]. 216 That is, the wireless links of RSU1 and RSU2 belong to Subnet1. 217 Thus, since Vehicle2 and Vehicle3 use the same prefix for Subnet1 and 218 they are within the wireless communication range, they can 219 communicate directly with each other. Note that in a multi-link 220 subnet, a vehicle (e.g., Vehicle2 and Vehicle3 in Figure 1) can 221 configure its global IPv6 address through an address registration 222 procedure including a multihop DAD, which is specified in VND 223 [ID-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 Vehicle1 are disconnected from Vehicle3, they can communicate 233 indirectly with each other through RSUs such as RSU1 and RSU2. 235 This document specifies a mobility management scheme in the vehicular 236 network architecture, as shown in Figure 1, it is assumed that 237 Vehicle2 communicates with the corresponding node denoted as CN1 238 where Vehicle2 is moving in the wireless coverage of RSU1. When 239 Vehicle2 moves out of the coverage of RSU1 and moves into the 240 coverage of RSU2 where RSU1 and RSU2 share the same prefix, the 241 packets sent by CN1 should be routed toward Vehicle2 via RSU2. Also, 242 when Vehicle2 moves out of the coverage of RSU2 and moves into the 243 coverage of RSU3 where RSU2 and RSU3 use two different prefixes, the 244 packets of CN1 should be delivered to Vehicle2 via RSU3. With a 245 handoff procedure, a sender's packets can be delivered to a 246 destination vehicle which is moving in the wireless coverage areas. 248 5. Mobility Management 250 This section explains the detailed procedure of mobility management 251 of a vehicle in a road network as shown in Figure 1. 253 5.1. Network Attachment of a Vehicle 255 A mobility management is required for the seamless communication of 256 vehicles moving between the RSUs. When a vehicle moves into the 257 coverage of another RSU, a different IP address is assigned to the 258 vehicle, resulting in the re-configuration of transport-layer session 259 information (i.e., an end-point's IP address) to avoid service 260 disruption. Considering this issue, this document proposes a handoff 261 mechanism for seamless communication. 263 In [VIP-WAVE], the authors constructed a network-based mobility 264 management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which 265 is highly suitable for vehicular networks. This document uses a 266 mobility management procedure similar to PMIPv6 but a new proposed 267 Shared-Prefix model that vehicles in the same subnet share the same 268 prefix. 270 Vehicle RSU MA 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 including 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 [ID-IPWAVE-VND]. 311 In PMIPv6, a unique prefix is allocated to each vehicle by an MA 312 (i.e., LMA) to guarantee the uniqueness of each address, but in this 313 document, a unique IP address is allocated to each vehicle with the 314 same prefix by an MA in its domain through the multihop-DAD-based 315 address registration. This unique IP address allocation ensures that 316 vehicles own unique IP addresses in a multi-link subnet and can 317 reduce the waste of IP prefixes in legacy PMIPv6. 319 5.2. Handoff within One Prefix Domain 321 When the vehicle changes its location and its current RSU (denoted as 322 c-RSU) detects that the vehicle is moving out of its coverage, c-RSU 323 needs to report the leaving of the vehicle to the MA and de-register 324 the binding via PBU. 326 Vehicle c-RSU MA n-RSU 327 | | | | 328 | |===Bi-Dir Tunnel==| | 329 | | | | 330 | | | | 331 | |----DeReg PBU---->| | 332 | | | | 333 | | | | 334 | |<-------PBA-------| | 335 | | | | 336 | | | | 337 | | | | 338 | | | | 339 | | | | 340 |(------------------RS with Mobility Info-------------->)| 341 | [VMI] | | 342 | |<-------PBU-------| 343 | | | 344 | | | 345 | |--------PBA------>| 346 | | | 347 | | | 348 | |===Bi-Dir Tunnel==| 349 | | | 350 | | | 351 |<--------------------RA with prefix---------------------| 352 | | 354 Figure 3: Handoff of a Vehicle within One Prefix Domain with PMIPv6 356 With this report, the MA will send back a PBA to notice the de- 357 register to c-RSU, and get ready to detect new binding requests. If 358 MA can figure out the new RSU (denoted as n-RSU) based on the 359 vehicle's trajectory, it will directly change the end-point of the 360 tunnel into n-RSU's IP address for the vehicle. 362 Figure 3 shows the handoff of a vehicle within one prefix domain 363 (i.e., a multi-link subnet) with PMIPv6. As shown in the figure, 364 when the MA receives a new PBU from the n-RSU, it changes the 365 tunnel's end-point from the c-RSU to n-RSU. If there are ongoing IP 366 packets toward the vehicle, the MA encapsulates the packets and then 367 forwards them towards n-RSU. Through this network-based mobility 368 management, the vehicle is not aware of any changes at its network 369 layer and can maintain its transport-layer sessions without any 370 disruption. 372 Vehicle c-RSU n-RSU 373 | | | 374 |---------------------| | 375 |c-RSU detects leaving| | 376 |---------------------| | 377 | |--------PBU------>| 378 | | | 379 | |===Bi-Dir Tunnel==| 380 | | | 381 | |<-------PBA-------| 382 | | | 383 | | | 384 |(--------RS with Mobility Info-------->)| 385 | [VMI] | 386 | | 387 |<------------RA with prefix-------------| 388 | | 390 Figure 4: Handoff of a Vehicle within One Prefix Domain with DMM 392 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 393 specified routes with fixed RSU allocation, the procedure can be 394 simplified by constructing the bidirectional tunnel directly between 395 them (cancel the intervention of MA) to alleviate the traffic flow in 396 MA as well as reduce handoff delay. 398 Figure 4 shows the handoff of a vehicle within one prefix domain (as 399 a multi-link subnet) with DMM [ID-DMM-PMIPv6]. RSUs are in charge of 400 detecting when a node joins or moves through its domain. If c-RSU 401 detects that the vehicle is going to leave its coverage and to enter 402 the area of an adjacent RSU, it sends a PBU message to inform n-RSU 403 of the handoff of the vehicle. If n-RSU receives the PBU message, it 404 constructs a bidirectional tunnel between c-RSU and itself, and then 405 sends back a PBA message as an acknowledgment to c-RSU. If there are 406 ongoing IP packets toward the vehicle, c-RSU encapsulates the packets 407 and then forwards them to n-RSU. When n-RSU detects the entrance of 408 the vehicle, it directly sends an RA message to the vehicle so that 409 the vehicle can assure that it is still connected to a router with 410 its current prefix. If the vehicle sends an RS message to n-RSU, 411 n-RSU responds to the RS message by replying an RA to the vehicle. 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 to MA1. MA1 figures out that the vehicle will get into the coverage 451 of the n-RSU based on its trajectory and sends MA2 a PBU message to 452 inform MA2 that the vehicle will enter the coverage of n-RSU 453 belonging to MA2. MA2 sends n-RSU a PBA message to inform n-RSU that 454 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). 459 After n-RSU receives the PBA message including the handoff context 460 from MA2, it sets up a bi-directional tunnel with MA2, and generates 461 RA messages with c-RSU's context information. That is, n-RSU 462 pretends to be a router belonging to Subnet1. When the vehicle 463 receives RA from n-RSU, it can maintain its connection with its 464 corresponding node (i.e., CN1). Note that n-RSU also sends RA 465 messages with its domain prefix called prefix2. The vehicle 466 configures another global IP address with prefix2, and can use it for 467 communication with neighboring vehicles under the coverage of n-RSU. 469 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 470 specified routes with fixed RSU allocation, the procedure can be 471 simplified by constructing the bidirectional tunnel directly between 472 them (cancel the intervention of MAs) to alleviate the traffic flow 473 in MA as well as reduce handoff delay. 475 Vehicle c-RSU n-RSU 476 | | | 477 |---------------------| | 478 |c-RSU detects leaving| | 479 |---------------------| | 480 | |--------PBU------>| 481 | | | 482 | |===Bi-Dir Tunnel==| 483 | | | 484 | |<-------PBA-------| 485 | | | 486 | | | 487 |(--------RS with Mobility Info-------->)| 488 | [VMI] | 489 | | 490 |<--------RA with prefix1 (c-RSU)--------| 491 | | 492 |<--------RA with prefix2 (n-RSU)--------| 493 | | 495 Figure 6: Handoff of a Vehicle within Multiple Prefix Domains with 496 DMM 498 Figure 6 shows the handoff of a vehicle within two prefix domains (as 499 two multi-link subnets) with DMM [ID-DMM-PMIPv6]. If c-RSU detects 500 that the vehicle is going to leave its coverage and to enter the area 501 of an adjacent RSU (n-RSU) belonging to a different prefix domain, it 502 sends a PBU message to inform n-RSU that the vehicle will enter the 503 coverage of n-RSU along with handoff context such as c-RSU's context 504 information (e.g., c-RSU's link-local address and prefix called 505 prefix1), and the vehicle's context information (e.g., the vehicle's 506 global IP address and MAC address). After n-RSU receives the PBA 507 message including the handoff context from c-RSU, it sets up a bi- 508 directional tunnel with c-RSU, and generates RA messages with c-RSU's 509 context information. That is, n-RSU pretends to be a router 510 belonging to Subnet1. When the vehicle receives RA from n-RSU, it 511 can maintain its connection with its corresponding node (i.e., CN1). 512 Note that n-RSU also sends RA messages with its domain prefix called 513 prefix2. The vehicle configures another global IP address with 514 prefix2, and can use it for communication with neighboring vehicles 515 under the coverage of n-RSU. 517 6. Security Considerations 519 This document shares all the security issues of Vehicular ND 520 [ID-IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM 521 [RFC7333][RFC7429][ID-DMM-PMIPv6]. 523 7. Acknowledgments 525 This work was supported by Basic Science Research Program through the 526 National Research Foundation of Korea (NRF) funded by the Ministry of 527 Education (2017R1D1A1B03035885). 529 This work was supported in part by Institute of Information & 530 Communications Technology Planning & Evaluation (IITP) grant funded 531 by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, 532 Cloud based Security Intelligence Technology Development for the 533 Customized Security Service Provisioning). 535 This work was supported in part by the MSIT under the ITRC 536 (Information Technology Research Center) support program (IITP- 537 2019-2017-0-01633) supervised by the IITP. 539 8. References 541 8.1. Normative References 543 [ID-IPWAVE-PS] 544 Jeong, J., Ed., "IPv6 Wireless Access in Vehicular 545 Environments (IPWAVE): Problem Statement and Use Cases", 546 draft-ietf-ipwave-vehicular-networking-14 (work in 547 progress), March 2020. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 553 in IPv6", RFC 3775, June 2004. 555 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 556 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 557 September 2007. 559 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 560 Address Autoconfiguration", RFC 4862, September 2007. 562 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., and K. 563 Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008. 565 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 566 "Requirements for Distributed Mobility Management", 567 RFC 7333, August 2014. 569 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 570 Bernardos, "Distributed Mobility Management: Current 571 Practices and Gap Analysis", RFC 7429, January 2015. 573 8.2. Informative References 575 [ID-DMM-PMIPv6] 576 Bernardos, CJ., Oliva, A., Giust, F., Zuniga, JC., and A. 577 Mourad, "Proxy Mobile IPv6 extensions for Distributed 578 Mobility Management", draft-ietf-dmm-pmipv6-dlif-06 (work 579 in progress), March 2020. 581 [ID-IPWAVE-VND] 582 Jeong, J., Ed., Shen, Y., Xiang, Z., and S. Cespedes, 583 "Vehicular Neighbor Discovery for IP-Based Vehicular 584 Networks", draft-jeong-ipwave-vehicular-neighbor- 585 discovery-09 (work in progress), May 2020. 587 [IEEE-802.11-OCB] 588 "Part 11: Wireless LAN Medium Access Control (MAC) and 589 Physical Layer (PHY) Specifications", IEEE Std 590 802.11-2016, December 2016. 592 [TS-23.285-3GPP] 593 3GPP, "Architecture Enhancements for V2X Services", 3GPP 594 TS 23.285, June 2018. 596 [VIP-WAVE] 597 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 598 Feasibility of IP Communications in 802.11p Vehicular 599 Networks", IEEE Transactions on Intelligent Transportation 600 Systems, vol. 14, no. 1, March 2013. 602 [WAVE-1609.0] 603 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 604 in Vehicular Environments (WAVE) - Architecture", IEEE Std 605 1609.0-2013, March 2014. 607 Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility- 608 management-02 610 The following changes are made from draft-jeong-ipwave-vehicular- 611 mobility-management-02: 613 o This version has a submission date update to maintain the active 614 status of the draft. 616 o This version updates the version numbers of the referenced drafts. 618 Authors' Addresses 620 Jaehoon Paul Jeong 621 Department of Computer Science and Engineering 622 Sungkyunkwan University 623 2066 Seobu-Ro, Jangan-Gu 624 Suwon, Gyeonggi-Do 16419 625 Republic of Korea 627 Phone: +82 31 299 4957 628 Fax: +82 31 290 7996 629 EMail: pauljeong@skku.edu 630 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 632 Yiwen Chris Shen 633 Department of Electrical and Computer Engineering 634 Sungkyunkwan University 635 2066 Seobu-Ro, Jangan-Gu 636 Suwon, Gyeonggi-Do 16419 637 Republic of Korea 639 Phone: +82 31 299 4106 640 Fax: +82 31 290 7996 641 EMail: chrisshen@skku.edu 643 Zhong Xiang 644 Department of Electrical and Computer Engineering 645 Sungkyunkwan University 646 2066 Seobu-Ro, Jangan-Gu 647 Suwon, Gyeonggi-Do 16419 648 Republic of Korea 650 Phone: +82 10 9895 1211 651 Fax: +82 31 290 7996 652 EMail: xz618@skku.edu