rfc3234.txt

RFC 的详细文档！

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