| Internet-Draft | Extensions to IS-IS for Advertising Quan | November 2026 |
| Zhang, et al. | Expires 6 May 2027 | [Page] |
Quantum Key Distribution (QKD) provides a method for generating shared symmetric keys between two QKD systems. Large-scale QKD networks commonly use trusted relay nodes to deliver key material across multiple QKD links.¶
to steer key-relay traffic through a sequence of trusted relay nodes. A critical prerequisite for this approach is the ability of collecting the QKD capability of the nodes and links in the network.¶
This document extends IS-IS by defining a new Application ID for QKD relay information within the GENINFO TLV [RFC6823]. This extension allows nodes to advertise their QKD relay informations and then collected by the QKD controller for QKD relay path calculation.¶
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 6 May 2027.¶
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.¶
Quantum Key Distribution (QKD) 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 requires a network path that selects the correct relay nodes in the correct order.¶
[I-D.chen-qirg-srv6-qkd-relay-framework] provides an Segment Routing over IPv6 (SRv6) based QKD trusted relay framework, which leverages SRv6 to steer key-relay traffic through a sequence of trusted relay nodes. It uses a QKD controller to calculate the trusted relay paths upon receiving a request. A critical prerequisite for this approach is the ability for the QKD controller to efficiently and dynamically collect the QKD capability of the nodes and links in the network.¶
The IS-IS routing protocol, widely deployed in live networks, offers a robust and scalable foundation for the collection of QKD related information. [RFC6823] extends IS-IS to advertise generic application information that are not directly related to the operation of the IS-IS protocol.¶
This document extends IS-IS by defining a new Application ID for QKD relay information within the GENINFO TLV [RFC6823]. This extension allows nodes to advertise their QKD relay informations and then collected by the QKD controller for QKD relay path calculation.¶
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.¶
This document uses terminology from [RFC6823] and [I-D.chen-qirg-srv6-qkd-relay-framework].¶
The framework specified in [I-D.chen-qirg-srv6-qkd-relay-framework] is illustrated in Figure 1, consists of the following logical components:¶
QKD Relay Node: A network node containing, or connected to, QKD key-generation and key-management functions, and are authorized to receive, process, and forward relayed key information.¶
QKD Link: A communication relationship between two directly connected QKD nodes that can generate shared key material.¶
QKD Controller: A control function that collects QKD topology information, receives service requirements, computes a trusted relay path, and installs the corresponding SRv6 path.¶
Application or KME: A trusted entity that sends QKD relay service request to QKD Controller.¶
Source/Destination QKD KME: The endpoints of the key-relay service.¶
+--------------------+
| Application or KME |
+--------------------+
|
Service Request |
|
v
+--------------------------------------------------------------+
| QKD Controller |
+--------------------------------------------------------------+
^ ^ ^ ^ |
| | | | |
| | QKD | | |SRv6-based QKD
| | Capability | | |Relay Path
| | Collection | | |Installation
| | | | |
| | | | v
+-------+ +-------+ +-------+ +-------+
| QKD |<-------->| QKD |<-------->| QKD |<-------->| QKD |
| Node | QKD Link | Node | QKD Link | Node | QKD Link | Node |
| (Dst) | | | | | | (Src) |
+-------+ +-------+ +-------+ +-------+
<------------SRv6 Based Key Relay ---------------------
The general information flow in this framework is as follows:¶
QKC Resource Collection: QKD links provides their Quantum Key Generation Rate (QKGR) to the QKD controller, and QKD nodes provides their Node and relay capabilities to the QKD controller.¶
Service Request: An application or KME sends a key-relay service request (e.g., source, destination, required key rate) to the QKD Controller.¶
Path Computation: The QKD controller combines the collected QKD topology information (from step 1) with the service requirements (from step 2). It runs a path-computation algorithm to select an ordered sequence of trusted relay nodes that meets the requirements.¶
Path Translation and Installation: The controller translates the selected relay-node sequence into an SRv6 segment list and installs the SRv6 path to the source node.¶
Key Relay: The source sends a UDP key-relay packet along the SRv6 path. Each trusted relay node processes the key-relay information, performs the required relay operation, and forwards the packet toward the next hop as dictated by the SRv6 path.¶
Since IS-IS has been widely deployed in live networks, and existing extensions allow it to advertise generic application information that are not directly related to the operation of the IS-IS protocol. Therefore, IS-IS can be extended for the collection of QKD related information from the QKD links and QKD relay nodes.¶
The detailed QKD related information that need to be collected includes:¶
Router's QKD relay capability: including their Key Manager Identifier (KM-ID) which uniqualy identifies a router with QKD relay capability.¶
Key Manager IP addresses(KM-IP) of routers support QKD relay capability, which are used as the input for the QKD controller to calculate the QKD relay paths, and forms QKD relay paths.¶
QKGR of QKD links: QKGR is a value generated by a QKD-enabled router through the negotiation with its QKD relay neighbors. The QKD controller uses the QKGR as a path selection constraint to calculate the QKD relay path.¶
As defined in [RFC6823], the GENINFO TLV (Type 251) is used to advertise application-specific information.¶
This document requests to allocate a new Application ID (TBD1, 101 is recommended) for QKD-related information.¶
The GENINFO TLV includes a Additional Application-Specific Information field, which can be used to carry application-specific sub-TLVs. This document defines two new sub-TLVs for QKD-specific information.¶
This Sub-TLV identifies the advertising node as a QKD Key Manager (KM) and provides its unique identifier. The format of this sub-TLV is shown as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KM-ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / optional sub-sub-TLVs... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1, 1 octet.¶
Length: 1 octet. The value MUST be 10 plus the total length of included sub-sub-TLVs.¶
Flags: 2 octets. No flags are currently defined. The sender MUST set this field to 0. The receiver MUST ignore this field.¶
KM-ID: 8 octets. An identifier that MUST be unique within the IS-IS domain.¶
A router SHOULD originate at most one QKD Capabilities Sub-TLV. This Sub-TLV MAY be present in any LSP fragment.¶
If multiple QKD Capabilities Sub-TLVs are received from the same router, only the first occurrence in the smallest fragment number is considered valid. Subsequent occurrences MUST be ignored.¶
This sub-sub-TLV carries the IP address of the Key Manager.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | KM-IP | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1, 1 octet.¶
Length: 1 octet. The value is 1 plus the length of the KM-IP address (4 for IPv4, 16 for IPv6).¶
Flags: 1 octets. Only one flag is defined currently, the reserved bits in the Flags field MUST be set to 0 by the sender and ignored by the receiver.¶
~~~ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |F| +-+-+-+-+-+-+-+-+ ~~~¶
- F Flag (Address Family Flag): If unset (0), the KM-IP is an IPv4 address. If set (1), the KM-IP is an IPv6 address.¶
KM-IP: Variable length. 4 octets for IPv4, 16 octets for IPv6.¶
IS-IS do not performs validation on the KM-IP format, it just passes transparently to the QKD controller.¶
At least one QKD KM-IP sub-sub-TLV SHOULD be included in the QKD Capability sub-TLV. If none is present, the entire QKD Capabilities Sub-TLV MUST be ignored.¶
This Sub-TLV describes the QKD capabilities of a specific point-to-point (P2P) link, which is a key input for QKD relay path computation.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System ID and pseudonode number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Link Local/Remote Identifiers sub-TLV / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / optional sub-sub-TLVs... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1 octet, the value of it is 2.¶
Length: 1 octet. The value MUST be 19 plus the total length of any included sub-sub-TLVs. If the Length does not satisfy this requirement, the receiver MUST ignore the Sub-TLV.¶
System ID and Pseudonode Number: 7 octets. it identifies the neighbor node of the link.¶
Link Local/Remote Identifiers Sub-TLV: 10 octets, as defined in [RFC5307], it is used to identify the physical interface.¶
Flags: 2 octets. No flags are currently defined. The sender MUST set this field to 0. The receiver MUST ignore this field.¶
A single link MAY have multiple QKD Link Capabilities Sub-TLVs (e.g., due to fragmentation). When a router receives multiple QKD Link Capabilities Sub-TLVs, it SHOULD merge all the non-conflicting attributes.¶
This optional sub-sub-TLV advertises the QKGR for a link.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length=6 | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QKD Key Generate Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1 octet, the value of it is 1.¶
Length: 1 octet, the value of it is 6.¶
RESERVED: 2 octets. Must be set to 0 by the sender and ignored by the receiver.¶
QKD Key Generate Rate: 4 octets. Unsigned integer. The unit is kilobits per second (kbps), representing the number of bits of QKD keys that can be generated per second.¶
A single link (identified by its local/remote identifiers) MUST have at most one QKD Generate Rate sub-sub-TLV across all fragments. If multiple QKD Generate Rate sub-sub-TLV are received from the same neighbor for the same link, only the first occurrence in the smallest fragment number is considered valid.¶
To reduce flooding overhead, updates to the QKD Generate Rate MAY be suppressed by a local configured suppression period.¶
This document defines new extensions that are fully backward compatible with existing IS-IS implementations.¶
Per [RFC6823], routers that do not support the new GENINFO Application ID (TBA1) will silently ignore the entire GENINFO TLV containing it. No error messages or routing disruptions will occur.¶
Therefore, these extensions are transparent to legacy routers. Operators can deploy QKD-capable nodes incrementally without affecting the stability of the existing IS-IS domain.¶
This document requests allocation for the following values, sub-TLVs, and sub-sub-TLVs by updating the existing registries and defining new registries under the "IS-IS TLV Codepoints" grouping.¶
IANA is requested to assign a value from the "GENINFO Application IDs" registry [RFC6823]:¶
| Value | Description | Reference |
|---|---|---|
| TBA1 | Quantum Key Distribution (QKD) | This document |
IANA is requested to create a new registry called "QKD Sub-TLVs" under GENINFO Application ID TBA1 specified in this document Section 3".¶
The registration procedure is "Expert Review", as defined in [RFC8126]. Guidance for the designated experts is provided in [RFC7370]. The following assignments are made by this document:¶
| Value | Description | Reference |
|---|---|---|
| 1 | QKD Capabilities | This document |
| 2 | QKD Link Capabilities | This document |
| 3-255 | Unassigned |
IAIA is requested to create a new registries under the "QKD Capability Sub-TLV registry.¶
The registration procedure is "Expert Review", as defined in [RFC8126]. Guidance for the designated experts is provided in [RFC7370]. The following assignments are made by this document:¶
| Value | Description | Reference |
|---|---|---|
| 1 | QKD KM-IP | This document |
| 2-255 | Unassigned |
IAIA is requested to create a new registries under the "QKD Link Capability Sub-TLV registry.¶
The registration procedure is "Expert Review", as defined in [RFC8126]. Guidance for the designated experts is provided in [RFC7370]. The following assignments are made by this document:¶
| Value | Description | Reference |
|---|---|---|
| 1 | QKD Generate Rate | This document |
| 2-3 | Unassigned | |
| 4 | Link Local/Remote Identifiers | RFC5307 |
| 2-255 | Unassigned |
The extensions defined in this document allow IS-IS to carry sensitive operational parameters about a QKD network, including KM identities, IP addresses, and key generation rates. The security of the underlying IS-IS routing protocol is paramount. Implementations SHOULD rely on existing IS-IS security mechanisms, such as the use of cryptographic authentication as defined in [RFC5304] and [RFC5310], to ensure the integrity and authenticity of the advertised information.¶
An attacker who can inject false LSPs could advertise incorrect KM-IDs, IP addresses, or link capabilities, potentially leading to denial of service, man-in-the-middle attacks, or misdirection of key material. Operators are strongly advised to deploy IS-IS authentication in any domain where these QKD extensions are used.¶
Furthermore, as outlined in the SRv6-based QKD relay framework [I-D.chen-qirg-srv6-qkd-relay-framework], the integrity of the path-computation inputs (the QKD information advertised via IS-IS) is critical. Compromised advertisements could lead the controller to select an insecure or ineffective relay path, undermining the security guarantees of the QKD network.¶