Export of Segment Routing Policy Attributes 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 28 August 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

Segment Routing (SR) [RFC8402] and Segment Routing over IPv6 (SRv6) [RFC8986] have become widely deployed technologies for source routing and traffic engineering in modern networks. SR Policy [RFC9256] provides a mechanism to steer traffic through an ordered list of segments to meet Service Level Agreements (SLAs) and other operational requirements.¶

An SR Policy is uniquely identified by the tuple <Headend, Color, Endpoint>, where:¶

• Headend: The node where the policy is instantiated.¶
• Color: A 32-bit numerical value representing the policy intent or class.¶
• Endpoint: The destination address of the policy (IPv4 or IPv6).¶

While network operators can monitor traffic flows using IP Flow Information Export (IPFIX) [RFC7011] and observe which SR policies are configured in the network, there has been no standardized way to correlate individual IP flows with the specific SR policies that carry them. This correlation is essential for:¶

• Service Assurance: Verifying that traffic is being forwarded according to the intended policy.¶
• Troubleshooting: Identifying which flows are affected when a policy fails.¶
• Routing Planning: Understanding traffic forwarding patterns per policy class.¶
• Security Monitoring: Detecting policy bypass or hijacking attempts.¶

This document defines new IPFIX Information Elements (IEs) to export SR and SRv6 policy attributes (color, endpoint, and type) associated with observed IP flows. These IEs enable Exporting Processes to report which SR policy was applied to each flow, providing crucial visibility into the relationship between traffic and network policies.¶

2. Terminology

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

This document makes use of the terms defined in [RFC7011], and [RFC8402].¶

The following terms are used as defined in [RFC7011]:¶

• IPFIX¶
• IPFIX Information Elements¶

The following terms are used as defined in [RFC8402]:¶

• Segment Routing (SR)¶
• SR-MPLS¶
• SRv6¶

3. IPFIX Information Elements for SR Policy Attributes

This section defines new IPFIX IEs for exporting SR Policy attributes.¶

srPolicyColor

The color value of the SR Policy applied to the flow. The color is a 32-bit unsigned integer that identifies the intent or class of the SR Policy.¶

srPolicyEndpointIPv4

The 32-bit IPv4 endpoint address of the SR Policy applied to the flow.¶

srPolicyEndpointIPv6

The 128-bit IPv6 endpoint address of the SR Policy applied to the flow.¶

srPolicyType

The type of SR Policy applied to the flow. It is used to distinguish between SR-MPLS and SRv6 policies.¶

4. Operational Considerations

For srPolicyColor IE, a value of 0 indicates that no SR Policy was applied to the flow (i.e., the flow was forwarded using conventional routing). Color values are locally significant to the headend node but are often coordinated network-wide to represent consistent service classes.¶

For srPolicyEndpointIPv4 and srPolicyEndpointIPv6 IE, A value of 0.0.0.0 for IPv4 address and ::0 for IPv6 address indicates that no SR Policy with an IPv4 or IPv6 endpoint was applied, or the endpoint is unknown. When these IEs is used with srPolicyColor IE, this pair uniquely identifies an SR Policy from the perspective of the headend node.¶

When multiple SR Policies could apply to a flow (e.g., through policy nesting), these IEs defined in this document SHOULD report the value of the outermost or primary policy. These IEs are most meaningfully reported by the headend node of the SR Policy - that is, the node where the policy is instantiated and where packets enter the SR Policy path. To identify the headend node of an SR Policy, the exporterIPv4Address (130) and exporterIPv6Address (131) IEs can be used.¶

These IEs about SR Policy attributes complement existing IPFIX IEs. When reporting SR Policy attributes, Exporting Processes SHOULD also include basic flow identification IEs such as source/destination addresses, protocol, and ports to provide context for the policy application.¶

5. Security Considerations

The Security Considerations for IPFIX [RFC7011] apply to this document as well.¶

SR Policy attributes reveal network engineering decisions and traffic steering policies. Unauthorized access to this information could aid in traffic analysis or network reconnaissance. Export of these IEs SHOULD be protected using IPFIX over TLS [RFC7011] or DTLS [RFC9147].¶

Manipulation of SR Policy attributes in flow records could mislead network operators about traffic paths, potentially hiding policy violations or attacks. Collecting Processes SHOULD verify data integrity when possible.¶

While SR Policy attributes themselves don't directly identify individuals, they could be combined with other flow data to infer sensitive information about network usage patterns.¶

Exporting additional IEs increases the size of flow records and template definitions. Exporting Processes SHOULD implement appropriate rate limiting and resource controls.¶

The ability to correlate flows with policies enables verification that traffic is following intended paths, which can help detect policy bypass attacks or configuration errors.¶

6. IANA Considerations

   +============+========================+===============+
   | Element ID | Name                   | Reference     |
   +============+========================+===============+
   | TBD1       | srPolicyColor          | This document |
   +------------+------------------------+---------------+
   | TBD2       | srPolicyEndpointIPv4   | This document |
   +------------+------------------------+---------------+
   | TBD3       | srPolicyEndpointIPv6   | This document |
   +------------+------------------------+---------------+
   | TBD4       | srPolicyType           | This document |
   +------------+------------------------+---------------+

Table 1: New IEs in the "IPFIX Information Elements" Registry

+=======+=====================================+===============+
| Value | Description                         | Reference     |
+=======+=====================================+===============+
| 0     | Unknown or unspecified policy type  | This document |
+-------+-------------------------------------+---------------+
| 1     | SR-MPLS policy                      | This document |
+-------+-------------------------------------+---------------+
| 2     | SRv6 policy                         | This document |
+-------+-------------------------------------+---------------+
| 255   | Reserved for experimentation        | This document |
+-------+-------------------------------------+---------------+

           Table 2: SR Policy Types Sub-Registry

Authors' Addresses