Audio/Video Transport Core Maintenance S. Dawkins Internet-Draft Wonder Hamster Internetworking LLC Intended status: Experimental 22 January 2026 Expires: 26 July 2026 RoQ Candidates with Interactive Connectivity Establishment (ICE) draft-dawkins-avtcore-roq-ice-latest Abstract This document describes the use of Interactive Connectivity Establishment (ICE) procedures to select candidate paths for use with RTP over QUIC (RoQ). About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://SpencerDawkins.github.io/roq-ice/draft-dawkins-avtcore-roq- ice.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dawkins-avtcore-roq-ice/. Discussion of this document takes place on the Audio/Video Transport Core Maintenance Working Group mailing list (mailto:avt@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/avt/. Subscribe at https://www.ietf.org/mailman/listinfo/avt/. Source for this draft and an issue tracker can be found at https://github.com/SpencerDawkins/roq-ice. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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 26 July 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Definitions 2.1. Notes for Readers 3. Background 4. Additional Application Considerations for RoQ ICE Usage 4.1. Candidate Selection 4.2. Candidate Preferences 4.3. Candidate Collection Techniques 4.4. Receiving Initial Offers and Composing Answers 4.5. Parallel QUIC Connection Initiation 5. Security Considerations 6. IANA Considerations 7. Normative References Acknowledgments Author's Address 1. Introduction This document describes the use of Interactive Connectivity Establishment (ICE) procedures ([RFC8445]) to select candidate paths for use with RTP over QUIC (RoQ) ([I-D.ietf-avtcore-rtp-over-quic]). 2. 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. 2.1. Notes for Readers (*Note to RFC Editor:* if this document ever reaches you, please remove this section) SDP for RoQ is defined in a separate document [I-D.draft-ietf-avtcore-sdp-roq], which mentions use of ICE with RoQ. This document describes how RoQ implementations would use ICE candidates as part of RoQ RTP session setup. That description might reasonably be folded back into [I-D.draft-ietf-avtcore-sdp-roq] at some point, but is currently separated to allow QUIC experts and ICE experts to review the description without having to excavate it as part of a larger specification. This document has not yet been adopted by any IETF working group, so does not carry any special status within the IETF. 3. Background The QUIC transport protocol ([RFC9000]) is encapsulated in UDP ([RFC768] and [RFC2460]), so in theory, a RoQ endpoint could use the ICE procedures described in [RFC8445] to identify candidate endpoint addresses and choose among them, and then attempt to open a QUIC connection allowing use of RoQ to carry RTP media. While that would work in theory, in practice, the potential for confusion between an RTP endpoint expecting to use UDP encapsulation and an RTP endpoint expecting to use RoQ encapsulation make this a bad idea. This specification defines a new ICE Transport Protocol (Section 6), so that RTP endpoints can distinguish between non-RoQ flows and RoQ flows, and provides additional application considerations (Section 4) when ICE is used for RoQ flows. The intention for ICE usage to identify RoQ candidates is that it should be as similar as possible to ICE usage to identify UDP candidates ([RFC8445]). "As similar as possible" does not mean "identical", so the relevant differences are described in Section 4. 4. Additional Application Considerations for RoQ ICE Usage The reason for defining a new ICE Transport Protocol identifier is to allow ICE endpoints to distiguish between candidates for RTP media flows encapsulated in UDP and candidates for RTP media flows encapsulated in RoQ. Without a new ICE Transport Identifier, it is difficult to tell the difference, because RoQ is encapsulated in QUIC, and then in UDP. Because UDP is very close to a null transport protocol (allowing port multiplexing, but not much more), and QUIC is a modern transport protocol, there are differences that application developers need to be aware of, in ICE candidate selection. These differences are described in this section. *Editor's Note:* The following subsections are very much works in progress! 4.1. Candidate Selection The description for gathering candidates in Section 4.1 of [RFC6544] includes a number of helpful considerations that would also apply to RoQ endpoints, including, for instance, deciding whether it is preferable to have no media at all, rather than to have media over TCP. Wise implementors will study those considerations carefully. 4.2. Candidate Preferences The recommended formula for candidate type preferences, referenced in Section 4.2 of [RFC6544] and described in Section 5.1.2.1 of [RFC8445] SHOULD also be used for RoQ candidates. *Editor's Note:* Section 4.2 of [RFC6544] suggests recommended candidate type preferences for NAT-assisted candidates (105) and UDP-tunneled candidates (75). Are RECOMMENDED candidate type preferences useful for RoQ candidates? 4.3. Candidate Collection Techniques *Editor's Note:* Section 5 of [RFC6544] provides a helpful outline for techniques that can be used to obtain candidates for use with ICE RoQ, but we still need to go through the details (for example, do we need to make recommendations about use of TURN-IPv6, Teredo, or SOCKS IPv4-IPv6 gatewaying for obtaining IPv6 RoQ candidates? The recommendations for ICE-TCP date from 2012!) 4.4. Receiving Initial Offers and Composing Answers The procedure described in Section 6 of [RFC6544] for receiving the initial offer and answer also apply for RoQ, except that RoQ candidates are encoded as described in Section 3 and Section 4 of [I-D.draft-ietf-avtcore-sdp-roq]. 4.5. Parallel QUIC Connection Initiation Because RoQ is also connection-oriented, the possibility described in Section 6.1 of [RFC6544] for an ICE offerer to initiate a QUIC connection to carry RoQ media sessions on a selected candidate pair in parallel with ICE-lite operation also applies, if the offerer is using the a=setup:active attribute. When this is the case, the requirements that the answerer accept that offer and repspond to it while keeping the already-created connectionin that section also apply to RoQ. *Editor's Note:* Harald Alvestrand notes that QUIC doesn't have peer-to-peer extensions specified, so the client end of the connection will have to specify port 9 (discard), meaning that it can do outgoing QUIC but not incoming QUIC over this UDP port pair. What other implications follow from this limitation? 5. Security Considerations The Security Considerations contained in [RFC8445], [RFC6445], [RFC9000], and ([I-D.ietf-avtcore-rtp-over-quic]) are included here by reference. 6. IANA Considerations IANA has created a sub-registry "ICE Transport Protocols" in the "Interactive Connectivity Establishment (ICE)" registry for ICE candidate-attribute transport extensions. This specification adds the "RoQ" token to that registry. +=======+================================+ | Token | Reference | +=======+================================+ | RoQ | (This Specification Section 6) | +-------+--------------------------------+ Table 1 7. Normative References [I-D.draft-ietf-avtcore-sdp-roq] Dawkins, S. and V. P. Pascual, "SDP Offer/Answer for RTP over QUIC (RoQ)", Work in Progress, Internet-Draft, draft- ietf-avtcore-sdp-roq-00, 11 October 2025, . [I-D.ietf-avtcore-rtp-over-quic] Engelbart, M., Ott, J., and S. Dawkins, "RTP over QUIC (RoQ)", Work in Progress, Internet-Draft, draft-ietf- avtcore-rtp-over-quic-14, 20 March 2025, . [ICE-protos] "ICE Transport Protocols", September 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC6445] Nadeau, T., Ed., Koushik, A., Ed., and R. Cetin, Ed., "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", RFC 6445, DOI 10.17487/RFC6445, November 2011, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] 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, July 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Acknowledgments This draft builds on considerable previous work that resulted in the base "Interactive Connectivity Establishment (ICE)" specification ([RFC8445]) and the related "TCP Candidates with Interactive Connectivity Establishment (ICE)" specification [RFC6544]. The author of this specification owes those authors many thanks. Author's Address Spencer Dawkins Wonder Hamster Internetworking LLC United States of America Email: spencerdawkins.ietf@gmail.com