Network Working Group A. McClelland Internet-Draft Start9 Intended status: Standards Track 23 June 2026 Expires: 25 December 2026 PCP Hostname Extension for SNI-Demultiplexed Port Mappings draft-start9-pcp-hostname-00 Abstract This document defines a Port Control Protocol (PCP) option, HOSTNAME, that associates one or more fully qualified domain names with a MAP request. A PCP server implementing this option demultiplexes inbound connections on a shared external port by inspecting the Server Name Indication presented in the TLS ClientHello and forwards each connection to the internal host that holds the binding for the presented name. This allows multiple internal hosts behind a single external IP address to share well-known ports (e.g. 443) provided their hostnames differ, while each host retains the ability to self- provision its mappings via ordinary PCP semantics. Demultiplexing is defined for TCP-carried TLS, with optional support for 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 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 25 December 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. McClelland Expires 25 December 2026 [Page 1] Internet-Draft PCP Hostname Extension June 2026 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 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 3. The HOSTNAME Option . . . . . . . . . . . . . . . . . . . . . 4 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Validity and the Fallback Mapping . . . . . . . . . . . . 5 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Mapping Table . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Conflicts . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Deletion . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. TCP Demultiplexing . . . . . . . . . . . . . . . . . . . 7 4.5. QUIC Demultiplexing (OPTIONAL) . . . . . . . . . . . . . 8 4.6. Source Address Preservation . . . . . . . . . . . . . . . 9 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 6. Interaction with Other PCP Options . . . . . . . . . . . . . 10 7. Interaction with Encrypted ClientHello . . . . . . . . . . . 10 8. New Result Codes . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Applicability and Limitations . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11.1. PCP Option Code . . . . . . . . . . . . . . . . . . . . 12 11.2. PCP Result Codes . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Implementation Status . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction McClelland Expires 25 December 2026 [Page 2] Internet-Draft PCP Hostname Extension June 2026 1.1. Motivation A NAT gateway exposes one external IP address, or at most a few. A conventional PCP MAP grants an entire (protocol, external IP, external port) tuple to a single internal host, so the number of hosts that can serve HTTPS on port 443 is limited to the number of external addresses, typically one. Operators work around this with a manually configured reverse proxy or SNI proxy on the gateway, which: 1. requires central, out-of-band configuration rather than client self-provisioning, and 2. typically replaces the client source address with the proxy address, hiding the real peer from the backend. Since hosts behind a NAT typically serve public Internet domains (the names are registered in public DNS and resolve to the gateway's external address), the hostname is a natural demultiplexing key that the internal host already knows and can assert itself. This extension moves the SNI routing table into PCP, so each internal host registers its own names, and the gateway, which is already on the return path for all LAN traffic, forwards with the original client source address preserved. 1.2. Requirements Language 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. 1.3. Terminology This document uses the terminology of [RFC6887] (PCP client, PCP server, internal host, external address, mapping, mapping nonce). In addition: Hostname binding: an association, held by the PCP server, from (protocol, external IP address, external port, hostname) to an internal address and internal port, created by a MAP request carrying a HOSTNAME option. Fallback mapping: a conventional mapping (created by a MAP request with no HOSTNAME option) on a port that also has hostname bindings; it receives connections that match no hostname binding (see Section 3.2). McClelland Expires 25 December 2026 [Page 3] Internet-Draft PCP Hostname Extension June 2026 Demultiplexed port: a (protocol, external IP address, external port) tuple holding at least one hostname binding. Inbound connections to a demultiplexed port are routed per Section 4.4 or Section 4.5 rather than by conventional destination NAT. 2. Overview of Operation This section is informative; normative requirements appear in Section 3 through Section 9. 1. An internal host sends a PCP MAP request for protocol TCP, suggesting an external port (e.g. 443), and includes one or more HOSTNAME options, each carrying an FQDN such as git.example.com. 2. The PCP server checks each requested name against its hostname bindings for that (external IP, external port). If no conflicting binding exists, it creates bindings with the requested lifetime and returns success, echoing the HOSTNAME options. 3. Other internal hosts may map the same external port with different hostnames; the port is shared because the mapping key is extended to (protocol, external IP, external port, hostname). 4. For each inbound TCP connection to a demultiplexed port, the server accepts the connection, reads the TLS ClientHello, extracts the server_name extension, selects the matching binding, and splices the connection to the bound internal host. 5. Because the PCP server is the default gateway for the internal network, it originates the internal leg with the original client's source address and port (transparent mode, Section 4.6); return packets necessarily traverse the gateway, which steers them back into the spliced connection. A host requests forwards for multiple hostnames either by including multiple HOSTNAME options in a single MAP request or by issuing multiple MAP requests; see Section 5. 3. The HOSTNAME Option 3.1. Format The option follows the PCP option format (Section 7.3 of [RFC6887]): McClelland Expires 25 December 2026 [Page 4] Internet-Draft PCP Hostname Extension June 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Reserved | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : hostname (variable length) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: HOSTNAME Option Format Option Code: TBD1, in the optional-to-process range. Option Length: length of the hostname field in octets (1 to 255). The option data is zero-padded to a 32-bit boundary per [RFC6887]; padding is not included in Option Length. hostname: the name to bind, encoded exactly as it appears on the wire in the SNI HostName field (Section 3 of [RFC6066]): ASCII, internationalized names as A-labels [RFC5890], no trailing dot, no NUL octets, total length 1 to 255 octets. Literal IPv4 and IPv6 addresses MUST NOT be used (Section 3 of [RFC6066]). Comparison is case-insensitive; servers SHOULD normalize names to lowercase on receipt. A syntactically invalid hostname MUST be rejected with MALFORMED_OPTION. Because the option code is in the optional-to-process range, a server that does not implement this option ignores it and processes the request as a conventional MAP, granting an unrestricted port forward. This degrades gracefully: if the requesting host is the only one using the port, observable behavior is identical, and a second host receives CANNOT_PROVIDE_EXTERNAL (or an alternate port) per standard MAP processing. Clients detect whether hostname scoping was applied by checking for the echoed HOSTNAME option(s) in the response; see Section 5. 3.2. Validity and the Fallback Mapping The HOSTNAME option is valid only for the MAP opcode. A server implementing this option MUST reject any other opcode carrying it with MALFORMED_OPTION. The option is valid for protocol TCP, and for protocol UDP only on servers implementing QUIC demultiplexing (Section 4.5). A server implementing this option MUST reject a HOSTNAME option for any other protocol, or for UDP when QUIC demultiplexing is not implemented, with UNSUPP_HOSTNAME (Section 8). Clients MUST NOT request hostname McClelland Expires 25 December 2026 [Page 5] Internet-Draft PCP Hostname Extension June 2026 bindings for protocols whose servers send application data before the client (e.g. SMTP, IMAP); a server cannot detect this misuse, and such connections will stall waiting for a ClientHello and then be handled as in Section 4.4, step 4. A HOSTNAME option MAY appear multiple times in a single MAP request, each occurrence creating one binding, subject to the atomic failure semantics of Section 4.2. There is no in-option fallback syntax. A conventional MAP request (no HOSTNAME option) for the same (protocol, external IP, external port) creates the fallback mapping: connections whose ClientHello carries no server_name extension, presents a name with no matching binding, or whose initial bytes do not parse as TLS (or as QUIC per Section 4.5), are forwarded to its holder. At most one fallback mapping exists per (protocol, external IP, external port), enforced by normal MAP exclusivity. 3.3. Wildcards A hostname whose first label is * (e.g. *.example.com) requests a wildcard binding matching exactly one left-most label, with the same semantics as certificate wildcard matching. Wildcard support is OPTIONAL; servers not implementing it respond with UNSUPP_HOSTNAME (Section 8). An exact binding takes precedence over a wildcard binding. 4. Server Behavior 4.1. Mapping Table The server maintains, per (protocol, external IP, external port), a set of hostname bindings, each comprising: hostname, internal address, internal port, lifetime, and the mapping nonce of the creating client. All standard MAP processing of [RFC6887] applies (lifetime decay, renewal by matching nonce, ANNOUNCE/epoch recovery). 4.2. Conflicts If a requested hostname is already bound on that (protocol, external IP, external port) under a different mapping nonce, the server MUST NOT create or alter the binding and MUST return result code HOSTNAME_TAKEN (Section 8). If any HOSTNAME option in a request fails validation or conflicts, the entire request fails and no bindings from that request are created or modified; PCP responses are atomic per request. McClelland Expires 25 December 2026 [Page 6] Internet-Draft PCP Hostname Extension June 2026 A conventional MAP for a (protocol, external IP, external port) that has hostname bindings is permitted and serves as the fallback mapping (Section 3.2). It is subject to ordinary MAP exclusivity. Hostname bindings and the fallback mapping have independent lifetimes; expiry of one does not affect the others. 4.3. Deletion A MAP request with requested lifetime 0 carrying HOSTNAME options deletes only the named bindings, subject to the nonce-matching rules of Section 15 of [RFC6887]. A lifetime-0 request without HOSTNAME options deletes only the requester's conventional (fallback) mapping, if any. Other bindings on the port are unaffected in both cases. 4.4. TCP Demultiplexing For TCP connections arriving at a demultiplexed port, the server: 1. Completes the TCP handshake with the external client. 2. Reads until it has the full ClientHello or a parse failure, subject to a buffer cap (16384 octets, the maximum TLS plaintext record fragment, is RECOMMENDED) and a timeout (5 seconds is RECOMMENDED). ClientHellos can span multiple TCP segments and, rarely, multiple TLS records; servers SHOULD handle multi-record ClientHellos. 3. Extracts server_name, selects the binding (exact match, then wildcard, then the fallback mapping if present), and connects to the bound internal host and port, replaying the buffered bytes before splicing. 4. If no binding matches and no fallback mapping exists, the server SHOULD close the connection. Whether to reset or send a TLS alert is implementation defined; the server MUST NOT forward the connection to an arbitrary binding. Demultiplexing engages only on demultiplexed ports. A port holding only a conventional mapping is forwarded as plain destination NAT per [RFC6887], with no ClientHello inspection. When the first hostname binding is added to a port with an existing conventional mapping, the port transitions to demultiplexed mode; established connections are unaffected, and the conventional mapping's holder begins receiving only fallback traffic for new connections. The reverse transition occurs when the last hostname binding expires. The server does not terminate TLS; it requires no keys and forwards the ClientHello bytes verbatim. McClelland Expires 25 December 2026 [Page 7] Internet-Draft PCP Hostname Extension June 2026 4.5. QUIC Demultiplexing (OPTIONAL) A server MAY additionally implement demultiplexing of QUIC [RFC9000] for hostname bindings with protocol UDP. Servers implementing this section accept HOSTNAME options with protocol UDP; servers that do not MUST reject them per Section 3.2, so a client can discover support by the result code. For UDP datagrams arriving at a demultiplexed port: 1. Initial packets. A datagram beginning with a QUIC long header ([RFC8999]) of a version the server supports is processed as a candidate Initial. The server derives the Initial secrets from the client's Destination Connection ID and the version-specific salt (Section 5.2 of [RFC9001]), decrypts the packet, and reassembles the CRYPTO stream to obtain the TLS ClientHello. The ClientHello can span multiple Initial packets; the server MUST buffer and reassemble across datagrams, subject to a cap (10 datagrams or 65535 octets of CRYPTO data is RECOMMENDED) and a timeout (5 seconds is RECOMMENDED). 2. Binding selection. The server extracts server_name and selects a binding exactly as in Section 4.4, step 3. It then creates flow state keyed on the connection's 4-tuple, forwards the buffered datagrams verbatim to the bound internal host, and forwards subsequent datagrams matching the flow in both directions. No decryption is performed after binding selection, and the server never holds handshake or 1-RTT keys. 3. Flow lifetime. Flow state is removed after an idle period consistent with the gateway's UDP mapping timeout. Version Negotiation and Retry exchanges initiated by the internal host traverse the established flow and require no special handling. 4. Non-matching datagrams. Datagrams that are not parseable Initials of a supported version (including short-header packets matching no flow, long headers of unknown versions, and non-QUIC UDP payloads) are forwarded to the fallback mapping if one exists and otherwise dropped. Two consequences follow from routing on flow state. First, active connection migration and NAT rebinding both move the connection to a 4-tuple the server has no state for; such packets carry connection IDs opaque to the server and arrive as non-matching datagrams. Internal hosts serving QUIC behind a demultiplexing gateway SHOULD send the disable_active_migration transport parameter (Section 18.2 of [RFC9000]) to suppress client-initiated migration; this does not prevent NAT rebinding (Section 9.3 of [RFC9000]), which can still McClelland Expires 25 December 2026 [Page 8] Internet-Draft PCP Hostname Extension June 2026 strand a connection on an unknown 4-tuple unless coordinated connection-ID routing is in use. Coordinated connection-ID routing (e.g. QUIC-LB [I-D.ietf-quic-load-balancers]) could lift this restriction and is out of scope. Second, a client whose first flight uses a QUIC version unknown to the server cannot be demultiplexed; servers SHOULD support all current standard versions and treat unknown-version long headers as non-matching rather than attempting Version Negotiation themselves. 4.6. Source Address Preservation Servers SHOULD originate the internal leg of demultiplexed TCP connections using the external client's source address and port (e.g. via IP_TRANSPARENT on Linux), relying on their position as the internal network's gateway to capture return traffic. When operating in this mode the forwarded connection is, from the internal host's perspective, indistinguishable from a direct destination-NAT forward. A server that cannot operate transparently uses its own address on the internal leg; this behavior is visible to internal hosts and operators should document it. QUIC demultiplexing (Section 4.5) forwards datagrams at the IP layer and preserves the source address inherently. 5. Client Behavior * Clients include one HOSTNAME option per name. Given the atomic failure semantics of Section 4.2, clients SHOULD use one MAP request per name when independent success matters, and MAY batch multiple options in one request when the names succeed or fail together (e.g. a certificate SAN set). * Clients MUST examine the response for echoed HOSTNAME options. Absence means the server did not process the option and the granted mapping is unrestricted; clients that require hostname scoping MAY delete such a mapping. Against a server that ignores the option, both request patterns above degrade safely: a batched request yields one unrestricted mapping covering all names, and per-name requests for the same internal port resolve to that same mapping ([RFC6887] keys mappings on the internal tuple), acting as refreshes rather than conflicts. McClelland Expires 25 December 2026 [Page 9] Internet-Draft PCP Hostname Extension June 2026 * On gateways with multiple external addresses, hostname bindings are scoped per external address: the same name may be bound on two external IPs to different internal hosts. Clients SHOULD set the Suggested External IP Address field (Section 11.1 of [RFC6887]) to the address their public DNS resolves to and SHOULD include PREFER_FAILURE so the server fails rather than assigning a different address. The Assigned External IP Address in the response is authoritative; clients publishing DNS records from PCP state SHOULD use it rather than the suggested address. * Clients renew exactly as in [RFC6887], re-sending the same MAP request (same nonce, same options) before lifetime expiry. * Clients MUST be prepared to receive HOSTNAME_TAKEN at any renewal (e.g. after server state loss and a race with another host) and SHOULD surface the condition rather than silently retrying. 6. Interaction with Other PCP Options FILTER ([RFC6887]): composes normally; filters restrict which remote peers may connect and are evaluated before demultiplexing. PREFER_FAILURE ([RFC6887]): composes normally; see Section 5 for its use on multihomed gateways. THIRD_PARTY ([RFC6887]): a request combining THIRD_PARTY and HOSTNAME options creates hostname bindings on behalf of the third party, subject to the server's THIRD_PARTY authorization policy; the conflict rules of Section 4.2 apply to the third party's bindings identically. PORT_SET ([RFC7753]): a request combining PORT_SET and HOSTNAME options is not meaningful (a hostname binding targets a single internal port) and MUST be rejected with MALFORMED_OPTION. 7. Interaction with Encrypted ClientHello ECH [I-D.ietf-tls-esni] encrypts the true server name; the outer ClientHello carries the public name of the client-facing server. A demultiplexing server sees only the outer SNI, for both TLS over TCP and QUIC. Deployments using this extension with ECH MUST bind the public name (the name published in the HTTPS/SVCB ech parameter), and the internal host performs inner-name routing itself if needed. Names hidden by ECH cannot serve as demultiplexing keys by design; this is a property of ECH, not a defect of this extension. McClelland Expires 25 December 2026 [Page 10] Internet-Draft PCP Hostname Extension June 2026 8. New Result Codes HOSTNAME_TAKEN (TBD2): the requested hostname is already bound on this external IP address and port by another client. This is a short lifetime error; the condition clears when the conflicting binding expires or is deleted. UNSUPP_HOSTNAME (TBD3): the hostname is syntactically valid but the request uses a feature this server does not support (e.g. wildcard bindings, or protocol UDP without QUIC demultiplexing support). This is a long lifetime error. Syntactically invalid hostnames are rejected with the existing MALFORMED_OPTION ([RFC6887]). 9. Security Considerations The security model is that of [RFC6887]: any host on the internal network may create mappings, so any host may claim any hostname, first come first served. This is equivalent in power to the existing ability of any internal host to claim an entire external port; the granularity is finer but the trust assumption is unchanged. Deployments requiring stronger guarantees SHOULD deploy PCP authentication [RFC7652] or restrict the option via policy (e.g. per- host hostname allowlists). A server MAY verify, at binding time, that the requested name resolves in public DNS to one of its external addresses, rejecting names that do not. DNS can change after binding and split-horizon deployments may legitimately fail such a check, so it MUST be possible to disable; it is a policy mechanism, not a protocol requirement. ClientHello collection (Section 4.4 and Section 4.5) creates state per pending connection. Servers MUST cap buffered bytes and the number of pending connections to bound memory under handshake-and- stall attacks, and SHOULD subject pending connections to the same limits as their existing connection tracking. The hostname presented in SNI is attacker controlled and unauthenticated. The server uses it only to select among pre- registered bindings; it MUST NOT be used to construct file paths or commands, and MUST be sanitized before inclusion in log output. McClelland Expires 25 December 2026 [Page 11] Internet-Draft PCP Hostname Extension June 2026 For QUIC demultiplexing, an attacker can cheaply elicit Initial- secret derivation and decryption work with spoofed datagrams. The per-version key derivation uses no secret state and the cost is bounded per datagram, but servers SHOULD rate-limit Initial processing per source address. 10. Applicability and Limitations Demultiplexing requires a client-first protocol carrying SNI: TLS over TCP (Section 4.4) and QUIC (Section 4.5). Non-TLS protocols with a cleartext hostname early in the stream (e.g. HTTP/1.1 Host) are out of scope; the fallback mapping covers them coarsely. Server- first protocols cannot be demultiplexed at all (Section 3.2). 11. IANA Considerations 11.1. PCP Option Code IANA is requested to assign the following option code in the "PCP Options" registry of the "Port Control Protocol (PCP) Parameters" group, from the Specification Required range (192-223); values in this range are optional-to-process: McClelland Expires 25 December 2026 [Page 12] Internet-Draft PCP Hostname Extension June 2026 +=============+===============================================+ | Field | Value | +=============+===============================================+ | Value | TBD1 | +-------------+-----------------------------------------------+ | Name | HOSTNAME | +-------------+-----------------------------------------------+ | Purpose | Associates a fully qualified domain name with | | | a MAP request; inbound connections on the | | | mapped external port are forwarded to the | | | internal host whose binding matches the SNI | | | presented in the TLS or QUIC ClientHello. | +-------------+-----------------------------------------------+ | Valid for | MAP | | Opcodes | | +-------------+-----------------------------------------------+ | Length | variable; 1 to 255 octets | +-------------+-----------------------------------------------+ | May Appear | Request. May appear in response only if it | | in | appeared in the associated request. | +-------------+-----------------------------------------------+ | Maximum | As many as fit within maximum PCP message | | Occurrences | size. | +-------------+-----------------------------------------------+ | Reference | This document | +-------------+-----------------------------------------------+ Table 1 11.2. PCP Result Codes IANA is requested to assign two result codes in the "PCP Result Codes" registry of the same group, from the Specification Required range (128-191): McClelland Expires 25 December 2026 [Page 13] Internet-Draft PCP Hostname Extension June 2026 +=======+=================+==========================+===========+ | Value | Name | Description | Reference | +=======+=================+==========================+===========+ | TBD2 | HOSTNAME_TAKEN | The requested hostname | This | | | | is already bound on the | document | | | | assigned external | | | | | address and port by | | | | | another client. This is | | | | | a short lifetime error. | | +-------+-----------------+--------------------------+-----------+ | TBD3 | UNSUPP_HOSTNAME | The HOSTNAME option | This | | | | requests a feature not | document | | | | supported by this | | | | | server. This is a long | | | | | lifetime error. | | +-------+-----------------+--------------------------+-----------+ Table 2 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, . [RFC7753] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port-Set Allocation", RFC 7753, DOI 10.17487/RFC7753, February 2016, . McClelland Expires 25 December 2026 [Page 14] Internet-Draft PCP Hostname Extension June 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . 12.2. Informative References [I-D.ietf-quic-load-balancers] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating Routable QUIC Connection IDs", Work in Progress, Internet- Draft, draft-ietf-quic-load-balancers-21, 27 August 2025, . [I-D.ietf-tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-25, 14 June 2025, . [RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port Control Protocol (PCP) Authentication Mechanism", RFC 7652, DOI 10.17487/RFC7652, September 2015, . Appendix A. Implementation Status An open-source implementation exists in StartOS and its StartTunnel gateway. Pending IANA assignment, it uses values from the PCP Private Use ranges: option code 224, and result codes 192 (HOSTNAME_TAKEN) and 193 (UNSUPP_HOSTNAME). These are placeholders and are expected to be replaced by the IANA-assigned values (TBD1, TBD2, TBD3) once allocated. McClelland Expires 25 December 2026 [Page 15] Internet-Draft PCP Hostname Extension June 2026 Author's Address Aiden McClelland Start9 Email: me@drbonez.dev McClelland Expires 25 December 2026 [Page 16]