SRH Reduction for SRv6 End.M.GTP6.E Behavior

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 5 May 2027.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

Segment Routing over IPv6 for the Mobile User Plane [RFC9433] defines interworking between SRv6 [RFC8986] networks and GTP-U [TS.29281] networks including required behaviors such as End.M.GTP6.E. This End.M.GTP6.E behavior converts SRv6 packets to GTP-U packets for downlink (DL) traffic at an egress MUP-PE [I-D.ietf-dmm-mup-architecture] when a gNB [TS.23501] uses IPv6/GTP-U.¶

In the End.M.GTP6.E behavior, an ingress MUP-PE requires two SIDs in an SRH with the remote endpoint information (IP address and TEID) in separate locations within the SRH and an egress MUP-PE also needs to fetch the last SID next to the active SID before outer IPv6 and SRH decapsulation to restore the IPv6/GTP-U header from those SIDs, in which current hardware pipelines may be unfamiliar or insufficient to implement.¶

This document specifies a new behavior named End.M.GTP6.E.Red which makes End.M.GTP6.E behavior more hardware-friendly by encoding the required information in a single SID. This behavior uses an Interwork Segment Discovery (ISD) Route and Type 1 Session Transformed (ST) Route of MUP SAFI [I-D.ietf-bess-mup-safi], specified in [I-D.ietf-dmm-mup-architecture] to reconstruct the gNB IPv6 address from the End.M.GTP6.E.Red SID and a locally maintained mapping.¶

2. Conventions and Definitions

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.¶

3. End.M.GTP6.E.Red Behavior

End.M.GTP6.E.Red (Endpoint Behavior with encapsulation for IPv6/GTP-U tunnel with reduced SRH) is used in the interworking scenarios described in [RFC9433] for the downlink toward a legacy gNB using IPv6/GTP-U.¶

Figure 1 depicts a topology used for the example. This topology is the same as Figure 4 described in Section 5.3 of [RFC9433] but terminology has been adapted from [I-D.ietf-dmm-mup-architecture].¶

              Interwork Segment             Direct Segment _______
                 IP GTP-U          SRv6                   /       \
+--+      +-----+ [N3] +--------+        +--------+ [N6] /         \
|UE|------| gNB |------| MUP-PE |--------| MUP-PE |------\   DN    /
+--+      +-----+      +--------+        +--------+       \_______/
                     Egress PE for DL   Ingress PE for DL

In this topology, the following addressing parameters are assumed:¶

• The prefix length of the Interwork Segment, that is, actual RAN IP Prefix is 'a'.¶

• The length of the LOC+FUNC field of the SID for End.M.GTP6.E.Red behavior on the Egress PE is 'b'.¶

Figure 2 shows the relationship between RAN IP Prefix, gNB address and End.M.GTP6.E.Red SID.¶

0
|
| NLRI in ISD Route                    40+b
+----------------------------------------+
|   advertised RAN IP Prefix             |
+----------------------------------------+
|   actual RAN IP Prefix   | stuff field |
+--------------------------+-------------+
|          a bits          | b+40-a bits |
:                          :             :
: gNB address              :             :                128
+--------------------------+-------------+-----------------+
|                       IPv6 address                       |
+--------------------------+-------------+-----------------+
:                                       /:                 :
:                         -------------- :                 :
: End.M.GTP6.E.Red SID   /               :                 :
+-----------------------+----------------+-----------------+
|  SRGW-IPv6-LOC-FUNC   |Args.Mob.Session| remainder bits  |
+-----------------------+----------------+-----------------+
|        b bits         |     40 bits    |   128-40-b bits |

In one deployment scenario, the length of actual RAN IP Prefix can be 64 bits (a=64) or shorter (a<64) and the length of SRGW-IPv6-LOC-FUNC can be 48 bits (b=48) in both cases of full SID and uSID. These are given by the addressing design of the RAN and the SRv6 domain. In this case, the stuff field is 24 bits (or more) and then, the prefix length of advertised RAN IP Prefix (the NLRI in the ISD Route) is 88 bits.¶

   S01. When an SRH is processed {
   S02.   If (Segments Left != 0) {
   S03.      Send an ICMP Parameter Problem to the Source Address with
                 Code 0 (Erroneous header field encountered) and
                 Pointer set to the Segments Left field,
                 interrupt packet processing, and discard the packet.
   S04.   }
   S05.   Proceed to process the next header in the packet
   S06. }

   S01.    Store the IPv6 DA and SA in buffer memory
   S02.    Pop the IPv6 header and all its extension headers
   S03.    Push a new IPv6 header with a UDP/GTP-U header
   S04.    Set the outer IPv6 SA to S
   S05.    Set the outer IPv6 DA (from buffer memory and mapping)
   S06.    Set the outer Payload Length, Traffic Class, Flow Label,
              Hop Limit, and Next Header fields
   S07.    Set the GTP-U TEID (from buffer memory)
   S08.    Submit the packet to the egress IPv6 FIB lookup for
              transmission to the new destination

4. Security Considerations

The security considerations for Segment Routing and SRv6 described in [RFC8402] and [RFC8754] apply to the behavior specified in this document.¶

The End.M.GTP6.E.Red behavior reconstructs the destination IPv6 address of a GTP-U tunnel using information encoded in the received SRv6 SID and a locally maintained mapping between SID prefixes and advertised RAN IP Prefixes. The GTP-U TEID is extracted from the Args.Mob.Session field of the received SID.¶

An attacker capable of injecting packets containing unauthorized End.M.GTP6.E.Red SIDs into the SR domain could potentially cause packets to be forwarded to unintended GTP-U endpoints or tunnels. Therefore, access to End.M.GTP6.E.Red SIDs needs to be restricted to authorized traffic within the SR domain, consistent with the security mechanisms described in [RFC8754].¶

The correctness of the destination address reconstruction depends on the integrity of the control-plane information used to establish the SID-to-RAN-prefix mappings. Unauthorized modification of this information could cause packets to be forwarded to incorrect destinations. Deployments need to protect the distribution and installation of these mappings using the security mechanisms applicable to the underlying control-plane protocols.¶

5. IANA Considerations

The following values have been allocated in the "SRv6 Endpoint Behaviors" [RFC8986] subregistry within the top-level "Segment Routing Parameters" registry:¶

IANA is requested to update the Reference field for this allocation to refer to this document upon its publication as an RFC.¶

6. References

Authors' Addresses