In Basic NAT, how does a static one-to-one source mapping differ from a dynamic address pool, and what happens when that pool runs out?
answer
- fixed for the NAT's lifetime vs on demand
- binding released with the last session
- one inside host per public address
- ICMP code 13 on refusal
basics
~20 sA static mapping binds one inside address to one public address permanently, so it also admits inbound sessions; a dynamic pool lends a free address from a host's first outbound session until its last one ends. An exhausted pool refuses new hosts.
solid answer
~50 sIn **Basic NAT** (RFC 2663, RFC 3022) only addresses are translated, so each public address serves one inside host at a time. A **static mapping** fixes that pairing for the lifetime of the NAT's operation: mail relay `10.20.5.25` always leaves as `203.0.113.16`, and outside hosts can open sessions to `203.0.113.16` because the binding exists before they call. A **dynamic pool** binds a free address when an inside host starts its first outbound session, reuses it for that host's later sessions, and frees it when the last one ends, so the host's public address can differ from one busy period to the next. With seven pool addresses, at most seven inside hosts reach the outside at once. An eighth host's first packet gets no binding: RFC 3022 says access is abruptly cut off, and RFC 5508 says the translator SHOULD drop the packet and return ICMP Destination Unreachable code 13.
go deeper
Remember the pairing: static means one inside address always maps to the same public address; dynamic means an address is borrowed from a pool while the host is busy.
Explain the binding lifecycle from RFC 2663: bound by the first outbound session, shared by later sessions, freed after the last one, and why dependable inbound sessions need a static binding.
Show the operational edges: pool exhaustion refuses new hosts, changing public addresses break allow-lists and attribution, and pool addresses must be routed or ARP-answered at the outside.
Decide which hosts earn a fixed public identity, how the pool is sized against peak concurrency, and when address-only translation should give way to port translation.
## Basic NAT and its two kinds of binding RFC 2663 splits traditional NAT into **Basic NAT**, which translates IP addresses only, and **NAPT**, which also translates transport identifiers so that many hosts can share one address. In Basic NAT a public address cannot be shared: while it is bound to one inside host, no other inside host can use it. RFC 2663 section 3.1 then describes two ways an address becomes bound. | | Static one-to-one mapping | Dynamic address pool | |---|---|---| | When the binding exists | for the lifetime of the NAT's operation (RFC 2663 3.1.1) | from the host's first outbound session (RFC 3022 3.1) | | When it is released | never, while configured | when the last session using it ends (RFC 2663 3.2.3) | | Public address seen by others | always the same | whichever free address was picked this time | | Inbound sessions | possible: the binding is already there | not dependable: nothing maps an address before its host has sent, and the address changes between bindings | | Capacity | one public address per mapped host | as many simultaneous hosts as pool addresses | ## Static: an identity that does not move In the reserved example, an office with inside network `10.20.0.0/16` holds eight public addresses, `203.0.113.16` through `203.0.113.23`, routed to it by its provider. The mail relay `10.20.5.25` is statically mapped to `203.0.113.16`. Three properties follow: - Its outbound mail always comes from `203.0.113.16`, so partners can allow-list that address and reverse DNS can name it. - Outside mail servers can open sessions to `203.0.113.16`, because the mapping exists before their first packet: the same binding serves as source translation outbound and destination translation inbound. RFC 3022 section 2.1 notes that static mappings can "allow access to the local host from external hosts via a fixed public address". - The translator never has to manage that binding's lifetime; RFC 2663 says static assignment means the NAT "does not have to administer address management with session flows". The price is that the address is spent on one host whether it is busy or idle. ## Dynamic: addresses on loan The other seven addresses, `203.0.113.17` to `203.0.113.23`, form a pool for everyone else. The lifecycle of a binding is the three phases of RFC 2663 section 3.2: 1. **Binding.** Workstation `10.20.4.31` sends its first outbound packet; the translator picks a free address, say `203.0.113.19`, and binds it. 2. **Lookup and translation.** Every later session from `10.20.4.31` reuses that binding, so all its concurrent sessions share one public address, the behaviour RFC 4787 REQ-2 calls "Paired" pooling and recommends for pooled NATs. 3. **Unbinding.** When the translator believes the last session using the binding has ended, it frees `203.0.113.19` for someone else. Because a NAT cannot be sure a TCP or UDP session is over, it relies on idle timers. Two operational consequences are easy to miss: - The same workstation can appear as `.19` this morning and `.22` this afternoon. An allow-list at a partner, or an abuse report naming one address, needs the translator's time-stamped binding log to identify the inside host. - The pool addresses must actually reach the translator. RFC 3022 section 5.3 expects the provider to route them to the NAT; if they belong to the subnet on the NAT's outside LAN, section 6.2 says the NAT must answer ARP requests for them with its own MAC address, because no other node owns them. ## When the pool runs out Seven pool addresses mean seven simultaneous inside hosts. An eighth host's first outbound packet finds no free address, so no binding and no session state can be created: - RFC 3022 section 5.4: external access for the extra hosts "is abruptly cut off after the last global address from the address list is used up". - RFC 5508 REQ-8: a NAT that cannot establish a session for a new flow because of resource limits SHOULD send ICMP Destination Unreachable with code 13 (Communication Administratively Prohibited) and drop the packet. - Forwarding the packet untranslated is no fallback: a private source address in the public realm cannot receive replies. - RFC 3022 also lets a Basic NAT switch its last pool address over to port translation so that remaining hosts share it; that is NAPT, a different translation mode. The practical fix is sizing: static mappings for the few hosts that need a stable identity or inbound reachability, a pool sized to peak concurrent hosts, and port translation where a pool cannot be large enough.
- In Basic NAT, why can a host's public address change between two sessions under a dynamic pool?The binding lives only as long as some session uses it. Once the last one ends and the idle timer expires, the address returns to the pool, and the host's next first packet binds whichever address is free then. Anything that keys on the public address, such as a partner's allow-list or an abuse report, needs the translator's time-stamped binding log to map it back to the inside host.
- How do replies reach a Basic NAT's pool addresses in the first place?Something must deliver packets for those addresses to the translator. RFC 3022 expects the provider to route the pool to the NAT, typically with a static route. If the pool is carved from the subnet on the NAT's outside LAN, the NAT must answer ARP requests for those addresses with its own MAC address, because no other node owns them.
saying these in an interview costs you the question
- A static NAT mapping is only for inbound traffic; outbound traffic always uses the pool.
- With seven pool addresses, Basic NAT serves seven hosts plus any number sharing ports.
- A dynamic binding is kept forever once a host has used it.
- When the pool is empty, the NAT forwards the packet with its private source address.
- Each new session from the same host takes a different pool address.