skip to content

How does RFC 4787 describe a NAT's mapping and filtering behaviour, and why did it retire RFC 3489's full-cone, restricted-cone and symmetric labels?

level: seniorimportance: should knowfreq 27%

answer

  1. two independent axes
  2. when is a public port reused
  3. who may send in
  4. one MUST, one RECOMMENDED
  5. real NATs fitting no label

basics

~20 s

RFC 4787 splits NAT behaviour into mapping (when a public port is reused across destinations) and filtering (which outside senders may reach it), each endpoint-independent, address-dependent or address-and-port-dependent. RFC 3489's four labels mixed both axes and misdescribed real NATs.

solid answer

~50 s

RFC 4787 (a Best Current Practice for NATs handling UDP) describes two independent behaviours. **Mapping** says when a NAT reuses the same public address and port for packets from one inside address and port: for any destination (*endpoint-independent*), only for the same destination IP (*address-dependent*), or only for the same destination IP and port (*address and port-dependent*). **Filtering** says which outside senders may use that mapping, along the same three steps. REQ-1 makes endpoint-independent mapping a MUST, because anything else forces a relay; REQ-8 recommends endpoint-independent filtering where application transparency matters most and address-dependent filtering where stricter filtering does. RFC 3489's "full cone", "restricted cone", "port restricted cone" and "symmetric" were four fixed combinations of the two axes, and RFC 4787 says the terms proved inadequate for real NATs, many of which fit none of them.

go deeper

for a junior

Know that NAT behaviour has two parts, which public port gets reused and who is allowed to send back in, and that the old cone words are outdated.

for a middle

Define the three mapping and three filtering behaviours precisely and translate each RFC 3489 label into the pair it stands for.

for a senior

Use the two axes to predict traversal outcomes, cite REQ-1 and REQ-8, and explain why mapping choice adds no security while filtering decides it.

for a principal

When you set requirements for NAT equipment you deploy, weigh endpoint-independent filtering's transparency against address-dependent filtering's strictness for the applications you must support.

## Two questions about every NAT RFC 4787 (BCP 127, the behavioural requirements for NATs that handle unicast UDP) stops classifying NATs as whole types and asks two separate questions about each one. **Mapping: when does the NAT reuse a public address and port?** An inside endpoint `X:x` sends to an outside endpoint `Y1:y1` and is given the public mapping `X1':x1'`. It then sends to a second endpoint `Y2:y2` and gets `X2':x2'`. The behaviour is defined by when `X2':x2'` equals `X1':x1'`: - **Endpoint-independent mapping** reuses the mapping for any destination. - **Address-dependent mapping** reuses it only if `Y2` equals `Y1`, whatever the port. - **Address and port-dependent mapping** reuses it only if `Y2:y2` equals `Y1:y1`. **Filtering: which outside packets may use the mapping?** Once `X:x` has sent to some endpoints: - **Endpoint-independent filtering** admits any packet addressed to the mapping, from anyone. - **Address-dependent filtering** admits packets only from IP addresses `X:x` has already sent to, from any port. - **Address and port-dependent filtering** admits packets only from the exact address and port `X:x` has sent to. ## What RFC 4787 requires | Requirement | Text | Why | |---|---|---| | REQ-1 | a NAT MUST have endpoint-independent mapping | otherwise traversal methods fail and a UDP relay is forced | | REQ-8 | endpoint-independent filtering RECOMMENDED if application transparency matters most; address-dependent filtering RECOMMENDED if stricter filtering matters most | filtering is where the security trade-off lives | | REQ-5 | a UDP mapping timer MUST NOT expire in under two minutes; five minutes or more RECOMMENDED as the default | avoids constant refresh traffic | | REQ-9 | a NAT MUST support hairpinning | lets inside hosts reach each other through public mappings | The RFC makes one point that is easy to miss: the choice of **mapping** behaviour makes **no difference to the NAT's security**. Security is decided entirely by which packets the filter lets in. So a NAT that allocates a new port per destination in the belief that it is safer gains nothing in protection and breaks traversal. ## The old labels, translated RFC 3489, the original STUN specification (obsoleted by RFC 5389 and then RFC 8489), described four "treatments" observed for UDP: | RFC 3489 label | Mapping | Filtering | |---|---|---| | Full cone | endpoint-independent | endpoint-independent | | Restricted cone | endpoint-independent | address-dependent | | Port restricted cone | endpoint-independent | address and port-dependent | | Symmetric | address and port-dependent | address and port-dependent | ## Why the labels were retired 1. **They tie two axes together.** Only four of the nine combinations have names. A NAT with **address-dependent mapping**, or one with dependent mapping but lenient filtering, fits none of them. 2. **They hide the axis that matters for traversal.** Whether hole punching can work depends mainly on mapping; whether unsolicited traffic gets in depends on filtering. A single label blurs which property is responsible for a failure. 3. **Real NATs vary along other axes too.** RFC 4787 also describes port assignment (port preservation, and the forbidden *port overloading*), IP address pooling (*paired* recommended, *arbitrary* problematic), refresh direction and timers, none of which the labels capture. 4. **The classification algorithm built on them did not work.** RFC 5389 recorded that classic STUN's procedure for detecting the NAT type was faulty, because many NATs did not fit cleanly into the types. RFC 4787 states it directly: the cone/symmetric terminology was the source of much confusion and proved inadequate at describing real-life NAT behaviour. ## Using the vocabulary - Say "endpoint-dependent mapping" (RFC 5128's umbrella term for the two dependent kinds) rather than "symmetric" when explaining why hole punching fails. - Ask about both axes when predicting whether two peers can connect: endpoint-independent mapping on both sides usually means a direct path; dependent mapping on both sides with port-dependent filtering means a relay. - Remember these are **requirements on NATs**, not descriptions of every NAT deployed. Devices built before or without regard to RFC 4787 still exist, which is why ICE tests real paths instead of trusting a classification. - Keep the "cone" words only for reading older material, and translate them when you meet them.

  • If mapping behaviour does not affect security, why did some NATs adopt address and port-dependent mapping?
    Usually from a belief that allocating a fresh port per destination hides internal hosts better. RFC 4787 rejects that argument: protection comes entirely from which inbound packets the filter admits. The cost is real, since peers cannot reuse a mapping they learned from a server, so traversal often falls back to a relay.
  • Which RFC 4787 filtering behaviour do TURN permissions imitate?
    Address-dependent filtering. RFC 8656 says TURN permissions mimic the address-restricted filtering of RFC 4787-compliant NATs: a permission is an IP address with a lifetime, and the relay forwards a peer's packet only if its source IP matches one, whatever the source port.

saying these in an interview costs you the question

  • A symmetric NAT is the secure choice because it gives each destination a new port.
  • Mapping and filtering are the same thing described from two directions.
  • RFC 4787 requires endpoint-independent filtering of every NAT.
  • Every NAT can be classified as one of the four cone or symmetric types.
  • Full cone means the NAT keeps the inside port number on the outside.