Requirements of SRv6 for the 6G User Plane
draft-cheng-dmm-srv6-6g-up-requirements-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Weiqiang Cheng , Xiaoqiu Zhang | ||
| Last updated | 2026-07-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cheng-dmm-srv6-6g-up-requirements-00
DMM W. Cheng
Internet-Draft X. Zhang
Intended status: Informational China Mobile
Expires: 20 January 2027 19 July 2026
Requirements of SRv6 for the 6G User Plane
draft-cheng-dmm-srv6-6g-up-requirements-00
Abstract
This document leverages the five standardized 6G service scenarios
defined in 3GPP TR 22.870—multi-agent collaborative communication,
compute-network integration, integrated sensing and communication
(ISAC), network digital twin (NDT), and wide-area deterministic
networking—as core business baselines. It systematically analyzes
the multi-dimensional stringent user-plane requirements introduced by
next-generation mobile systems. This work further dissects inherent
technical limitations within the 5G GTP-U point-to-point tunnel
architecture that render it incapable of accommodating dynamic 6G
service characteristics. Based on the above analysis, this draft
illustrates the inherent programmability benefits provided by SRv6,
and accordingly establishes a suite of standardization requirements
for SRv6 to serve as the underlay forwarding protocol of the 6G user
plane.
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 20 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cheng & Zhang Expires 20 January 2027 [Page 1]
Internet-Draft SRv6，6G，UPF 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 . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Analysis of Typical 6G Scenarios and Corresponding
Requirements . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Multi-Agent Collaborative Communication . . . . . . . . . 4
2.2. Compute-Network Integration (CNI) . . . . . . . . . . . . 5
2.3. Integrated Sensing and Communication (ISAC) . . . . . . . 6
2.4. Network Digital Twin (NDT) . . . . . . . . . . . . . . . 6
2.5. Wide-Area Deterministic Networking . . . . . . . . . . . 7
2.6. Scenario Requirements Summary . . . . . . . . . . . . . . 7
3. General Standardization Requirements . . . . . . . . . . . . 8
3.1. SRv6 Forwarding-Plane Existing Capability Mapping and 6G
Extension Requirements . . . . . . . . . . . . . . . . . 8
3.1.1. Overall Adaptability Foundation of Existing SRv6
Capabilities . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Unified 6G Full-Scenario Extension Requirements
Summary . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Control-Plane Coordination and Orchestration . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4.1. Path Spoofing and Traffic Hijacking . . . . . . . . . . . 11
4.2. SRH Integrity . . . . . . . . . . . . . . . . . . . . . . 11
4.3. User Location Privacy . . . . . . . . . . . . . . . . . . 12
4.4. Control-Plane Security . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The 5G user plane relies throughout the network on GTP-U point-to-
point tunnels to carry N3/N9 interface traffic, with tunnel endpoints
statically bound during PDU session establishment. This architecture
has four inherent limitations that prevent it from matching the
dynamic, multi-dimensional service requirements of 6G:
Cheng & Zhang Expires 20 January 2027 [Page 2]
Internet-Draft SRv6，6G，UPF July 2026
* Forwarding path rigidity: The forwarding path is determined at
session establishment and cannot be dynamically adjusted based on
real-time link state, compute load, or service requirements,
making routing detours highly likely and significantly increasing
service latency. Moreover, GTP tunnels are anchored between fixed
N3/N9 endpoint pairs; there is no native mechanism to dynamically
insert or remove intermediate service nodes (such as compute
offload points or AI inference accelerators) without tearing down
and re-establishing the complete PDU session, introducing
excessive signaling overhead in highly dynamic scenarios.
* High path-reconfiguration latency: The current 5G user plane
adopts a serialized, segment-by-segment establishment approach,
with a relatively lengthy procedure. Path reconfiguration caused
by user mobility, service requirement changes, or network element/
link failures results in latency that is difficult to meet for
delay-sensitive services.
* Single-dimensional service identification: 6G scenarios impose
stringent requirements on network latency, bandwidth, reliability,
and emerging metrics such as computational capacity. Network
conditions and service requirements change dynamically in real
time. The current approach, which relies primarily on indirect
descriptions based on parameters such as GBR and QCI, cannot
directly, comprehensively, or precisely describe the
differentiated requirements of diverse scenarios.
* Coarse forwarding granularity: User-plane path construction relies
on parameters such as DNN and S-NSSAI at the PDU session level,
which prevents fine-grained differentiated forwarding for
individual data flows or specific types of sensing packets.
The 6G era introduces new services such as dynamic agent
collaboration, distributed AI inference, massive ISAC data ingestion,
full-network digital twinning, and industrial control. These
scenarios demand a forwarding plane that is inherently flexible,
maintains minimal state at intermediate nodes, and is capable of
binding transport behaviors to application-layer semantics. SRv6
meets these demands through its three programmable capabilities:
* Path Programmability: An ordered list of SIDs (Segment
Identifiers) in the SRH (Segment Routing Header) completely
specifies the end-to-end forwarding path. It supports dynamic
insertion or removal of transit nodes, primary/backup path
separation, and Fast Reroute without control-plane intervention.
Cheng & Zhang Expires 20 January 2027 [Page 3]
Internet-Draft SRv6，6G，UPF July 2026
* Service Programmability: Through IPv6/SRv6 extension headers, it
can carry QoS, slicing, bandwidth, and latency constraints to
achieve flow-granularity differentiated scheduling.
* Application Programmability: Through standardized fields carried
in SRv6 packets for application-specific identifiers (such as AI
compute load and application information), the forwarding plane is
enabled to sense and respond to application-layer semantics.
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
* GTP: GPRS Tunneling Protocol
* UPF: User Plane Function
* ISAC: Integrated Sensing and Communication
* NDT: Network Digital Twin
* QFI: QoS Flow Identifier
* DN: Data Network
2. Analysis of Typical 6G Scenarios and Corresponding Requirements
2.1. Multi-Agent Collaborative Communication
Distributed AI agents (such as autonomous fleet controllers,
federated learning worker nodes, and multi-robot coordination
systems) exchange high-frequency control messages and model gradient
data across geographically dispersed UPFs. These interactions
require low-jitter, highly reliable, and non-detoured mesh
connectivity. Agent members join and leave at sub-second timescales
based on task assignment and mobility, supporting real-time cross-
regional interaction and collaborative task scheduling among multiple
agents.
Key Service Requirements:
Cheng & Zhang Expires 20 January 2027 [Page 4]
Internet-Draft SRv6，6G，UPF July 2026
* Sub-second dynamic agent on-boarding and off-boarding, with no
interruption to ongoing PDU sessions during path changes.
* Dynamic insertion and deletion of multi-level intermediate
processing nodes (preprocessing, inference, aggregation) in
service chains.
* Differentiation between small control packets and large model
traffic flows, with independent queues and differentiated latency
guarantees for the two types of traffic.
* Support for mesh connectivity between any nodes across the entire
network, avoiding latency increases caused by cross-region routing
detours.
* Load balancing of massive concurrent service flows across equal-
cost links, with in-order packet delivery guaranteed for the same
conversation flow.
2.2. Compute-Network Integration (CNI)
Addressing the deployment of AI models at edge UPFs and multi-level
scheduling of wide-area KV Cache, this scenario supports high-speed
lossless migration of KV Cache data across edge UPFs and between
central cache nodes, ensuring continuous and imperceptible large-
model inference services during user mobility.
Key Service Requirements:
* Support for arbitrary mesh topology to enable high-speed lossless
migration of cache data across edge UPFs.
* Path planning must integrate multi-dimensional metrics including
compute load and storage utilization for joint scheduling.
* Service interruption duration during compute instance switching
must be controlled within 50ms.
* Stateful AI inference services must maintain the binding
relationship between data flows and local cache.Frequent switching
of compute nodes would incur cold-start penalties and
significantly increase inference latency.
Cheng & Zhang Expires 20 January 2027 [Page 5]
Internet-Draft SRv6，6G，UPF July 2026
2.3. Integrated Sensing and Communication (ISAC)
6G networks simultaneously possess both communication transmission
and environmental sensing capabilities, achieving deep integration of
communication and sensing to support scenarios such as vehicle-
infrastructure cooperation and security surveillance. Base stations
simultaneously complete communication transmission and environmental
sensing, with the user plane needing to carry Gbps-level point-cloud
data flows and millions of concurrent micro-sensing data packets
(such as radar point clouds, environmental fingerprints, LiDAR
returns). Packets are typically 100-300 bytes in size, with millions
of flows from densely deployed sensor arrays converging
simultaneously on the edge network. Massive sensing data and high-
value communication data are transmitted together, requiring that
important sensing flows receive deterministic quality assurance.
Key Service Requirements:
* Massive real-time sensing small packets of hundreds of bytes
require reduced encapsulation transmission overhead and improved
bandwidth utilization.
* Massive concurrent sensing flows require route aggregation to
reduce forwarding hardware FIB entry pressure.
* Resource isolation between high-priority radar/security sensing
flows and ordinary background sensing flows to avoid congestion
preemption.
* Real-time collection of end-to-end latency and packet loss metrics
for each sensing packet, with dynamic forwarding path adjustment
based on measurement results.
* Low-frequency raw point-cloud/radio-frequency large packets
require support for lossless fragmentation and transmission of
oversized packets.
2.4. Network Digital Twin (NDT)
Construct a digital mirror that maps the physical network in real
time, accurately restoring network state and maintaining a real-time
digital replica of the entire network, including all forwarding
nodes, links, and queues. All network nodes continuously report
latency, jitter, packet loss, queue depth, and utilization metrics to
the twin platform, supporting network simulation, fault prediction,
and closed-loop optimization.
Key Service Requirements:
Cheng & Zhang Expires 20 January 2027 [Page 6]
Internet-Draft SRv6，6G，UPF July 2026
* Telemetry measurement traffic must be completely isolated from
user production traffic, with no preemption of service bandwidth.
* Collected data must cover all forwarding hops, not just endpoints.
* Real measured values for per-hop latency, queue depth, and link
load must be obtainable, without reliance on estimated data.
* Support for on-demand adjustment of telemetry sampling frequency
and collection scope to balance measurement overhead and data
accuracy.
2.5. Wide-Area Deterministic Networking
Applications such as remote automated factory control, smart grid
protection relay signaling, autonomous vehicle platooning, and remote
surgery require stringent bounded latency (e.g., end-to-end < 10ms),
jitter < 1ms, packet loss rate < 10^-6, and sub-50ms automatic
failure recovery. Industrial control flows must pass through
security service nodes in sequence, such as "firewall → intrusion
detection → controller"; any detour or out-of-order delivery could
cause control logic errors.
Key Service Requirements:
* End-to-end latency, jitter, and packet loss rate must have
deterministic upper-bound constraints; optimizing only average
metrics is insufficient.
* Primary and backup paths must be physically link/node-disjoint to
avoid shared failure domains.
* Automatic link failure switching with service interruption
duration below 50ms.
* Industrial control flows must pass through security service nodes
such as firewall and intrusion detection in a fixed order; routing
detours that disrupt the processing sequence must be prevented.
* Dedicated end-to-end transmission resources must be reserved for
critical services to ensure highly reliable isolated transmission.
2.6. Scenario Requirements Summary
Synthesizing the above five categories of 6G key service scenarios,
six categories of user-plane general capability requirements can be
abstracted as the input baseline for the SRv6 capability analysis in
Section 4:
Cheng & Zhang Expires 20 January 2027 [Page 7]
Internet-Draft SRv6，6G，UPF July 2026
1. Dynamic Topology and Seamless Path Scheduling Support for dynamic
addition/removal of nodes/service chains, mesh connectivity, fast
failure self-healing, and long-duration interruption-free
mobility/compute switching.
2. Fine-Grained Differentiated QoS and Traffic Isolation
Differentiation between different types of data flows, allocation
of independent forwarding resources, and guaranteed prioritized
transmission for critical services.
3. Deterministic Reliable Forwarding and Physical Redundancy
Physically disjoint primary/backup paths, sub-50ms failure
switching, ordered service chains, and dedicated resource
reservation. Primarily targeting wide-area deterministic
communication, while also addressing vehicle-infrastructure
sensing and AI high-reliability interactive services.
4. Application Semantics In-Band Carriage The forwarding plane must
be able to recognize upper-layer service-specific identifiers
(cache affinity, compute requirements, sensing types, etc.) and
adjust forwarding policies based on application semantics.
5. Efficient Data Transmission and Large-Scale Flow Aggregation
Reduced header encapsulation overhead for small packets, and
convergence of forwarding table entries for massive concurrent
flows. Primarily adapting to ISAC scenarios while also
optimizing high-frequency control small packets for AI agents.
6. Full-Path Native Operations and Measurement Per-hop real-time
collection of network performance metrics, traffic isolation,
flexible sampling, supporting full-network digital twin
simulation and fault localization.
3. General Standardization Requirements
3.1. SRv6 Forwarding-Plane Existing Capability Mapping and 6G Extension
Requirements
This section, based on the six general 6G user-plane capability
dimensions summarized in Section 3, provides a unified summary of
SRv6's existing IETF-standardized native capabilities, and distills
the new standardization extension directions required for 6G
services.
Cheng & Zhang Expires 20 January 2027 [Page 8]
Internet-Draft SRv6，6G，UPF July 2026
3.1.1. Overall Adaptability Foundation of Existing SRv6 Capabilities
The existing SRv6 standards family (RFC8402, RFC8754, RFC8986,
RFC9800, etc.) has already formed a complete underlying forwarding
capability foundation that can cover the basic forwarding
requirements of 6G services:
Path Scheduling: Source routing via SR Policy enables explicit
definition of complete end-to-end forwarding paths; combined with TI-
LFA and BFD, it provides sub-50ms failure self-healing without
control-plane intervention; the Make-Before-Break (MBB) mechanism
ensures service continuity during path switching.
Service Chaining: SRv6 SFC supports sequential forwarding of service
flows through ordered service nodes.
Differentiated Scheduling: SRH extension TLVs and IPv6 extension
headers can carry basic QoS priority and latency constraints, with
differentiated SIDs enabling basic traffic queue isolation.
Overhead Optimization: The compressed SID scheme defined in RFC9800
reduces small-packet header overhead.
Application Carriage: SID Arguments and SRH TLVs reserve standardized
extension fields capable of carrying various upper-layer service
identifiers.
In-Band Measurement: IOAM measurement fields can be embedded in
packets to collect per-hop performance metrics such as latency and
queue load.
Deterministic Assurance: SR Policy supports binding bandwidth
reservation parameters, providing basic resource assurance for
deterministic services.
Mobility Interworking: RFC9433 defines End.M.GTP6.E/End.M.GTP6.D to
complete bidirectional encapsulation conversion between GTP and SRv6.
3.1.2. Unified 6G Full-Scenario Extension Requirements Summary
Building upon the existing standards foundation, to fully satisfy the
integrated service constraints of 6G scenarios such as dynamic AI
agents, compute-network integration, massive ISAC traffic, wide-area
industrial control, and full-network digital twins, a unified and
comprehensive set of SRv6 extension standardization specifications
needs to be perfected. The following dimensions can be considered:
Cheng & Zhang Expires 20 January 2027 [Page 9]
Internet-Draft SRv6，6G，UPF July 2026
Path Scheduling: A local SID segment update mechanism is needed to
enable dynamic forwarding path adjustment without requiring complete
PDU session re-establishment.
QoS and Resource Isolation: Unified binding rules between network
slicing and SR SIDs are needed, with dedicated endpoint forwarding
behaviors defined for industrial control, sensing, and AI inference
services to achieve hard resource isolation.
Application Semantics Carriage: Unified encoding specifications are
needed for service labels such as cache affinity, compute load, and
agent priority in SID Arguments or SRH TLVs, along with a control-
plane collaborative process that reads application semantics and
automatically selects optimal forwarding paths.
Deterministic Service Assurance: Support is needed for hard-
constraint assurance mechanisms for end-to-end latency, jitter, and
packet loss metrics.
3.2. Control-Plane Coordination and Orchestration
SRv6 path computation, SID allocation management, and policy mapping
rely on deep coordination between the core network control plane
(e.g., SMF, AMF) and the transport network control plane (e.g., SDN
controller, BGP route reflectors).
End-to-End Centralized Path Computation and Policy Download: The
control plane must be capable of collecting comprehensive network
state information—including UPF node status, link TE metrics, compute
load indicators, and available slice resources—and performing end-to-
end SRv6 path computation. The computed complete SID list, service
scheduling rules (FAR/PDR, etc.), and application extension
parameters (ARG/TLV) must be downloaded to the ingress UPF in a
single transaction using standard protocols (such as PCEP or BGP SR-
Policy). This ensures transactional consistency between path
selection and policy installation.
Dynamic Path Adjustment: During user mobility or compute node
migration, the control plane should support updating only the
affected portion of the SR path (e.g., replacing the middle SID
representing the serving UPF) without tearing down the entire SR
policy or interrupting online data flows. The update operation
should adopt a Make-Before-Break mechanism: the new SID list is
installed in hardware at the ingress UPF while the old list remains
active, with traffic switched only after the new path is verified
(e.g., via BFD).
Cheng & Zhang Expires 20 January 2027 [Page 10]
Internet-Draft SRv6，6G，UPF July 2026
SLA-to-SID Mapping: The control plane must map the 3GPP-defined 5QI/
QFI parameters to SRv6 TLV fields (latency, jitter, packet loss rate,
priority) or IPv6 extension headers. This mapping should be pre-
configured in the policy table at the ingress UPF to enable rapid
translation for each new flow without controller interaction. When
network SLA degrades (e.g., measured latency exceeds the target), the
control plane should support automatic path re-optimization triggered
by telemetry data, migrating affected flows to backup paths.
State Synchronization Between SMF and Transport Controller: The
Session Management Function (SMF) and the transport network
controller must synchronize state regarding active sessions and their
associated SID lists.
4. Security Considerations
The introduction of source routing (SRv6) in the 6G user plane raises
specific security concerns that must be addressed. These are
categorized below, with clear traceability to the requirements
defined in Section 4.
4.1. Path Spoofing and Traffic Hijacking
Since the path is encoded in the packet header, external attackers
could inject a forged SRH and malicious SID list to redirect traffic
to a rogue node or create loops in the network that consume
resources.
Every SRv6-capable UPF must validate that the packet source IPv6
address belongs to the allowed administrative domain (e.g., using
ingress ACLs that restrict source addresses to the operator's prefix
range). Additionally, the SRH should be protected by a cryptographic
signature or HMAC in the IPv6 extension header, with the signature
covering the SID list and critical TLV fields to prevent tampering.
4.2. SRH Integrity
Modifying QoS, compute load, or application-semantics ARG could allow
attackers to elevate service priority, misdirect traffic to congested
nodes, or degrade service quality. The control-plane protocol used
to download SID lists and TLVs must be secured with TLS, SSH, or
similar security protocols, with mutual authentication between the
controller and the UPF. This ensures that only authenticated
controllers can issue SID updates. At the forwarding plane, where
feasible, nodes should implement integrity verification of ARG and
critical TLV fields—either through per-hop verification (e.g., using
a shared secret to validate TLV checksums) or through cryptographic
protection of the entire SRH.
Cheng & Zhang Expires 20 January 2027 [Page 11]
Internet-Draft SRv6，6G，UPF July 2026
4.3. User Location Privacy
The SID list may inadvertently expose the precise location of a user-
plane endpoint, especially when the last segment is a UPF identifier
associated with a specific cell site or geographic region.
Edge aggregation nodes should strip or obfuscate terminal-specific
SIDs before the packet leaves the trusted administrative domain for
an external Data Network (DN). This should be achieved by replacing
the terminal-specific SID with a generic egress SID that does not
reveal location information, or by using privacy-preserving SIDs that
are periodically rotated. For flows that remain within the
operator's domain, location privacy may be protected through the use
of anonymized SIDs.
4.4. Control-Plane Security
The control plane (controller, PCE, SMF and other control plane
entities) is a critical component. An attacker compromising this
component could manipulate all forwarding policies. All control-
plane interactions—between PCE/SDN controller and UPFs, and between
SMF and transport controller—must use secure transport protocols
(e.g., TLS 1.3 or higher) with mutual authentication. Role-Based
Access Control (RBAC) should be enforced to restrict which entities
can modify SRv6 policies. Access logs should be maintained for all
policy changes to support forensic analysis in the event of security
incidents.
5. IANA Considerations
This document makes no requests for new IANA registrations.
6. References
6.1. Normative References
[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>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/rfc/rfc7855>.
Cheng & Zhang Expires 20 January 2027 [Page 12]
Internet-Draft SRv6，6G，UPF 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>.
[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>.
[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>.
6.2. Informative References
[I-D.draft-ietf-dmm-srv6mob-arch-03]
Kamata, T., Horn, J., Jalil, L., Cheng, W., and M. Kohno,
"Architecture Discussion on SRv6 Mobile User plane", Work
in Progress, Internet-Draft, draft-ietf-dmm-srv6mob-arch-
03, 25 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-
srv6mob-arch-03>.
Authors' Addresses
Weiqiang Cheng
China Mobile
China
Email: chengweiqiang@chinamobile.com
Xiaoqiu Zhang
China Mobile
China
Email: zhangxiaoqiu@chinamobile.com
Cheng & Zhang Expires 20 January 2027 [Page 13]