Internet Draft                                              P. Srisuresh
Document: draft-ford-behave-top-03.txt                        Consultant
Expires: April 23, 2007                                          B. Ford
                                                                  M.I.T.
                                                        October 23, 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.

   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
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This document identifies two deployment scenarios that have arisen
   from the unconventional network topologies formed using Network
   Address Translator devices (NATs). First, the simplicity of
   administering networks through the combination of NAT and DHCP has
   increasingly lead to the deployment of multi-level inter-connected
   private networks involving overlapping IP address spaces. Second,
   the proliferation of private networks in enterprises, hotels and
   conferences, and the wide spread use of Virtual Private Networks
   (VPNs) to access enterprise intranet from remote locations has
   increasingly lead to overlapping IP address space between remote
   and corporate networks. The document does not dismiss these
   unconventional scenarios as invalid, but recognizes them as real and



Srisuresh & Ford                                                [Page 1]


Internet-Draft     Complications from NAT Deployments       October 2006


   offers recommendations to ensure these real scenarios can funtion.

Table of Contents

   1. Introduction and Scope........................................
   2. Multi-Level NAT Network Topologies ...........................
      2.1 Operational Details of the Multi-Level NAT Network .......
          2.1.1. Client/Server Communication .......................
          2.1.2. Peer-to-Peer Communication ........................
      2.2. Anomalies of the Multi-Level NAT Network ................
          2.2.1. Plug-and-Play NAT Devices .........................
          2.2.2. Unconventional Addressing on NAT Devices ..........
          2.2.3. Multi-Level NAT Translations ......................
          2.2.4. Mistaken End Host Identity ........................
      2.3. Summary of Recommendations ..............................
   3. Remote Access VPN Network Topologies .........................
      3.1. Operational Details of the Remote Access VPN Network ....
      3.2. Anomalies of the Remote Access VPN Network ..............
           3.2.1. Remote Router and DHCP Server Address Conflict ...
           3.2.2. Simultaneous Connectivity Conflict ...............
           3.2.3. VIP Address Conflict .............................
           3.2.4. Mistaken End Host Identity .......................
      3.3. Summary of Recommendations ..............................
   4. Security Considerations ......................................
   5. Acknowledgements .............................................
   6. Normative References .........................................
   7. Informational References .....................................

1. Introduction and Scope

   The Internet was originally designed to use a single, global 32-bit
   IP address space to uniquely 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 the following.

   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



Srisuresh & Ford                                                [Page 2]


Internet-Draft     Complications from NAT Deployments       October 2006


      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.
      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. Auto-configuration of private hosts makes
      NAT devices a compelling solution in this common scenario.

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

   [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 to the two
   scenarios identified in sections 2 and 3, as arising out of
   unconventional NAT deployment and private address space overlap.
   Even though the scenarios appear unconventional, they are real and
   and not uncommon to find. For each scenario, the document describes
   the seeming anomalies and offers recommendations on how best to make
   the topologies work.

   Section 2 describes the problem of private address space overlap
   due to multi-level NAT topology, the anomalies with the topology and
   recommendations to address the anomalies. Section 3 describes the
   problem of private address space overlap with remote access
   Virtual Private Network (VPN)  connection, the anomalies with
   address overlap and recommendations to address the anomalies.
   Section 4 describes the security considerations in these scenarios.


2 Multi-Level NAT Network Topologies




Srisuresh & Ford                                                [Page 3]


Internet-Draft     Complications from NAT Deployments       October 2006


   Due to the pragmatic considerations discussed in the previous
   section and perhaps others, NATs are increasingly, and often
   unintentionally, used to create hierarchically interconnected
   clusters of private networks as illustrated in figure 1 below. 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.


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

   Figure 1. Multi-level NAT topology with Overlapping Address Space


   In the above scenario, Bob, Alice, Jim, and CheapoISP have each
   obtained a "genuine", globally routable IP address from an upstream



Srisuresh & Ford                                                [Page 4]


Internet-Draft     Complications from NAT Deployments       October 2006


   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 (66.39.3.7) 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
   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
   public 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 (NAT-3 or NAT-44) into the IP



Srisuresh & Ford                                                [Page 5]


Internet-Draft     Complications from NAT Deployments       October 2006


   address space of CheapoISP's Private Network 2, and then again by
   CheapoISP's  NAT-2 into the public Internet's global IP address
   space.


2.1 Operational Details of the Multi-Level NAT Network

   In the "de facto" Internet address architecture that has resulted
   from the above pragmatic and economic incentives, only the nodes on
   the public Internet have globally unique IP addresses assigned by
   the 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. However, when "plug-and-play" NATs are used to create
   hierarchically interconnected clusters of private networks, a given
   private IP address can be and often is reused across many different
   private networks. In figure 1 above, for example, private networks
   1, 2, 3, and 4 all have a node with IP address 10.1.1.10.


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 public 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 18.181.0.31, NAT-1 modifies the packets comprising the
   session so as to appear on the public Internet as if the session
   originated from NAT-1.  Similarly, if host F on private network 3
   initiates a connection to host A, NAT-3 modifies the outgoing packet
   so the packet appears on private network 2 as if it had originated
   from NAT-3 at IP address 10.1.1.10.  When the modified packet
   traverses NAT-2 on private network 2, NAT-2 further modifies the
   outgoing packet so as to appear on the public Internet as if it had
   originated from NAT-2 at public IP address 155.99.25.1. The NATs in



Srisuresh & Ford                                                [Page 6]


Internet-Draft     Complications from NAT Deployments       October 2006


   effect serve as proxies that give their private "downstream" client
   nodes a temporary presence on "upstream" networks to support
   individual communication sessions.

   In summary, all hosts on the private networks 1, 2, 3, and 4 in
   figure 1 above are able to establish a client/server-style
   communication sessions with servers on the public Internet.


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

   In summary, peer-to-peer communication between hosts on disjoint
   private networks 1, 2, 3, and 4 in figure 1 above is a challenge
   without the assistance of a well known server on the public
   Internet. However, with assistance from a node in the public
   Internet, all hosts on the private networks 1, 2, 3, and 4 in
   figure 1 above are able to establish a peer-to-peer style
   communication sessions amongst themselves as well as with hosts
   on the public Internet.


2.2. Anomalies of the Multi-Level NAT Network

   Even though conventional wisdom would suggest that the network
   described above is seriously broken, in practice it still works in
   many ways. We break up figure 1 into two sub figures to better
   illustrate the anomalies. Figure 1.1 is the left half of figure 1
   and reflects the conventional single NAT deployment that is widely
   prevalent in many last-mile locations. The deployment in figure 1.1
   is popularly viewed as a pragmatic solution to work around the



Srisuresh & Ford                                                [Page 7]


Internet-Draft     Complications from NAT Deployments       October 2006


   depletion of IPv4 address space and is not considered broken.
   Figure 1.2 is the right half of figure-1 and is representative of
   the anomalies we are about to discuss.


                     Public Internet
                   (Public IP addresses)
       ----+---------------+---------------+-----------
           |               |               |
           |               |               |
       66.39.3.7      18.181.0.31     138.76.29.7
       +-------+        Host A          Host B
       | NAT-1 |        (Alice)         (Jim)
       | (Bob) |
       +-------+
       10.1.1.1
           |
           |
       Private Network 1
     (private IP addresses)
       ----+--------+----
           |        |
           |        |
       10.1.1.10 10.1.1.11
        Host C    Host D

   Figure 1.1. Conventional Single-level NAT Network topology
























Srisuresh & Ford                                                [Page 8]


Internet-Draft     Complications from NAT Deployments       October 2006



                       Public Internet
                     (Public IP addresses)
               ---+---------------+---------------+----
                  |               |               |
                  |               |               |
              18.181.0.31     138.76.29.7     155.99.25.1
               Host A          Host B      +-------------+
               (Alice)         (Jim)       |    NAT-2    |
                                           | (CheapoISP) |
                                           +-------------+
                                              10.1.1.1
                                                  |
                                                  |
                                         Private Network 2
                                       (private IP addresses)
                ----+---------------+-------------+--+-------
                    |               |                |
                    |               |                |
                10.1.1.10       10.1.1.11        10.1.1.12
                +-------+        Host E          +-------+
                | NAT-3 |        (Mary)          | NAT-4 |
                | (Ann) |                        | (Lex) |
                +-------+                        +-------+
                10.1.1.1                         10.1.1.1
                    |                                |
                    |                                |
           Private Network 3                 Private Network 4
         (private IP addresses)            (private IP addresses)
      ----+-----------+------             ----+-----------+----
          |           |                       |           |
          |           |                       |           |
     10.1.1.10   10.1.1.11                10.1.1.10   10.1.1.11
       Host F      Host G                   Host H      Host I

   Figure 1.2. Unconventional Multi-level NAT Network topology


2.2.1. Plug-and-Play NAT Devices

   Consumer NAT devices are predominantly "plug-and-play" NAT devices,
   and assume minimal user intervention during device setup. The
   "plug-and-play" NAT devices provide DHCP service on one interface
   and NAT function on another interface. Vendors of the consumer NAT
   devices make assumptions about how their consumers configure and
   hook up their PCs to the device. When consumers do not adhere to the
   vendor assumptions, the consumers end up with a broken network.




Srisuresh & Ford                                                [Page 9]


Internet-Draft     Complications from NAT Deployments       October 2006


   A "plug-and-play" NAT device provides DHCP service on the LAN
   attached to the private interface, and assumes that all private
   hosts at the consumer site have DHCP client enabled and are
   connected to the single LAN. Consumers should be informed of the
   assumption that all private hosts must be on a single LAN, with no
   router in between.

   A "Plug-and-Play" NAT device also assumes that there is no other
   NAT device or DHCP server device on the same LAN at the customer
   premises. When there are multiple "Plug-and-play" NAT devices on
   the same LAN, each NAT device will offer DHCP service on the same
   LAN, and likely from the same address pool. This could result
   in multiple end nodes on the same LAN ending up with identical IP
   addresses. That will break network connectivity to end hosts.
   Consumers should be cautioned against using more than one
   "plug-and-play" NAT device on the same LAN.

   Recommendation-1. Consumers should be informed that all private
   hosts behind a "Plug-and-play" NAT must be on a single LAN subnet,
   and that there should be no more than one "Plug-and-play" NAT device
   on the same LAN.


2.2.2. Unconventional Addressing on NAT Devices

   Let us consider the unconventional addressing with NAT-3 and
   NAT-4. 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, as well as through its
   private interface facing clients Host-F and Host-G. Likewise, NAT-4
   also has two interfaces on the same subnet 10.1.1/24.

   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 must be on a single
   connected LAN (bridged LAN or a single physical LAN). Clearly, that
   is not the case here. Even though both NAT-3 and NAT-4 have two
   interfaces on the same subnet 10.1.1/24, the NAT devices view the
   two interfaces as being on two disjoint subnets and routing realms.
   The "plug-and-play" NAT devices are really not multi-homed on the
   same subnet as in a traditional sense.

   In a traditional network, both NAT-3 and NAT-4 in figure 1.2 should
   be 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 on either of the



Srisuresh & Ford                                               [Page 10]


Internet-Draft     Complications from NAT Deployments       October 2006


   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.

   Even though both NAT-3 and NAT-4 have hosts bearing the same IP
   address on the adjacent networks, the NAT devices do communicate
   effectively as end points. Many of the "plug-and-play" NAT devices
   offer a limited number of services on them. For example, many of
   the NAT devices respond to pings from hosts on either of the
   interfaces. Even though a NAT device is often not actively
   managed, many of the NAT devices are equipped to be managed from
   the private interface. This unconventional communication with
   NAT devices is achievable because NAT devices view the
   two interfaces as being on two disjoint routing domains and
   distinguish between sessions with hosts on either interface
   (private or public).

   Consumer oriented "Plug-and-Play" NAT devices must and all NATs
   should be able to handle multi-level NAT topologies such as the one
   described in figure 1.2, 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. Essentially 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 contains. This recommendation reiterates REQ-7 of
   [BEH-UDP].

   Recommendation-2. As specified in REQ-7 of [BEH-UDP], NAT devices
   should support IP address space overlap between the address space
   on its private interface and the address space on its public
   interface. Essentially, a NAT device should keep the two IP address
   spaces separate 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.


2.2.3. Multi-Level NAT Translations

   Use of a single NAT to connect private hosts to the public Internet
   as in figure 1.1 is a fairly common practice. Many consumer NATs are
   deployed this way. However, use of multi-level NAT translations as
   in figure 1.2 is not a common practice and is not well understood.

   Let us consider the conventional single NAT translation in
   figure 1.1. Because the public and private IP address ranges are



Srisuresh & Ford                                               [Page 11]


Internet-Draft     Complications from NAT Deployments       October 2006


   numerically disjoint, nodes on private networks can make use of both
   public and private IP addresses when initiating network
   communication sessions. Nodes on a private network can use private
   IP addresses to refer to other nodes on the same private network,
   and public IP addresses to refer to nodes on the public Internet.
   For example, host C in figure 1.1 is on private network 1 and can
   directly address hosts A, B and D using their assigned IP addresses.
   This is in spite of the fact that hosts A and B are on the public
   Internet and host D alone is on the private network.

   Next, let us consider the unconventional multi-level NAT topology in
   figure 1.2. In this scenario, private hosts are able to connect to
   hosts on the public Internet. But, private hosts are not able to
   connect with all other private hosts. For example, host F in
   figure 1.2 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 cannot address
   host E by its assigned IP address, even though host 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 addressing is "legitimate" in the NAT world
   because the two hosts are on different private networks.

   It would seem that the topology in figure 1.2 with multiple
   NAT translations is broken because private hosts are not able to
   address each other directly. However, the network is not broken.
   Nodes on any private network have no direct method of addressing
   nodes on other private networks. The private networks 1, 2, 3 and 4
   are all disjoint. Hosts on private network 1 are unable to directly
   address nodes on private networks 2, 3 or 4 and vice versa. Multiple
   NAT translations was not the cause of this.

   As described in sections 2.1.1 and 2.1.2, client-server and
   peer-to-peer communication can and should be possible even with
   multi-level NAT topology deployment. A host on any private network
   must be able to communicate with any other host, no matter which
   private network the host is attached to or where the private network
   is located. Host F should be able to communicate with host E and
   carry out both client-server communication and peer-to-peer
   communication, and vice versa. Host F and host E form a hairpin
   session through NAT-2 to communicate with each other. Each host
   uses the public endpoint assigned by the Internet facing NAT (NAT-2)
   to address its peer. NAT devices should support hairpin translation
   ([P2P-STATE]) for session flows that originate from a host on one
   attached private network and targeted to a host on another private
   network also attached to the same NAT device. Hairpin translation
   is explained in detail in section 4.4 of [P2P-STATE].




Srisuresh & Ford                                               [Page 12]


Internet-Draft     Complications from NAT Deployments       October 2006


   Ideally, ISPs should not use NAT devices to connect their customers,
   so the customers do not get caught up in a multi-level NAT scenario
   and hairpin session flows. NAT devices must support hairpin
   translations for all protocol sessions the NAT device supports.
   Hairpin translation support is a requirement for peer node
   connectivity in multi-level NAT topologies. This is reiterated in
   BEHAVE recommendations for NAT devices for UDP, TCP and ICMP
   protocols ([BEH_UDP], [BEH-TCP], [BEH-ICMP]).

   Recommendation-3. As specified in BEHAVE documents for IP protocols
   ([BEH-UDP], [BEH-TCP], [BEH-ICMP]), NAT devices need to support
   hairpin translation.


2.2.4. Mistaken End Host Identity

   There can be a potential security threat due to mistaken identity
   in figure 1.2. Suppose, the CheapoISP in figure 1.2 used host E as
   the ISP mail server. Host E is assigned an RFC 1918 address of
   10.1.1.11. This address can potentially overlap with addresses on
   private networks 3 and 4. So, if a customer of CheapoISP had a
   mail server installed on his/her private network, bearing an IP
   address exactly the same as host E, this could pose a severe
   security threat to customer's mail messages. Potentially, the
   customer mail messages could be hijacked by the ISP's mail server.

   Ideally, ISPs should not use NAT devices to provide connectivity to
   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 devices themselves.

   Recommendation-4. Ideally, ISPs should not use NAT devices to
   provide connectivity to 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 customer IP addresses don't conflict with
   IP addresses of the ISP's servers.


2.3. Summary of Recommendations

   The following is a summary of recommendations identified in section
   2.2 to support the unconventional multi-level NAT topologies, such
   as the one identified in figure 1. The recommendations are addressed
   to NAT vendors, ISPs and consumers. Note, the recommendations listed
   are emanating merely from the perspective of a specific topology
   considered in the document. For this reason, the recommendations



Srisuresh & Ford                                               [Page 13]


Internet-Draft     Complications from NAT Deployments       October 2006


   should not be considered complete for NAT vendors, ISPs or
   consumers. Specifically, the recommendations for NAT vendors is
   limited. Readers should refer BEHAVE protocol documents ([BEH-UDP],
   [BEH-TCP] and [BEH-ICMP]) for a comprehensive list of requirements
   for NAT vendors. It may be noted that the recommendations provided
   for NAT vendors in this document (i.e., recommendations 2 & 3) are
   well in line with the recommendations in BEHAVE documents.

   Recommendation-1. Consumers should be informed that all private
   hosts behind a "Plug-and-play" NAT must be on a single LAN subnet,
   and that there should be no more than one "Plug-and-play" NAT device
   on the same LAN.

   Recommendation-2. As specified in REQ-7 of [BEH-UDP], NAT devices
   should support IP address space overlap between the address space
   on its private interface and the address space on its public
   interface. Essentially, a NAT device should keep the two IP address
   spaces separate 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.

   Recommendation-3. As specified in BEHAVE documents for IP protocols
   ([BEH-UDP], [BEH-TCP], [BEH-ICMP]), NAT devices need to support
   hairpin translation.

   Recommendation-4. Ideally, ISPs should not use NAT devices to
   provide connectivity to 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 customer IP addresses don't conflict with
   IP addresses of the ISP's servers.


3. Remote Access VPN Network Topologies

   Enterprises use remote access VPN to allow secure access to the
   employees working outside the enterprise premises. While outside
   the enterprise premises, an 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 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.

   IPsec, L2TP and SSL are some of the well known secure VPN
   technologies used by the remote access vendors. Besides



Srisuresh & Ford                                               [Page 14]


Internet-Draft     Complications from NAT Deployments       October 2006


   authenticating employees for granting access, remote access VPN
   servers often enforce different forms of security (e.g. IPsec, SSL)
   to protect the integrity and confidentiality of the run-time
   traffic between the VPN client and the VPN server.

   Many enterprises deploy their internal networks using RFC-1918
   private address space and 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 (VIP) address assigned to them (by the
   corporate VPN server) to access applications inside the corporate.

   Consider the remote access VPN scenario in figure 2 below.


                     (Corporate Private network 10.0.0.0/8)
                     ---------------+----------------------
                                    |
                                 10.1.1.10
                          +---------+-------+
                          | Enterprise Site |
                          | Remote Access   |
                          | VPN Server      |
                          +--------+--------+
                             129.32.34.18
                                   |
                         {---------+------}
                       {                    }
                     {                        }
                   {      Public Internet       }
                   {   (Public IP addresses)    }
                     {                        }
                       {                    }
                         {---------+------}
                                   |
                             155.99.25.1
                          +--------+--------+
                          | Remote Site     |
                          | "Plug-and-Play" |
                          | NAT router      |
                          +--------+--------+
                               10.1.1.1
                                   |



Srisuresh & Ford                                               [Page 15]


Internet-Draft     Complications from NAT Deployments       October 2006


      Remote Site Private Network  |
      -----+-----------+-----------+-------------+-----------
           |           |           |             |
        10.1.1.10  10.1.1.11   10.1.1.12     10.1.1.13
         Host A    Host B      +--------+    Host C
                               | VPN    |
                               | Client |
                               | on a PC|
                               +--------+

   Figure 2. Remote Access VPN with Overlapping Address Space


   In the above scenario, say an employee of the corporate is at a
   remote location and attempts to access the corporate network using
   the VPN client. The corporate network is laid out using RFC-1918
   address pool of 10.0.0.0/8 and say the VPN server is configured with
   an address block of 10.1.1.0/24 to assign virtual IP addresses to
   remote access VPN 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 this scenario, it is
   conventionally problematic for the VPN client to connect to the
   server(s) and other hosts at the enterprise.

   Nevertheless, despite the direct address overlap, the remote access
   VPN connection between the VPN client at the remote site and the
   VPN server at the enterprise should remain connected and should be
   made to work. I.e., the NAT device at the remote site should not
   obstruct the VPN connection traversing it. And, the remote user
   should be able to connect to any host at the enterprise through the
   VPN from the remote desktop.

   The following subsections describe the operational details of the
   VPN, anomalies with the address overlap and recommendations on
   how best to address the situation.


3.1. Operational Details of Remote Access VPN Network

   As mentioned earlier, in the "de facto" Internet address
   architecture, only the nodes on the public Internet have globally
   unique IP addresses assigned by the official IP address registries.
   Many of the networks in the edges use private IP addresses from
   RFC 1918 and use NAT devices to connect their private networks
   to the public Internet. Many enterprises adapted the approach of
   using private IP addresses internally. Employees within the
   enterprise's Intranet private network are "trusted" and may connect



Srisuresh & Ford                                               [Page 16]


Internet-Draft     Complications from NAT Deployments       October 2006


   to any of the internal hosts with minimal administrative or policy
   enforcement overhead. When an employee leaves the enterprise
   premises, remote access VPN provides the same level of intranet
   connectivity to the remote user.

   The objective of this section is to provide an overview of the
   operational details of a remote access VPN application so the reader
   has an appreciation for the problem of remote address space overlap.
   This is not a tutorial or specification of remote access VPN
   products, per se.

   When an employee at a remote site launches his/her remote access VPN
   client, the VPN server at the corporate premises demands the VPN
   client to authenticate itself. When the authentication succeeds,
   the VPN server assigns a Virtual IP (VIP) address to the client for
   connecting with the corporate Intranet. From this point onwards,
   while the VPN is active, outgoing IP packets directed to the hosts
   in the corporate Intranet are tunneled through the VPN, in that the
   the VPN server serves as the next-hop and the VPN connection as the
   next-hop link for these packets. Within the corporate Intranet, the
   outbound IP packets appear as arriving from the VIP address. so,
   IP packets from the corporate hosts to the remote user are sent to
   the remote user's VIP address and the IP packets are tunneled
   inbound to the remote user's PC through the VPN tunnel.

   This works well so long as the subnets in the corporate network
   do not conflict with subnets at the remote site where the remote
   user's PC is located. However, when the corporate network is built
   using RFC 1918 private address space and the remote location where
   the VPN client is launched is also using an overlapping network from
   RFC 1918 address space, there can be addressing conflicts. The
   remote user's PC will have a conflict in accessing nodes on the
   corporate site and nodes at 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 and the
   local network at the remote site simultaneously.

   In spite of address overlap, remote access VPN clients should be
   able to successfully establish connections with Intranet hosts in
   the enterprise.


3.2. Anomalies of the Remote Access VPN network

   Even though conventional wisdom would suggest that the remote access
   VPN scenario with overlapping address space would be seriously
   broken, in practice it still works in many ways. Let us look at some
   anomalies where there might be a problem and identify solutions



Srisuresh & Ford                                               [Page 17]


Internet-Draft     Complications from NAT Deployments       October 2006


   through which the remote access VPN application could be made to
   work even under the problem situations.


3.2.1. Remote Router and DHCP Server Address Conflict

   Routing and DHCP service are bootstrap services essential for a
   remote host to establish a VPN connection. Without DHCP lease, the
   remote host can not communicate over the IP network. Without a
   router to connect to the Internet, the remote host is unable to
   access past the local subnet to connect to the VPN server at the
   enterprise. It is essential that neither of these bootstrap services
   be tampered at the remote host in order for the VPN connection to
   stay operational. Typically, a "Plug-and-play" NAT device at the
   remote site provides both routing and DHCP services from the same
   IP address.

   When there is address overlap between hosts at corporate Intranet
   and hosts at the remote site, the remote VPN user is often unaware
   of the address conflict. Address overlap could potentially cause the
   remote user to lose connectivity to the enterprise entirely or
   lose connectivity to an arbitrary block of hosts at the enterprise.

   Consider, for example, a scenario where the IP address of the DHCP
   server at the remote site matched the IP address of a host at
   the enterprise network. When the remote user's PC is ready to
   renew the lease of the locally assigned IP address, the remote
   user's VPN client would incorrectly identify the IP packet
   as being addressed to an enterprise host and tunnel the DHCP
   renewal packet over the VPN to the remote VPN server. The DHCP
   renewal requests simply do not reach the DHCP server at the
   remote site. As a result, the remote PC would eventually lose the
   lease on the IP address and the VPN connection to the enterprise
   would be broken.

   Consider another scenario where the IP address of the remote user's
   router overlapped with the IP address of a host in the enterprise
   network. If the remote user's PC were to send ping or some type of
   periodic keep-alive packets to the router (say, to test the liveness
   of the router), the packets are intercepted by the VPN client and
   simply redirected to the VPN tunnel. This type of unintended
   redirection has the twin effect of hijackng critical packets
   addresed to the router as well as the host in the enterprise
   network (bearing the same IP address as the remote router) being
   bombarded with unintended keep-alive packets. Loss of connectivity
   to the router can result in the VPN connection being broken.

   Clearly, it is not desirable for the corporate intranet to conflict



Srisuresh & Ford                                               [Page 18]


Internet-Draft     Complications from NAT Deployments       October 2006


   with the IP addresses of the router and DHCP server at the remote
   site. VPN servers should, at a minimum, disallow access to corporate
   hosts that are using an IP address that might match any of the
   following entities at the remote site - a) client's next-hop router
   IP address used to access the VPN server, and b) DHCP server
   providing address lease on the remote host network interface. By
   doing this, VPN client on the remote PC will not intercept IP
   packets whose target IP addresses are not in the authorized list
   of enterprise hosts. And, the VPN connection remains. This however
   has the downside that the VPN client loses connectivity to a
   potentially mission critical host at the corporate site.

   Recommendation-5. When deploying a remote access VPN client, if
   there is conflict of address space between corporate Intranet and
   the remote site, the VPN server server should disallow access from
   the VPN client to corporate hosts bearing the same IP address as the
   router or DHCP server at the remote site.


3.2.2. Simultaneous Connectivity Conflict

   Ideally speaking, it is not desirable for the corporate intranet to
   conflict with any of the hosts at the remote site. As a general
   practice, if simultaneous communication with end hosts at the remote
   location is important, it is advisable to disallow access to any
   corporate network resource that overlaps the client's subnet at the
   remote site. By doing this, the remote user is able to connect to
   all local hosts simultaneously while the VPN connection is active.
   For example, if the PC's external network interface is configured
   with 10.1.1.1/24, the VPN server may be configured to disallow
   access to the corporate network that overlaps this subnet at the
   remote site for the VPN client. Such a configuration on the VPN
   server is also termed sometimes as "Split VPN" configuration. When
   "Split VPN" is enabled, the remote user is able to carry out
   simultaneous communication with hosts at the remote site and the
   hosts at the corporate intranet, with the exception of the hosts
   that overlapped the remote subnet.

   If simultaneous connectivity to local hosts is not important, the
   VPN server may be configured to require the VPN client to direct
   all communication traffic from the remote user to the VPN server
   across the VPN. This essentially ensures that all
   communication from the remote user's PC traverses the VPN link and
   routed through the VPN server. No communication takes place with
   hosts on the remote site. This configuration on the VPN server is
   also termed sometimes as "Non-split VPN". When "Non-Split VPN" is
   enabled, all traffic from the remote user's PC is directed to the
   VPN server, with the exception of traffic directed to the local



Srisuresh & Ford                                               [Page 19]


Internet-Draft     Complications from NAT Deployments       October 2006


   router and DHCP server.

   Recommendation-6. If simultaneous communication with end hosts at
   remote site is important, enterprises should configure the VPN
   server in "Split VPN" mode and disallow access to corporate hosts
   that overlap the client's subnet at remote site. If simultaneous
   connectivity to hosts at remote site is not important, enterprises
   should configure the VPN server in "Non-split VPN" mode, so the VPN
   client directs to the VPN server all traffic from the remote user,
   with the exception of traffic to the router and DHCP server at the
   remote site.


3.2.3. VIP Address Conflict

   When the VIP address assigned to the VPN client at the remote site
   is in direct conflict with the IP address of the existing network
   interface, the VPN client might be unable to establish the VPN
   connection.

   Consider a scenario where the VIP address assigned by the
   VPN server directly matched the IP address of the networking
   interface at the remote site. When the VPN client on the remote
   host attempts to set the VIP address on a virtual adapter (specific
   to the remote access application), the VIP address configuration
   will simply fail due to conflict with the IP address of the existing
   network interface. The configuration failure in turn will result in
   the remote access VPN tunnel not being established.

   Clearly, it is not advisable to have the VIP address overlap
   the IP address of the remote user's existing network interface. As a
   general rule, it is not advisable for the VIP address to overlap
   any IP address in the remote user's local subnet, as the VPN client
   on the remote PC might be forced to respond to ARP requests on the
   remote site and the VPN client might not process the handling of ARP
   requests gracefully.

   We recommend that VPN vendors offer provision to detect conflict of
   VIP address with remote site address space and switch between a
   minimum two VIP address pools on the VPN server. We also recommend
   enterprises deploying the VPN solution to use this vendor provision
   and configure the VPN server with a minimum of two distinct IP
   address pools. Alternately, the enterprises should deploy a minimum
   of two VPN servers with different address pools. By doing this, a
   VPN client that detected the conflict of VIP address with the local
   subnet is able to reconnect with the alternate VPN server using
   the alternate address pool that will not conflict.




Srisuresh & Ford                                               [Page 20]


Internet-Draft     Complications from NAT Deployments       October 2006


   Recommendation-7. VPN vendors should offer provision to detect
   conflict of VIP address with remote site address space and
   switch between a minimum of two VIP address pools with different
   subnets on the VPN server so the VIP address assigned is not in
   conflict with the address space at remote site.

   Recommendation-8. Enterprises deploying remote access VPN solution
   should adapt a strategy to avoid VIP address conflict with the
   subnet at remote site. Below are two suggestions.
   a) If the VPN device being deployed has provision to configure two
   address pools (as in recommendation above), configure the VPN
   server with a minimum of two distinct IP address pools.
   b) Deploy a minimum of two VPN servers with different address pools.
   By doing this, a VPN client that detected the conflict of VIP
   address with the subnet at remote site has the option to switch to
   alternate VPN server and eliminate VIP address conflict.


3.2.4. Mistaken End Host Identity

   When "Split VPN" configuration is set on the VPN server, there can
   be a potential security threat due to mistaken identity.
   Say, 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
   remote site, thereby violating the integrity and confidentiality of
   the contents relating to that application. Potentially, remote
   user mail messages could be hijacked by the ISP's mail server.

   Enterprises deploying remote access VPN servers should allocate
   global IP addresses for the critical servers the remote VPN clients
   typically need to access. By doing this, even if most of the private
   corporate network uses RFC 1918 address space, this will ensure that
   the remote VPN clients can always access the critical servers
   regardless of the private address space used at the remote
   attachment point.

   Recommendation-9. When "Split VPN" is configured on the VPN server,
   enterprises deploying remote access VPN servers should allocate
   global IP addresses for the critical servers the remote VPN clients
   typically need to access.


3.3. Summary of Recommendations

   The following is a summary of recommendations identified in section
   3.2 to support the address overlap in remote access VPN networks,
   such as the one identified in figure 2. The recommendations are



Srisuresh & Ford                                               [Page 21]


Internet-Draft     Complications from NAT Deployments       October 2006


   addressed to remote access VPN vendors, enterprises deploying the
   VPN servers and finally, the remote access VPN consumers. Following
   the recommendations will help ensure that a complete "network
   meltdown" is prevented.

   Recommendation-5. When deploying a remote access VPN client, if
   there is conflict of address space between corporate Intranet and
   the remote site, the VPN server server should disallow access from
   the VPN client to corporate hosts bearing the same IP address as the
   router or DHCP server at the remote site.

   Recommendation-6. If simultaneous communication with end hosts at
   remote site is important, enterprises should configure the VPN
   server in "Split VPN" mode and disallow access to corporate hosts
   that overlap the client's subnet at remote site. If simultaneous
   connectivity to hosts at remote site is not important, enterprises
   should configure the VPN server in "Non-split VPN" mode, so the VPN
   client directs to the VPN server all traffic from the remote user,
   with the exception of traffic to the router and DHCP server at the
   remote site.

   Recommendation-7. VPN vendors should offer provision to detect
   conflict of VIP address with remote site address space and
   switch between a minimum of two VIP address pools with different
   subnets on the VPN server so the VIP address assigned is not in
   conflict with the address space at remote site.

   Recommendation-8. Enterprises deploying remote access VPN solution
   should adapt a strategy to avoid VIP address conflict with the
   subnet at remote site. Below are two suggestions.
   a) If the VPN device being deployed has provision to configure two
   address pools (as in recommendation above), configure the VPN
   server with a minimum of two distinct IP address pools.
   b) Deploy a minimum of two VPN servers with different address pools.
   By doing this, a VPN client that detected the conflict of VIP
   address with the subnet at remote site has the option to switch to
   alternate VPN server and eliminate VIP address conflict.

   Recommendation-9. When "Split VPN" is configured on the VPN server,
   enterprises deploying remote access VPN servers should allocate
   global IP addresses for the critical servers the remote VPN clients
   typically need to access.


4. Security Considerations

   This document does not inherently create new security issues.
   Security issues known to DHCP servers and NAT devices are



Srisuresh & Ford                                               [Page 22]


Internet-Draft     Complications from NAT Deployments       October 2006


   applicable, but not within the scope of this document. Likewise,
   security issues specific to remote access VPN devices are also
   appliable to the remote access VPN topology, but not within the
   scope of this document. The security issues reviewed here only
   those relevant to the topologies described in sections 2 and 3,
   specifcally as they apply to private address space overlap in the
   topologies described.

   Mistaken end host identity is a security concern present in both
   topologies discussed. Mistaken end host identity, described in
   sections 2.2.4 and 3.2.4 for each of the topologies reviewed,
   essentially points the possibility of application services being
   hijacked by the wrong application server (ex: Mail server). Security
   violation due to mistaken end host identity arises principally due
   to critical servers being assigned RFC 1918 private addresses. The
   recommendation suggested for both scenarios is to assign globally
   unique pulic IP addresses for the critical servers.

   It is also recommended in section 2.1.2 that applications adapt
   end-to-end authentication and not depend on source IP address for
   authentication. Doing this will thwart connection hijacking and
   denial of service attacks.


5. Acknowledgements

   The authors wish to thank Dan Wing for reviewing the document in
   detail and making helpful suggestions in reorganizing the
   document format.


6. Normative References

[BEH-ICMP]  Srisuresh, P., Ford, B., Sivakumar, S., and Guha, S.,
            "NAT Behavioral Requirements for ICMP Protocol",
            draft-ietf-behave-nat-icmp-01.txt (Work In Progress),
            October 2006.

[BEH-TCP]   Guha, S., Biswas, K., Ford, B., Sivakumar, S., and
            Srisuresh, P., "NAT Behavioral Requirements for TCP",
            draft-ietf-behave-nat-tcp-02.txt (Work In Progress),
            October 2006.

[BEH-UDP]   Audet, F. and Jennings, C., "NAT Behavioral Requirements
            for Unicast UDP", draft-ietf-behave-nat-udp-08.txt (Work
            In Progress), October 2006.

[NAT-TERM]  P. Srisuresh and M. Holdrege, "IP Network Address Translator



Srisuresh & Ford                                               [Page 23]


Internet-Draft     Complications from NAT Deployments       October 2006


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

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


7. Informational References

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

[P2P-STATE] Srisuresh, P., Ford, B., and Kegel, D., "State of Peer-to-
            Peer(P2P) Communication Across Network Address Translators
            (NATs)", draft-ietf-behave-p2p-state-00.txt,
            October 2006, Work in Progress.


Authors' Addresses:

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

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


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to



Srisuresh & Ford                                               [Page 24]


Internet-Draft     Complications from NAT Deployments       October 2006


   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


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
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.














Srisuresh & Ford                                               [Page 25]