Summary

  • RFC 3424 says there is no unique outside to a NAT: a reflected address is one service's observation of one mapping in one address realm at one time.
  • A temporary traversal mechanism needs a limited problem statement, an exit strategy, a brittleness account, requirements for the durable solution and evidence from deployed behavior. Successful reflection alone answers none of them.

The reflector answered correctly. It saw an address and port, sent them back, and the client put them into a signalling message. The incident ticket then made a larger claim: the client had discovered its public address.

That last sentence is where observation became architecture.

RFC 3424, published by the IAB in November 2002 as an Informational memo, examined what it called Unilateral Self-Address Fixing, or UNSAF. The label covered processes by which an endpoint tried to learn or repair the address by which it was seen in another realm, usually across a network address translator. The memo did not standardise a universal traversal protocol. It warned that a useful short-term heuristic could acquire permanent authority unless its designers defined how dependence would end.

Its central fact is easy to understate: there is no single “outside” of a NAT. A server in one realm can report the source tuple it observes. A different target, reached through a different translation boundary or policy path, may observe another tuple or none at all. The report is therefore relative to observer, route, time and state. Calling it the endpoint's address discards those qualifiers.

One witness cannot issue a universal address

The translation state lives in the translating device. The endpoint does not automatically know the mapping, its lifetime, the rule that created it or whether the same rule applies toward another destination. A reflection service has no privileged integration with that device. It reports what arrived.

That report is useful evidence. It can seed a candidate, support diagnosis or let a surrounding protocol test a possibility. It does not prove that the eventual target will see the same mapping, that return traffic is permitted, that the mapping will remain alive, that the transport will establish or that an application will accept the exchange.

Even authenticating the reflector would only authenticate who made the statement. It would not expand the statement's geographic or temporal scope. A signed claim that “I observed tuple X at time T” is still not “every target can reach X”. Identity, mapping and reachability remain different objects.

This distinction becomes sharper with multiple translators. The reflector and target can be separated from the client by different stateful boundaries. A mapping chosen for traffic toward the reflector may not be reused toward the target. The word “public” encourages an invariant that the mechanism never measured.

Keepalive converts a guess into an operating obligation

Mappings can expire, be reclaimed or change. A workaround may therefore send periodic traffic, repeat reflection or maintain state at both client and service. Each action makes the first observation last longer, but none turns it into a policy guarantee.

A live keepalive proves that a packet was sent and perhaps answered on that path. It does not prove that an incoming flow is authorised, that another destination shares the mapping, or that the device will preserve state after a route change. The mechanism assumes that past middlebox behaviour predicts future behaviour even though the reflection service cannot inspect the middlebox's algorithm.

Operationally, this is the moment a convenience gains a budget. The application now depends on the reflector's availability, name resolution, routing, capacity, abuse controls and state assumptions. A failure in the added service can prevent communication that the two original endpoints might otherwise have completed. Fate sharing has expanded.

The cost is not only uptime. Cross-layer state complicates diagnosis. An application symptom may arise from signalling, address reflection, translation lifetime, firewall policy, candidate choice, transport establishment or application authorization. If dashboards compress all of these into “connected” or “failed”, the workaround owns decisions without leaving receipts.

Traversal and policy are different control surfaces

Discovering a mapping is not permission to use it. Without explicit communication with a middlebox, a unilateral technique cannot know whether inbound communication is crossing under the device's intended policy supervision or merely exploiting observed behaviour.

That does not make traversal inherently hostile. It means the policy claim must remain bounded. A packet that traversed once demonstrates an event, not a durable authorization. An open binding is not the same as a firewall decision. A successful transport handshake is not an authenticated application transaction.

RFC 3424's concern was architectural: when applications route around a boundary whose policy they cannot query, the workaround can undermine the function the boundary was installed to perform. Conversely, when operators silently rely on brittle translation behaviour, they create a private dependency that applications cannot understand or challenge. Both sides lose a legible control plane.

Five questions before the exception becomes the system

RFC 3424 sets out five obligations for proposals of this kind.

First, define a precise and limited problem. “Make everything work through every NAT” is not a scope; it is an invitation for the heuristic to become permanent. A narrow use case exposes what the workaround does not promise.

Second, state an exit or transition plan. The preferred temporary mechanism should naturally see less use as the sound technology arrives. A calendar date is not enough. The plan needs a measurable retirement condition and an owner able to remove the dependency.

Third, account for brittleness: extra services, state, layer coupling, debugging cost and transition risk. The workaround's happy path is not its architecture. Its failure graph is.

Fourth, derive requirements for the longer-term solution and contribute to it. A temporary bridge is defensible when the traffic across it teaches designers how to eliminate it.

Fifth, examine actual deployed NAT behaviour and experience. A diagram cannot substitute for running evidence. At the same time, one successful implementation cannot establish universal behaviour.

Together these questions reverse a common commissioning habit. The team proposing the shortcut must explain not just how it starts, but how it loses authority.

Later tools narrowed the claim

The history of STUN shows the value of that narrowing. RFC 3489 presented the original STUN with broader traversal ambitions. RFC 5389 obsoleted it, renamed STUN as Session Traversal Utilities for NAT and made it a tool used by a defined surrounding mechanism rather than a complete traversal solution. RFC 8489 later revised the tool again without converting a server-reflexive address into universal identity.

ICE provides a stronger surrounding process. It gathers host, server-reflexive and relayed candidates, exchanges them and checks candidate pairs. The selected pair is evidence that a particular ICE session found working connectivity under its tests. It is not proof that the reflected candidate was globally valid, that every future session will follow the same path or that the application accepted useful work.

PCP approaches a different boundary by explicitly requesting control of a mapping. That is more legible than inferring a rule from observed side effects. Yet a granted mapping is still not a receipt from the remote application. Explicit middlebox control and end-to-end outcome remain separate.

These later mechanisms do not supply one universal exit from RFC 3424's problem. They demonstrate a more disciplined vocabulary: utility, candidate, check, selected pair, mapping request, granted lifetime. Each noun carries less authority than “the public address”, and that is a strength.

Twelve records, not one green light

A defensible evidence chain begins with the local interface and transport tuple. It identifies the reflector, route and address realm, then stores the reflected mapping with timestamp and assumed lifetime. If an explicit mapping or policy rule exists, that record belongs beside the observation rather than being inferred from it.

Next record the target and what the target actually observed. Preserve the candidate-pair check, transport establishment, authenticated application exchange and user-visible result as distinct events. A green application outcome must not retroactively authenticate every earlier assumption.

The chain also needs adverse time: retry, expiry, network change and changed-path behaviour. Finally, name the exception owner, its scope, its retirement trigger and the metric showing that use is declining. Without the last record, “temporary” is merely a description of the meeting in which the workaround was approved.

Evidence boundary

RFC 3424 is not a current census of NAT behaviour. It proves no claim about a named vendor, operator, application or incident. It does not establish that IPv6, STUN, TURN, ICE or PCP is a universal replacement. A reflected mapping is not authenticated endpoint identity; a connectivity check is not application authorization; a keepalive is not stable policy.

Heng Lu's doctrine supplies a disclosed editorial lens rather than deployment evidence. A minimum initial specification should preserve local future decisions and voluntary adoption. Running code should discipline claims with observed outcomes. Applied here, those principles favour a small utility whose limits remain visible over a workaround that silently declares itself infrastructure.

The narrow conclusion is enough. The reflector may have returned exactly what it saw. The governance failure begins when the system forgets who saw it, where, when, for which target and until what exit condition.

Sources