A Framework for SRv6-Based Trusted Key Relay in Quantum Key Distribution Networks
draft-chen-qirg-srv6-qkd-relay-framework-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 | Chenxinyu , Liuyan Han , Longfei Dai | ||
| Last updated | 2026-07-06 | ||
| 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-chen-qirg-srv6-qkd-relay-framework-00
QIRG X. Chen
Internet-Draft L. Han
Intended status: Informational China Mobile
Expires: 7 January 2027 L. Dai
Huawei Technologies
6 July 2026
A Framework for SRv6-Based Trusted Key Relay in Quantum Key Distribution
Networks
draft-chen-qirg-srv6-qkd-relay-framework-00
Abstract
Quantum Key Distribution (QKD) links generate symmetric key material
between directly connected QKD nodes. Trusted relay is commonly used
to extend key delivery beyond the reach of a single QKD link. A
complete trusted-relay service requires the network to collect QKD
link capacity and node trust information, compute a relay path
according to service requirements, translate the result into an SRv6
path, and carry the relayed key information in an IPv6/UDP packet
steered by that SRv6 path.
This document describes an architectural framework for such a
service. Each QKD link provides its available quantum key rate
capacity, and each relay node provides a trust level. A controller
uses these inputs together with application requirements to calculate
a relay path. The path-computation algorithm is not standardized and
may be selected or defined by the user, operator, or implementation.
The calculated relay sequence is represented as an SRv6 path, and UDP
packets following that path carry the key-relay information.
This document identifies the protocol extension points needed to
support the framework. The detailed encodings, message formats, SRv6
behaviors, TLVs, and signaling procedures are left for future work
and are marked as TBD.
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/.
Chen, et al. Expires 7 January 2027 [Page 1]
Internet-Draft SRv6 QKD Relay Framework July 2026
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 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 (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 . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Framework Overview . . . . . . . . . . . . . . . . . . . . . 6
4.1. Functional Components . . . . . . . . . . . . . . . . . . 6
4.2. Information Flow . . . . . . . . . . . . . . . . . . . . 7
5. Path-Computation Inputs . . . . . . . . . . . . . . . . . . . 8
5.1. Quantum Key Rate Capacity . . . . . . . . . . . . . . . . 8
5.2. Node Trust Level . . . . . . . . . . . . . . . . . . . . 9
5.3. Service Requirements . . . . . . . . . . . . . . . . . . 9
6. Path Computation . . . . . . . . . . . . . . . . . . . . . . 10
6.1. General Requirements . . . . . . . . . . . . . . . . . . 10
6.2. User-Defined Algorithms . . . . . . . . . . . . . . . . . 10
6.3. Path Output . . . . . . . . . . . . . . . . . . . . . . . 11
7. SRv6-Based Key Relay . . . . . . . . . . . . . . . . . . . . 11
7.1. SRv6 Path Representation . . . . . . . . . . . . . . . . 11
7.2. UDP-Based Key Relay . . . . . . . . . . . . . . . . . . . 12
7.3. Processing at Trusted Relay Nodes . . . . . . . . . . . . 12
8. Protocol Extension Requirements . . . . . . . . . . . . . . . 13
8.1. QKD Link Capacity Advertisement . . . . . . . . . . . . . 13
8.2. Node Trust Advertisement . . . . . . . . . . . . . . . . 14
8.3. SRv6 Path Installation . . . . . . . . . . . . . . . . . 14
8.4. SRv6 Service Identification . . . . . . . . . . . . . . . 15
Chen, et al. Expires 7 January 2027 [Page 2]
Internet-Draft SRv6 QKD Relay Framework July 2026
8.5. Key-Relay Context in SRv6 Packets . . . . . . . . . . . . 15
8.6. UDP Key-Relay Message . . . . . . . . . . . . . . . . . . 15
8.7. Acknowledgment and Error Handling . . . . . . . . . . . . 16
9. Operational Considerations . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Manageability Considerations . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Normative References . . . . . . . . . . . . . . . . . . . . 19
14. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Example Service Procedure . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
Quantum Key Distribution provides a method for generating shared
symmetric keys between two QKD systems. The physical distance of a
single QKD link is limited by optical attenuation, noise, equipment
capability, and deployment conditions. Large-scale QKD networks
therefore commonly use trusted relay nodes to deliver key material
across multiple QKD links.
Trusted relay is not only a key-management function. It also
requires a network path that selects the correct relay nodes in the
correct order. The path should take into account at least two QKD-
specific properties:
* the quantum key rate capacity available on each QKD link; and
* the trust level of each node that may process the relayed key.
After the path is calculated, the network must enforce the selected
relay sequence and carry the key-relay information between the nodes.
This document uses SRv6 as the path-steering mechanism and UDP as the
transport for the key-relay information.
The framework is intended to connect four previously separated
functions:
* QKD resource and trust information collection;
* service-driven path computation;
* SRv6 path generation and installation; and
* hop-by-hop trusted key relay using SRv6-steered UDP packets.
Chen, et al. Expires 7 January 2027 [Page 3]
Internet-Draft SRv6 QKD Relay Framework July 2026
This document focuses on the architecture and protocol requirements.
It does not define detailed wire formats or a mandatory path-
computation algorithm.
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. Scope
This document specifies an architectural framework in which:
* each QKD link provides quantum key rate capacity information;
* each QKD node provides node trust information;
* a controller computes a relay path according to service
requirements;
* the path-computation algorithm may be defined by the operator,
user, or implementation;
* the controller translates the selected relay sequence into an SRv6
path;
* SRv6 steers UDP packets through the selected trusted relay nodes;
and
* the UDP payload carries the key-relay information required by the
trusted relay process.
The following items are outside the scope of this document:
* the detailed algorithm used for path computation;
* the detailed protocol encoding used to advertise QKD link
capacity;
* the detailed protocol encoding used to advertise node trust
levels;
* the detailed SRv6 endpoint behavior or SRH extension;
* the detailed UDP message format;
Chen, et al. Expires 7 January 2027 [Page 4]
Internet-Draft SRv6 QKD Relay Framework July 2026
* the cryptographic protection format for the UDP payload;
* the local interface between the relay function and the QKD key
management system; and
* multi-path key splitting and reconstruction.
All such protocol details are left as TBD.
2. Terminology
QKD Link
A communication relationship between two directly connected QKD
nodes that can generate shared key material.
QKD Node
A network node containing, or connected to, QKD key-generation and
key-management functions.
Trusted Relay Node
A QKD node authorized to receive, process, and forward relayed key
information.
Quantum Key Rate Capacity
A metric describing the amount or rate of QKD-generated key
material that a QKD link can provide for a key-relay service.
Node Trust Level
A metric describing the trustworthiness of a QKD node according to
the operator's security policy.
Service Requirement
A set of constraints associated with a key-relay request, such as
requested key rate, minimum node trust level, maximum number of
relays, latency, administrative policy, and protection
requirements.
QKD Controller
A control function that collects QKD topology information,
receives service requirements, computes a trusted relay path, and
installs the corresponding SRv6 path.
SRv6 Path
An ordered SRv6 segment list used to steer a key-relay packet
through the selected trusted relay nodes.
Chen, et al. Expires 7 January 2027 [Page 5]
Internet-Draft SRv6 QKD Relay Framework July 2026
Key-Relay Packet
An IPv6 packet containing an SRv6 path and a UDP payload carrying
key-relay information.
3. Problem Statement
A conventional IP path is selected mainly according to reachability
and network metrics. Such a path may not be suitable for QKD key
relay because it does not necessarily consider QKD key availability
or node trustworthiness.
For example, the shortest IP path may traverse:
* a QKD link that currently provides insufficient key rate;
* a relay node whose trust level is below the requirement of the
application;
* a node that has no QKD relay capability; or
* a relay sequence different from the sequence selected by the QKD
controller.
A QKD relay service therefore needs a mechanism that connects path
computation with packet forwarding. The controller first selects a
relay path based on QKD-specific inputs and service requirements. It
then expresses that path as an SRv6 segment list so that key-relay
packets visit the selected relay nodes in the selected order.
The key-relay information is carried in the UDP payload. Each
trusted relay node processes the received information and forwards a
new or updated UDP packet toward the next relay according to the SRv6
path.
4. Framework Overview
4.1. Functional Components
The framework contains the following logical components:
Chen, et al. Expires 7 January 2027 [Page 6]
Internet-Draft SRv6 QKD Relay Framework July 2026
+--------------------+ resource and trust +-------------+
| QKD Links and | ----------------------------> | |
| QKD Relay Nodes | | |
+--------------------+ | |
| QKD |
+--------------------+ service request | Controller |
| Application or KME | ----------------------------> | |
+--------------------+ | |
+------+------+
path install |
+----------------------------------------------------+
|
v
+---------+ +-----------+ +-----------+ +---------+
| Source |----->| Relay R1 |----->| Relay R2 |----->| Dest. |
| QKD/KME | | SRv6/QKD | | SRv6/QKD | | QKD/KME |
+---------+ +-----------+ +-----------+ +---------+
SRv6-steered IPv6/UDP key-relay packets
Figure 1: SRv6-Based QKD Trusted Relay Framework
The components may be implemented in separate physical devices or
combined in one device. For example, an SRv6 router and a QKD key
management entity may be integrated or connected through a protected
local interface.
4.2. Information Flow
The general information flow is:
1. QKD links provide their quantum key rate capacity to the control
system.
2. QKD relay nodes provide their node trust levels and relay
capabilities to the control system.
3. An application or key-management entity sends a key-relay
service request to the QKD controller.
4. The controller combines the QKD topology information with the
service requirements.
5. The controller runs a path-computation algorithm selected by the
user, operator, or implementation.
6. The controller generates an ordered relay-node sequence.
Chen, et al. Expires 7 January 2027 [Page 7]
Internet-Draft SRv6 QKD Relay Framework July 2026
7. The controller translates the relay-node sequence into an SRv6
path.
8. The controller installs the SRv6 path and any required relay
state.
9. The source sends a UDP key-relay packet along the SRv6 path.
10. Each trusted relay node processes the key-relay information and
forwards the packet toward the next relay.
11. The destination accepts the delivered key information and may
return an acknowledgment.
5. Path-Computation Inputs
5.1. Quantum Key Rate Capacity
Quantum Key Rate Capacity, referred to as QKRC in this document, is a
metric describing the QKD key-generation resource associated with a
QKD link.
The value SHOULD represent the amount of key material that can be
made available to new key-relay services. Depending on the
implementation, it may represent:
* a nominal key-generation rate;
* a currently available key-generation rate;
* an available amount of key material in a key pool;
* a combination of current rate and stored key amount; or
* another operator-defined capacity metric.
The exact capacity model is deployment specific. A controller MUST
understand the semantics of the value before using it for path
computation.
A QKD link with no usable key-generation capability MUST NOT be
selected for a new key-relay path.
The protocol used to advertise QKRC and its detailed encoding are
TBD.
Chen, et al. Expires 7 January 2027 [Page 8]
Internet-Draft SRv6 QKD Relay Framework July 2026
5.2. Node Trust Level
Node Trust Level, referred to as NTL in this document, is a policy-
defined metric representing the degree of trust assigned to a QKD
relay node.
An implementation may use a five-level model such as:
Level 1
Minimal trust.
Level 2
Basic operational trust.
Level 3
Moderate trust with controlled physical and management access.
Level 4
High trust with enhanced hardware and operational protection.
Level 5
Maximum trust under the operator's assurance policy.
The specific criteria associated with each level are defined by the
operator, user, or applicable assurance framework. Trust levels from
different administrative or assurance domains may not be directly
comparable.
A service may require that every selected trusted relay node meet a
minimum NTL.
The protocol used to advertise NTL and its detailed encoding are TBD.
5.3. Service Requirements
A key-relay request may contain one or more of the following
requirements:
* source QKD node or source KME;
* destination QKD node or destination KME;
* requested key rate;
* requested key amount;
* minimum node trust level;
Chen, et al. Expires 7 January 2027 [Page 9]
Internet-Draft SRv6 QKD Relay Framework July 2026
* maximum number of trusted relay nodes;
* maximum latency;
* administrative inclusion or exclusion policy;
* path diversity or protection requirement;
* service priority; and
* service lifetime.
The exact service-request interface and message format are TBD.
6. Path Computation
6.1. General Requirements
The controller uses the QKD topology information and service
requirements to select a trusted relay path.
A valid path SHOULD satisfy all mandatory service constraints. At a
minimum, the controller SHOULD verify that:
* consecutive relay nodes are connected by usable QKD links;
* selected QKD links provide sufficient quantum key rate capacity;
* selected relay nodes satisfy the required node trust level;
* selected relay nodes support the required trusted relay function;
and
* the selected relay sequence can be represented and installed as an
SRv6 path.
The controller MAY consider additional information, including IP
transport cost, link latency, key-pool status, network congestion,
failure risk, administrative boundaries, or protection policy.
6.2. User-Defined Algorithms
This document does not define or require a specific path-computation
algorithm.
The algorithm MAY be:
* selected by the operator;
Chen, et al. Expires 7 January 2027 [Page 10]
Internet-Draft SRv6 QKD Relay Framework July 2026
* configured by the user;
* implemented as a shortest-path or constrained shortest-path
algorithm;
* implemented as a multi-objective optimization algorithm;
* based on policy rules;
* based on real-time measurements; or
* implemented using another vendor-specific or application-specific
method.
Different algorithms may produce different valid paths for the same
input. Such differences do not affect protocol interoperability,
provided that the resulting relay path can be represented as an SRv6
path and installed consistently at the participating nodes.
6.3. Path Output
The output of path computation is an ordered sequence of trusted
relay nodes from the source to the destination.
The controller maps each relay node to an SRv6 segment or SRv6
service instruction. The resulting SRv6 path MUST preserve the relay
order selected by the path-computation function.
The detailed mapping between a trusted relay node and an SRv6 SID is
TBD.
The controller MAY also insert transport-related segments when needed
to constrain the classical IP path between two trusted relay nodes.
The detailed rules are TBD.
7. SRv6-Based Key Relay
7.1. SRv6 Path Representation
SRv6 provides an ordered list of network instructions that can be
carried in an IPv6 packet. In this framework, the SRv6 path
represents the ordered trusted relay sequence selected by the
controller.
Each trusted relay node SHOULD be explicitly represented in the SRv6
path. This ensures that the key-relay packet is processed by all
selected relay nodes in the required order.
Chen, et al. Expires 7 January 2027 [Page 11]
Internet-Draft SRv6 QKD Relay Framework July 2026
The framework may require one or more SRv6 extensions to identify a
QKD trusted relay function or to associate an SRv6 SID with a local
key-relay service.
The specific SRv6 endpoint behavior, SID format, signaling method,
and processing rules are TBD.
7.2. UDP-Based Key Relay
The SRv6 packet carries a UDP datagram. The UDP payload carries the
information required by the trusted key-relay process.
The UDP payload may need to contain information such as:
* key-relay service identifier;
* relay session identifier;
* source and destination KME identifiers;
* key identifier;
* protected key material;
* sequence information;
* relay-hop information;
* lifetime information;
* acknowledgment indication; and
* error information.
This list identifies functional requirements only. It does not
define a wire format.
The UDP port, message types, field encoding, cryptographic container,
and message-protection mechanism are TBD.
7.3. Processing at Trusted Relay Nodes
When a key-relay packet reaches a trusted relay node, the node
performs the trusted relay function associated with that SRv6
processing point.
The logical processing includes:
Chen, et al. Expires 7 January 2027 [Page 12]
Internet-Draft SRv6 QKD Relay Framework July 2026
1. Verify that the packet belongs to an authorized key-relay
service.
2. Verify that the packet follows an installed and valid relay path.
3. Deliver the UDP key-relay information to the local QKD relay or
KME function.
4. Process the received key information according to the trusted
relay policy.
5. Obtain any key material required to protect the next relay hop.
6. Generate or update the UDP key-relay information for the next
node.
7. Continue forwarding according to the SRv6 path.
At the destination, the key information is delivered to the
destination KME or application.
The exact packet-processing behavior and the division of functions
between the SRv6 node and the KME are TBD.
8. Protocol Extension Requirements
This section identifies the protocol areas that require extension.
Only the extension objectives are defined. All detailed formats and
procedures are TBD.
8.1. QKD Link Capacity Advertisement
A protocol extension is required to advertise the quantum key rate
capacity of each QKD link to the controller.
The extension SHOULD support:
* identification of the associated QKD link;
* representation of QKRC;
* indication of link availability;
* dynamic update of the value;
* withdrawal or expiration of stale information; and
* integrity protection of the advertised information.
Chen, et al. Expires 7 January 2027 [Page 13]
Internet-Draft SRv6 QKD Relay Framework July 2026
The protocol selected for carrying this information and the detailed
extension format are TBD.
Possible protocol families may include a link-state routing protocol,
BGP-LS, a management protocol, or a controller-specific interface.
No specific choice is made in this document.
8.2. Node Trust Advertisement
A protocol extension is required to advertise the trust level and QKD
relay capability of each node.
The extension SHOULD support:
* node identification;
* node trust level;
* trust or assurance domain;
* indication of trusted relay capability;
* validity or freshness information; and
* withdrawal or downgrade after a security event.
The protocol selected for carrying this information and the detailed
extension format are TBD.
8.3. SRv6 Path Installation
A mechanism is required for the controller to install the calculated
SRv6 path at the source and, when necessary, at the trusted relay
nodes.
The mechanism SHOULD support:
* installation of an ordered segment list;
* association of the segment list with a QKD relay service;
* activation and deactivation of a path;
* replacement of an old path by a new path;
* installation of a reverse or protection path when required; and
* consistent lifecycle management of path and relay state.
Chen, et al. Expires 7 January 2027 [Page 14]
Internet-Draft SRv6 QKD Relay Framework July 2026
The use of an existing SR Policy mechanism or another controller-to-
device protocol is possible. The selected mechanism and any required
extension are TBD.
8.4. SRv6 Service Identification
An SRv6 extension may be required to identify that a segment invokes
a QKD trusted relay function.
The extension may be realized by a dedicated SRv6 endpoint behavior,
a service SID, an argument carried in a SID, a policy association, or
another SRv6 mechanism.
The selected mechanism, code point, SID structure, and processing
behavior are TBD.
8.5. Key-Relay Context in SRv6 Packets
The key-relay packet may require non-secret context that is visible
to the SRv6 and relay-processing functions.
Such context may include:
* service identifier;
* session identifier;
* path identifier;
* relay count;
* minimum required trust level; and
* processing flags.
The context may be carried in an SRH TLV, another IPv6 extension, the
UDP payload, or local policy state.
The selected location, encoding, mutability rules, and protection
method are TBD.
Key material itself SHOULD NOT be carried in an unprotected SRv6 or
IPv6 header field.
8.6. UDP Key-Relay Message
A UDP-based protocol extension or new protocol is required to carry
the key-relay information.
Chen, et al. Expires 7 January 2027 [Page 15]
Internet-Draft SRv6 QKD Relay Framework July 2026
The protocol SHOULD support:
* transfer of protected key material;
* service and session identification;
* source and destination identification;
* sequencing and duplicate detection;
* relay-hop processing;
* lifetime control;
* acknowledgment;
* error reporting; and
* cryptographic protection.
The UDP port, versioning model, common header, payload encoding, key-
protection method, and algorithm negotiation are TBD.
8.7. Acknowledgment and Error Handling
A key-relay service may require confirmation that the destination has
accepted the relayed key.
The framework therefore requires a mechanism for:
* successful delivery acknowledgment;
* relay-processing failure notification;
* path or session mismatch notification;
* insufficient QKD resource notification;
* retransmission or status query; and
* duplicate-safe delivery.
The message types, timers, retry rules, state machine, and error
codes are TBD.
Chen, et al. Expires 7 January 2027 [Page 16]
Internet-Draft SRv6 QKD Relay Framework July 2026
9. Operational Considerations
QKD link capacity and node trust information may change over time. A
controller SHOULD use sufficiently fresh information when admitting a
new key-relay service.
A controller SHOULD coordinate the following operations:
* collection of QKD resource and trust information;
* path computation;
* QKD resource reservation, when supported;
* SRv6 path installation;
* relay-state installation;
* source activation;
* path update or protection switching; and
* resource and state release.
When the relay path changes, the controller SHOULD ensure that
packets associated with the old path are not incorrectly processed on
the new path.
The specific reservation, transaction, and make-before-break
procedures are TBD.
10. Security Considerations
Trusted Relay Model
Every trusted relay node may obtain access to the relayed key
information. The security of the end-to-end service therefore
depends on every selected relay node. A node trust level is a
policy input and does not eliminate the inherent trusted-relay
risk.
Integrity of Path-Computation Inputs
An attacker that changes QKRC or NTL information may cause the
controller to select an exhausted, unavailable, or insufficiently
trusted path. The mechanisms used to distribute these values MUST
provide authentication and integrity protection. The detailed
mechanism is TBD.
Chen, et al. Expires 7 January 2027 [Page 17]
Internet-Draft SRv6 QKD Relay Framework July 2026
Authorization of SRv6 Paths
An attacker MUST NOT be able to create an unauthorized SRv6 path
that invokes the trusted relay function. SRv6 ingress filtering,
policy authorization, and path validation SHOULD be used. Any
additional mechanism is TBD.
Protection of Key Material
Key material carried in the UDP payload MUST be protected against
disclosure and modification. The detailed encryption,
authentication, key-identification, and nonce-handling mechanisms
are TBD.
Binding to the Selected Path
A key-relay message SHOULD be bound to the intended service,
session, and relay path so that it cannot be moved to a different
path or replayed in a different context. The detailed binding
mechanism is TBD.
Replay and Duplicate Delivery
The key-relay protocol MUST provide replay protection and
duplicate-safe processing. The detailed sequence-number and
state-management procedures are TBD.
Relay Node Protection
A relay node SHOULD process plaintext key information only inside
a protected execution and storage environment. The implementation
SHOULD minimize the lifetime of plaintext key material.
Denial of Service
SRv6 and UDP processing may expose relay nodes and KMEs to
resource-exhaustion attacks. Implementations SHOULD use
filtering, rate limiting, bounded state, and authorization checks.
Metadata Exposure
An SRv6 path may reveal the trusted relay sequence, and visible
context may reveal that a QKD key-relay service is active.
Operators SHOULD evaluate whether additional tunnel or metadata-
protection mechanisms are required.
11. Manageability Considerations
An implementation SHOULD provide management and telemetry for:
* QKD link capacity and availability;
* node trust level and its validity;
* active key-relay service requests;
Chen, et al. Expires 7 January 2027 [Page 18]
Internet-Draft SRv6 QKD Relay Framework July 2026
* calculated relay paths;
* installed SRv6 policies;
* active relay sessions;
* key-relay packet counts;
* successful and failed key deliveries;
* path changes and protection events; and
* security and policy failures.
Management systems MUST NOT expose plaintext key material or QKD link
keys in logs, telemetry, alarms, or diagnostic output.
The detailed YANG models, telemetry models, and management interfaces
are TBD.
12. IANA Considerations
This document makes no IANA requests.
Future documents that define the protocol extensions identified in
Section 8 may request allocations for SRv6 endpoint behaviors, SRH
TLVs, routing-protocol TLVs, UDP service names or port numbers,
message types, error codes, or other protocol parameters.
13. 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/info/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/info/rfc8174>.
[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/info/rfc8200>.
Chen, et al. Expires 7 January 2027 [Page 19]
Internet-Draft SRv6 QKD Relay Framework July 2026
[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>.
[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>.
14. Informative References
[ETSI-QKD014]
ETSI, "Quantum Key Distribution (QKD); Protocol and data
format of REST-based key delivery API", ETSI GS QKD 014.
[ITU-Y3800]
ITU-T, "Overview on networks supporting quantum key
distribution", Recommendation Y.3800, October 2019.
[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>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
Appendix A. Example Service Procedure
This appendix provides a non-normative example.
Assume the following relay topology:
Source S ---- Relay R1 ---- Relay R2 ---- Destination D
Figure 2: Example Relay Topology
Each QKD link reports its available quantum key rate capacity. R1
and R2 report their node trust levels.
An application requests a key-relay service from S to D with:
* a required key rate;
Chen, et al. Expires 7 January 2027 [Page 20]
Internet-Draft SRv6 QKD Relay Framework July 2026
* a minimum node trust level; and
* a maximum number of relay nodes.
The controller performs the following actions:
1. Collect the current QKD link capacity and node trust
information.
2. Invoke a path-computation algorithm selected by the user or
operator.
3. Select the ordered relay sequence S-R1-R2-D.
4. Translate R1, R2, and D into an SRv6 segment list.
5. Install the SRv6 path and any required relay state.
6. Instruct S to send a UDP key-relay packet.
7. R1 processes the key-relay information and forwards it toward
R2.
8. R2 processes the key-relay information and forwards it toward D.
9. D accepts the delivered key information.
10. D may send an acknowledgment to S.
The detailed routing-protocol extensions, SRv6 behavior, packet
formats, state machine, and cryptographic processing are all TBD.
Authors' Addresses
Xinyu Chen
China Mobile
Email: chenxinyuyjy@chinamobile.com
Liuyan Han
China Mobile
Email: hanliuyan@chinamobile.com
Longfei Dai
Huawei Technologies
Email: larry.dai@huawei.com
Chen, et al. Expires 7 January 2027 [Page 21]