RFC 6335

Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry

📅 published August 2011, from ietf

RFC 6335 🎀 Part 1 of 8

Okay bestie, let's get into it. This is RFC 6335, and it's the IANA rulebook for the Service Name and Transport Protocol Port Number registry 📖✨

  • Series and number: RFC 6335, filed as BCP 165 (a Best Current Practice) 🌸
  • Title: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry 💅
  • Authors: M. Cotton (ICANN), L. Eggert (Nokia), J. Touch (USC/ISI), M. Westerlund (Ericsson), and S. Cheshire (Apple) 🫶
  • Category: Best Current Practice 👑
  • ISSN: 2070-1721
  • Date: August 2011 🦋
  • Publisher: Internet Engineering Task Force (IETF)
  • Updates: 2780, 2782, 3828, 4340, 4960, 5595 🔥
  • Obsoletes: The title block doesn't list anything here, but the Abstract says it obsoletes the older UDP and TCP port assignment procedures in Sections 8 and 9.1 of the IANA Allocation Guidelines. So that's the plot twist 😭

Abstract ✨

Okay so the Abstract says this document lays out the procedures IANA follows when it handles assignment requests and other requests for the Service Name and Transport Protocol Port Number registry. It also explains the reasoning behind those procedures and how they help the registry last long-term 🌈

It also updates IANA's procedures. It obsoletes the older UDP and TCP port assignment procedures from Sections 8 and 9.1 of the IANA Allocation Guidelines. It updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). And it updates the DNS SRV specification so it's clear what a service name is and how one gets registered 💖

Status of This Memo ✨

This memo documents an Internet Best Current Practice 🎀

This document comes from the Internet Engineering Task Force (IETF). It reflects what the IETF community agrees on. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, check out Section 2 of RFC 5741 📚

You can find the current status of this document, any errata, and a way to send feedback at http://www.rfc-editor.org/info/rfc6335 🦋

Copyright (c) 2011 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, which you can find at http://trustee.ietf.org/license-info. Those rules are in effect on the date this document was published. Please read them carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶

Some of this document may contain material from IETF Documents or IETF Contributions that was published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸

Table of Contents ✨

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  6
4.  Conventions Used in This Document  . . . . . . . . . . . . . .  8
5.  Service Names  . . . . . . . . . . . . . . . . . . . . . . . .  8
  5.1.  Service Name Syntax  . . . . . . . . . . . . . . . . . . .  9
  5.2.  Service Name Usage in DNS SRV Records  . . . . . . . . . . 10
6.  Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 11
  6.1.  Service Names and Port Numbers for Experimentation . . . . 12
7.  Principles for Service Name and Transport Protocol Port
    Number Registry Management . . . . . . . . . . . . . . . . . . 12
  7.1.  Past Principles  . . . . . . . . . . . . . . . . . . . . . 13
  7.2.  Updated Principles . . . . . . . . . . . . . . . . . . . . 13
8.  IANA Procedures for Managing the Service Name and
    Transport Protocol Port Number Registry  . . . . . . . . . . . 16
  8.1.  Service Name and Port Number Assignment  . . . . . . . . . 16
  8.2.  Service Name and Port Number De-Assignment . . . . . . . . 21
  8.3.  Service Name and Port Number Reuse . . . . . . . . . . . . 21
  8.4.  Service Name and Port Number Revocation  . . . . . . . . . 22
  8.5.  Service Name and Port Number Transfers . . . . . . . . . . 22
  8.6.  Maintenance Issues . . . . . . . . . . . . . . . . . . . . 23
  8.7.  Disagreements  . . . . . . . . . . . . . . . . . . . . . . 23
9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
  10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 24
  10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 26
  10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
  13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
  13.2. Informative References . . . . . . . . . . . . . . . . . . 30

1. Introduction ✨

Okay so for years, picking new service names and port number values for TCP [RFC0793] and UDP [RFC0768] has been kinda messy, because the guidelines weren't very clear 😭 Then new transport protocols showed up, like SCTP [RFC4960] and DCCP [RFC4342], and new mechanisms like DNS SRV records [RFC2782] got built too. Each of those got its own registry and its own rules. The community also realized it needed procedures for more than just assignment, like modification, revocation, and release 🙈

The big glow-up in this document is that it sets up identical assignment procedures for every IETF transport protocol. It brings the TCP and UDP procedures in line with the ones for SCTP and DCCP. The result is one process that requesters and IANA both follow for every request, for every transport protocol, including ones that don't exist yet 💅

This document also covers the post-assignment stuff that used to be handled in an ad hoc way. That includes de-assigning a port number that's no longer in use, taking a port number from a service that's dead and reusing it for a different service, and the way IANA can revoke a previous port number assignment all on its own. Section 8 has the specifics of these procedures, and the steps requesters and IANA follow for every request, for all current and future transport protocols 🦋

IANA is the authority for assigning service names and port numbers, and it maintains the registries where those assignments are stored. For protocols built by IETF working groups, IANA now also offers "early assignment" [RFC4020] of service names and port numbers. That's described in Section 8.1 ✨

This document updates IANA's procedures for UDP and TCP port numbers by obsoleting Sections 8 and 9.1 of the IANA Allocation Guidelines [RFC2780]. (Side note: other sections of those Guidelines, about the protocol field values in IPv4 headers, were also updated in February 2008 [RFC5237].) This document also updates the IANA assignment procedures for DCCP [RFC4340] [RFC5595] and SCTP [RFC4960] 🌈

UDP-Lite (the Lightweight User Datagram Protocol) shares the port space with UDP. The UDP-Lite specification [RFC3828] says: "UDP-Lite uses the same set of port number values assigned by the IANA for use by UDP". So when the UDP procedures get updated, the UDP-Lite procedures get updated along with them 🔥

This document also makes it clear what a service name is and how it's assigned. That matters for the DNS SRV specification [RFC2782], because that spec only briefly says that symbolic service names are defined in "Assigned Numbers" [RFC1700]. It doesn't say which section of that 230-page document it means. The DNS SRV spec might have meant the list of Port Assignments (known as /etc/services on Unix), or the "Protocol And Service Names" section, or both, or some other section entirely 😭 On top of that, "Assigned Numbers" [RFC1700] was obsoleted [RFC3232] and replaced by online registries [PORTREG] [PROTSERVREG] 💖

Developing new transport protocols is a big deal, and the IETF doesn't do it very often. If a new transport protocol gets standardized in the future, it's expected to follow these guidelines and practices for using service names and port numbers as much as possible, so everything stays consistent 🎀

Last thing: when this document was written, the internal procedures of "Expert Review" teams, including IANA's port review team, weren't documented in any RFC. This document doesn't change that 🙈

2. Motivation ✨

okay so info about how port registry assignments work has been scattered across THREE different places 😭: the request forms on the IANA website [SYSFORM] [USRFORM], an intro section sitting at the top of the port numbers registry file itself (aka the port numbers registry) [PORTREG], and two little sections of the IANA Allocation Guidelines [RFC2780]. like, who has time for that? 💀

service names got the same chaotic energy 🌀. they started out as mnemonic labels for port numbers with no real syntax, except the 14-character limit mentioned on the IANA website [SYSFORM] [USRFORM]. and even that limit wasn't consistently followed, because some assigned service names are 15 characters long 🙈. then DNS SRV Resource Records (RRs) showed up [RFC2782], and suddenly it made sense to assign service names on their own. but IANA had no procedure for giving out a service name without a port number attached, so people made an informal temporary service name registry that IANA doesn't control. it now has roughly 500 service names in it [SRVREG]. iconic? not really. 😅

this document pulls all of that scattered info into ONE reference 🎀. it lines everything up and clearly defines how management works for both service names and port numbers. it gives prospective requesters way more detailed guidance than the old docs did, and it streamlines the IANA procedures so requests can actually get finished in a timely manner. ✨

it also defines rules for assigning service names without port numbers, for stuff like DNS SRV records [RFC2782], which just wasn't possible under the old IANA procedures 🫶. and it merges the service name assignments from the non-IANA ad hoc registry [SRVREG] and from the IANA Protocol and Service Names registry [PROTSERVREG] into the IANA Service Name and Transport Protocol Port Number registry [PORTREG]. from here on, that one is the single authoritative registry for service names and port numbers 👑.

another goal of this doc is to spell out the principles the IETF and IANA follow as the long-term joint stewards of the service name and port number registry 🦋. TCP and UDP have been absolutely unstoppable over the last few decades 🔥. thousands of applications and application-level protocols have service names and port numbers assigned to them, and there's every reason to think that trend keeps going. so it's extremely important that registry management sticks to principles that keep it useful as a shared resource for the long haul. Section 7 covers those principles in detail. 💜

3. Background

TCP [RFC0793] and UDP [RFC0768] have had a remarkable run over the decades as the two most widely used transport protocols on the Internet 💅. they rely on "ports" as logical entities for Internet communication. ports do two jobs 🧚: first, they act as a demultiplexing identifier so transport sessions between the same pair of endpoints can be told apart, and second, they can also identify the application protocol and associated service that processes connect to. newer transport protocols like the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] also adopted ports for their sessions, and they use 16-bit port numbers the same way TCP and UDP do (and so does UDP-Lite [RFC3828], a variant of UDP) ✨.

port numbers are the original and most widely used way to identify applications and services on the Internet 🌸. they're 16-bit numbers, and the combo of source and destination port numbers plus the IP addresses of the communicating end systems uniquely identifies a session of a given transport protocol. port numbers also go by their service names, like "telnet" for port 23 and "http" (plus "www" and "www-http") for port 80 🍓.

all the parties involved need to agree on which service matches a particular destination port 🫶. that includes hosts running services, hosts accessing services on other hosts, and middleboxes (like firewalls and NATs) that restrict services. it's ultimately a local decision that only matters between the endpoints of a connection, but lots of services have a default port they usually listen on when possible, and IANA records those ports through the service name and port number registry [PORTREG] 🎀.

over time, the idea that one port number always means one particular service gets less and less true 🙈. for example, multiple instances of the same service on the same host generally can't listen on the same port, and multiple hosts behind the same NAT gateway can't all map the same port on the external side of the gateway. this is true whether the mappings are static and set up by hand, or dynamic and set up automatically with a port mapping protocol like the NAT Port Mapping Protocol [NAT-PMP] or Internet Gateway Device [IGD] 💀.

applications have a few options for finding port numbers 🔍. they can use port numbers directly, look them up from service names with system calls like getservbyname() on UNIX, look them up by querying DNS SRV records [RFC2782] [DNS-SD], or figure them out in other ways, like the TCP Port Service Multiplexer (TCPMUX) [RFC1078] 🌈.

application designers can apply to IANA for an assigned service name and port number for a specific application ✨. once it's assigned, they can assume no other application will use that service name or port number for its communication sessions 💖. they can also just request an assigned service name without a fixed port number if their application doesn't need one, like apps that use DNS SRV records to look up port numbers dynamically at run-time 🦋. and since the port number space is finite (so conservation is a big goal), using service names instead of port numbers is RECOMMENDED whenever possible 💜.

4. 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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] 🧠.

this document uses the word "assignment" for the procedure where IANA hands out service names and/or port numbers to requesting parties. other RFCs call this "allocation" or "registration" 🔁. this doc treats all of those terms as meaning the same thing, and it only uses other words than "assignment" when quoting or referring to text from those other documents 💅.

5. Service Names

service names are the unique key in the Service Name and Transport Protocol Port Number registry 🔑. that unique symbolic name can also be used for other stuff, like DNS SRV records [RFC2782]. inside the registry, this key makes sure different services can be told apart clearly, which prevents name collisions and keeps things clear about who the Assignee is for each entry 👑.

a single transport protocol and port can have more than one service name attached. there are three ways this port number overloading can happen 🙈:

  • overloading happens when one service is an extension of another service, and there's an in-band mechanism for figuring out whether the extension is present. one example is port 3478, which has the service name aliases "stun" and "turn". Traversal Using Relays around NAT (TURN) [RFC5766] is an extension to the Session Traversal Utilities for NAT (STUN) [RFC5389] service. TURN-enabled clients that want to find TURN servers could try to discover "stun" services and then check in-band whether the server also supports TURN, but that would be inefficient. it's way better to let them query for "turn" servers directly by name 🙌. (note that TURN servers in this case should also be findable via a "stun" discovery, because every TURN server is also a STUN server 🫶.)
  • by historical accident, the service name "http" has two synonyms, "www" and "www-http". when used in SRV records [RFC2782] and similar service discovery mechanisms, only the service name "http" should be used, not these extra names 💅. if a server advertised "www", clients browsing for "http" wouldn't find it 😭. advertising or browsing for the aliases as well as the primary name is inefficient, and it doesn't achieve anything that using "http" exclusively doesn't already achieve 💀.
  • as this document says in Section 10.1, overloading has been used to create replacement names that follow the syntax this document prescribes for legacy names that don't already conform to it 🦋. in those cases, only the new name should be used in SRV records, to avoid the same issues as the historical multiple-name cases, and also because the legacy names are incompatible with SRV record use 🌸.
assignment requests for new names for services that already have a registered name will be rejected, as a result 🚫.

implementers are asked to tell IANA if they find other cases where a single service has multiple names, so one name can be recorded as the primary name for service discovery purposes 🎀.

service names get assigned on a "first come, first served" basis, as described in Section 8.1 ✨. names should be brief and informative, and they should avoid words or abbreviations that are redundant in the context of the registry (e.g., "port", "service", "protocol", etc.) 💖. names for discovery services (e.g., ones that use multicast or broadcast to find endpoints capable of a given service) SHOULD use an easily identifiable suffix (e.g., "-disc") 🔍.

5.1. Service Name Syntax

okay bestie, the rules for what counts as a valid service name are locked in 🔒💅 normatively, a valid service name:

  • MUST be at least 1 character and no more than 15 characters long 🌸
  • MUST contain only US-ASCII [ANSI.X3.4-1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45) 🎀
  • MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') ✨
  • MUST NOT begin or end with a hyphen 🙈
  • hyphens MUST NOT be adjacent to other hyphens 💀

so why the at-least-one-letter thing? 👀 it's so "23" doesn't get mistaken for a numeric port, and "6000-6063" doesn't get mistaken for a numeric port range. also, case is ignored when comparing names, so "http" and "HTTP" are the same service, no debate 🦋

service names are purely opaque identifiers, meaning there's no hidden meaning baked in just because a name looks structured 🧚 for example, a company called "Example" can register "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" products, but it can't claim to "own" every name starting with "Example-" 🙅‍♀️ someone else can still register "Example-Baz" for a different service, and other developers can still use "Example-Foo" and "Example-Bar" to interoperate with those products. technically, in service discovery protocols, service names are just byte values on the wire. humans can read them as ASCII characters because that's mnemonic and cute, but software should treat them as opaque and not try to parse extra meaning out of them 🫶

as of August 5, 2009, about 98% of the "Short Names" [SYSFORM] [USRFORM] for existing port number assignments [PORTREG] already followed these rules, so for those services the service name is exactly the same as the historical "Short Name" 🍓 for the other ~2%, the new service name is derived from the old "Short Name", as described in Section 10.1 🔥

the rules for valid service names are also written below in ABNF [RFC5234] as a non-normative convenience (the 15-character limit isn't included in this version):

   SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)
   ALNUM   = ALPHA / DIGIT     ; A-Z, a-z, 0-9
   HYPHEN  = %x2D              ; "-"
   ALPHA   = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
   DIGIT   = %x30-39           ; 0-9       [RFC5234]

5.2. Service Name Usage in DNS SRV Records

the DNS SRV spec [RFC2782] says the Service Label part of the owner name of a DNS SRV record includes a "Service" element, described as "the symbolic name of the desired service" 🧐 but as we talked about above, it's honestly not super clear what that means, so this document clears it up 💖

the Service Label MUST be a service name as defined herein with an underscore prepended. ✨ the service name SHOULD be registered with IANA and recorded in the Service Name and Transport Protocol Port Number registry [PORTREG] 📋

all the details for using service names in SRV Service Labels live in the DNS SRV spec [RFC2782] 🌈

6. Port Number Ranges

okay so TCP, UDP, UDP-Lite, SCTP, and DCCP all use 16-bit namespaces for their port number registries 🎀 the registries for all of these transport protocols are split into three ranges [RFC1340], and Section 8.1.2 walks through the IANA procedures for each range in detail:

  • the System Ports, also known as the Well Known Ports, from 0-1023 (assigned by IANA) 👑
  • the User Ports, also known as the Registered Ports, from 1024-49151 (assigned by IANA) 🌸
  • the Dynamic Ports, also known as the Private or Ephemeral Ports, from 49152-65535 (never assigned) 🦋

of the assignable ranges (System Ports and User Ports, i.e., port numbers 0-49151), each individual port number is in one of three states at any given time:

  • Assigned: Assigned port numbers are currently assigned to the service indicated in the registry. 💅
  • Unassigned: Unassigned port numbers are currently available for assignment upon request, as per the procedures outlined in this document. 🧚
  • Reserved: Reserved port numbers are not available for regular assignment; they are "assigned to IANA" for special purposes. Reserved port numbers include values at the edges of each range, e.g., 0, 1023, 1024, etc., which may be used to extend these ranges or the overall port number space in the future. 🔮

to keep the registry manageable, IANA typically only records the Assigned and Reserved service names and port numbers. Unassigned values usually aren't listed explicitly. (there are SO many Unassigned service names that listing them all would be totally impractical 😭)

as a data point, when this document was written, about 76% of the TCP and UDP System Ports were assigned, and about 9% of the User Ports were assigned. (and as mentioned, Dynamic Ports are never assigned 🙅‍♀️)

6.1. Service Names and Port Numbers for Experimentation

okay, so of the System Ports, two TCP and UDP port numbers (1021 and 1022), along with their service names ("exp1" and "exp2"), have been set aside for experimenting with new applications and application-layer protocols that need a port number in the assigned ports range [RFC4727] 🧪✨

for how these experimental port numbers should be used, check out Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] 📚

this document also assigns the same two service names and port numbers for experimenting with new application-layer protocols over SCTP and DCCP, in Section 10.2 🌈

⚠️ real talk: it can be really hard to limit who gets into these ports. Users SHOULD take measures to make sure experimental ports are connecting to the intended process. for example, users of these ports might include a 64-bit nonce, once on each segment of a message-oriented channel (e.g., UDP), or once at the beginning of a byte-stream (e.g., TCP), which is used to confirm the port is being used as intended. that confirmation is especially important when these ports are tied to privileged (e.g., system or administrator) processes 🫣

7. Principles for Service Name and Transport Protocol Port Number Registry Management

so managing the Service Name and Transport Protocol Port Number registry covers assigning service names and port numbers when someone asks, plus looking after info about existing assignments 🗂️ that includes keeping contact and description info up to date, revoking abandoned assignments, and redefining assignments when needed. out of all of this, careful port number assignment is the most critical, because we need to keep conserving the port numbers we have left 🫶

as noted earlier, only about 9% of the User Port space is currently assigned. the current rate of assignment is about 400 ports per year, and it's stayed steady for the past 8 years 📈 at that rate, if similar conservation continues, this resource will last another 85 years of assignment, without needing to reassign released values or revoke anything 😤✨ the namespace for service names is much bigger, which means simpler management procedures are possible 🍓

7.1. Past Principles

the principles for service name and port number management were based on recommendations from the IANA "Expert Review" team 🧠 until recently, that team followed a set of informal guidelines built from review experience with previous assignment requests. those original guidelines were informal and never publicly documented 🙈 they're written down here for historical purposes only. the current guidelines are in Section 7.2. the old guidelines were:

  • TCP and UDP ports were simultaneously assigned when either was requested 🎀
  • Port numbers were the primary assignment; service names were informative only, and did not have a well-defined syntax 🦋
  • Port numbers were conserved informally, and sometimes inconsistently (e.g., some services were assigned ranges of many port numbers even where not strictly necessary) 🌸
  • SCTP and DCCP service name and port number registries were managed separately from the TCP/UDP registries 🧚
  • Service names could not be assigned in the old ports registry without assigning an associated port number at the same time 💅

7.2. Updated Principles ✨

okay so this section is the glow-up 💅 It sums up the principles IANA currently follows when handling the Service Name and Transport Protocol Port Number registry, and how it tries to conserve the port number space 🎀 It's written to help applicants requesting service names and port numbers. IANA has flexibility beyond these principles, bestie. Other factors may come into play, and exceptions may be made to best serve the needs of the Internet. Applicants should be aware that IANA decisions are not required to be bound to these principles 🙈 Also, these principles and the general advice on port use are expected to change over time 🦋

IANA strives to assign service names that do not request an associated port number assignment under a simple "First Come First Served" policy [RFC5226]. IANA MAY, at its discretion, refer service name requests to "Expert Review" in cases of mass assignment requests or other situations where IANA believes "Expert Review" is advisable [RFC5226]. Use of the "Expert Review" helps advise IANA informally in cases where "IETF Review" or "IESG Approval" is used, as with most IETF protocols 💜

The basic principle of service name and port number registry management is to conserve use of the port space where possible 🌸 Extensions to support larger port number spaces would require changing many core protocols of the current Internet in a way that would not be backward compatible and interfere with both current and legacy applications. Not it 😭

Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. In particular, the principles form a goal that IANA strives to achieve for new applications (with exceptions as deemed appropriate, especially as for extensions to legacy services) as follows:

  • IANA strives to assign only one assigned port number per service or application.

Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol.

  • IANA strives to assign only one assigned port number for all variants of a service (e.g., for updated versions of a service).
  • IANA strives to encourage the deployment of secure protocols. 🔥
  • IANA strives to assign only one assigned port number for all different types of devices using or participating in the same service.
  • IANA strives to assign port numbers only for the transport protocol(s) explicitly named in an assignment request.
  • IANA may recover unused port numbers, via the new procedures of de-assignment, revocation, and transfer. ♻️

Where possible, a given service is expected to demultiplex messages if necessary. For example, applications and protocols are expected to include in-band version information, so that future versions of the application or protocol can share the same assigned port. Applications and protocols are also expected to be able to efficiently use a single assigned port for multiple sessions, either by demultiplexing multiple streams within one port or by using the assigned port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]) ✨

Ports are used in various ways, notably:

  • as endpoint process identifiers
  • as application protocol identifiers
  • for firewall-filtering purposes

Both the process-identifier and the protocol-identifier uses suggest that anything a single process can demultiplex, or that can be encoded into a single protocol, should be. The firewall-filtering use suggests that some uses that could be multiplexed or encoded could instead be separated to allow for easier firewall management. Note that this latter use is much less sound, because port numbers have meaning only for the two endpoints involved in a connection, and drawing conclusions about the service that generated a given flow based on observed port numbers is not always reliable. So be careful with that one, babe 🙃

Effective with the publication of this document, IANA will begin assigning port numbers for only those transport protocols explicitly included in an assignment request. This ends the long-standing practice of automatically assigning a port number to an application for both TCP and UDP, even if the request is for only one of these transport protocols. The new assignment procedure conserves resources by assigning a port number to an application for only those transport protocols (TCP, UDP, SCTP, and/or DCCP) it actually uses. The port number will be marked as Reserved -- instead of Assigned -- in the port number registries of the other transport protocols. When applications start supporting the use of some of those additional transport protocols, the Assignee for the assignment MUST request that IANA convert these reserved ports into assignments. An application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport protocol without IANA converting the reservation into an assignment. This is a big deal, so pay attention 👑

When the available pool of unassigned numbers has run out in a port range, it will be necessary for IANA to consider the Reserved ports for assignment. This is part of the motivation for not automatically assigning ports for transport protocols other than the requested one(s). This will allow more ports to be available for assignment at that point. To help conserve ports, application developers SHOULD request assignment of only those transport protocols that their application currently uses. 🍓

Conservation of port numbers is improved by procedures that allow previously assigned port numbers to become Unassigned, either through de-assignment or through revocation, and by a procedure that lets application designers transfer an assigned but unused port number to a new application. Section 8 describes these procedures, which until now were undocumented. Port number conservation is also improved by recommending that applications that do not require an assigned port should register only a service name without an associated port number 🧚

8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry 🌈

This section describes the process for handling requests associated with IANA's management of the Service Name and Transport Protocol Port Number registry. Such requests include initial assignment, de-assignment, reuse, and updates to the contact information or description associated with an assignment. Revocation is an additional process, initiated by IANA.

8.1. Service Name and Port Number Assignment 🦋

Assignment refers to the process of providing service names or port numbers to applicants. All such assignments are made from service names or port numbers that are Unassigned or Reserved at the time of the assignment.

  • Unassigned names and numbers are assigned according to the rules described in Section 8.1.2 below.
  • Reserved numbers and names are generally only assigned by a "Standards Action" or "IESG Approval", and MUST be accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. The only exception to this rule is that the current Assignee of a port number MAY request the assignment of the corresponding Reserved port number for other transport protocols when needed. IANA will initiate an "Expert Review" [RFC5226] for such requests.

When an assignment for one or more transport protocols is approved, the port number for any non-requested transport protocol(s) will be marked as Reserved. IANA SHOULD NOT assign that port number to any other application or service until no other port numbers remain Unassigned in the requested range. It is anticipated that at such time a new document will be published specifying IANA procedures for assignment of such ports 💖

8.1.1. General Assignment Procedure 📝

okay so every service name or port number request needs to bring this exact info with it. The service name is the unique ID for a service, so let's go 💅

Service Name (REQUIRED)
Transport Protocol(s) (REQUIRED)
Assignee (REQUIRED)
Contact (REQUIRED)
Description (REQUIRED)
Reference (REQUIRED)
Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL)
  • Service Name: a desired unique service name for the service in the request MUST be provided 🎀 This name can be used with different service selection and discovery stuff (including, but not limited to, DNS SRV records [RFC2782]). The name MUST be compliant with the syntax in Section 5.1. To stay unique, names MUST NOT be identical to any currently assigned service name in the IANA registry [PORTREG]. Service names are case-insensitive. You can type them with mixed case so they look nice in the registry, but case is ignored otherwise ✨
  • Transport Protocol(s): the transport protocol(s) you want an assignment for MUST be provided. Right now this field is limited to one or more of TCP, UDP, SCTP, and DCCP. Even if you're only requesting a service name with no port, you still have to say which protocol the service uses 🦋
  • Assignee: the name and email address of the party getting the assignment. This is REQUIRED. The Assignee is the organization, company, or individual person responsible for the initial assignment. For assignments done through RFCs published via the "IETF Document Stream" [RFC4844], the Assignee will be the IESG <iesg@ietf.org> 👑
  • Contact: the name and email address of the Contact person. This is REQUIRED. The Contact is the responsible person the Internet community sends questions to. They're also authorized to submit changes on behalf of the Assignee. If the Assignee and Contact ever disagree, the Assignee's decisions win. Additional address information MAY be provided. For assignments done through RFCs published via the "IETF Document Stream" [RFC4844], the Contact will be the IETF Chair <chair@ietf.org> 💜
  • Description: a short description of the service in the request is REQUIRED. It should avoid all but the most well-known acronyms 🌸
  • Reference: a description of (or a reference to a document describing) the protocol or application using this port. This is REQUIRED 🔥 The description must state whether the protocol uses IP-layer broadcast, multicast, or anycast communication.

For assignments that only request a Service Name, or a Service Name and User Port, it's also fine to say the protocol is proprietary and not publicly documented. The catch is that you still have to give the required info about IP broadcast, multicast, or anycast use 🙈

For any assignment request that includes a User Port, the request MUST explain why a port number in the Dynamic Ports range (the ones clients discover dynamically at run-time) is unsuitable for the application 🧚

For any assignment request that includes a System Port, the request MUST explain why a port number in the User Ports or Dynamic Ports ranges is unsuitable, and a reference to a stable protocol specification document MUST be provided 💀

IANA MAY accept early assignment [RFC4020] requests (called "early allocation" in that doc) from IETF working groups that reference a sufficiently stable Internet-Draft instead of a published Standards-Track RFC 🫶

  • Port Number: if you want a port number, you MUST provide either the port number you're suggesting or the port range you want (user or system). If you only want a service name, leave this field empty. If you ask for a specific port number, IANA is encouraged to assign the number you requested. If you specify a range, IANA will pick a suitable number from the User or System Ports ranges. Heads up: the applicant MUST NOT use the requested port in implementations deployed on the public Internet before the assignment is completed, because there's no guarantee IANA will actually give you that port 😭
  • Service Code: if the request includes DCCP as a transport protocol, then the request MUST include a desired unique DCCP service code [RFC5595], and MUST NOT include a requested DCCP service code otherwise. Section 19.8 of the DCCP specification [RFC4340] defines the requirements and rules for assignment, and this document updates them. As the DCCP Service Codes document [RFC5595] notes, some service codes aren't assigned at all. Zero (no meaningful service code at all) and 4294967295 (0xFFFFFFFF, an invalid service code) are permanently reserved. The Private service codes 1056964608-1073741823 (0x3F000000-0x3FFFFFFF, i.e., 32-bit values whose high-order byte is 63 (0x3F), which matches the ASCII character '?') are not centrally assigned 🎀
  • Known Unauthorized Uses: a list of uses by applications or organizations that are not the Assignee. This is OPTIONAL. IANA can add to this list after assignment when unauthorized uses get reported 🍓
  • Assignment Notes: notes about owner or name changes, or any other assignment process issue. This is OPTIONAL. IANA can update this list after assignment to help track changes to an assignment, like de-assignment, owner or name changes, and so on 🌈

If the request is to add a new transport protocol to a service name that's already assigned, and the requester isn't the Assignee or Contact for that existing service name, IANA has to check with the Assignee for the existing assignment about whether the addition is okay 🫠

If the request is for a new service name that shares a port with a previously assigned service name (see port number overloading in Section 5), IANA needs to check with the Assignee for the existing service name and other appropriate experts about whether the overloading is appropriate 👀

When IANA gets an assignment request that includes all of the above info and asks for a port number, IANA SHALL start an "Expert Review" [RFC5226] to decide whether the assignment should be made 🔍 For requests that aren't seeking a port number, IANA SHOULD assign the service name under a simple "First Come First Served" policy [RFC5226] ✨

8.1.2. Variances for Specific Port Number Ranges 🌸

Section 6 covers the different port number ranges. It's really important to know that IANA uses slightly different procedures when managing each range in the service name and port number registry 🧠

  • Dynamic Ports range (49152-65535): these ports are specifically set aside for local and dynamic use, so they can't be assigned through IANA. Application software can just use any dynamic port that's free on the local host, no assignment needed 🦋 That said, application software MUST NOT assume that a specific port number in the Dynamic Ports range will always be available for communication at all times, so a port number in that range MUST NOT be used as a service identifier 🙅‍♀️
  • User Ports range (1024-49151): these are available for assignment through IANA, and MAY be used as service identifiers once they're successfully assigned 💖 Since assigning a port to one application uses up a bit of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. For most IETF protocols, User Ports range assignments go through the "IETF Review" or "IESG Approval" procedures [RFC5226], and no further documentation is required. Where those procedures don't apply, the requester has to put the documentation into the "Expert Review" procedure [RFC5226], where IANA has a technical expert review the request to decide whether to grant the assignment. No matter which path you take ("IETF Review", "IESG Approval", or "Expert Review"), the submitted documentation is expected to be the same, as described in this section, and it MUST explain why using a port number in the Dynamic Ports range is unsuitable for the application. IANA MAY also use the "Expert Review" process informally to help decide its position when participating in "IETF Review" and "IESG Approval" 🎀
  • System Ports range (0-1023): these are also available for assignment through IANA. The System Ports range is both the smallest and the most densely assigned, so the requirements for new assignments are stricter than for the User Ports range. They're only granted under the "IETF Review" or "IESG Approval" procedures [RFC5226] 👑 A request for a System Port number MUST document both why using a port number from the Dynamic Ports range is unsuitable and why using a port number from the User Ports range is unsuitable for that application 🫶

8.2. Service Name and Port Number De-Assignment 🧹

The Assignee of a granted port number assignment can give the port number back to IANA at any time if they no longer need it. The port number will then be de-assigned and marked as Reserved. IANA should not reassign de-assigned port numbers until all unassigned port numbers in that specific range have been assigned 🍃

Before IANA goes ahead with a port number de-assignment, it needs to reasonably establish that the value is actually no longer in use 🔎

Since there's much less danger of running out of service name space compared to port number space, it is RECOMMENDED that a given service name stay assigned even after all of its associated port number assignments have been de-assigned 💜 Under this policy, it will show up in the registry as if it had been created through a service name assignment request that didn't include any port numbers.

Every once in a while it may still be useful to de-assign a service name. In those cases, IANA will mark the service name as Reserved and will involve their IESG-appointed expert 🙈

IANA will include a comment in the registry whenever a de-assignment happens, to note its historic usage 📜

8.3. Service Name and Port Number Reuse ♻️

Okay so, if the Assignee of a granted port number assignment no longer needs the number but wants to reuse it for a different application, they can submit a request to IANA to do so 🦋

Logically, port number reuse is treated as a de-assignment (Section 8.2) followed by an immediate (re-)assignment (Section 8.1) of the same port number for a new application. So the info you give about the proposed new use is identical to what you'd provide for a brand new port number assignment in that specific ports range 💅

Because there is way less danger of running out of service names than port numbers, it is RECOMMENDED that the original service name tied to the prior use stays assigned, and that a new service name gets created and associated with the port number. This is again consistent with viewing a reuse request as a de-assignment followed by an immediate (re-)assignment. Reusing an assigned service name for a different application is NOT RECOMMENDED 🙅

IANA needs to review these requests super carefully before approving them ✨ Sometimes the Expert Reviewer will find that the application the port number was assigned to has picked up usage beyond the original Assignee, or that there's a concern it may have such users. This determination MUST be made quickly 🚨 A community call concerning revocation of a port number (see below) MAY be considered if a broader use of the port number is suspected.

8.4. Service Name and Port Number Revocation 🫥

A port number revocation is basically an IANA-initiated de-assignment (Section 8.2), and it has exactly the same effect on the registry.

Sometimes it's super clear that a specific port number is no longer in use, and IANA can revoke it and mark it as Reserved. Other times it's unclear whether an assigned port number is still being used somewhere on the Internet. In those cases, IANA must carefully consider the consequences of revoking the port number, and SHOULD only do so if there is an overwhelming need 😬

With the help of their IESG-appointed Expert Reviewer, IANA SHALL formulate a request to the IESG to issue a four-week community call concerning the pending port number revocation. The IESG and IANA, with the Expert Reviewer's support, SHALL determine promptly after the end of the community call whether revocation should proceed, and then communicate their decision to the community. This procedure typically involves similar steps to de-assignment, except that it's initiated by IANA.

Because there is way less danger of exhausting the service name space compared to the port number space, revoking service names is NOT RECOMMENDED 🌸

8.5. Service Name and Port Number Transfers 🚫

The value of service names and port numbers comes from careful management as a shared Internet resource, whereas enabling transfers opens the door to monetary exchanges. As a result, the IETF does not permit service name or port number assignments to be transferred between parties, even when they're mutually consenting 🙅‍♀️

The appropriate alternate procedure is a coordinated de-assignment and assignment: the new party requests the service name or port number via an assignment, and the previous party releases its assignment via the de-assignment procedure outlined above 🤝

With the help of their IESG-appointed Expert Reviewer, IANA SHALL carefully determine if there is a valid technical, operational, or managerial reason to grant the requested new assignment.

8.6. Maintenance Issues 🛠️

In addition to the formal procedures described above, updates to the Description and Contact information are coordinated by IANA in an informal manner. These updates may be initiated by either the Assignee or by IANA, e.g., by the latter requesting an update to current Contact information. (Note that the Assignee cannot be changed as a separate procedure; see instead Section 8.5 above.) 📝

8.7. Disagreements 🗣️

In the case of disagreements around any request, there is the possibility of appeal following the normal appeals process for IANA assignments, as defined by Section 7 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. 🫶

9. Security Considerations 🔐

The IANA guidelines described in this document do not change the security properties of UDP, TCP, SCTP, or DCCP. Phew, the protocols themselves stay exactly as safe (or not) as they were 💜

Assignment of a service name or port number does not in any way imply an endorsement of an application or product. The fact that network traffic is flowing to or from an assigned port number does not mean that it is "good" traffic, or even that it is used by the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, NOT based on whether or not there is an assigned service name or port number. Main character energy for real 🧱

Services are expected to include support for security, either as a default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided, in order to discourage the deployment of insecure services. Insecure services should not get their own shiny registry entries 💀

10. IANA Considerations 📚

This document obsoletes Sections 8 and 9.1 of the March 2000 IANA Allocation Guidelines [RFC2780]. Bye bye, old rules 👋

Upon approval of this document for publication as an RFC, IANA worked with Stuart Cheshire, maintainer of the independent service name registry [SRVREG], to merge the contents of that private registry into the official IANA registry. The independent registry web page has been updated with pointers to the IANA registry and to this RFC. Teamwork makes the dream work 🌈

IANA created a new service name entry in the service name and port number registry [PORTREG] for all entries in the Protocol and Service Names registry [PROTSERVREG] that did not already have one assigned ✨

IANA also indicates in the Assignment Notes for "www" and "www-http" that they are duplicate terms that refer to the "http" service, and should not be used for discovery purposes. For this conceptual service (human-readable web pages served over HTTP), the correct service name to use for service discovery purposes is "http" (see Section 5). Use "http," not "www," bestie 🎀

10.1. Service Name Consistency ✨

okay so Section 8.1 is where we finally define which strings count as well-formed service names 💅. before this, nobody had really nailed it down. the definition in Section 8.1 was picked to be as compatible as possible with current and future service discovery mechanisms 🔥.

as of August 5, 2009, about 98% of the so-called "Short Names" in existing port number assignments [PORTREG] already followed the rules for legal service names in Section 8.1 🎀. for those services, the service name is exactly the same as their "Short Name" 🌸.

the other roughly 2% can't be used as-is, because they contain illegal characters like asterisks, dots, pluses, slashes, or underscores 💀. every existing "Short Name" does meet the length rule of 15 characters or fewer ✨. for those 96 unsuitable "Short Names" (listed in the table below), the service name is the Short Name with each illegal character swapped for a hyphen 🦋. IANA added a new entry to the registry for the well-formed primary service name. that entry otherwise duplicates the original assignment info 💖. in its description field, IANA recorded that it assigned a well-formed service name for the previous service and linked back to the original assignment 🧚. then in the Assignment Notes field of the original assignment, IANA added a note saying this entry is an alias for the new well-formed name, and that the old service name is historic and not usable with many common service discovery mechanisms 😭.

96 names containing illegal characters to be replaced by hyphens:

      +----------------+-----------------+-----------------+
      | 914c/g         | acmaint_dbd     | acmaint_transd  |
      | atex_elmd      | avanti_cdp      | badm_priv       |
      | badm_pub       | bdir_priv       | bdir_pub        |
      | bmc_ctd_ldap   | bmc_patroldb    | boks_clntd      |
      | boks_servc     | boks_servm      | broker_service  |
      | bues_service   | canit_store     | cedros_fds      |
      | cl/1           | contamac_icm    | corel_vncadmin  |
      | csc_proxy      | cvc_hostd       | dbcontrol_agent |
      | dec_dlm        | dl_agent        | documentum_s    |
      | dsmeter_iatc   | dsx_monitor     | elpro_tunnel    |
      | elvin_client   | elvin_server    | encrypted_admin |
      | erunbook_agent | erunbook_server | esri_sde        |
      | EtherNet/IP-1  | EtherNet/IP-2   | event_listener  |
      | flr_agent      | gds_db          | ibm_wrless_lan  |
      | iceedcp_rx     | iceedcp_tx      | iclcnet_svinfo  |
      | idig_mux       | ife_icorp       | instl_bootc     |
      | instl_boots    | intel_rci       | interhdl_elmd   |
      | lan900_remote  | LiebDevMgmt_A   | LiebDevMgmt_C   |
      | LiebDevMgmt_DM | mapper-ws_ethd  | matrix_vnet     |
      | mdbs_daemon    | menandmice_noh  | msl_lmd         |
      | nburn_id       | ncr_ccl         | nds_sso         |
      | netmap_lm      | nms_topo_serv   | notify_srvr     |
      | novell-lu6.2   | nuts_bootp      | nuts_dem        |
      | ocs_amu        | ocs_cmu         | pipe_server     |
      | pra_elmd       | printer_agent   | redstorm_diag   |
      | redstorm_find  | redstorm_info   | redstorm_join   |
      | resource_mgr   | rmonitor_secure | rsvp_tunnel     |
      | sai_sentlm     | sge_execd       | sge_qmaster     |
      | shiva_confsrvr | sql*net         | srvc_registry   |
      | stm_pproc      | subntbcst_tftp  | udt_os          |
      | universe_suite | veritas_pbx     | vision_elmd     |
      | vision_server  | wrs_registry    | z39.50          |
      +----------------+-----------------+-----------------+

on top of those 96, the service name for "whois++" is "whoispp" 🍓. that follows the lead of the "application/whoispp-query" MIME Content-Type [RFC2957] ✨.

four names in IANA's Port Number Registry [PORTREG] clashed with names already in the ad hoc SRV name registry [SRVREG]: esp, hydra, recipe, and xmp 😭. but the drama was resolved super nicely 🫶.

  • the Port Number Registry Short Name "esp" was registered by Andrew Chernow. he told the authors the port wasn't in use anymore and the registration wasn't needed, so the SRV registry entry for "esp" stays in effect 🌈.
  • the SRV name "hydra" for SubEthaEdit had already been retired in favor of the new SRV name "see". the Port Number Registry entry for "hydra" stays in effect 💜.
  • the SRV name "recipe" was being used by an open source project that hadn't been packaged for distribution yet. the registrant, Daniel Taylor, was happy to switch to a different service name. huge thanks to Daniel Taylor for being so accommodating 👑. the Port Number Registry entry for "recipe" stays in effect ✨.
  • the Port Number Registry Short Name "xmp" was registered by Bobby Krupczak. his registration included an assigned port number that's still in use and isn't affected by this change, so he was willing to switch to a different service name 🦋. thanks to Bobby Krupczak too 🫶. the SRV registry entry for "xmp" stays in effect 🌸.

10.2. Port Numbers for SCTP and DCCP Experimentation

two System UDP and TCP ports, 1021 and 1022, were reserved for experimental use [RFC4727] 🧚. this document gives those same port numbers to SCTP and DCCP too, updates the TCP and UDP assignments, and tells IANA to automatically assign these two port numbers to any future transport protocol with a similar 16-bit port number namespace 💖.

and yes, these ports are only meant for temporary experiments and development in controlled environments 🙈. before you touch them, seriously think about the advice in Section 6.1 of this document, plus Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] 📚. most importantly, application developers must request a permanent port number assignment from IANA as described in Section 8.1 before any kind of non-experimental deployment 🚨.

        +--------------------+-----------------------------+
        | Service Name       | exp1                        |
        | Transport Protocol | DCCP, SCTP, TCP, UDP        |
        | Assignee           | IESG <iesg@ietf.org>        |
        | Contact            | IETF Chair <chair@ietf.org> |
        | Description        | RFC3692-style Experiment 1  |
        | Reference          | [RFC4727] [RFC6335]         |
        | Port Number        | 1021                        |
        +--------------------+-----------------------------+

        +--------------------+-----------------------------+
        | Service Name       | exp2                        |
        | Transport Protocol | DCCP, SCTP, TCP, UDP        |
        | Assignee           | IESG <iesg@ietf.org>        |
        | Contact            | IETF Chair <chair@ietf.org> |
        | Description        | RFC3692-style Experiment 2  |
        | Reference          | [RFC4727] [RFC6335]         |
        | Port Number        | 1022                        |
        +--------------------+-----------------------------+

10.3. Updates to DCCP Registries

this document updates the IANA assignment procedures for the DCCP Port Number and DCCP Service Codes Registries [RFC4340] 🦋.

10.3.1. DCCP Service Code Registry

service codes get handed out on a "first come, first served" basis, following Section 19.8 of the DCCP specification [RFC4340] 🍓. this document beefs up those guidelines in a couple of ways ✨:

  • IANA MAY assign new service codes without seeking "Expert Review" at its discretion, but SHOULD seek "Expert Review" if a request asks for more than five service codes 💅.
  • IANA should feel free to contact the DCCP Expert Reviewer with any questions about requests for DCCP-related codepoints 🫶.

10.3.2. DCCP Port Numbers Registry

the DCCP ports registry is defined by Section 19.9 of the DCCP specification [RFC4340] 🎀. assignments in this registry need a service code to be assigned first. not every service code needs an IANA-assigned port 🌈. this document updates that section with these extra guidelines 👑:

  • IANA should normally assign a value in the range 1024-49151 to a DCCP server port. IANA requests to assign port numbers in the System Ports range (0 through 1023) require an "IETF Review" [RFC5226] before IANA assigns them [RFC4340] 🧚.
  • IANA MUST NOT assign more than one DCCP server port to a single service code value 🚫.
  • assigning multiple service codes to the same DCCP port is allowed, but it's subject to "Expert Review" 💜.
  • the set of service code values tied to a DCCP server port should be recorded in the service name and port number registry 📚.
  • asking for more service codes to be associated with an already assigned port number requires "Expert Review" 🔥. these requests will normally be accepted when they come from the contact tied to the port assignment. in other cases, those applications will be expected to use an unassigned port, when one is available 💖.

the DCCP specification [RFC4340] notes that a short port name MUST be associated with each DCCP server port that has been assigned 🚨. this document clarifies that this short port name is the service name defined here, and that this name MUST be unique ✨.

11. Contributors

Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have contributed text and ideas to this document 🫶.

12. Acknowledgments

the text in Section 10.3 is based on a suggestion first proposed as part of the DCCP Service Codes document [RFC5595] by Gorry Fairhurst 🌸.

Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program 🇪🇺✨.

13. References

13.1. Normative References 📚✨

Okay bestie, these are the must-reads 💅 Every one of these is pulled in for the spec, so here's the full list, nothing cut:

[ANSI.X3.4-1986]  American National Standards Institute, "Coded
                  Character Set - 7-bit American Standard Code for
                  Information Interchange", ANSI X3.4, 1986.

[RFC0768]         Postel, J., "User Datagram Protocol", STD 6,
                  RFC 768, August 1980.

[RFC0793]         Postel, J., "Transmission Control Protocol", STD 7,
                  RFC 793, September 1981.

[RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2780]         Bradner, S. and V. Paxson, "IANA Allocation
                  Guidelines For Values In the Internet Protocol and
                  Related Headers", BCP 37, RFC 2780, March 2000.

[RFC2782]         Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
                  RR for specifying the location of services (DNS
                  SRV)", RFC 2782, February 2000.

[RFC3828]         Larzon, L-A., Degermark, M., Pink, S., Jonsson,
                  L-E., and G. Fairhurst, "The Lightweight User
                  Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.

[RFC4020]         Kompella, K. and A. Zinin, "Early IANA Allocation
                  of Standards Track Code Points", BCP 100, RFC 4020,
                  February 2005.

[RFC4340]         Kohler, E., Handley, M., and S. Floyd, "Datagram
                  Congestion Control Protocol (DCCP)", RFC 4340,
                  March 2006.

[RFC4727]         Fenner, B., "Experimental Values In IPv4, IPv6,
                  ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727,
                  November 2006.

[RFC4960]         Stewart, R., "Stream Control Transmission
                  Protocol", RFC 4960, September 2007.

[RFC5226]         Narten, T. and H. Alvestrand, "Guidelines for
                  Writing an IANA Considerations Section in RFCs",
                  BCP 26, RFC 5226, May 2008.

[RFC5234]         Crocker, D. and P. Overell, "Augmented BNF for
                  Syntax Specifications: ABNF", STD 68, RFC 5234,
                  January 2008.

[RFC5595]         Fairhurst, G., "The Datagram Congestion Control
                  Protocol (DCCP) Service Codes", RFC 5595,
                  September 2009.

13.2. Informative References 🌸

These ones are the extra context, the "ooh, go read this if you're curious" pile 🦋 Same deal, every single entry is here:

[DNS-SD]          Cheshire, S. and M. Krochmal, "DNS-Based Service
                  Discovery", Work in Progress, February 2011.

[IGD]             UPnP Forum, "Internet Gateway Device (IGD) V 1.0",
                  November 2001.

[NAT-PMP]         Cheshire, S., "NAT Port Mapping Protocol (NAT-
                  PMP)", Work in Progress, April 2008.

[PORTREG]         Internet Assigned Numbers Authority (IANA),
                  "Service Name and Transport Protocol Port Number
                  Registry",
                  <http://www.iana.org/assignments/port-numbers>.

[PROTSERVREG]     Internet Assigned Numbers Authority (IANA),
                  "Protocol and Service Names Registry",
                  <http://www.iana.org/assignments/service-names>.

[RFC0959]         Postel, J. and J. Reynolds, "File Transfer
                  Protocol", STD 9, RFC 959, October 1985.

[RFC1078]         Lottor, M., "TCP port service Multiplexer
                  (TCPMUX)", RFC 1078, November 1988.

[RFC1340]         Reynolds, J. and J. Postel, "Assigned Numbers",
                  RFC 1340, July 1992.

[RFC1700]         Reynolds, J. and J. Postel, "Assigned Numbers",
                  RFC 1700, October 1994.

[RFC2957]         Daigle, L. and P. Faltstrom, "The application/
                  whoispp-query Content-Type", RFC 2957,
                  October 2000.

[RFC3232]         Reynolds, J., "Assigned Numbers: RFC 1700 is
                  Replaced by an On-line Database", RFC 3232,
                  January 2002.

[RFC3692]         Narten, T., "Assigning Experimental and Testing
                  Numbers Considered Useful", BCP 82, RFC 3692,
                  January 2004.

[RFC4342]         Floyd, S., Kohler, E., and J. Padhye, "Profile for
                  Datagram Congestion Control Protocol (DCCP)
                  Congestion Control ID 3: TCP-Friendly Rate Control
                  (TFRC)", RFC 4342, March 2006.

[RFC4844]         Daigle, L. and Internet Architecture Board, "The
                  RFC Series and RFC Editor", RFC 4844, July 2007.

[RFC5237]         Arkko, J. and S. Bradner, "IANA Allocation
                  Guidelines for the Protocol Field", BCP 37,
                  RFC 5237, February 2008.

[RFC5389]         Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
                  "Session Traversal Utilities for NAT (STUN)",
                  RFC 5389, October 2008.

[RFC5766]         Mahy, R., Matthews, P., and J. Rosenberg,
                  "Traversal Using Relays around NAT (TURN): Relay
                  Extensions to Session Traversal Utilities for NAT
                  (STUN)", RFC 5766, April 2010.

[SRVREG]          "DNS SRV Service Types Registry",
                  <http://www.dns-sd.org/ServiceTypes.html>.

[SYSFORM]         Internet Assigned Numbers Authority (IANA),
                  "Application for System (Well Known) Port Number",
                  <http://www.iana.org/>.

[TRILOGY]         "Trilogy Project",
                  <http://www.trilogy-project.org/>.

[USRFORM]         Internet Assigned Numbers Authority (IANA),
                  "Application for User (Registered) Port Number",
                  <http://www.iana.org/>.

Authors' Addresses 💖

Meet the squad who wrote this! Here are all the contact details, exactly as they appear 🫶

Michelle Cotton
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA  90292
USA

Phone: +1 310 823 9358
EMail: michelle.cotton@icann.org
URI:   http://www.iana.org/


Lars Eggert
Nokia Research Center
P.O. Box 407
Nokia Group  00045
Finland

Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI:   http://research.nokia.com/people/lars_eggert/


Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA  90292
USA

Phone: +1 310 448 9151
EMail: touch@isi.edu
URI:   http://www.isi.edu/touch


Magnus Westerlund
Ericsson
Farogatan 6
Stockholm  164 80
Sweden

Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com
Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA  95014
USA

Phone: +1 408 974 3207
EMail: cheshire@apple.com
URI:   http://stuartcheshire.org/
📦 where this page comes from