How IANA Port Assignments Actually Work

A port number is a 16-bit field in every TCP and UDP header, so there are 65,536 of them, numbered 0 to 65535. The number tells the receiving machine which program should get the data. Nothing in the protocol says that port 22 must be SSH or that port 443 must be HTTPS. Those are agreements, and the place the agreements are written down is a single public list kept by the Internet Assigned Numbers Authority, IANA.

Its full name is the Service Name and Transport Protocol Port Number Registry. The rules for running it are set out in RFC 6335, published in 2011, which pulled several older lists together and wrote down how assignment, return and revocation work. If you have ever searched for "iana service name" followed by a port number, this is the document the answer comes from.

Who hands out port numbers#

IANA keeps the registry, but it does not decide every request on its own. Depending on the range, a request goes through one of three routes defined for IANA registries in general:

• IETF Review. The port is requested in an RFC that goes through the Internet Engineering Task Force's normal consensus process. This is the normal route for a protocol the IETF itself defines.
• IESG Approval. The IETF's steering group approves the request directly, without a full RFC.
• Expert Review. A designated expert reads the application and decides. This is the usual route for a vendor that wants a number for its product.

Whoever approves it, the result is the same: a row in the registry naming the service, the port, the transport protocol and the person or body that asked.

The three ranges#

RFC 6335 splits the number space into three blocks, and the rules differ sharply between them:

• System Ports, 0 to 1023. Also called the well-known ports. These are only granted through IETF Review or IESG Approval, and the request has to explain why a higher number would not do. This is where SMTP, DNS, HTTP and SSH live.
• User Ports, 1024 to 49151. Also called the registered ports. These can also go through Expert Review, so this is where most vendor products sit, like Microsoft's Remote Desktop on port 3389, and where 8080 sits as the registered "HTTP Alternate".
• Dynamic Ports, 49152 to 65535. Also called private or ephemeral ports. IANA never assigns these. They are left for temporary use, most often as the source port your own machine picks when it opens an outbound connection.

Operating systems do not all follow the last one. Windows moved its default outbound range to 49152–65535 in Vista, explicitly to match IANA's recommendation, having used 1025 to 5000 before. Linux still defaults to 32768 to 60999, which overlaps the top of the User range. So a connection from a Linux box can leave from a source port that is officially registered to something else, and nothing breaks, because a source port on an outbound connection is never where a server is listening.

The "privileged port" idea, where only root can listen below 1024, comes from Unix and not from IANA. Linux even makes it adjustable: the ip_unprivileged_port_start setting defaults to 1024 but can be lowered.

How a port gets assigned#

A few rules shape every assignment made today, and they explain some oddities you will see in the registry.

One port per service. IANA tries to give each application a single number and expects it to sort different kinds of messages internally, rather than asking for one port per feature. Ports in the lower ranges are a finite resource, so a request for five numbers gets pushback.

Only the transports you ask for. Older assignments almost always covered both TCP and UDP, whether the protocol used both or not, which is why you will find a UDP row for services that have never sent a datagram. Under RFC 6335, IANA assigns only the transports named in the request and marks the same number as Reserved for the others, so it stays free if the owner needs it later.

Returns go to the back of the queue. An assignee can hand a number back at any time. It becomes Reserved rather than unassigned, and the RFC says IANA should not reassign a returned number until every never-used number in that range has been given out. That protects software still in the field from a new service suddenly appearing on its port.

There are exceptions. Port 465 was briefly registered for SMTP over TLS, had that registration revoked, and was reassigned to an unrelated protocol called URD. Mail software kept using it for encrypted submission anyway. RFC 8314 in 2018 cleaned this up by adding a second TCP assignment, the service name submissions, on top of the existing one, and called it a one-time procedural exception to RFC 6335. So 465/tcp now has two official names at once.

The service name is the real key#

Every assignment carries a short service name, like ssh, https or ms-wbt-server. RFC 6335 is strict about the format: 1 to 15 characters, only letters, digits and hyphens, at least one letter, no hyphen at either end and no two hyphens in a row. Case is ignored when comparing names.

The name exists because port numbers are not the only way to find a service. DNS SRV records look up a service by name, in the form _ldap._tcp.example.com, and return whatever host and port the operator chose. A protocol that uses SRV does not strictly need a fixed number at all, which is why the registry also holds service names with no port attached. Those are assigned first come, first served, since there is no scarce resource to protect. In the copy of the registry we pulled on 27 September 2026, over a thousand rows were names with no number.

If you have read our piece on LDAP ports 389 and 636, this is why Active Directory clients can find domain controllers without anyone typing a port: they ask DNS for the SRV record by service name.

Reading a registry row#

The registry is published as a table with twelve columns. The ones worth reading are:

• Service Name and Port Number. The pair that was assigned. One port can appear several times with different names, and one name can appear on several ports.
• Transport Protocol. TCP, UDP, SCTP or DCCP. Each row covers exactly one, so 465/tcp and 465/udp are separate entries, and in this case they belong to different services.
• Description. A few words from the applicant, often terse. Port 3389's description is just "MS WBT Server", an old name for what became Remote Desktop.
• Assignee and Contact. Who requested it. For IETF protocols this is usually the IESG. For vendor ports it is often an individual, written in brackets with underscores for spaces.
• Reference. The RFC or document that defines the protocol, when there is one. Many vendor assignments have none.
• Unauthorized Use Reported. Notes on software known to use the port without being its assignee. Port 79, for example, carries a note about unauthorized use by some mail users, pointing to RFC 4146.

A useful habit is to read the whole set of rows for a port rather than the first one. Port 80 alone has entries for http, www and www-http, with notes marking the last two as duplicates that should not be used for service discovery.

Reserved, unassigned and squatted#

Not every number has a service. Four states are worth telling apart:

• Assigned. A service name and assignee are on record.
• Reserved. Held back and not available to request, either because it was returned, because it is being kept for another transport, or for protocol reasons. Port 0 is Reserved on both TCP and UDP, and in practice it is used as "pick any free port for me" when a program opens a socket.
• Unassigned. Free to be requested. There are still gaps even in the System range.
• Squatted. Not an official state at all, just a common one: software that picked a number without asking, or kept using one assigned to someone else. Game servers, malware and internal tools do this constantly. The registry only notes it when someone reports it.

That last point matters most. The registry records claims. It has no way to stop anyone from listening on any port, and IANA says so at the top of the registry page: an assignment is not an endorsement, and traffic on a registered port is not necessarily good traffic.

What an assignment does not tell you#

When a scan shows a port open, the registry tells you what that number was requested for. It cannot tell you what is running there. A web server on 3389, an SSH daemon on 443 to get through a strict firewall, a backdoor on a port nobody expects: all of these are common, and all of them would look like the assigned service to anyone reading only the number.

So treat the IANA name as a first guess and confirm it another way, by connecting and reading the banner, checking the TLS certificate, or asking whoever runs the machine. Our guide to what open ports reveal about an IP walks through that process, and the common ports cheat sheet lists the numbers you will meet most often.

When you just need the registry answer, our port lookup shows it for any number: the IANA and nmap service names, transports and descriptions on file, the range the port falls in, the reference document when there is one, and how often nmap's own data sees it open. For the ports people search most, it adds researched notes on what the service does and what to check when you find it exposed. The registry says who asked for a number. Everything after that is up to you to check.