SPRING Working Group F. Yang
Internet-Draft China Mobile
Intended status: Informational C. Lin
Expires: 18 December 2025 New H3C Technologies
16 June 2025
SID as source address in SRv6
draft-yang-spring-sid-as-source-address-06
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.
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 18 December 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yang & Lin Expires 18 December 2025 [Page 1]
Internet-Draft SID as source address June 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
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) . . . . . . 4
2.1.2. L2 VPN Virtual Private LAN Service(VPLS) . . . . . . 4
2.1.3. L3 IPv4/IPv6 VPN Service . . . . . . . . . . . . . . 4
2.2. Control Traffic . . . . . . . . . . . . . . . . . . . . . 5
2.3. OAM Traffic . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Management Traffic . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . 6
3.2.1. Content of SRv6 Source Verification Entry . . . . . . 6
3.2.2. Management of SRv6 Source Verification Table . . . . 6
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. SRv6 Network with SR-aware Stateful Firewall . . . . . . 7
4.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 7
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Yang & Lin Expires 18 December 2025 [Page 2]
Internet-Draft SID as source address June 2025
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.
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
There are still the following key gaps in current network technology:
Application-aware features. It is necessary to provide
differentiated services based on the different services of the same
user. For example, video conferencing needs to avoid stuttering or
screen tearing due to congestion and packet loss to ensure a customer
experience, while general web browsing services can strive for the
best.
Data plane programming capabilities. Identify and classify user
application data, and transfer it to the appropriate service-level
tunnel based on the results.
Ability to perceive the user experience. Through real-time detection
and perception of user-level service experience, it works with
intelligent routing to ensure service assurance for high-priority
services. Currently, there is a lack of traffic identification for
rapid classification and statistical analysis of the user experience
of this type of traffic.
Ability to prevent leakage of network services. The security of the
access network is relatively poor, and there is a risk of leakage of
information related to user applications.
2.1. User Traffic
There are several cases for using SRv6 SID as source address.
Yang & Lin Expires 18 December 2025 [Page 3]
Internet-Draft SID as source address June 2025
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: L2 VPWS
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.
+------------+
| PE | +------------+
| +------+ | | SRv6 |
--------+--+ VPLS +--+--------+ Provider |
| +------+ | | 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
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.
Yang & Lin Expires 18 December 2025 [Page 4]
Internet-Draft SID as source address June 2025
+-------------+
| PE | +--------------+
+----+ | +--------+ | | SRv6 |
| CE +---+--+Tenant--+-+----+ Provider |
+----+ | +--------+ | | Backbone |
+-------------+ +--------------+
Figure 3: L3 VPN
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.
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.
Yang & Lin Expires 18 December 2025 [Page 5]
Internet-Draft SID as source address June 2025
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
or misconfiguration. 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:
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.
Yang & Lin Expires 18 December 2025 [Page 6]
Internet-Draft SID as source address June 2025
* 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
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 18 December 2025 [Page 7]
Internet-Draft SID as source address June 2025
+---+ +---+ +--------+ +---+ +---+
|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 18 December 2025 [Page 8]
Internet-Draft SID as source address June 2025
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 & Lin Expires 18 December 2025 [Page 9]
Internet-Draft SID as source address June 2025
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.
Yang & Lin Expires 18 December 2025 [Page 10]
Internet-Draft SID as source address June 2025
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
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.
Yang & Lin Expires 18 December 2025 [Page 11]
Internet-Draft SID as source address June 2025
By leveraging the routes' native search capability, we introduce a
source address verification mechanism to address such problem.
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: SDWAN
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 & Lin Expires 18 December 2025 [Page 12]
Internet-Draft SID as source address June 2025
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
fundamental requirements for SRv6 core network architecture is to
Yang & Lin Expires 18 December 2025 [Page 13]
Internet-Draft SID as source address June 2025
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
To prevent the CE (Customer Edge) from arbitrarily designating
intermediate network forwarding nodes without restriction, the
following method can be adopted to verify the legality of the path.
Verification of SRv6 (Segment Routing over IPv6) path legitimacy is
conducted on PE (Provider Edge) and P (Provider) nodes through a
verification table. Each entry in this table includes a token value
and its corresponding verification information. The token acts as
the table's index and can represent a path through a Path SID
(Segment Identifier). The verification information includes
properties that determine forwarding actions, such as the legitimate
incoming interface for the path and the next hop SID.
SRv6 packets sent by user-side equipment (CE) need to carry the
token in the innermost layer. Upon receiving the packet, the PE node
extracts the token value from this innermost layer of the SID List
to look up the corresponding verification table information. If the
packet does not include a token, it is discarded. If a matching
entry is found, the node checks whether the packet's incoming
interface matches the incoming interface in the verification table
entry, and whether the next hop address matches the next SID in the
packet's SID List. Depending on the level of verification,
forwarding only occurs if either the incoming interface, the next
hop, or both match.
7. References
7.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,
<https://www.rfc-editor.org/rfc/rfc8200>.
[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 18 December 2025 [Page 14]
Internet-Draft SID as source address June 2025
[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>.
[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/rfc/rfc4301>.
[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>.
[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>.
7.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/rfc/rfc5920>.
[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-11, 23 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-11>.
[I-D.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-03, 5 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-security-03>.
Yang & Lin Expires 18 December 2025 [Page 15]
Internet-Draft SID as source address June 2025
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 & Lin Expires 18 December 2025 [Page 16]