Internet DRAFT - draft-yang-spring-sid-as-source-address

draft-yang-spring-sid-as-source-address



SPRING Working Group                                            F. Yang
Internet Draft                                             China Mobile
Intended status: Informational                                   C. Lin
Expires: July 19, 2024                             New H3C Technologies
                                                       January 19, 2024
                                                         



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


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 19 2024.

Copyright Notice

   Copyright (c) 2024 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
   (http://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 Simplified BSD License text as described in



Yang, et al.            Expires July, 2024                  [Page 1]

Internet-Draft      SID as source address in SRv6         January 2024


   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   In SRv6 network, the SRv6 packets usually use loopback address as
   source address. However, when there is symmetric traffic requirement
   for bidirectional flow, or there is requirement for traffic source
   validation, using loopback address as source address is not
   sufficient. This document proposes using SID as source address for
   SRv6 traffic, also identifies solution for several use cases.

Table of Contents


   1. Introduction.....................................................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. Using Source Address for Validation in SRv6 Network..............5
      3.1. Source Verification on the SRv6 Tunnel 2nd Hop Node.........5
      3.2. Source Verification on the SRv6 Tunnel Tail.................5
         3.2.1. Content of SRv6 Source Verification Entry..............5
         3.2.2. Management of SRv6 Source Verification Table...........6
   4. Use Cases........................................................6
      4.1. SRv6 Network with SR-aware Stateful Firewall................6
         4.1.1. Problem Statement......................................6
         4.1.2. Solution for SRv6 Traffic Pass Thru SR-aware Stateful
         Firewall......................................................9
      4.2. Enhanced Traffic Isolation between VPNs....................10
         4.2.1. Problem Statement.....................................10
         4.2.2. Source Validation Solution for SRv6 SDWAN Network.....12
         4.2.3. Source Validation Solution for SRv6 Core Network......13
   5. IANA Considerations.............................................14
   6. Security Considerations.........................................14
   7. References......................................................14
      7.1. Normative References.......................................14
      7.2. Informative References.....................................15
   8. Acknowledgments.................................................16
   Authors' Addresses.................................................17




Yang, et al.            Expires July, 2024                 [Page 2]

Internet-Draft      SID as source address in SRv6         January 2024


  1. Introduction

   Typically, the SRv6 packets usually use loopback address as source
   address. However, when there is symmetric traffic requirement for
   bidirectional flow, or there is requirement for traffic source
   validation, using loopback address as source address is not
   sufficient. This document proposes using SRv6 SID as source address
   for SRv6 traffic, also identifies solution for several use cases.

  2. Using SRv6 SID as 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 provider
   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    +
                          ---+---L2 VPWS---+--------+    Provider  +
                             |            |         +    Backbone  +
                             +------------+         +--------------+
                                 Figure 1


2.1.2. L2 VPN Virtual Private LAN Service(VPLS)

   For L2 VPN VPLS, the user traffic towards SRv6 provider 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, et al.            Expires July, 2024                 [Page 3]

Internet-Draft      SID as source address in SRv6         January 2024


                             +------------+
                             |    PE      |         +--------------+
                             |  +------+  |         +      SRv6    +
                     --------+--+ VPLS  +--+--------+    Provider  +
                             |  +------+  |         +    Backbone  +
                             +------------+         +--------------+
                                 Figure 2
2.1.3. L3 IPv4/IPv6 VPN Service

   For L3 IPv4/IPv6 VPN Service case, the user traffic towards SRv6
   provider 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 +----+--+Tenant--+-+-----+    Provider  +
                 +----+    |  +--------+ |     +    Backbone  +
                           +-------------+     +--------------+
                                 Figure 3

2.2. Control Traffic

   Control traffic will not be terminated by VPN, thus should 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
   anexample, 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.




Yang, et al.            Expires July, 2024                 [Page 4]

Internet-Draft      SID as source address in SRv6         January 2024


  3. Using Source Address for Validation in SRv6 Network

   Refer to figure 7, when the traffic is passing through the SRv6
   bearer network, the received traffic can be verified at the
   following two locations.

      Ingress PE node of IPv6 backbone network

      C-PE node of destination tenant site or destination client network

3.1. Source Verification on the SRv6 Tunnel 2nd Hop Node

   Main reason for doing this is to prevent SRv6 tunnel source address
   fraud.

   On the C-PE node, it will receive one or more local SRv6 SIDs
   configuration from controller or generate SRv6 SID locally. On the
   nexthop node, i.e. PE node, it can learn those SRv6 SID either from
   controller or IGP protocol.

   Suppose the C-PE will generate SRv6 packets with the SRv6 SID as
   source address, when the SRv6 end point node next to the C-PE, i.e.
   PE node, receives the packets, it can do forward table lookup with
   incoming interface and source address as key for forwarding table
   lookup. If the lookup failed, it is considered as illegal traffic
   and should not be forwarded. Otherwise, the source address is legal.

3.2. Source Verification on the SRv6 Tunnel Tail

   Main reason for doing this is to prevent SRv6 tunnel tail SID fraud.
   Only after the packet is forwarded to the SRv6 egress node (that is,
   the access point of the destination client network, such as C-PE)
   can we have the opportunity to continue to verify whether the packet
   is legal.

   As mentioned before, the source C-PE will generate SRv6 packets with
   the SRv6 SID as source address. On the destination C-PE, it has
   source verification table with all of source VPN SIDs have been
   authorized for access. After receiving SRv6 packet, based on the
   source address, it can check the SRv6 packet for authorized access.
   If the SRv6 packet passes check, it will forward the SRv6 packet;
   otherwise, discard it.

3.2.1. Content of SRv6 Source Verification Entry

   Every VPN will have a source verification table. And there are
   multiple source verification entries in the source verification
   table, and each table entry contains the following contents:

Yang, et al.            Expires July, 2024                 [Page 5]

Internet-Draft      SID as source address in SRv6         January 2024


      The source service address which is encapsulated as the outer
      source IPv6 address of the packet, used to identify the service of
      the source client network. For example, the source service SID of
      SRv6.

   The source service address is the content that must be verified.

3.2.2. Management of SRv6 Source Verification Table

   The SRv6 source verification entry can be created in the following
   ways:

      Manual static configuration on the SRv6 egress node. Configure the
      source address in local L3VPN/L2VPN source address Verification
      table.

      Dynamic creation after learning the service address of the source
      client network through BGP. When the L3VPN/L2VPN route with the
      remote L3VPN/L2VPN service id is inserted into the local VPN table,
      the relationship between the local L3VPN/L2VPN service sid of the
      destination VPN table and the remote L3VPN/L2VPN service id is
      recorded to form a dynamic source address Verification table in
      local VPN table.

  4. Use Cases

4.1. SRv6 Network with SR-aware Stateful Firewall

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


Yang, et al.            Expires July, 2024                 [Page 6]

Internet-Draft      SID as source address in SRv6         January 2024


   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, et al.            Expires July, 2024                 [Page 7]

Internet-Draft      SID as source address in SRv6         January 2024


      +---+   +---+       +--------+       +---+   +---+
      |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, et al.            Expires July, 2024                 [Page 8]

Internet-Draft      SID as source address in SRv6         January 2024


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

4.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, et al.            Expires July, 2024                 [Page 9]

Internet-Draft      SID as source address in SRv6         January 2024


   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.2. Enhanced Traffic Isolation between VPNs

4.2.1. Problem Statement

   As analyzed in [RFC5920], there is no 100% safe network. There is a
   risk of traffic being hijacked or tampered anywhere in the network.

   In SRv6 network when someone manipulate the SRH, he/she can reach
   any VPNs without authorized. In other words, VPN isolation needs be
   improved in the source routing scenario.

   Taking the SRv6 SDWAN overlay network as an example, if C-PE is
   hijacked, misconfigured or misconnected, the services that should be
   isolated between CPE sites can be accessible to each other.

   As shown in the figure below, C-PE is deployed in the tenant site,
   and the tenant of the site is responsible for operation and
   maintenance management. Normally users in client network 1 (CN1) of
   C-PE1 can only communicate with users in CN1 of other C-PEs through

Yang, et al.            Expires July, 2024                [Page 10]

Internet-Draft      SID as source address in SRv6         January 2024


   IPv6 backbone network. CN1 is isolated from other client networks,
   and traffic cannot be forwarded to each other.

                                       +----+
                           +-----------| RR |----------+
                          /            +----+           \
                         /                               \
                        /                                 \
        +----+  +--------+                              +------+  +----+
        | CN1|--|        A1----+                  +---- B1     |--| CN1|
        +----+  | C-PE1  |     | +--------------+ |     | C-PE2|  +----+
        +----+  |        A2--+-+-+              +-+-+   |      |  +----+
        | CN2|--|        |   | PE|              |PE |---B2     |--| CN2|
        +----+  +--------+   +---+              +---+   +------+  +----+
                                 |     IPv6     |
        +----+  +--------+   +---+    Network   +---+   +------+  +----+
        | CN1|--|        C1--| PE|              |PE |-- D1     |--| CN1|
        +----+  | C-PE3  |   +-+-+              +-+-+   | C-PE4|  +----+
                |        |     | +--------------+ |     |      |
        +----+  |        |     |                  |     |      |  +----+
        | CN3|--|        C2----+                  +-----D2     |--| CN3|
        +----+  +--------+                              +------+  +----+
                   |<=========== SRv6 Forwarding ===========>|

                                 Figure 7

   However, due to some misconfiguration or security issues, the
   destination address of VPN packets sent by C-PE to other destination
   client networks may be filled in as the service address of other
   client networks.

   For example, the destination address of the traffic from CN1 of C-
   PE1 to CN1 of C-PE2 is misconfigured or tampered with as the service
   SID of CN3 of C-PE4. The traffic can be send to C-PE4. If the
   service SID happens to exist in CN3 of C-PE4, the traffic will be
   forwarded to CN3. This is a very serious security vulnerability for
   client networks that should be completely isolated.

   In theory, the HMAC TLV in the SRH with integrity check on the way
   can address this problem. However, HMAC integrity check is hard to
   be supported by the routers hardware in line rate. Thus nobody
   actually do that on router.

   By leveraging the routes' native search capability, we introduce a
   source address verification mechanism to address such problem.




Yang, et al.            Expires July, 2024                [Page 11]

Internet-Draft      SID as source address in SRv6         January 2024


4.2.2. Source Validation Solution for SRv6 SDWAN Network

   In the SRv6 SDWAN overlay network, in order to completely isolate
   the VPN services of different tenant sites, the SRv6 source
   verification function can be enabled on the C-PE of the tenant site
   connecting to the IPv6 backbone network. At the same time, specify
   which user sites from which C-PE can communicate with it on each C-
   PE.

   That is, destination C-PE verifies the source VPN SID, destination
   VPN SID.

                                          +---+
                           +--------------|RR |------------+
                          /               +-+-+             \
                         /                                   \
                        /                                     \
             +----+  +---------+      + -------------+       +------+  +----+
             | CN1|--|         P1-----+              +------ P1     |--| CN1|
             +----+  | C-PE1   P2-----+              |       | C-PE2|  +----+
             +----+  |         P3-----+              +------ P2     |  +----+
             | CN2|--|         |      |     IPv6     +------ P3     |--| CN3|
             +----+  +---------+      |   Network    |       +------+  +-+--+
             +----+  +---------+      |              |       +------+  +----+
             | CN2|--|         P1-----+              +------ P1     |--| CN1|
             +----+  | C-PE3   P2-----+              |       | C-PE4|  +----+
             +----+  |         P3-----+              +------ P2     |  +----+
             | CN3|--+---------+      + -------------+       +------+--| CN2|
             +-+--+                                                    +----+
                       |<=========== SRv6 Forwarding ===========>|

                                 Figure 8


   Taking the networking shown in Figure 8 as an example, C-PE1
   connects two VPN tenants CN1 and CN2, and C-PE2 connects VPN tenants
   CN1 and CN3.

   1)           Configure VPN SID.









Yang, et al.            Expires July, 2024                [Page 12]

Internet-Draft      SID as source address in SRv6         January 2024


      VPN SID on C-PE1:
         CN1:
            vpn-instance 1 end-dt4 100::100
         CN2:
            vpn-instance 2 end-dt4 100::200
      VPN SID on C-PE2:
         CN1:
            vpn-instance 1 end-dt4 200::100
         CN3:
            vpn-instance 3 end-dt4 200::300
      VPN SID on C-PE3:
         CN2:
            vpn-instance 2 end-dt4 300::200
         CN3:
            vpn-instance 3 end-dt4 300::300
      VPN SID on C-PE4:
         CN1:
            vpn-instance 1 end-dt4 400::100
         CN2:
            vpn-instance 3 end-dt4 400::200

   2)           Configure source address verification entries.

      Source address verification table on C-PE1:
            vpn-instance 1:
                Trusted-source-address 200::100
                Trusted-source-address 400::100
            Vpn-instance 2:
                Trusted-source-address 300::200
                Trusted-source-address 400::200
      Source address verification table on C-PE2:
            Vpn-instance 1:
                Trusted-source-address 100::100
                Trusted-source-address 400::100
            Vpn-instance 3:
                Trusted-source-address 300::300


4.2.3. Source Validation Solution for SRv6 Core Network

   Some operators are currently building, or plan to build an IPv6-only
   native infrastructure for their core network. These operators are
   also looking at the possibility to set up an explicit path based on
   the IPv6 source address for specific types of traffic in order to
   efficiently use their network infrastructure.  In such an
   environment, the IPv6 source address could be used by the edge nodes
   of the network to steer traffic and forward it through a specific
   path other than the optimal path. Additionally, one of the

Yang, et al.            Expires July, 2024                [Page 13]

Internet-Draft      SID as source address in SRv6         January 2024


   fundamental requirements for SRv6 core network architecture is to
   provide scalable, isolated tenant networks.

   Due to some misconfiguration or security issues, when the traffic is
   pass through the SRv6 core network, the received traffic can be
   verified by source verification. The SRv6 source verification
   function can be enabled on the PE of the tenant network connecting
   to the PE-based SRv6 core network.

                                       +---+
                                       |PE2|
                                       +-+-+
                                         ^
                                         |
                                         v
                         +---+         +-+-+        +---+
                         |PE1| <=====> | RR| <====> |PE3|
                         +-+-+         +---+        +-+-+
                           |                          |
                           +--- SRv6 core netowrk ----+

               Figure 9 PE-based SRv6 core network

  5. IANA Considerations

   This document has no IANA actions.

  6. Security Considerations

   This document does not introduce any security considerations.

7. References

7.1. Normative References

   [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks",
             RFC 5920, DOI 10.17487/RFC5920, July 2010,
             <https://www.rfc-editor.org/info/rfc5920>.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
             December 2005, <https://www.rfc-editor.org/info/rfc4301>.



Yang, et al.            Expires July, 2024                [Page 14]

Internet-Draft      SID as source address in SRv6         January 2024


   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, RFC 8174, May 2017

   [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/info/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/info/rfc8754>.

   [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/info/rfc9252>.

   [I-D.li-savnet-intra-domain-architecture] Li, D., Wu, J., Qin, L.,
             Gao, F., Geng, N., Zhou, T., "Intra-domain Source Address
             Validation (SAVNET) Architecture", draft-li-savnet-intra-
             domain-architecture-00, (work in progress), October 2022.

   [I-D.wu-savnet-inter-domain-architecture] Wu, J., Li, D., Huang, M.,
             Qin, L., Geng, N., Zhou, T., "Inter-domain Source Address
             Validation (SAVNET) Architecture", draft-wu-savnet-inter-
             domain-architecture-00(work in progress), October 2022.

7.2. Informative References

   [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/info/rfc8986>.

   [I-D.ietf-spring-sr-service-programming] Clad, F., 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-07, 15 February
             2023, <https://www.ietf.org/archive/id/draft-ietf-spring-
             sr-service-programming-07.txt>.





Yang, et al.            Expires July, 2024                [Page 15]

Internet-Draft      SID as source address in SRv6         January 2024


  8. Acknowledgments

   The authors would like to thank the following for their valuable
   contributions of this document:

   TBD










































Yang, et al.            Expires July, 2024                [Page 16]

Internet-Draft      SID as source address in SRv6         January 2024


Authors' Addresses

   Feng Yang
   China Mobile
   Beijing
   China
   Email: yangfeng@chinamobile.com

   Changwang Lin
   New H3C Technologies
   Beijing
   China

   Email: linchangwang.04414@h3c.com


   
   
   
   
   


  
   
   
   
   




















Yang, et al.            Expires July, 2024                [Page 17]