[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5684

Internet Draft                                              P. Srisuresh
Document: draft-ford-behave-top-01.txt                        Consultant
Expires: September 5, 2006                                       B. Ford
                                                           March 5, 2006

   Complications from Network Address Translator Deployment Topologies

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This document identifies two problems that have arisen from the
   the unconventional network topologies that are often constructed
   with the deployment of network address translator devices (NATs).
   This document also specifies best current practice recommendations
   for dealing with the issues identified with the two problems.
   First, the simplicity of administering networks through the
   combination of NAT and DHCP has increasingly lead to the
   deployment of multi-level hierarchies of inter-connected private
   networks involving overlapping private IP address spaces. Second,

Srisuresh & Ford                                                [Page 1]

Internet-Draft     Complications from NAT Deployments         March 2006

   the proliferation of private networks in the corporates and the
   wide spread use of remote access virtual private networks (VPNs) can
   lead to conflict of private IP address space between the remote
   network where the VPN client is located and the corporate network.

Table of Contents

   1.  Introduction and Scope........................................
   2.  Multi-Level Private Address Space Topologies .................
       2.1. Operational Details of the Network ......................
       2.1.1. Client/Server Communication ...........................
       2.1.2. Peer-to-Peer Communication ............................
       2.2. Anomalies and Caveats with the Network ..................
       2.2.1. Anomalies with the Network ............................
       2.2.2. Caveats with the Network ..............................
       2.3. Recommendations .........................................
   3.  Remote Access VPN Topologies with Private Address Space ......
       3.1. Operational Details of the Network ......................
       3.2. Caveats with the Network ................................
       3.3. Recommendations .........................................
   4.  Security Considerations ......................................
   5.  Informational References .....................................

1. Introduction and Scope

   The Internet was originally designed to use a single, global 32-bit
   IP address space to identify hosts on the network, allowing
   applications on one host to address and initiate communications with
   applications on any other host regardless of the respective hosts'
   topological locations or administrative domains.  For a variety of
   pragmatic reasons, however, the Internet has gradually drifted away
   from strict conformance to this ideal of a single flat global address
   space, and towards a hierarchy of smaller "private" address spaces
   [RFC1918] clustered around a large central "public" address space.
   The most important pragmatic causes of this unintended evolution of
   the Internet's architecture appear to be:

   1. Depletion of the 32-bit IPv4 address space due to the exploding
      total number of hosts on the Internet.  Although IPv6 promises to
      solve this problem, the uptake of IPv6 has in practice been slower
      than expected.

   2. Perceived Security and Privacy: Traditional NAT devices provide a
      filtering function that permits session flows to cross the NAT in
      just one direction, from private hosts to public network hosts.
      This filtering function is widely perceived as a security benefit.

Srisuresh & Ford                                                [Page 2]

Internet-Draft     Complications from NAT Deployments         March 2006

      In addition, the NAT's translation of a host's original IP
      addresses and port number in private network into an unrelated,
      external IP address and port number is perceived by some as a
      privacy benefit.

   3. Ease-of-use: NAT vendors often combine the NAT function with a
      DHCP server function in the same device, which creates a
      compelling, effectively "plug-and-play" method of setting up small
      Internet-attached personal networks that is often much easier in
      practice for unsophisticated consumers than configuring an
      IP subnet.  The many popular and inexpensive consumer NAT devices
      on the market are usually configured "out of the box" to obtain a
      single "public" IP address from an ISP or "upstream" network via
      DHCP, and the NAT device in turn acts as both a DHCP server and
      default router for any "downstream" hosts (and even other NATs)
      that the user plugs into it.  Consumer NATs in this way
      effectively create and manage private home networks automatically
      without requiring any knowledge of network protocols or management
      on the part of the user.

      This ease-of-use benefit of NAT stems ultimately from the fact
      that DHCP is only capable of providing a single auto-configured
      IP address to each client.  A DHCP client currently has no way to
      request a *block* of IP addresses from the server, from which it
      might form its own auto-configured "downstream" IP subnet for use
      with the DHCP service it offers.  The fact that the DHCP function
      in the NAT devices is capable of auto-configuring client hosts
      makes NAT devices a compelling solution in this common scenario.

   The term NAT used throughout the document specifically refers to
   the traditional NAT, as defined in [NAT-TERM] and specified in

   [NAT-PROT] identifies various complications with application
   protocols due to NAT devices. This document acts as an adjunct to
   [NAT-PROT]. The scope of the document is restricted specifically to
   two problems that were identified as arising out of private address
   space overlaps. For each of the problems, the document describes the
   problem statement, caveats, topologies in which the problem can
   occur, and offers recommendations on how to alleviate.

   Section 2 describes the problem of private address space overlap
   due to multi-level hierarchies of private networks and provides
   recommendations on how to alleviate them. Section 3 describes the
   problem of private address space conflict between the address space
   at remote access VPN client locations and the VPN server site, and
   makes recommendations on how to alleviate them. Section 4 refers
   the security considerations in these scenarios.

Srisuresh & Ford                                                [Page 3]

Internet-Draft     Complications from NAT Deployments         March 2006

2 Multi-Level Private Address Space Topologies

   Due to the above pragmatic considerations and perhaps others, NATs
   are increasingly, and often unintentionally, used to create
   hierarchically interconnected clusters of private networks as
   illustrated in the following diagram. The creation of multi-level
   hierarchies is often unintentional, since each level of NAT is
   typically deployed by a separate administrative entity such
   as an ISP, a corporation, or a home user.

Srisuresh & Ford                                                [Page 4]

Internet-Draft     Complications from NAT Deployments         March 2006

                               Public Internet
                           (Public IP addresses)
           |               |               |               |
           |               |               |               |
       +-------+        Host A          Host B      +-------------+
       | NAT-1 |        (Alice)         (Jim)       |    NAT-2    |
       | (Bob) |                                    | (CheapoISP) |
       +-------+                                    +-------------+                              
           |                                               |
           |                                               |
       Private Network 1                      Private Network 2
     (private IP addresses)                 (private IP addresses)
       ----+--------+----      ----+-----------------------+----
           |        |              |           |           |
           |        |              |           |           |
        Host C    Host D       +-------+    Host E     +-------+
                               | NAT-3 |    (Mary)     | NAT-4 |
                               | (Ann) |               | (Lex) |
                               +-------+               +-------+
                                   |                       |
                                   |                       |
               Private Network 3   |         Private Network 4
             (private IP addresses)|       (private IP addresses)
               ----+-----------+---+       ----+-----------+----
                   |           |               |           |
                   |           |               |           |
                Host F      Host G          Host H      Host I

     Figure 1: Multi-level NAT topology with private address space

   In the above scenario, Bob, Alice, Jim, and CheapoISP have each
   obtained a "genuine", globally routable IP address from an upstream
   service provider.  Alice and Jim have chosen to attach only a single
   machine at each of these public IP addresses, preserving the
   originally intended architecture of the Internet and making their
   hosts, A and B, globally addressable throughout the Internet.  Bob,
   in contrast, has purchased and attached a typical consumer NAT box.
   Bob's NAT obtains its external IP address ( from Bob's ISP
   via DHCP, and automatically creates a private 10.1.1.x network for
   Bob's hosts C and D, acting as the DHCP server and default router for

Srisuresh & Ford                                                [Page 5]

Internet-Draft     Complications from NAT Deployments         March 2006

   this private network.  Bob probably does not even know anything about
   IP addresses; he merely knows that plugging the NAT into the Internet
   as instructed by the ISP, and then plugging his hosts into the NAT as
   the NAT's manual indicates, seems to work and gives all of his hosts
   access to Internet.

   CheapoISP, an inexpensive service provider, has allocated only one or
   a few globally routable IP addresses, and uses NAT to share these
   public IP addresses among its many customers. Such an arrangement is
   becoming increasingly common, especially in rapidly-developing
   countries where the exploding number of Internet-attached hosts
   greatly outstrips the ability of ISPs to obtain globally unique IP
   addresses for them. CheapoISP has chosen the popular 10.1.1.x
   address for its private network, since this is one of the three
   well-known private IP address blocks allocated in RFC1918
   specifically for this purpose.

   Of the three incentives listed in section 1 for NAT deployment, the
   last two still apply even to customers of ISPs that use NAT,
   resulting in multi-level NAT topologies as illustrated in the right
   side of the above diagram. Even three-level NAT topologies are known
   to exist. CheapoISP's customers Ann, Mary, and Lex have each obtained
   a single IP address on CheapoISP's network (Private Network 2), via
   DHCP.  Mary attaches only a single host at this point, but
   Ann and Lex each independently purchase and deploy consumer NATs in
   the same way that Bob did above.  As it turns out, these consumer
   NATs also happen to use 10.1.1.x addresses for the private networks
   they create, since these are the configuration defaults hard-coded
   into the NATs by their vendors.  Ann and Lex probably know nothing
   about IP addresses, and in particular they are probably unaware that
   the IP address spaces of their own private networks overlap not only
   with each other but also with the private IP address space used by
   their immediately upstream network.

   Nevertheless, despite this direct overlap, all of the "multi-level
   NATted hosts" - F, G, H, and I in this case - all nominally function
   and are able to initiate connections to any public server on the main
   Internet that has a globally routable IP address.  Connections made
   from these hosts to the main Internet are merely translated twice.
   once by the consumer NAT (3 or 4) into the IP address space of
   CheapoISP's Private Network 2, and then again by CheapoISP's NAT 2
   into the main Internet's global IP address space.

2.1 Operational Details of the Network

   In the "de facto" Internet address architecture that has resulted
   from the above pragmatic and economic incentives, only the nodes on
   the main Internet have globally unique IP addresses assigned by the

Srisuresh & Ford                                                [Page 6]

Internet-Draft     Complications from NAT Deployments         March 2006

   official IP address registries.  IP addresses on different private
   networks are typically managed independently - either manually by
   the administrator of the private network itself, or automatically by
   the NAT through which the private network is connected to its
   "upstream" service provider.

   By convention, nodes on private networks are usually assigned IP
   addresses in one of the private address space ranges specifically
   allocated to this purpose in RFC 1918, ensuring that private IP
   addresses are easily distinguishable and do not conflict with the
   public IP addresses officially assigned to globally routable Internet
   hosts.  A given private IP address can be and often is reused across
   many different private networks, however.  In the figure above, for
   example, private networks 1, 2, 3, and 4 all have a node with IP

   Because the public and private IP address ranges are numerically
   disjoint, nodes on private networks can make use of both public and
   private IP addresses when initiating network communication sessions.
   Nodes on private networks can use private IP addresses to refer to
   other nodes on the same private network, and nodes can use public IP
   addresses to refer to nodes on the main Internet.  Nodes on private
   networks have no direct method of addressing nodes on other private
   networks, however, and nodes on the main Internet have no direct way
   to address nodes on any private network.  For example, host F in the
   figure above can directly address hosts A, B, and G using their
   assigned IP addresses, but F has no way to address any of the other
   hosts in the diagram.  Host F in particular has no way even to
   address host E, even though E is located on the immediately
   "upstream" private network through which F is connected to the
   Internet!  Host E has the same IP address as host G. Yet, this is
   "legitimate" in the NAT world because the two hosts are on different
   private networks.

2.1.1. Client/Server Communication

   When a host on a private network initiates a client/server-style
   communication session with a server on the main Internet, via the
   server's public IP address, the NAT intercepts the packets comprising
   that session (usually as a consequence of being the default router
   for the private network), and modifies the packets' IP and TCP/UDP
   headers so as to make the session appear externally as if it was
   initiated by the NAT itself.

   For example, if host C above initiates a connection to host A at IP
   address, NAT 1 modifies the packets comprising the
   session so as to appear on the main Internet as if the session
   originated from NAT 1.  Similarly, if host F on private network 3

Srisuresh & Ford                                                [Page 7]

Internet-Draft     Complications from NAT Deployments         March 2006

   initiates a connection to host A, NAT 3 modifies the session so as to
   appear on private network 2 as if it had originated from NAT 3 at IP
   address  The modified session then traverses private
   network 2 and arrives at NAT 2, which further modifies the session so
   as to appear on the main Internet as if it had originated from NAT 2
   at public IP address  The NATs in effect serve as
   proxies that give their private "downstream" client nodes a temporary
   presence on "upstream" networks to support individual communication

2.1.2. Peer-to-Peer Communication

   While this network organization functions in practice for
   client/server-style communication, when the client is behind one or
   more levels of NAT and the server is on the main Internet, the lack
   of globally routable addresses for hosts on private networks makes
   direct peer-to-peer communication between those hosts difficult.  For
   example, two private hosts F and H on the network shown above might
   "meet" and learn of each other through a well-known server on the
   main Internet, such as Host A, and desire to establish direct
   communication between G and H without requiring A to forward each
   packet.  If G and H merely learn each other's (private) IP addresses
   from a registry kept by A, their attempts to connect to each other
   will fail because G and H reside on different private networks.
   Worse, if their connection attempts are not properly authenticated in
   some fashion, they may appear to succeed but end up talking to the
   wrong host: for example, G may end up talking to Host F, the host on
   Private Network 3 that happens to have the same private IP address as
   Host H.  Host H might similarly end up unintentionally connecting to
   Host I.

2.2. Anomalies and Caveats with the Network

2.2.1 Anomalies with the network

   Even though conventional wisdom would suggest that the network
   described above is seriously broken, in practice it still works in
   many ways.  Let us look at some anomalies here.

   For example, NAT-3 and NAT-4 are apparently multi-homed on the same
   subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24
   through its external interface facing NAT-2, and is also on subnet
   10.1.1/24 through its private interface facing clients, Host-F and
   Host-G. Similarly the case with NAT-4. In a traditional network, when
   a node has multiple interfaces with IP addresses on the same subnet,
   it is natural  to assume that all interfaces with addresses on the
   same subnet are on a single connected LAN (bridged LAN or a single
   physical LAN). Clearly, that is not the case here. Even though both

Srisuresh & Ford                                                [Page 8]

Internet-Draft     Complications from NAT Deployments         March 2006

   NAT-3 and NAT-4 have two interfaces on the same subnet 10.1.1/24,
   the two interfaces are on two disjoint subnets and LANs. So, the
   NATs are really not multi-homed. This is an anomaly.

   Both NAT-3 and NAT-4 are incapable of communicating reliably as a
   transport endpoint with other nodes on their adjacent networks
   (ex: private networks 2 and 3 in the case of NAT-3 and private
   Networks 2 and 4 in the case of NAT-4). This is because applications
   on either of the NAT devices cannot know to differentiate packets
   from hosts either of the subnets bearing the same IP address. If
   NAT-3 attempts to resolve the IP address of a neighboring host in
   the conventional manner by broadcasting an ARP request on all of its
   physical interfaces bearing the same subnet, it may get a different
   response on each of its physical interfaces.  This is another

   Broken as it already is, it could have been worse and non-functional
   if the network layout wasn't carefully orchestrated.

   For example, all external interfaces for intermediate Nat devices
   in figure 1 are arranged hierarchically, so the outgoing path for
   all intermediate NAT devices are oriented towards the Internet
   facing NAT. Further, the NAT devices provide the DHCP-service on
   the private interfaces and the NAT service on the external interface.
   If the nodes are connected differently or the services were offered
   on the wrong interface, chaos could have ensued. Imagine NAT-3
   device having its private interface on private network 2 and NAT
   interface on private network 3.

   Chaos would also ensue if there were multiple NAT devices on the same
   LAN.  Multiple NAT devices providing DHCP service on the same LAN,
   from the same address pool is a recipe for chaos. Multiple nodes
   would end up having the same IP address. That would make the network
   broken. The network can also be broken if two NAT nodes attempted to
   provide NAT service without coordination between the two.

   The network will also be broken, if the address a NAT node
   (ex: NAT-3 or NAT-4) assumed on the DHCP-service providing interface
   is same as the address it is assigned on the external interface.
   This can easily happen when the vendors are different. Say, both
   interfaces being assigned

2.2.1 Caveats with the network

   Below are some known caveats with the network shown in figure 1.

   1. The NAT boxes (NAT-3, NAT-4, NAT-1, NAT-2) themselves do not
   provide any service other than respond to ping. NATs are not

Srisuresh & Ford                                                [Page 9]

Internet-Draft     Complications from NAT Deployments         March 2006


   2. Hosts on the private realm are all assumed to be on a single LAN

   3. There can be a security threat. Suppose, an ISP unwisely used
   RFC1918 IP addresses for its mail servers and say these addresses
   overlapped with the customer's mail servers. In such a case,
   Customer mail messages could be hijacked by the ISP’s mail server.

2.3. Recommendations

   Consumer-oriented "Plug and Play" NAT devices MUST, and all NATs
   SHOULD, be able to handle topologies such as the one described above,
   in which a private IP address space on one side of the NAT
   potentially conflicts with the private IP address space on the other
   side.  This means that the NAT must be able to keep the two IP
   address spaces separate in its internal data structures, and base
   all packet processing decisions on the "side" or "port" from which
   the packet arrived and not just on the basis of the IP addresses it

   NATs should individually conform to [BEHAVE-UDP] and [BEHAVE-TCP]
   guidelines, especially including hairpin translation support.

   Peer-to-peer apps should conform to [BEHAVE-APP] guidelines for
   middlebox traversal.

   Ideally, ISPs should not NAT their customers.  If they do, any
   servers on the ISP's private network that need to be accessible to
   the ISP's customers (e.g., mail servers) should have global IP
   addresses, to ensure accessibility to customers who deploy NAT

   NAT boxes should provide an ability to use one of two DHCP address
   pools and automagically use an address pool that does not conflict
   with the external interface IP address.

3. Remote Access VPN Topologies with Private Address Space

   Remote Access Virtual Private Network (VPN) is popular with
   enterprises. Enterprises use Remote Access VPN to allow secure
   access to their employees working outside the enterprise premises.
   While outside the enterprise premises, the employee may be located
   in his/her home office, hotel, conference or a partner's office.
   In all cases, it is desirable for the employee at the remote site
   to have unhindered access to his/her corporate network and the
   applications running on the corporate networks. This is so the

Srisuresh & Ford                                               [Page 10]

Internet-Draft     Complications from NAT Deployments         March 2006

   employee can get his/her work done seamlessly without jeopardizing
   the integrity and confidentiality of the corporate network and the
   applications running on the network.

   Besides authenticating employees for granting access, remote access
   VPN servers often enforce different forms of security to protect the
   integrity and confidentiality of the run-time traffic between the
   VPN client and the remote access server. IPsec, L2TP and SSL are
   some of the well known secure VPN technologies used by the remote
   access vendors.

   Many small enterprises deploy their internal networks using RFC-1918
   private address space. The enterprises use NAT devices to connect to
   the public Internet. Further, many of the applications in the
   corporate network refer to information (such as URLs) and services
   using private addresses in the corporate network. Applications such
   as NFS rely on simple source IP address based filtering to restrict
   access to corporate users. These are some reasons why the remote
   access VPN servers are configured with a block of IP addresses from
   the corporate private network to assign to remote access clients.
   VPN clients use the virtual IP address assigned to them (by the
   corporate VPN server) to access applications inside the corporate.

   Consider the following remote access scenario.

Srisuresh & Ford                                               [Page 11]

Internet-Draft     Complications from NAT Deployments         March 2006

                     (Corporate Private network
                            |               |
                            | Secure        |
                            | Remote Access |
                            | VPN Server    |
              {                                    }
              {           Public Internet          }
              {        (Public IP addresses)       }
              {                                    }
                            |    NAT         |
                            | (in a Hotel    |         +--------+
                            | or home office |         |        |
                            | or a partner's |         | DHCP   |
                            | corp. office   |         | Server |
                            |                |         |        |
                            +----------------+         +--------+
                                   |                        |
          Remote Private Network   |                        |
           |           |           |             |
           |           |           |             |
         Host A    Host B      +--------+    Host C
                               | RA-VPN |
                               | Client |
                               | PC     |

    Figure 2: Remote access VPN to access enterprise from private LAN

    In the above scenario, say an employee of the corporate is at a
    remote site and trying to access the corporate network using the

Srisuresh & Ford                                               [Page 12]

Internet-Draft     Complications from NAT Deployments         March 2006

    VPN client. The corporate network is laid out using
    and say the VPN server is configured with an address block of to assign virtual IP addresses to its remote access
    clients. Now. say the employee at the remote site is attached to
    a network on the remote site which also happens to be using a
    RFC-1918 address space based network and coincidentally overlaps
    the corporate network. In such a situation, there can be several
    problems with using the VPN client to connect to the remote
    access server at the enterprise.

    The following subsections describe the operational of VPNs,
    caveats with the address overlap scenario and potential remedies
    to correct the situation.

3.1. Operational Details of the Network

   Below is a high level description of how a remote access VPN
   typically works. The specifics may vary from vendor to vendor. The
   intent is to provide a high level understanding of the operation to
   gain appreciation for the problem at hand.

   Typically, when an employee at the remote site launches his/her
   VPN client, the VPN client is required to authenticate with the VPN
   server at the corporate premises. Once the authentication succeeds,
   the VPN server assigns a Virtual IP (VIP) address for use by the
   VPN client in all its transactions with the corporate network and
   applications. The VPN client in turn installs a Virtual adapter
   (VA) on the PC and configures the VA with the VIP address it was
   assigned by the VPN server. Further, the VPN client adds new routes
   to the PC such that all the subnets in the corporate are accessible
   via the Virtual Adapter. By doing this, all traffic directed to
   and from the corporate networks is redirected to the secure VPN,
   while leaving all other routes unchanged on the PC.

   This works well so long as there is no conflict of routes on the PC
   when new routes to the corporate network are added. This becomes
   tricky when the corporate intranet network is built using RFC1918
   address space and the remote location where the VPN client is
   launched is also using an overlapping network from RFC1918 address

   In such a situation, the routing table on the PC will have a
   conflict in accessing nodes on the corporate site and nodes in
   the remote site bearing the same IP address simultaneously.
   Consequently, the VPN client may be unable to have full access
   to the employee's corporate network.

3.2. Caveats with the Network

Srisuresh & Ford                                               [Page 13]

Internet-Draft     Complications from NAT Deployments         March 2006

   When there is address overlap between corporate network and the
   remote site, the VPN user may be unaware of this and may loose
   connectivity to an arbitrary block of services on the corporate
   network. Worse yet, when a certain service (ex: SMTP mail service)
   is configured on exactly the same IP address on both the corporate
   site and the remote site, the user could unknowingly be using the
   service on the wrong node at remote site, thereby violating the
   integrity and confidentiality of the contents relating to that

   In the case a corporate address resource overlaps with the router
   on the remote site, the VPN user could loose connectivity entirely
   if requests to the router address are redirected to the VPN.
   Likewise, if a corporate address resource overlaps with the DHCP
   server on the remote site, the VPN user could also loose
   connectivity if requests to the DHCP server are redirected to the

3.3. Recommendations

   Remote access VPN clients work best when the external client IP
   address (on the physical network interface) does not overlap with
   the address space from the corporate VPN address pool. However,
   this cannot be assumed always. Employees often need to work from
   locations such as hotel rooms and conferences that use arbitrary
   blocks of private address spaces, which neither the employee nor
   the corporate network administrator has any control over. In these
   situations, the following recommendations will help ensure that a
   complete "network meltdown" is prevented.

   1. The VPN client's external IP address and subnet (at the remote
      site) should not fall within the VIP address pool assigned by the
      VPN server.

   2. The VPN users should not attempt to access services on the remote
      site and services on the corporate site simultaneously.
      Specifically, when the VPN is connected, the VPN user should not
      attempt to access services on the remote site. Unavoidable
      services such as the routing and DHCP service at the remote site
      are exempted.

   3. VPN servers should not permit access to corporate services that
      are running on an IP address that match the following entities
      at the remote site. a) client's external IP address, b) client's
      next-hop router IP address used to access the VPN server, and
      c) DHCP server providing address lease on the external interface.
      The good news is that all these three essential services are

Srisuresh & Ford                                               [Page 14]

Internet-Draft     Complications from NAT Deployments         March 2006

      on the same subnet on the external interface.

      As a general practice, it is advisable to disallow access to any
      corporate network resource that overlaps the client's external
      IP subnet. For example, if the PC's external network interface is
      configured with, disallow access to the corporate
      network that overlaps this subnet from the remote access VPN

   The above recommendations do not guarantee that the remote
   employee will be able to gain complete access to the corporate
   network he needs to if there is address overlap. Below are some
   recommendations to ensure the employee is always able to
   access mission critical application on the corporate network.

   1. Even if most of the private corporate network uses RFC1918 address
      space, allocate global IP addresses at least for the pool of IP
      addresses assigned to remote VPN clients, and for the critical
      servers on the corporate network that the remote VPN clients
      typically need to access.  This will ensure that the remote VPN
      clients can always access those critical servers regardless of
      the private address space used at the remote attachment point.

   2. We suggest that there be two IP address pools on the VPN
      server, (or) two VPN servers with different address pools so
      the address pool which is used for a VPN client doesn't
      ever conflict with the physical Network interface IP address.
      For example, the VPN server might detect a conflict and inform
      the user that he/she should try to connect to the "other" VPN
      server or IP address pool. Ideally, the VPN client and server
      could cooperate to perform this negotiation automatically.

   3. The subnet mask used on the hotels be as small as possible (say,
      /29) and the hotels have a centralized DHCP-server that covers
      multiple small subnets. By doing this, the likelihood of
      conflict with corporate services is minimized.

      Perhaps, if the VPN server identified the overlap of the remote
      IP network and notified the VPN-client of the loss of
      connectivity to that portion of the corporate world, the
      VPN-client could do something about it - such as talk to the
      local admin about assigning himself an IP address from a
      different subnet (say, plugging to a different plug point) if
      the hotel has such a facility.

   4. Finally, the VPN-client could come in as bump in the stack and
      redirect all relevant packets in the subnet (with the exception
      of those that match with the router and DHCP server) over the

Srisuresh & Ford                                               [Page 15]

Internet-Draft     Complications from NAT Deployments         March 2006

      VPN. This at least reduces the size of the "black hole" on the
      corporate network from a whole subnet to merely the specific
      services running on the DHCP server and the next-hop router.

4. Security Considerations

   Sections 2.2.1 and 3.2 specify the potential security violations
   that can arise when there are IP address conflicts from topological
   deployments. Sections 2.3 and 3.3 recommend ways to protect the
   users from these security violations.

5. Informational References

[RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and
           Lear, E., "Address Allocation for Private Internets", BCP 5,
           RFC 1918, February 1996.

[KEGEL]    Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999.

[NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications
           with the IP Network Address Translator", RFC 3027,
           January 2001.

[NAT-PT]   G. Tsirtsis and P. Srisuresh, "Network Address
           Translation - Protocol Translation (NAT-PT)", RFC 2766,
           February 2000.

[NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address
           Translator (NAT) Terminology and Considerations", RFC
           2663, August 1999.

[NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network
           Address Translator (Traditional NAT)", RFC 3022,
           January 2001.

Authors' Addresses:

   Pyda Srisuresh
   20072 Pacifica Dr.
   Cupertino, CA 95014
   Phone: (408) 836-4773
   E-mail: srisuresh@yahoo.com

   Bryan Ford

Srisuresh & Ford                                               [Page 16]

Internet-Draft     Complications from NAT Deployments         March 2006

   Computer Science and Artificial Intelligence Laboratory
   Massachusetts Institute of Technology
   77 Massachusetts Ave.
   Cambridge, MA 02139
   Phone: (617) 253-5261
   E-mail: baford@mit.edu
   Web: http://www.brynosaurus.com/

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on

Srisuresh & Ford                                               [Page 17]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/