Skip to main content

Vehicular Mobility Management for IP-Based Vehicular Networks
draft-jeong-ipwave-vehicular-mobility-management-09

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Jaehoon Paul Jeong , Bien Aime Mugabarigira , Yiwen Shen , Hyeonah Jung
Last updated 2023-02-04
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jeong-ipwave-vehicular-mobility-management-09
IPWAVE Working Group                                       J. Jeong, Ed.
Internet-Draft                                           B. Mugabarigira
Intended status: Standards Track                                 Y. Shen
Expires: 8 August 2023                                           H. Jung
                                                 Sungkyunkwan University
                                                         4 February 2023

     Vehicular Mobility Management for IP-Based Vehicular Networks
          draft-jeong-ipwave-vehicular-mobility-management-09

Abstract

   This document specifies a Vehicular Mobility Management (VMM) scheme
   for IP-based vehicular networks.  The VMM scheme takes advantage of a
   vehicular link model based on a multi-link subnet.  With a vehicle's
   mobility information (e.g., position, speed, acceleration/
   deceleration, and direction) and navigation path (i.e., trajectory),
   it can provide a moving vehicle with proactive and seamless handoff
   along with its trajectory.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 August 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Jeong, et al.             Expires 8 August 2023                 [Page 1]
Internet-Draft        Vehicular Mobility Management        February 2023

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Vehicular Network Architecture  . . . . . . . . . . . . . . .   4
     4.1.  Vehicular Network . . . . . . . . . . . . . . . . . . . .   4
   5.  Mobility Management . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Network Attachment of a Vehicle . . . . . . . . . . . . .   6
     5.2.  Handoff within One Prefix Domain  . . . . . . . . . . . .   8
     5.3.  Handoff between Multiple Prefix Domains . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  14
   Appendix B.  Contributors . . . . . . . . . . . . . . . . . . . .  14
   Appendix C.  Changes from
           draft-jeong-ipwave-vehicular-mobility-management-08 . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document proposes a mobility management scheme for IP-based
   vehicular networks, called Vehicular Mobility Management (VMM).  The
   VMM is tailored for a vehicular network architecture and a vehicular
   link model described in the IPWAVE problem statement document
   [ID-IPWAVE-PS].

   Vehicle Neighbor Discovery (VND) is proposed as Extended IPv6
   Neighbor Discovery (ND) for IP-based vehicle networks [ID-IPWAVE-VND]
   to support the vehicle-to-vehicle or the vehicle to Road-Side Unit
   (RSU) interactions.  For an efficient IPv6 Stateless Address
   Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized Address
   Registration using a multihop Duplicate Address Detection (DAD).
   This multihop DAD enables a vehicle to have a unique IP address in a
   multi-link subnet consisting of multiple wireless subnets with the
   same IP prefix, which corresponds to wireless coverage of multiple
   RSUs.  VND also supports IP packet routing over a connected Vehicular
   Ad Hoc Network (VANET) by allowing vehicles to exchange the prefixes
   of their internal networks through their external wireless interface.

Jeong, et al.             Expires 8 August 2023                 [Page 2]
Internet-Draft        Vehicular Mobility Management        February 2023

   The mobility management in this multi-link subnet needs a new
   approach from the legacy mobility management schemes.  This document
   aims at an efficient mobility management scheme called VMM to support
   efficient V2V, V2I, and V2X communications in a road network.  The
   VMM takes advantage of the mobility information (e.g.,a vehicle's
   speed, direction, and position) and trajectory (i.e., navigation
   path) of each vehicle registered in the Traffic Control Center (TCC)
   of the vehicular cloud.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Terminology

   This document uses the terminology described in [RFC4861] and
   [RFC4862].  In addition, the following new terms are defined as
   below:

   *  DMM: Acronym for "Distributed Mobility Management"
      [RFC7333][RFC7429].

   *  Mobility Anchor (MA): A node that maintains the IP addresses and
      mobility information of vehicles in a road network to support
      their address autoconfiguration and mobility management with a
      binding table.  It has end-to-end connections with RSUs under its
      control.

   *  On-Board Unit (OBU): A node that with a network interface (e.g.,
      IEEE 802.11-OCB and Cellular V2X (C-V2X) [TS-23.285-3GPP]) for
      wireless communications with other OBUs and RSUs, and may be
      connected to in-vehicle's devices or networks.  An OBU is mounted
      on a vehicle.  It is assumed that a radio navigation receiver
      (e.g., Global Positioning System (GPS)) is included in a vehicle
      with an OBU for efficient navigation.

   *  OCB: Acronym for "Outside the Context of a Basic Service Set"
      [IEEE-802.11-OCB].

   *  Road-Side Unit (RSU): A node that has physical communication
      devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless
      communication with vehicles and is also connected to the Internet
      as a router or switch for packet forwarding.  An RSU is typically
      deployed on the road infrastructure, either at an intersection or
      in a road segment, but may also be located in cars parking areas.

Jeong, et al.             Expires 8 August 2023                 [Page 3]
Internet-Draft        Vehicular Mobility Management        February 2023

   *  Traffic Control Center (TCC): A node that maintains the road
      infrastructure information (e.g., RSUs, traffic signals, and loop
      detectors), vehicular traffic statistics (e.g., average vehicle
      speed and vehicle inter-arrival time per road segment), and
      vehicle information (e.g., a vehicle's identifier, position,
      direction, speed, and trajectory as a navigation path).  TCC is
      included in a vehicular cloud for vehicular networks.

   *  Vehicular Cloud: A cloud infrastructure for vehicular networks,
      having compute nodes, storage nodes, and network nodes.

   *  WAVE: Acronym for "Wireless Access in Vehicular Environments"
      [WAVE-1609.0].

4.  Vehicular Network Architecture

   This section describes a vehicular network architecture for V2V and
   V2I communication.  A vehicle and an RSU have their internal networks
   including in-vehicle devices or servers, respectively.

4.1.  Vehicular Network

   A vehicular network architecture for V2I and V2V is illustrated in
   Figure 1.  In this figure, there is a vehicular cloud containing a
   TCC.  The TCC has Mobility Anchors (MAs) responsible for the vehicles
   mobility management.  Each MA is in charge of the mobility management
   of vehicles under its prefix domain, which is a multi-link subnet of
   RSUs sharing the same prefix [ID-IPWAVE-PS].  A vehicular network is
   a wireless network consisting of RSUs and vehicles.  The RSUs are
   interconnected via a wired network, allowing vehicles to build VANETs
   via V2V and V2I communications.

Jeong, et al.             Expires 8 August 2023                 [Page 4]
Internet-Draft        Vehicular Mobility Management        February 2023

                      *-----------------------------------------*
                     *          TCC in Vehicular Cloud           *
                    *   +-------------------------------------+   *
  +--------+       *    |   +---------+         +---------+   |    *
  |  CN1   |<---->*     |   |   MA1   |<------->|   MA2   |   |     *
  +--------+      *     |   +---------+         +---------+   |     *
                   *    +-------------------------------------+    *
                    *           ^                    ^            *
                     *          |      INTERNET      |           *
                      *---------v--------------------v----------*
                       ^               ^                     ^
                       | Ethernet      |                     |
                       |               |                     |
                       v               v                     v
                  +--------+ Ethernet +--------+ Ethernet +--------+
                  |  RSU1  |<-------->|  RSU2  |<-------->|  RSU3  |
                  +--------+          +--------+          +--------+
                     ^                   ^                   ^
                     :                   :                   :
              +-----------------------------------+  +-----------------+
              |      : V2I           V2I :        |  |   V2I :         |
              |      v                   v        |  |       v         |
 +--------+   |   +--------+       +--------+     |  |  +--------+     |
 |Vehicle1|===>   |Vehicle2|===>   |Vehicle3|===> |  |  |Vehicle4|===> |
 |        |<.....>|        |<.....>|        |     |  |  |        |     |
 +--------+  V2V  +--------+  V2V  +--------+     |  |  +--------+     |
              |                                   |  |                 |
              +-----------------------------------+  +-----------------+
                             Subnet1                       Subnet2

       <----> Wired Link   <....> Wireless Link   ===> Moving Direction

 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking

   In Figure 1, three RSUs are deployed either at intersections or along
   roadways.  They are connected to an MA through wired networks.  The
   vehicular network has two subnets, such as Subnet1 and Subnet2.
   Subnet1 is a multi-link subnet consisting of multiple wireless
   coverage areas of multiple RSUs, which share the same IPv6 prefix to
   construct a single logical subnet [ID-IPWAVE-PS].  That is, the RSU1
   and RSU2 wireless links belong to Subnet1.  Thus, since Vehicle2 and
   Vehicle3 use the same prefix for Subnet1, and that are within the
   wireless communication range, they can communicate directly with each
   other.  Note that in a multi-link subnet, a vehicle (e.g., Vehicle2
   and Vehicle3 in Figure 1) can configure its global IPv6 address
   through an address registration procedure that includes the multihop
   DAD specified in VND [ID-IPWAVE-VND].

Jeong, et al.             Expires 8 August 2023                 [Page 5]
Internet-Draft        Vehicular Mobility Management        February 2023

   Subnet2 on the other hand, uses a different prefix than Subnet1.
   Vehicle4 residing in Subnet2 cannot communicate directly to Vehicle3
   because it belongs to a different subnet.  Vehicles can construct a
   connected VANET so they can communicate with each other without
   relaying on RSU, but on the forwarding over the VANET.  In the case
   where two vehicles belong to the same multi-link subnet, but they are
   not connected in the same VANET, they can use RSUs.  In Figure 1,
   even though Vehicle1 is disconnected from Vehicle3, they can
   communicate indirectly with each other through RSUs such as RSU1 and
   RSU2.

   This document specifies a mobility management scheme for the
   vehicular network architecture, as shown in Figure 1.  Vehicle2 is
   supposed to communicate with the corresponding node denoted as CN1,
   and Vehicle2 is moving in the wireless coverage of RSU1.  When
   Vehicle2 moves out of the coverage of RSU1 and moves into the
   coverage of RSU2 where RSU1 and RSU2 share the same prefix, packets
   sent by CN1 should be routed through RSU2 to Vehicle2.  Also, when
   Vehicle2 moves out of the coverage of RSU2 and moves into the
   coverage of RSU3 where RSU2 and RSU3 use two different prefixes, the
   CN1 packets should be delivered to Vehicle2 via RSU3.  A handoff
   procedure allows a sender's packets to be delivered to a destination
   vehicle which is moving within the wireless coverage areas.

5.  Mobility Management

   This section explains the detailed procedure of mobility management
   of a vehicle in a road network as shown in Figure 1.

5.1.  Network Attachment of a Vehicle

   A mobility management is required for the seamless communication of
   vehicles moving between the RSUs.  When a vehicle moves into the
   coverage of another RSU, a different IP address is assigned to the
   vehicle, the transport-layersession information (i.e., an end-point's
   IP address) is reconfigured to avoid service disruption.  Considering
   this issue, this document proposes a handoff mechanism for seamless
   communication.

   In [VIP-WAVE], the authors constructed a network-based mobility
   management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which
   is highly suitable for vehicular networks.  This document uses a
   mobility management procedure similar to PMIPv6, but uses a newly
   proposed Shared-Prefix model in which vehicles in the same subnet
   share the same prefix.

Jeong, et al.             Expires 8 August 2023                 [Page 6]
Internet-Draft        Vehicular Mobility Management        February 2023

             Vehicle                    RSU                MA
                |                        |                  |
                |-RS with Mobility Info->|                  |
                |         [VMI]          |                  |
                |                        |                  |
                |                        |--------PBU------>|
                |                        |                  |
                |                        |                  |
                |                        |<-------PBA-------|
                |                        |                  |
                |                        |                  |
                |                        |===Bi-Dir Tunnel==|
                |                        |                  |
                |                        |                  |
                |<----RA with prefix-----|                  |
                |                        |                  |

      Figure 2: Message Interaction for a Vehicle's Network Attachment

   Figure 2 shows the binding update flow when a vehicle entered the RSU
   subnet.  The RSUs act as Mobility Anchor Gateway (MAG) defined in
   [VIP-WAVE].  When it receives an RS message from a vehicle containing
   its mobility information (e.g., position, speed, and direction), an
   RSU sends a Proxy Binding Update (PBU) message to its MA
   [RFC5213][RFC3775].  This contains a Mobility Option including the
   vehicle's mobility information.  The MA receives the PBU and sets up
   a Binding Cache Entry (BCE) as well as a bi-directional tunnel
   (denoted as Bi-Dir Tunnel in Figure 2) between the serving RSU and
   itself.  Through this tunnel, all traffic packets to the vehicle are
   encapsulated toward the RSU.  Simultaneously, the MA sends back a
   Proxy Binding Acknowledgment (PBA) message to the serving RSU.  This
   serving RSU receives the PBA and sets up a bi-directional tunnel with
   the MA.  After this binding update, the RSU sends back an RA message
   to the vehicle.  This message includes the RSU's prefix for the
   address autoconfiguration of the vehicle.

   When the vehicle receives the RA message, it performs the address
   registration procedure including a multihop DAD for its global IP
   address based on the prefix announced by the RA message according to
   the VND [ID-IPWAVE-VND].

Jeong, et al.             Expires 8 August 2023                 [Page 7]
Internet-Draft        Vehicular Mobility Management        February 2023

   In PMIPv6, an MA (i.e., LMA) allocates a unique prefix to each
   vehicle to guarantee the uniqueness of each address, but in this
   document, an MA allocates in its domain a unique IP address to each
   vehicle with the same prefix through the multihop-DAD-based address
   registration.  This unique IP address allocation ensures that
   vehicles own unique IP addresses in a multi-link subnet and can
   reduce the waste of IP prefixes in legacy PMIPv6.

5.2.  Handoff within One Prefix Domain

   When the vehicle changes its location and its current RSU (denoted as
   c-RSU) detects that the vehicle is moving out of its coverage, the
   c-RSU reports the leaving of the vehicle to the MA and de-register
   the binding via PBU.

      Vehicle            c-RSU                MA               n-RSU
         |                  |                  |                  |
         |                  |===Bi-Dir Tunnel==|                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |----DeReg PBU---->|                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |<-------PBA-------|                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |(------------------RS with Mobility Info-------------->)|
         |                          [VMI]      |                  |
         |                                     |<-------PBU-------|
         |                                     |                  |
         |                                     |                  |
         |                                     |--------PBA------>|
         |                                     |                  |
         |                                     |                  |
         |                                     |===Bi-Dir Tunnel==|
         |                                     |                  |
         |                                     |                  |
         |<--------------------RA with prefix---------------------|
         |                                                        |

    Figure 3: Handoff of a Vehicle within One Prefix Domain with PMIPv6

Jeong, et al.             Expires 8 August 2023                 [Page 8]
Internet-Draft        Vehicular Mobility Management        February 2023

   With this report, the MA will send back a PBA to notice the de-
   register to c-RSU, and get ready to detect new binding requests.  If
   MA can figure out the new RSU (denoted as n-RSU) based on the
   vehicle's trajectory, it will directly change the end-point of the
   tunnel into n-RSU's IP address for the vehicle.

   Figure 3 shows the handoff of a vehicle within one prefix domain
   (i.e., a multi-link subnet) with PMIPv6.  As shown in the figure,
   when the MA receives a new PBU from the n-RSU, it changes the
   tunnel's end-point from the c-RSU to n-RSU.  If there are ongoing IP
   packets toward the vehicle, the MA encapsulates the packets and then
   forwards them towards n-RSU.  Through this network-based mobility
   management, the vehicle is not aware of any changes at its network
   layer and can maintain its transport-layer sessions without any
   disruption.

           Vehicle               c-RSU              n-RSU
              |                     |                  |
              |---------------------|                  |
              |c-RSU detects leaving|                  |
              |---------------------|                  |
              |                     |--------PBU------>|
              |                     |                  |
              |                     |===Bi-Dir Tunnel==|
              |                     |                  |
              |                     |<-------PBA-------|
              |                     |                  |
              |                     |                  |
              |(--------RS with Mobility Info-------->)|
              |                 [VMI]                  |
              |                                        |
              |<------------RA with prefix-------------|
              |                                        |

      Figure 4: Handoff of a Vehicle within One Prefix Domain with DMM

   If c-RSU and n-RSU are adjacent, that is, vehicles are moving in
   specified routes with fixed RSU allocation, the procedure can be
   simplified by constructing the bidirectional tunnel directly between
   them (cancel the intervention of MA) to alleviate the traffic flow in
   MA as well as reduce handoff delay.

   Figure 4 shows a vehicle handoff within one prefix domain (as a
   multi-link subnet) with DMM [RFC8885].  The RSUs are in charge of
   detecting when a node joins or moves to its domain.  If the c-RSU
   detects that the vehicle is going to leave its coverage and to enter
   the area of an adjacent RSU, it sends a PBU message to inform n-RSU
   of the vehicle's handoff.  If n-RSU receives the PBU message, it

Jeong, et al.             Expires 8 August 2023                 [Page 9]
Internet-Draft        Vehicular Mobility Management        February 2023

   constructs a bidirectional tunnel between c-RSU and itself, and then
   sends back a PBA message as an acknowledgment to c-RSU.  If there are
   ongoing IP packets toward the vehicle, c-RSU encapsulates the packets
   and then forwards them to n-RSU.  When n-RSU detects the entrance of
   the vehicle, it directly sends an RA message to the vehicle so that
   the vehicle can assure that it is still connected to a router with
   its current prefix.  If the vehicle sends an RS message to n-RSU,
   n-RSU responds to the RS message by replying to the vehicle with an
   RA .

5.3.  Handoff between Multiple Prefix Domains

   When a vehicle moves from a prefix domain to another prefix domain, a
   handoff between multiple prefix domains is required.  As shown in
   Figure 1, when Vehicle3 moves from the subnet of RSU2 (i.e., Subnet1)
   to the subnet of RSU3 (i.e., Subnet2), a multiple domain handoff is
   performed through the cooperation of RSU2, RSU3, MA1 and MA2.

  Vehicle     c-RSU               MA1              MA2             n-RSU
    |            |                 |                |                 |
    |            |==Bi-Dir Tunnel==|                |                 |
    |            |                 |                |                 |
    |            |                 |                |                 |
    |            |---DeReg PBU---->|                |                 |
    |            |                 |-------PBU----->|                 |
    |            |                 |                |                 |
    |            |<------PBA-------|                |-------PBA------>|
    |            |                 |                |                 |
    |            |                 |                |==Bi-Dir Tunnel==|
    |            |                 |                |                 |
    |            |                 |                |                 |
    |(----------------------RS with Mobility Info------------------->)|
    |            |                [VMI]             |                 |
    |            |                 |                |                 |
    |            |                 |                |                 |
    |<----------------------RA with prefix1 (c-RSU)-------------------|
    |            |                 |                |                 |
    |<----------------------RA with prefix2 (n-RSU)-------------------|
    |            |                 |                |                 |

      Figure 5: Handoff of a Vehicle between Multiple Prefix Domains
                               with PMIPv6

   Figure 5 shows the handoff of a vehicle between two prefix domains
   (i.e., two multi-link subnets) with PMIPv6.  When the vehicle moves
   out of its c-RSU belonging to Subnet1, and moves into the n-RSU
   belonging to Subnet2, c-RSU detects the vehicle's leaving and reports
   it to MA1.  MA1 figures out that the vehicle will get into the

Jeong, et al.             Expires 8 August 2023                [Page 10]
Internet-Draft        Vehicular Mobility Management        February 2023

   coverage of the n-RSU based on its trajectory and sends MA2 a PBU
   message to inform MA2 that the vehicle will enter the coverage of
   n-RSU belonging to MA2.  MA2 sends a PBA message to n-RSU to inform
   that the vehicle will enter the coverage of n-RSU along with handoff
   context such as c-RSU's context information (e.g., c-RSU's link-local
   address and prefix called prefix1), and the vehicle's context
   information (e.g., the vehicle's global IP address and MAC address).
   After n-RSU receives the PBA message including the handoff context
   from MA2, it sets up a bi-directional tunnel with MA2, and generates
   RA messages with c-RSU's context information.  That is, n-RSU
   pretends to be a router belonging to Subnet1.  When the vehicle
   receives RA from n-RSU, it can maintain its connection with its
   corresponding node (i.e., CN1).  Note that n-RSU also sends RA
   messages with its domain prefix called prefix2.  The vehicle
   configures another global IP address with prefix2, and can use it for
   communication with neighboring vehicles under the coverage of n-RSU.

   If c-RSU and n-RSU are adjacent, that is, vehicles are moving in
   specified routes with fixed RSU allocation, the procedure can be
   simplified by constructing the bidirectional tunnel directly between
   them (cancel the intervention of MAs) to alleviate the traffic flow
   in MA as well as reduce handoff delay.

           Vehicle               c-RSU              n-RSU
              |                     |                  |
              |---------------------|                  |
              |c-RSU detects leaving|                  |
              |---------------------|                  |
              |                     |--------PBU------>|
              |                     |                  |
              |                     |===Bi-Dir Tunnel==|
              |                     |                  |
              |                     |<-------PBA-------|
              |                     |                  |
              |                     |                  |
              |(--------RS with Mobility Info-------->)|
              |                 [VMI]                  |
              |                                        |
              |<--------RA with prefix1 (c-RSU)--------|
              |                                        |
              |<--------RA with prefix2 (n-RSU)--------|
              |                                        |

       Figure 6: Handoff of a Vehicle within Multiple Prefix Domains
                                  with DMM

Jeong, et al.             Expires 8 August 2023                [Page 11]
Internet-Draft        Vehicular Mobility Management        February 2023

   Figure 6 shows the vehicle handoff within two prefix domains (as two
   multi-link subnets) with DMM [RFC8885].  If c-RSU detects that the
   vehicle is going to leave its coverage and to enter the area of an
   adjacent RSU (n-RSU) belonging to a different prefix domain, it sends
   a PBU message to inform n-RSU that the vehicle will enter the
   coverage of n-RSU along with handoff context such as c-RSU's context
   information (e.g., c-RSU's link-local address and prefix called
   prefix1), and the vehicle's context information (e.g., the vehicle's
   global IP address and MAC address).  After n-RSU receives the PBA
   message including the handoff context from c-RSU, it sets up a bi-
   directional tunnel with c-RSU, and generates RA messages with c-RSU's
   context information.  That is, n-RSU pretends to be a router
   belonging to Subnet1.  When the vehicle receives RA from n-RSU, it
   can maintain its connection with its corresponding node (i.e., CN1).
   Note that n-RSU also sends RA messages with its domain prefix called
   prefix2.  The vehicle configures another global IP address with
   prefix2, and can use it for communication with neighboring vehicles
   under the coverage of n-RSU.

6.  Security Considerations

   This document shares all the security issues of Vehicular ND
   [ID-IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM
   [RFC7333][RFC7429][RFC8885].

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
              September 2007, <https://www.rfc-editor.org/rfc/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007,
              <https://www.rfc-editor.org/rfc/rfc4862>.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., and K.
              Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008,
              <https://www.rfc-editor.org/rfc/rfc5213>.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004,
              <https://www.rfc-editor.org/rfc/rfc3775>.

Jeong, et al.             Expires 8 August 2023                [Page 12]
Internet-Draft        Vehicular Mobility Management        February 2023

   [RFC7333]  Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management",
              RFC 7333, August 2014,
              <https://www.rfc-editor.org/rfc/rfc7333>.

   [RFC7429]  Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
              Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429, January 2015,
              <https://www.rfc-editor.org/rfc/rfc7429>.

   [RFC8885]  Bernardos, CJ., Oliva, A. de la., Giust, F., Zuniga, JC.,
              and A. Mourad, "Proxy Mobile IPv6 Extensions for
              Distributed Mobility Management", RFC 8885, October 2020,
              <https://www.rfc-editor.org/rfc/rfc8885>.

   [ID-IPWAVE-PS]
              Jeong, J., Ed., "IPv6 Wireless Access in Vehicular
              Environments (IPWAVE): Problem Statement and Use Cases",
              Work in Progress, Internet-Draft, draft-ietf-ipwave-
              vehicular-networking-30, October 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-
              vehicular-networking-30>.

7.2.  Informative References

   [ID-IPWAVE-VND]
              Jeong, J., Ed., Shen, Y., Kwon, J., and S. Cespedes,
              "Vehicular Neighbor Discovery for IP-Based Vehicular
              Networks", Work in Progress, Internet-Draft, draft-jeong-
              ipwave-vehicular-neighbor-discovery-15, February 2023,
              <https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-
              vehicular-neighbor-discovery-15>.

   [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
              Feasibility of IP Communications in 802.11p Vehicular
              Networks", IEEE Transactions on Intelligent Transportation
              Systems, vol. 14, no. 1, March 2013.

   [IEEE-802.11-OCB]
              "Part 11: Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) Specifications", IEEE Std
              802.11-2016, December 2016.

   [WAVE-1609.0]
              IEEE 1609 Working Group, "IEEE Guide for Wireless Access
              in Vehicular Environments (WAVE) - Architecture", IEEE Std
              1609.0-2013, March 2014.

Jeong, et al.             Expires 8 August 2023                [Page 13]
Internet-Draft        Vehicular Mobility Management        February 2023

   [TS-23.285-3GPP]
              3GPP, "Architecture Enhancements for V2X Services", 3GPP
              TS 23.285, June 2018.

Appendix A.  Acknowledgments

   This work was supported in part by Institute of Information &
   Communications Technology Planning & Evaluation (IITP) grant funded
   by the Korea Ministry of Science and ICT (MSIT) (2020-0-00395-003,
   Standard Development of Blockchain based Network Management
   Automation Technology).

   This work was supported in part by the MSIT under the ITRC
   (Information Technology Research Center) support program (IITP-
   2022-2017-0-01633) supervised by the IITP.

Appendix B.  Contributors

   This document is made by the group effort of IPWAVE working group.
   Many people actively contributed to this document, such as Carlos J.
   Bernardos and Russ Housley.  The authors sincerely appreciate their
   contributions.

   The following are co-authors of this document:

   Zhong Xiang - Department of Electrical and Computer Engineering,
   Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do
   16419, Republic of Korea.  EMail: xz618@skku.edu

Appendix C.  Changes from draft-jeong-ipwave-vehicular-mobility-
             management-08

   The following changes are made from draft-jeong-ipwave-vehicular-
   mobility-management-08

   *  This version updates the version number.

Authors' Addresses

   Jaehoon Paul Jeong (editor)
   Department of Computer Science and Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4957

Jeong, et al.             Expires 8 August 2023                [Page 14]
Internet-Draft        Vehicular Mobility Management        February 2023

   Email: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php

   Bien Aime Mugabarigira
   Department of Electrical and Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 10 5964 8794
   Email: bienaime@skku.edu

   Yiwen Chris Shen
   Department of Electrical and Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: chrisshen@skku.edu

   Hyeonah Jung
   Department of Computer Science and Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: hyeonah214@skku.edu

Jeong, et al.             Expires 8 August 2023                [Page 15]