[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

       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]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/