rfc3234.txt

RFC 的详细文档！

      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.