Export of GTP-U Information in IP Flow Information Export (IPFIX)

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

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

A dedicated header, called GPRS Tunneling Protocol (GTP) Header, is defined by 3GPP for the GTP User Plane (GTP-U) [TS.29281] traffic of mobile subscribers.¶

This document specifies eight IPFIX Information Elements (IEs) [RFC7012] to export GTP-U information.¶

Specifically, these IEs are used to export the GTP-U Tunnel Endpoint Identifier (TEID), QoS Flow Identifier (QFI), and PDU Type from the PDU Session Container extension header.¶

Some examples are provided in Appendix A.¶

2. Terminology

This document makes use of the terms defined in [RFC7011]¶

• IPFIX¶

• IPFIX Information Element¶

• Template¶

• Template Record¶

• Options Template¶

• Options Template Record¶

• Data Record¶

• Data Set¶

This document uses the term "User Plane" as used by 3GPP GTP-U in [TS.29281].¶

The document uses the following abbreviations:¶

• IE: Information Element¶

• GTP: GPRS Tunneling Protocol¶

• GTP-U: GTP User Plane¶

• GTP-C: GTP Control Plane¶

• PDU: Protocol Data Unit¶

• TEID: Tunnel Endpoint Identifier¶

• UPF: User Plane Function¶

• QFI: QoS Flow Identifier¶

3. IPFIX GTP-U Information Elements

This section defines IPFIX IEs corresponding to various fields in the GTP-U header. When the corresponding field is not present in the observed packet, or when 3GPP specifications state that the field shall not be interpreted, an Exporting Process SHOULD use a Template that omits the corresponding IE. If operational constraints require use of a fixed Template, the Exporting Process MUST export a value of zero for that IE, and the Collecting Process MUST treat that value in this context as "field not available". Reserved bits in exported gtpuQFI and gtpuPduType values MUST be set to zero by the Exporting Process and MUST be ignored by the Collecting Process.¶

gtpuFlags

8-bit flags field indicating the version of GTP-U header, protocol type, and presence of extension header, sequence number and N-PDU number defined in Section 5.1 of the 3GPP specification [TS.29281]. The bits are exported as observed.¶

gtpuMsgType

8-bit field which indicates the type of the GTP-U message as mentioned in section 6.1 of 3GPP specification [TS.29281].¶

gtpuTEid

32-bit tunnel endpoint identifier field unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP/IP endpoint.¶

gtpuSequenceNum

16-bit sequence number field defined in the GTP-U. This field is interpreted based on the sequence number flag value from gtpuFlags.¶

gtpuQFI

6-bit QoS flow identifier field defined in PDU Session Container extension header of GTP-U. This may be used to determine the QoS flow and QoS profile which are associated with the received packet. The presence of this extension header is interpreted based on the extension header flag value from gtpuFlags.¶

gtpuPduType

4-bit PDU type field defined in PDU Session Container extension header of GTP-U. This field indicates the structure of the PDU session user plane frame. The presence of this extension header is interpreted based on the extension header flag value from gtpuFlags.¶

gtpuTotalHdrLength

8-bit field indicating the total length of the GTP-U header which includes mandatory fields and all the optional headers as defined in Sections 5.1 and 5.2 of the 3GPP specification [TS.29281]. This IE is derived from the observed packet header and does not export the GTP-U Length field defined in Section 5.1 of [TS.29281].¶

gtpuHeaderSection

This Information Element carries a series of n octets from the GTP-U header mandatory fields and all the following optional headers if any, defined in Section 5 of the 3GPP specification [TS.29281] as a series of octets in IPFIX.¶

4. Sample Use Cases

The GTP-U related IPFIX IEs are helpful in order to identify the transport performance of PDU Sessions, e.g., with specific QoS class within a network slice (refer to [RFC9889]) or within a group of network slices hosted on the same User Plane Function (UPF).¶

For example, when a set of UPFs are deployed per 5G slice, the slice is identified first using a list of gNodeB IP addresses composing the slice and a list of IP addresses of UPFs dedicated for the slice. The gNodeB and the UPF form the tunnel endpoints. The traffic for each individual PDU Session per direction is identified using the GTP-U TEID, GTP-U PDU Type together with the above mentioned IP tunnel endpoints. Furthermore, the traffic for a specific QoS class within a PDU Session per traffic direction is identified using the combination of GTP-U TEID, GTP-U PDU Type, and GTP-U QFI attributes. It is possible that for a single PDU session there might be multiple IP flows with different GTP-U QFI but with same GTP-U TEID.¶

In another scenario when multiple 5G slices share the same UPF, each slice is identified using a separated list of gNodeB IPv4 or IPv6 addresses per slice. If an Uplink Classifier (refer to section 3.1 of [TS.23501]) is deployed there is an addition of a GTP-U tunnel between the Intermediate/Uplink-Classifier UPF and the final UPF. This brings a challenge for identifying the end-to-end path for a certain PDU Session - the GTP-U PDU Type and GTP-U QFI attributes from the gNodeB and Intermediate/Uplink-Classifier UPF tunnel will be the same on the Intermediate/Uplink-Classifier and final UPF tunnels, however the GTP-U TEIDs will be different since on each tunnel.¶

The use of the IPFIX GTP-U IEs is to identify either a particular PDU Session on a particular slice (using GTP-U TEID in combination with the gNodeB and the UPF IP addresses) or all the IP traffic flows for a 3GPP QoS flow on a slice (using GTP-U QFI in combination with the gNodeB and the UPF IP addresses) or a 3GPP QoS flow for a particular PDU Session on a slice (using both GTP-U TEID and GTP-U QFI in combination with the gNodeB and UPF IP addresses).¶

Additionally, exporting GTP-U IEs together with the transportChecksum IE 503 registered in the IANA IPFIX registry [IANA-IPFIX] can help detect misbehaving nodes, particularly when using GTP-U over IPv6.¶

5. IANA Considerations

IANA has registered the following IEs in the "IPFIX Information Elements" registry available at [IANA-IPFIX].¶

Table 1 lists the GTP-U IEs:¶

     +-------+-------------------+
     |Element| Name              |
     |       |                   |
     |   ID  |                   |
     |       |                   |
     +-------+-------------------+
     | 505   | gtpuFlags         |
     |       |                   |
     +-------+-------------------+
     | 506   | gtpuMsgType       |
     |       |                   |
     +-------+-------------------+
     | 507   | gtpuTEid          |
     |       |                   |
     +-------+-------------------+
     | 508   | gtpuSequenceNum   |
     |       |                   |
     +-------+-------------------+
     | 509   | gtpuQFI           |
     |       |                   |
     +-------+-------------------+
     | 510   | gtpuPduType       |
     |       |                   |
     +-------+-------------------+
     | TBD1  | gtpuTotalHdrLength|
     |       |                   |
     +-------+-------------------+
     | TBD2  | gtpuHeaderSection |
     |       |                   |
     +-------+-------------------+

  Table 1: GTP-U IEs in the "IPFIX Information Elements" Registry

IANA is requested to update the references for the existing GTP-U Information Elements listed in Table 1 to point to this RFC. IANA is also requested to allocate two new Information Element IDs for gtpuTotalHdrLength and gtpuHeaderSection in the "IPFIX Information Elements" registry.¶

6. Acknowledgements

The authors would like to thank Benoit Claise, Ketan Talaulikar, Dhananjay Patki, Paul Aitken, Shraddha Hegde, Chongfeng Liu, and Mahesh Jethanandani for their reviews and valuable comments.¶

7. Contributors

8. Implementation Status

Note to the RFC-Editor: Please remove this section before publishing.¶

9. Security Considerations

The IEs described in this document export GTP user plane information on how packets are being forwarded in a 3GPP network. In particular, TEIDs, QFIs, PDU types, and raw header sections can enable correlation of traffic with individual PDU sessions and, depending on deployment, with subscriber activity. Implementations and operators therefore SHOULD treat this data as sensitive network telemetry.¶

Applications and operators using the IEs described in this document must evaluate the sensitivity of this information in their implementation context, and apply the data-at-rest storage guidance in Section 11.8 of [RFC7011] as appropriate.¶

Operators SHOULD restrict access to these exported IEs, apply retention limits appropriate to sensitive operational telemetry, and avoid exporting gtpuHeaderSection unless required by the operational use case.¶

10. Operational Considerations

The IPFIX IEs defined in this document require extraction of fields from packets. There may exist older devices in the network that do not support extensions defined in this document. For those devices [RFC7133] defines dataLinkFrameSection which is a useful mechanism to export the packet header as a fallback scenario. However, when dataLinkFrameSection is used, Flow aggregation as per [RFC7015] can't be applied. This document will serve as a guideline to extract the necessary fields from the GTP-U header for the above scenarios.¶

Appendix A. IPFIX Encoding Examples

In this section, an example is provided to show IPFIX encoding format for the GTP-U introduced IEs. Template definition and data set corresponding to an observed GTP-U header is illustrated below.¶

          Observed GTP-U Header:
          Flags = 0x34, Message Type = 0xff, GTP-U Length = 0x0064,
          TEID = 0x00000001, Sequence Number = 0x0000,
          N-PDU Number = 0x00,
          Next Extension Header Type = 0x85 (PDU Session Container),
          PDU Session Container bytes = 0x01 0x10 0x08 0x00,
          PDU Type = 1, QFI = 8, gtpuTotalHdrLength = 16

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SET ID = 2           |       Length = 40             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 256        |      Field Count = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuFlags = 505            |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuMsgType = 506          |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuSequenceNum = 508      |      Field Length = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuTEid = 507             |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuQFI = 509              |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuPduType = 510          |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuTotalHdrLength = TBD1  |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuHeaderSection = TBD2   |      Field Length = 0xFFFF    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1: Sample Template Record

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SET ID = 256          |           Length = 32         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | gtpuFlags     |  gtpuMsgType  |   gtpuSequenceNum= 0x0000     |
   | = 0x36        |  = 0xff       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   gtpuTEid = 0x00000001                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | gtpuQFI = 8   | gtpuPduType   |  gtpuTotalHdr |  Length = 36  |
   |               | = 0           |  Length = 16  |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x34            0xff           0x00             0x64     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x00            0x00           0x00             0x01     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x05            0x01           0xd0             0x85     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x01            0x10           0x08             0x00     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x45            0x00           0x00             0x5c     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x03            0xec           0x00             0x00     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x40            0x01           0x7a             0x88     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0a            0xd4           0xe1             0x49     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x08            0x08           0x08             0x08     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 2: Data Set Encoding Format

   The gtpuHeaderSection octets in this example are:
   0x34 0xff 0x00 0x64 0x00 0x00 0x00 0x01
   0x05 0x01 0xd0 0x85 0x01 0x10 0x08 0x00
   0x45 0x00 0x00 0x5c 0x03 0xec 0x00 0x00
   0x40 0x01 0x7a 0x88 0x0a 0xd4 0xe1 0x49
   0x08 0x08 0x08 0x08

Authors' Addresses