idnits 2.17.1 draft-jeong-ipwave-vehicular-mobility-management-01.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 (July 8, 2019) is 1751 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 483, 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-09 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-07 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: January 9, 2020 Sungkyunkwan University 6 July 8, 2019 8 Vehicular Mobility Management for IP-Based Vehicular Networks 9 draft-jeong-ipwave-vehicular-mobility-management-01 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, and direction) and 17 navigation path (i.e., trajectory), it can provide a moving vehicle 18 with proactive and seamless handoff along with its trajectory. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Vehicular Network Architecture . . . . . . . . . . . . . . . 4 58 4.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 4 59 5. Mobility Management . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Network Attachment of a Vehicle . . . . . . . . . . . . . 6 61 5.2. Handoff within One Prefix Domain . . . . . . . . . . . . 8 62 5.3. Handoff between Multiple Prefix Domains . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 7.2. Informative References . . . . . . . . . . . . . . . . . 12 67 Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility- 68 management-00 . . . . . . . . . . . . . . . . . . . 14 69 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 This document proposes a mobility management scheme for IP-based 75 vehicular networks, which is called Vehicular Mobility Management 76 (VMM). The VMM is tailored for a vehicular network architecture and 77 a vehicular link model described in the IPWAVE problem statement 78 document [I-D.IPWAVE-PS]. 80 To support the interaction between vehicles or between vehicles and 81 Rode-Side Units (RSUs), Vehicular Neighbor Discovery (VND) is 82 proposed as an enhanced IPv6 Neighbor Discovery (ND) for IP-based 83 vehicular networks [I-D.IPWAVE-VND]. For an efficient IPv6 Stateless 84 Address Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized 85 Address Registration using a multihop Duplicate Address Detection 86 (DAD). This multihop DAD enables a vehicle to have a unique IP 87 address in a multi-link subnet that consists of multiple wireless 88 subnets with the same IP prefix, which corresponds to wireless 89 coverage of multiple RSUs. Also, VND supports IP packet routing via 90 a connected Vehicular Ad Hoc Network (VANET) by letting vehicles 91 exchange the prefixes of their internal networks through their 92 external wireless interface. 94 The mobility management in this multi-link subnet needs a new 95 approach from legacy mobility management schemes. This document aims 96 at an efficient mobility management scheme called VMM to support 97 efficient V2V, V2I, and V2X communications in a road network. The 98 VMM takes advantage of the mobility information (e.g., a vehicle's 99 speed, direction, and position) and trajectory (i.e., navigation 100 path) of each vehicle registered into a Traffic Control Center (TCC) 101 in the vehicular 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 TCC. 166 The TCC has Mobility Anchors (MAs) for the mobility management of 167 vehicles under its control. Each MA is in charge of the mobility 168 management of vehicles under its prefix domain, which is a multi-link 169 subnet of RSUs sharing the same prefix [I-D.IPWAVE-PS]. A vehicular 170 network is a wireless network consisting of RSUs and vehicles. RSUs 171 are interconnected with each other through a wired network, and 172 vehicles can construct VANETs via V2V and V2I communications. 174 *-----------------------------------------* 175 * TCC in Vehicular Cloud * 176 * +-------------------------------------+ * 177 +--------+ * | +---------+ +---------+ | * 178 | CN1 |<---->* | | MA1 |<------->| MA2 | | * 179 +--------+ * | +---------+ +---------+ | * 180 * +-------------------------------------+ * 181 * ^ ^ * 182 * | INTERNET | * 183 *---------v--------------------v----------* 184 ^ ^ ^ 185 | Ethernet | | 186 | | | 187 v v v 188 +--------+ Ethernet +--------+ Ethernet +--------+ 189 | RSU1 |<-------->| RSU2 |<-------->| RSU3 | 190 +--------+ +--------+ +--------+ 191 ^ ^ ^ 192 : : : 193 +-----------------------------------+ +-----------------+ 194 | : V2I V2I : | | V2I : | 195 | v v | | v | 196 +--------+ | +--------+ +--------+ | | +--------+ | 197 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===> | | |Vehicle4|===> | 198 | |<.....>| |<.....>| | | | | | | 199 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 200 | | | | 201 +-----------------------------------+ +-----------------+ 202 Subnet1 Subnet2 204 <----> Wired Link <....> Wireless Link ===> Moving Direction 206 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 208 In Figure 1, three RSUs are deployed either at intersections or along 209 roadways. They are connected to an MA through wired networks. In 210 the vehicular network, there are two subnets such as Subnet1 and 211 Subnet2. Subnet1 is a multi-link subnet consisting of multiple 212 wireless coverage areas of multiple RSUs, and those areas share the 213 same IPv6 prefix to construct a single logical subnet 214 [I-D.IPWAVE-PS]. That is, the wireless links of RSU1 and RSU2 belong 215 to Subnet1. Thus, since Vehicle2 and Vehicle3 use the same prefix 216 for Subnet1 and they are within the wireless communication range, 217 they can communicate directly with each other. Note that in a multi- 218 link subnet, a vehicle (e.g., Vehicle2 and Vehicle3 in Figure 1) can 219 configure its global IPv6 address through an address registration 220 procedure including a multihop DAD, which is specified in VND 221 [I-D.IPWAVE-VND]. 223 On the other hand, Subnet2 uses a prefix different from Subnet1's. 224 Vehicle4 residing in Subnet2 cannot talk to Vehicle3 directly because 225 they belong to different subnets. Vehicles can construct a connected 226 VANET, so they can communicate with each other without the relaying 227 of an RSU, but the forwarding over the VANET. In the case where two 228 vehicles belong to the same multi-link subnet, but they are not 229 connected in the same VANET, they can use RSUs. In Figure 1, even 230 though Vehicle1 are disconnected from Vehicle3, they can communicate 231 indirectly with each other through RSUs such as RSU1 and RSU2. 233 In Figure 1, it is assumed that Vehicle2 communicates with the 234 corresponding node denoted as CN1 where Vehicle2 is moving in the 235 wireless coverage of RSU1. When Vehicle2 moves out of the coverage 236 of RSU1 and moves into the coverage of RSU2 where RSU1 and RSU2 share 237 the same prefix, the packets sent by CN1 should be routed toward 238 Vehicle2. Also, when Vehicle2 moves out of the coverage of RSU2 and 239 moves into the coverage of RSU3 where RSU2 and RSU3 use two different 240 prefixes, the packets of CN1 should be delivered to Vehicle2. With a 241 handoff procedure, a sender's packets can be delivered to a 242 destination vehicle which is moving in the wireless coverage areas. 243 Thus, this document specifies a mobility management scheme in the 244 vehicular network architecture, as shown in Figure 1. 246 5. Mobility Management 248 This section explains the detailed procedure of mobility management 249 of a vehicle in a vehicular network as shown in Figure 1. 251 5.1. Network Attachment of a Vehicle 253 A mobility management is required for the seamless communication of 254 vehicles moving between the RSUs. When a vehicle moves into the 255 coverage of another RSU, a different IP address is assigned to the 256 vehicle, resulting in the re-configuration of transport-layer session 257 information (i.e., an end-point's IP address) to avoid service 258 disruption. Considering this issue, this document proposes a handoff 259 mechanism for seamless communication. 261 In [VIP-WAVE], the authors constructed a network-based mobility 262 management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which 263 is highly suitable for vehicular networks. This document uses a 264 mobility management procedure similar to PMIPv6 along with prefix 265 discovery. 267 Vehicle RSU MA 268 | | | 269 |-RS with Mobility Info->| | 270 | [VMI] | | 271 | | | 272 | |--------PBU------>| 273 | | | 274 | | | 275 | |<-------PBA-------| 276 | | | 277 | | | 278 | |===Bi-Dir Tunnel==| 279 | | | 280 | | | 281 |<----RA with prefix-----| | 282 | | | 284 Figure 2: Message Interaction for a Vehicle's Network Attachment 286 Figure 2 shows the binding update flow when a vehicle entered the 287 subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined 288 in [VIP-WAVE]. When it receives an RS message from a vehicle 289 containing its mobility information (e.g., position, speed, and 290 direction), an RSU sends its MA a Proxy Binding Update (PBU) message 291 [RFC5213][RFC3775], which contains a Mobility Option for the 292 vehicle's mobility information. The MA receives the PBU and sets up 293 a Binding Cache Entry (BCE) as well as a bi-directional tunnel 294 (denoted as Bi-Dir Tunnel in Figure 2) between the serving RSU and 295 itself. Through this tunnel, all traffic packets to the vehicle are 296 encapsulated toward the RSU. Simultaneously, the MA sends back a 297 Proxy Binding Acknowledgment (PBA) message to the serving RSU. This 298 serving RSU receives the PBA and sets up a bi-directional tunnel with 299 the MA. After this binding update, the RSU sends back an RA message 300 to the vehicle, which includes the RSU's prefix for the address 301 autoconfiguration of the vehicle. 303 When the vehicle receives the RA message, it performs the address 304 registration procedure including a multihop DAD for its global IP 305 address based on the prefix announced by the RA message according to 306 the VND [I-D.IPWAVE-VND]. 308 In PMIPv6, a unique prefix is allocated to each vehicle by an MA 309 (i.e., LMA) to guarantee the uniqueness of each address, but in this 310 document, a unique IP address is allocated to each vehicle with the 311 same prefix by an MA in its domain through the multihop-DAD-based 312 address registration. This unique IP address allocation ensures that 313 vehicles own unique IP addresses in a multi-link subnet and can 314 reduce the waste of IP prefixes in legacy PMIPv6. 316 5.2. Handoff within One Prefix Domain 318 When the vehicle changes its location and its current RSU (denoted as 319 c-RSU) detects that the vehicle is moving out of its coverage, c-RSU 320 needs to report the leaving of the vehicle to the MA and de-register 321 the binding via PBU. 323 Vehicle c-RSU MA n-RSU 324 | | | | 325 | |===Bi-Dir Tunnel==| | 326 | | | | 327 | | | | 328 | |----DeReg PBU---->| | 329 | | | | 330 | | | | 331 | |<-------PBA-------| | 332 | | | | 333 | | | | 334 | | | | 335 | | | | 336 | | | | 337 |(------------------RS with Mobility Info-------------->)| 338 | [VMI] | | 339 | |<-------PBU-------| 340 | | | 341 | | | 342 | |--------PBA------>| 343 | | | 344 | | | 345 | |===Bi-Dir Tunnel==| 346 | | | 347 | | | 348 |<--------------------RA with prefix---------------------| 349 | | 351 Figure 3: Handoff of a Vehicle within One Prefix Domain with PMIPv6 353 With this report, the MA can figure out the new RSU (denoted as 354 n-RSU) based on the vehicle's trajectory and change the end-point of 355 the tunnel into n-RSU's IP address for the vehicle or get ready to 356 detect new binding requests. 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 n-RSU, it changes the 361 tunnel's end-point from the c-RSU to n-RSU. If there are ongoing IP 362 packets toward the vehicle, the MA encapsulates the packets and then 363 forwards them towards n-RSU. Through this network-based mobility 364 management, the vehicle is not aware of any changes at its network 365 layer and can maintain its transport-layer sessions without any 366 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 the bidirectional tunnel directly between 391 them (cancel the intervention of MA) to alleviate the traffic flow in 392 MA 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 the 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 with 406 its current prefix. If the vehicle sends an RS message to n-RSU, 407 n-RSU responds to the RS 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 c-RSU belonging to Subnet1, and moves into the n-RSU 445 belonging to Subnet2, c-RSU detects the vehicle's leaving and reports 446 to MA1. MA1 figures out that the vehicle will get into the coverage 447 of the n-RSU based on its trajectory and sends MA2 a PBU message to 448 inform MA2 that the vehicle will enter the coverage of n-RSU 449 belonging to MA2. MA2 sends n-RSU a PBA message to inform n-RSU that 450 the vehicle will enter the coverage of n-RSU along with handoff 451 context such as c-RSU's context information (e.g., c-RSU's link-local 452 address and prefix called prefix1), and the vehicle's context 453 information (e.g., the vehicle's global IP address and MAC address). 454 After n-RSU receives the PBA message including the handoff context 455 from MA2, it sets up a bi-directional tunnel with MA2, and generates 456 RA messages with c-RSU's context information. That is, n-RSU 457 pretends to be a router belonging to Subnet1. When the vehicle 458 receives RA from n-RSU, it can maintain its connection with its 459 corresponding node (i.e., CN1). Note that n-RSU also sends RA 460 messages with its domain prefix called prefix2. The vehicle 461 configures another global IP address with prefix2, and can use it for 462 communication with neighboring vehicles under the coverage of n-RSU. 464 If c-RSU and n-RSU are adjacent, that is, vehicles are moving in 465 specified routes with fixed RSU allocation, the procedure can be 466 simplified by constructing the bidirectional tunnel directly between 467 them (cancel the intervention of MAs) to alleviate the traffic flow 468 in MA as well as reduce handoff delay. 470 Vehicle c-RSU n-RSU 471 | | | 472 |---------------------| | 473 |c-RSU detects leaving| | 474 |---------------------| | 475 | |--------PBU------>| 476 | | | 477 | |===Bi-Dir Tunnel==| 478 | | | 479 | |<-------PBA-------| 480 | | | 481 | | | 482 |(--------RS with Mobility Info-------->)| 483 | [VMI] | 484 | | 485 |<--------RA with prefix1 (c-RSU)--------| 486 | | 487 |<--------RA with prefix2 (n-RSU)--------| 488 | | 490 Figure 6: Handoff of a Vehicle within Multiple Prefix Domains with 491 DMM 493 Figure 6 shows the handoff of a vehicle within two prefix domains (as 494 two multi-link subnets) with DMM [I-D.DMM-PMIPv6]. If c-RSU detects 495 that the vehicle is going to leave its coverage and to enter the area 496 of an adjacent RSU (n-RSU) belonging to a different prefix domain, it 497 sends a PBU message to inform n-RSU that the vehicle will enter the 498 coverage of n-RSU along with handoff context such as c-RSU's context 499 information (e.g., c-RSU's link-local address and prefix called 500 prefix1), and the vehicle's context information (e.g., the vehicle's 501 global IP address and MAC address). After n-RSU receives the PBA 502 message including the handoff context from c-RSU, it sets up a bi- 503 directional tunnel with c-RSU, and generates RA messages with c-RSU's 504 context information. That is, n-RSU pretends to be a router 505 belonging to Subnet1. When the vehicle receives RA from n-RSU, it 506 can maintain its connection with its corresponding node (i.e., CN1). 507 Note that n-RSU also sends RA messages with its domain prefix called 508 prefix2. The vehicle configures another global IP address with 509 prefix2, and can use it for communication with neighboring vehicles 510 under the coverage of n-RSU. 512 6. Security Considerations 514 This document shares all the security issues of Vehicular ND 515 [I-D.IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM 516 [RFC7333][RFC7429][I-D.DMM-PMIPv6]. 518 7. References 520 7.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 526 in IPv6", RFC 3775, June 2004. 528 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 529 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 530 September 2007. 532 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 533 Address Autoconfiguration", RFC 4862, September 2007. 535 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., and K. 536 Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008. 538 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 539 "Requirements for Distributed Mobility Management", 540 RFC 7333, August 2014. 542 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 543 Bernardos, "Distributed Mobility Management: Current 544 Practices and Gap Analysis", RFC 7429, January 2015. 546 7.2. Informative References 548 [I-D.DMM-PMIPv6] 549 Bernardos, CJ., Oliva, A., Giust, F., Zuniga, JC., and A. 550 Mourad, "Proxy Mobile IPv6 extensions for Distributed 551 Mobility Management", draft-ietf-dmm-pmipv6-dlif-04 (work 552 in progress), January 2019. 554 [I-D.IPWAVE-PS] 555 Jeong, J., Ed., "IP Wireless Access in Vehicular 556 Environments (IPWAVE): Problem Statement and Use Cases", 557 draft-ietf-ipwave-vehicular-networking-09 (work in 558 progress), May 2019. 560 [I-D.IPWAVE-VND] 561 Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular 562 Neighbor Discovery for IP-Based Vehicular Networks", 563 draft-jeong-ipwave-vehicular-neighbor-discovery-07 (work 564 in progress), July 2019. 566 [IEEE-802.11-OCB] 567 "Part 11: Wireless LAN Medium Access Control (MAC) and 568 Physical Layer (PHY) Specifications", IEEE Std 569 802.11-2016, December 2016. 571 [TS-23.285-3GPP] 572 3GPP, "Architecture Enhancements for V2X Services", 3GPP 573 TS 23.285, June 2018. 575 [VIP-WAVE] 576 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 577 Feasibility of IP Communications in 802.11p Vehicular 578 Networks", IEEE Transactions on Intelligent Transportation 579 Systems, vol. 14, no. 1, March 2013. 581 [WAVE-1609.0] 582 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 583 in Vehicular Environments (WAVE) - Architecture", IEEE Std 584 1609.0-2013, March 2014. 586 Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility- 587 management-00 589 The following changes are made from draft-jeong-ipwave-vehicular- 590 mobility-management-00: 592 o In Section 4.1, the description of the vehicular network 593 architecture is clarified. 595 o In Section 5.2, the description on the handoff procedure within 596 one prefix domain is clarified. 598 o In Section 5.3, the decription on the the handoff procedure within 599 multiple prefix domains is clarified. 601 o Some typo errors are corrected and the repeated acronyms are 602 removed. 604 Appendix B. Acknowledgments 606 This work was supported by Basic Science Research Program through the 607 National Research Foundation of Korea (NRF) funded by the Ministry of 608 Education (2017R1D1A1B03035885). 610 This work was supported by the MSIT (Ministry of Science and ICT), 611 Korea, under the ITRC (Information Technology Research Center) 612 support program (IITP-2019-2017-0-01633) supervised by the IITP 613 (Institute for Information & communications Technology Promotion). 615 Authors' Addresses 617 Jaehoon Paul Jeong 618 Department of Computer Science and Engineering 619 Sungkyunkwan University 620 2066 Seobu-Ro, Jangan-Gu 621 Suwon, Gyeonggi-Do 16419 622 Republic of Korea 624 Phone: +82 31 299 4957 625 Fax: +82 31 290 7996 626 EMail: pauljeong@skku.edu 627 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 628 Yiwen Chris Shen 629 Department of Electrical and Computer Engineering 630 Sungkyunkwan University 631 2066 Seobu-Ro, Jangan-Gu 632 Suwon, Gyeonggi-Do 16419 633 Republic of Korea 635 Phone: +82 31 299 4106 636 Fax: +82 31 290 7996 637 EMail: chrisshen@skku.edu 639 Zhong Xiang 640 Department of Electrical and Computer Engineering 641 Sungkyunkwan University 642 2066 Seobu-Ro, Jangan-Gu 643 Suwon, Gyeonggi-Do 16419 644 Republic of Korea 646 Phone: +82 10 9895 1211 647 Fax: +82 31 290 7996 648 EMail: xz618@skku.edu