SPRING F. Yang Internet-Draft China Mobile Intended status: Standards Track C. Lin Expires: 13 August 2026 New H3C Technologies 9 February 2026 SID as source address in SRv6 draft-yang-spring-sid-as-source-address-08 Abstract 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, legitimate SRv6 traffic will be dropped. This proposal addresses this issue by using SID as source address in SRv6 packets. 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 13 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Yang & Lin Expires 13 August 2026 [Page 1] Internet-Draft SID as source address February 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Using SRv6 SID as Source Address . . . . . . . . . . . . . . 3 2.1. User Traffic . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. L2 VPN Virtual Private Wire Service(VPWS) . . . . . . 3 2.1.2. L2 VPN Virtual Private LAN Service(VPLS) . . . . . . 3 2.1.3. L3 IPv4/IPv6 VPN Service . . . . . . . . . . . . . . 4 2.2. Control Traffic . . . . . . . . . . . . . . . . . . . . . 4 2.3. OAM Traffic . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Management Traffic . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. SRv6 Network with SR-aware Stateful Firewall . . . . . . 5 3.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 5 3.1.2. Solution for SRv6 Traffic Pass Thru SR-aware Stateful Firewall . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. 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, legitimate SRv6 traffic will be dropped. This proposal addresses this issue by using SID as source address in SRv6 packets. The reason has been elaborated in Section 8.1 of [I-D.draft-ietf-spring-srv6-security]. In brief, SRv6 using loopback as source address will cause asymmetric address, which will be blocked by the firewall. As a result, users are forced to encapsulate traffic with multiple layers of tunnel headers—such as IPSec or L2TP—to ensure it can pass through the firewall. This Yang & Lin Expires 13 August 2026 [Page 2] Internet-Draft SID as source address February 2026 approach introduces two significant issues: first, it increases overhead—for example, IPSec adds approximately 80 bytes of header overhead; second, it undermines the programmability benefits of SRv6, as forwarding is performed based on IPSec rather than SRv6 itself. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Using SRv6 SID as Source Address SRv6 endpoints typically create many SIDs. This section describes the method for selecting a SID as the source address. 2.1. User Traffic There are several cases for using SRv6 SID as source address. 2.1.1. L2 VPN Virtual Private Wire Service(VPWS) For L2 VPN VPWS case, the user traffic towards SRv6 SD-WAN backbone will be encapsulated in SRv6 tunnel. When constructing an SRv6 packet, the source address field of the SRv6 packet should be assigned with the local VPN SID value of the PE device. The local VPN SID value can be determined by L2 Cross-Connect. +------------+ | PE | +--------------+ | +------+ | | SRv6 | ---+--| VPWS-+--+--------+ | | +------+ | | Backbone | +------------+ +--------------+ Figure 1: L2 VPWS 2.1.2. L2 VPN Virtual Private LAN Service(VPLS) For L2 VPN VPLS, the user traffic towards SRv6 backbone will be encapsulated in SRv6 tunnel. When constructing an SRv6 packet, the source address field of the SRv6 packet should be assigned with the local VPN SID value of the PE device. The local VPN SID value can be determined by L2 VPN VPLS. Yang & Lin Expires 13 August 2026 [Page 3] Internet-Draft SID as source address February 2026 +------------+ | PE | +------------+ | +------+ | | SRv6 | ---+--+ VPLS +--+--------+ | | +------+ | | Backbone | +------------+ +------------+ Figure 2: L2 VPLS 2.1.3. L3 IPv4/IPv6 VPN Service For L3 IPv4/IPv6 VPN Service case, the user traffic towards SRv6 backbone will be encapsulated in SRv6 tunnel. When constructing an SRv6 packet, the source address field of the SRv6 packet should be assigned with the local VPN SID value of the PE device. The local VPN SID value can be determined by the L3 IPv4/IPv6 VPN. +-------------+ | PE | +--------------+ +----+ | +--------+ | | SRv6 | | CE +---+--+ L3VPN +-+----+ | +----+ | +--------+ | | Backbone | +-------------+ +--------------+ Figure 3: L3 VPN 2.2. Control Traffic Control traffic will not be terminated by VPN, thus will not be impacted. 2.3. OAM Traffic OAM traffic terminated by the SRv6 tunnel may use the SRv6 SID as source address, such as ping, trace. Refer to RFC 8986 4.1.1, Allowing the processing of specific Upper-Layer header types is useful for Operations, Administration, and Maintenance (OAM). As an example, an operator might permit pinging of SIDs. To do this, they may enable local configuration to allow Upper-Layer header type 58(ICMPv6). 2.4. Management Traffic Management traffic will not be terminated by VPN, thus should not be impacted. 3. Use Cases Yang & Lin Expires 13 August 2026 [Page 4] Internet-Draft SID as source address February 2026 3.1. SRv6 Network with SR-aware Stateful Firewall 3.1.1. Problem Statement To provide VPN service in an SRv6 network [RFC9252], the ingress PE encapsulates the payload in an outer IPv6 header with the Segment Routing Header (SRH) [RFC8754] carrying the SR Policy segment list along with the VPN Service SID. If the VPN service is with 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 [I-D.draft-ietf-spring-sr-service-programming]. 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. Figure 4 and Figure 5 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. Yang & Lin Expires 13 August 2026 [Page 5] Internet-Draft SID as source address February 2026 +---+ +---+ +--------+ +---+ +---+ |CE1|---|PE1|--...--|Firewall|--...--|PE2|---|CE2| +---+ +---+ +--------+ +---+ +---+ Packet (PE1 ---> 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 * ********************** ********************** Figure 4: SR-Policy-based VPN Traffic across Firewall +---+ +---+ +--------+ +---+ +---+ |CE1|---|PE1|--...--|Firewall|--...--|PE2|---|CE2| +---+ +---+ +--------+ +---+ +---+ Packet (PE1 ---> 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 * ********************** ********************** Figure 5: Best-Effort VPN Traffic across Firewall 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 on 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 Yang & Lin Expires 13 August 2026 [Page 6] Internet-Draft SID as source address February 2026 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 tuple of the packet from PE1 to PE2 is , and the other direction is . However, the source address of the outer IPv6 packet is usually a loopback interface of the ingress PE. Eventually, the source address and destination address of the forward and backward VPN traffic are regarded as different flow, and they may be blocked by the firewall. 3.1.2. 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. Yang & Lin Expires 13 August 2026 [Page 7] Internet-Draft SID as source address February 2026 Outer IPv6 Header of SR-Policy-based VPN Traffic: ********************** ********************** * IPv6 * * IPv6 * * SA=PE1-VPN-SID * * SA=PE2-VPN-SID * * DA=NextSegment * * DA=NextSegment * ********************** ********************** * SRH * * SRH * * Seg[0]=PE2-VPN-SID * * Seg[0]=PE1-VPN-SID * * Seg[...] * * Seg[...] * ********************** ********************** Outer IPv6 Header of Best-effort VPN Traffic: ********************** ********************** * IPv6 * * IPv6 * * SA=PE1-VPN-SID * * SA=PE2-VPN-SID * * DA=PE2-VPN-SID * * DA=PE1-VPN-SID * ********************** ********************** Figure 6: Outer IPv6 Header in the Proposed Solution According to [RFC8402] and [RFC8986], 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. 4. IANA Considerations This document has no IANA actions. 5. Security Considerations TBD. 6. References 6.1. Normative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . Yang & Lin Expires 13 August 2026 [Page 8] Internet-Draft SID as source address February 2026 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . Yang & Lin Expires 13 August 2026 [Page 9] Internet-Draft SID as source address February 2026 [I-D.draft-ietf-spring-sr-service-programming] Abdelsalam, A., Xu, X., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr- service-programming-12, 3 November 2025, . [I-D.draft-ietf-spring-srv6-security] Buraglio, N., Mizrahi, T., tongtian124, Contreras, L. M., and F. Gont, "Segment Routing IPv6 Security Considerations", Work in Progress, Internet-Draft, draft- ietf-spring-srv6-security-11, 2 February 2026, . Authors' Addresses Feng Yang China Mobile China Email: yangfeng@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Yang & Lin Expires 13 August 2026 [Page 10]