| Internet-Draft | DTN QUIC CL | September 2026 |
| Taylor & Kline | Expires 11 March 2027 | [Page] |
This document specifies a minimal convergence layer protocol for transferring Bundle Protocol version 7 (BPv7) bundles over QUIC. The protocol leverages QUIC's native capabilities for reliable streaming, connection management, and security. Reliable transfers carry each bundle on its own QUIC stream, either directly or wrapped in a single CBOR byte string, with no further application-layer framing. Unreliable transfers use the Bundle Transfer Protocol - Unidirectional (BTP-U) over QUIC datagrams.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://ekline.github.io/draft-dtn-qubicle/draft-ek-dtn-qubicle.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ek-dtn-qubicle/.¶
Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dtn/. Subscribe at https://www.ietf.org/mailman/listinfo/dtn/.¶
Source for this draft and an issue tracker can be found at https://github.com/ekline/draft-dtn-qubicle.¶
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 11 March 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.¶
Bundle Protocol version 7 (BPv7) [RFC9171] requires Convergence Layer Adapters (CLAs) to transfer bundles between nodes. This document specifies the QUIC Bundle Protocol Convergence Layer, referred to in this document as "Qubicle", a minimal CLA using QUIC [RFC9000] that embraces QUIC's native capabilities rather than layering additional protocol machinery.¶
The design philosophy is simple: QUIC already provides reliable streams, multiplexing, flow control, congestion control, and integrated security. This specification adds only what is strictly necessary to transfer bundles.¶
The protocol provides two services:¶
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.¶
Convergence Layer Adapter, as defined in [RFC9171]. Also abbreviated "CL" where the context is clear.¶
The Qubicle peer that initiates the QUIC connection. This is a connection-level role and does not imply any restriction on bundle transfer direction.¶
The Qubicle peer that accepts the QUIC connection. This is a connection-level role and does not imply any restriction on bundle transfer direction.¶
The period during which a QUIC connection is established between two Qubicle peers. A session begins when the QUIC handshake completes and ends when the QUIC connection closes. Both client and server are equal peers for the purpose of bundle transfer.¶
Qubicle adds no transport machinery of its own, so its applicability to a given environment is that of QUIC itself: Qubicle SHOULD NOT be used where the QUIC transport cannot be expected to perform well. With the default transport parameters and timer values of general-purpose QUIC implementations, this primarily means deployments where round-trip times (RTTs) remain under a few seconds, so that QUIC's handshake and loss-recovery behavior are well matched to the path.¶
This boundary is not fixed. QUIC's transport parameters and timers can be adjusted to longer-delay paths (Section 7.2), and a profile of QUIC developed for a particular environment, whether by tuning, by use of optional QUIC features such as 0-RTT resumption (Section 6.4), or by other means, applies to Qubicle sessions without modification. Where such a profile exists for an environment, Qubicle's applicability follows it. For extremely high-delay or disrupted environments such as deep space communications (e.g., Earth-Mars links with multi-minute RTTs) in the absence of such a profile, specialized protocols like the Licklider Transmission Protocol (LTP) [RFC5326] may be more appropriate.¶
Similarly, the SVCB-based DNS service discovery mechanism (Section 7.6) SHOULD NOT be used in environments where DNS itself might not perform well. DNS-based discovery is NOT RECOMMENDED for use in DTN environments where DNS infrastructure is unavailable, network disruptions cause failed lookups or stale cached records, DNSSEC validation fails due to a mismatch between query RTT and valid signature lifetimes, or DNS query overhead is significant relative to available bandwidth. For such environments, implementations SHOULD support alternative CL provisioning mechanisms including manual configuration with pre-planned contact schedules, contact graph routing protocols that maintain topology independently of DNS, or out-of-band metadata distribution through mission management plane channels.¶
A hybrid approach is RECOMMENDED for nodes bridging Internet and deep-space networks: use Qubicle with DNS discovery for Internet-side connections, and use alternate mission management planes for space-side connections.¶
A Qubicle session is established by initiating a QUIC connection to a peer. The QUIC handshake authenticates both peers via TLS 1.3 [RFC9001] as described in Section 4.2.¶
The ALPN identifier for Qubicle is qbcl.¶
Qubicle does not exchange Node IDs in-band. A peer's Node ID is the Node ID
carried in the BundleEID OtherName ([RFC9174], Section 4.4.2) of the
certificate it presents during the TLS handshake. Accordingly, both client
and server MUST present a certificate containing a BundleEID OtherName,
and each peer MUST validate the certificate of the other as described in
Section 6.1.¶
The sole exception is a deployment in which a peer has already been
configured with the Node ID of the remote peer by other means (e.g., a
contact plan or manual configuration keyed on the remote address). Such a
peer MAY accept a certificate lacking a BundleEID OtherName and associate
the configured Node ID with the session instead. If the peer has a configured
Node ID and the certificate also contains a BundleEID OtherName, the two
MUST match; a mismatch MUST be treated as a certificate validation failure
and the handshake terminated.¶
The means by which a peer obtains the rendezvous information (address and port) for a remote Node ID, whether by manual configuration, contact plan, or DNS (see Section 7.6), is independent of the identification mechanism above. Rendezvous information locates a candidate peer; only the authenticated certificate establishes which Node ID has actually been reached.¶
For reliable transfer, each bundle is sent on a dedicated QUIC unidirectional stream:¶
The sender creates a new unidirectional stream.¶
The sender writes exactly one bundle to the stream, in one of the two forms described in Section 4.3.2.¶
The sender closes the stream by sending a STREAM frame with the FIN bit set.¶
The receiver reads data from the stream until FIN is received, then delivers the complete bundle to the BPA.¶
QUIC guarantees reliable, in-order delivery of stream data, and Qubicle defines no convergence-layer acknowledgment. A reliable transfer is complete from the sender's perspective when the QUIC endpoint reports that all stream data, including the FIN, has been acknowledged by the peer.¶
This completion signal is generated by the peer's QUIC transport implementation upon receipt of the data. It confirms that the data reached the peer's QUIC endpoint; it does not confirm that the peer's convergence layer has read the data, nor that the peer's BPA has accepted the bundle. In particular, data acknowledged by the QUIC endpoint but not yet consumed by the receiving application can be lost if the receiving process fails. Receivers SHOULD therefore read stream data promptly and pass each completed bundle to the BPA without unnecessary delay, so as to minimize the interval during which acknowledged data is held only in transport buffers.¶
Transfer completion is consequently not a sufficient basis for a sending BPA to conclude that a bundle has been received by the next-hop BPA. Where such assurance is required, it MUST be obtained by bundle-layer mechanisms, such as the status reports defined in [RFC9171], Section 6.1, rather than inferred from the convergence layer.¶
In terms of the convergence layer service model, Qubicle provides the following indications to the BPA:¶
All stream data for the bundle has been acknowledged by the peer's QUIC endpoint, as described above.¶
The stream was reset by either peer (Section 4.6), or the connection closed before all stream data was acknowledged.¶
A complete bundle has been received (FIN received, and for the wrapped form, exactly the declared length) and passed to the BPA.¶
The stream was reset by either peer, or the connection closed before the bundle was complete; any partial data has been discarded.¶
Qubicle does not provide intermediate progress indications; a BPA requiring them can observe stream-level flow control state where the QUIC implementation exposes it.¶
A stream carries exactly one bundle, in either of two forms:¶
The bundle's own encoding is written to the stream without any wrapper. The bundle is framed by the stream boundaries: its length is known to the receiver only when the FIN is received.¶
The bundle's encoding is carried as the content of a single definite-length CBOR byte string ([RFC8949], Section 3.1). The byte string head declares the bundle's exact length before any bundle data is read.¶
A receiver MUST accept both forms and distinguishes them by the first octet of the stream:¶
| First Octet | Interpretation |
|---|---|
| 0x9f | Direct form, BPv7 bundle (CBOR indefinite-length array, [RFC9171], Section 4.1) |
| 0x06 | Direct form, BPv6 bundle ([RFC5050] version octet) |
| 0x40 - 0x5b | Wrapped form; the bundle version is determined by the first octet of the byte string's content as above |
| any other value | Protocol error |
An indefinite-length byte string (first octet 0x5f) is not permitted, as it
would not convey the bundle's length. Receipt of any first octet not listed
above, of an indefinite-length byte string, or of a byte string whose
content does not begin with a recognized bundle version octet, is a protocol
error and the receiver MUST close the connection with QBCL_PROTOCOL_ERROR.¶
In the wrapped form, the receiver reads exactly the declared number of
content octets and then expects FIN. Receipt of additional data after the
declared length, or of FIN before the declared length has been received, is
a protocol error and the receiver MUST close the connection with
QBCL_PROTOCOL_ERROR. In the direct form, the entire stream content is
delivered to the BPA as a single bundle; whether that content constitutes
exactly one well-formed bundle is determined by the BPA, not by the
convergence layer.¶
The two forms serve different needs. The wrapped form allows a receiver to
learn the bundle's size from the first few octets and to reject an
oversized bundle (Section 4.6) or pre-allocate storage before the bulk
of the data arrives. The direct form allows a sender to begin transmitting a
bundle whose total length is not yet known, for example when forwarding a
bundle that is itself still being received on another stream (cut-through
forwarding). A sender SHOULD use the wrapped form whenever the bundle's
length is known in advance, which is the usual case for a bundle held in
storage, and MAY use the direct form otherwise. A receiver MAY, as a matter
of local policy, decline direct-form bundles by cancelling the transfer with
QBCL_LENGTH_REQUIRED.¶
This framing is agnostic to the bundle version carried. Qubicle
implementations MUST support BPv7 bundles. Support for other bundle versions,
including BPv6, is OPTIONAL; a receiver that recognizes but does not support
the version of an incoming bundle SHOULD cancel the transfer with
QBCL_UNSUPPORTED_BUNDLE_VERSION rather than treating it as a protocol
error.¶
Both peers can send bundles simultaneously. Each peer creates unidirectional streams to send its bundles. QUIC stream IDs inherently separate client-initiated streams (IDs 2, 6, 10...) from server-initiated streams (IDs 3, 7, 11...), ensuring no collision between the two directions of bundle flow.¶
Qubicle uses only unidirectional streams. Peers SHOULD set the
initial_max_streams_bidi transport parameter to 0. A peer that
nonetheless receives a bidirectional stream MUST treat this as a protocol
error and close the connection with QBCL_PROTOCOL_ERROR.¶
Senders MAY use QUIC stream priorities to expedite higher-priority bundles. The mapping of bundle priority to QUIC stream priority is an implementation matter.¶
Qubicle relies entirely on QUIC flow control to manage receiver resources; no
convergence-layer mechanism is defined. A receiver controls the number of
bundles concurrently in transfer through the initial_max_streams_uni
transport parameter and subsequent MAX_STREAMS frames, the amount of any
single bundle that may be in flight through initial_max_stream_data_uni
and MAX_STREAM_DATA, and total buffered data through initial_max_data
and MAX_DATA. A receiver that is temporarily unable to accept more data
simply withholds credit, causing the sender to pause without error.
Receivers SHOULD size these limits to reflect the storage they are actually
prepared to commit to in-progress bundles; see Section 7.3.¶
QUIC stream identifiers are 62-bit values, so the total number of streams over a connection's lifetime is not a practical constraint. If an implementation nonetheless reaches an internal limit on stream creation, it SHOULD gracefully close the connection and establish a new one.¶
For unreliable transfer, bundles are sent using QUIC datagrams [RFC9221] with [BTP-U] framing.¶
Support for the unreliable service is OPTIONAL. An implementation offering
it MUST advertise the max_datagram_frame_size transport parameter. The
unreliable service is available on a session only if both peers have
advertised this parameter; otherwise neither peer sends DATAGRAM frames and
only the reliable service is available. Implementations SHOULD make the
availability of the unreliable service known to the BPA so that it can
select an appropriate service for each bundle.¶
Each QUIC DATAGRAM frame carries one or more [BTP-U] messages, and plays
the role of the Link-layer PDU in the [BTP-U] model: it is delivered in
its entirety or not at all. A sender MUST NOT construct a datagram larger
than the peer's advertised max_datagram_frame_size, and SHOULD size
datagrams to fit within the current path MTU so that they are not dropped by
the QUIC layer. [BTP-U] segmentation, reassembly, transfer identification,
and optional repetition apply unchanged.¶
The [BTP-U] Transfer Window size ([BTP-U], Section 5) MUST be configured consistently at both peers; how this is done is out of scope for this document.¶
QUIC DATAGRAM frames are subject to QUIC congestion control ([RFC9221], Section 5), satisfying the [BTP-U] requirement that it not be deployed without congestion control where congestion may occur.¶
The mapping of bundle priority to [BTP-U] transfer interleaving is an implementation matter.¶
A session ends when the QUIC connection closes, whether by an explicit
CONNECTION_CLOSE from either peer or by expiry of the idle timeout
(Section 4.7). Idle timeout is a normal way for a session to end, not an
error; a peer with further bundles to send simply establishes a new session.¶
A peer wishing to end a session gracefully SHOULD stop opening new streams
and initiating new [BTP-U] transfers, allow in-progress reliable transfers
in both directions to complete, and then close the connection with
QBCL_NO_ERROR. Since QUIC provides no means to tell the remote peer that
no further streams will be opened, a peer SHOULD bound this wait with a
local timer.¶
A peer MAY instead close the connection immediately at any time. If it does
so deliberately while transfers are in progress it SHOULD use
QBCL_SHUTTING_DOWN; other codes in Section 5 apply for error
conditions.¶
When a connection closes for any reason, all incomplete reliable transfers on it have failed. The receiver MUST discard any partially received bundle data, as in Section 4.6, and the sender's BPA is notified of each failure so that the affected bundles can be re-forwarded. Any incomplete [BTP-U] transfers on the session are likewise lost.¶
Two peers may establish connections to each other concurrently, resulting in more than one session between the same pair of Node IDs. This is permitted and is not an error. A peer MAY choose to gracefully close a redundant session, but MUST accept bundles received on any established session.¶
Either peer may cancel an in-progress reliable transfer.¶
A sender cancels a transfer by sending RESET_STREAM on the bundle's stream
with an appropriate error code (Section 5). A sender might do this,
for example, when the bundle's lifetime expires before transfer completes,
or when the BPA withdraws the bundle from this CLA.¶
A receiver cancels a transfer by sending STOP_SENDING on the bundle's
stream with an appropriate error code. The sender MUST respond with
RESET_STREAM as required by [RFC9000], Section 3.5. A receiver might do
this, for example, when the incoming bundle exceeds the receiver's storage
or policy limits, or when the receiver's BPA is shutting down.¶
On receiving RESET_STREAM, a receiver MUST discard any partially received
bundle data for that stream and MUST NOT deliver a partial bundle to the BPA.
A receiver that has sent STOP_SENDING MUST likewise discard any data
subsequently received on that stream. A cancelled transfer is reported to the
sending BPA as a failed transfer; the bundle itself is unaffected and MAY be
retransmitted on a new stream or via another CLA, subject to BPA policy.¶
A receiver enforcing a maximum receivable bundle size can reject a
wrapped-form bundle (Section 4.3.2) as soon as the byte string head has
been read, before any bundle data is received. A direct-form bundle can only
be rejected once the received octet count exceeds the limit, by which time
that much bandwidth has been consumed. Receivers for which this matters can
additionally bound in-flight data using the initial_max_stream_data_uni
transport parameter, or decline direct-form bundles altogether with
QBCL_LENGTH_REQUIRED. Since a sender learns the peer's stream flow control
limit during the handshake, a sender SHOULD NOT begin transfer of a bundle
larger than that limit unless it has reason to expect the limit to be
raised.¶
Cancellation of unreliable transfers is governed by [BTP-U].¶
Qubicle relies on QUIC's native idle timeout mechanism. Peers negotiate the max_idle_timeout transport parameter during connection establishment. See Section 7.2 for guidance on selecting this and related values.¶
Where a session must be kept alive across periods with no bundles to send, implementations MAY use QUIC PING frames ([RFC9000], Section 10.1.2) where the QUIC implementation exposes such a facility. Keepalives should be balanced against the idle timeout guidance in Section 7.2: a session that is deliberately allowed to time out and re-established later can be preferable to keeping one alive through a scheduled link outage.¶
Qubicle defines a single space of application error codes, used in the QUIC
CONNECTION_CLOSE frame (with the application-level frame type, see
[RFC9000], Section 19.19), RESET_STREAM frame, and STOP_SENDING
frame. QUIC application error codes are 62-bit unsigned integers.¶
| Code | Name | Description |
|---|---|---|
| 0x00 | QBCL_NO_ERROR | Graceful connection closure, no error |
| 0x01 | QBCL_PROTOCOL_ERROR | Peer violated this specification |
| 0x02 | QBCL_TRANSFER_CANCELLED | Transfer aborted for a reason not otherwise specified (e.g., bundle lifetime expired, BPA withdrew the bundle) |
| 0x03 | QBCL_BUNDLE_TOO_LARGE | Incoming bundle exceeds the receiver's maximum receivable bundle size |
| 0x04 | QBCL_STORAGE_EXHAUSTED | Receiver temporarily cannot accept bundles; the sender MAY retry later |
| 0x05 | QBCL_SHUTTING_DOWN | Peer is deliberately closing the session; no fault is implied |
| 0x06 | QBCL_LENGTH_REQUIRED | Receiver policy does not accept direct-form bundles (Section 4.3.2) |
| 0x07 | QBCL_UNSUPPORTED_BUNDLE_VERSION | Receiver does not support the version of the bundle being transferred |
QBCL_NO_ERROR is only meaningful on CONNECTION_CLOSE. A cancelled
transfer always has a cause, so peers MUST NOT use QBCL_NO_ERROR in
RESET_STREAM or STOP_SENDING; a peer receiving it there SHOULD treat it
as QBCL_TRANSFER_CANCELLED.¶
When a peer closes the session deliberately while transfers are still in
progress, it SHOULD use QBCL_SHUTTING_DOWN on CONNECTION_CLOSE rather
than QBCL_NO_ERROR, so that the remote peer can distinguish an orderly
shutdown with collateral transfer failures from an idle close.¶
A peer receiving an unrecognized error code MUST treat it as
QBCL_PROTOCOL_ERROR on CONNECTION_CLOSE and as QBCL_TRANSFER_CANCELLED
on RESET_STREAM or STOP_SENDING.¶
QUIC mandates TLS 1.3 for all connections, providing confidentiality, integrity, and authentication. Qubicle inherits these security properties.¶
As specified in Section 4.2, Qubicle requires mutual certificate
authentication: both client and server present certificates, and each peer
validates the other's certificate before exchanging bundles. Certificate
validation, including the BundleEID OtherName checks and the applicable
certificate profile, SHOULD follow [RFC9174], Section 4.4. Automated
certificate provisioning is available via the ACME extensions defined in
[RFC9891].¶
Transport security protects bundles in transit between adjacent nodes. For end-to-end bundle security, implementations SHOULD use BPSec [RFC9172].¶
QUIC provides built-in protection against many denial-of-service attacks, including address validation and amplification prevention.¶
QUIC flow control (Section 4.3.5) is the primary means of bounding the resources a peer can consume; receivers SHOULD configure it accordingly rather than accepting unbounded data and discarding it afterwards.¶
QUIC 0-RTT data is not protected against replay. Because a replayed bundle transfer could cause a bundle to be received and forwarded more than once, implementations SHOULD NOT send bundles as 0-RTT data, and servers MAY decline to accept 0-RTT altogether.¶
0-RTT resumption could nonetheless materially reduce session establishment cost on long-delay paths between peers that reconnect frequently. The consequence of a replayed transfer is duplicate receipt of a bundle, which a BPA can detect from the combination of source node ID and creation timestamp ([RFC9171], Section 4.2.7) together with any fragment offset, except for anonymous bundles, and whose impact is bounded where BPSec ([RFC9172]) protects the bundle. Whether this risk is acceptable in a given environment is a matter for operational experience and for any QUIC profile applicable to that environment (Section 3); a deployment that does permit 0-RTT SHOULD ensure that its BPAs perform duplicate bundle detection.¶
To resist ossification, Qubicle endpoints are RECOMMENDED to support QUIC version 2 [RFC9369] and compatible version negotiation [RFC9368]. Qubicle operates identically over any QUIC version providing the features used in this document.¶
QUIC connection behavior is governed by a number of timers. Some are
negotiated via transport parameters during the handshake (e.g.,
max_idle_timeout and max_ack_delay), while others are derived locally
from measured path characteristics (e.g., the Probe Timeout (PTO) computed
from RTT estimates per [RFC9002], seeded by an implementation's initial
RTT value).¶
In many deployments, particularly those on the terrestrial Internet, the default values recommended by [RFC9000] and [RFC9002] and used by general-purpose QUIC implementations are expected to be adequate, and Qubicle implementations MAY use them unchanged.¶
However, Qubicle peers may possess knowledge of end-to-end path characteristics that is unavailable to the QUIC transport itself, for example from contact plans, orbital mechanics, or link scheduling information in non-terrestrial deployments. Such information may indicate expected propagation delays, predictable link outages, or highly asymmetric paths for which Internet defaults are inappropriate (e.g., an idle timeout short enough to be tripped by a scheduled link gap, or an initial RTT small enough to cause spurious PTO retransmissions during the handshake). Implementations SHOULD allow these timers and transport parameters to be configured on a per-peer basis so that they can be adjusted using such knowledge. The means by which such path knowledge is obtained, and the specific adjustments derived from it, are out of scope for this document and may be the subject of environment-specific QUIC profiles.¶
The QUIC flow control limits described in Section 4.3.5 interact. Because a sender must wait for stream credit before opening a stream, a receiver that grants very few concurrent streams limits sender parallelism; conversely, a receiver that grants many streams but little per-stream data can find a large bundle stalling behind many small ones. Per-stream and connection-level data limits also bound throughput to roughly the limit divided by the path RTT, so limits sized purely for storage protection may underutilize a high-bandwidth, high-delay path. The appropriate balance between storage commitment, parallelism, and throughput is deployment-specific, and the same out-of-scope path knowledge discussed in Section 7.2 can inform it.¶
As noted in [RFC9308], some networks block UDP traffic such that Qubicle connections cannot be established. Bundle Protocol Agents that employ Qubicle are RECOMMENDED to support additional Convergence Layers, e.g. TCPCLv4 [RFC9174].¶
It is RECOMMENDED that Qubicle implementations use a dedicated UDP port for operational simplicity.¶
Bundle Protocol Agents that employ Qubicle and other UDP-based Convergence Layers on the same UDP port MUST be able to disambiguate received datagrams in order to route them to the correct CLA. For UDP CLs that use DTLS, [RFC9443] provides the required guidance to disambiguate QUIC traffic from DTLS-encapsulated CL traffic.¶
Qubicle senders may be manually provisioned with a hostname (or IP addresses) and UDP port corresponding to the listening Qubicle endpoint for a peer Bundle Protocol Agent. If only a hostname is known but a port is not, [RFC9460] SVCB Resource Records may be looked up to find a listening UDP port and confirm expected ALPN configuration.¶
Consider this zone file for example.:¶
;; zone: example.
;
$ORIGIN example.
_dtn-bundle._tcp.mars-orbiter IN SRV 10 20 4556 cloud-agent.example.
_qbcl.mars-orbiter IN SVCB 0 cloud-agent.example.
cloud-agent IN A 192.0.2.1
cloud-agent IN AAAA 2001:db8::1
cloud-agent IN SVCB 10 . (
ipv4hint=192.0.2.1
ipv6hint=2001:db8::1
port=1234 alpn="qbcl")
¶
A BPA supporting both TCPCLv4 [RFC9174] and Qubicle may attempt to
resolve an SRV record for the _dtn-bundle._tcp prefixed hostname. A BPA
that supports Qubicle
might also issue DNS SVCB queries for the [AttrLeaf] prefix "_qbcl". The
sample above indicates that mars-orbiter.example. has an SVCB record in
AliasMode referring to cloud-agent.example. The SVCB record associated
with cloud-agent.example. contains all required QUIC transport rendezvous
information.¶
IANA is requested to register the following ALPN identifier in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry:¶
| Protocol | Identification Sequence | Reference |
|---|---|---|
| Qubicle | 0x71 0x62 0x63 0x6C ("qbcl") | This document |
Per [AttrLeaf], IANA is requested to add the following entry to the DNS "Underscored and Globally Scoped DNS Node Names" registry:¶
| RR Type | _NODE NAME | Reference |
|---|---|---|
| SVCB | _qbcl | this document |
IANA is requested to create a new registry "Qubicle Error Codes". Values in this registry are 62-bit unsigned integers, matching the range of QUIC application error codes. Each entry consists of a Code, a Name, a brief Description, and a Reference.¶
The registration policy for this registry is Specification Required [RFC8126] for codes in the range 0x00 to 0x3FFFFFFF. Codes in the range 0x40000000 to 0x3FFFFFFFFFFFFFFF are reserved for Private Use [RFC8126] and are not assigned by IANA.¶
The initial contents of the registry are:¶
| Code | Name | Description | Reference |
|---|---|---|---|
| 0x00 | QBCL_NO_ERROR | Graceful connection closure, no error | This document |
| 0x01 | QBCL_PROTOCOL_ERROR | Peer violated this specification | This document |
| 0x02 | QBCL_TRANSFER_CANCELLED | Transfer aborted, unspecified reason | This document |
| 0x03 | QBCL_BUNDLE_TOO_LARGE | Bundle exceeds receiver's maximum size | This document |
| 0x04 | QBCL_STORAGE_EXHAUSTED | Receiver temporarily cannot accept bundles | This document |
| 0x05 | QBCL_SHUTTING_DOWN | Peer is deliberately closing the session | This document |
| 0x06 | QBCL_LENGTH_REQUIRED | Receiver does not accept direct-form bundles | This document |
| 0x07 | QBCL_UNSUPPORTED_BUNDLE_VERSION | Receiver does not support the bundle version | This document |
| 0x08-0x3FFFFFFF | Unassigned | ||
| 0x40000000-0x3FFFFFFFFFFFFFFF | Reserved for Private Use | This document |