Browse Prior Art Database

Architectural Implications of NAT (RFC2993)

IP.com Disclosure Number: IPCOM000005187D
Original Publication Date: 2000-Nov-01
Included in the Prior Art Database: 2001-Aug-17
Document File: 30 page(s) / 74K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Hain: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 5% of the total text.

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 ...