As per Relevance of the word addresses, we have this rfc below:
Network Working Group T.
Request for Comments: 2993
Category: Informational November 2000
Architectural Implications of
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
In light of the growing interest in, and deployment of
address translation (NAT) RFC-1631, this paper will discuss some
the architectural implications and guidelines for implementations.
is assumed the reader is familiar with the address
concepts presented in RFC-1631.
Table of
1. Introduction................................................... 2
2. Terminology.................................................... 4
3. Scope.......................................................... 6
4. End-to-End Model............................................... 7
5. Advantages of NATs............................................. 8
6. Problems with NATs............................................ 10
7. Illustrations................................................. 13
7.1 Single point of failure...................................... 13
7.2. ALG complexity............................................. 14
7.3. TCP state violations........................................ 15
7.4. Symmetric state management................................. 16
7.5. Need for a globally unique FQDN when advertising
services................................................... 18
7.6. L2TP tunnels increase frequency of address collisions...... 19
7.7. Centralized data collection system report correlation...... 20
8. IPv6.......................................................... 21
9. Security Considerations....................................... 22
10. Deployment Guidelines........................................ 23
11. Summary...................................................... 24
12. References................................................... 27
Hain Informational [Page 1]
RFC 2993 Architectural Implications of NAT November 2000
13. Acknowledgments.............................................. 28
14. Author's Address............................................. 28
15. Full Copyright Statement..................................... 29
1.
Published in May 1994, written by K. Egevang and P. Francis, RFC-1631
[2] defined NAT as one means to ease the growth rate of IPv4
use. But the authors were worried about the impact of
technology. Several places in the document they pointed out the
to experiment and see what applications may be adversely affected
NAT's header manipulations, even before there was any
operational experience. This is further evidenced in a quote
the conclusions: 'NAT has several negative characteristics that
it inappropriate as a long term solution, and may make
inappropriate even as a short term solution.'
Now, six years later and in spite of the prediction, the use of
is becoming widespread in the Internet. Some people are
NAT as both the short and long term solution to some of
Internet's address availability issues and questioning the need
continue the development of IPv6. The claim is sometimes made
NAT 'just works' with no serious effects except on a few
applications. At the same time others see a myriad of
caused by the increasing use of NAT
The arguments pro & con frequently take on religious tones, with
side passionate about its position
- Proponents bring enthusiasm and frequently cite the most
applications of Mail & Web services as shining examples of
transparency. They will also point out that NAT is the
that finally breaks the semantic overload of the IP address
both a locator and the global endpoint identifier (EID).
- An opposing view of NAT is that of a malicious technology, a
which is destined to choke out continued Internet development
While recognizing there are perceived address shortages,
opponents of NAT view it as operationally inadequate at best
bordering on a sham as an Internet access solution. Reality
somewhere in between these extreme viewpoints
In any case it is clear NAT affects the transparency of end-to-
connectivity for transports relying on consistency of the IP header
and for protocols which carry that address information in
other than the IP header. Using a patchwork of
configured application specific gateways (ALG's), endpoints can
around some of the operational challenges of NAT. These
challenges vary based on a number of factors including network
Hain Informational [Page 2]
RFC 2993 Architectural Implications of NAT November 2000
application topologies and the specific applications in use. It
be relatively easy to deal with the simplest case, with
between two endpoints running over an intervening network with
parallel redundant NAT devices. But things can quickly get
complicated when there are parallel redundant NAT devices, or
there are more distributed and multi-point applications like multi
party document sharing. The complexity of coordinating the
necessary to work around NAT grows geometrically with the number
endpoints. In a large environment, this may require concerted
to simultaneously update all endpoints of a given application
service
The architectural intent of NAT is to divide the Internet
independent address administrations, (also see "address realms",
RFC-2663 [3]) specifically facilitating casual use of private
assignments RFC-1918 [4]. As noted by Carpenter, et al RFC-2101 [5],
once private use addresses were deployed in the network,
were guaranteed to be ambiguous. For example, when simple NATs
inserted into the network, the process of resolving names to or
addresses becomes dependent on where the question was asked.
result of this division is to enforce a client/server
(vs. peer/peer) where the servers need to exist in the public
realm
A significant factor in the success of the Internet is
flexibility derived from a few basic tenets. Foremost is the End
to-End principle (discussed further below), which notes that
functions can only be performed in the endpoints, thus they are
control of the communication, and the network should be a
datagram service that moves bits between these points. Restated,
endpoint applications are often the only place capable of
managing the data stream. Removing this concern from the lower
packet-forwarding devices streamlines the forwarding process
contributing to system-wide efficiency
Another advantage is that the network does not maintain
connection state information. This allows fast rerouting
failures through alternate paths and to better scaling of the
network. Lack of state also removes any requirement for the
nodes to notify each other as endpoint connections are formed
dropped. Furthermore, the endpoints are not, and need not be,
of any network components other than the destination, first
router(s), and an optional name resolution service. Packet
is preserved through the network, and transport checksums and
address-dependent security functions are valid end-to-end
Hain Informational [Page 3]
RFC 2993 Architectural Implications of NAT November 2000
NAT devices (particularly the NAPT variety) undermine most of these
basic advantages of the end-to-end model, reducing
flexibility, while often increasing operational complexity
impeding diagnostic capabilities. NAT variants such as RSIP [6]
recently been proposed to address some of the end-to-end concerns
While these proposals may be effective at providing the private
with a public address (if ports are available), they do not
several issues like network state management, upper layer
like TCP_TIME_WAIT state, or well-known-port sharing. Their
multiplexing variants also have the same DNS limitations as NAPT,
each host requires significant stack modifications to enable
technology (see below).
It must be noted that firewalls also break the end-to-end model
raise several of the same issues that NAT devises do, while adding
few of their own. But one operational advantage with firewalls
that they are generally installed into networks with the
intent to interfere with traffic flow, so the issues are more
to be understood or at least looked at if mysterious problems arise
The same issues with NAT devices can sometimes be overlooked
NAT devices are frequently presented as transparent to applications
One thing that should be clearly stated up front is, that attempts
use a variant of NAT as a simple router replacement may
several significant issues that should be addressed
deployment. The goal of this document is to discuss these with
intent to raise awareness
2.
Recognizing that many of these terms are defined in detail in
2663 [3], the following are summaries as used in this document
NAT - Network Address Translation in simple form is a method by
IP addresses are mapped from one address administration to another
The NAT function is unaware of the applications traversing it, as
only looks at the IP headers
ALG - Application Layer Gateway: inserted between application
to simulate a direct connection when some intervening protocol
device prevents direct access. It terminates the transport protocol
and may modify the data stream before forwarding
NAT/ALG - combines ALG functions with simple NAT. Generally
useful than pure NAT, because it embeds components for
applications that would not work through a pure NAT
Hain Informational [Page 4]
RFC 2993 Architectural Implications of NAT November 2000
DNS/ALG - a special case of the NAT/ALG, where an ALG for the
service interacts with the NAT component to modify the contents of
DNS response
Firewall - access control point that may be a special case of an ALG
or packet filter
Proxy - A relay service designed into a protocol, rather
arbitrarily inserted. Unlike an ALG, the application on at least
end must be aware of the proxy
Static NAT - provides stable one-to-one mapping between
spaces
Dynamic NAT - provides dynamic mapping between address
normally used with a relatively large number of addresses on one
(private space) to a few addresses on the other (public space).
NAPT - Network Address Port Translation accomplishes translation
multiplexing transport level identifiers of multiple addresses
one side, simultaneously into the transport identifiers of a
address on the other. See 4.1.2 of RFC-2663. This permits
endpoints to share and appear as a single IP address
RSIP - Realm Specific IP allows endpoints to acquire and use
public address and port number at the source. It includes
for the private node to request multiple resources at once.
clients must be aware of the address administration boundaries,
specific administrative area its peer resides in for
application, and the topology for reaching the peer. To complete
connection, the private node client requests one or more
and/or ports from the appropriate RSIP server, then initiates
connection via that RSIP server using the acquired public resources
Hosts must be updated with specific RSIP software to support
tunneling functions
VPN - For purposes of this document, Virtual Private
technically treat an IP infrastructure as a multiplexing substrate
allowing the endpoints to build virtual transit pathways, over
they run another instance of IP. Frequently the 2nd instance of
uses a different set of IP addresses
AH - IP Authentication Header, RFC-2401 [7], which provides
integrity, data origin authentication, and an optional anti-
service
Hain Informational [Page 5]
RFC 2993 Architectural Implications of NAT November 2000
ESP - Encapsulating Security Payload protocol, RFC 2401, may
data confidentiality (encryption), and limited traffic
confidentiality. It also may provide data integrity, data
authentication, and an anti-replay service
Address administration - coordinator of an address pool assigned to
collection of routers and end systems
Addressing realm - a collection of routers and end
exchanging locally unique location knowledge. (Further defined
RFC-2663 NAT Terminology.) NAT is used a means to distribute
allocation authority and provide a mechanism to map addresses
one address administration into those of another administration
3.
In discussing the architectural impact of NATs on the Internet,
first task is defining the scope of the Internet. The most
definition is; a concatenation of networks built using IETF
technologies. This simple description does not distinguish
the public network known as the Internet, and the private
built using the same technologies (including those connected
NAT). Rekhter, et al in RFC-1918 defined hosts as public when
need network layer access outside the enterprise, using a
unambiguous address. Those that need limited or no access
defined as private. Another way to view this is in terms of
transparency of the connection between any given node and the rest
the Internet
The ultimate resolution of public or private is found in the
of the network in question. Generally, networks that do not
to be part of the greater Internet will use some screening
to insert a barrier. Historically barrier devices between the
and private networks were known as Firewalls or Application Gateways
and were managed to allow approved traffic while blocking
else. Increasingly, part of the screening technology is a NAT,
manages the network locator between the public and private-
address spaces, and then, using ALGs adds support for protocols
are incompatible with NAT. (Use of NAT within a private network
possible, and is only addressed here in the context that
component of the private network is used as a common transit
between the NAT attached stubs.)
RFC-1631 limited the scope of NAT discussions to stub appendages of
public Internet, that is, networks with a single connection to
rest of the Internet. The use of NAT in situations in which
network has multiple connections to the rest of the Internet
significantly more complex than when there is only a
Hain Informational [Page 6]
RFC 2993 Architectural Implications of NAT November 2000
connection since the NATs have to be coordinated to ensure that
have a consistent understanding of address mapping for
individual device
4. End-to-End
The concept of the End-to-End model is reviewed by Carpenter
Internet Transparency [8]. One of the key points is "state should
maintained only in the endpoints, in such a way that the state
only be destroyed when the endpoint itself breaks"; this is
"fate-sharing". The goal behind fate-sharing is to
robustness. As networks grow in size, likelihood of
failures affecting a connection becomes increasingly frequent.
failures lead to loss of communication, because key state is lost
then the network becomes increasingly brittle, and its
degrades. However, if an endpoint itself fails, then there is
hope of subsequent communication anyway. Therefore the End-to-
model argues that as much as possible, only the endpoints should
critical state
For NATs, this aspect of the End-to-End model translates into the
becoming a critical infrastructure element: if it fails,
communication through it fails, and, unless great care is taken
assure consistent, stable storage of its state, even when it
the communication that was passing through it will still
(because the NAT no longer translates it using the same mappings).
Note that this latter type of failure is more severe than the
of a router; when a router recovers, any communication that it
been forwarding previous can continue to be successfully
through it
There are other important facets to the End-to-End model
- when state is held in the interior of the network, then
dependent on that state cannot be routed around failures
somehow the state is replicated to the fail-over points, which
be very difficult to do in a consistent yet efficient and
fashion
- a key principle for scaling networks to large size is to
state-holding out to the edges of the network. If state is
by elements in the core of the network, then as the network
the amount of state the elements must holds likewise grows.
capacities of the elements can become severe chokepoints and
number of connections affected by a failure also grows
- if security state must be held inside the network (see
discussion below), then the possible trust models the network
support become restricted
Hain Informational [Page 7]
RFC 2993 Architectural Implications of NAT November 2000
A network for which endpoints need not trust network
providers has a great deal more security flexibility than one
does. (Picture, for example, a business traveler connecting
their hotel room back to their home office: should they have to
the hotel's networking staff with their security keys?, or the
of the ISP that supplies the hotel with its networking service?
about when the traveler connects over a wireless connection at
airport?)
Related to this, RFC-2101 notes
Since IP Security authentication headers assume that the
in the network header are preserved end-to-end, it is not
how one could support IP Security-based authentication between
pair of hosts communicating through either an ALG or a NAT
In addition, there are distributed applications that assume that
addresses are globally scoped, globally routable, and all hosts
applications have the same view of those addresses. Indeed,
standard technique for such applications to manage their
control and data connections is for one host to send to another
address and port that the second host should connect to. NATs
these applications. Similarly, there are other applications
assume that all upper layer ports from a given IP address map to
same endpoint, and port multiplexing technologies like NAPT and
break these. For example, a web server may desire to associate
connection to port 80 with one to port 443, but due to the
presence of a NATPT, the same IP address no longer ensures the
host
Limiting such applications is not a minor issue: much of the
of the Internet today is due to the ease with which new
can run on endpoints without first requiring upgrades
infrastructure elements. If new applications must have the
upgraded in order to achieve widespread deployment, then
deployment is hindered, and the pace of innovation slowed
5. Advantages of
A quick look at the popularity of NAT as a technology shows that
tackles several real world problems when used at the border of a
domain
- By masking the address changes that take place, from either dial
access or provider changes, minimizes impact on the local
by avoiding renumbering
- Globally routable addresses can be reused for intermittent
customers. This pushes the demand for addresses towards
number of active nodes rather than the total number of nodes
Hain Informational [Page 8]
RFC 2993 Architectural Implications of NAT November 2000
- There is a potential that ISP provided and managed NATs
lower support burden since there could be a consistent,
device with a known configuration at the customer end of an
interface
- Breaking the Internet into a collection of address
limits the need for continual justification of allocations
network managers to avoid the use of more advanced
techniques such as variable length subnets
- Changes in the hosts may not be necessary for applications
don't rely on the integrity of the packet header, or carry
addresses in the payload
- Like packet filtering Firewalls, NAPT, & RSIP block
connections to all ports until they are administratively mapped
Taken together these explain some of the strong motivations
moving quickly with NAT deployment. Traditional NAT [2] provides
relatively simple function that is easily understood
Removing hosts that are not currently active lowers address
on the public Internet. In cases where providers would otherwise
up with address allocations that could not be aggregated,
improves the load on the routing system as well as lengthens
lifetime of the IPv4 address space. While reclaiming idle
is a natural byproduct of the existing dynamic allocation, dial
access devices, in the dedicated connection case this service
be provided through a NAT. In the case of a NAPT, the
potential is even greater as multiple end systems share a
public address
By reducing the potential customer connection options and
the support matrix, it is possible that ISP provided NATs would
support costs
Part of the motivation for NAT is to avoid the high cost
renumbering inherent in the current IPv4 Internet. Guidelines
the assignment of IPv4 addresses RFC-2050 [9] mean that ISP
are currently required to renumber their networks if they want
switch to a new ISP. Using a NAT (or a firewall with NAT functions
means that only the Internet facing IP addresses must be changed
internal network nodes do not need to be reconfigured.
address administration to the NAT minimizes renumbering costs,
simultaneously provides for a much larger local pool of
than is available under current allocation guidelines. (The
guidelines are intended to prolong the lifetime of the IPv4
space and manage routing table growth, until IPv6 is ready or
routing technology reduces the pressure on the routing table.
is accomplished by managing allocations to match actual demand and
enforce hierarchical addressing. An unfortunate byproduct of
Hain Informational [Page 9]
RFC 2993 Architectural Implications of NAT November 2000
current guidelines is that they may end up hampering growth in
where it is difficult to sort out real need from potential hoarding.)
NAT is effective at masking provider switching or other
to change addresses, thus mitigates some of the growth issues
NAT deployments have been raising the awareness of protocol
who are interested in ensuring that their protocols work end-to-end
Breaking the semantic overload of the IP address will
applications to find a more appropriate mechanism for
identification and discourage carrying the locator in the
stream. Since this will not work for legacy applications, RFC-1631
discusses how to look into the packet and make NAT transparent to
application (i.e.: create an application gateway). This may not
possible for all applications (such as IP based authentication
SNMP), and even with application gateways in the path it may
necessary to modify each end host to be aware when there
intermediaries modifying the data
Another popular practice is hiding a collection of hosts that
a combined service behind a single IP address (i.e.: web host
sharing). In many implementations this is architecturally a NAT
since the addresses are mapped to the real destination on the fly
When packet header integrity is not an issue, this type of
host requires no modifications to the remote applications since
end client is unaware of the mapping activity. While the
host has the CPU performance characteristics of the total set
machines, the processing and I/O capabilities of the NAT/ALG
bound the overall performance as it funnels the packets back
forth
6. Problems with
- NATs break the flexible end-to-end model of the Internet
- NATs create a single point where fates are shared, in the
maintaining connection state and dynamic mapping information
- NATs complicate the use of multi-homing by a site in order
increase the reliability of their Internet connectivity. (
single routers are a point of fate sharing, the lack of state in
router makes creating redundancy trivial. Indeed, this is on
the reasons why the Internet protocol suite developed using
connectionless datagram service as its network layer.)
- NATs inhibit implementation of security at the IP level
- NATs enable casual use of private addresses. These
addresses are subject to collisions when companies using
addresses merge or want to directly interconnect using VPNs
- NATs facilitate concatenating existing private name spaces
the public DNS
Hain Informational [Page 10]
RFC 2993 Architectural Implications of NAT November 2000
- Port versions (NAPT and RSIP) increase operational complexity
publicly published services reside on the private side
- NATs complicated or may even invalidate the
mechanism of SNMPv3.
- Products may embed a NAT function without identifying it as such
By design, NATs impose limitations on flexibility. As such,
thought about the introduced complications is called for. This
especially true for products where the NAT function is a
service, such as load balancing routers that re-write the IP
to other public addresses. Since the addresses may be all
publicly administered space these are rarely recognized as NATs,
they break the integrity of the end-to-end model just the same
NATs place constraints on the deployment of applications that
IP addresses (or address derivatives) in the data stream, and
operate on the assumption that each session is independent. However
there are applications such as FTP and H.323 that use one or
control sessions to set the characteristics of the follow-on
in their control session payload. Other examples include SNMP
for configuration, and COPS policy messages. Applications
protocols like these assume end-to-end integrity of addresses
will fail when traversing a NAT. (TCP was specifically designed
take advantage of, and reuse, the IP address in combination with
ports for use as a transport address.) To fix how NATs break
applications, an Application Level Gateway needs to exist within
alongside each NAT. An additional gateway service is necessary
each application that may imbed an address in the data stream.
NAT may also need to assemble fragmented datagrams to
translation of the application stream, and then adjust TCP
numbers, prior to forwarding
As noted earlier, NATs break the basic tenet of the Internet that
endpoints are in control of the communication. The original
put state control in the endpoints so there would be no
inherent points of failure. Moving the state from the endpoints
specific nodes in the network reduces flexibility, while it
the impact of a single point failure. See further discussion
Illustration 1 below
In addition, NATs are not transparent to all applications,
managing simultaneous updates to a large array of ALGs may exceed
cost of acquiring additional globally routable addresses.
further discussion in Illustration 2 below
While RSIP addresses the transparency and ALG issues, for
specific case of an individual private host needing public access
there is still a node with state required to maintain the connection
Hain Informational [Page 11]
RFC 2993 Architectural Implications of NAT November 2000
Dynamic NAT and RSIP will eventually violate higher layer
about address/port number reuse as defined in RFC-793 [10] RFC-1323
[11]. The TCP state, TCP_TIME_WAIT, is specifically designed
prevent replay of packets between the 4-tuple of IP and port for
given IP address pair. Since the TCP state machine of a node
unaware of any previous use of RSIP, its attempt to connect to
same remote service that its neighbor just released (which is
in TCP_TIME_WAIT) may fail, or with a larger sequence number may
the prior connection directly from TCP_TIME_WAIT state, at the
of the protection afforded by the TCP_TIME_WAIT state (
discussion in 2.6 of RFC-2663 [3]).
For address translators (which do not translate ports) to comply
the TCP_TIME_WAIT requirements, they must refrain from assigning
same address to a different host until a period of 2*MSL has
since the last use of the address, where MSL is the Maximum
Lifetime defined in RFC-793 as two minutes. For address-and-
translators to comply with this requirement, they similarly
refrain from assigning the same host/port pair until 2*MSL
elapsed since the end of its first use. While these requirements
simple to state, they can place a great deal of pressure on the NAT
because they temporarily reduce the pool of available addresses
ports. Consequently, it will be tempting or NAT implementers
ignore or shorten the TCP_TIME_WAIT requirements, at the cost of
of TCP's strong reliability. Note that in the case where the
reliability is in fact compromised by the appearance of an
packet, the failure can manifest itself as the receiver
incorrect data. See further discussion in Illustration 3 below
It is sometimes argued that NATs simply function to
"routing realms", where each domain is responsible for
addresses within its boundaries. Such a viewpoint clouds
limitations created by NAT with the better-understood need
routing management. Compartmentalization of routing information
correctly a function of routing protocols and their scope
application. NAT is simply a means to distribute address
authority and provide a mechanism to map addresses from one
realm into those of another realm
In particular, it is sometimes erroneously believed that NATs
to provide routing isolation. In fact, if someone were to define
OSPF ALG it would actually be possible to route across a
boundary. Rather than NAT providing the boundary, it is
experienced operators who know how to limit network topology
serve to avoid leaking addresses across a NAT. This is
operational necessity given the potential for leaked addresses
introduce inconsistencies into the public infrastructure
Hain Informational [Page 12]
RFC 2993 Architectural Implications of NAT November 2000
One of the greatest concerns from the explosion of NATs is the
on the fledgling efforts at deploying network layer end-to-end
security. One fundamental issue for IPSec is that with both AH
ESP, the authentication check covers the TCP/UDP checksum (which
turn covers the IP address). When a NAT changes the IP address,
checksum calculation will fail, and therefore authentication
guaranteed to fail. Attempting to use the NAT as a security
fails when requirement is end-to-end network layer encryption,
only the endpoints have access to the keys. See further
in Illustration 4 below
Finally, while the port multiplexing variants of NAT (popular
they allow Internet access through a single address) work
well for connecting private hosts to public services, they
management problems for applications connecting from public
private. The concept of a well-known port is undermined because
one private side system can be mapped through the single public-
port number. This will affect home networks, when applications
multi-player Internet games can only be played on one system at
time. It will also affect small businesses when only one system at
time can be operated on the standard port to provide web services
These may sound like only medium-grade restrictions for the present
but as a basic property of the Internet, not to change years into
future, it is highly undesirable. The issue is that the
toward private usage requires administrative mapping for each
prior to connection. If the ISP chooses to provide a
version of these to lower configuration options, they may find
support costs of managing the ALGs will exceed the cost of
address space. See further discussion in Illustration 6 below
7.
7.1 Single point of
A characteristic of stateful devices like NATs is the creation of
single point of failure. Attempts to avoid this by
redundant NATs, creates a new set of problems related to
communication of the state, and routing related failures.
encompasses several issues such as update frequency,
impact of frequent updates, reliability of the state
transaction, a-priori knowledge of all nodes needing this
information, and notification to end nodes of alternatives. (
notification could be accomplished with a routing protocol,
might require modifications to the hosts so they will listen.)
Hain Informational [Page 13]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A |-----| Host B |
-------- | --------
-----------------
| |
------ ------
| AD 1 | | AD 2 |
------ ------
\ /
--------
/Internet
----------
--------
Illustration 1
In the traditional case where Access Device (AD) 1 & 2 are routers
the single point of failure is the end Host, and the only
needed to maintain the connections through a router or link
is a simple routing update from the surviving router. In the
where the ADs are a NAT variant there will be connection
maintained in the active path that would need to be shared
alternative NATs. When the Hosts have open connections
either NAT, and it fails, the application connections will
unless the state had been previously moved to the surviving NAT.
hosts will still need to acquire a routing redirect. In the case
RSIP, the public side address pool would also need to be
between the ADs to allow movement. This sharing creates
real-time operational complexity to prevent conflicting
at connection setup. NAT as a technology creates a point
sharing outside the endpoints, in direct contradiction to
original Internet design goals
7.2. ALG
In the following example of a proposed corporate network,
NAT/ALG was to be one or more devices at each physical location,
there were to be multiple physical locations per
connection. The logistics of simply updating software on this
is cumbersome, even when all the devices are the same
and model. While this would also be true with routers, it would
unnecessary for all devices to run a consistent version for
application to work across an arbitrary path
Hain Informational [Page 14]
RFC 2993 Architectural Implications of NAT November 2000
----------------------------------------
| Corporate Network |
| Asia |------| Americas |------| Europe |
------ ---------- --------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs
-------- -------- --------
| | |
--------------------------------------------
| Internet |
--------------------------------------------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs
-------- -------- --------
| | |
------------------ -------------- ----------------
Home Telecommuters Branch Offices Partner
------------------ -------------- ----------------
--------
Illustration 2
7.3. TCP state
The full range of upper layer architectural assumptions that
broken by NAT technologies may not be well understood without a
large-scale deployment, because it sometimes requires the
that comes with large-scale use to uncover unusual failure modes.
following example illustrates an instance of the problem
above in section 6.
Hain Informational [Page 15]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A |-----| Host B |
-------- | --------
--------
|NAT/RSIP
--------
|
--------
|Internet
--------
|
---------
| Web |
| Server |
---------
--------
Illustration 3
Host A completes its transaction and closes the web service on
port 80, and the RSIP releases the public side address used for
A. Host B attempts to open a connection to the same web service,
the NAT assigns then next free public side address which is the
one A just released. The source port selection rules on Host
happen to lead it to the same choice that A used. The
request from Host B is rejected because the web server, conforming
the TCP specifications, has that 4-tuple in TIME WAIT for 4 minutes
By the time a call from Host B gets through to the
complaining about no access, the requested retry will work, so
issue is marked as resolved, when it in fact is an on-going,
intermittent, problem
7.4. Symmetric state
Operational management of networks incorporating stateful
modifying device is considerably easier if inbound and
packets traverse the same path. (Otherwise it's a headache to
state for the two directions synchronized.) While easy to say,
with careful planning it can be difficult to manage using
connectionless protocol like IP. The problem of creating
connections is ensuring that routes advertised to the private
reach the end nodes and map to the same device as the public
route advertisements. This state needs to persist throughout
lifetime of sessions traversing the NAT, in spite of frequent
simultaneous internal and external topology churn. Consider
following case where the -X- links are broken, or flapping
Hain Informational [Page 16]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A | | Host B |
| Foo | | Bar |
-------- --------
| |
---- ----
|Rtr1|---X1---|Rtr2|
---- ----
| |
---- ----
|NAT1| |NAT2|
---- ----
| |
--------------
|Rtr Rtr
| / Internet \ | ---
|Rtr----X2---Rtr|----|DNS
-------------- ---
| |
| |
-------- --------
| Host C | | Host D |
-------- --------
--------
Illustration 4
To preserve a consistent view of routing, the best path to
Internet for Routers 1 & 2 is via NAT1, while the Internet is
the path to the address pool managed by the NATs is best
through NAT1. When the path X1 breaks, Router 2 would attempt
switch to NAT2, but the external return path would still be
NAT1. This is because the NAT1 device is advertising availability
a pool of addresses. Directly connected routers in this
situation would advertise the specific routes that existed after
loss. In this case, redundancy was useless
Consider the case that the path between Router 1 & 2 is up, and
remote link in the network X2 is down. It is also assumed that
returns addresses for both NATs when queried for Hosts A or B.
Host D tries to contact Host B, the request goes through NAT2,
due to the internal routing, the reply is through NAT1. Since
state information for this connection is in NAT2, NAT1 will provide
new mapping. Even if the remote path is restored, the
will not be made because the requests are to the public IP of NAT2,
while the replies are from the public IP of NAT1.
Hain Informational [Page 17]
RFC 2993 Architectural Implications of NAT November 2000
In a third case, both Host A & B want to contact Host D, when
remote link X2 in the Internet breaks. As long as the path X1
down, Host B is able to connect, but Host A is cut off. Without
thorough understanding of the remote topology (unlikely
Internet providers tend to consider that sensitive
information), the administrator of Hosts A & B would have no clue
one worked and the other didn't. As far as he can tell the
paths through the NATs are up but only one connection works. Again
this is due to lack of visibility to the topology that is
when a stateful device is advertising availability to a pool
than the actual connected networks
In any network topology, individual router or link failures
present problems with insufficient redundancy, but the
maintenance requirements of NAT present an additional burden that
not as easily understood or resolved
7.5. Need for a globally unique FQDN when advertising public
The primary feature of NATs is the 'simple' ability to
private networks to the public Internet. When the private
exists prior to installing the NAT, it is unlikely and
that its name resolver would use a registered domain. As noted
RFC 1123 [12] DNS queries may be resolved via local multicast
Connecting the NAT device, and reconfiguring it's resolver to
for all external requests allows access to the public network
hosts on the private network. Configuring the public DNS for the
of private hosts that need inbound connections would require
registered domain (either private, or from the connecting ISP) and
unique name. At this point the partitioned name space
concatenated and hosts would have different names based on inside vs
outside queries
Hain Informational [Page 18]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A | | Host B |
| Foo |-----| Bar |
-------- | -------- ---
|-------------|DNS
--- ---
|NAT
---
|
-------- ---
|Internet|----|DNS
-------- ---
|
---
|NAT
--- ---
|-------------|DNS
-------- | -------- ---
| Host C |-----| Host D |
| Foo | | Bar |
-------- --------
--------
Illustration 5
Everything in this simple example will work until an
embeds a name. For example, a Web service running on Host D
present embedded URL's of the form http://D/bar.html, which
work from Host C, but would thoroughly confuse Host A. If
embedded name resolved to the public address, Host A would be happy
but Host C would be looking for some remote machine. Using
public FQDN resolution to establishing a connection from Host C to D
the NAT would have to look at the destination rather than
forwarding the packet out to the router. (Normal operating mode
a NAT is translate & forward out the other interface, while
do not send packets back on the same interface they came from.)
NAT did not create the name space fragmentation, but it
attempts to merge networks with independent name administrations
7.6. L2TP tunnels increase frequency of address
The recent mass growth of the Internet has been driven by support
low cost publication via the web. The next big push appears to
support of Virtual Private Networks (VPNs) frequently
using L2TP. Technically VPN tunnels treat an IP infrastructure as
multiplexing substrate allowing the endpoints to build what appear
be clear pathways from end-to-end. These tunnels redefine
visibility and increase the likelihood of address collision
Hain Informational [Page 19]
RFC 2993 Architectural Implications of NAT November 2000
traversing multiple NATs. Address management in the private
behind NATs will become a significant burden, as there is no
body capable of, or willing to do it. The lower burden for the
is actually a transfer of burden to the local level,
administration of addresses and names becomes both distributed
more complicated
As noted in RFC-1918, the merging of private address spaces can
an overlap in address use, creating a problem. L2TP tunnels
increase the likelihood and frequency of that merging through
simplicity of their establishment. There are several
of address overlap which will cause failure, but in the
example shown below the private use address of Host B matches
private use address of the VPN pool used by Host A for
connections. When Host B tries to establish the VPN interface,
A will assign it an address from its pool for inbound connections
and identify the gateway for Host B to use. In the example, Host
will not be able to distinguish the remote VPN gateway address
Host A from its own private address on the physical interface,
the connection will fail. Since private use addresses are
definition not publicly coordinated, as the complexity of the
mesh increases so does the likelihood that there will be a
that cannot be resolved
--------------- ----------------
| 10.10.10.10 |--------L2TP-------| Assigned by A |
| Host A | --- --- | Host B |
| 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 |
--------------- --- --- ----------------
--------
Illustration 6
7.7. Centralized data collection system report
It has been reported that NAT introduces additional challenges
intrusion detection systems attempt to correlate reports
sensors inside and outside the NAT. While the details of
systems are beyond the scope of this document, it is clear that
centralized system with monitoring agents on both sides of the
would also need access to the current NAT mappings to get this right
It would also be critical that the resulting data be indexed
if there were agents behind multiple NATs using the same
range for the private side
This also applies to management data collected via SNMP. Any
the data stream carries an IP address; the central collector or
will need to manipulate the data based on the current mappings in
Hain Informational [Page 20]
RFC 2993 Architectural Implications of NAT November 2000
NAT
8. IPv
It has been argued that IPv6 is no longer necessary because
relieve the address space constraints and allow the Internet
continue growing. The reality is they point out the need for IPv
more clearly than ever. People are trying to connect
machines through a single access line to their ISP and have
willing to give up some functionality to get that at minimum cost
Frequently the reason for cost increases is the perceived
(therefore increased value) of IPv4 addresses, which would
eliminated through deployment of IPv6. This crisis mentality
creating a market for a solution to a problem already solved
greater flexibility by IPv6.
If NAT had never been defined, the motivation to resolve
dwindling IPv4 address space would be a much greater. Given
NATs are enabling untold new hosts to attach to the Internet daily
it is difficult to ascertain the actual impact to the lifetime
IPv4, but NAT has certainly extended it. It is also difficult
determine the extent of delay NAT is causing for IPv6, both
relieving the pressure, and by redirecting the intellectual
away from the longer-term solution
But at the same time NAT functionality may be a critical
in the deployment of IPv6. There are already 100 million or
computers running IPv4 on data networks. Some of these networks
connected to and thus part of the Internet and some are on
isolated networks. It is inconceivable that we could have a "
day" and convert all of the existing IPv4 nodes to IPv6 at the
time. There will be a very long period of coexistence while
IPv4 and IPv6 are being used in the Internet and in private networks
The original IPv6 transition plan relied heavily on having new IPv
nodes also be able to run IPv4 - a "dual stack" approach. When
dual stack node looks up another node in the DNS it will get back
IPv4 or an IPv6 address in response. If the response is an IPv
address then the node uses IPv4 to contact the other node. And if
response is an IPv6 address then IPv6 can be used to make
contact. Turning the NAT into a 6to4 [13]router enables
deployment of IPv6 while providing an IPv4 path if IPv6
unavailable. While this maintains the current set of issues for IPv
connections, it reestablishes the end-to-end principle for IPv
connections
Hain Informational [Page 21]
RFC 2993 Architectural Implications of NAT November 2000
An alternative methodology would be to translate the packets
IPv6 and IPv4 at the boarders between IPv4 supporting networks
IPv6 supporting networks. The need for this functionality
recognized in [RFC 1752], the document that recommended to the
that IPv6 be developed and recommended that a set of working
be established to work on a number of specific problems.
translation (i.e, NAT) was one of those problems
Of course, NATs in an IPv6 to IPv4 translation environment
all of the same problems that NATs encounter in a pure IPv4 and
environment and cautions in this document apply to both situations
9. Security
NAT (particularly NAPT) actually has the potential to lower
security because it creates the illusion of a security barrier,
does so without the managed intent of a firewall.
security mechanisms are implemented in the end host, without
on assumptions about routing hacks, firewall filters, or missing
translations, which may change over time to enable a service to
neighboring host. In general, defined security barriers assume
any threats are external, leading to practices that make
breaches much easier
IPsec RFC-2401 [7] defines a set of mechanisms to support packet
level authentication and encryption for use in IP networks.
this may be less efficient than application-level security but in
words of RFC-1752 [14] "support for basic packet-level
will provide for the adoption of a much needed, widespread,
infrastructure throughout the Internet."
NATs break IPsec's authentication and encryption technologies
these technologies depend on an end-to-end consistency of the
addresses in the IP headers, and therefore may stall
deployment of enhanced security across the Internet. NATs raise
number of specific issues with IPsec. For example
- Use of AH is not possible via NAT as the hash protects the
address in the header
- Authenticated certificates may contain the IP address as part
the subject name for authentication purposes
- Encrypted Quick Mode structures may contain IP addresses and
for policy verifications
- The Revised Mode of public key encryption includes the
identity in the encrypted payload
Hain Informational [Page 22]
RFC 2993 Architectural Implications of NAT November 2000
It may be possible to engineer and work around NATs for IPsec on
case-by-case basis, but at the cost of restricting the trust model
as discussed in section 4 above. With all of the restrictions
on deployment flexibility, NATs present a significant obstacle
security integration being deployed in the Internet today
As noted in the RFC-2694 [15], the DNS/ALG cannot support secure
name servers in the private domain. Zone transfers between
servers will be rejected when necessary modifications are attempted
It is also the case that DNS/ALG will break any modified,
responses. This would be the case for all public side queries
private nodes, when the DNS server is on the private side. It
also be true for any private side queries for private nodes, when
DNS server is on the public side. Digitally signed records could
modified by the DNS/ALG if it had access to the source
key. DNSsec has been specifically designed to avoid distribution
this key, to maintain source authenticity. So NATs that use DNS/
to repair the namespace resolutions will either; break the
when modifying the record, or will require access to all source
to requested resolutions
Security mechanisms that do not protect or rely on IP addresses
identifiers, such as TLS [16], SSL [17], or SSH [18] may operate
environments containing NATs. For applications that can
and make use of this type of transport connection, NATs do not
any additional complications. These technologies may not
sufficient protection for all applications as the header is exposed
allowing subversive acts like TCP resets. RFC-2385 [19]
the issues in more detail
Arguments that NATs may operate in a secure mode preclude true End
to-End security, as the NAT becomes the security endpoint
Operationally the NAT must be managed as part of the security domain
and in this mode the packets on the unsecured side of the NAT
fully exposed
10. Deployment
Given that NAT devices are being deployed at a fairly rapid pace
some guidelines are in order. Most of these cautionary in nature
are designed to make sure that the reader fully understands
implications of the use of NATs in their environment
- Determine the mechanism for name resolution, and ensure
appropriate answer is given for each address administration
Embedding the DNS server, or a DNS ALG in the NAT device
likely be more manageable than trying to synchronize
DNS systems across administrations
Hain Informational [Page 23]
RFC 2993 Architectural Implications of NAT November 2000
- Is the NAT configured for static one to one mappings, or will
dynamically manage them? If dynamic, make sure the TTL of the
responses is set to 0, and that the clients pay attention to
don't cache notification
- Will there be a single NAT device, or parallel with multiple paths
If single, consider the impact of a device failure. If multiple
consider how routing on both sides will insure the packets
through the same box over the connection lifetime of
applications
- Examine the applications that will need to traverse the NAT
verify their immunity to address changes. If necessary provide
appropriate ALG or establish a VPN to isolate the application
the NAT
- Determine need for public toward private connections,
of destinations on the private side, and potential for
use of public side port numbers. NAPTs increase administration
these apply
- Determine if the applications traversing the NAPT or RSIP
all ports from the public IP address to be the same endpoint
Administrative controls to prevent simultaneous access
multiple private hosts will be required if this is the case
- If there are encrypted payloads, the contents cannot be
unless the NAT is a security endpoint, acting as a gateway
security realms. This precludes end-to-end confidentiality, as
path between the NAT and endpoint is exposed
- Determine the path for name resolutions. If hosts on the
side of a NAPT or RSIP server need visibility to each other,
private side DNS server may be required
- If the environment uses secure DNS records, the DNS/ALG
require access to the source authentication keys for all records
be translated
- When using VPNs over NATs, identify a clearinghouse for the
side addresses to avoid collisions
- Assure that applications used both internally and externally
embedding names, or use globally unique ones
- When using RSIP, recognize the scope is limited to
private network connecting to the public Internet. If other
are in the path (including web-server load-balancing devices),
advantage of RSIP (end-to-end address/port pair use) is lost
- For RSIP, determine the probability of TCP_Time_Wait
when subsequent private side hosts attempt to contact a
disconnected public side service
Hain Informational [Page 24]
RFC 2993 Architectural Implications of NAT November 2000
11.
Over the 6-year period since RFC-1631, the experience base has grown
further exposing concerns raised by the original authors. NAT
a fundamental assumption of the Internet design; the endpoints are
control. Another design principle, 'keep-it-simple' is
overlooked as more features are added to the network to work
the complications created by NATs. In the end, overall
and manageability are lowered, and support costs go up to deal
the problems introduced
Evangelists, for and against the technology, present their cases
righteous while downplaying any rebuttals
- NATs are a 'fact of life', and will proliferate as an
that sustains the existing IPv4 infrastructure
- NATs are a 'necessary evil' and create an administrative
that is not easily resolved. More significantly, they inhibit
roll out of IPsec, which will in turn slow growth of
that require a secure infrastructure
In either case, NATs require strong applicability statements,
declaring what works and what does not
An overview of the pluses and minuses
NAT advantages NAT
-------------------------------- --------------------------------
Masks global address changes Breaks end-to-end
Eases renumbering when providers Facilitates concatenation
change multiple name
Breaks
Stateful points of
Address administrations avoid Requires source specific DNS
justifications to registries or DNS/
DNS/ALG breaks DNSsec
Lowers address utilization Enables end-to-end
Lowers ISP support burden Increases local support burden
Transparent to end systems in some Unique development for each
Load sharing as virtual host Performance limitations with
Delays need for IPv4 replacement May complicate integration of IPv
Hain Informational [Page 25]
RFC 2993 Architectural Implications of NAT November 2000
There have been many discussions lately about the value of
with IPv6 development when the market place is widely deploying IPv
NATs. A shortsighted view would miss the point that both have
role, because NATs address some real-world issues today, while IPv
is targeted at solving fundamental problems, as well as
forward. It should be recognized that there will be a long co
existence as applications and services develop for IPv6, while
lifetime of the existing IPv4 systems will likely be measured
decades. NATs are a diversion from forward motion, but they
enable wider participation at the present state. They also break
class of applications, which creates the need for complex work-
scenarios
Efforts to enhance general security in the Internet include IPsec
DNSsec. These technologies provide a variety of services to
authenticate and protect information during transit. By
these technologies, NAT and the DNS/ALG work-around,
deployment of enhanced security throughout the Internet
There have also been many questions about the probability of
being established that might raise some of the listed concerns.
it is hard to predict the future, one way to avoid ALGs for
application is to establish a L2TP over the NATs. This restricts
NAT visibility to the headers of the tunnel packets, and removes
effects from all applications. While this solves the ALG issues,
raises the likelihood that there will be address collisions
arbitrary connections are established between uncoordinated
spaces. It also creates a side concern about how an
establishes the necessary tunnel
The original IP architecture is powerful because it provides
general mechanism on which other things (yet unimagined) may
built. While it is possible to build a house of cards, time
experience have lead to building standards with more
integrity. IPv6 is the long-term solution that retains end-to-
transparency as a principle. NAT is a technological diversion
sustain the lifetime of IPv4.
Hain Informational [Page 26]
RFC 2993 Architectural Implications of NAT November 2000
12.
1 Bradner, S., " The Internet Standards Process -- Revision 3",
9, RFC 2026, October 1996.
2 Egevang, K. and P. Francis, "The IP Network Address Translator",
RFC 1631, May 1994.
3 Srisuresh, P. and M. Holdrege, "NAT Terminology
Considerations", RFC 2663, August 1999.
4 Rekhter, Y., Moskowitz, B., Karrenberg