doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc3234.txt b/doc/rfc/rfc3234.txt
new file mode 100644
index 0000000..5204991
--- /dev/null
+++ b/doc/rfc/rfc3234.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                       B. Carpenter
+Request for Comments: 3234                IBM Zurich Research Laboratory
+Category: Informational                                          S. Brim
+                                                           February 2002
+
+
+                    Middleboxes: Taxonomy and Issues
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document is intended as part of an IETF discussion about
+   "middleboxes" - 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 catalogue or taxonomy of middleboxes, cites previous
+   and current IETF work concerning middleboxes, and attempts to
+   identify some preliminary conclusions.  It does not, however, claim
+   to be definitive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Brim             Informational                      [Page 1]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+Table of Contents
+
+   1. Introduction and Goals.........................................  3
+   1.1. Terminology..................................................  3
+   1.2. The Hourglass Model, Past and Future.........................  3
+   1.4. Goals of this Document.......................................  4
+   2. A catalogue of middleboxes.....................................  5
+   2.1 NAT...........................................................  6
+   2.2 NAT-PT........................................................  7
+   2.3 SOCKS gateway.................................................  7
+   2.4 IP Tunnel Endpoints...........................................  8
+   2.5. Packet classifiers, markers and schedulers...................  8
+   2.6 Transport relay...............................................  9
+   2.7. TCP performance enhancing proxies............................ 10
+   2.8. Load balancers that divert/munge packets..................... 10
+   2.9. IP Firewalls................................................. 11
+   2.10. Application Firewalls....................................... 11
+   2.11. Application-level gateways.................................. 12
+   2.12. Gatekeepers/ session control boxes.......................... 12
+   2.13. Transcoders................................................. 12
+   2.14. Proxies..................................................... 13
+   2.15. Caches...................................................... 14
+   2.16. Modified DNS servers........................................ 14
+   2.17. Content and applications distribution boxes................. 15
+   2.18. Load balancers that divert/munge URLs....................... 16
+   2.19. Application-level interceptors.............................. 16
+   2.20. Application-level multicast................................. 16
+   2.21. Involuntary packet redirection.............................. 16
+   2.22. Anonymisers................................................. 17
+   2.23. Not included................................................ 17
+   2.24. Summary of facets........................................... 17
+   3. Ongoing work in the IETF and elsewhere......................... 18
+   4. Comments and Issues............................................ 19
+   4.1. The end to end principle under challenge..................... 19
+   4.2. Failure handling............................................. 20
+   4.3. Failures at multiple layers.................................. 21
+   4.4. Multihop application protocols............................... 21
+   4.5. Common features.............................................. 22
+   5. Security Considerations........................................ 22
+   6. Acknowledgements............................................... 23
+   7. References..................................................... 23
+   Authors' Addresses................................................ 26
+   Acknowledgement................................................... 26
+   Full Copyright Statement.......................................... 27
+
+
+
+
+
+
+
+Carpenter & Brim             Informational                      [Page 2]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+1. Introduction and Goals
+
+1.1. Terminology
+
+   The phrase "middlebox" was coined by Lixia Zhang as a graphic
+   description of a recent phenomenon in the Internet.  A middlebox is
+   defined as any intermediary device performing functions other than
+   the normal, standard functions of an IP router on the datagram path
+   between a source host and destination host.
+
+   In some discussions, especially those concentrating on HTTP traffic,
+   the word "intermediary" is used.  For the present document, we prefer
+   the more graphic phrase.  Of course, a middlebox can be virtual,
+   i.e., an embedded function of some other box.  It should not be
+   interpreted as necessarily referring to a separate physical box.  It
+   may be a device that terminates one IP packet flow and originates
+   another, or a device that transforms or diverts an IP packet flow in
+   some way, or a combination.  In any case it is never the ultimate
+   end-system of an applications session.
+
+   Normal, standard IP routing functions (i.e., the route discovery and
+   selection functions described in [RFC 1812], and their equivalent for
+   IPv6) are not considered to be middlebox functions; a standard IP
+   router is essentially transparent to IP packets.  Other functions
+   taking place within the IP layer may be considered to be middlebox
+   functions, but functions below the IP layer are excluded from the
+   definition.
+
+   There is some discrepancy in the way the word "routing" is used in
+   the community.  Some people use it in the narrow, traditional sense
+   of path selection based on IP address, i.e., the decision-making
+   action of an IP router.  Others use it in the sense of higher layer
+   decision-making (based perhaps on a URL or other applications layer
+   string).  In either case it implies a choice of outbound direction,
+   not the mere forwarding of a packet in the only direction available.
+   In this document, the traditional sense is always qualified as "IP
+   routing."
+
+1.2. The Hourglass Model, Past and Future
+
+   The classical description of the Internet architecture is based
+   around the hourglass model [HOURG] and the end-to-end principle
+   [Clark88, Saltzer].  The hourglass model depicts the protocol
+   architecture as a narrow-necked hourglass, with all upper layers
+   riding over a single IP protocol, which itself rides over a variety
+   of hardware layers.
+
+
+
+
+
+Carpenter & Brim             Informational                      [Page 3]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   The end-to-end principle asserts that some functions (such as
+   security and reliability) can only be implemented completely and
+   correctly end-to-end, with the help of the end points.  The end-to-
+   end principle notes that providing an incomplete version of such
+   functions in the network itself can sometimes be useful as a
+   performance enhancement, but not as a substitute for the end-to-end
+   implementation of the function.  The references above, and [RFC
+   1958], go into more detail.
+
+   In this architecture, the only boxes in the neck of the hourglass are
+   IP routers, and their only function is to determine routes and
+   forward packets (while also updating fields necessary for the
+   forwarding process).  This is why they are not classed as
+   middleboxes.
+
+   Today, we observe deviations from this model, caused by the insertion
+   in the network of numerous middleboxes performing functions other
+   than IP forwarding.  Viewed in one way, these boxes are a challenge
+   to the transparency of the network layer [RFC 2775].  Viewed another
+   way, they are a challenge to the hourglass model: although the IP
+   layer does not go away, middleboxes dilute its significance as the
+   single necessary feature of all communications sessions.  Instead of
+   concentrating diversity and function at the end systems, they spread
+   diversity and function throughout the network.
+
+   This is a matter of concern for several reasons:
+
+   *  New middleboxes challenge old protocols.  Protocols designed
+      without consideration of middleboxes may fail, predictably or
+      unpredictably, in the presence of middleboxes.
+
+   *  Middleboxes introduce new failure modes; rerouting of IP packets
+      around crashed routers is no longer the only case to consider.
+      The fate of sessions involving crashed middleboxes must also be
+      considered.
+
+   *  Configuration is no longer limited to the two ends of a session;
+      middleboxes may also require configuration and management.
+
+   *  Diagnosis of failures and misconfigurations is more complex.
+
+1.4. Goals of this Document
+
+   The principle goal of this document is to describe and analyse the
+   current impact of middleboxes on the architecture of the Internet and
+   its applications.  From this, we attempt to identify some general
+   conclusions.
+
+
+
+
+Carpenter & Brim             Informational                      [Page 4]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   Goals that might follow on from this work are:
+
+   *  to identify harmful and harmless practices,
+
+   *  to suggest architectural guidelines for application protocol and
+      middlebox design,
+
+   *  to identify requirements and dependencies for common functions in
+      the middlebox environment,
+
+   *  to derive a system design for standardisation of these functions,
+
+   *  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].
+
+   The document initially establishes a catalogue of middleboxes, and
+   cites previous or current IETF work concerning middleboxes, before
+   proceeding to discussion and conclusions.
+
+2. A catalogue of middleboxes
+
+   The core of this document is a catalogue of a number of types of
+   middlebox.  There is no obvious way of classifying them to form a
+   hierarchy or other simple form of taxonomy.  Middleboxes have a
+   number of facets that might be used to classify them in a
+   multidimensional taxonomy.
+
+   DISCLAIMER: These facets, many of distinctions between different
+   types of middlebox, and the decision to include or exclude a
+   particular type of device, are to some extent subjective.  Not
+   everyone who commented on drafts of this document agrees with our
+   classifications and descriptions.  We do not claim that the following
+   catalogue is mathematically complete and consistent, and in some
+   cases purely arbitrary choices have been made, or ambiguity remains.
+   Thus, this document makes no claim to be definitive.
+
+   The facets considered are:
+
+   1. Protocol layer.  Does the box act at the IP layer, the transport
+      layer, the upper layers, or a mixture?
+
+   2. Explicit versus implicit.  Is the middlebox function an explicit
+      design feature of the protocol(s) in use, like an SMTP relay? Or
+      is it an add-on not foreseen by the protocol design, probably
+      attempting to be invisible, like a network address translator?
+
+
+
+Carpenter & Brim             Informational                      [Page 5]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   3. Single hop versus multi-hop.  Can there be only one box in the
+      path, or can there be several?
+
+   4. In-line versus call-out.  The middlebox function may be executed
+      in-line on the datapath, or it may involve a call-out to an
+      ancillary box.
+
+   5. Functional versus optimising.  Does the box perform a function
+      without which the application session cannot run, or is the
+      function only an optimisation?
+
+   6. Routing versus processing.  Does the box simply choose which way
+      to send the packets of a session, or does it actually process them
+      in some way (i.e., change them or create a side-effect)?
+
+   7. Soft state versus hard state.  If the box loses its state
+      information, does the session continue to run in a degraded mode
+      while reconstructing necessary state (soft state), or does it
+      simply fail (hard state)?
+
+   8. Failover versus restart.  In the event that a hard state box
+      fails, is the session redirected to an alternative box that has a
+      copy of the state information, or is it forced to abort and
+      restart?
+
+   One possible classification is deliberately excluded: "good" versus
+   "evil".  While analysis shows that some types of middlebox come with
+   a host of complications and disadvantages, no useful purpose would be
+   served by simply deprecating them.  They have been invented for
+   compelling reasons, and it is instructive to understand those
+   reasons.
+
+   The types of box listed below are in an arbitrary order, although
+   adjacent entries may have some affinity.  At the end of each entry is
+   an attempt to characterise it in terms of the facets identified
+   above.  These characterisations should not be interpreted as rigid;
+   in many cases they are a gross simplification.
+
+   Note: many types of middlebox may need to perform IP packet
+   fragmentation and re-assembly.  This is mentioned only in certain
+   cases.
+
+2.1 NAT
+
+   Network Address Translator.  A function, often 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 & Brim             Informational                      [Page 6]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   translated on the fly.  Because NAT is incompatible with application
+   protocols with IP address dependencies, a NAT is in practice always
+   accompanied by an ALG (Application Level Gateway - see below).  It
+   also touches the transport layer to the extent of fixing up
+   checksums.
+
+   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
+   [RSIP].
+
+   {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+   processing, 7 hard, 8 restart}
+
+2.2 NAT-PT
+
+   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.
+
+   NAT-PT itself depends on the Stateless IP/ICMP Translation Algorithm
+   (SIIT) mechanism [RFC 2765] for its protocol translation function.
+   In practice, SIIT and NAT-PT will both need an associated ALG and
+   will need to touch transport checksums.  Due to the permitted absence
+   of a UDP checksum in IPv4, translation of fragmented unchecksummed
+   UDP from IPv4 to IPv6 is hopeless.  NAT-PT and SIIT also have other
+   potential fragmentation/MTU problems, particularly when dealing with
+   endpoints that don't do path MTU discovery (or when transiting other
+   middleboxes that break path MTU discovery).  ICMP translation also
+   has some intractable difficulties.
+
+   NAT-PT is a Proposed Standard from the NGTRANS WG [RFC 2766].  The
+   Dual Stack Transition Mechanism adds a second related middlebox, the
+   DSTM server [DSTM].
+
+   {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+   processing, 7 hard, 8 restart}
+
+2.3 SOCKS gateway
+
+   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 source IP address and port number used outside the firewall.  The
+
+
+
+Carpenter & Brim             Informational                      [Page 7]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   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.
+
+   {1 multi-layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6
+   routing, 7 hard, 8 restart}
+
+2.4 IP Tunnel Endpoints
+
+   Tunnel endpoints, including virtual private network endpoints, use
+   basic IP services to set up tunnels with their peer tunnel endpoints
+   which might be anywhere in the Internet.  Tunnels create entirely new
+   "virtual" networks and network interfaces based on the Internet
+   infrastructure, and thereby open up a number of new services.  Tunnel
+   endpoints base their forwarding decisions at least partly on their
+   own policies, and only partly if at all on information visible to
+   surrounding routers.
+
+   To the extent that they deliver packets intact to their destinations,
+   tunnel endpoints appear to follow the end-to-end principle in the
+   outer Internet.  However, the destination may be completely different
+   from what a router near the tunnel entrance might expect.  Also, the
+   per-hop treatment a tunneled packet receives, for example in terms of
+   QoS, may not be what it would have received had the packet traveled
+   untunneled [RFC2983].
+
+   Tunnels also cause difficulties with MTU size (they reduce it) and
+   with ICMP replies (they may lack necessary diagnostic information).
+
+   When a tunnel fails for some reason, this may cause the user session
+   to abort, or an alternative IP route may prove to be available, or in
+   some cases the tunnel may be re-established automatically.
+
+   {1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+   processing, 7 hard, 8 restart or failover}
+
+2.5. Packet classifiers, markers and schedulers
+
+   Packet classifiers classify packets flowing through them according to
+   policy and either select them for special treatment or mark them, in
+   particular for differentiated services [Clark95, RFC 2475].  They may
+   alter the sequence of packet flow through subsequent hops, since they
+   control the behaviour of traffic conditioners.
+
+
+
+
+
+
+Carpenter & Brim             Informational                      [Page 8]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   Schedulers or traffic conditioners (in routers, hosts, or specialist
+   boxes inserted in the data path) may alter the time sequence of
+   packet flow, the order in which packets are sent, and which packets
+   are dropped.  This can significantly impact end-to-end performance.
+   It does not, however, fundamentally change the unreliable datagram
+   model of the Internet.
+
+   When a classifier or traffic conditioner fails, the user session may
+   see any result between complete loss of connectivity (all packets are
+   dropped), through best-effort service (all packets are given default
+   QOS), up to automatic restoration of the original service level.
+
+   {1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6
+   processing, 7 soft, 8 failover or restart}
+
+2.6 Transport relay
+
+   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 well 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 IP routing configurations.  TLGs are also
+   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 middlebox, 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
+
+
+
+
+Carpenter & Brim             Informational                      [Page 9]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   this problem is not unique to middleboxes, but can also be caused by
+   checksum offloading TCP implementations within the sender, for
+   example.
+
+   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.
+
+   {1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 functional
+   (mainly), 6 routing, 7 hard, 8 restart}
+
+2.7. TCP performance enhancing proxies
+
+   "TCP spoofer" is often used as a term for middleboxes 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.
+
+   {1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising,
+   6 routing, 7 hard, 8 restart}
+
+2.8. Load balancers that divert/munge packets.
+
+   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
+   split applications across servers by IP routing based 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.
+
+
+
+Carpenter & Brim             Informational                     [Page 10]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   {1 multi-layer, 2 implicit, 3 single hop, 4 in-line, 5 optimising, 6
+   routing, 7 hard, 8 restart}
+
+2.9. IP Firewalls
+
+   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].
+
+   Although a pure IP firewall does not alter the packets flowing
+   through it, by rejecting some of them it may cause connectivity
+   problems that are very hard for a user to understand and diagnose.
+
+   "Stateless" firewalls typically allow all IP fragments through since
+   they do not contain enough upper-layer header information to make a
+   filtering decision.  Many "stateful" firewalls therefore reassemble
+   IP fragments (and re-fragment if necessary) in order to avoid leaking
+   fragments, particularly fragments that may exploit bugs in the
+   reassembly implementations of end receivers.
+
+   {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+   routing, 7 hard, 8 restart}
+
+2.10. Application Firewalls
+
+   Application-level firewalls act as a protocol end point and relay
+   (e.g., an 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].
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 11]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   {1 Application layer, 2 implicit, 3 multihop, 4 in-line, 5
+   functional, 6 processing, 7 hard, 8 restart}
+
+2.11. Application-level gateways
+
+   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
+   the sessions they are handling, and if this state is lost, the
+   session will normally break irrevocably.
+
+   Some ALGs are also implemented in ways that create fragmentation
+   problems, although in this case the problem is arguably the result of
+   a deliberate layer violation (e.g., mucking with the application data
+   stream of an FTP control connection by twiddling TCP segments on the
+   fly).
+
+   {1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line,
+   5 functional, 6 processing, 7 hard, 8 restart}
+
+2.12. Gatekeepers/ session control boxes
+
+   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].
+
+   {1 Application layer, 2 explicit, 3 multihop, 4 in-line or call-out,
+   5 functional, 6 processing, 7 hard, 8 restart?}
+
+2.13. Transcoders
+
+   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.  In many cases, 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.
+
+
+
+Carpenter & Brim             Informational                     [Page 12]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   Not all media translators are mandatory.  They may simply be an
+   optimisation.  For example, in the case of multicast, if all the
+   low-bandwidth receivers sit in one "corner" of the network, 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.
+
+   {1 Application layer, 2 explicit or implicit, 3 single hop, 4 in-
+   line, 5 functional, 6 processing, 7 hard?, 8 restart or failover}
+
+2.14. Proxies
+
+   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."
+
+   A Web proxy may be associated with a firewall, 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.
+
+   Note that HTTP proxies do in fact terminate an IP packet flow and
+   recreate another one, but they fall under the definition of
+   "middlebox" given in Section 1.1 because the actual applications
+   sessions traverse them.
+
+   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
+   travel end-to-end but to a designated intermediate box.)
+
+   {1 Application layer, 2 explicit (HTTP) or implicit (interception), 3
+   multihop, 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}.
+
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 13]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   Note: Some so-called Web 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
+   caused confusion by mis-describing these as "transparent" proxies.
+   Interception devices are anything but transparent.  See [WREC] for a
+   full discussion.
+
+2.15. Caches
+
+   Caches are of course used in many shapes and forms in the Internet,
+   and are in principle distinct from proxies.  Here we refer mainly to
+   content 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 transient content, particularly in
+   transactional applications.  HTTP caching is well described in
+   Section 13 of [RFC 2616], and in the HTTP case caches and proxies are
+   inextricably mixed.
+
+   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].
+
+   It can be argued that caches terminate the applications sessions, and
+   should not be counted as middleboxes (any more than we count SMTP
+   relays).  However, we have arbitrarily chosen to include them since
+   they do in practice re-issue the client's HTTP request in the case of
+   a cache miss, and they are not the ultimate source of the application
+   data.
+
+   {1 Application layer, 2 explicit (if HTTP proxy caches), 3 multihop,
+   4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}
+
+2.16. Modified DNS servers
+
+   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
+
+
+
+
+Carpenter & Brim             Informational                     [Page 14]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   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").
+
+   Modified DNS servers are not intermediaries in the application data
+   flow of interest.  They are included here because they mean that
+   independent sessions that at one level appear to involve a single
+   host actually involve multiple hosts, which can have subtle effects.
+   State created in host A.FOR.EXAMPLE by one session may turn out not
+   to be there when a second session apparently to the same host is
+   started, because the DNS server has directed the second session
+   elsewhere.
+
+   If such a DNS server fails, users may fail over to an alternate DNS
+   server that doesn't know the same tricks, with unpredicatble results.
+
+   {1 Application layer, 2 implicit, 3 multihop, 4 in-line (on DNS query
+   path), 5 functional or optimising, 6 processing, 7 soft, 8 failover}
+
+2.17. Content and applications distribution boxes
+
+   An emerging generalisation of caching is content distribution and
+   application distribution.  In this model, content (such as static web
+   content or streaming 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 a system of middleboxes - 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.
+
+   As with caches, it is an arbitrary choice to include these devices,
+   on the grounds that although they terminate the client session, they
+   are not the ultimate origin of the applications data.
+
+   {1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line
+   or call-out, 5 optimising, 6 routing or processing, 7 soft, 8
+   restart?}
+
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 15]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+2.18. Load balancers that divert/munge URLs
+
+   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 rewrite HTTP
+   requests to direct them to a particular member of a pool of servers.
+
+   These devices are included as middleboxes because they divert an
+   applications session in an arbitrary way.
+
+   {1 Application layer, 2 explicit, 3 single hop, 4 in-line, 5
+   functional, 6 routing, 7 soft, 8 restart}
+
+2.19. Application-level interceptors
+
+   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).  Like any non-standard proxy, it has
+   undefined consequences in the case of dynamic or non-cacheable
+   content.
+
+   {1 Application layer, 2 implicit, 3 single hop, 4 in-line, 5
+   functional or optimising, 6 routing, 7 hard, 8 restart}
+
+2.20. Application-level multicast
+
+   Some (mainly proprietary) applications, including some approaches to
+   instant messaging, use an application-level mechanism to replicate
+   packets to multiple destinations.
+
+   An example is given in [CHU].
+
+   {1 Application layer, 2 explicit, 3 multihop, 4 in-line, 5
+   functional, 6 routing, 7 hard, 8 restart}
+
+2.21. Involuntary packet redirection
+
+   There appear to be a few instances of boxes that (based on
+   application level content or other information above the network
+   layer) redirect 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 usually also perform NAT functions.
+
+
+
+
+Carpenter & Brim             Informational                     [Page 16]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   {1 multi-layer, 2 implicit, 3 single hop, 4 call-out, 5 functional, 6
+   routing, 7 hard, 8 restart}
+
+2.22. Anonymisers
+
+   Anonymiser boxes can be implemented in various ways that hide the IP
+   address of the data sender or receiver.  Although the implementation
+   may be distinct, this is in practice very similar to a NAT plus ALG.
+
+   {1 multi-layer, 2 implicit or explicit, 3 multihop, 4 in-line, 5
+   functional, 6 processing, 7 hard, 8 restart}
+
+2.23. Not included
+
+   Some candidates suggested for the above list were excluded for the
+   reasons given below.  In general, they do not fundamentally change
+   the architectural model of packet delivery from source to
+   destination.
+
+   Bridges and switches that snoop ARP, IGMP etc.  These are below the
+   IP layer, but use a layer violation to emulate network layer
+   functions.  They do not change IP layer functions.
+
+   Wiretaps and snoopers in general - if they are working correctly,
+   they have no impact on traffic, so do not require analysis.
+
+   Mobile IP home agents are intended to assist packet delivery to the
+   originally desired destination, so they are excluded on the same
+   grounds as standard routers.
+
+   Relays in interplanetary networks - although these would certainly
+   appear to be middleboxes, they are not currently deployed.
+
+2.24. Summary of facets
+
+   By tabulating the rough classifications above, we observe that of the
+   22 classes of middlebox described:
+
+   17 are application or multi-layer
+   16 are implicit (and others are explicit OR implicit)
+   17 are multi-hop
+   21 are in-line; call-out is rare
+   18 are functional; pure optimisation is rare
+   Routing & processing are evenly split
+   16 have hard state
+   21 must restart session on failure
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 17]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   We can deduce that current types of middlebox are predominantly
+   application layer devices not designed as part of the relevant
+   protocol, performing required functions, maintaining hard state, and
+   aborting user sessions when they crash.  Indeed this represents a
+   profound challenge to the end-to-end hourglass model.
+
+3. Ongoing work in the IETF and elsewhere
+
+   Apart from work cited in references above, current or planned work in
+   the IETF includes:
+
+   MIDCOM - a working group with focus on the architectural framework
+   and the requirements for the protocol between a requesting device and
+   a middlebox and the architectural framework for the interface between
+   a middlebox and a policy entity [MIDFRAME, MIDARCH].  This may
+   interact with session control issues [SIPFIRE].
+
+   Work is also proceeding outside the MIDCOM group on middlebox
+   discovery [MIDDISC].
+
+   WEBI (Web Intermediaries) - a working group that addresses 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.
+
+   Intermediaries are also an important focus in the development of XML
+   Protocol by the World-Wide Web Consortium, who have published an
+   interesting analysis [XMLPI].
+
+   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.
+
+   CDI (Content Distribution Internetworking) is a potential working
+   group for allowing cooperation between different Content Distribution
+   Networks and cache clusters [CDNP].
+
+   RSERPOOL (Reliable Server Pooling) is a 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 & Brim             Informational                     [Page 18]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+4. Comments and Issues
+
+   A review of the list in Section 2 suggests that middleboxes fit into
+   one or more of three broad categories:
+
+   1) mechanisms to connect dissimilar networks to enable cross-protocol
+      interoperability;
+
+   2) mechanisms to separate similar networks into zones, especially
+      security zones;
+
+   3) performance enhancement.
+
+   As observed in [RFC 2775], the rise of middleboxes puts into question
+   the general applicability of the end-to-end principle [RFC 1958].
+   Middleboxes introduce dependencies and hidden 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 middleboxes?
+
+4.1. The end to end principle under challenge
+
+   Many forms of middlebox are explicitly addressed at the 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 middleboxes that divert an
+   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 involuntary packet redirectors.
+   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.
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 19]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   We conclude that:
+
+      Although the rise of middleboxes has negative impact on the end to
+      end principle at the packet level, it does not nullify it as a
+      useful or desirable principle of applications protocol design.
+      However, future application protocols should be designed in
+      recognition of the likely presence of network address translation,
+      packet diversion, and packet level firewalls, along the data path.
+
+4.2. Failure handling
+
+   If a middlebox 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" middleboxes 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" middleboxes must be present for the session
+   to continue, so they are candidates for rapid failover or rapid
+   restart mechanisms.  We conclude that:
+
+      Middlebox design should include a clear mechanism for dealing with
+      failure.
+
+
+
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 20]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+4.3. Failures at multiple layers
+
+   Difficulties occur when middlebox functions occur at different
+   layers, for example the following situation, where B and C are not in
+   the same physical box:
+
+      Apps layer:     A ------------------------> C ------> D
+
+      Lower layer:    A -----> B -------------------------> D
+
+   When all is well, i.e., there is an IP path from A to B to C to D and
+   both B and C are working, this may appear quite workable.  But the
+   failure modes are very challenging.  For example, if there is a
+   network failure between C and D, how is B instructed to divert the
+   session to a backup box for C?.  Since C and B function at different
+   protocol layers, there is no expectation that they will have
+   coordinated failure recovery mechanisms.  Unless this is remedied in
+   some general way, we conclude that
+
+      Middlebox failure recovery mechanisms cannot currently assume they
+      will get any help from other layers, and must have their own means
+      of dealing with failures in other layers.
+
+      In the long term future, we should be able to state clearly for
+      each middlebox function what it expects from its environment, and
+      make recommendations about which middlebox functions should be
+      bound together if deployed.
+
+4.4. Multihop application protocols
+
+   We can also observe that protocols such as SMTP, UUCP, and NNTP have
+   always worked hop-by-hop, i.e., via multiple middleboxes.  Nobody
+   considers this to be an issue or a problem.  Difficulties arise when
+   inserting a middlebox in an application protocol stream that was not
+   designed for it.  We conclude that:
+
+      New application protocol designs should include explicit
+      mechanisms for the insertion of middleboxes, and should consider
+      the facets identified in Section 2 above as part of the design.
+
+   A specific challenge is how to make interactive or real-time
+   applications ride smoothly over middleboxes.  This will put
+   particular stress on the failure handling aspects.
+
+
+
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 21]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+4.5. Common features
+
+   Given that the IP layer - the neck of the hourglass - is no longer
+   alone in its role supporting end-to-end connectivity, it would be
+   desirable to define requirements and features that are common to
+   middlebox intermediaries.  It would then be possible to implement
+   middleboxes, and in particular the protocols that communicate with
+   them, fully from the stance of supporting the end-to-end principle.
+   Conceptually, this would extend the neck of the hourglass upwards to
+   include a set of common features available to all (or many)
+   applications.  In the context of middleboxes and multihop protocols,
+   this would require common features addressing at least:
+
+      Middlebox discovery and monitoring
+      Middlebox configuration and control
+      Call-out
+      Routing preferences
+      Failover and restart handling
+      Security, including mutual authentication
+
+   As far as possible, the solutions in these areas being developed in
+   the IETF and W3C should be sufficiently general to cover all types of
+   middlebox; if not, the work will be done several times.
+
+5. Security Considerations
+
+   Security risks are specific to each type of middlebox, 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
+   middlebox design requires particular attention to security analysis.
+   A few general points can be made:
+
+   1. The interference with end-to-end packet transmission by many types
+      of middlebox is a crippling impediment to generalised use of IPSEC
+      in its present form, and also invalidates transport layer security
+      in many scenarios.
+
+   2. Middleboxes require us to move definitively from a two-way to an
+      N-way approach to trust relationships and key sharing.
+
+   3. The management and configuration mechanisms of middleboxes are a
+      tempting point of attack, and must be strongly defended.
+
+   These points suggest that we need a whole new approach to security
+   solutions as the middlebox paradigm ends up being deployed in lots of
+   different technologies, if only to avoid each new technology
+
+
+
+Carpenter & Brim             Informational                     [Page 22]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   designing a end-to-end security solution appropriate to its
+   particular impact on the data stream.
+
+   Additionally, 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 required.
+
+6. Acknowledgements
+
+   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, and Rob
+   Austein made other substantial contributions.  Participants in the
+   MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including
+   Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker,
+   Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen,
+   Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave
+   invaluable input.  Mark Nottingham brought the W3C work to our
+   attention.  Melinda Shore suggested using a facet-based
+   categorization.  Patrik Faltstrom inspired section 4.3.
+
+7. References
+
+   [RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
+              1812, June 1995.
+
+   [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and
+              L. Jones, "SOCKS Protocol Version 5", March 1996.
+
+   [RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
+              RFC 1958, June 1996.
+
+   [RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
+              version 2", RFC 2186, September 1997.
+
+   [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
+              and W. Weiss, "An Architecture for Differentiated
+              Service", RFC 2475, December 1998.
+
+   [RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
+              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
+              March 1999.
+
+   [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+
+
+Carpenter & Brim             Informational                     [Page 23]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations", RFC
+              2663, August 1999.
+
+   [RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
+              (HTCP/0.0)", RFC 2756, January 2000.
+
+   [RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+              Translation - Protocol Translation (NAT-PT)", RFC 2766,
+              February 2000.
+
+   [RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February
+              2000.
+
+   [RFC 2979] Freed, N., "Behavior of and Requirements for Internet
+              Firewalls", RFC 2979, October 2000.
+
+   [RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
+              2983, October 2000.
+
+   [RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
+              November 2000.
+
+   [RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.
+              and J. Segers, "Megaco Protocol 1.0", RFC 3015, November
+              2000.
+
+   [RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
+              Address Translator (Traditional NAT)", RFC 3022, January
+              2001.
+
+   [RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
+              with the IP Network Address Translator", RFC 3027, January
+              2001.
+
+   [CHU]      Y. Chu, S. Rao, and H. Zhang, A Case for End System
+              Multicast, SIGMETRICS, June 2000.
+              http://citeseer.nj.nec.com/chu00case.html
+
+   [CLARK88]  The Design Philosophy of the DARPA Internet Protocols,
+              D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4,
+              August 1988, pages 106-114 (reprinted in ACM CCR Vol 25,
+              Number 1, January 1995, pages 102-111).
+
+   [CLARK95]  "Adding Service Discrimination to the Internet", D.D.
+              Clark, Proceedings of the 23rd Annual Telecommunications
+              Policy Research Conference (TPRC), Solomons, MD, October
+              1995.
+
+
+
+Carpenter & Brim             Informational                     [Page 24]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   [CDNP]     M. Day, et al., "A Model for Content Internetworking
+              (CDI)", Work in Progress.
+
+   [DSTM]     J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A.
+              Durand, "Dual Stack Transition Mechanism (DSTM)", Work in
+              Progress.
+
+   [H323]     ITU-T Recommendation H.323: "Packet Based Multimedia
+              Communication Systems".
+
+   [HOURG]    "Realizing the Information Future: The Internet and
+              Beyond", Computer Science and Telecommunications Board,
+              National Research Council, Washington, D.C., National
+              Academy Press, 1994. However, the "hourglass" metaphor was
+              first used by John Aschenbrenner in 1979, with reference
+              to the ISO Open Systems Interconnection model.
+
+   [HTTPSUB]  Moore, K., "On the use of HTTP as a Substrate", BCP 56,
+              RFC 3205, February 2002.
+
+   [MIDARCH]  E. Lear, "A Middlebox Architectural Framework", Work in
+              Progress.
+
+   [MIDDISC]  E. Lear, "Requirements for Discovering Middleboxes", Work
+              in Progress.
+
+   [MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A.
+              Rayhan, "Middlebox Communication: Framework and
+              Requirements", Work in Progress.
+
+   [PILCPEP]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
+              Shelby, "Performance Enhancing Proxies Intended to
+              Mitigate Link-Related Degradations", RFC 3135, June 2001.
+
+   [RSIP]     Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
+              "Realm Specific IP: Framework", RFC 3102, October 2001.
+
+   [SALTZER]  End-To-End Arguments in System Design, J.H. Saltzer,
+              D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November
+              1984, pp 277-288.
+
+   [SIPFIRE]  S. Moyer, D. Marples, S. Tsang, J. Katz, P. Gurung, T.
+              Cheng, A. Dutta, H. Schulzrinne, A. Roychowdhury,
+              "Framework Draft for Networked Appliances Using the
+              Session Initiation Protocol", Work in Progress.
+
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 25]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+   [SOCKS6]   Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
+              RFC 3089, April 2001.
+
+   [TRANS64]  "Overview of Transition Techniques for IPv6-only to Talk
+              to IPv4-only Communication", Work in Progress.
+
+   [WREC]     Cooper, I, Melve, I. and G. Tomlinson, "Internet Web
+              Replication and Caching Taxonomy", RFC 3040, January 2001.
+
+   [XMLPI]    Intermediaries and XML Protocol, Mark Nottingham, Work in
+              Progress at http://lists.w3.org/Archives/Public/xml-dist-
+              app/2001Mar/0045.html
+
+Authors' Addresses
+
+   Brian E. Carpenter
+   IBM Zurich Research Laboratory
+   Saeumerstrasse 4 / Postfach
+   8803 Rueschlikon
+   Switzerland
+
+   EMail: brian@hursley.ibm.com
+
+
+   Scott W. Brim
+   146 Honness Lane
+   Ithaca, NY 14850
+   USA
+
+   EMail: sbrim@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 26]
+
+RFC 3234            Middleboxes: Taxonomy and Issues       February 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Brim             Informational                     [Page 27]
+