Summary
- RFC 5382 REQ-7 says a TCP NAT must not let different internal endpoints use the same address-and-port mapping simultaneously; otherwise two lawful connections to one common external endpoint can become indistinguishable.
- Port utilization, mapping allocation, filtering permission, TCP establishment, attribution and completed application work are separate receipts. A high-density allocation is not valid if it erases the identity needed by the next packet.
The green capacity cell
Imagine a carrier translator serving two households. A laptop behind the first subscriber opens a TCP connection. A workstation behind the second opens another. The translator assigns both the same public IPv4 address and the same public port because their destinations differ. Its internal table uses the remote address and port as an extra discriminator. Nothing immediately breaks. One public port appears to carry two conversations, and the utilization dashboard celebrates.
Now both users contact the same large service on the same TCP port. The two internal sources are different, but after translation their visible source address and port are identical. Their destination address and port are also identical. The external four-tuples collide. The optimization has used up the distinction on which the server, the return path and the translator depend.
This is the concrete failure behind section 7.1 of RFC 5382. The document calls the behavior “port overloading” and says it is undesirable because two internal endpoints sharing one mapping cannot establish simultaneous connections to a common external endpoint. REQ-7 turns the observation into a requirement: a NAT must not use port-overloading port assignment for TCP.
The rule is easy to misread as a conservative preference about capacity. It is stronger. It protects the meaning of an external coordinate. Saving the port does not merely increase contention; it makes identity conditional on private context that may vanish exactly when traffic converges.
Mapping reuse is not mapping co-ownership
RFC 5382 also requires endpoint-independent mapping for TCP. That can sound like an invitation to maximize reuse, but the subject of reuse matters. Endpoint-independent mapping means one internal endpoint can retain its mapping while talking to different external destinations. Port overloading means different internal endpoints share the same mapping at the same time. The former provides continuity for one claimant. The latter creates co-owners.
Those are not two positions on one efficiency dial. They are different statements about the object being named. A mapping can follow one internal address and port across several remote peers without losing its source identity. Once the mapping is lent simultaneously to another internal address and port, the translator must carry some additional secret to tell the claimants apart. Frequently that secret is the remote endpoint. If the peers later converge, the secret no longer distinguishes them.
Filtering is another independent surface. A stable mapping does not decide which external sources may send packets back. RFC 5382 explicitly discusses endpoint-independent and address-dependent filtering as security and transparency choices. Existing BTW analysis owns that distinction. REQ-7 asks a prior question: before a filter decides whether a packet is permitted, does the external source tuple name one internal claimant or several?
An allocation review should therefore resist three substitutions. “Endpoint-independent” does not mean shared by different internal endpoints. “Permitted by the filter” does not mean uniquely routable. “A SYN left the box” does not mean a connection was established. Each claim needs its own evidence.
The collision is not simultaneous open
RFC 5382 is also known for its treatment of TCP simultaneous open, and an existing BTW Article follows that history. The port-overloading problem is different.
In simultaneous open, two TCP peers actively initiate toward each other, their SYNs cross, and the endpoints move through a valid TCP state-machine path. The challenge for a NAT is not to mistake a valid inbound SYN for wholly unsolicited traffic. In a port-overloading collision, two separate internal endpoints have been projected onto one external source identity and they contact one common external endpoint. The problem is not crossed roles. It is that the translator admitted two claims that cannot remain distinct in the public tuple.
Keeping the cases separate matters operationally. A simultaneous-open failure calls for state-machine and policy evidence. A port-overloading failure calls for allocation evidence: which internal endpoints received which external mappings, for how long, under which generation of the assignment policy, and what happened when their destinations converged.
One packet capture at one endpoint cannot reconstruct that decision. The translator's table is part of the evidence, but it is not sufficient by itself. It must be connected to packet timestamps, allocation events and the outcome observed by both applications.
A public tuple is a temporary claim, not a spare part
IPv4 scarcity makes the optimization attractive. Public addresses are expensive and finite. Ports look numerous. A vendor can quote sessions per address, allocations per second and peak table size. A procurement team can compare boxes using those figures. The temptation is to treat every unused port as fungible capacity and every reuse as a gain.
TCP does not consume a port in isolation. A live flow has endpoints, sequence state and a return path. The external source address and port are a temporary claim through which the remote peer sends traffic back. The claim need not be permanent, globally meaningful beyond its lifetime or owned by the subscriber. It must nevertheless be unambiguous while the translator presents it as one TCP endpoint.
This is why exhaustion and collision should not be confused. When no compliant mapping is available, the translator can refuse a new connection and expose resource pressure. That failure is undesirable but legible. If it instead admits the connection by overloading an existing TCP mapping, the system may report success before the common-destination case silently corrupts identity. An honest refusal preserves the old claim and produces evidence. Ambiguous admission can damage both.
Capacity engineering should count the cost of uniqueness rather than define it away. Port blocks, address pools, timeouts and admission control are legitimate levers. None authorizes the translator to promise two internal endpoints the same usable public identity at the same moment.
Hairpinning reveals what applications believe
REQ-8 requires TCP hairpinning and says the hairpinned packet must carry the external source address and port. The scenario is two internal endpoints that know each other by their mapped external addresses. The translator turns the traffic back inside, but it preserves the source identity the applications expect to see.
Hairpinning is not the reason for REQ-7, yet it makes the identity contract visible. Applications exchange coordinates and then compare what arrives with the peer they intended to contact. If the translator substitutes an unexpected internal source, an implementation can reject or misassociate the packet. The public tuple is therefore not decorative. It participates in endpoint recognition.
Port overloading weakens that same recognition in another direction. A coordinate that names one claimant only when paired with a hidden remote qualifier is less portable than it appears. It may work inside one table, on one node, before one failover, for one destination pattern. It does not provide the stable singular claim that external peers and internal applications infer from the wire.
The operational requirement is not to make a tuple eternal. It is to preserve its meaning for the lifetime and scope in which the NAT uses it.
Diagnostics cannot own the session
RFC 5382's adjacent ICMP requirements reinforce a useful discipline. A NAT translating TCP should translate relevant Destination Unreachable messages, but receiving an ICMP message must not terminate the mapping or TCP connection. An error is evidence about a path or packet. It is not unilateral authority to destroy the identity state to which it refers.
Likewise, a timeout is an operating policy, not proof that an endpoint died. The RFC provides minimum idle periods when the NAT cannot determine endpoint activity: two hours and four minutes for established connections and four minutes for transitory connections. Existing BTW work examines the uncertainty of quiet TCP sessions. For REQ-7, the relevant point is narrower: while a mapping remains allocated, the translator must not treat its apparent inactivity as permission to lend the same TCP identity concurrently to another internal endpoint.
Application-level gateways create another accounting burden. If a translator modifies TCP sequence numbers, RFC 5382 says it must handle Selective Acknowledgement correctly. Every hidden mutation creates state that must be applied consistently to later evidence. Port overloading would add a more fundamental ambiguity before sequence translation even begins: which claimant's sequence space does the packet belong to?
The pattern is consistent. ICMP, idle timers, ALG state and port allocation all affect a session. None should be allowed to inherit more authority than its evidence supports.
What a conformance receipt must contain
A configuration screen saying “port overloading disabled” is an intention. A table row is a local state observation. A passing test is stronger only if it exercises the collision that the requirement forbids.
The minimum useful test starts with two distinct internal address-and-port pairs. The first opens a TCP connection to an external address and port and keeps its mapping live. The second then opens a connection to the same external address and port. Observe both translated source tuples. They must be distinct, or the second attempt must receive an explicit resource failure. Repeat across address-pool pressure, port exhaustion, policy reload and translator failover.
Preserve the internal tuple, external mapped tuple, remote tuple, protocol, allocation timestamp, policy version, node identity, failover epoch and deletion cause. Correlate the SYN, SYN-ACK and ACK for each flow. Then verify an application exchange independently. A completed handshake shows transport establishment; it does not prove useful work. A successful request shows more, but it does not retroactively validate the allocation policy for untested concurrency.
Attribution must be equally precise. An external address and port observed at a given time can identify a temporary mapping only within the quality of the allocation ledger and clocks. If the design permits multiple internal claimants, the remote peer becomes necessary to reconstruct the mapping. That dependence must be stated rather than hidden. Under REQ-7, the better design avoids simultaneous TCP co-ownership in the first place.
Sources
- RFC 5382 HTML
- RFC 5382 plain text
- RFC 5382 publication record
- IETF Datatracker record for RFC 5382
- RFC 5382 document history
- RFC 5382 references
- RFC 5382 errata search
- RFC 7857 HTML
- RFC 7857 plain text
- RFC 7857 publication record
- IETF Datatracker record for RFC 7857
- RFC 4787: NAT behavioral requirements for UDP
- RFC 6888: common requirements for carrier-grade NATs
- RFC 2663: IP network address translator terminology
- RFC 3022: traditional IP network address translator
- RFC 4008: NAT management information base
- RFC 1122: requirements for Internet hosts
- RFC 2018: TCP selective acknowledgment options
- RFC 5508: NAT behavioral requirements for ICMP
- Heng Lu, Running-Code Primacy
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
