]> Cisco

fluffy@iii.ca

Cisco

snandaku@cisco.com

Web and Internet Transport Media Over QUIC media over quic svcb https records service discovery srv mdns dns-sd This document defines how MOQT clients discover server endpoints using DNS and Multicast DNS (mDNS). It specifies SVCB and HTTPS DNS record mappings for the moqt URI scheme, SRV records as a fallback mechanism, and DNS-SD over mDNS for local network discovery. About This Document Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Media over QUIC Transport (MOQT) protocol identifies servers using the moqt URI scheme. Clients establish MOQT sessions over native QUIC or over WebTransport (). This document defines three complementary discovery mechanisms:

SVCB and HTTPS records ():

Unicast DNS records that carry connection parameters — including supported ALPNs — alongside address records. Section 2.4 of requires a mapping document for each URI scheme using SVCB; this document fulfills that requirement for moqt.

SRV records ():

Unicast DNS records that provide port and target information for load balancing and failover. They carry no ALPN or connection parameters.

mDNS and DNS-SD ():

Multicast DNS and DNS Service Discovery for local network discovery without a central DNS server.

Conventions and Definitions This specification uses the terminology from , , and . 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 when, and only when, they appear in all capitals, as shown here.

SVCB and HTTPS Records for MOQT

Record Types MOQT uses two DNS record types:

SVCB RRs (RR type 64):

For native QUIC MOQT endpoints. Published at a moqt-specific owner name (); carries moqt/moqt-N ALPNs only.

HTTPS RRs (RR type 65):

For WebTransport MOQT endpoints. MAY carry both moqt and HTTP ALPN (h3). moqt URIs using WebTransport map to https URIs (); both schemes default to port 443.

Record Names

SVCB Record Name For a moqt URI with host H and port P, the SVCB (type 64) owner name is:

• _moqt.H when P is 443 or omitted (defaulting to 443).
• _P._moqt.H when P is any other value.

HTTPS Record Name For a moqt URI with host H and port P, the HTTPS (type 65) owner name is:

• H when P is 443 or omitted (defaulting to 443).
• _P._https.H when P is any other value, as specified in .

Default ALPN Identifiers Unlike https (which implies h2/h3), the moqt URI scheme has no implicit default ALPN. Every ServiceMode record MUST include an explicit alpn SvcParamKey listing all supported protocols. The following ALPN identifiers are defined for MOQT:

moqt:

Native QUIC, published MOQT specification (). MUST appear in SVCB records; MAY appear in HTTPS records when the server supports both native QUIC and WebTransport.

moqt-N (where N is a non-negative integer):

Native QUIC, draft version N (e.g., moqt-15). Ephemeral; MUST NOT be used in production. Same record-placement rules as moqt.

h3:

WebTransport over HTTP/3 (). HTTPS records only.

A client MUST treat a record whose alpn contains none of its supported identifiers as unusable and proceed as if no record were present. TODO: Define ALPN identifier and record-placement rules for qmux once the qmux specification matures.

Automatically Mandatory SvcParamKeys The moqt scheme introduces no additional automatically mandatory SvcParamKeys; standard processing rules apply. Omitting alpn is equivalent to publishing a record with no supported protocols (), which clients will treat as unusable.

Relevant SvcParamKeys

alpn and no-default-alpn The alpn SvcParamKey MUST be present in every ServiceMode record (see ). The no-default-alpn SvcParamKey MUST NOT appear; with no default ALPNs defined, it has no effect and would be misleading.

port When present, port specifies the UDP port (native QUIC or WebTransport over HTTP/3). When absent, the port from the moqt URI is used, defaulting to 443.

ech ECH MAY appear in SVCB or HTTPS records. Clients that support ECH SHOULD use it; without it, the moqt URI authority is exposed in the TLS SNI extension ().

ipv4hint and ipv6hint MAY be used to provide address hints that reduce DNS round trips. Hints are advisory and do not replace A/AAAA resolution.

ALPN Selection A client uses the alpn SvcParamKey to determine which connection modes the server supports and connects using any ALPN identifier from the record that it supports. Selection among multiple supported ALPNs is a matter of local client policy and is out of scope for this document.

SRV Records for MOQT SRV records provide port and target for load balancing and failover but carry no ALPN or connection parameters.

SRV Record Names For a moqt URI with host H, SRV queries are performed at:

• _moqt._udp.H (both native QUIC and WebTransport over HTTP/3 use UDP).

Using SRV Target and Port When SRV records are found:

• The target hostname and port from the SRV record MUST be used as the connection endpoint.
• The original moqt URI's host component MUST be used as the TLS SNI value and for certificate validation; it MUST NOT be replaced by the SRV target hostname.
• SRV targets with a port of 0 and a dot (.) target indicate that the service is not available at this name and MUST be treated as indicating no service.

Interaction with SVCB When SVCB (type 64) or HTTPS (type 65) records are available and usable for a moqt authority, clients SHOULD prefer them over SRV records and MAY skip the SRV query entirely. Operators SHOULD publish SVCB and/or HTTPS records rather than (or in addition to) SRV records for new deployments.

mDNS and DNS-SD Discovery for MOQT mDNS and DNS-SD enable MOQT discovery on local links without a central DNS server.

DNS-SD Service Names MOQT uses the following DNS-SD service types, which are also registered for SRV use ():

_moqt._udp:

Advertises MOQT endpoints (native QUIC and WebTransport over HTTP/3).

A MOQT relay on the local network announces itself by publishing PTR, SRV, and TXT records under the appropriate service type in the .local. domain, as specified in .

TXT Record Parameters The TXT record for a MOQT DNS-SD instance MUST contain the following key-value pair:

alpn:

The ALPN identifier for the transport mode advertised by this instance (e.g., moqt, moqt-15, h3).

A client MUST treat an instance whose TXT record does not contain a recognized alpn value as unusable.

URI Normalization For comparison purposes, the URI, or part of the URI, is put in a canonical form and then bitwise compared to the data from the X.509 certificate after putting it into canonical form. This section defines how to create the canonical form. The URI MUST be normalized using Case Normalization and Percent-Encoding Normalization as specified in Sections 6.2.2.1 and 6.2.2.2 of . The "." and ".." sequences have no special meaning in MOQT URIs and are not changed during normalization. If the port is missing, it MUST be replaced with the default port (443). If the URI reg-name ends in a ".", that MUST be removed. Internationalized Domain Names in the reg-name MUST be converted to IDNA format as defined in . When comparing hostnames, wildcard matching MUST NOT be supported and the "*" character has no special meaning.

X.509 Certificate Matching The fields referenced in this section are defined in and . The CN-ID field as defined in MUST NOT be used. If any one of the following identifiers in the subjectAltName of the certificate matches the URI, then the certificate is valid for that URI.

• dNSName: The canonicalized dNSName from the certificate matches the host part of the authority from the canonicalized URI.
• iPAddress: The host part of the authority from the canonicalized URI, parsed as an IP address, matches the iPAddress value from the certificate.
• uniformResourceIdentifier: The canonicalized uniformResourceIdentifier MUST match the canonicalized URI with the query and fragment removed.
• SRVName: Matched as described in Section 4 of using the host part of the authority from the canonicalized URI as the name restriction and a SRVName restrictions of "_moqt".

SVCB and SRV Indirection When a client is redirected to a different target host, certificate matching MUST be performed against the authority from the original moqt URI, not the resolved target name. This is consistent with the requirements in and with the SRV rules in of this document. SRVName matching () applies regardless of whether the client discovered the endpoint via SRV records or SVCB records, because the _moqt service type is the same in both cases.

Security Considerations TODO

IANA Considerations

Service Name Registration IANA is requested to register the following entry in the "Service Name and Transport Protocol Port Number Registry":

• Service Name: moqt
• Transport Protocol(s): udp
• Assignee: IETF
• Contact: moq@ietf.org
• Description: Media over QUIC Transport
• Reference: This document and
• Port Number: 443

This registration covers use of the _moqt._udp service label in SRV records () and DNS-SD ().

ALPN Registration The ALPN identifier moqt is already registered in the "TLS Application- Layer Protocol Negotiation (ALPN) Protocol IDs" registry by . No additional registrations are requested by this document.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK] Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. Informative References This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP").

Acknowledgments TODO: Acknowledgments to be added.