Multicast Extension for QUIC

1.1. Conventions and Definitions

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.¶

Commonly used terms in this document are described below.¶

2.1. Channel using Multipath QUIC

From the point of view of the client, each Multicast QUIC channel is handled as an additional path from the server. A client keeps its unicast connection with the server open during all the transmission. Additionally, the server can inform the client about an additional path where it will receive multicast content. All mechanisms, except those listed below, follow [I-D.draft-ietf-quic-multipath]. TODO: either rely the current Multipath QUIC draft (the client must create the new path itself) or extend the draft to allow the server to initiate the creation of the second path.¶

The first major change concerns the encryption of the multicast path. To keep the unicast path between the client and the server secure, the multicast path MUST use a different key and MAY use a different algorithm, that is common between all clients. As such, each path is encrypted differently, differing from the current version of [I-D.draft-ietf-quic-multipath]. NB: there are discussions within the Multipath QUIC draft to integrate this feature to strengthen the security of MPQUIC. Secondly, a client MUST NOT send any data on the multicast path with the server.¶

Leveraging Multipath QUIC for Multicast QUIC provides interesting properties from the client's point of view. For example, the client can seamlessly receive data from the multicast and the unicast path. This enables efficient unicast fall-back and unicast retransmissions. Leaving the multicast channel is performed by closing the multicast path with the server.¶

This draft imposes the Multiple Packet Number Space version of Multipath QUIC (See Section 5 of [I-D.draft-ietf-quic-multipath]). Each channel possesses its own packet number space. To enable clients to detect lost packets, packet numbers in channels SHOULD be continuous.¶

The use of any particular channel is OPTIONAL for both the server and the client. It is recommended that applications designed to leverage the multicast capabilities of this extension also provide graceful degradation for endpoints that do not or cannot make use of the multicast functionality (see Section 12.5).¶

The server has access to all data transmitted on any multicast channel it uses, and could optionally send this data with unicast instead.¶

No special handling of the data is required in a client application that has enabled multicast. A datagram or any particular bytes from a server-initiated unidirectional stream can be delivered over the unicast connection or a multicast channel transparently to a client application consuming the stream or datagram.¶

Client applications should have a mechanism that disables the use of multicast on connections with enhanced privacy requirements for the privacy-related reasons covered in [I-D.draft-krose-multicast-security].¶

4.1. Channel Management

The client tells its server about some restrictions on resources that it is capable of processing with the initial values in the multicast_client_params transport parameter (Section 3) and later can update these limits with MC_LIMITS Section 10.7 frames. Servers ensure the set of channels the client is currently requested to join remains within these advertised client limits as covered in Section 5.¶

The server asks the client to join channels with MC_JOIN (Section 10.3) frames and to leave channels with MC_LEAVE (Section 10.4) frames.¶

The server uses the MC_ANNOUNCE (Section 10.1) frame before any join or leave frames for the channel to describe the channel properties to the client, including values the client can use to ensure the server's requests remain within the limits it has sent to the server, as well as the secrets necessary to decode the headers of packets in the channel. Sending an MC_ANNOUNCE before an MC_JOIN ensures the client can establish the necessary state required to join and retire any connection IDs that might collide with channel IDs. MC_KEY frames provide the secrets necessary to decode the payload of packets in the channel. Figure 2 shows the states a channel has from the clients point of view.¶

Joining a channel after receiving an MC_JOIN frame is OPTIONAL for clients. If a client decides not to join after being asked to do so, it can indicate this decision by sending an MC_STATE (Section 10.9) frame with state DECLINED_JOIN and an appropriate reason.¶

The server ensures that in aggregate, all channels that the client has currently been asked to join and that the client has not left or declined to join fit within the limits indicated by the initial values in the transport parameter or last MC_LIMITS (Section 10.7) frame the server received.¶

This extension does not define an application-layer catalogue or content-selection protocol. Application protocols determine what content, service, program, representation, or other application context is relevant to a connection. The multicast extension merely provides a transport mechanism by which the server can describe channels that are available in that context and request that the client join or leave them. A server is not expected to announce every multicast channel that it operates to every client. The set of channels announced to any specific client can be limited by application-layer state, prior application requests, receiver limits, server policy, or any combination of these.¶

For example, a server may provide a video stream in different resolutions, with each available resolution being carried in a different multicast channel. The server would only announce the channel that offers the best available quality while remaining under the limits set by the client. In this case, this could happen without any involvement of the client-side application.¶

                            o
                            |
----------------------->|   | Receive MC_ANNOUNCE and/or MC_KEY
^                       |   |
|                       |   |
|  Receive MC_JOIN (and v   v
|     unable to join) +----------+
|<--------------------*          |
                      | unjoined | Receive MC_RETIRE
--------------------->|          *------------------------>|
^                     +----*-----+                         |
|                          | Receive MC_JOIN               |
|                          |   (and able to join)          |
|                          |                               |
|                          v                               v
|                     +----------+                    +---------+
|    Receive MC_LEAVE |          |                    |         |
|     (or error case) |  joined  | Receive MC_RETIRE  | retired |
|<--------------------*          *------------------->|         |
                      +----------+                    +---------+

*: Each transition except the initial receiving of MC_ANNOUNCE
   and MC_KEY frames causes the client to send an MC_STATE frame
   describing the state transition (for LEFT or DECLINED_JOIN, this
   includes a reason for the transition).

"able to join" means:
- Both MC_KEY and MC_ANNOUNCE have been received
- Result will be within latest advertised client limits
- Nothing preventing a join is active (e.g. a hold-down timer,
  administrative blocking, etc.)

When the server has asked the client to join a channel and has not received any MC_STATE frames Section 10.9 with state DECLINED_JOIN or LEFT, it also sends MC_INTEGRITY frames (Section 10.5) to enable the client to verify packet integrity before processing the packet. A client MUST NOT decode packets for a channel for which it has not received an applicable MC_ANNOUNCE (Section 10.1), or for which it has not received a matching packet hash in an MC_INTEGRITY (Section 10.5) frame, or for which it has not received an applicable MC_KEY frame Section 10.2.¶

Figure 3 shows the frames that are being exchanged about and over a channel during the lifetime of an example channel.¶

Client                                        Server

MC_LIMITS/initial_limits  --->

                                              MC_ANNOUNCE
                                              MC_KEY
                                       <----  MC_JOIN

MC_STATE(JOINED)  --->

                                              MC_INTEGRITY
                                       <----  [STREAM(...)]
MC_ACK  --->                                  ...
...                                    <----  MC_KEY
...
MC_LIMITS  --->

                                       <----  MC_LEAVE

MC_STATE(LEFT)  --->

                                       <----  MC_JOIN

MC_STATE(JOINED)  --->

                                              MC_INTEGRITY
                                       <----  [STREAM(...)]
MC_ACK  --->                                  ...
...

                                       <----  MC_LEAVE

MC_STATE(LEFT)  --->

                                       <----  MC_RETIRE

MC_STATE(RETIRED)  --->

TODO: incorporate server-side state diagram and explanation, latest proposed sketch at https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/issues/62¶

4.2. Client Response

The client sends back information about how it has responded to the server's requests to join and leave channels in MC_STATE (Section 10.9) frames. MC_STATE frames are only sent for channels after the server has requested the client to join the channel, and are thereafter sent any time the state changes.¶

Clients that receive and decode data on a multicast channel send acknowledgements for the data on the unicast connection using MC_ACK (Section 10.6) frames.¶

A server can determine if a client receives packets for a multicast channel if it receives MC_ACK frames associated with that channel. Accordingly, a client MUST send an MC_ACK frame as soon as possible after receiving the first packets on a newly joined channel. As such, it is in general up to the server to decide on the time after which it deems a client to be unable to receive packets on a given channel and take appropriate steps, e.g. sending an MC_LEAVE frame to the client. Note that clients willing to join a channel SHOULD remain joined to the channel even if they receive no channel data for an extended period, to enable multicast-capable networks to perform popularity-based admission control for multicast channels.¶

4.3. Data Carried in Channels

Data transmitted in a multicast channel is encrypted with symmetric keys so that on-path observers without access to these keys cannot decode the data. However, since potentially many receivers receive identical packets and identical keys for the multicast channel and some receivers might be malicious, the packets are also protected by MC_INTEGRITY (Section 10.5) frames transmitted over a separate integrity-protected path.¶

A client MUST NOT decode packets on a multicast channel for which it has not received a matching hash in an MC_INTEGRITY frame over a different integrity-protected communication path. The different path can be either the unicast connection or another multicast channel with packets that were verified with an earlier MC_INTEGRITY frame.¶

Note that MC_INTEGRITY frames MAY be carried in packets on multicast channels, however such packets will not be accepted unless another accepted MC_INTEGRITY frame contains its packet hash. Hashes of packets containing hashes of other packets can thus form a Merkle tree [MERKLE] with a root that is carried in the unicast connection.¶

See Section 7 for a more complete overview of the security issues involved here.¶

A client is not required to buffer unauthenticated packets indefinitely. A client MAY discard unauthenticated packets when doing so is necessary to bound memory use. A client SHOULD use the channel's Max Rate and Max Authentication Delay values to size the buffer it is willing to allocate for unauthenticated packets on that channel.¶

If a packet has not become authenticated within Max Authentication Delay after it was received, the client MAY discard the packet. If this occurs persistently, or if the number of unauthenticated packets exceeds the client's local buffering capacity, the client SHOULD leave the channel and send MC_STATE(LEFT) with reason AUTHENTICATION_DELAY_EXCEEDED.¶

A client MAY decline to join a channel, or MAY leave a joined channel, if the Max Authentication Delay value is larger than the client is willing to support.¶

4.4. Stream Processing

Stream IDs in channels are restricted to unidirectional server initiated streams, or those with the least significant 2 bits of the stream ID equal to 3 (see Section 2.1 of [RFC9000]).¶

Multicast channels do not define independent QUIC stream ID spaces. STREAM frames received on a multicast channel are processed as regular STREAM frames for the associated QUIC connection. Stream IDs are therefore allocated from the same connection-wide stream ID space, whether stream data is sent on the unicast path or on one or more multicast channels.¶

A server that sends STREAM frames on one or more multicast channels associated with the same QUIC connection is responsible for coordinating stream ID allocation across the unicast paths of all potential multicast receivers, and across all relevant multicast channels.¶

Using disjoint stream ID ranges for different channels is one possible implementation strategy, but is not required by this specification.¶

When a channel contains, or may soon contain, streams with IDs that exceed the stream ID limit implied by the client's server-initiated unidirectional MAX_STREAMS value, the server MUST NOT send MC_JOIN to instruct the client to join that channel and SHOULD send a STREAMS_BLOCKED frame, as described in Sections 4.6 and 19.14 of [RFC9000].¶

If the client is already joined to a channel that carries streams that exceed or will soon exceed the client's unidirectional MAX_STREAMS, the server SHOULD send an MC_LEAVE frame.¶

If a client receives a STREAM frame with an ID above its MAX_STREAMS on a channel, the client MAY increase its unidirectional MAX_STREAMS to a value greater than the new ID and send an update to the server, otherwise it MUST drop the packet and leave the channel with reason "MAX_STREAMS_EXCEEDED".¶

Since clients can join later than a channel began, it is RECOMMENDED that clients supporting the multicast extensions to QUIC be prepared to handle stream IDs that do not begin at early values, since by the time a client joins a channel in progress the stream ID count might have been increasing for a long time. Clients should therefore begin with a high initial_max_streams_uni or send an early MAX_STREAMS type 0x13 value (see Section 19.11 of [RFC9000]) with a high limit. Clients MAY use the maximum 2^60 for this high initial limit, but the specific choice is implementation-dependent.¶

The same stream ID may be used in both one or more multicast channels and the unicast connection. As described in Section 2.2 of [RFC9000], stream data received multiple times for the same offset MUST be identical, including when the data is received on different multicast channels or on both multicast and unicast paths. If it's not identical it MAY be treated as a connection error of type MC_EXTENSION_ERROR.¶

7.1. Packet Hashes

TODO: explanation and example for how to calculate the packet hash. Note that the hash is on the encrypted packet to avoid leaking data about the encrypted contents to those who can see a hash but not the key. (This approach also may help make better use of [I-D.draft-ietf-mboned-ambi] by making it possible to generate the same hashes for use in both AMBI and QUIC MC_INTEGRITY frames.)¶

9.1. Stateless Reset

As clients can unilaterally stop the delivery of multicast packets by leaving the relevant (S,G), channels do not need stateless reset tokens. Clients therefore do not share the stateless reset tokens of channels with the server. Instead, if an endpoint receives packets addressed to an (S,G) that it can not associate with any existing channel, it MAY take the necessary steps to prevent the reception of further such packets, without the need to signal to the server that it should stop sending.¶

If a server or client detect a stateless reset for a channel, they MUST ignore it.¶

9.2. Connection Migration

If the unicast connection migrated, e.g. due to a change of the NAT binding or because the UE has changed to a different network, the client properties might change. For example, the client might switch from a network that supports both IPv6 and IPv4 multicast to a network that only support IPv4. As such, it MUST immediately send an MC_LIMITS frame after it has noticed that it migrated. The client MAY rejoin any previously joined channels, if its limits still allow it to. It MUST send MC_STATE(LEFT) frames with reason LIMIT_VIOLATION for any channels it does not rejoin.¶

The server SHOULD take notice of migrating clients as the delay that is being caused by rejoining a multicast group can lead to exceeding the expected MAX_ACK_DELAY, which a server might interpret as a loss of multicast connectivity. Instead, the server SHOULD treat all multicast channels of a client whose unicast connection just migrated as if it had just joined these channels initially and allow for ample time before expecting the first MC_ACK frames.¶

10.1. MC_ANNOUNCE

Once a server learns that a client supports multicast through its transport parameters, it can send one or multiple MC_ANNOUNCE frames (type=TBD-11..TBD-12) to share information about available channels with the client. The MC_ANNOUNCE frame contains the properties of a channel that do not change during its lifetime.¶

MC_ANNOUNCE frames are formatted as shown in Figure 4.¶

MC_ANNOUNCE Frame {
  Type (i) = TBD-11..TBD-12 (experiments use 0xff3e811/0xff3e812),
  ID Length (8),
  Channel ID (8..160),
  Source IP (32..128),
  Group IP (32..128),
  UDP Port (16),
  Cipher Suite (16),
  Header Secret Length (i),
  Header Secret (..),
  Integrity Hash Algorithm (16),
  Max Rate (i),
  Max Authentication Delay (i),
  Max ACK Delay (i),
  Ack-Eliciting Threshold (i),
  Reordering Threshold (i)
}

Frames of type TBD-11 are used for IPv4 and both Source and Group address are 32 bits long. Frames of type TBD-12 are used for IPv6 and both Source and Group address are 128 bits long.¶

MC_ANNOUNCE frames contain the following fields:¶

• ID Length: The length in bytes of the Channel ID field.¶

• Channel ID: The channel ID of the channel that is getting announced.¶

• Source IP: The IP Address of the source of the (S,G) for the channel. Either a 32-bit IPv4 address or a 128-bit IPv6 address, as indicated by the frame type (TBD-11 indicates IPv4, TBD-12 indicates IPv6).¶

• Group IP: The IP Address of the group of the (S,G) for the channel. Either a 32-bit IPv4 address or a 128-bit IPv6 address, as indicated by the frame type (TBD-11 indicates IPv4, TBD-12 indicates IPv6). This address MUST be a valid SSM destination address as specified in [RFC4607].¶

• UDP Port: The 16-bit UDP Port of traffic for the channel.¶

• Cipher Suite: A value from the "TLS Cipher Suites" registry in the "Transport Layer Security (TLS) Parameters" registry group [IANA.tls-parameters]. The cipher suite determines the AEAD algorithm used for packet protection, the hash function used for key derivation, and the header protection algorithm for channel packets, as described in Section 5 of [RFC9001]. The value MUST match a value provided in the Cipher Suite List of the multicast_client_params transport parameter; see Section 3.¶

• Header Secret Length: Provides the length of the Header Secret field.¶

• Header Secret: A secret used to derive the header protection key for channel packets. The header protection key is derived from this secret using the cipher suite identified by the Cipher Suite field and the "quic hp" label, as described in Section 5.1 of [RFC9001]. The header protection algorithm is the algorithm defined by [RFC9001] for the AEAD associated with the Cipher Suite used by this channel. The Header Secret is not used to derive packet protection keys or IVs.¶

• Integrity Hash Algorithm: The hash algorithm used in MC_INTEGRITY frames.¶

  • Author's Note: Several candidate IANA registries, not sure which one to use? Some have only text for some possibly useful values. For now we use the first of these:¶

    • https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg¶

    • https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18¶

    • (text-only): https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml¶

• Max Rate: The maximum rate in Kibps of the payload data for this channel. Channel data MUST NOT exceed this rate over any 5s window, if it does clients SHOULD leave the channel with reason "MAX_RATE_EXCEEDED".¶

• Max Authentication Delay: The maximum time, in microseconds, that a client is expected to buffer a multicast channel packet before the packet becomes authenticated by an accepted MC_INTEGRITY frame. The delay is measured from receipt of the channel packet until the packet becomes authenticated. See Section 12.8.¶

• Max ACK Delay: The maximum amount of time, in microseconds, that a client can intentionally delay sending an MC_ACK frame for ack-eliciting packets received on this channel. This value is used similarly to max_ack_delay (Section 18.2 of [RFC9000]), but applies only to MC_ACK frames for this channel. A client SHOULD NOT intentionally delay an MC_ACK for this channel beyond this value.¶

• Ack-Eliciting Threshold: The maximum number of ack-eliciting channel packets that a client can receive on this channel without sending an MC_ACK. This field has the same semantics as the Ack-Eliciting Threshold field of ACK_FREQUENCY ([I-D.ietf-quic-ack-frequency]), except that it applies only to MC_ACK frame generation for this channel. A value of 0 requests that every ack-eliciting channel packet be acknowledged immediately. A value of 1 corresponds to the default QUIC behavior of acknowledging after receiving two ack-eliciting packets.¶

• Reordering Threshold: A packet-count threshold used to determine when receipt of out-of-order channel packets causes an immediate MC_ACK. This field has the same semantics as the Reordering Threshold field of ACK_FREQUENCY ([I-D.ietf-quic-ack-frequency]), except that it applies only to this channels packet number space and to MC_ACK frames for this channel.¶

A client MUST NOT use the channel ID included in an MC_ANNOUNCE frame as a connection ID for the unicast connection. If it is already in use, the client SHOULD retire it as soon as possible. As the server knows which connection IDs are in use by the client, it MUST wait with the sending of an MC_JOIN frame until the channel ID associated with it has been retired by the client.¶

If a client receives an MC_ANNOUNCE frame with a Group IP that is not within the SSM destination address range as outlined in [RFC4607], it SHOULD close the connection with reason MC_EXTENSION_ERROR.¶

As all the properties in MC_ANNOUNCE frames are immutable during the lifetime of a channel, a server SHOULD NOT send an MC_ANNOUNCE frame for the same channel more than once to each client except as needed for recovery.¶

A server SHOULD send an MC_ANNOUNCE frame for a channel before sending an MC_KEY frame for that channel.¶

A server MUST NOT send an MC_JOIN frame for a channel unless it has sent, or is sending in the same packet, both an applicable MC_ANNOUNCE frame and an applicable MC_KEY frame for that channel.¶

10.2. MC_KEY

Multicast channel keys are channel-scoped rather than connection-scoped. The same channel secret will be shared by receivers on many different QUIC connections, and clients can join a channel after it has started or leave before it ends, or miss key updates while not joined. The regular QUIC Key Update mechanism (Section 6 of [RFC9001]) can not cover such cases. Therefore, the server needs an explicit mechanism to provide the current channel secret to authorized receivers, identify the packet number from which that secret applies, and rotate channel keys independently of the unicast connection's 1-RTT keys.¶

An MC_KEY frame (type=TBD-01) is sent from server to client, either with the unicast connection or in an existing joined multicast channel. The MC_KEY frame contains an updated secret that is used to generate the keying material for the payload of 1-RTT packets received on the multicast channel.¶

A server can send a new MC_KEY frame with a sequence number increased by one. A server MUST generate continuous sequence numbers, and MAY start at a value higher than 0. Note that while not joined, a client will not receive updates to channel secrets, and thus may see jumps in the Key Sequence Number values between MC_KEY frames. However, while joined the Key Sequence Numbers in the MC_KEY frames MUST increment by 1 for each new secret.¶

Secrets with even-valued Key Sequence Numbers have a Key Phase of 0 in the 1-RTT packet, and secrets with odd-valued Key Sequence Numbers have a Key Phase of 1 in the 1-RTT packet. Secrets with a Key Phase indicating an unknown key SHOULD be discarded without attempting to decrypt them. (An unknown key might happen after loss of the latest MC_KEY frame, so that packets on a channel have an updated Key Phase starting at a particular packet number, but the client does not yet know about the key change.)¶

Should a client receive two different Keys with the same Key Sequence Number and Channel ID, e.g. one over the unicast connection and one over the multicast channel, it SHOULD close the connection with reason MC_EXTENSION_ERROR.¶

It is RECOMMENDED that servers send regular secret updates.¶

MC_KEY frames are formatted as shown in Figure 5.¶

MC_KEY Frame {
  Type (i) = TBD-01 (experiments use 0xff3e801),
  ID Length (8),
  Channel ID (8..160),
  Key Sequence Number (i),
  From Packet Number (i),
  Secret Length (i),
  Secret (..)
}

MC_KEY frames contain the following fields:¶

• ID Length: The length in bytes of the Channel ID field.¶

• Channel ID: The channel ID for the channel associated with this frame.¶

• Key Sequence Number: Increases by 1 each time the secret for the channel is changed by the server. If there is a gap in sequence numbers due to reordering or retransmission of packets, on receipt of the older MC_KEY frame, the client MUST apply the secret contained and the packet numbers on which it applies as if they arrived in order.¶

• From Packet Number: The values in this MC_KEY frame apply only to packets starting at From Packet Number and continuing until they are overwritten by a new MC_KEY frame with a higher From Packet Number. The Packet Number MUST never decrease with an increased Key Sequence Number.¶

• Secret Length: Provides the length of the secret field.¶

• Secret: A channel packet protection secret. Packet protection keys and IVs for channel packets are derived from this secret using the cipher suite identified in the corresponding MC_ANNOUNCE frame and the "quic key" and "quic iv" labels, as described in Section 5.1 of [RFC9001]. This secret is not used to derive the header protection key.¶

To maintain forward secrecy and prevent malicious clients from decrypting packets long after they have left or were removed from the unicast connection, servers SHOULD periodically send key updates using only unicast.¶

Clients MUST delete old secrets and the keys derived from them after receiving new MC_KEY frames. Deleting old keys prevents later compromise of a client from discovering an otherwise uncompromised key, thus improving the chances of achieving forward secrecy for data sent before a key rotation.¶

Client implementations MAY institute a delay before deleting secrets to allow for decoding of packets for the channel that arrive shortly after a new MC_KEY frame. For this experimental specification, it is RECOMMENDED that clients delete old keys 10 seconds after receiving a new key or after 3 seconds that elapse without receiving any new data to decode with the old key, whichever is shorter. Clients MUST NOT delay more than 60 seconds before deleting the old keys.¶

The delay values for this specification are somewhat arbitrary and allow for implementation-dependent experimentation. One of the target discoveries for experimental evaluation is to determine good default delay values to use, and to understand whether there are use cases that would benefit from a negotiation between server and client to determine the delays to use dynamically. (A poor delay choice results in either overhead from dropping packets instead of decoding them with old keys for too short a delay or in extra forward secrecy exposure time for too long a delay, and the purpose of the delays are to bound the forward secrecy exposure without inducing unreasonable overhead.)¶

The From Packet Number is used to indicate the starting packet number (Section 17.1 of [RFC9000]) of the 1-RTT packets for which the secret contained in an MC_KEY frame is applicable. This secret is applicable to all future packets until it is updated by a new MC_KEY frame.¶

A server SHOULD NOT send MC_KEY frames for channels except those the client has joined or will be imminently asked to join.¶

10.3. MC_JOIN

An MC_JOIN frame (type TBD-02) is sent from server to client and requests that the client join the channel identified by Channel ID. The client uses the channel's transport addresses and properties from the corresponding MC_ANNOUNCE frame. The MC_KEY Sequence Number field identifies the channel key generation that the server expects the client to have available when processing channel packets.¶

A client cannot join a multicast channel without first receiving an applicable MC_ANNOUNCE frame and an applicable MC_KEY frame for that channel.¶

MC_JOIN frames are formatted as shown in Figure 6.¶

MC_JOIN Frame {
  Type (i) = TBD-02 (experiments use 0xff3e802),
  ID Length (8),
  Channel ID (8..160),
  MC_LIMITS Sequence Number (i),
  MC_STATE Sequence Number (i),
  MC_KEY Sequence Number (i)
}

MC_JOIN frames contain the following fields:¶

• ID Length: The length in bytes of the Channel ID field.¶

• Channel ID: The channel ID for the channel that the client is requested to join.¶

• MC_LIMITS Sequence Number: The most recent Client Limits Sequence Number processed by the server when constructing this join request.¶

• MC_STATE Sequence Number: The most recent Client Channel State Sequence Number for this channel processed by the server when constructing this join request.¶

• MC_KEY Sequence Number: The Key Sequence Number for the channel key generation that the server expects the client to use when joining the channel.¶

If a client receives an MC_JOIN for a channel for which it has not received both an applicable MC_ANNOUNCE frame and an applicable MC_KEY frame, it MUST send an MC_STATE frame with State DECLINED_JOIN and Reason Code UNSYNCHRONIZED_PROPERTIES.¶

If the client joins, it MUST send an MC_STATE frame with State JOINED. If the client does not join, it MUST send an MC_STATE frame with State DECLINED_JOIN and an appropriate Reason Code.¶

10.4. MC_LEAVE

An MC_LEAVE frame (type=TBD-03) is sent by a server to request that the client leave the given channel. MC_LEAVE does not retire the channel and the server can later send another MC_JOIN for the same channel as long as it is not retired.¶

MC_LEAVE frames are formatted as shown in Figure 7.¶

MC_LEAVE Frame {
  Type (i) = TBD-03 (experiments use 0xff3e803),
  ID Length (8),
  Channel ID (8..160),
  MC_STATE Sequence Number (i)
}

MC_LEAVE frames contain the following fields:¶

• ID Length: The length in bytes of the Channel ID field.¶

• Channel ID: The channel ID for the channel that the client is requested to leave.¶

• MC_STATE Sequence Number: The most recent Client Channel State Sequence Number processed by the server for this channel. This value allows the client to ignore leave requests that are based on stale client channel state.¶

A client that receives an MC_LEAVE for a channel that it has already left, declined to join, or retired MUST ignore the frame.¶

A client that has received an MC_JOIN or MC_LEAVE for the same Channel ID with a greater MC_STATE Sequence Number MUST ignore the MC_LEAVE frame.¶

Otherwise, the client MUST leave the channel immediately and send an MC_STATE frame with State LEFT and Reason Code REQUESTED_BY_SERVER.¶

10.5. MC_INTEGRITY

MC_INTEGRITY frames are sent from server to client and are used to convey packet hashes for validating the integrity of packets received over the multicast channel as described in Section 7.1.¶

MC_INTEGRITY frames are formatted as shown in Figure 8.¶

MC_INTEGRITY Frame {
  Type (i) = TBD-04..TBD-05 (experiments use 0xff3e804/0xff3e805),
  ID Length (8),
  Channel ID (8..160),
  Packet Number Start (i),
  [Packet Hashes Length (i)],
  Packet Hashes (..)
}

For type TBD-05, Packet Hashes Length is present and is the length in bytes of the Packet Hashes field. For TBD-04, Packet Hashes Length is not present and the Packet Hashes field extends to the end of the packet.¶

The Packet Hashes field contains a sequence of packet hashes. The first hash in the Packet Hashes list is a hash of a 1-RTT packet with the Channel ID equal to the Channel ID in the MC_INTEGRITY frame and packet number equal to the Packet Number Start field. Subsequent hashes refer to the packets for that channel with packet numbers increasing by one.¶

Each hash has its length determined by the Integrity Hash Algorithm in the corresponding MC_ANNOUNCE frame. The Packet Hashes field MUST contain a non-zero integer multiple of of the hash length for the channel. A client that receives an MC_INTEGRITY frame whose Packet Hashes field length is zero, or whose Packet Hashes field length is not an integer multiple of the hash length for the channel, MUST treat this as a connection error of type MC_EXTENSION_ERROR.¶

See Section 7.1 for a description of the packet hash calculation.¶

10.6. MC_ACK

The MC_ACK frame (types TBD-06 and TBD-07; experiments use 0xff3e806..0xff3e807) is an extension of the ACK frame defined by [RFC9000]. It is used to acknowledge packets that were sent on multicast channels. If the frame type is TBD-07, MC_ACK frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point.¶

MC_ACK generation is controlled by the MC_ACK policy advertised in the MC_ANNOUNCE frame of the corresponding channel. The Max ACK Delay, Ack-Eliciting Threshold, and Reordering Threshold fields of MC_ANNOUNCE apply separately to each multicast channel packet number space.¶

A client SHOULD send an MC_ACK for a channel when either:¶

• the number of ack-eliciting channel packets received since the last MC_ACK for that channel is greater than the Ack-Eliciting Threshold;¶

  or¶

• Max ACK Delay has elapsed and at least one ack-eliciting channel packet has been received since the last MC_ACK for that channel.¶

A client MAY send an MC_ACK earlier than required by these rules. A client MUST send the first MC_ACK for a newly joined channel without intentional delay after receiving ack-eliciting packets on that channel.¶

A client SHOULD use the Reordering Threshold to determine when receipt of out-of-order channel packets causes an immediate MC_ACK, following the behavior defined for ACK_FREQUENCY ([I-D.ietf-quic-ack-frequency]), applied to the channel packet number space.¶

All channel packets that require acknowledgment MUST be acknowledged at least once. When MC_ACK frames are sent less frequently, clients need to retain ACK range information long enough to avoid permanently omitting acknowledgment of received channel packets.¶

ACK_FREQUENCY and IMMEDIATE_ACK frames defined by [I-D.ietf-quic-ack-frequency] do not affect MC_ACK generation unless a future extension explicitly defines such behavior. The ACK policy for MC_ACK frames is instead defined by the MC_ANNOUNCE frame for the corresponding channel.¶

(TODO: Would there be value in reusing the multiple packet number space version of ACK_MP from Section 12.2 of [I-D.draft-ietf-quic-multipath], defining channel ID as the packet number space? at 2022-05 they're identical except the Channel ID and types.)¶

MC_ACK frames are formatted as shown in Figure 9.¶

MC_ACK Frame {
  Type (i) = TBD-06..TBD-07 (experiments use 0xff3e806, 0xff3e807),
  ID Length (8),
  Channel ID (8..160),
  Largest Acknowledged (i),
  ACK Delay (i),
  ACK Range Count (i),
  First ACK Range (i),
  ACK Range (..) ...,
  [ECN Counts (..)],
}

10.7. MC_LIMITS

MC_LIMITS frames are formatted as shown in Figure 10.¶

MC_LIMITS Frame {
  Type (i) = TBD-09 (experiments use 0xff3e809),
  Client Limits Sequence Number (i),
  Reserved (6),
  IPv6 Channels Allowed (1),
  IPv4 Channels Allowed (1),
  Max Aggregate Rate (i),
  Max Channel IDs (i),
  Max Joined Count (i),
}

The sequence number is implicitly 0 before the first MC_LIMITS frame from the client, and increases by 1 each new frame that's sent. Newer frames override older ones.¶

The 6 Reserved bits MUST be set to 0 by the client and MUST be ignored by the server. These are reserved to advertise future capabilities.¶

IPv6 Channels Allowed is a 1-bit field set to 1 if IPv6 channels can be joined and 0 if IPv6 channels cannot be joined.¶

IPv4 Channels Allowed is a 1-bit field set to 1 if IPv4 channels can be joined and 0 if IPv4 channels cannot be joined.¶

It is valid for both IPv4 Channels Allowed and IPv6 Channels Allowed to be set to zero simultaneously. This indicates that the client does not currently permit joining multicast channels using either IP address family. This does not disable support for this extension on the connection and does not prevent the client from later sending an MC_LIMITS frame that permits one or both address families.¶

After receiving an MC_LIMITS frame, the server MUST NOT send MC_JOIN for a channel whose address family is not currently allowed by the client. If a client receives such an MC_JOIN responds as described in Section 5. If the client is currently joined to one or more channels that are no longer allowed by the updated limits, the server MUST send an MC_LEAVE frame for those channels unless it has already received MC_STATE indicating that the client has left those channels.¶

Max Aggregate Rate allowed across all joined channels is in Kibps.¶

Max Channel IDs is the count of channel IDs that can be announced to this client and have keys. Retired Channel IDs don't count against this value.¶

Max Joined Count is the count of channels that are allowed to be joined concurrently.¶

10.8. MC_RETIRE

An MC_RETIRE frame retires a channel by Channel ID and causes the client to discard any state associated with that channel.¶

MC_RETIRE frames are formatted as shown in Figure 11.¶

MC_RETIRE Frame {
  Type (i) = TBD-0a (experiments use 0xff3e80a),
  ID Length (8),
  Channel ID (8..160)
}

MC_RETIRE frames contain the following fields:¶

• ID Length: The length in bytes of the Channel ID field.¶

• Channel ID: The channel ID for the channel that the client is requested to leave.¶

After receiving an MC_RETIRE frame, the client MUST retire the channel immediately and send an MC_STATE frame with State RETIRED and Reason Code REQUESTED_BY_SERVER.¶

If the client is still joined to the channel that is being retired, it MUST also leave the channel. In this case, the client does not send a separate MC_STATE frame with State LEFT, as State RETIRED also implies that the client has left the channel.¶

10.9. MC_STATE

MC_STATE frames (type=TBD-0b or TBD-0c) are sent from client to server to report changes in the client's channel state. Each time the channel state changes, the Client Channel State Sequence number is increased by one. Due to packet loss it is possible that Sequence numbers aren't continuous on the server side. As such, the server MUST only consider the frames with the highest Sequence number. It is a state change to the channel if the server requests that a client join a channel and the client declines the join, even though no join occurs on the network.¶

Frames of type TBD-0b are used for cases in which the reason for the state change occur in the QUIC multicast layer while frames of type TBD-0c are used for reasons that are application specific.¶

MC_STATE frames are formatted as shown in Figure 12.¶

MC_STATE Frame {
  Type (i) = TBD-0b..TBD-0c (experiments use 0xff3e80b and 0xff3e80c),
  ID Length (8),
  Channel ID (8..160),
  Client Channel State Sequence Number (i),
  State (8),
  Reason Code (i),
  Reason Phrase Length (i),
  Reason Phrase (..)
}

State has these defined values:¶

• 0x1: LEFT¶

• 0x2: DECLINED_JOIN¶

• 0x3: JOINED¶

• 0x4: RETIRED¶

If a server receives an undefined value, it SHOULD close the connection with reason MC_EXTENSION_ERROR.¶

If State is JOINED or RETIRED, the Reason Code MUST be REQUESTED_BY_SERVER (0x1).¶

If State is LEFT or DECLINED_JOIN, for frames of type TBD-0b the Reason Code field is set to one of:¶

• 0x0: UNSPECIFIED_OTHER¶

• 0x1: REQUESTED_BY_SERVER¶

• 0x2: ADMINISTRATIVE_BLOCK¶

• 0x3: PROTOCOL_ERROR¶

• 0x4: PROPERTY_VIOLATION¶

• 0x5: UNSYNCHRONIZED_PROPERTIES¶

• 0x6: ID_COLLISION¶

• 0x10: HELD_DOWN¶

• 0x12: MAX_RATE_EXCEEDED¶

• 0x13: HIGH_LOSS¶

• 0x14: EXCESSIVE_SPURIOUS_TRAFFIC¶

• 0x15: MAX_STREAMS_EXCEEDED¶

• 0x16: LIMIT_VIOLATION¶

• 0x17: AUTHENTICATION_DELAY_EXCEEDED¶

(Author's note TODO: consider whether that these reasons should be added to the QUIC Transport Error Codes registry (Section 22.5 of [RFC9000]) instead of defining a new registry specific to multicast.)¶

For frames of type TBD-0c, the Reason Code is left to the application, as described in Section 20.2 of [RFC9000]¶

The Reason Phrase field, in combination with the Reason Phrase Length field, can optionally be used to give further details for the state change.¶

A client might receive multicast packets that it can not associate with any channel ID, or that cannot be verified as matching hashes from MC_INTEGRITY frames, or cannot be decrypted. This traffic is presumed either to have been corrupted in transit or to have been sent by someone other than the legitimate sender of traffic for the channel, possibly by an attacker or a misconfigured sender. If these packets are addressed to an (S,G) that is used for reception in one or more known channels, the client MAY leave these channels with reason "Excessive Spurious traffic".¶

10.10. Retransmission of information

In addition to the mechanisms used for retransmission described in Section 13.3 of [RFC9000] and Section 5.2 of [RFC9221] the following rules apply to the newly introduced frames:¶

• As the properties carried in MC_ANNOUNCE frames can not change during the lifetime of a channel, information contained in them can be retransmitted without any special considerations.¶

• Since conditions of the client or channel can have changed by the time a retransmission of an MC_JOIN, MC_LEAVE or MC_RETIRE channel becomes necessary, a retransmission might no longer be required or even appropriate. A retransmission SHOULD only occur if the channel in question should still be joined/left/retired.¶

• Retransmission of information contained in MC_ACK frames MUST be handled exactly as with regular ACK frames.¶

• For MC_KEY, MC_LIMITS, and MC_STATE, retransmissions MUST include the most up-to-date information.¶

• For MC_INTEGRITY, retransmissions MUST include the packet hashes that are still needed to authenticate packets that the server expects the client to process. The same packet hash MAY be sent in more than one MC_INTEGRITY frame. Servers SHOULD prioritize retransmission of MC_INTEGRITY information whose absence is likely to cause receivers to exceed the Max Authentication Delay advertised for the channel.¶

12.1. Constraints on Stream Data

Note that when a newly connected client joins a channel, the client will only be able to receive application data carried in stream frames delivered on that channel when they have received the stream data starting from offset 0 of the stream.¶

This usually means that new streams must be started for application data carried in channel packets whenever there might be new clients that have joined since an earlier stream started. If the server deems it convenient, it could also send preceding data for that stream over the unicast connection to catch the client up.¶

With broadcast video, this usually means a new stream is necessary for every video segment or group of video frames since new clients will join throughout the broadcast, whereas for video conferencing, it could be possible to start a new stream whenever new clients join the conference without needing a new stream per object.¶

12.2. Application Use Cases

There are several known applications that could benefit from using multicast QUIC, either with their own custom application-layer transport or with one of the transports discussed in Section 12.3. A few examples include:¶

• Existing multicast-capable applications that are modified to use QUIC datagrams instead of UDP payloads can potentially get improved encryption and congestion feedback, while keeping existing error recovery techniques (e.g. techniques based on the forward error correction (FEC) framework in [RFC6363]).¶

  • An external tunnel could supply this kind of encapsulation without modification to the sender or receiver for some applications, while retaining the benefits of multicast scalability¶

  • Using QUIC datagrams in place of UDP packets could usefully support existing implementations of file-transfer protocols like FLUTE [RFC6726] or FCAST [RFC6968] to enable file downloads such as operating system updates or popular game downloads, but adding encryption, packet-level authentication, and congestion control as provided by QUIC.¶

• Conferencing systems, especially within an enterprise that can deploy multicast network support, often can save significantly on server costs by using multicast¶

• The traditional multicast use case of broadcasting of live sports with a set-top box would benefit from an interoperable system such as these QUIC extensions that can fall back to unicast transparently as needed, for example if there are a few customers who installed a non-multicast-capable home router.¶

• Smart TVs or other video playing in-home devices could interoperate with a standard sender using multicast QUIC, rather than requiring proprietary integrations with TV operators.¶

12.3. Data Transport Use Cases

This section outlines considerations for some known transport mechanisms that are worth highlighting as potentially useful with multicast QUIC.¶

12.4. Moving Clients Between Channels

MC_LEAVE and MC_RETIRE take effect immediately when processed by the receiver. These frames do not provide a mechanism for draining a channel up to a packet-number boundary.¶

A server that wants to minimize loss when moving receivers away from a channel SHOULD stop scheduling new data on the old channel before sending MC_LEAVE or MC_RETIRE, or provide any required replacement data over the associated unicast connection or another channel.¶

For example, when switching receivers from one channel to another, a server can stop sending new application data that is important for those receivers on the old channel, send any transition data on the unicast connection or the new channel, and then send MC_LEAVE or MC_RETIRE for the old channel.¶

12.5. Graceful Degradation

Clients with multicast QUIC support can stop accepting multicast for a variety of reasons.¶

Applications like live broadcast-scale video that rely on multicast QUIC may benefit from anticipating that clients might stop using multicast and providing data feeds with similar content that can scale even if many clients stop using multicast, for example by ensuring that a lower-bitrate rendition can still be delivered over unicast to all or most of the clients simultaneously, and ensuring that the server has a way to make the client start using the low-bitrate version when it switches to unicast.¶

While some existing Adaptive Bitrate video players might have an easy way to provide this, other video players might need specialized logic to provide the server a way to control what bitrate individual clients consume. Although under ideal conditions it may often be possible using features like server push (Section 12.3.1) to use unmodified existing HTTP-based video players with multicast QUIC, in practice it may require extra development at the application level to make a player that robustly delivers a good user experience under variable network conditions, depending on the scalability gains that multicast transport is providing and the Adaptive Bitrate algorithms the player is using.¶

12.6. Server Scalability

Use of QUIC multicast channels can provide large scalability gains, but there still will be significant scaling requirements on server operators to support a large client footprint.¶

Servers, possibly many of them, still will be required to maintain unicast connections with all the clients and provide for handling MC_ACK frames from the clients, delivering MC_INTEGRITY frames, managing the clients' channel join states, and providing recovery for lost packets.¶

Further, the use of multicast channels likely requires increased coordination between the different servers, relative to services that operate completely independently.¶

For large deployments, server implementations will often need to operate on separate devices from the ones generating the multicast channel packets, and will need to be designed accordingly.¶

As several MC_ACKs can be bundled for efficiency purposes, servers SHOULD make sure that information contained in packets is stored and able to be retransmitted for a reasonable time. This SHOULD be at least the max_ack_delay of a channel plus half the RTT between client and server. The MC_ACK policy advertised in MC_ANNOUNCE controls when clients send MC_ACK frames for a channel. Clients MAY send MC_ACK frames more frequently than this policy requires, but SHOULD avoid sending them less frequently. Servers should choose Max ACK Delay, Ack-Eliciting Threshold, and Reordering Threshold values that balance uplink load against the need for timely loss, congestion, ECN, and liveness feedback.¶

12.7. Address Collisions

Multicast channels at the network layer are addressed with a source IP, a destination group IP address, and a destination UDP port.¶

These offers a number of potential address collision considerations that are worth mentioning:¶

1. If properties change for the data being used in a channel (for example, new video encoding settings might result in a change to the expected max rate for a video feed), a server might reuse the same network addresses in a new QUIC multicast channel, and might send a join for the new channel and a leave for the old channel to clients that can support the new max rate. If they arrive together, this could be handled by the client without making a change to the IGMP or MLD membership state, as an optimization that can prevent the need for some recovery, or even by reusing the same UDP socket. Doing so does not change any requirements for the channel state management at the QUIC layer, and as long as the situation is transient, should not result in leaving due to Excessive Spurious Traffic even if some packets were reordered or may still be in flight.¶

2. As described in Section 6 of [RFC4607], link-layer addresses can be linked to the low-order bits of multicast addresses, and may be the same for different group destinations. Collisions in the link-layer addressing, even with traffic that comes from other sources, can cause congestion or receiver CPU load for colliding channels that might be different from that seen with other channels that were delivered with apparently the same network paths.¶

3. Even though multicast QUIC uses only source-specific multicast, older networks with devices that don't have IGMPv3 or MLDv2 support can propagate the joins as any-source multicast. If there are active senders sending to that destination, this can cause network congestion and CPU load due to discarding packets from the wrong source, even though at the application layer the UDP socket won't receive those packets from the wrong source.¶

4. If different channels use the same (S,G) but different UDP ports, they will share the same multicast forwarding tree in an IP network. This is often useful when the data in the channels are linked, for example if MC_INTEGRITY frames are carried on one channel for packets carried on another channel, because it provides some fate-sharing for the linked data. However, for data that is not so linked, it would generally be a disadvantage to share the (S,G) because the network link of any receiver joined to one of those channels but not the other would receive both packets and throw away the data for the un-joined port, causing extra congestion and CPU load for the receiving device.¶

12.8. Buffering Unauthenticated Packets

Clients need to buffer multicast packets that have been received but not yet authenticated if they want to process those packets after the corresponding MC_INTEGRITY information arrives. The amount of memory needed for this buffer is a function of the channel rate, the delay in receiving integrity information, packet reordering, and implementation policy.¶

Max Authentication Delay is a channel property because the amount of receiver buffering required for unauthenticated packets depends on the channel's rate, the way integrity information is distributed for that channel, and the latency requirements of the application data carried on that channel. For example, a low-latency media channel might require integrity information to arrive quickly, while a file-transfer or software-update channel might tolerate a larger authentication delay in exchange for lower unicast integrity traffic or larger integrity blocks.¶

Servers SHOULD choose Max Authentication Delay values that are appropriate for the channel's media or application latency requirements and for expected receiver memory constraints. Servers SHOULD send and retransmit MC_INTEGRITY information so that packets can be authenticated within the advertised Max Authentication Delay under normal operating conditions. Clients MAY use local policy to impose a smaller buffering limit than the value advertised by the server, in which case they might discard unauthenticated packets or leave the channel.¶

15.1. Normative References

[I-D.draft-ietf-mboned-ambi]

Holland, J., Rose, K., and M. Franke, "Asymmetric Manifest Based Integrity", Work in Progress, Internet-Draft, draft-ietf-mboned-ambi-05, 17 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mboned-ambi-05>.

[I-D.draft-ietf-mboned-cbacc]

Holland, J., Rose, K., and M. Franke, "Circuit Breaker Assisted Congestion Control", Work in Progress, Internet-Draft, draft-ietf-mboned-cbacc-06, 17 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mboned-cbacc-06>.

[I-D.draft-ietf-quic-multipath]

Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Managing multiple paths for a QUIC connection", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-21, 17 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-21>.

[I-D.draft-krose-multicast-security]

Rose, K., Franke, M., and J. Holland, "Security and Privacy Considerations for Multicast Transports", Work in Progress, Internet-Draft, draft-krose-multicast-security-07, 7 May 2025, <https://datatracker.ietf.org/doc/html/draft-krose-multicast-security-07>.

[I-D.ietf-quic-ack-frequency]

Iyengar, J., Swett, I., and M. Kühlewind, "QUIC Acknowledgment Frequency", Work in Progress, Internet-Draft, draft-ietf-quic-ack-frequency-14, 5 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-14>.

[IANA.tls-parameters]

IANA, "Transport Layer Security (TLS) Parameters", <https://www.iana.org/assignments/tls-parameters>.

[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>.

[RFC8085]

Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.

[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>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC9001]

Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.

[RFC9002]

Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

[RFC9221]

Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/rfc/rfc9221>.

15.2. Informative References

[I-D.draft-ietf-masque-h3-datagram]

Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", Work in Progress, Internet-Draft, draft-ietf-masque-h3-datagram-11, 17 June 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram-11>.

[I-D.draft-ietf-webtrans-http3]

Frindell, A., Kinnear, E., and V. Vasiliev, "WebTransport over HTTP/3", Work in Progress, Internet-Draft, draft-ietf-webtrans-http3-15, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-15>.

[I-D.draft-michel-quic-fec]

Michel, F. and O. Bonaventure, "Forward Erasure Correction for QUIC loss recovery", Work in Progress, Internet-Draft, draft-michel-quic-fec-01, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-michel-quic-fec-01>.

[MERKLE]

Merkle, R., "Secrecy, Authentication, and Public Key Systems", Computer Science Series, UMI Research Press, ISBN: 9780835713849 , 1983.

[RFC4607]

Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/rfc/rfc4607>.

[RFC6363]

Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/rfc/rfc6363>.

[RFC6726]

Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <https://www.rfc-editor.org/rfc/rfc6726>.

[RFC6968]

Roca, V. and B. Adamson, "FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6968, DOI 10.17487/RFC6968, July 2013, <https://www.rfc-editor.org/rfc/rfc6968>.

[RFC9114]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.