Internet-Draft P2P QUIC July 2023
Thatcher Expires 11 January 2024 [Page]
Audio/Video Transport Core Maintenance
Intended Status:
Standards Track
P. Thatcher



This document describes how to combine ICE and QUIC to do p2p QUIC.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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 January 2024.

Table of Contents

1. Introduction

ICE [RFC8445] is a protocol for establishing peer-to-peer (p2p) connections. It can be combined with client-server protocols such as DTLS [RFC9147] for p2p versions of those protocols. This document describes how to use ICE with QUIC [RFC9000] for p2p QUIC connections.

2. Terminology and Notation

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.


The QUIC ALPN MUST be "q2q".

4. (De)multiplexing ICE and QUIC

QUIC packets MUST be sent using the ICE selected candidate pair.

ICE and QUIC packets are demultiplexed using the STUN magic cookie. If a packet contains a STUN magic cookied, it MUST treated as an ICE packet. If it does not contain a STUN magic cookie, it SHOULD be treated as a QUIC packet (but further demultiplexing between QUIC and other protocols is possible).

5. Signaling

In addition to all signaling necessary for ICE (ICE parameters and candidates), the following information MUST be signaled or otherwise negotiated between the peers: - Which side will take on the active (client) or passive (server) role. - Certificate fingerprint(s) - Whether or not to enable the grease bit - Whether or not to the MuliplexingID is used

6. Certificate verification

Peers MAY use self-signed certificates. Each peer MUST verify the certificate, meaning a QUIC implementation MUST support a server verifying a client certificate.

7. Grease bit

Peers SHOULD enable and use the grease bit if only multiplexing ICE and QUIC. When multiplexing other protocols that conflict with the grease bit, peers SHOULD NOT use the grease bit.

8. Multipath

QUIC multipath SHOULD NOT be used unless it is known that one of the peers is a server.

9. QUIC datagrams

QUIC datagrams SHOULD be supported.

10. Congestion control

A real-time congestion control algorithm SHOULD be used, which may require extensions to QUIC (such as additional timestamps in feedback messages) and additional signaling.

11. QUIC Pings

ACKed QUIC PING frames MAY be treated the same as a succesful ICE check, such that a peer may choose to send QUIC PING frames instead of ICE checks once an ICE candidate pair has had at least one successful ICE check.

12. Network Migration

Network migration SHOULD be done using ICE, not QUIC. But ICE migrates between candidate pairs, QUIC should change behavior (such as congestion control) as if it had done a network migration, but it SHOULD NOT change the connection ID due to ICE migration.

13. MultiplexingID

Because it is often difficult to obtain an ICE connection, it is often advantageous to multiplex many uses over a single ICE connection. For example, one may wish to send control data, real-time audio and video, and real-time data altogether over the same ICE connection. If all of these uses are done using QUIC, there must be a way to distinguish multiple uses of QUIC within the same QUIC connection, both for streams and for datagrams.

The MultiplexingID is an optional, variable-length integer at the beginning of every QUIC datagram and stream. If it is negotiated to be used, it MUST be included on every datagram and stream. If it is not negotiated to be used, it MUST NOT be included on any datagram or stream.

The variable-length encoding is the same as used by QUIC, as defined in section 16.

14. SDP

If SDP is used for signaling, the media type may be "audio", "video", or "application". The transport protocol MUST begin with "UDP/QUIC". The transport protocol suffix combined with the media format may be any values which describe the protocol used on top of QUIC, either defined by other specifications or by applications. The media format MAY be the value "generic". The ICE parameters and candidates are signaled as defined by ICE ("a=ice-ufrag", "a=ice-pwd", "a=ice-options", "a=candidate"). The QUIC role and fingerprints are signaled using the same attributes as DTLS ("a=setup", and "a=fingerprint"). QUIC options are negotiated the same as ICE options but with an "a=quic-options" field. The grease bit defaults to off unless a QUIC option of "grease" is included. The MultiplexingID is signaled using an "a=mid" line, and the value MUST be a base-10 integer. If any "a=mid" is specified in any QUIC m-section in a BUNDLE group, then all QUIC m-sections in the same BUNDLE group MUST have an "a=mid" specified.

For example:

o=- 4962303333179871722 1 IN IP4
t=0 0
a=group:BUNDLE 1 2 3
m=audio 9 UDP/QUIC/RTP/AVPF 99
a=rtpmap:99 OPUS/4800/2
m=video 9 UDP/QUIC/RTP/AVPF 100
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
m=application 9 UDP/QUIC generic

15. Security Considerations

This document is subject to the security considerations of ICE and QUIC.

16. IANA Considerations

The ALPN "q2q" should be registered.

17. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, , <>.
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <>.
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, , <>.

Author's Address

Peter Thatcher