Architectural Implications of NAT
RFC 2993
|
| Document |
Type |
|
RFC - Informational
(November 2000; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IAB
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
IAB state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
Network Working Group T. Hain
Request for Comments: 2993 Microsoft
Category: Informational November 2000
Architectural Implications of NAT
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
In light of the growing interest in, and deployment of network
address translation (NAT) RFC-1631, this paper will discuss some of
the architectural implications and guidelines for implementations. It
is assumed the reader is familiar with the address translation
concepts presented in RFC-1631.
Table of Contents
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 public
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. Introduction
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 address
use. But the authors were worried about the impact of this
technology. Several places in the document they pointed out the need
to experiment and see what applications may be adversely affected by
NAT's header manipulations, even before there was any significant
operational experience. This is further evidenced in a quote from
the conclusions: 'NAT has several negative characteristics that make
it inappropriate as a long term solution, and may make it
inappropriate even as a short term solution.'
Now, six years later and in spite of the prediction, the use of NATs
is becoming widespread in the Internet. Some people are proclaiming
NAT as both the short and long term solution to some of the
Internet's address availability issues and questioning the need to
continue the development of IPv6. The claim is sometimes made that
NAT 'just works' with no serious effects except on a few legacy
applications. At the same time others see a myriad of difficulties
caused by the increasing use of NAT.
The arguments pro & con frequently take on religious tones, with each
side passionate about its position.
- Proponents bring enthusiasm and frequently cite the most popular
applications of Mail & Web services as shining examples of NAT
transparency. They will also point out that NAT is the feature
that finally breaks the semantic overload of the IP address as
both a locator and the global endpoint identifier (EID).
- An opposing view of NAT is that of a malicious technology, a weed
which is destined to choke out continued Internet development.
While recognizing there are perceived address shortages, the
opponents of NAT view it as operationally inadequate at best,
bordering on a sham as an Internet access solution. Reality lies
somewhere in between these extreme viewpoints.
In any case it is clear NAT affects the transparency of end-to-end
Show full document text