What are the three IANA port-number ranges for TCP and UDP, and where does a client's ephemeral source port come from?
answer
- three ranges in a 16-bit space
- boundaries at 1023 and 49151
- one range IANA never assigns
- picked by the client's own stack
- unpredictable on purpose
basics
~20 sRFC 6335 splits the 16-bit space into System ports 0-1023, User ports 1024-49151 and Dynamic ports 49152-65535. A client's ephemeral port is chosen by its own stack at connect time from a locally configured range, ideally unpredictably (RFC 6056).
solid answer
~40 sRFC 6335 divides each transport's 16-bit port space into three ranges: **System** (Well-Known) ports `0-1023` and **User** (Registered) ports `1024-49151`, both assigned by IANA, and **Dynamic** (Private or Ephemeral) ports `49152-65535`, which IANA never assigns and which must not be used as a fixed service identifier. The ranges are a registry convention, not something TCP enforces: some systems require privilege to bind System ports, but RFC 7605 notes that distinction has blurred. A client's **ephemeral port** is chosen by its own stack when it connects without binding a port, from a range the implementation configures — RFC 6056 recommends selecting from the whole `1024-65535` range, excluding ports local services need. RFC 6056 also recommends making the choice unpredictable, because a guessable port helps an off-path attacker complete a connection's 5-tuple.
go deeper
Recall the three ranges and their boundaries, and that the client's source port is picked by the client's own stack, not by the server.
Explain that the ranges are a registry convention, that the ephemeral range is an implementation choice, and why the chosen port must keep the 5-tuple unique.
Explain why RFC 6056 randomises port selection, and use the host's real ephemeral range when reasoning about outbound connection capacity or return-traffic filters.
Weigh port policy as a platform decision: a wider ephemeral range buys outbound capacity but collides more with local services and filters that assume the IANA dynamic range.
## The port space and its three ranges TCP and UDP ports are 16-bit numbers, so each transport has 65,536 values. RFC 6335 (Section 6, BCP 165) defines how IANA manages that space and splits it into three ranges: | Range | Names | Assigned by IANA? | Intended use | |---|---|---|---| | `0-1023` | System ports, Well-Known ports | yes, strictest review | long-established services | | `1024-49151` | User ports, Registered ports | yes, on documented request | services that need a fixed number | | `49152-65535` | Dynamic, Private or Ephemeral ports | **never** | local and temporary use | RFC 6335 Section 8.1.2 adds two rules about the Dynamic range: applications may use any available dynamic port without assignment, but they "MUST NOT assume that a specific port number in the Dynamic Ports range will always be available", and such a port "MUST NOT be used as a service identifier". A service that needs a known port asks IANA for a User or System port and must explain why a dynamic port will not do. ## What the ranges do and do not mean - **They are a registry, not a protocol rule.** Nothing in the TCP state machine treats port `80` differently from port `50000`. The meaning of a well-known port is an agreement that a given service listens there. - **Privilege is an operating-system policy.** RFC 7605 (Sections 4 and 7.3) explains that System ports originally required privileged access and that "on some systems" they still do, but "some current systems do not limit access control to System port numbers", and it advises developers "to treat services as if they are always run without privilege". - **"Registered" is ambiguous.** RFC 7605 notes that since both System and User ports are IANA-assigned, "registered" sometimes means the whole `0-49151` span and sometimes only `1024-49151`. - **The same number can mean different things per transport.** A registration is per transport protocol, so TCP port *n* and UDP port *n* are separate namespaces. ## Where an ephemeral port comes from When a client calls `connect` without binding a port, its own stack fills in the local half of the connection: 1. It chooses the **local address**, normally from the route toward the destination. 2. It chooses a **local port** from its configured ephemeral range such that the resulting 5-tuple is unique — RFC 6056 (Section 2.2) states that "the selection of ephemeral port numbers must result in a unique five-tuple". 3. It sends the SYN (or, for UDP, the first datagram) from that socket. The server never chooses the client's port; it only sees it in the arriving SYN. The range used is **the implementation's choice**. RFC 6056 (Section 3.2) observes that the IANA dynamic range is `49152-65535` but recommends that "ephemeral port selection algorithms should use the whole range 1024-65535", while excluding any port a local service may need. Real stacks configure ranges of different sizes and positions, which matters when you estimate how many outgoing connections a host can hold toward one destination. ## Why the choice should be unpredictable RFC 6056 (BCP 156) exists because the traditional allocator was a global counter: the next port was the previous one plus one. Its Section 2.2 lists two problems: - **Guessability.** An off-path attacker who wants to inject into a connection must guess its whole 5-tuple. Addresses and the server port are usually known, so a predictable client port removes most of the guesswork. - **Information leak.** Watching the counter reveals how many connections a host opened in a period. The RFC's algorithms randomise the choice. Algorithm 3 keeps the good property of the counter — ports toward the same destination are reused as late as possible — by computing an offset from a keyed hash of the local address, remote address and remote port, so each destination gets its own unpredictable sequence. Reusing ports late matters because the previous connection's tuple may still be in TIME-WAIT at the server (RFC 6056 Section 2.3). ## Practical consequences - Estimating capacity toward one server: the size of the configured ephemeral range, not 65,535, is the number of client ports you have. - A client port number tells you nothing about the application; a server port usually does. - Filters written for return traffic must allow the whole range the client stack actually uses, not only `49152-65535`.
- Why does RFC 6056 care whether ephemeral ports are predictable?An off-path attacker who wants to inject a forged segment into a connection must guess its full 5-tuple. The addresses and the server port are usually known, so the client port is most of what remains. The traditional sequential allocator also leaks how many connections a host has opened. Randomised selection removes both, and RFC 6056's hash-based algorithms still reuse ports toward one destination as late as possible.
- Is a port in the System range automatically privileged?Not by protocol. RFC 7605 explains the range was meant to signal privilege and that some systems still require it, for example running as a privileged user, while others do not restrict it at all. Developers are advised to treat services as if they always run without privilege. Where the restriction exists, it is an operating-system policy.
saying these in an interview costs you the question
- Every port above 1023 is an ephemeral port.
- IANA assigns ports in the 49152-65535 range to specific applications.
- The server chooses the client's source port during the handshake.
- TCP itself refuses to use a System port without root privileges.
- Every stack picks ephemeral ports only from 49152-65535.