| Internet-Draft | IPv6 over 5G V2X | April 2024 |
| Jeong, et al. | Expires 24 October 2024 | [Page] |
This document provides methods and settings for using IPv6 to communicate among IPv6 nodes within the communication range of one another over 5G V2X (i.e., the 5th Generation Vehicle-to-Everything) links. Support for these methods and settings require minimal changes to the existing IPv6 protocol stack. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 in more complex 5G scenarios are not covered in this specification and are a subject for future work.¶
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 24 October 2024.¶
Copyright (c) 2024 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 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.¶
This document provides a baseline for using IPv6 in the hosts communicating with each other by the 5th Generation New Radio (NR) Vehicle-to-Everything (5G NR V2X) links [TS23303] [TS23304] defined by the 3rd Generation Partnership Project (3GPP). The baseline defined in this document has the minimal changes to existing stacks. Moreover, the document identifies the limitations of such usage.¶
The 3GPP has published the long-term evolution V2X (LTE V2X) in its Release 14 to support V2X communications using the Uu and PC5 reference points for vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V), respectively. In the recent development, the 5G V2X has also been proposed to enhance the existing and future V2X use cases. Particularly, the 5G V2X improves the sidelink resource allocation and the handling of quality-of-service (QoS) in the current 5G networks, and beyond 5G networks, such as 6G networks. It also extends the communication modes for UE over PC5 from broadcast mode to groupcast and unicast mode [TS24587].¶
The motivation for this document is the service discovery that utilizes the specifications developed by 3GPP to enhance and broaden the connectivity in a vehicular environment. As the 5G Core (5GC) and 5G New Radio (5G-NR) with 5G User Equipment (UE) are being deployed world wide, they can be of great importance in creating a connected network for moving objects such as automobiles, motorcycles, drones etc.¶
However, for IPv6-based 5G V2X communications based on the 3GPP documents [TS23287] [TS24587] it is still not clear how the IPv6 addresses are well configured for multi-hop 5G V2X networks. Particularly, when the Stateless Address Autoconfiguration (SLAAC) process is used in IPv6-based 5G V2X communications, a vehicle as an IPv6 router, which assigns an IPv6 prefix to another vehicle in SLAAC, shall be selected or determined. For a scenario having ground moving vehicles, how to determine the IPv6 router for SLAAC is still not clear. In addition, the 3GPP 5G V2X specifications discourage the use of the Duplicate Address Detection (DAD) [RFC4862] [RFC7527] and Neighbor Discover (ND) messages [RFC4861], which arises the concern of unusable IPv6-based 5G V2X services in the future. On top of that, other issues such as multi-hop packet forwarding among non-IPv6 router vehicles and efficiency of mobility management may also occur [RFC9365].¶
Thus this document offers the basic support for IPv6-based 5G V2X communications to enable application services such as infotainment and cooperative driving safety through the driving context information sharing.¶
+------------+
| NG-RAN | Base Station
+------------+ (e.g., gNodeB)
^
:
: Uu
:
V
+------------+ PC5 +------------+ PC5 +------------+
| IP-VehUE A |<.......>| IP-VehUE B |<.......>| UE C |
+------------+ +------------+ +------------+
Car A ==> Car B ==> Pedestrian ==>
<....> Wireless Link ===> Moving Direction
This document uses the terminology described in [RFC8691]. In addition, the following terms are defined below:¶
IP-VehUE (Internet Protocol Vehicle User Equipment): It is a UE device mounted on a vehicle such as car, motorcycle, and scooter that operates based on 5G V2X services to transmit IPv6 data packets. It can connect to the vehicle's internal networks.¶
NG-RAN (Next Generation Radio Access Network) node: It is a base station node that provides user plane and control plane functions toward IP-VehUEs, and it also connects to 5GC networks. It can be a gNodeB (gNB) in 5G or an ng-eNobdB (ng-eNB) in E-UTRA per the 5G network definition [TS23501] [TS38300].¶
5G NR-PC5 RP (5G New Radio PC5 Reference Point): The 5G NR-PC5 RP is referred to as communication links among IP-VehUEs (i.e., V2V).¶
5G NR-Uu RP(5G New Radio Uu Reference Point): The 5G NR-Uu RP is referred to as communication links between an IP-VehUE and an NG-RAN node.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
+-------------------+
| UDP/TCP V2X App |
+-------------------+
|
+===================+
| IPv6 |
+===================+
|
+-----------------------+
|3GPP Underlying Layers |
| +--------------+ |
| | SDAP | |
| +--------------+ |
| | |
| +--------------+ |
| | PDCP | |
| +--------------+ |
| | |
| +--------------+ |
| | RLC | |
| +--------------+ |
| | |
| +--------------+ |
| | MAC | |
| +--------------+ |
| | |
| +--------------+ |
| | PHY | |
| +--------------+ |
+-----------------------+
A high-level system architecture for V2X communication over PC5 and Uu reference points is shown in Figure 1. A modified sidelink interface allows IP-VehUEs to communicate with each other by the PC5 RP. An IP-VehUE can connect with a stationary NG-RAN through Uu interface. Both communications among IP-VehUEs and between IP-VehUEs and NG-RAN mainly rely on the lower layers shown in Figure 2.¶
The 5G V2X communications support both IP and non-IP based message exchanges in unicast, broadcast, and groupcast modes per 3GPP documents [TS23287] [TS24587]. For the IPv6-based 5G V2X communications via PC5 RP, only IPv6 is used for the communications. In the unicast mode of IPv6-based 5G V2X by PC5 RP, an IP-VehUE uses either the IPv6 Stateless Address Autoconfiguration (SLAAC) process or the IPv6 link-local addresses to generate usable IP addresses [RFC4862].¶
When using SLAAC, an IP-VehUE uses an IPv6 prefix sent by another IP-VehUE acting as an IPv6 default router.¶
When using IPv6 link-local addresses, an IP-VehUE forms the link-local addresses locally without Duplicate Address Detection (DAD) [TS23287].¶
In the broadcast and groupcast modes of 5G V2X over PC5 RP, an IP-VehUE configures a link-local IPv6 address as the source IP address. The configuration of the link-local IPv6 address does not send Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages for DAD per the 3GPP document [TS23287].¶
The V2X standard based on the 5G NR air interface introduced advanced functionalities to support connected and automated driving. The default MTU for IP packets on 5G V2X links over both PC5 and Uu RPs is inherited from [RFC2464], which is 1500 octets. Also as defined in [RFC8200], the 5G V2X links must offer a minimum MTU of 1280 octets to the IP layer and IP packets on those links must follow other IPv6 recommendations, especially with regard to fragmentation.¶
As shown in Figure 2, the IP packets over 5G V2X links follow the general frame format according to the protocol stack defined by 3GPP.¶
The IPv6-based 5G V2X communications use link-local addresses for IP packets. IPv6 addresses are assigned enabling the establishment of communication in and out of the subnet. To avoid conflicts between link local address in wireless vehicle networks, the interface identifier used by each IP-VehUE is ensured to be unique through addressing. There are several types of IPv6 addresses [RFC4291][RFC4193] that may be assigned to a 5G V2X interface.¶
This section suggests the extension over 5G V2X links to enable SLAAC process for a multi-hop communication scenario.¶
+---------------------+
| Access and Mobility |
| Management Function |
+---------------------+
^
|
|
|
V
+------------+ +------------+ +------------+
| NG-RAN A |<--Xn-->| NG-RAN B |<--Xn-->| NG-RAN C |
+------------+ +------------+ +------------+
^ ^ ^
: : :
: Uu : Uu : Uu
: : :
V V V
+-----------------------------------------+ +------------------+
| | | |
| +------------+ PC5 +------------+ | PC5 | +------------+ |
| | IP-VehUE A |<.......>| IP-VehUE B |<.........>| UE C | |
| +------------+ +------------+ | | +------------+ |
| Car A ==> Car B ==> | | Pedestrian ==> |
+-----------------------------------------+ +------------------+
Subnet 1 Subnet 2
<----> Wired Link <....> Wireless Link ===> Moving Direction
To enable a reachability of moving nodes across different subnets, an address registration is defined [RFC4862]. Links among moving IP-VehUEs (i.e., electric scooter, unmanned aerial vehicles, and connected cars) through optimized address registration and a multi-hop DAD mechanism need to be conducted.¶
A dynamic IPv6 address given by the stateless address autoconfiguration is used for forwarding the packet domain and packet forwarding in a subnetwork. The hight mobility features in a 5G-NR vehicular network requires a persistent connection to ensure communication. In the highway scenario, vehicular ad hoc networks (VANET) where IP-VehUEs wirelessly interconnect, improve communication efficiency. The details of neighbor discovery are addressed in [I-D.jeong-ipwave-vehicular-neighbor-discovery] and the mobility management handling strategies are address in [I-D.jeong-ipwave-vehicular-mobility-management] as well.¶
For 5G V2V by PC5 in unicast mode, one vehicle UE (VehUE) needs to be an IPv6 router for IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. The 5G V2X specifications [TS23287][TS24587] do not specify which VehUE shall be the IPv6 router for SLAAC. Also, it does not specify how many IPv6 addresses/prefixes a VehUE will have in this case.¶
===> ===> ===> ===>
+--------+ SLAAC +--------+ SLAAC +--------+ Link-Local +--------+
| Car B |<........>| Car A |<........>| Car C |<..........>| Car D |
+--------+ +--------+ +--------+ +--------+
IPv6 Host IPv6 Router IPv6 Host IPv6 Host
<....> Wireless Link ===> Moving Direction
As shown in Figure 4, a VehUE (e.g., Car A) among VehUEs shall be acting as an IPv6 router using SLAAC to assign IPv6 addresses/prefixes for other VehUEs. In this case, there are several issues to solve for IPv6 ND over 5G V2X as follows:¶
Which VehUE shall be the IPv6 router for the role to assign IPv6 addresses/prefixes if multiple VehUEs can be or want to be an IPv6 router?¶
For a VehUE acting as an IPv6 router, how many IPv6 addresses/prefixes will it assign? How much Will the role of an IPv6 router burden the IPv6 router VehUE?¶
For a VehUE receiving IPv6 addresses/prefixes from an IPv6 router VehUE, how many IPv6 addresses/prefixes will it have on the movement?¶
If a VehUE (e.g., Car D in Figure 4) does not have any connection with an IPv6 router VehUE, it will only use an IPv6 link local address for communications. In this case, multihop routing is triggered to forward IPv6 packets. How will this scenario affect the IPv6 networking among VehUEs?¶
For V2V and V2I communications among VehUEs and gNodeB, the 5G specifications [TS23287][TS24587] do not mention that VehUEs will use the same IPv6 configuration. It is necessary to consider whether the VehUEs will use the same prefix or the different prefixes for both V2V and V2I communications.¶
For multihop V2V and V2I among VehUEs and gNodeB, existing routing protocols are costly to maintain a routing table. The 5G specifications [TS23287][TS24587] do not consider how to minimize control traffic overhead for both routing and IPv6 Neighbor Discovery (ND) [RFC4861].¶
The network structure stated in Figure 3 follows the specifications defined in [I-D.jeong-ipwave-vehicular-neighbor-discovery]. Among the three NG-RAN deployed, two are deployed in same the subnet 1 and NG-RAN C is in a different subnet 2. An IP-VehUE establishes a connection in the coverage of an NG-RAN, and to enable a handover between two NG-RANs, a multi-link subnet is involved. The internetworking within subnetworks is done through IP router (i.e., NG-RAN).¶
IP-VehUE addresses with IPV6 prefixes belonging to the same subnetwork are specified using SLAAC.¶
The security considerations in this document inherit those in [RFC8691][RFC9365].¶
This document does not require any IANA actions.¶
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)(No. 2022-0-01015, Development of Candidate Element Technology for Intelligent 6G Mobile Core Network).¶
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) (No. 2022-0-01199, Regional strategic industry convergence security core talent training business).¶
This document is a group work, greatly benefiting from inputs and texts by Erik Kline (Aalyria) and Eric Vyncke (Cisco). The authors sincerely appreciate their contributions.¶
The following are coauthors of this document:¶
The following changes are made from draft-jeong-6man-ipv6-over-5g-v2x-02:¶
There are updates in the References.¶