 |
Symmetric: We have already encountered the symmetric NAT, where the NAT mapping refers specifically to the
connection between the local host address and port number and the destination address and port number and a binding of
the local address and port to a publicside address and port. Any attempts to change any one of these fields
requires a different NAT binding. This is the most restrictive form of NAT behavior under UDP, and it has been observed
that this form of NAT behavior is becoming quite rare, because it prevents the operation of all forms of applications
that undertake referral and handover.
Figure 5: Symetric NAT

|
 |
Full-cone: A full-cone NAT is the least restrictive form of NAT behavior, where the binding of a local address
and port to a public-side address and port, when established, can be used by any remote host on any remote port address.
(Refer to Figure 6.)
Figure 6: Full Cone NAT

|
 |
Restricted-cone: A restricted-cone NAT is one where the NAT binding is accessible only by the destination host,
although in this case the destination host can send packets from any port address after the binding is created. (Refer to
Figure 7.)
Figure 7: Restricted-Cone NAT

|
 |
Port-restricted-cone: A port-restricted-cone NAT is one where the NAT binding is accessible by any remote host,
although in this case the remote host must use the same source port address as the original port address that triggered
the NAT binding. (Refer to Figure 8.)
Figure 8: Port-Restricted-Cone NAT

|
 |
Binding, or context-based packet translation: Detecting those packets that can be associated with a current
binding and using that binding in a manner according to the logical direction of the packet to perform packet header
transforms
|
 |
Filtering, or packet discard: Discarding those packets that cannot be associated with current bindings and
discarding them
|
 |
Endpoint independent: The NAT reuses the port binding for subsequent sessions initiated from the same internal
IP address and port to any external IP address and port. This is analogous to a full-cone NAT.
|
 |
Endpoint address dependent: The NAT reuses the port binding for subsequent sessions initiated from the same
internal IP address and port only for sessions to the same external IP address, regardless of the external port. This is
a looser form of symmetric NAT, where the binding is created on the basis of the external address, rather than the
external address and port.
|
 |
Endpoint address and port dependent: The NAT reuses the port binding for subsequent sessions initiated from the
same internal IP address and port only for sessions to the same external IP address and port. This is a more precise form
of UDP symmetry where the binding is available only to a single session, where a session is the 5-tuple of protocol,
source address, source port, destination address, and destination port.
|
 |
Port preservation: In addition to the differences in the binding between the two cases, the NAT may attempt to
preserve the local port number, if possible. The terminology proposed here is port preservation to describe this NAT
action.
|
 |
Port overloading: Some NATs attempt to undertake port preservation at all times, so that when a different local
host establishes a binding using a port that is already being preserved, the new binding will usurp the existing binding.
This behavior is proposed to be termed port overloading.
|
 |
Port multiplexing: The alternative to port overloading is use of the external entity to perform the
demultiplexing of the port. In this case if two local systems use the same source port to send packets to two different
external hosts, the NAT preserves the source port in the two bindings. If the NAT is using a single external address, the
external view is two packets with the same source address and source port, sent to two different external addresses. The
reverse packets have the same destination address and port, and the NAT determines the appropriate binding based on the
source address and port in the reserve packets. This requires an endpoint address and port-dependant binding behavior. If
two internal hosts are directing packets to the same external endpoint using the same source port addresses, then it is
necessary for one of the sessions to use a binding with an altered port number. This could be considered as
nondeterministic behavior.
|
 |
Bidirectional: The NAT does not keep the binding active indefinitely, and normally removes the binding if there
are no further packets that use the binding within a certain time period. However, there are variations in the
classification of packets that the NAT considers as packets that reset the timer. In the case of bidirectional binding
timer refresh, packets from either the local hosts or an external host that uses the NAT binding cause the NAT binding
expiration time to be reset.
|
 |
Outbound: An outbound binding timer refresh NAT resets the expiration timer only when packets pass from the
local host to the external host within the context of the binding. The implication is that a local host may have to use
some form of keepalive operation to maintain a NAT binding in the face of an inbound UDP unidirectional traffic flow.
Additionally, the expiration timer may be on a persession basis, or may be on a per-binding basis if multiple
sessions are associated to a single binding in the NAT.
|
 |
Inbound: As the name suggests, this is the opposite of the previous case, where only inbound packets cause the
expiration timer of the binding to be refreshed.
|
 |
Transport Protocol state: Although these forms are useful in the case of UDP-based sessions, when the binding is
based on a transport session (such as TCP), the NAT can base its binding timer refresh on the transport session state.
For TCP this would infer a binding refresh time that is refreshed by any session packet in either direction
(bidirectional), with the exception of packets with the TCP RST or
FIN flags set. Although it would be an option to drop the NAT binding state when such packets
are seen, this makes the NAT vulnerable to denial-of-service attacks by third-party injection of TCP
RST packets, so there is some merit in using the binding timer for TCP sessions.
|
 |
Endpoint independent: The NAT does not filter and discard packets that are addressed to the external part of the
binding, irrespective of the source values in the packet. This is analogous to a full-cone NAT.
|
 |
Endpoint address dependent: The NAT filters and discards packets that are addressed to the external part of the
binding, unless the source address of the packet matches the destination address used in the binding. This is analogous
to a restricted-cone NAT.
|
 |
Endpoint address and port dependent: The NAT filters and discards packets that are addressed to the external
part of the binding, unless the source address and port number of the packet matches the destination address used in the
binding. This is analogous to a port-restricted-cone NAT or a symmetric NAT.
|
 |
End hosts and local routers do not change. Whether there is a NAT in place between the local network and the Internet or
not, local devices can use the same software and support the same applications. NATs do not require customized versions
of operating systems or router images.
|
 |
As long as you accept the limitation that sessions must be initiated from the "inside," NATs can work in an
entirely transparent fashion for a set of client-server classes of applications.
|
 |
If you accept the perspective that services and usage scenarios that are not supported by NATs are "unwelcome" or
"unsafe," then NATs can be placed into a role as a component of a site's security architecture, providing protection from
attacks launched from the outside toward the inside network.
|
 |
NAT conserves its use of public address space.
|
 |
NAT allows previously disconnected privately addressed networks to connect to the global Internet without any form of
renumbering or host changesand renumbering networks can be a very time-consuming, disruptive, and expensive
operation, or, in other words, renumbering is difficult.
|
 |
NAT address space is an effective, provider-independent addressing solution with multihoming capabilities. NAT allows for
rapid switching to a different upstream provider, by renumbering the NAT address pool to the new provider's address
space. In essence, NATs provide the local network manager with the flexibility of using provider-independent space
without having to meet certain size and use requirements that would normally be required for an allocation of public,
provider-independent address space.
|
 |
NAT allows the network administrator to exercise some control over the form of network transactions that can occur
between local hosts and the public network.
|
 |
NATs require no local device or application changes. This is perhaps one of the major "features" of NATs, in that the
local network requires no changes in configuration to operate behind a NAT.
|
 |
NATs do not require a coordinated deployment. There is no transition, and no "flag day" across the Internet. Each local
network manager can make an independent decision whether or not to use a NAT. This allows for incremental deployment
without mutual dependencies.
|
 |
These days the common theme of the public address assignment policy stresses conservative use of address space with
minimum waste. The standard benchmark is to be able to show that a target of 80 percent of assigned address space is
assigned to a number of connected devices. Achieving such a very high usage rate is a challenging task in many network
scenarios, and NATs represent an alternative approach where the local network can be configured using private addresses
without reference to the use of public addresses.
|
 |
NATs are very widely available and bundled into a large variety of gateway and firewall units. In many units NATs are not
an optional extrathey are configured in as a basic item of product functionality.
|
 |
First, NATs cannot support applications where the initiator lies on the "outside." The external device has no idea of the
address of the local internal device, and, therefore, cannot direct any packets to that device in order to initiate a
session. This implies that peer-to-peer services, such as voice, cannot work unaltered in a NAT environment.
|
 |
The workaround to this form of shortcoming is to force an altered deployment architecture, where service platforms used
by external entities are placed "beside" the NAT, allowing command and control from the interior of the local network,
and having a permanent (non-NAT) interface to the external network. Obviously this implies some further centralization of
IT services within the NATed site.
|
 |
Even this approach does not work well for applications such as voiceover-IP, where the "server" now needs to operate as
some form of proxy agent. The generic approach here for applications to traverse NATs in the "wrong" direction is for the
inside device to forge a UDP connection to the outside agent, and for the inside device to then establish what NAT
translated address has been used, and the nature of the NAT in the path, and then republish this address as the local
entity's published service rendezvous point. Sounds fragile? Unfortunately, it is. The other approach is to shift the
application to use a set of endpoint identifiers that are distinct from IP addresses, and use a distributed set of
"agents" and "helpers" to dynamically translate the application level identifiers into transport IP addresses as
required. This tends to create added complexity in application deployment, and also embarks on a path of interdependency
that is less than desirable. In summary, workarounds to reestablish a peer-topeer networking model with NATs tend to be
limited, complex, and often fragile.
|
 |
The behavior of NATs varies dramatically from one implementation to another. Consequently, it is very difficult for
applications to predict or expose the precise behavior of one or more NATs that may exist on the application data path.
|
 |
Robust security in IP environments typically operates on an end-toend model, where both ends include additional
information in the packet that can detect attempts to alter the packet in various ways. In IPSec the header part of the
packet is protected by the Authentication Header, where an encrypted signature of certain packet header fields is
included in the IPSec packet. If the packet header is changed in transit in unexpected ways, the signature check will
fail. Obviously IPSec attempts to protect the packet address fieldsthe very same fields that NATs alter! This leads
to the observation that robust security measures and NATs do not mix very well. NATs inhibit implementation of security
at the IP level.
|
 |
NATs have no inherent failover. NATs are an active in-band mechanism that cannot fail into a safe operating fallback
mode. When a NAT goes offline, all traffic through the NAT stops. NATs create a single point where fates are shared in
the NAT device maintaining connection state and dynamic mapping information.
|
 |
NATs sit on the data path and attempt to process every packet. Obviously bandwidth scaling requires NAT scaling.
|
 |
NATs are not backed up by industry-standardized behavior. Although certain NAT-traversal applications make assumptions
about the way NATs behave, it is not the case that all NATs necessarily behave in precisely the same way. Applications
that work in one context may not necessarily operate in others.
|
 |
Multiple NATs can get very confusing with "inside" and "outside" concepts when NATs are configured in arbitrary ways.
NATs are best deployed in a strict deployment model of an "inside" being a stub private network and an "outside" of the
public Internet. Forms of multiple interconnects, potential loops, and other forms of network transit with intervening
NATs lead to very strange failure modes that are at best highly frustrating.
|
 |
With NATs there is no clear, coherent, and stable concept of network identity. From the outside these NAT-filtered
interior devices are visible only as transient entities.
|
 |
Policy-based mechanisms that are based on network identity (for example, Policy Quality of Service [QoS]) cannot
work through NATs.
|
 |
Normal forms of IP mobility are broken when any element behind the NAT attempts to roam beyond its local private domain.
Solutions are possible, generally involving specific NAT-related alterations to the behavior of the Home Agent and the
mobile device.
|
 |
Applications that work with identified devices, or that actually identify devices (such as the Simple Network
Management Protocol [SNMP] and DNS) require very careful configuration when operating an a NAT environment.
|
 |
NATs may drop IP packet fragments in either direction: without complete TCP/UDP headers, the NAT may not have sufficient
stored state to undertake the correct header translation.
|
 |
NATs often contain ALGs that attempt to be context-sensitive, depending on the source or destination port number. The
behavior of the ALGs can be difficult to anticipate, and these behaviors have not always been documented.
|
 |
Most NAT implementations with ALGs that attempt to translate TCP application protocols do not perform their functions
correctly when the substrings they must translate span across multiple TCP segments; some of them are also known to fail
on flows that use TCP option headers, for example timestamps.
|
 |
NATs must show endpoint-independent behavior for UDP-based bindings. This is to ensure that the NAT can support
application rendezvous without the need for various multiparty relays and agents.
|
 |
NAT should not use port preservation nor port overloading, and should operate in a deterministic manner. Port
preservation exposes the NATs to nonstandard behaviors when port preservation cannot be enforced. In addition, NATs must
have deterministic behavior.
|
 |
A dynamic NAT UDP binding timer should be 5 minutes, and should avoid expiration timers of 2 minutes or less. This is to
ensure that the timeout is long enough to avoid excessively frequent timer refresh packets.
|
 |
The NAT UDP timeout binding must use a timer refresh based on outbound traffic, and all sessions that use a particular
binding should use a common refresh timer. This requirement is a security consideration, in that letting inbound traffic
refresh the timer allows an external party to keep a port open on the NAT.
|
 |
The NAT filtering function should be address dependant. This represents a balance between security and utility.
|
 |
The timeout behavior of the NAT UDP filter must be the same as that of the NAT UDP binding timeout. This is intended to
reduce the complexity of applications that are reliant on long-held NAT state.
|
 |
The NAT should support hairpin connections, using the external address and port.
|
 |
If the NAT includes ALG support, the ALGs should be configurable in terms of being able to turn off the ALG function on a
per-application basis.
|
 |
NATs should support fragmentation and forwarding of packet fragments.
|
 |
NATs must support ICMP Destination Unreachable messages, and the ICMP timeout should be greater than 2 seconds.
|