IETF                                                        B. Carpenter
Internet Draft
January 2001

                   Middle boxes: taxonomy and issues

                             Copyright Notice

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



   This document is intended as input to IETF discussion about "middle
   boxes" - defined as any intermediary box performing functions apart
   from normal, standard functions of an IP router on the data path
   between a source host and destination host.  This document
   establishes a taxonomy of middle boxes, cites previous or current
   IETF work concerning middle boxes, and attempts to identify issues
   and areas where further work is necessary.

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   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-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

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

Carpenter                  Expires July 2001                    [Page 1]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   Table of Contents:

      Status of this Memo.............................................1
      1. Introduction.................................................3
      2. Taxonomy.....................................................3
      2.1 Network and transport level.................................3
      2.1.1 NAT (functional)..........................................3
      2.1.2 NAT-PT (functional).......................................4
      2.1.3 SOCKS gateway (functional)................................4
      2.1.4 Transport relay (functional)..............................4
      2.1.5 TCP performance enhancing proxies (optimising)............5
      2.1.6 Load balancers that divert/munge packets (optimising).....5
      2.1.7 Firewalls (1) (functional)................................6
      2.2 Application level...........................................6
      2.2.1 Firewalls (2) (functional)................................6
      2.2.2 Application-level gateways (functional)...................6
      2.2.3 Gatekeepers/ session control boxes (functional)...........7
      2.2.4 Transcoders (functional)..................................7
      2.2.5 Proxies (functional)......................................7
      2.2.6 Caches (optimising).......................................8
      2.2.7 Tricky DNS servers (functional)...........................8
      2.2.8 Content and applications distribution boxes (optimising)..9
      2.2.9 Load balancers that divert/munge URLs (optimising)........9
      2.2.10 Application-level interceptors (functional/optimising)...9
      2.2.11 Application-level multicast (functional).................9
      2.2.12 Packet hijackers (functional)...........................10
      2.2.12 Anonymisers (functional)................................10
      3. Ongoing work................................................10
      4. Comments and Issues.........................................11
      5. Security considerations.....................................12
      6. Acknowledgements............................................12
      7. References..................................................13
      Authors' Addresses.............................................14
      Full Copyright Statement.......................................14

Carpenter                  Expires July 2001                    [Page 2]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

1. Introduction

   This document is intended as input to IETF discussion about "middle
   boxes" - defined as any intermediary box performing functions apart
   from normal, standard functions of an IP router on the data path
   between a source host and destination host.

   The goals of such discussion, not necessarily covered by this
   document, include:

   * To analyze issues raised by the growth of middle boxes in the Internet
   * To identify harmful and harmless practices.
   * To suggest architectural guidelines.
   * To identify additional work that should be done in the IETF and IRTF.

   An implied goal is to identify any necessary updates to the
   Architectural Principles of the Internet [RFC 1958].

   This document establishes a taxonomy of middle boxes, cites previous
   or current IETF work concerning middle boxes, and attempts to
   identify issues and areas where further work is necessary.

2. Taxonomy

   For presentation purposes, the types of middle box listed below are
   split into those principally located in the transport or network
   layers, and those principally located in the application layer.
   However, this distinction is far from rigid and in some cases the two
   classes are inextricably mixed.

   Another dimension of taxonomy is whether a box is primarily intended
   to optimise performance (an optimising box), or whether it is
   primarily intended to execute a specific function that neither of the
   end systems can perform (a functional box).

   It's also noteworthy that certain protocols are specifically oriented
   towards multi-hop operation, and therefore architecturally require
   middle boxes. Some of these boxes, such as mail or news relays, have
   been with us for a long time.

2.1 Network and transport level

2.1.1 NAT (functional)

   Network Address Translator. A function, normally built into a router,
   that dynamically assigns a globally unique address to a host that
   doesn't have one, without that host's knowledge. As a result, the
   appropriate address field in all packets to and from that host is

Carpenter                  Expires July 2001                    [Page 3]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   translated on the fly. Because NAT is incompatible with application
   protocols with address dependencies, a NAT is always accompanied by
   an ALG (see below).

   NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993,
   RFC 3022, RFC 3027, etc.]

   The experimental RSIP proposal complements NAT with a dynamic tunnel
   mechanism inserting a stateful RSIP server in place of the NAT

2.1.2 NAT-PT (functional)

   NAT with Protocol Translator. A function, normally built into a
   router, that performs NAT between an IPv6 host and an IPv4 network,
   additionally translating the entire IP header between IPv6 and IPv4
   formats. Also requires an ALG.

   NAT-PT is a Proposed Standard from the NGTRANS WG [RFC 2766]. The
   Dual Stack Transition Mechanism adds a second related middle box, the
   DSTM server [DSTM].

2.1.3 SOCKS gateway (functional)

   SOCKSv5 [RFC 1928] is a stateful mechanism for authenticated firewall
   traversal, in which the client host must communicate first with the
   SOCKS server in the firewall before it is able to traverse the
   firewall. It is the SOCKS server, not the client, that determines the
   IP address and port number used outside the firewall. The client's
   stack must be "SOCKSified" to take account of this, and address-
   sensitive applications may get confused, rather as with NAT. However,
   SOCKS gateways do not require ALGs.

   SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.

2.1.4 Transport relay (functional)

   Transport relays are basically the transport layer equivalent of an
   ALG; another (less common) name for them is a TLG.  As with ALGs,
   they're used for a variety of purposes, some very established and
   meeting needs not otherwise met.  Early examples of transport relays
   were those that ran on MIT's ITS and TOPS-20 PDP-10s on the ARPANET
   and allowed Chaosnet-only hosts to make outgoing connections from
   Chaosnet onto TCP/IP.  Later there were some uses of TCP-TP4 relays.
   A transport relay between IPv6-only and IPv4-only hosts is one of the
   tools of IPv6 transition [TRANS64].  TLGs are sometimes used in
   combination with simple packet filtering firewalls to enforce
   restrictions on which hosts can talk to the outside world or to
   kludge around strange routing configurations.  TLGs are also

Carpenter                  Expires July 2001                    [Page 4]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   sometimes used to gateway between two instances of the same transport
   protocol with significantly different connection characteristics; it
   is in this sense that a TLG may also be called a TCP or transport
   spoofer.  In this role, the TLG may shade into being an optimising
   rather than a functional middle box, but it is distinguished from
   Transport Proxies (next section) by the fact that it makes its
   optimisations only by creating back-to- back connections, and not by
   modification or re-timing of TCP messages.

   Terminating one TCP connection and starting another mid-path means
   that the TCP checksum does not cover the sender's data end-to-end.
   Data corruptions or modifications may be introduced in the processing
   when the data is transferred from the first to the second connection.
   Some TCP relays are split relays and have even more possibility of
   lost data integrity, because the there may be more than two TCP
   connections, and multiple nodes and network paths involved.  In all
   cases, the sender has less than the expected assurance of data
   integrity that is the TCP reliable byte stream service.  Note that
   this problem is not unique to middle boxes, but can also be caused by
   checksum offloading TCP implementations within the sender, for

   In some such cases, other session layer mechanisms such as SSH or
   HTTPS would detect any loss of data integrity at the TCP level,
   leading not to retransmission as with TCP, but to session failure.
   However, there is no general session mechanism to add application
   data integrity so one can detect or mitigate possible lack of TCP
   data integrity.

2.1.5 TCP performance enhancing proxies (optimising)

   "TCP spoofer" is often used as a term for middle boxes that modify
   the timing or action of the TCP protocol in flight for the purposes
   of enhancing performance.  Another, more accurate name is TCP
   performance enhancing proxy (PEP). Many TCP PEPs are proprietary and
   have been characterised in the open Internet primarily when they
   introduce interoperability errors with standard TCP.  As with TLGs,
   there are circumstances in which a TCP PEP is seen to meet needs not
   otherwise met.  For example, a TCP PEP may provide re-spacing of ACKs
   that have been bunched together by a link with bursty service, thus
   avoiding undesireable data segment bursts.  The PILC (Performance
   Implications of Link Characteristics) working group has analyzed
   types of TCP PEPs and their applicability [PILCPEP].  TCP PEPs can
   introduce not only TCP errors, but also unintended changes in TCP
   adaptive behavior.

2.1.6 Load balancers that divert/munge packets (optimising).

   There is a variety of techniques that divert packets from their
   intended IP destination, or make that destination ambiguous.  The
   motivation is typically to balance load across servers, or even to

Carpenter                  Expires July 2001                    [Page 5]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   split applications across servers by effectively routing on the
   destination port number. Except for rare instances of one-shot UDP
   protocols, these techniques are inevitably stateful as all packets
   from the same application session need to be directed to the same
   physical server. (However, a sophisticated solution would also be
   able to handle failover.)

   To date these techniques are proprietary and can therefore only be
   applied in closely managed environments.

2.1.7 Firewalls (1) (functional)

   The simplest form of firewall is a router that screens and rejects
   packets based purely on  fields in the IP and Transport headers (e.g.
   disallow incoming traffic to certain port numbers, disallow any
   traffic to certain subnets, etc.)

   Although firewalls have not been the subject of standardisation, some
   analysis has been done [RFC 2979].

2.2 Application level

2.2.1 Firewalls (2) (functional)

   Application-level firewalls act as a protocol end point and relay
   (e.g., a SMTP client/server or a Web proxy agent). They may

       (1)   implement a "safe" subset of the protocol,
       (2)   perform extensive protocol validity checks,
       (3)   use an implementation methodology designed to minimize
             the likelihood of bugs,
       (4)   run in an insulated, "safe" environment, or
       (5)   use some combination of these techniques in tandem.

   Although firewalls have not been the subject of standardisation, some
   analysis has been done [RFC 2979]. The issue of firewall traversal
   using HTTP has been discussed [HTTPSUB].

2.2.2 Application-level gateways (functional)

   These come in many shapes and forms. NATs require ALGs for certain
   address-dependent protocols such as FTP; these do not change the
   semantics of the application protocol, but carry out mechanical
   substitution of fields. At the other end of the scale, still using
   FTP as an example, gateways have been constructed between FTP and
   other file transfer protocols such as the OSI and DECnet (R)
   equivalents. In any case, such gateways need to maintain state for

Carpenter                  Expires July 2001                    [Page 6]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   the sessions they are handling, and if this state is lost, the
   session will normally break irrevocably.

2.2.3 Gatekeepers/ session control boxes (functional)

   Particularly with the rise of IP Telephony, the need to create and
   manage sessions other than TCP connections has arisen.  In a
   multimedia environment that has to deal with name lookup,
   authentication, authorization, accounting, firewall traversal, and
   sometimes media conversion, the establishment and control of a
   session by a third-party box seems to be the inevitable solution.
   Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543] and
   MEGACO controllers [RFC 3015].

2.2.4 Transcoders (functional)

   Transcoders are boxes performing some type of on-the-fly conversion
   of application level data. Examples include the transcoding of
   existing web pages for display on hand-held wireless devices, and
   transcoding between various audio formats for interconnecting digital
   mobile phones with voice-over-IP services. By definition, such
   transcoding cannot be done by the end-systems, and at least in the
   case of voice, it must be done in strict real time with extremely
   rapid failure recovery.

   Not all media translators are mandatory. They may just be useful in
   case of multicast, for example, where all the low-bandwidth receivers
   sit in one "corner" of the network and it would be inefficient for
   the sender to generate two streams or send both stream all the way
   across the network if the "thin" one is only needed far away from the
   sender.  Generally, media translators are only useful if the two end
   systems don't have overlapping codecs or if the overlapping set is
   not a good network match.

2.2.5 Proxies (functional)

   HTTP1.1 [RFC 2616] defines a Web proxy as follows:

      "An intermediary program which acts as both a server and a client
       for the purpose of making requests on behalf of other clients.
       Requests are serviced internally or by passing them on, with
       possible translation, to other servers. A proxy MUST implement
       both the client and server requirements of this specification. A
       "transparent proxy" is a proxy that does not modify the request or
       response beyond what is required for proxy authentication and
       identification. A "non-transparent proxy" is a proxy that modifies
       the request or response in order to provide some added service to
       the user agent, such as group annotation services, media type
       transformation, protocol reduction, or anonymity filtering. "

Carpenter                  Expires July 2001                    [Page 7]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   The function of a transparent proxy is essentially firewall traversal
   when the firewall does not allow outgoing HTTP packets. However, HTTP
   makes the use of a proxy "voluntary": the client must be configured
   to use the proxy. Some proxies have been implemented as
   "interception" devices that intercept HTTP packets and re-issue them
   with their own source address; like NAT and SOCKs, this can disturb
   address-sensitive applications. Unfortunately some vendors have lied
   by describing these as "transparent" proxies. Interception devices
   are anything but transparent. See [WREC] for a full discussion.

   SIP proxies [RFC 2543] also raise some interesting issues, since they
   can "bend" the media pipe to also serve as media translators. (A
   proxy can modify the session description so that media no longer
   travels end-to-end but to a designated intermediate box.)

2.2.6 Caches (optimising)

   Caches are of course used in many shapes and forms in the Internet.
   Here we refer only to HTTP caches, intended to optimise user response
   times. HTTP makes provision for proxies to act as caches, by
   providing for both expiration and re-validation mechanisms for cached
   content. These mechanisms may be used to guarantee that specific
   content is not cached, which is a requirement for dynamically
   generated content, particularly in transactional applications. HTTP
   caching is well described in Section 13 of [RFC 2616].

   To improve optimisation, caching is not uniquely conducted between
   the origin server and the proxy cache directly serving the user. If
   there is a network of caches, the nearest copy of the required
   content may be in a peer cache. For this an inter-cache protocol is
   required. At present the most widely deployed solution is Internet
   Cache Protocol (ICP) [RFC 2186] although there have been alternative
   proposals such as [RFC 2756].

2.2.7 Tricky DNS servers (functional)

   DNS servers can play games. As long as they appear to deliver a
   syntactically correct response to every query, they can fiddle the
   semantics. For example, names can be made into "anycast" names by
   arranging for them to resolve to different IP addresses in different
   parts of the network. Or load can be shared among different members
   of a server farm by having the local DNS server return the address of
   different servers in turn. In a NAT environment, it is not uncommon
   for the FQDN-to-address mapping to be quite different outside and
   inside the NAT ("two-faced DNS").

   Tricky DNS servers are not strictly middle boxes in the sense of
   interfering with a packet stream, but because they mean that
   independent sessions that at one level appear to involve a single
   host actually involve multiple hosts, they can have subtle effects.
   State created in host A.FOR.EXAMPLE by one session may turn out not

Carpenter                  Expires July 2001                    [Page 8]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   to be there when a second session apparently to the same host is

2.2.8 Content and applications distribution boxes (optimising)

   An emerging generalisation of caching is content distribution and
   application distribution. In this model, content (such as static web
   content or multimedia content) is replicated in advance to many
   widely distributed servers. Further, interactive or even
   transactional applications may be remotely replicated, with some of
   their associated data. Since this is a recent model, it cannot be
   said that there is an industry standard practice in this area. Some
   of the issues are discussed in [WREC] and several new IETF activities
   have been proposed in this area.

   Content distribution solutions tend to play with URLs in one way or
   another, and often involve more than one middle box - for example
   using HTTP redirects to send a request for WWW.EXAMPLE.COM off to
   WWW.EXAMPLE.NET, where the latter name may be an "anycast" name as
   mentioned above, and will actually resolve in DNS to the nearest
   instance of a content distribution box.

2.2.9 Load balancers that divert/munge URLs (optimising)

   Like DNS tricks, URL redirects can be used to balance load among a
   pool of servers - essentially a local version of a content
   distribution network. Alternatively, an HTTP proxy can massage HTTP
   requests to direct them to a particular member of a pool of servers.

2.2.10 Application-level interceptors (functional/optimising)

   Some forms of pseudo-proxy intercept HTTP packets and deliver them to
   a local proxy server instead of forwarding them to the intended
   destination. Thus the destination IP address in the packet is
   ignored. It is hard to state whether this is a functional box (i.e. a
   non-standard proxy) or an optimising box (i.e. a way of forcing the
   user to use a cache). In any case it has undefined consequences in
   the case of dynamic or non-cacheable content.

2.2.11 Application-level multicast (functional)

   Some (mainly proprietary) applications, including some approaches to
   instant messaging, use an application-level mechanism to replicate
   packets to multiple destinations.

Carpenter                  Expires July 2001                    [Page 9]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

2.2.12 Packet hijackers (functional)

   There appear to be a few instances of boxes that (based on
   application level content) hijack packets for functional reasons. For
   example, more than one "high speed Internet" service offered in hotel
   rooms intercepts initial HTTP requests and diverts them to an HTTP
   server that demands payment before opening access to the Internet.
   These boxes also perform NAT functions.

2.2.12 Anonymisers (functional)

   Anonymiser boxes can be implemented in various ways that hide the IP
   address of the data sender or receiver.

3. Ongoing work

   Apart from work cited in references above, current or planned work in
   the IETF includes:

   MIDCOM - a new working group with focus on the architectural
   framework and the requirements for the protocol between a requesting
   device and a middle box and the architectural framework for the
   interface between a middle box and a policy entity [MIDFRAME,
   MIDARCH]. This may interact with session control issues [SIPFIRE].

   WEBI - a new working group that will address specific issues in the
   world wide web infrastructure (as identified by the WREC working
   group), by providing generic mechanisms which are useful in several
   application domains (e.g., proxies, content delivery surrogates).
   Specific mechanisms will be Intermediary Discovery and Description
   and a Resource Update Protocol.

   OPES (Open Pluggable Extension Services) - a proposed  working group
   whose output will enable construction of services executed on
   application data by participating transit intermediaries.  Caching is
   the most basic intermediary service, one that requires a basic
   understanding of application semantics by the cache server.

   CDNP (Content Distribution Internetworking) - a potential working
   group [CNDP].

   RSERPOOL (Reliable Server Pooling) is a recently established working
   group that will define architecture and requirements for management
   and access to server pools, including requirements from a variety of
   applications, building blocks and interfaces, different styles of
   pooling, security requirements and performance requirements, such as
   failover times and coping with heterogeneous latencies.

Carpenter                  Expires July 2001                   [Page 10]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

4. Comments and Issues

   As observed in [RFC 2775], the rise of middle boxes puts into
   question the general applicability of the end-to-end principle [RFC
   1958].  Middle boxes introduce dependencies and hidden single points
   of failure that violate the fate-sharing aspect of the end-to-end
   principle.  Can we define architectural principles that guarantee
   robustness in the presence of middle boxes?

   In particular, if a middle box fails, it is desirable that the effect
   on sessions currently in progress should be inconvenient rather than
   catastrophic. There appear to be three approaches to achieve this:

   * soft state mechanisms. The session continues in the absence of
     the box, probably with reduced performance, until the necessary
     session state is recreated automatically in an alternative box
     (or the original one, restarted). In other words the state
     information optimises the user session but is not essential.
     An example might be a true caching mechanism, whose temporary
     failure only reduces performance.

   * rapid failover mechanisms. The session is promptly redirected
     to a hot spare box, which already has a copy of the necessary
     session state.

   * rapid restart mechanisms. The two ends of the session promptly
     detect the failure and themselves restart the session via a spare
     box, without being externally redirected. Enough session state
     is kept at each end to recover from the glitch.

   It appears likely that "optimising" middle boxes are suitable
   candidates for the soft state approach and for non-real-time data
   streams, since the consequence of failure of the box is not
   catastrophic for the user.  (Configured HTTP proxies used as caches
   are an awkward case, as their failure causes client failure.)  On the
   other hand, "functional" middle boxes must be present for the session
   to continue, so they are candidates for rapid failover or rapid
   restart mechanisms.

   We can also observe that messaging protocols such as SMTP, uucp, NNTP
   or proprietary reliable messaging protocols have always worked hop-
   by-hop, i.e. via multiple middle boxes. Nobody considers this to be
   an issue or a problem. The challenge is really how to make
   interactive or real-time applications ride over middle boxes as
   smoothly as messaging protocols have done for many years.

   Many forms of middle box are explicitly addressed at IP level, and
   terminate a transport connection (or act as a final destination for
   UDP packets) in a normal way. Although they are potential single
   points of failure, they do not otherwise interfere with the end to
   end principle [RFC 1958]. (This statement does not apply to transport
   relays or TCP spoofers; they do not terminate a transport connection
   at the expected destination in the normal way.)

   However, there is a general feeling that middle boxes that divert an

Carpenter                  Expires July 2001                   [Page 11]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   IP packet from its intended destination, or substantively modify its
   content on the fly, are fundamentally different from those that
   correctly terminate a transport connection and carry out their
   manipulations at applications level. Such diversion or modification
   violates the basic architectural assumption that packets flow from
   source to destination essentially unchanged (except for time-to-live
   and QOS-related fields). The effects of such changes on transport and
   applications is unpredictable in the general case. Much of the
   analysis that applies to NAT [RFC 2993, RFC 3027] will also apply to
   RSIP, NAT-PT, DSTM, SOCKS, and packet hijackers. Interception
   proxies, anonymisers, and some types of load balancer can also have
   subtle effects on address-sensitive applications, when they cause
   packets to be delivered to or from a different address.  Transport
   relays and TCP spoofers may deceive applications by delivering an
   unreliable service on a TCP socket.

   Do we need the routing system to export topology information to an
   application level routing framework, so that application level
   routing and load balancers don't have to cheat?

   What are the characteristics of a sound middle box design? ...of an
   unsound middle box design?

   From the taxonomy and existing work, what are the gaps and unstudied

5. Security considerations

   Security risks are specific to each type of middle box, so little can
   be said in general. Of course, adding extra boxes in the
   communication path creates extra points of attack, reduces or
   eliminates the ability to perform end to end encryption, and
   complicates trust models and key distribution models. Thus, every
   middle box design requires particular attention to security analysis.

   Content caches and content distribution mechanisms raise the issue of
   access control for content that is subject to copyright or other
   rights. Distributed authentication, authorisation and accounting are

6. Acknowledgements

   Rob Austein, Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik
   Faltstrom, Henning Schulzrinne, and Lixia Zhang all gave valuable
   feedback on early versions of this document. Rob Austein and Allison
   Mankin drafted the text on transport relays and TCP spoofers.

Carpenter                  Expires July 2001                   [Page 12]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

7. References

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

   [RFC 1958] Architectural Principles of the Internet. B. Carpenter.
   June 1996.

   [RFC 2186] Internet Cache Protocol (ICP), version 2. D. Wessels, K.
   Claffy.  September 1997.

   [RFC 2543] SIP: Session Initiation Protocol. M. Handley, H.
   Schulzrinne, E.  Schooler, J. Rosenberg. March 1999.

   [RFC 2616] Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J.
   Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.
   June 1999.

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

   [RFC 2756] Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D.
   Wessels.  January 2000.

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

   [RFC 2775] Internet Transparency. B. Carpenter. February 2000.

   [RFC 2979] Behavior of and Requirements for Internet Firewalls. N.
   Freed.  October 2000.

   [RFC 2993] Architectural Implications of NAT. T. Hain. November 2000.

   [RFC 3015] Megaco Protocol 1.0. F. Cuervo, N. Greene, A. Rayhan, C.
   Huitema, B. Rosen, J. Segers. November 2000.

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

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

   [CNDP] A Model for CDN Peering, draft-day-cdnp-model-04.txt, work in

   [DSTM] Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-
   dstm-03.txt, work in progress.

   [H323] ITU-T Recommendation H.323: "Packet Based Multimedia
   Communication Systems".

   [HTTPSUB] On the use of HTTP as a Substrate for Other Protocols,
   draft-moore-using-http-01.txt, work in progress.

Carpenter                  Expires July 2001                   [Page 13]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   [MIDARCH] A Middle Box Architectural Framework, draft-lear-
   middlebox-arch-00.txt, work in progress.

   [MIDFRAME] Middlebox Communication: Framework and Requirements,
   draft-kuthan-midcom-framework-00.txt, work in progress.

   [PILCPEP] Performance Enhancing Proxies, draft-ietf-pilc-pep-05.txt,
   work in progress.

   [RSIP] Realm Specific IP: Framework, draft-ietf-nat-rsip-framework-
   05.txt, work in progress

   [SIPFIRE] Framework Draft for Networked Appliances Using the Session
   Initiation Protocol, draft-moyer-sip-appliances-framework-01.txt,.ps,
   work in progress.

   [SOCKS6] A SOCKS-based IPv6/IPv4 Gateway Mechanism, draft-ietf-
   ngtrans-socks-gateway-05.txt, work in progress.

   [TRANS64] Overview of Transition Techniques for IPv6-only to Talk to
   IPv4-only Communication, draft-ietf-ngtrans-translator-03.txt, work
   in progress.

   [WREC] Internet Web Replication and Caching Taxonomy, draft-ietf-
   wrec-taxonomy-05.txt, work in progress.

Authors' Addresses

      Brian E. Carpenter
      iCAIR, Suite 150
      1890 Maple Avenue
      Evanston IL 60201, USA


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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

Carpenter                  Expires July 2001                   [Page 14]

Internet Draft     Middle boxes: taxonomy and issues        January 2001

   followed, or as required to translate it into languages other than

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

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Carpenter                  Expires July 2001                   [Page 15]