skip to content

Why do idle TCP connections and UDP flows through a NAPT break, and what do RFC 4787 and RFC 5382 require of mapping timers?

level: middleimportance: should knowfreq 42%

answer

  1. bindings are soft state
  2. silence lets the timer run out
  3. two minutes for UDP
  4. two hours four minutes for established TCP

basics

~20 s

NAPT bindings expire after an idle period, and later packets then find no binding. RFC 4787 forbids UDP timers under two minutes; RFC 5382 forbids established-TCP timers under 2 hours 4 minutes, but many devices use far shorter ones.

solid answer

~50 s

A NAPT keeps each binding only while traffic refreshes its timer. When a flow goes quiet longer than the timer, the binding is deleted: the server's next packet matches nothing and is dropped, and the client's next packet may leave on a new external port the server does not recognize. RFC 4787 REQ-5 says a UDP mapping timer MUST NOT expire in under two minutes (shorter only for specific well-known destination ports) and recommends five or more; RFC 5382 REQ-5 sets the established-TCP idle-timeout floor at 2 hours 4 minutes and the transitory (opening or closing) floor at 4 minutes. RFC 4787 REQ-6 requires outbound traffic to refresh a mapping; inbound refresh is only allowed. Deployed translators often use much shorter timers, an implementation choice, so long-lived quiet connections need application heartbeats or keepalives sent more often than the shortest timer on the path.

go deeper

for a junior

Remember that a NAT forgets quiet flows: if nothing crosses it for long enough, the binding is gone and the connection stops working even though both ends still think it is open.

for a middle

Explain the timers and their floors: two minutes for UDP with five recommended, 2 hours 4 minutes for established TCP, 4 minutes for transitory TCP, and that outbound traffic must refresh a binding.

for a senior

Diagnose idle-connection loss from the symptoms, separate the RFC floor from a device's actual timer, and choose heartbeat or keepalive intervals below the shortest timer on the path.

for a principal

Weigh long translator timers, which hold ports and memory, against short ones that break quiet connections, and decide where heartbeats belong when you do not control every translator in the path.

## Bindings are soft state A NAPT (the translator commonly called PAT) holds a **binding** for every active flow: the private address and port on one side, the public address and assigned port on the other. Nothing in TCP or UDP tells the translator when a flow is truly finished. UDP has no connection at all, and a TCP connection can sit in the established state for days without sending a byte. So every binding carries an **idle timer**: each qualifying packet resets it, and when it runs out the binding, and the external port it held, are released. That makes silence dangerous. A connection that is perfectly healthy at both ends can lose its path through the translator just by being quiet. ## What the RFCs require | Timer | Source | Requirement | |---|---|---| | UDP mapping | RFC 4787 REQ-5 | MUST NOT expire in less than **two minutes**; a default of **five minutes or more** is RECOMMENDED | | UDP mapping, specific well-known destination ports | RFC 4787 REQ-5a | MAY be shorter, for an IANA-registered application on that port (0-1023) known to use short exchanges | | TCP, established phase | RFC 5382 REQ-5 | idle-timeout MUST NOT be less than **2 hours 4 minutes** | | TCP, partially open or closing phase | RFC 5382 REQ-5 | transitory idle-timeout MUST NOT be less than **4 minutes** | | TCP transitory, revisited | RFC 7857 section 2.1 | open and closing timers SHOULD be separately configurable; a NAT MAY go below 4 minutes, but a **4-minute minimum default** is RECOMMENDED | RFC 4787, RFC 5382 and RFC 7857 are Best Current Practice documents: they describe what a well-behaved NAT does, and real devices do not all comply. ## Why those particular numbers - **2 hours 4 minutes** comes from TCP keepalives. RFC 1122 says keepalives are optional, default to off, and when enabled must default to an interval of no less than two hours. A NAT that waits slightly over two hours can see a keepalive from any host using the default; the extra 4 minutes allows for packets still in flight. - **4 minutes** for the transitory phases reflects how long a connection that is opening or closing can stay idle while waiting for in-flight packets. - **Two minutes** for UDP is a floor chosen so that applications do not have to send refresh packets too often; five minutes is the recommended default. ## What refreshes a binding 1. **Outbound packets.** RFC 4787 REQ-6 says the NAT mapping refresh direction MUST include outbound: traffic from the internal host always keeps its binding alive. 2. **Inbound packets, optionally.** Inbound refresh is only a MAY, because it lets an outside party keep a mapping alive indefinitely. RFC 7857 section 7 adds that inbound packets the NAT's filtering rejects SHOULD NOT refresh the mapping. 3. **Not error replies.** RFC 7857 section 7.1 says outbound ICMP errors or TCP resets sent in response to inbound packets SHOULD NOT refresh it. So an application that only receives cannot count on the server's packets to hold the path open. ## What deployed translators do, and what breaks Many translators use timers far below these minimums, for example tens of seconds for UDP or well under two hours for idle TCP. That is an implementation or operator choice, not the RFC. The failure then looks like this: 1. A connection goes quiet: a database pool's spare connection, a long-poll, an idle SSH session. 2. The translator's timer expires and the binding is deleted. 3. The server sends data. It arrives at the public address and port, matches no binding and is typically dropped, so the server sees only retransmission timeouts. 4. The client sends data. The translator may drop it, or create a fresh binding. If that binding uses a different external port, the segment belongs to no connection the server knows, so the server answers with a reset. For UDP the symptom is a peer that suddenly appears from a new port, or traffic that stops arriving inside. ## Keeping a binding alive - Send an **application heartbeat** more often than the shortest timer on the path, from the inside. - If you rely on **TCP keepalives**, lower the interval well below the two-hour default; the default only satisfies a translator that honors RFC 5382's floor. - Have connection pools retire idle connections before the path's timers can, rather than discovering the loss on first use. - Do not depend on inbound traffic to refresh anything.

  • Why is the established-TCP floor 2 hours 4 minutes rather than a round two hours?
    RFC 1122 says TCP keepalives, when enabled, must default to an interval of no less than two hours. A NAT that waits a little longer than that can see a keepalive from a host using the default before it reaps the binding; RFC 5382 adds 4 minutes to allow for packets still in flight.
  • A UDP application only receives data after an initial request. Can the server's packets keep its NAT binding alive?
    Not reliably. RFC 4787 REQ-6 requires outbound refresh but leaves inbound refresh as a MAY, because inbound refresh lets an outsider hold a mapping open. The application should send something outbound, even a small keepalive, more often than the shortest mapping timer on the path.

saying these in an interview costs you the question

  • RFC 4787 sets the NAT UDP mapping timeout at 30 seconds.
  • A NAT always sends a reset to both ends when it expires a TCP binding.
  • TCP keepalive's two-hour default is enough to hold any NAT binding open.
  • Packets from the server always refresh the client's NAT binding.
  • After a binding expires, the next outbound packet always reuses the same external port.