]> China Mobile

CN yangfeng@chinamobile.com

New H3C Technologies

CN linchangwang.04414@h3c.com

RTG SPRING SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. Both the carrier market and the enterprise market are adopting SRv6 for end-to-end service delivery. However, if a firewall exists along an SRv6 path, not only legitimate SRv6 traffic but also ICMP packets generated on SRv6 transit node will be dropped. This proposal addresses this issue by using SID as source address in SRv6 packets.

Introduction SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. Both the carrier market and the enterprise market are adopting SRv6 for end-to-end service delivery. However, if a firewall exists along an SRv6 path, not only legitimate SRv6 traffic but also ICMP packets generated on SRv6 transit node will be dropped. The reason has been elaborated in Section 8.1 of . SRv6 implementations use the ingress PE's loopback IPv6 address as the outer IPv6 source address for encapsulated traffic. This design leads to asymmetric bidirectional flow tuples. When stateful firewalls exist along the SRv6 forwarding path, legitimate bidirectional traffic and all upstream response packets, e.g., ICMP response, are dropped by firewalls, as they fail to match stateful session rules. Operators are forced to deploy additional multi-layer tunneling such as IPsec to bypass firewall filtering, which introduces significant header overhead and weakens the native programmability advantages of SRv6.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology AC: attachment circuit. PE: Provider Edge. SID: Segment Identifier, defined in . SRv6: SR over IPv6, defined in . VPLS: Virtual Private LAN Service. VPWS: Virtual Private Wire Service. VPN: Virtual Private Network.

Using SRv6 SID as Source Address Only unicast traffic is eligible for using SID as source address. Several cases SHOULD be considered for using SRv6 SID as source address when there is firewall in middle. User traffic. This includes IP VPN over SRv6 and Global IP over SRv6. ICMP traffic. This is mainly for SRv6 Ping in SRv6 OAM scenario.

User Traffic

IP VPN over SRv6 The user traffic SHOULD use the SRv6 service SID as the source address of the outer IPv6 header. All those End.DX* and End.DT* SIDs except End.DT2M SHOULD be used for source address. Service SIDs in SRv6 VPN deployments may be allocated per-AC, per-VRF, or per-prefix, and these three granularities can coexist within the same network and even within the same VRF. There are 3 options: Option A: Use the VRF-bound SID as source address. Option B: Use the AC-bound SID as source address. Option C: Use the prefix SID as source address, and perform a source-IP-based lookup in the VRF to select the SID associated with the route matching the source address. Option A requires zero additional lookup, as the VRF is identified from the incoming AC. This is operationally simple and sufficient for many deployments. However, all CEs in the same VRF will appear to the firewall as originating from the same source SID, which may limit per-CE state tracking. Option B provides the symmetry at the AC level, and with zero additional lookup. Option C introduces significant additional lookup cost, as the PE must perform a separate lookup on the source IP address of the customer packet. This is operationally expensive and may impact forwarding performance. The selection of the source service SID on the ingress PE is dependent on and MUST mirror the service SID that the egress PE expects to receive for the corresponding VPN flow; the most granular available SID that matches the incoming context MUST be chosen, which typically means using the per-prefix SID when available, falling back to the per-AC SID, and last is per VPN SID.

Global IP over SRv6 Sections 5.3 and 5.4 of specify the SRv6 Service SIDs to be used for Global IP over SRv6 Core (both IPv4 and IPv6). Accordingly, for the IPv4 over SRv6 Core scenario, End.DX4, End.DT4, or End.DT46 SHOULD be selected as the source address; for the IPv6 over SRv6 Core scenario, End.DX6, End.DT6, or End.DT46 SHOULD be selected as the source address.

ICMP Traffic For SRv6 ping, the ICMP Echo Request MAY use an End SID as the outer IPv6 source address to verify the reachability of the return path. When an SRv6 transit node generates an ICMP error response, using its own SID (the one from the segment list that caused the processing error) as the source address offers a clear operational benefit: the head-end can immediately pinpoint exact SID and node on which the error occurred. When the ICMP error is triggered by VPN traffic, the ingress PE, upon receiving the ICMP error response, MUST process the Upper-Layer header of the embedded packet as specified in Section 4.1.1 of . This ensures that the inner ICMP can be forwarded to the CE.

Control and Management Traffic Control and Management Traffic will not be terminated by VPN, thus will not be impacted.

Use Cases

SRv6 Network with SR-aware Stateful Firewall

Problem Statement To provide VPN service in an SRv6 network , the ingress PE encapsulates the payload in an outer IPv6 header with the Segment Routing Header (SRH) carrying the SR Policy segment list along with the VPN Service SID. If the VPN service provides best-effort connectivity, the destination address of the outer IPv6 header carries the VPN service SID and the SRH is omitted. Along the forwarding path in the SRv6 network, firewalls may be deployed to filter the traffics. If a firewall is SR-aware, it will retrieve the final destination of an SRv6 packet from the last entry in the SRH rather than the destination address field of the IPv6 header . A stateful firewall keeps a track of the state of the network connections traveling across it. Whenever a packet arrives to seek permission to pass through it, the firewall checks from its state table if there is an active connection between identified by 3-tuple or 5-tuple. Thus only legitimate packets are allowed to be transmitted across it. and show the bidirectional VPN traffic packets passing through a firewall in an SRv6 network. The source address of the outer IPv6 header is the IPv6 address of ingress PE. The final destination address of the outer IPv6 header is the VPN Service SID of egress PE. In the SR-Policy-based way, the final destination address is encapsulated in the last entry in the SRH, Segment[0]. In the best-effort way, the SRH is omitted.

PE2): Packet (PE1 <--- PE2): ********************** ********************** * IPv6 * * IPv6 * * SA=PE1-IP-ADDR * * SA=PE2-IP-ADDR * * DA=NextSegment * * DA=NextSegment * ********************** ********************** * SRH * * SRH * * Seg[0]=PE2-VPN-SID * * Seg[0]=PE1-VPN-SID * * Seg[...] * * Seg[...] * ********************** ********************** * Eth/IPv4/IPv6 * * Eth/IPv4/IPv6 * * Source=CE1 * * Source=CE2 * * Destination=CE2 * * Destination=CE1 * ********************** ********************** * Payload * * Payload * ********************** ********************** ]]>

PE2): Packet (PE1 <--- PE2): ********************** ********************** * IPv6 * * IPv6 * * SA=PE1-IP-ADDR * * SA=PE2-IP-ADDR * * DA=PE2-VPN-SID * * DA=PE1-VPN-SID * ********************** ********************** * Eth/IPv4/IPv6 * * Eth/IPv4/IPv6 * * Source=CE1 * * Source=CE2 * * Destination=CE2 * * Destination=CE1 * ********************** ********************** * Payload * * Payload * ********************** ********************** ]]>

The stateful firewall will check the association relationships of the bidirectional VPN traffic packets. A common implementation may record the key information of the packets in the forward way(internal to external), such as source address and destination address. When receiving a packet on backward way(external to internal), it checks the state table if there is an existing forward packet flow. For example, the firewall may require that the source address of packet on backward way matches the destination address of packet on forward way, and destination address will be checked in the similar way. If not matched, the packet on the backward path will be regarded as illegal and thus dropped. An SR-aware firewall is able to retrieve the final destination of an SRv6 packet from the last entry in the SRH. The <source, destination> tuple of the packet from PE1 to PE2 is <PE1-IP-ADDR, PE2-VPN-SID>, and the other direction is <PE2-IP-ADDR, PE1-VPN-SID>. However, the source address of the outer IPv6 packet is usually a loopback interface of the ingress PE. Consequently, the source address and destination address of the forward and backward VPN traffic are regarded as different flows, and they may be blocked by the firewall.

Solution for SRv6 Traffic Pass Thru SR-aware Stateful Firewall In the SRv6-based VPN service, the final destination of the outer IPv6 header is the VPN-SID of the egress PE, which is associated with that VPN service. But the source address of the outer IPv6 header is usually unrelated to the VPN service. So, it can be difficult for a stateful firewall to establish the association relationship between the bidirectional traffic flows. The proposed solution is to unify the semantic of the source and destination address thus ensure the symmetry of the bidirectional flow. When an ingress PE receives the client packet from CE, it checks which L3 VPN service it belongs to, and uses the VPN-SID associated with that L3 VPN service as the source address when encapsulating the outer IPv6 header with the optional SRH.

According to and , an SRv6 VPN Service SID is an IPv6 address, and it is routable by its Locator prefix in the SRv6 network. In the proposed solution, when an SRv6 VPN Service SID is used as the source address of the outer IPv6 header in the SRv6 network, it is treated as a normal IPv6 address and does not perform any special behavior.

Considerations on SRv6 Compression When an SRv6 packet is forwarded in the SRv6 domain, its IPv6 destination address is modified in each segment, and the final destination address is not available in the IPv6 header. It is therefore possible to retrieve the final destination of an SRv6 packet from the last entry in the SRH. When compressed segment lists are used, the last element of the Routing Header may be different from the destination address as received by the final destination. Furthermore, compressed segment lists can be used in the destination address without the presence of a Routing Header, and in this case the IPv6 destination address can be modified along the path. To ensure proper operation of the stateful firewall, it is RECOMMENDED that during the deployment of , the last destination address remains uncompressed and be carried as the last element in the SRH.

Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to . This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

New H3C Technologies Organization: New H3C Technologies. Implementation: H3C CR16000 and CR19000 series routers implement SID as source address in SRv6. Description: All sections including all the "MUST" and "SHOULD" clauses have been implemented in the above-mentioned New H3C products(running version 7.1.119 and above). Maturity Level: Production Coverage: All sections. Version: Draft-13 Licensing: N/A Implementation experience: Nothing specific. Contact: linchangwang.04414@h3c.com Last updated: June 30, 2026

Security Considerations This document is subject to the same security considerations discussed in , , and . The proposed use of an SRv6 SID as the IPv6 source address introduces specific considerations: Source Accountability: Using an SRv6 SID as the source address may impair traceability mechanisms that rely on source address validation, reducing the trustworthiness of the source identity within the domain. Access Control Bypass: Since SRv6 Locator prefixes are typically advertised throughout the routing domain, any node can originate traffic with a spoofed source address matching an internal SID prefix. This could allow attackers to bypass intra-domain access control policies by masquerading as trusted internal traffic. Stateful Device Impact: The dynamic and programmable nature of SRv6 SIDs, when used as source addresses, can lead to rapid churn in the session tables of stateful devices like firewalls. This may cause excessive resource consumption, abnormal session aging, and potential session table overflow, impacting device performance and stability. Operational Requirement: Deployment of this mechanism requires strict operational controls to govern which service flows are permitted to use an SRv6 SID as a source address. Unrestricted use amplifies the associated risks.

IANA Considerations This document has no IANA actions.

Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network. The document also specifies the OAM flag (O-flag) in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain. Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Cisco Systems, Inc. China Mobile Cisco Systems, Inc. Bell Canada Huawei Orange Mellanox AT&T Nokia Universita di Roma "Tor Vergata" This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. Energy Sciences Network Huawei China Unicom Telefonica SI6 Networks SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols.

Acknowledgements The authors would like to thank Bruno Decraene of the SPRING Working Group for his detailed review and constructive comments on this document.