Summary

  • RFC 3489 used three Binding tests to classify the path as open Internet, firewall or one of four NAT types, but every answer depended on a socket, server, destination, address realm and moment.
  • RFC 5389 kept STUN as a way to observe a mapped address, but rejected the type label as a traversal verdict. The missing evidence was a check from the intended peer, with relay available when the direct path failed.

In March 2003, RFC 3489 offered an attractive compression. A client behind an unknown middlebox could send a small sequence of requests to a cooperating server. From the returned address and the presence or absence of replies from changed server addresses, the client could name its situation: open Internet, symmetric UDP firewall, full-cone NAT, restricted-cone NAT, port-restricted-cone NAT or symmetric NAT.

The flow chart looked like diagnosis. Test I asked the server to reply normally and compared the client socket with MAPPED-ADDRESS. Test II requested a reply from a different IP address and port. Test III changed only the server port. A second Test I, sent to CHANGED-ADDRESS, checked whether the mapping stayed the same. The answers were real observations. The difficulty lay in promoting them into a stable property of the intervening device.

Each result belonged to a particular experiment. It used one local socket, one server and alternate address, one direction through perhaps several translators, one address realm and one instant. RFC 3489 itself warned that a later run should use a different local address and port, because state left by the first run could invalidate the next result. Waiting for old bindings to expire was only an alternative. The measurement altered the surface it was trying to describe.

The category also erased destination. A tuple observed by the STUN server might remain stable when the client contacted that server yet change when it contacted the intended peer. Filtering might admit a response from one source and reject another. Several NATs in series were collapsed into the apparent behavior of the most restrictive one. A label attached to “the NAT” concealed which box, destination or timer produced the answer.

The address-realm condition was equally important. A server not located in a common ancestor realm could report an address that another participant could not use. Two peers behind the same NAT could also fail when they tried to reach each other through an external mapping. MAPPED-ADDRESS meant “this server observed this source tuple.” It did not mean “every peer can reach me here.”

Lifetime discovery added another inference. By maintaining one binding and probing another after increasing waits, a client could estimate when state disappeared. Yet RFC 3489 admitted that bindings might have different timers, that overload could change them dynamically, and that a reboot could corrupt the result. A number learned once was not a lease issued by the NAT.

Security did not close the evidence gap. Shared secrets and message integrity could bind certain replies to a STUN exchange. They could not make a server-relative observation true for another destination. RFC 5389 later described an incorrect-mapped-address attack that was not fundamentally soluble by cryptography under some topologies. Authenticity of testimony and scope of testimony were separate problems.

RFC 5389's retrospective is unusually direct. Experience showed that classic STUN did not work well enough as a deployable traversal solution. Learned addresses sometimes worked and sometimes did not; classic STUN could neither determine which case applied nor repair failure. Many NATs did not fit neatly into the original types. The revision therefore removed the old response-address and change-request machinery from the base protocol and renamed STUN from a complete-sounding traversal technique to a set of session traversal utilities.

Later architecture preserved the useful receipt and discarded the overclaim. RFC 5780 measured mapping and filtering behavior separately, still with explicit limits. ICE in RFC 8445 gathered candidates, formed candidate pairs and ran connectivity checks between the actual parties before nominating a path. TURN, now specified by RFC 8656, offered a relay when direct connectivity could not be established. The operational question changed from “What kind of NAT is this?” to “Which candidate pair works now, for these participants, and what fallback remains?”

That change matches Heng Lu's distinction between a minimum shared mechanism and localized future decisions. STUN could remain a small observation tool while each usage defined servers, timing, authentication, checks and fallback. It also matches the reality-layer discipline: socket creation, request delivery, mapped-address observation, behavior sample, peer check, nomination, packet exchange and application success are different receipts.

The historical lesson is not that classification is useless. A label can summarize evidence. The mistake is letting the summary outrank the conditions that produced it. RFC 3489 named the middlebox; RFC 5389 returned attention to the path.

Sources