SID as source address in SRv6
draft-yang-spring-sid-as-source-address-13

SPRING                                                           F. Yang
Internet-Draft                                              China Mobile
Intended status: Informational                                    C. Lin
Expires: 2 January 2027                             New H3C Technologies
                                                             1 July 2026

                     SID as source address in SRv6
               draft-yang-spring-sid-as-source-address-13

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

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 2 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Yang & Lin               Expires 2 January 2027                 [Page 1]
Internet-Draft            SID as source address                July 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
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Using SRv6 SID as Source Address  . . . . . . . . . . . . . .   3
     2.1.  User Traffic  . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  IP VPN over SRv6  . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Global IP over SRv6 . . . . . . . . . . . . . . . . .   4
     2.2.  ICMP Traffic  . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Control and Management Traffic  . . . . . . . . . . . . .   5
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     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.  Considerations on SRv6 Compression  . . . . . . . . . . . . .   8
   5.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
     5.1.  New H3C Technologies  . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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, 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
   [I-D.draft-ietf-spring-srv6-security].  SRv6 implementations use the
   ingress PE's loopback IPv6 address as the outer IPv6 source address

Yang & Lin               Expires 2 January 2027                 [Page 2]
Internet-Draft            SID as source address                July 2026

   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.

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.

1.2.  Terminology

   AC: attachment circuit.

   PE: Provider Edge.

   SID: Segment Identifier, defined in [RFC8402].

   SRv6: SR over IPv6, defined in [RFC8402].

   VPLS: Virtual Private LAN Service.

   VPWS: Virtual Private Wire Service.

   VPN: Virtual Private Network.

2.  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[RFC9259]
      scenario.

Yang & Lin               Expires 2 January 2027                 [Page 3]
Internet-Draft            SID as source address                July 2026

2.1.  User Traffic

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

2.1.2.  Global IP over SRv6

   Sections 5.3 and 5.4 of [RFC9252] 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.

Yang & Lin               Expires 2 January 2027                 [Page 4]
Internet-Draft            SID as source address                July 2026

2.2.  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 [RFC8986].  This ensures that the inner ICMP can be
   forwarded to the CE.

2.3.  Control and Management Traffic

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

3.  Use Cases

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 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 [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 1 and Figure 2 show the bidirectional VPN traffic packets
   passing through a firewall in an SRv6 network.

Yang & Lin               Expires 2 January 2027                 [Page 5]
Internet-Draft            SID as source address                July 2026

   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.

           +---+   +---+       +--------+       +---+   +---+
           |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 1: 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 2: Best-Effort VPN Traffic across Firewall

Yang & Lin               Expires 2 January 2027                 [Page 6]
Internet-Draft            SID as source address                July 2026

   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.

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 2 January 2027                 [Page 7]
Internet-Draft            SID as source address                July 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 3: 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.  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[RFC9800] 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
   [RFC9800], the last destination address remains uncompressed and be
   carried as the last element in the SRH.

Yang & Lin               Expires 2 January 2027                 [Page 8]
Internet-Draft            SID as source address                July 2026

5.  Implementation Status

   [Note to the RFC Editor - remove this section before publication, as
   well as remove the reference to [RFC7942].  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 [RFC7942].  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 [RFC7942], "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".

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

Yang & Lin               Expires 2 January 2027                 [Page 9]
Internet-Draft            SID as source address                July 2026

6.  Security Considerations

   This document is subject to the same security considerations
   discussed in [RFC8402], [RFC8754], and [RFC8986].

   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.

7.  IANA Considerations

   This document has no IANA actions.

8.  References

8.1.  Normative References

   [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, <https://www.rfc-editor.org/rfc/rfc8402>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8754>.

Yang & Lin               Expires 2 January 2027                [Page 10]
Internet-Draft            SID as source address                July 2026

   [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,
              <https://www.rfc-editor.org/rfc/rfc8986>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9252>.

   [RFC9259]  Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
              Chen, "Operations, Administration, and Maintenance (OAM)
              in Segment Routing over IPv6 (SRv6)", RFC 9259,
              DOI 10.17487/RFC9259, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9259>.

   [RFC9800]  Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
              Clad, Ed., "Compressed SRv6 Segment List Encoding",
              RFC 9800, DOI 10.17487/RFC9800, June 2025,
              <https://www.rfc-editor.org/rfc/rfc9800>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/rfc/rfc7942>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-service-programming-12>.

Yang & Lin               Expires 2 January 2027                [Page 11]
Internet-Draft            SID as source address                July 2026

   [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-15, 24 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-security-15>.

Acknowledgements

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

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 2 January 2027                [Page 12]