community – Why is symmetric NAT known as “symmetric”?

tl;dr It comes from STUN and is symmetric as a result of it identifies a 1:1 relationship between NAT mapping and L4 move.

The title symmetric NAT is so far as I do know launched by the unique STUN RFC 3489, with the next definition:

A symmetric NAT is one the place all requests from the identical inside IP
deal with and port, to a particular vacation spot IP deal with and port, are
mapped to the identical exterior IP deal with and port. If the identical host
sends a packet with the identical supply deal with and port, however to a
completely different vacation spot, a unique mapping is used. Moreover, solely
the exterior host that receives a packet can ship a UDP packet again to
the interior host.

This may occasionally not make clear issues in case you are not that conversant in NAT and the entire idea of STUN. Let me attempt to construct this up.

The primary necessary idea is the 5-tuple (protocol, host port, server port, host deal with, server deal with) the place protocol is mostly both UDP or TCP. This 5-tuple is used to determine a L4 protocol move. I take advantage of host and server terminology to simplify some issues and keep away from directional phrases akin to supply and vacation spot.

Now, the entire idea of a NA(P)T system is to dynamically change the (host port, host deal with) on the interior community (inside) with a (NAT port, NAT deal with) on the exterior community (exterior). The state of such a translation can be known as a NAT mapping. At its simplest the NAT perform doesn’t care about protocol, server ip, and server port. On this case a number of Layer 4 protocol flows could use the identical NAT mapping, so long as the host ip and host-port used on the within are the identical. This N:1 mannequin of multiplexing/demultiplexing flows to mappings is commonly represented by way of a funnel or cone.

The most important various is to create a mapping for every new 5-tuple. So even when for instance all of protocol, host ip, host port, and server ip are the identical however server port is completely different, a brand new mapping can be created and the ensuing NAT ip, NAT port can be completely different. There’s thus a full 1:1 symmetry between a layer 4 move and a NAT mapping.

Not related to the query, however just a few historical past why this time period is definitely necessary for the STUN RFC and never left as an implementation element. One of many objectives of stun was to allow P2P connections between two purchasers behind NAT. The concept was that for a lot of purposes (e.g. VoIP) there would solely be preliminary communication by way of servers, however all remaining communication could be P2P. To arrange this P2P, the purchasers would make a connections to a stun server, which does three issues:

1. It informs them on the kind of NAT, as this solely labored with the ‘full cone’ model. So detecting cone vs symmetric is necessary right here (stun has a couple of variants of cone really)
2. It creates a NAT mapping as defined above.
3. The stun sever informs the consumer of the surface port+IP of that mapping.

Then, the consumer would ship the realized port+IP by way of the applying (voip) server to the opposite consumer, and now that can be utilized to arrange a P2P connection.

In apply this barely works, and stun as described there was obsoleted and changed by RFC 5389. As well as, many NAT implementations have added Utility-level Gateways to resolve sure protocols immediately. On high of that there are particular protocols to create NAT mappings on demand, most prominently UPnP IGD and PCP. However, as typically occurs, a few of the unique STUN ideas caught endlessly anyway :).