rfc3234.txt

RFC 的详细文档！

   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