Subject: [Ietf-behave] Topological complications from NAT

From: Bryan Ford <[email-masked]>
Date: Sun, 23 Jan 2005 03:08:18 -0800 (PST)

Hi folks,

I want to get your "first reactions" on an early draft of a new document that 
my co-author Pyda Srisuresh and I have started, which discusses certain NAT 
topics that the BEHAVE roadmap currently doesn't address, but probably needs 
to.  As written so far, the document focuses particularly on discussing some 
of the "weird topologies" that NAT deployment increasingly (and often 
unintentionally) leads to, such as multi-level NAT with potentially 
overlapping private IP address spaces, and IP address space conflicts created 
by remote access VPN software.

I've been thinking, however, that this document might appropriately be 
generalized a bit further into a document describing "recommendations 
pertaining to NAT deployment" or something like that.  Currently on the 
BEHAVE roadmap we have several documents targetted at NAT implementors, and a 
document targetted at application developers, but nothing targetted at 
network administrators who actually _deploy_ NATs - this might be a crucial 
gap.  (Obviously we want to avoid making the title sound like the document is 
recommending the deployment of NAT, which it's definitely not - but that's a 
wording issue.)  Let us know what you think.

Thanks,
Bryan

---

  Topological Complications from Network Address Translation (NAT-TOP)

Abstract

   This document identifies and provides recommendations for dealing
   with several new issues that have arisen recently out the ubiquitous
   deployment of network address translators (NAT), and the
   unconventional network topologies that are often constructed with
   them.  First, the simplicity of configuring and administering
   networks through the combination of NAT and DHCP is increasingly
   leading to the deployment of multi-level hierarchies of
   interconnected private networks involving many overlapping private IP
   address spaces.  The creation of these multi-level hierarchies is
   often unintentional, since each level of NAT is typically deployed by
   a separate administrative entity: e.g., an ISP, a corporation, or a
   home user.  Second, the popularity of corporate virtual private
   networks (VPN) in conjunction with NAT leads to problems in which the
   private IP address space of the Internet access network through which
   a remote client is attached may unintentionally conflict with the
   private IP address space of the corporate network into which the
   remote client is tunneled.  This document specifies best current
   practice recommendations for addressing each of these issues.

Internet Draft                                                   B. Ford
Document: draft-ford-behave-top-00.txt                            M.I.T.
Expires: July 2005                                          P. Srisuresh
                                                          Caymas Systems
                                                            January 2005

  Topological Complications from Network Address Translation (NAT-TOP)

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.  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

   Distribution of this document is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This document identifies and provides recommendations for dealing
   with several new issues that have arisen recently out the ubiquitous
   deployment of network address translators (NAT), and the
   unconventional network topologies that are often constructed with
   them.  First, the simplicity of configuring and administering
   networks through the combination of NAT and DHCP is increasingly
   leading to the deployment of multi-level hierarchies of
   interconnected private networks involving many overlapping private IP
   address spaces.  The creation of these multi-level hierarchies is
   often unintentional, since each level of NAT is typically deployed by

Ford                                                            [Page 1]

draft-ford-behave-top-00.txt                                January 2005

   a separate administrative entity: e.g., an ISP, a corporation, or a
   home user.  Second, the popularity of corporate virtual private
   networks (VPN) in conjunction with NAT leads to problems in which the
   private IP address space of the Internet access network through which
   a remote client is attached may unintentionally conflict with the
   private IP address space of the corporate network into which the
   remote client is tunneled.  This document specifies best current
   practice recommendations for addressing each of these issues.

Table of Contents

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

1. Introduction

   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.

Ford                                                            [Page 2]

draft-ford-behave-top-00.txt                                January 2005

      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 up a true
      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 it might
      in turn form its own auto-configured "downstream" IP subnet for
      which it provides its own DHCP service.  The fact that DHCP is
      only capable of auto-configuring client hosts, and is not capable
      of auto-configuring entire "client subnets", makes NAT a
      compelling solution in this common scenario.

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:

Ford                                                            [Page 3]

draft-ford-behave-top-00.txt                                January 2005

                               Main 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

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

Ford                                                            [Page 4]

draft-ford-behave-top-00.txt                                January 2005

   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 extremely 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 RFC specifically for this purpose.

   Out of the three incentives listed above for NAT deployment, the last
   two still apply even to customers of ISPs that use NAT, resulting in
   multi-level NAT toplogies 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 as usual.  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
   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.

Ford                                                            [Page 5]

draft-ford-behave-top-00.txt                                January 2005

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

   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, which 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 18.181.0.31, 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
   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 10.1.1.10.  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 155.99.25.1.  The NATs in effect serve as

Ford                                                            [Page 6]

draft-ford-behave-top-00.txt                                January 2005

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

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. Caveats with the Network

   (XXX This section is very rough and still needs a lot of work.)

   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 & NAT-4 are multi-homed on the same subnet(say,
   10.1.1/24). Yet, the subnet is disjoint on different LANs; and so the
   NATs are really not multi-homed.  This is an anomaly.

   NAT-3 is incapable of communicating reliably as a transport endpoint
   with other nodes on its adjacent networks 2 and 3 (e.g., for
   management purposes), unless its TCP/IP stack is capable of
   differentiating packets and communication sessions by the "side" or
   "port" they arrived from and not merely by 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, for example, then it may get a different
   response on each of its physical interfaces.  This is another
   anomaly.

Ford                                                            [Page 7]

draft-ford-behave-top-00.txt                                January 2005

   2) Broken as it already is, it could have been worse and non-
   functional if the network layout wasnt carefully orchestrated to
   work.

   For example, all external interfaces are supposed to be
   heirarchically arranged, so the outgoign path reaches the Internet
   facing NAT. The NAT device is assumed to be providing DHCP-service on
   the private interfaces and NAT service on the external interface. If
   the nodes are connected differently, chaos could ensue - imagine one
   of the NAT devices (say, NAT-3) having its private interface on
   network-2 and NAt interface on network 3.

   Chaos could 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
   woudl end up having the same IP address. That would make the network
   broken. The network can also be broken if two NAT nodes attempt 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 10.1.1.1 However below are some known caveats.

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

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

   What if ISP unwisely uses private RFC1918 IP addresses for its mail
   servers, etc., which need to be accessible to its customers?  Answer:
   bad things happen.

2.3. Recommendations

   (XXX needs a lot of work.)

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

Ford                                                            [Page 8]

draft-ford-behave-top-00.txt                                January 2005

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

   NAT boxes shoudl privide 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

   Typically, when an enterprise user has a secure remote-access VPN
   client installed on his/her PC, the VPN client installs a Virtual
   adapter (VA) on the PC. When the secure VPN is established with
   corporate office, the VA is assigned an IP address  from the
   corporate VPN-address pool. Subsequent to that, the routes on the PC
   are redone such that routes to all networks in the corporate network
   are redirected to the secure VPN, while leaving all other routes
   unchanged. Now, this becomes tricky when the corporate intranet
   network is built using RFC1918 address space. The employee may be
   accessing the corporate VPN either from his/her home office (or) a
   hotel (or) a customer site (or) a partner site. In other words, the
   employee's PC may already be located in a RFC1918 address space. So,
   when the VA is assigned an RC1918 address from the VPN server pool,
   there may be conflict with being able to route the packets correctly
   to the employee's corporate network.

Ford                                                            [Page 9]

draft-ford-behave-top-00.txt                                January 2005

                     (Corporate Private network 10.0.0.0/8)
            --------+---------------+------------+----------
                                    |
                                    |
                                 10.1.1.1
                            +---------------+
                            |               |
                            | Secure        |
                            | Remote Access |
                            | VPN Server    |
                            +------+--------+
                                   |
              {----+---------------+---------------}
              {                                    }
              {           Main Internet            }
              {        (public IP addresses)       }
              {                                    }
              {----+---------------+---------------}
                                   |
                             155.99.25.1
                            +----------------+
                            |    NAT         |
                            | (in a Hotel    |         +--------+
                            | or home office |         |        |
                            | or a partner's |         | DHCP   |
                            | corp. office   |         | Server |
                            |                |         |        |
                            +----------------+         +--------+
                               10.1.1.1                 10.1.1.2
                                   |                        |
          Remote Private Network   |                        |
       ----+-----------+-----------+-------------+----------+------
           |           |           |             |
           |           |           |             |
        10.1.1.10  10.1.1.11   10.1.1.12     10.1.1.13
         Host A    Host B      +--------+    Host C
                               | RA-VPN |
                               | Client |
                               | PC     |
                               +--------+

3.1. Operational Details of the Network

Ford                                                           [Page 10]

draft-ford-behave-top-00.txt                                January 2005

3.2. Caveats with the Network

3.3. Recommendations

   Clearly, the remote access VPN client works best when the external
   client IP address (on the ethernet NIC) does not overlap with the
   corporate  address space and the coporate VPN address pool. However,
   this cannot be assumed always.  Employees often need to work from
   within arbitrary private IP address spaces such as hotel rooms, which
   neither the employee nor the corporate network administrator has any
   control over.  In these situations, we advise the following to ensure
   proper operation of the Remote access VPN client.

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

   2. The corporate VPN resources that match the following entities in
      remote address space will not be permitted access from the remote
      access VPN client.  These are: a) client's external IP address, b)
      client's next-hop IP address, necessary to access the remote
      access VPN server from external interface, c) DHCP server on the
      remote network thatprovides address leases. In general, in orer to
      ensure continued availability of DHCP-server, any corporate
      network resource that overlaps the client's xternal IP address
      network is disallowed.  For example, if the PC's external NIC is
      configured with 10.1.1.1/24, corporate network that overlaps this
      is not accessible from the remote access VPN client.

   XXX The above recommendations prevent "network meltdown", but still
   do not guarantee that the remote employee will be able to access the
   nodes on the corporate network he needs to if there is address
   overlap.  Possible solutions:

   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 at least 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 can suggest that there be two IP address pools on the VPN
      server, so the address pool which is used for a VPN client doesnt
      ever conflict with the physical NIC's IP address.  For example,
      the VPN server might detect a conflict and inform the user that he

Ford                                                           [Page 11]

draft-ford-behave-top-00.txt                                January 2005

      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.

   4. Perhaps, if the VPN server identifed 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
      soemthing 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.

   5. Finally, the VPN-client could come in as bump in the stack and
      redirect all relevant packets in the subnet (with the exception of
      this that match with the router and DHCP server) over the VPN.
      This at least reduces the size of the "black hole" on the
      corporate network from a whole subnet to merely two IP addresses.

4. Security Considerations

References (XXX needs serious updating)

[BIDIR]    Peer-to-Peer Working Group, NAT/Firewall Working Committee,
           "Bidirectional Peer-to-Peer Communication with Interposing
           Firewalls and NATs", August 2001.
           http://www.peer-to-peerwg.org/tech/nat/

[ICE]      J. Rosenberg, "Interactive Connectivity Establishment (ICE):
           A Methodology for Network Address Translator (NAT) Traversal
           for the Session Initiation Protocol (SIP)",
           draft-rosenberg-sipping-ice-00 (Work In Progress),
           February 2003.

[IPSEC-NAT] B. Aboba and W. Dixon,
        "IPsec-Network Address Translation (NAT) Compatibility Requirements",
        RFC 3715, March 2004.

[KEGEL]    Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999.
           http://www.alumni.caltech.edu/~dank/peer-nat.html

[MIDCOM]   P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and
           A. Rayhan, "Middlebox communication architecture and
           framework", RFC 3303, August 2002.

Ford                                                           [Page 12]

draft-ford-behave-top-00.txt                                January 2005

[NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly
           Application Design Guidelines", RFC 3235, January 2002.

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

[RSIP]     M. Borella, J. Lo, D. Grabelsky, and G. Montenegro,
           "Realm Specific IP: Framework", RFC 3102, October 2001.

[SOCKS]    M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and
           L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.

[STUN]     J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy,
           "STUN - Simple Traversal of User Datagram Protocol (UDP)
           Through Network Address Translators (NATs)", RFC 3489,
           March 2003.

[SYM-STUN] Y. Takeda, "Symmetric NAT Traversal using STUN",
           draft-takeda-symmetric-nat-traversal-00.txt (Work In
           Progress), June 2003.

[TCP]      "Transmission Control Protocol", RFC 793, September 1981.

[TEREDO]   C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs",
           draft-ietf-ngtrans-shipworm-08.txt (Work In Progress),
           September 2002.

[TURN]     J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema,
           "Traversal Using Relay NAT (TURN)",
           draft-rosenberg-midcom-turn-01 (Work In Progress),
           March 2003.

[UPNP]     UPnP Forum, "Internet Gateway Device (IGD) Standardized
           Device Control Protocol V 1.0", November 2001.
           http://www.upnp.org/standardizeddcps/igd.asp

Ford                                                           [Page 13]

draft-ford-behave-top-00.txt                                January 2005

Author's Address

   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@xxxxxxx
   Web: http://www.brynosaurus.com/

   Pyda Srisuresh
   Caymas Systems, Inc.
   1179-A North McDowell Blvd.
   Petaluma, CA 94954
   U.S.A.
   Phone: (707) 283-5063
   E-mail: srisuresh@xxxxxxxxx

   Dan Kegel
   Kegel.com
   901 S. Sycamore Ave.
   Los Angeles, CA 90036
   Phone: (323) 931-6717
   E-mail: dank@xxxxxxxxx
   Web: http://www.kegel.com/

Full Copyright Statement

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

Ford                                                           [Page 14]

draft-ford-behave-top-00.txt                                January 2005

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Ford                                                           [Page 15]