Network Working Group Yakov Rekhter
Internet Draft cisco Systems
Expiration Date: February 1999
Implications of NATs on the TCP/IP architecture
draft-ietf-nat-arch-implications-00.txt
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
2. Abstract
In light of the growing interest in, and deployment of network
address translation (NAT - RFC 1631), this document will present some
highlights of the architectural implications. A reader is assumed to
be well familiar with the principles of NAT operations [RFC1631].
Yakov Rekhter [Page 1]
Internet Draft draft-ietf-nat-arch-implications-00.txt August 1998
3. Implications on routing and addressing
Use of NATs allows to build a TCP/IP network as a collection of
routing realms, rather than require the network to be a single
routing realm. Routing realms are interconnected via NATs, where a
NAT is assumed to be connected to two or more routing realms.
Regardless of whether a network is constructed as a single routing
realm, or as an interconnection of multiple routing realms, an IP
address carried in a packet acts as a "locator". The distinction
between the former (single routing realm) and the latter (multiple
routing realms) is that in the former case the same address acts as a
locator across the whole network (network-wide locator), while in the
latter case the same address acts as a locator only within a part of
the network (within a single routing realm). Moreover in the former
case to act as a locator, an address in the IP header has to be
modified at the boundaries between routing realms. This, in turn,
implies that addresses in the IP header may not be preserved end-to-
end (in fact, they are guaranteed not to be preserved end-to-end for
any communication than spans multiple routing realms).
With NATs temporal uniqueness of IP addresses is no longer assured.
It may be quite short, possibly comparable to a transport connection
time. In such cases an IP address is no longer a suitable long-term
end point identifier. This has some impact on end-to-end security
(see below). Note that DHCP, PPP, and renumbering are some of the
other factors that make IP addresses unsuitable as long-term end-
point identifiers.
Constructing a network out of multiple routing realms allows to build
a network whose size is no longer bounded by the scaling limitations
of the IP routing system. Using multiple routing realms, instead of
a single one allows to reduce the load on the network layer routing
system, as the routing system has to handle routing only within
individual routing realms. As a result, the amount of routing
information that the routing system has to handle is bounded by the
size of the individual routing realms that form a network, rather
than by the size of the whole network.
Use of multiple routing realms, instead of a single one, may permit
relaxation of some of the constraints on IP address assignment within
a network. Specifically, since the routing system operates within the
confines of a single routing realm, any constraints on address
assignment imposed by the routing system are confined to a single
routing realm as well.
Yakov Rekhter [Page 2]
Internet Draft draft-ietf-nat-arch-implications-00.txt August 1998
For example, addresses are required to be unique only within a single
routing realm, but not across multiple routing realms. This
simplifies IP address administration and management, as each routing
realm could administer and manage its address space independent of
all other routing realms, thus reducing the amount of required
coordination among organizations involved in address administration
and management, and ultimately reducing the cost associated with
address administration and management.
Likewise, hierarchical address assignment required to support
hierarchical routing is required only within individual routing
realms (only within parts of the network), but not across multiple
routing realms (not across the whole network). This reduces the need
for renumbering when network topology changes (e.g., an enterprise
changes its Internet Service Provider), which in turn lowers the
overall cost of operations by reducing the cost of renumbering.
Complexity of interconnecting routing realms with NATs depends (among
other factors) on the network topology at the level of routing
realms. Current practice could be closely (although not precisely)
approximated by a two level hierarchy, with the Internet being at the
top level of the hierarchy. Further work is needed to understand how
routing realms could be interconnected (via NATs) in an arbitrary
(mesh) topology.
Since NATs maintain state associated with inter-realm connectivity,
failure of a NAT may cause disruption of inter-realm connections
handled by the NAT. Techniques such as "hot stand-by" NAT could be
used to avoid the disruption. Such techniques require syncronization
of state between the "primary" and the "hot stand-by".
4. Implications on DNS
A network formed by multiple routing realms relies on DNS for
providing connectivity among these realms. This places certain
requirements on DNS.
For a network formed by a set of interconnected routing realms, fully
qualified domain names are required to be unique across the whole set
(across the whole network), even if IP addresses are no longer unique
across the set. Note that this requirement has to be satisfied
regardless of whether the network is formed by a single or multiple
routing realms.
A routing realm may contain one or more zones.
Yakov Rekhter [Page 3]
Internet Draft draft-ietf-nat-arch-implications-00.txt August 1998
In general one should try to avoid (or at least minimize) spreading a
single DNS zone across multiple routing realms. This is because
spreading a DNS zone across multiple routing realms increases the
amount of manual configuration on NATs interconnecting these realms.
Further work is required to identify implications on DNS in the
presence of DNS Security and DNS Dynamic Updates.
5. Implications on transport layer
Since communication across multiple routing realms requires addresses
in the IP header to be modified at the boundaries between the realms,
transport header checksum has to be adjusted at the boundaries
between the realms. Procedures for doing this are described in
[RFC1631].
6. Implications on applications
If hosts in different routing realms communicate among themselves via
an application that carries IP addresses in the application data
stream (e.g., FTP), the NATs that interconnect the realms have to be
augmented with the Application Layer Gateway (ALG) functionality for
that application. This is because IP addresses are guaranteed to be
unambiguous only within a single routing realm. Thus when they are
carried in the application data stream the data stream has to be
modified as it crosses routing realm's boundaries by the NATs placed
at the boundaries. Modifying this application data stream requires to
understand the semantics of the stream, which in turn requires the
ALG functionality specific to the application.
Unconstrained proliferation of applications that carry IP addresses
in the application data stream clearly complicates support of such
applications across multiple routing realms. Whether this is a
problem of practical significance, or how wide is going to be the
proliferation of such applications is a matter of opinion.
Applications that do not carry IP addresses in the application data
stream place no additional requirements, other than what is required
by NAT (address translation and transport header checksum
adjustment).
The discussion on whether applications should carry IP addresses in
the application data stream is outside the scope of this document,
but may well be within the scope of the overall TCP/IP architecture.
Yakov Rekhter [Page 4]
Internet Draft draft-ietf-nat-arch-implications-00.txt August 1998
7. Implications on security
As long as a security mechanism doesn't depend on addresses in the IP
header being preserved end-to-end, using such mechanism for
communications that span multiple routing realms places no additional
requirements on either the mechanism or NATs. For example, use of SSH
for communications that span multiple routing realms poses no
problem, as proven by operational experience.
On the other hand, the use of IPSec, or any other protocol which uses
IP addresses as part of a security association, for communications
that span multiple routing realms is problematic. Use of IPSec is
likely to require boundaries between different IP Security domains to
be aligned with routing realms boundaries. More work is needed to
identify specific scenarios where IPSec could work, as well as the
scenarios where IPSec is not going to work.
While NATs clearly limit the scope where IPSec could be applicable
(or vice versa, IPSec could limit the scope where NATs could be
applicable), one need to remember that IPSec is just one mechanism
for providing security, but not the only one possible. Moreover,
there are scenarios where IPSec could be used in conjunction with
NATs.
The discussion on whether IPSec should depend on preserving addresses
in the IP header end-to-end is outside the scope of this document,
but may as well be within the scope of the overall TCP/IP
architecture.
For applications that carry IP addresses in the application data
stream, a combined NAT/ALG needs to "see" the application data stream
in clear. If security is viewed as necessary for such applications,
then satisfying this requires to align security domains with routing
realms boundaries, at least for such applications.
Yakov Rekhter [Page 5]
Internet Draft draft-ietf-nat-arch-implications-00.txt August 1998
8. Implications on performance
It is quite clear that performing IP forwarding on a packet requires
less processing than performing NAT. Whether this difference has any
practical impact is a matter of opinion.
The impact on performance is clearly going to be more significant for
applications that carry IP addresses in the application data stream,
and handling such applications require not just NAT, but ALG as well
(which has longer path length than NAT).
9. "Many-to-one", "one-to-many"
NATs allow to model a collection of hosts as a single "virtual" host.
Doing this requires no host modifications. One possible application
of this mechanism is to provide load sharing across multiple servers.
NATs allow to present a host with a single IP address as if the host
would have multiple IP addresses. Doing this requires no
modifications to host software. One possible application of this
mechanism is support connectivity between multi-homed sites and the
Internet.
10. Preserving addresses end-to-end
In general any application that assumes that addresses in the IP
header would be preserved end-to-end is going to be impacted by NATs,
as NATs clearly violate this assumption. The degree of the impact may
depend on a variety of factors, and is likely to be application
specific.
The discussion on whether the TCP/IP architecture should evolve to
explicitly recognize the possibility that addresses in the IP header
may not be preserved end-to-end is outside the scope of this
document, but may well be within the scope of the overall TCP/IP
architecture.
Yakov Rekhter [Page 6]
Internet Draft draft-ietf-nat-arch-implications-00.txt August 1998
11. Security Considerations
The impact of NATs on security is discussed in section "Implications
on security" of this document.
12. References
[RFC 1631], Egevang, K., Francis, P., "The IP Network Address
Translator", RFC 1631, May 1994
[RFC 2101], Carpenter et. al., "IPv4 Address Behavior Today", RFC
2101, February 1997
13. Acknowledgments
TBD
14. Author's Addresses
Yakov Rekhter
cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Email: yakov@cisco.com
Phone: 1-914-215-2128
Yakov Rekhter [Page 7]
