TSVWG J. Touch Internet Draft Independent Consultant Updates: 4727 Intended status: Standards Track September 15, 2025 Expires: March 2026 User Ports and Port Identifiers for Experiments draft-ietf-tsvwg-usr-exp-14.txt Abstract This document defines user ports for experiments using transport protocols and the use of experiment identifiers to enable shared use of these ports. It updates RFC 4727 to recommend the use of these experimental identifiers for the system ports for experiments in the same manner. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. The list of current Internet-Drafts can be accessed at https://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html 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 March 15, 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Touch Expires March 15, 2026 [Page 1] Internet-Draft User Ports and Port IDs for Experiments September 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 2. Conventions used in this document .............................3 3. User Ports for Experiments ....................................3 4. Protocol Experiment Identifiers (PExIDs) ......................4 5. Using PExIDs in Transport Protocols ...........................5 5.1. PExID Use in General .....................................5 5.2. SCTP and DCCP PExID Use ..................................6 5.3. TLS and DTLS Use .........................................7 6. PExID Interactions with Other Protocols and Mechanisms ........7 7. Security Considerations .......................................8 8. IANA Considerations ...........................................8 9. References ...................................................10 9.1. Normative References ....................................10 9.2. Informative References ..................................11 10. Acknowledgments .............................................12 1. Introduction Various network codepoints have been allocated for experimental use, including those for IPv4 [RFC791], IPv6 [RFC8200], ICMPv4 [RFC792], ICMPv6 [RFC4443], UDP [RFC768], and TCP [RFC9293]. These include transport protocol port numbers 1021 and 1022, using the service names "EXP1" and "EXP2", respectively [RFC4727]. Service names are case-insensitive but are shown in upper-case throughout this document to improve their visibility. There has always been an expectation that experiments needing privileged (system) ports use these assignments and unprivileged ports use those from the dynamic range [RFC6335][RFC7605]. However, dynamic ports can be difficult to reserve in some systems or blocked from traversing some firewalls. As a consequence, there is a need for non-privileged, non-dynamic ports - i.e., user ports - for experiments. The mechanism described in this document is intended for such cases, notably where dynamic ports are insufficient and Touch Expires March 15, 2026 [Page 2] Internet-Draft User Ports and Port IDs for Experiments September 2025 where multiple uses of the experiment ports could interfere. This mechanism is not intended for production use, nor is it intended for experiments that can use dynamic ports or where concurrent use of experiment ports is not needed. This document reserves user ports for experimentation and describes the use of 32-bit unsigned protocol experiment identifiers (PExIDs) to differentiate shared use of these ports for concurrent experiments, by prepending these PExIDs to the experimental protocol's transport data, typically in front of each separate message payload or byte stream. This document also creates a PExID registry, in addition to the IANA service names and ports registry [SP-reg], to reduce the potential that uses of PExIDs on either user or system experiment ports interfere with each other if they are tested in the same environment or in the public Internet. This document updates RFC 4727 by adding the following text to section 1: "[IANA-THIS-RFC] defines PExIDs, which are recommended for services that might not qualify for a port assignment per current requirements in [RFC6335] and [RFC7605] because they are either short-term or need more than one port number during development (see Sec. 7.1 of [RFC7605])." 2. Conventions used in this document 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. 3. User Ports for Experiments The system, user, and dynamic port ranges vary in their properties [RFC7605]. System ports often include privileged access, sometimes known as 'root'. Dynamic ports are used as client ports when establishing associations with services on registered ports. User ports have neither privilege nor the risk of use by other connections. User ports are also more likely be allowed in firewall configurations, where system and dynamic ports can be difficult to 'un-block'. Touch Expires March 15, 2026 [Page 3] Internet-Draft User Ports and Port IDs for Experiments September 2025 This document registers USR-EXP1 and USR-EXP2 for user port experiments, using port numbers #UPORT1 and #UPORT2, with the details provided in Section 8. These ports are assigned from the user range, allowing non-privileged experiments without the need to use ports from the dynamic range. They are intended to complement the system ports already assigned for experimental use [RFC4727]. 4. Protocol Experiment Identifiers (PExIDs) This document also creates a registry for port experiment identifiers (PExIDs), in the same manner as the registry created for shared TCP option experiments [RFC6994][TCP-reg]. These PExIDs are intended for services that typically do not qualify for a port assignment per current requirements in [RFC6335] and [RFC7605] because they are either short-term or need more than one port number during development (see Sec. 7.1 of [RFC7605]). Such is the case for student projects that operate over the public Internet and/or across firewalls. Additionally, although protocol designers could select an arbitrary PExID and hope no other concurrent experiment uses it too, PExIDs are obtained as first-come, first-served with no additional requirements, so registration is both easy and encouraged. The PExID approach is inspired by the ExID method for sharing experimental option codepoints, originally developed for TCP [RFC6994] and later applied to UDP [TH25]. Unlike ExIDs, PExIDs are used in the data path and can be used by applications with no OS modification. Experimenters SHOULD register PExIDs with IANA and include them at the beginning of their transport data, i.e., at the front of each separate message payload or byte stream, as a 32-bit unsigned integer in network-standard byte order. The use of PExIDs helps differentiate experiments without the immediate need for additional port assignments. The use of these PExIDs for experiments using existing experiment ports, i.e., system ports EXP1 (#1021) and EXP2 (#1022) is RECOMMENDED. PExIDs differentiate experiments but are not intended to be specific to a given experiment port, whether system or user, so a single registration is used for all experiment ports. It is the responsibility of the experimenter to determine which port(s) each experiment uses. If an experiment using PExIDs is intended to be more widely deployed, its designers SHOULD apply for an assigned port, notably Touch Expires March 15, 2026 [Page 4] Internet-Draft User Ports and Port IDs for Experiments September 2025 before distribution as a product for public use. The expectations for such services are described in Section 7 of [RFC7605]. If an assigned port is granted to a formerly experimental service with a registered PExID, that service MUST NOT continue to use the experiment ports (even using that PExID) in a deployed system available to the public (i.e., a 'shipped product'), per Section 1.1 of [RFC3692]. If a service transitions from using experiment ports with PExIDs to receiving an assigned port, the service SHOULD NOT continue to use PExIDs in the service when operating on an assigned port. Such use is unnecessarily inefficient and could be misinterpreted as providing benefit. PExIDs are registered for use on the system and user experiment ports only; there is no registration that governs the first bytes used on other assigned ports. PExIDs SHOULD NOT be used for classroom assignments or training- related experiments; in those cases, dynamic ports are more appropriate. PExIDs SHOULD NOT be used on devices with limited resources, such as Internet of Things (IoT), low-power, or other constrained systems, due to the additional protocol and processing overhead they require. PExIDs are not needed in experiments whose use of experiment ports is contained and would not potentially interfere with other experiments using those ports. The remainder of this document focuses on the issues associated with using PExIDs. 5. Using PExIDs in Transport Protocols PExIDs differentiate use of the experiment transport ports, both for UDP and TCP as previously assigned [RFC4727] and for other transports as defined in this document. The remainder of this section describes PExID use in transport protocols in general, the detailed issues associated with SCTP and DCCP use, and PExID coordination during state negotiation. 5.1. PExID Use in General PExIDs are intended to be placed in network-standard byte order at the beginning of each independent transport data payload or byte stream. For connection-oriented transport protocols, such as TCP [RFC9293], SCTP [RFC9260], and DCCP [RFC4340], the PExID is typically sent once for each connection at the beginning of the user transfer and echoed Touch Expires March 15, 2026 [Page 5] Internet-Draft User Ports and Port IDs for Experiments September 2025 upon receipt, enabling both ends to confirm the experiment for the connection's socket pair. That socket pair is then associated with the experiment identified by that PExID for the duration of the connection. For connectionless transport protocols, such as UDP [RFC768], the PExID is typically included at the beginning of every message in both directions. In most cases, the PExID is sent as user data. SCTP is one exception, because of its Payload Protocol Identifier (PPID), as discussed further in Section 5.2. Alternately, PExID can be confirmed during the connection or security handshake, as discussed in Section 5.3. Two endpoints can engage in multiple experiments using the same experimental port number and transport protocol. In such cases, users are expected to support demultiplexing of those different experiments using the PExID. However, PExIDs SHOULD NOT be used to differentiate versions of a protocol or service, because such a service would be more difficult to transition to use of an assigned port for all future versions, as indicated by Section 7.5 of [RFC7605]. 5.2. SCTP and DCCP PExID Use SCTP and DCCP connections already have a mechanism to indicate experimental-use using a self-assigned Private Use DCCP Service Code [RFC4340][RFC5595] or a registered SCTP Payload Protocol Identifier (PPID) [RFC9260]. There is thus no need to use PExIDs to differentiate experiments on the same port number. PExIDs can be used in addition to those codes if desired, notably in developing a single application-layer solution for multiple transport protocols. SCTP also includes a Payload Protocol Identifier (PPID), which identifies the information within each user message. PPIDs are assigned on a first-come, first-served (FCFS) basis and are abundant (2^32 codepoints), so there is no need for a separate experimental- use PPID. The PExID differentiate shared use of the user experimental port number and thus serves a different purpose than the PPID; both can be used together or separately for SCTP. Because SCTP supports multiple concurrent streams, it is useful for experiments using PExIDs to be identified in a particular stream before proceeding with other streams, to avoid excessive buffering. For SCTP using only PExIDs for that purpose, users SHOULD send the PExID ordered and reliably as the first user message using PPID of Touch Expires March 15, 2026 [Page 6] Internet-Draft User Ports and Port IDs for Experiments September 2025 #PPID1 in stream 0 (the default stream). Until the PExID user message is echoed back on stream 0, user messages on stream 0 SHOULD be sent ordered and the user SHOULD avoid transmitting user messages on other streams. The echoed user message SHOULD use the PPID of #PPID1 assigned for this purpose. That PExID user message MUST contain only the PExID as a 32-bit unsigned integer in network- standard byte order. 5.3. TLS and DTLS Use Both TLS and DTLS provide extensions to negotiate additional security association parameters [RFC8446][RFC9147]. In both cases, the PExID could be sent in ClientHello requests and echoed in ServerHello responses, although for these protocols the extension requires two fields (because such fields carry only 16 bits of content and two are needed for the 32-bit PExID). 6. PExID Interactions with Other Protocols and Mechanisms PExIDs help differentiate different uses of the same experimental transport port number using data that augments the port number of the transport header, and thus are not be supported by existing NATs, firewalls, deep-packet inspectors (DPIs), or service function chaining [RFC7665]. To differentiate between shared uses of experiment ports, these devices would need to be modified to detect the PExID, either at the beginning of the connection (for connection-oriented uses) or within each data payload (for connectionless uses). Some methods to traverse tunnels are also affected by the use of PExIDs. STUN uses a method similar to PExIDs in its in-band message identifier [RFC8489]. These identifiers begin with a 32-bit field first two bits are "00", followed by a type and length, followed by a 32-bit 'magic number' of 0x2112A442, followed by a 96-bit transaction identifier. PExIDs are similar to the transaction identifier, but they occur earlier in the data stream. The STUN mechanism can be used concurrent with PExIDs if the PExIDs are selected where the two highest bits are something other than "00" (as required in STUN messages). Because not all service or protocols are intended to be used concurrent with STUN, this restricting should not be a concern. The TURN mechanism for NAT traversal does not interact with use of PExIDs [RFC8656]. Some protocols use "magic bytes" to identify streams and/or messages. PExIDs are a specific interpretation of the first four Touch Expires March 15, 2026 [Page 7] Internet-Draft User Ports and Port IDs for Experiments September 2025 magic bytes of each stream or message to demultiplex shared use of the experimental transport ports, thus they are typically not compatible with other concurrent use of magic bytes. The use of PExIDs may interfere with some aspects of ICMP, because all applications sharing the experiment ports would be treated the same. In such cases, the experimenter is advised to use other means in place of ICMP, e.g., direct measurement of the path MTU. 7. Security Considerations The creation of new ports for experiment purposes does not create any new security considerations. At best, it potentially reduces the use of privileged system ports for such experiments, which avoids the associated risk of unnecessary privileged access. Like conventional transport protocol port numbers, PExIDs can be used by deep-packet inspection (DPI) to identify services and protocols (see Sec. 5.2.1 of [RFC6973]). When such information is intended to be protected or private, it can be sent as user data inside an encrypted stream or message, e.g., as user data in TCP/TLS or UDP/DTLS. PExIDs are not supported by existing firewalls, DPI devices, IPsec traffic selectors or other systems that demultiplex or identify traffic using transport port numbers. Different services using the same port number cannot currently rely on PExIDs for selective filtering. Experimenters are expected to support security capabilities in any new experiment, regardless of whether an experimental or assigned port is being used (per Section 7.4 of [RFC7605]). 8. IANA Considerations This document hereby requests the assignment of two user ports for experimental purposes below. IANA is asked to replace instances of #UPORT1 and #UPORT2 throughout this document based on the actual allocation. This paragraph is intended to be removed prior to final publication. This document also hereby requests the assignment of the SCTP PPID "PEXID" for use in association with these port numbers. IANA is asked to replace instances of #PPID1 throughout this document based on the actual allocation. This paragraph is intended to be removed prior to final publication. Touch Expires March 15, 2026 [Page 8] Internet-Draft User Ports and Port IDs for Experiments September 2025 IANA has assigned the following user ports for experiments: Service Name USR-EXP1 Transport Protocol(s) TCP, UDP, DCCP, and SCTP Assignee IESG Contact IETF Chair Description RFC[TBD-rfc]-style Experiment Reference RFC [TBD-rfc] Port Number #UPORT1 (requesting 1031) Service Code none - use private use service codes Known Unauthorized Uses none Assignment Notes Intended for use with PExIDs only And: Service Name USR-EXP2 Transport Protocol(s) TCP, UDP, DCCP, and SCTP Assignee IESG Contact IETF Chair Description RFC[TBD-rfc]-style Experiment Reference RFC [TBD-rfc] Port Number #UPORT2 (requesting 1032) Service Code none - use private use service codes Known Unauthorized Uses none Assignment Notes Intended for use with PExIDs only IANA has assigned the following SCTP Payload Protocol Identifier (PPID) for experiments associated with these port numbers: Touch Expires March 15, 2026 [Page 9] Internet-Draft User Ports and Port IDs for Experiments September 2025 SCTP PPID #PPID1 This document directs IANA to create a "Port Experimental Option Experiment Identifiers (PExIDs)" registry linked under the IANA ports registry [SP-reg], using a the same format and structure as the TCP Experimental Option Experiment ID registry [TCP-reg]. The registry records PExIDs as 32-bit unsigned integers, including a brief description, document pointer (if available), assignee name, and e-mail contact for each entry. It also includes the transport protocol indicated at the time of assignment; additional entries can be added for other transport protocols with different references if needed. Once registered, PExIDs can be used with either the system (EXP1 #1021, EXP2 #1022) or user (USR-EXP1 #UPORT1, USR-EXP2 #UPORT2) ports and with any transport protocol, regardless of whether a separate registration is provided for each transport protocol. This registry has no initial entries. Entries are assigned on a First Come, First Served (FCFS) basis [RFC8126]. IANA will also record known duplicate uses to assist the community in both debugging assigned uses as well as correcting unauthorized duplicate uses. IANA should impose no requirements on making a registration request other than indicating the desired codepoint and providing a point of contact. A short description or acronym for the use is desired but not required. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful," RFC 3692, BCP 82, Jan. 2004. [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers," RFC 4727, Nov. 2026. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry," BCP 165, RFC 6335, Aug. 2011. Touch Expires March 15, 2026 [Page 10] Internet-Draft User Ports and Port IDs for Experiments September 2025 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 6994, Aug. 2013. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 9.2. Informative References [RFC768] Postel, J., "User Datagram Protocol," STD 6, RFC 768, Aug. 1980. [RFC791] Postel, J., "Internet Protocol," STD 5, RFC 791, Sep. 1981. [RFC792] Postel, J., "Internet Control Message Protocol," STD 5, RFC 792, Sep. 1981. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)," RFC 4340, March 2006. [RFC4443] Conta, A., Deering, S., and M. Gupta, (Ed.), "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification," STD 89, RFC 4443, Mar. 2006. [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. [RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers," BCP 165, RFC 7605, Aug. 2015. [RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, October 2015. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," STD 86, RFC 8200, Jul. 2017. Touch Expires March 15, 2026 [Page 11] Internet-Draft User Ports and Port IDs for Experiments September 2025 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol VerREsion 1.3", RFC 8446, Aug. 2018. [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", RFC 8489, February 2020. [RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 8656, February 2020, [RFC9000] Iyengar, J., Ed., and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021. [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022. [RFC9260] Stewart, R. (Ed.), "Stream Control Transmission Protocol," RFC 9260, Sep. 2007. [RFC9293] Eddy, W. (Ed.), "Transmission Control Protocol (TCP), Aug. STD 7, RFC 9293, 2022. [SP-reg] Service Name and Transport Protocol Port Number Registry, https://www.iana.org/assignments/service-names-port- numbers/service-names-port-numbers.xhtml [TCP-reg] TCP/UDP Experimental Option Experiment ID (TCP/UDP ExID) registry, https://www.iana.org/assignments/tcp- parameters/tcp-parameters.xhtml#tcp-exids [TH25] Touch, J, C. Heard (Ed.), "Transport Options for UDP", draft-ietf-tsvwg-udp-options, Mar. 2025. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Joe Touch Manhattan Beach, CA 90266 USA Phone: +1 (310) 560-0334 Email: touch@strayalpha.com Touch Expires March 15, 2026 [Page 12]