]> Google Switzerland GmbH

Gustav-Gull-Platz 1 Zürich 8004 Switzerland ietf@trammell.ch

Web and Internet Transport Transport and Services Working Group HTTP port allocation IANA service registration provides guidance on the use of port numbers and the criteria for new port assignments, including a test for whether a proposed service is distinct from an existing service. It gives the example that "an automated system that happens to use HTTP framing -- but is not primarily accessed by a browser -- might be a new service." It also might not. This document clarifies the application of the distinct-protocol test in Section 7.1 to services built on HTTP as a substrate, in light of HTTP's evolution since its publication, and provides guidance to applicants and reviewers on when an HTTP-based service qualifies for a new port assignment and when it does not. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction provides guidance on when a new port assignment is warranted, including a distinctness test in Section 7.1: a new service merits an assignment only if an unmodified client of an existing service cannot interact with it. In the decade since that document was published in 2015, HTTP has become an overwhelmingly popular de facto substrate for application protocol design -- a development that both documents and embraces. Section 7.1's observation that "an automated system that happens to use HTTP framing -- but is not primarily accessed by a browser -- might be a new service" was intended to leave room for novel cases. The evolution of and investment in the HTTP ecosystem since then has only made the use of HTTP and the ecosystem surrounding it as a substrate more attractive. One practical consequence of this development has been some confusion about whether new protocols over HTTP are new protocols in the sense of "requiring a port assignment". This document clarifies how the Section 7.1 distinctness test applies to HTTP-based services, and provides guidance to applicants and reviewers on when it is and is not satisfied. It does not replace , but rather updates its application to reflect the maturity of the HTTP ecosystem. Specifically, it addresses how modern deployment patterns—such as ubiquitous TLS, SNI, ALPN, and user-space demultiplexing—have resolved the practical cohabitation and access control issues that have previously motivated requests for dedicated port assignments.

HTTP as an Application Transport Substrate HTTP has evolved since its origins as the basis of the World Wide Web. HTTP/2 redesigned HTTP's wire format around multiplexed binary framing with non-browser use as an explicit design goal; HTTP/3 continues this evolution over QUIC . provides detailed guidance on building new protocols beyond the web atop HTTP. The benefits of this approach are substantial: HTTP-based services can leverage existing infrastructure including reverse proxies, load balancers, content delivery networks, and firewalls; they interoperate naturally with web clients; and they inherit well-established security properties including TLS certificate management and authentication frameworks. Operating on standard web ports (80 and 443) also improves compatibility with existing network tooling—such as packet analyzers and diagnostic tools that are pre-configured for HTTP—and maximizes the likelihood of traversing firewalls that restrict outbound traffic to standard web ports. Such traversal is not guaranteed: firewalls increasingly apply deep packet inspection and application-behavior analysis to traffic on ports 80 and 443, so using these ports offers the best chance of traversal rather than a certainty of it. Furthermore, reusing these ports directly supports transport port conservation, a key goal of . The HTTP ecosystem also provides a rich set of mechanisms for service differentiation, discovery, and coexistence that do not require dedicated port assignments. Multiple independent services can share ports 80 and 443 concurrently on the same host using path-based routing (via reverse proxies or API gateways), host-based routing (via TLS Server Name Indication (SNI) ), or protocol-based multiplexing (via Application-Layer Protocol Negotiation (ALPN) ). These user-space demultiplexing techniques are standard in modern deployments, resolving the "first binder wins" problem inherent in OS-level transport-layer demultiplexing. Additionally, sharing these ports allows network operators to leverage Layer 7 security policies (such as SNI- or ALPN-based filtering) rather than relying on port-based firewall rules. A service that requires a new ALPN identifier should register it in the IANA TLS ALPN Protocol IDs registry, not seek a new port assignment.

Evaluating HTTP-Based Protocols for Distinctness Section 7.1 of establishes one useful test for whether a proposed service warrants a new port assignment: can an unmodified client of an existing service interact with the proposed service? Interoperability implies non-distinctness, and a non-distinct protocol does not merit a new assignment. For HTTP-based services, this test is easy to implement: can an unmodified generic HTTP client tool such as curl issue requests to and receive valid responses from the proposed service? Service differentiation achieved through URL path structure, HTTP header values, Content-Type negotiation, payload schema, or authentication scheme does not constitute wire-level distinctness; these are application-layer conventions carried within HTTP, not independent protocols. This does not mean that all HTTP-based protocols are indistinct. Examples that might warrant an assignment include:

• a REST API running over the same TLS connection as a protocol with a different wire format, using a protocol-specific multiplexing scheme; or
• a protocol running on UDP or SCTP that uses a REST API over TCP as a control or management plane.

The former would not interoperate with an unmodified client, and the latter has incomplete semantics when used as such. Similarly, protocols that run natively over QUIC but do not use HTTP semantics are distinct from HTTP. While HTTP/3 runs over QUIC on port 443, a protocol that uses QUIC as a transport layer directly (without the HTTP mapping defined in ) is a different service. For example, DNS-over-QUIC (DoQ) runs directly over QUIC and is assigned a dedicated port (853), whereas DNS-over-HTTPS (DoH) layers DNS queries within HTTP sessions and runs over standard web ports. That a protocol is wire-distinct from HTTP does not by itself imply that it requires a new port assignment, however. Because ALPN allows multiple protocols to share a port, a non-HTTP protocol running directly over QUIC may coexist with HTTP/3 on port 443, selected by its own ALPN identifier rather than "h3"; media delivery protocols that can operate either over HTTP/3 or directly over QUIC are one example. Such a protocol should generally register an ALPN identifier rather than request a port. DoQ's assignment of a dedicated port (853) reflects its role as a transport-layer companion to DNS-over-TLS, which already occupies that port, rather than a general expectation that protocols running natively over QUIC receive dedicated ports. A related case involves hybrid protocols that use a UDP-based transport for primary data transfer but rely on an HTTP-based REST API for control, management, or bootstrap operations. In these cases, if the UDP component clearly warrants a dedicated port assignment on its own, the protocol designer should consider the tradeoffs of using the corresponding TCP port for the control plane versus the advantages of using standard web ports.

Application Naming Beyond Port Numbers A service built on these substrates may be identified in more than one IANA registry: a service name in the Service Name and Transport Protocol Port Number Registry (used, for example, in DNS SRV records ); an ALPN protocol identifier in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry ; and an underscored node name in the Underscored and Globally Scoped DNS Node Names registry . These registries evolved independently and are not coordinated. A single service may require entries in several of them, with no guarantee that a chosen name is available or consistent across all three. Rationalizing these namespaces is out of scope for this document; the point here is that a port assignment is only one of several forms of registration a service may need, and often not the one most relevant to how the service is actually selected on the wire.

Security Considerations The intended effect of the guidance given by this document is effectively to reduce port assignments for HTTP-based services, directing these services to use port 443 rather than dedicated port assignments. This has implications for overall network security: traffic from non-Web HTTP applications running on port 443 is less distinguishable from other traffic in the face of metadata examination. TLS deployment is more likely to be properly configured when services share the standard HTTPS port and its associated certificate management infrastructure, and network operators can apply consistent security policy across all services on that port. Section 4.4.3 notes that deploying an HTTP-based application on a non-default port carries privacy implications because the protocol becomes distinguishable from other traffic; the guidance in this document is consistent with minimizing that distinguishability.

IANA Considerations This document has no IANA actions. It is intended as guidance for IANA Transport Port Expert Reviewers.

References Normative References This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. Informative References This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] 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. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. 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 specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK]

Disclosure LLM-based tools (Claude Sonnet in Claude Code, Gemini Flash in Antigravity) were used in the workflow management, reference and archival research, initial draft generation, and editorial review of this document, in part as an evaluation of the readiness of these tools for such tasks.

Acknowledgments The author would like to thank Wesley Eddy, Michael Scharf, Joe Touch, and Christian Huitema for the feedback and input that improved this document.