Traditional IP Network Address Translator (Traditional NAT)
RFC 3022

Document Type RFC - Informational (January 2001; Errata)
Obsoletes RFC 1631
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized with errata bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 3022 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       P. Srisuresh
Request for Comments: 3022                              Jasmine Networks
Obsoletes: 1631                                               K. Egevang
Category: Informational                                Intel Corporation
                                                            January 2001

      Traditional IP Network Address Translator (Traditional 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 (2001).  All Rights Reserved.

Preface

   The NAT operation described in this document extends address
   translation introduced in RFC 1631 and includes a new type of network
   address and TCP/UDP port translation.  In addition, this document
   corrects the Checksum adjustment algorithm published in RFC 1631 and
   attempts to discuss NAT operation and limitations in detail.

Abstract

   Basic Network Address Translation or Basic NAT is a method by which
   IP addresses are mapped from one group to another, transparent to end
   users.  Network Address Port Translation, or NAPT is a method by
   which many network addresses and their TCP/UDP (Transmission Control
   Protocol/User Datagram Protocol) ports are translated into a single
   network address and its TCP/UDP ports.  Together, these two
   operations, referred to as traditional NAT, provide a mechanism to
   connect a realm with private addresses to an external realm with
   globally unique registered addresses.

1. Introduction

   The need for IP Address translation arises when a network's internal
   IP addresses cannot be used outside the network either for privacy
   reasons or because they are invalid for use outside the network.

   Network topology outside a local domain can change in many ways.
   Customers may change providers, company backbones may be reorganized,
   or providers may merge or split.  Whenever external topology changes

Srisuresh & Egevang          Informational                      [Page 1]
RFC 3022                    Traditional NAT                 January 2001

   with time, address assignment for nodes within the local domain must
   also change to reflect the external changes.  Changes of this type
   can be hidden from users within the domain by centralizing changes to
   a single address translation router.

   Basic Address translation would (in many cases, except as noted in
   [NAT-TERM] and section 6 of this document) allow hosts in a private
   network to transparently access the external network and enable
   access to selective local hosts from the outside.  Organizations with
   a network setup predominantly for internal use, with a need for
   occasional external access are good candidates for this scheme.

   Many Small Office, Home Office (SOHO) users and telecommuting
   employees have multiple Network nodes in their office, running
   TCP/UDP applications, but have a single IP address assigned to their
   remote access router by their service provider to access remote
   networks.  This ever increasing community of remote access users
   would be benefited by NAPT, which would permit multiple nodes in a
   local network to simultaneously access remote networks using the
   single IP address assigned to their router.

   There are limitations to using the translation method.  It is
   mandatory that all requests and responses pertaining to a session be
   routed via the same NAT router.  One way to ascertain this would be
   to have NAT based on a border router that is unique to a stub domain,
   where all IP packets are either originated from the domain or
   destined to the domain.  There are other ways to ensure this with
   multiple NAT devices.  For example, a private domain could have two
   distinct exit points to different providers and the session flow from
   the hosts in a private network could traverse through whichever NAT
   device has the best metric for an external host.  When one of the NAT
   routers fail, the other could route traffic for all the connections.
   There is however a caveat with this approach, in that, rerouted flows
   could fail at the time of switchover to the new NAT router.  A way to
   overcome this potential problem is that the routers share the same
   NAT configuration and exchange state information to ensure a fail-
   safe backup for each other.

   Address translation is application independent and often accompanied
   by application specific gateways (ALGs) to perform payload monitoring
   and alterations.  FTP is the most popular ALG resident on NAT
   devices.  Applications requiring ALG intervention must not have their
   payload encoded, as doing that would effectively disables the ALG,
   unless the ALG has the key to decrypt the payload.

   This solution has the disadvantage of taking away the end-to-end
Show full document text