IETF B. Carpenter Internet Draft January 2001 Middle boxes: taxonomy and issues Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract draft-carpenter-midtax-00.txt This document is intended as input to IETF discussion about "middle boxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a taxonomy of middle boxes, cites previous or current IETF work concerning middle boxes, and attempts to identify issues and areas where further work is necessary. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Carpenter Expires July 2001 [Page 1] Internet Draft Middle boxes: taxonomy and issues January 2001 Table of Contents: Status of this Memo.............................................1 1. Introduction.................................................3 2. Taxonomy.....................................................3 2.1 Network and transport level.................................3 2.1.1 NAT (functional)..........................................3 2.1.2 NAT-PT (functional).......................................4 2.1.3 SOCKS gateway (functional)................................4 2.1.4 Transport relay (functional)..............................4 2.1.5 TCP performance enhancing proxies (optimising)............5 2.1.6 Load balancers that divert/munge packets (optimising).....5 2.1.7 Firewalls (1) (functional)................................6 2.2 Application level...........................................6 2.2.1 Firewalls (2) (functional)................................6 2.2.2 Application-level gateways (functional)...................6 2.2.3 Gatekeepers/ session control boxes (functional)...........7 2.2.4 Transcoders (functional)..................................7 2.2.5 Proxies (functional)......................................7 2.2.6 Caches (optimising).......................................8 2.2.7 Tricky DNS servers (functional)...........................8 2.2.8 Content and applications distribution boxes (optimising)..9 2.2.9 Load balancers that divert/munge URLs (optimising)........9 2.2.10 Application-level interceptors (functional/optimising)...9 2.2.11 Application-level multicast (functional).................9 2.2.12 Packet hijackers (functional)...........................10 2.2.12 Anonymisers (functional)................................10 3. Ongoing work................................................10 4. Comments and Issues.........................................11 5. Security considerations.....................................12 6. Acknowledgements............................................12 7. References..................................................13 Authors' Addresses.............................................14 Full Copyright Statement.......................................14 Acknowledgement................................................15 Carpenter Expires July 2001 [Page 2] Internet Draft Middle boxes: taxonomy and issues January 2001 1. Introduction This document is intended as input to IETF discussion about "middle boxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. The goals of such discussion, not necessarily covered by this document, include: * To analyze issues raised by the growth of middle boxes in the Internet infrastructure. * To identify harmful and harmless practices. * To suggest architectural guidelines. * To identify additional work that should be done in the IETF and IRTF. An implied goal is to identify any necessary updates to the Architectural Principles of the Internet [RFC 1958]. This document establishes a taxonomy of middle boxes, cites previous or current IETF work concerning middle boxes, and attempts to identify issues and areas where further work is necessary. 2. Taxonomy For presentation purposes, the types of middle box listed below are split into those principally located in the transport or network layers, and those principally located in the application layer. However, this distinction is far from rigid and in some cases the two classes are inextricably mixed. Another dimension of taxonomy is whether a box is primarily intended to optimise performance (an optimising box), or whether it is primarily intended to execute a specific function that neither of the end systems can perform (a functional box). It's also noteworthy that certain protocols are specifically oriented towards multi-hop operation, and therefore architecturally require middle boxes. Some of these boxes, such as mail or news relays, have been with us for a long time. 2.1 Network and transport level 2.1.1 NAT (functional) Network Address Translator. A function, normally built into a router, that dynamically assigns a globally unique address to a host that doesn't have one, without that host's knowledge. As a result, the appropriate address field in all packets to and from that host is Carpenter Expires July 2001 [Page 3] Internet Draft Middle boxes: taxonomy and issues January 2001 translated on the fly. Because NAT is incompatible with application protocols with address dependencies, a NAT is always accompanied by an ALG (see below). NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993, RFC 3022, RFC 3027, etc.] The experimental RSIP proposal complements NAT with a dynamic tunnel mechanism inserting a stateful RSIP server in place of the NAT [RSIP]. 2.1.2 NAT-PT (functional) NAT with Protocol Translator. A function, normally built into a router, that performs NAT between an IPv6 host and an IPv4 network, additionally translating the entire IP header between IPv6 and IPv4 formats. Also requires an ALG. NAT-PT is a Proposed Standard from the NGTRANS WG [RFC 2766]. The Dual Stack Transition Mechanism adds a second related middle box, the DSTM server [DSTM]. 2.1.3 SOCKS gateway (functional) SOCKSv5 [RFC 1928] is a stateful mechanism for authenticated firewall traversal, in which the client host must communicate first with the SOCKS server in the firewall before it is able to traverse the firewall. It is the SOCKS server, not the client, that determines the IP address and port number used outside the firewall. The client's stack must be "SOCKSified" to take account of this, and address- sensitive applications may get confused, rather as with NAT. However, SOCKS gateways do not require ALGs. SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG. 2.1.4 Transport relay (functional) Transport relays are basically the transport layer equivalent of an ALG; another (less common) name for them is a TLG. As with ALGs, they're used for a variety of purposes, some very established and meeting needs not otherwise met. Early examples of transport relays were those that ran on MIT's ITS and TOPS-20 PDP-10s on the ARPANET and allowed Chaosnet-only hosts to make outgoing connections from Chaosnet onto TCP/IP. Later there were some uses of TCP-TP4 relays. A transport relay between IPv6-only and IPv4-only hosts is one of the tools of IPv6 transition [TRANS64]. TLGs are sometimes used in combination with simple packet filtering firewalls to enforce restrictions on which hosts can talk to the outside world or to kludge around strange routing configurations. TLGs are also Carpenter Expires July 2001 [Page 4] Internet Draft Middle boxes: taxonomy and issues January 2001 sometimes used to gateway between two instances of the same transport protocol with significantly different connection characteristics; it is in this sense that a TLG may also be called a TCP or transport spoofer. In this role, the TLG may shade into being an optimising rather than a functional middle box, but it is distinguished from Transport Proxies (next section) by the fact that it makes its optimisations only by creating back-to- back connections, and not by modification or re-timing of TCP messages. Terminating one TCP connection and starting another mid-path means that the TCP checksum does not cover the sender's data end-to-end. Data corruptions or modifications may be introduced in the processing when the data is transferred from the first to the second connection. Some TCP relays are split relays and have even more possibility of lost data integrity, because the there may be more than two TCP connections, and multiple nodes and network paths involved. In all cases, the sender has less than the expected assurance of data integrity that is the TCP reliable byte stream service. Note that this problem is not unique to middle boxes, but can also be caused by checksum offloading TCP implementations within the sender, for 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. 2.1.5 TCP performance enhancing proxies (optimising) "TCP spoofer" is often used as a term for middle boxes that modify the timing or action of the TCP protocol in flight for the purposes of enhancing performance. Another, more accurate name is TCP performance enhancing proxy (PEP). Many TCP PEPs are proprietary and have been characterised in the open Internet primarily when they introduce interoperability errors with standard TCP. As with TLGs, there are circumstances in which a TCP PEP is seen to meet needs not otherwise met. For example, a TCP PEP may provide re-spacing of ACKs that have been bunched together by a link with bursty service, thus avoiding undesireable data segment bursts. The PILC (Performance Implications of Link Characteristics) working group has analyzed types of TCP PEPs and their applicability [PILCPEP]. TCP PEPs can introduce not only TCP errors, but also unintended changes in TCP adaptive behavior. 2.1.6 Load balancers that divert/munge packets (optimising). There is a variety of techniques that divert packets from their intended IP destination, or make that destination ambiguous. The motivation is typically to balance load across servers, or even to Carpenter Expires July 2001 [Page 5] Internet Draft Middle boxes: taxonomy and issues January 2001 split applications across servers by effectively routing on the destination port number. Except for rare instances of one-shot UDP protocols, these techniques are inevitably stateful as all packets from the same application session need to be directed to the same physical server. (However, a sophisticated solution would also be able to handle failover.) To date these techniques are proprietary and can therefore only be applied in closely managed environments. 2.1.7 Firewalls (1) (functional) The simplest form of firewall is a router that screens and rejects packets based purely on fields in the IP and Transport headers (e.g. disallow incoming traffic to certain port numbers, disallow any traffic to certain subnets, etc.) Although firewalls have not been the subject of standardisation, some analysis has been done [RFC 2979]. 2.2 Application level 2.2.1 Firewalls (2) (functional) Application-level firewalls act as a protocol end point and relay (e.g., a SMTP client/server or a Web proxy agent). They may (1) implement a "safe" subset of the protocol, (2) perform extensive protocol validity checks, (3) use an implementation methodology designed to minimize the likelihood of bugs, (4) run in an insulated, "safe" environment, or (5) use some combination of these techniques in tandem. Although firewalls have not been the subject of standardisation, some analysis has been done [RFC 2979]. The issue of firewall traversal using HTTP has been discussed [HTTPSUB]. 2.2.2 Application-level gateways (functional) These come in many shapes and forms. NATs require ALGs for certain address-dependent protocols such as FTP; these do not change the semantics of the application protocol, but carry out mechanical substitution of fields. At the other end of the scale, still using FTP as an example, gateways have been constructed between FTP and other file transfer protocols such as the OSI and DECnet (R) equivalents. In any case, such gateways need to maintain state for Carpenter Expires July 2001 [Page 6] Internet Draft Middle boxes: taxonomy and issues January 2001 the sessions they are handling, and if this state is lost, the session will normally break irrevocably. 2.2.3 Gatekeepers/ session control boxes (functional) Particularly with the rise of IP Telephony, the need to create and manage sessions other than TCP connections has arisen. In a multimedia environment that has to deal with name lookup, authentication, authorization, accounting, firewall traversal, and sometimes media conversion, the establishment and control of a session by a third-party box seems to be the inevitable solution. Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543] and MEGACO controllers [RFC 3015]. 2.2.4 Transcoders (functional) Transcoders are boxes performing some type of on-the-fly conversion of application level data. Examples include the transcoding of existing web pages for display on hand-held wireless devices, and transcoding between various audio formats for interconnecting digital mobile phones with voice-over-IP services. By definition, such transcoding cannot be done by the end-systems, and at least in the case of voice, it must be done in strict real time with extremely rapid failure recovery. Not all media translators are mandatory. They may just be useful in case of multicast, for example, where all the low-bandwidth receivers sit in one "corner" of the network and it would be inefficient for the sender to generate two streams or send both stream all the way across the network if the "thin" one is only needed far away from the sender. Generally, media translators are only useful if the two end systems don't have overlapping codecs or if the overlapping set is not a good network match. 2.2.5 Proxies (functional) HTTP1.1 [RFC 2616] defines a Web proxy as follows: "An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. " Carpenter Expires July 2001 [Page 7] Internet Draft Middle boxes: taxonomy and issues January 2001 The function of a transparent proxy is essentially firewall traversal when the firewall does not allow outgoing HTTP packets. However, HTTP makes the use of a proxy "voluntary": the client must be configured to use the proxy. Some proxies have been implemented as "interception" devices that intercept HTTP packets and re-issue them with their own source address; like NAT and SOCKs, this can disturb address-sensitive applications. Unfortunately some vendors have lied by describing these as "transparent" proxies. Interception devices are anything but transparent. See [WREC] for a full discussion. SIP proxies [RFC 2543] also raise some interesting issues, since they can "bend" the media pipe to also serve as media translators. (A proxy can modify the session description so that media no longer travels end-to-end but to a designated intermediate box.) 2.2.6 Caches (optimising) Caches are of course used in many shapes and forms in the Internet. Here we refer only to HTTP caches, intended to optimise user response times. HTTP makes provision for proxies to act as caches, by providing for both expiration and re-validation mechanisms for cached content. These mechanisms may be used to guarantee that specific content is not cached, which is a requirement for dynamically generated content, particularly in transactional applications. HTTP caching is well described in Section 13 of [RFC 2616]. To improve optimisation, caching is not uniquely conducted between the origin server and the proxy cache directly serving the user. If there is a network of caches, the nearest copy of the required content may be in a peer cache. For this an inter-cache protocol is required. At present the most widely deployed solution is Internet Cache Protocol (ICP) [RFC 2186] although there have been alternative proposals such as [RFC 2756]. 2.2.7 Tricky DNS servers (functional) DNS servers can play games. As long as they appear to deliver a syntactically correct response to every query, they can fiddle the semantics. For example, names can be made into "anycast" names by arranging for them to resolve to different IP addresses in different parts of the network. Or load can be shared among different members of a server farm by having the local DNS server return the address of different servers in turn. In a NAT environment, it is not uncommon for the FQDN-to-address mapping to be quite different outside and inside the NAT ("two-faced DNS"). Tricky DNS servers are not strictly middle boxes in the sense of interfering with a packet stream, but because they mean that independent sessions that at one level appear to involve a single host actually involve multiple hosts, they can have subtle effects. State created in host A.FOR.EXAMPLE by one session may turn out not Carpenter Expires July 2001 [Page 8] Internet Draft Middle boxes: taxonomy and issues January 2001 to be there when a second session apparently to the same host is started. 2.2.8 Content and applications distribution boxes (optimising) An emerging generalisation of caching is content distribution and application distribution. In this model, content (such as static web content or multimedia content) is replicated in advance to many widely distributed servers. Further, interactive or even transactional applications may be remotely replicated, with some of their associated data. Since this is a recent model, it cannot be said that there is an industry standard practice in this area. Some of the issues are discussed in [WREC] and several new IETF activities have been proposed in this area. Content distribution solutions tend to play with URLs in one way or another, and often involve more than one middle box - for example using HTTP redirects to send a request for WWW.EXAMPLE.COM off to WWW.EXAMPLE.NET, where the latter name may be an "anycast" name as mentioned above, and will actually resolve in DNS to the nearest instance of a content distribution box. 2.2.9 Load balancers that divert/munge URLs (optimising) Like DNS tricks, URL redirects can be used to balance load among a pool of servers - essentially a local version of a content distribution network. Alternatively, an HTTP proxy can massage HTTP requests to direct them to a particular member of a pool of servers. 2.2.10 Application-level interceptors (functional/optimising) Some forms of pseudo-proxy intercept HTTP packets and deliver them to a local proxy server instead of forwarding them to the intended destination. Thus the destination IP address in the packet is ignored. It is hard to state whether this is a functional box (i.e. a non-standard proxy) or an optimising box (i.e. a way of forcing the user to use a cache). In any case it has undefined consequences in the case of dynamic or non-cacheable content. 2.2.11 Application-level multicast (functional) Some (mainly proprietary) applications, including some approaches to instant messaging, use an application-level mechanism to replicate packets to multiple destinations. Carpenter Expires July 2001 [Page 9] Internet Draft Middle boxes: taxonomy and issues January 2001 2.2.12 Packet hijackers (functional) There appear to be a few instances of boxes that (based on application level content) hijack packets for functional reasons. For example, more than one "high speed Internet" service offered in hotel rooms intercepts initial HTTP requests and diverts them to an HTTP server that demands payment before opening access to the Internet. These boxes also perform NAT functions. 2.2.12 Anonymisers (functional) Anonymiser boxes can be implemented in various ways that hide the IP address of the data sender or receiver. 3. Ongoing work Apart from work cited in references above, current or planned work in the IETF includes: MIDCOM - a new working group with focus on the architectural framework and the requirements for the protocol between a requesting device and a middle box and the architectural framework for the interface between a middle box and a policy entity [MIDFRAME, MIDARCH]. This may interact with session control issues [SIPFIRE]. WEBI - a new working group that will address specific issues in the world wide web infrastructure (as identified by the WREC working group), by providing generic mechanisms which are useful in several application domains (e.g., proxies, content delivery surrogates). Specific mechanisms will be Intermediary Discovery and Description and a Resource Update Protocol. OPES (Open Pluggable Extension Services) - a proposed working group whose output will enable construction of services executed on application data by participating transit intermediaries. Caching is the most basic intermediary service, one that requires a basic understanding of application semantics by the cache server. CDNP (Content Distribution Internetworking) - a potential working group [CNDP]. RSERPOOL (Reliable Server Pooling) is a recently established working group that will define architecture and requirements for management and access to server pools, including requirements from a variety of applications, building blocks and interfaces, different styles of pooling, security requirements and performance requirements, such as failover times and coping with heterogeneous latencies. Carpenter Expires July 2001 [Page 10] Internet Draft Middle boxes: taxonomy and issues January 2001 4. Comments and Issues As observed in [RFC 2775], the rise of middle boxes puts into question the general applicability of the end-to-end principle [RFC 1958]. Middle boxes introduce dependencies and hidden single points of failure that violate the fate-sharing aspect of the end-to-end principle. Can we define architectural principles that guarantee robustness in the presence of middle boxes? In particular, if a middle box fails, it is desirable that the effect on sessions currently in progress should be inconvenient rather than catastrophic. There appear to be three approaches to achieve this: * soft state mechanisms. The session continues in the absence of the box, probably with reduced performance, until the necessary session state is recreated automatically in an alternative box (or the original one, restarted). In other words the state information optimises the user session but is not essential. An example might be a true caching mechanism, whose temporary failure only reduces performance. * rapid failover mechanisms. The session is promptly redirected to a hot spare box, which already has a copy of the necessary session state. * rapid restart mechanisms. The two ends of the session promptly detect the failure and themselves restart the session via a spare box, without being externally redirected. Enough session state is kept at each end to recover from the glitch. It appears likely that "optimising" middle boxes are suitable candidates for the soft state approach and for non-real-time data streams, since the consequence of failure of the box is not catastrophic for the user. (Configured HTTP proxies used as caches are an awkward case, as their failure causes client failure.) On the other hand, "functional" middle boxes must be present for the session to continue, so they are candidates for rapid failover or rapid restart mechanisms. We can also observe that messaging protocols such as SMTP, uucp, NNTP or proprietary reliable messaging protocols have always worked hop- by-hop, i.e. via multiple middle boxes. Nobody considers this to be an issue or a problem. The challenge is really how to make interactive or real-time applications ride over middle boxes as smoothly as messaging protocols have done for many years. Many forms of middle box are explicitly addressed at IP level, and terminate a transport connection (or act as a final destination for UDP packets) in a normal way. Although they are potential single points of failure, they do not otherwise interfere with the end to end principle [RFC 1958]. (This statement does not apply to transport relays or TCP spoofers; they do not terminate a transport connection at the expected destination in the normal way.) However, there is a general feeling that middle boxes that divert an Carpenter Expires July 2001 [Page 11] Internet Draft Middle boxes: taxonomy and issues January 2001 IP packet from its intended destination, or substantively modify its content on the fly, are fundamentally different from those that correctly terminate a transport connection and carry out their manipulations at applications level. Such diversion or modification violates the basic architectural assumption that packets flow from source to destination essentially unchanged (except for time-to-live and QOS-related fields). The effects of such changes on transport and applications is unpredictable in the general case. Much of the analysis that applies to NAT [RFC 2993, RFC 3027] will also apply to RSIP, NAT-PT, DSTM, SOCKS, and packet hijackers. Interception proxies, anonymisers, and some types of load balancer can also have subtle effects on address-sensitive applications, when they cause packets to be delivered to or from a different address. Transport relays and TCP spoofers may deceive applications by delivering an unreliable service on a TCP socket. Do we need the routing system to export topology information to an application level routing framework, so that application level routing and load balancers don't have to cheat? What are the characteristics of a sound middle box design? ...of an unsound middle box design? From the taxonomy and existing work, what are the gaps and unstudied topics? 5. Security considerations Security risks are specific to each type of middle box, so little can be said in general. Of course, adding extra boxes in the communication path creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models and key distribution models. Thus, every middle box design requires particular attention to security analysis. Content caches and content distribution mechanisms raise the issue of access control for content that is subject to copyright or other rights. Distributed authentication, authorisation and accounting are required. 6. Acknowledgements Rob Austein, Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom, Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on early versions of this document. Rob Austein and Allison Mankin drafted the text on transport relays and TCP spoofers. Carpenter Expires July 2001 [Page 12] Internet Draft Middle boxes: taxonomy and issues January 2001 7. References [RFC 1928] SOCKS Protocol Version 5. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas & L. Jones. April 1996. [RFC 1958] Architectural Principles of the Internet. B. Carpenter. June 1996. [RFC 2186] Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. [RFC 2543] SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999. [RFC 2616] Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999. [RFC 2663] IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. [RFC 2756] Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. January 2000. [RFC 2766] Network Address Translation - Protocol Translation (NAT- PT). G. Tsirtsis, P. Srisuresh. February 2000. [RFC 2775] Internet Transparency. B. Carpenter. February 2000. [RFC 2979] Behavior of and Requirements for Internet Firewalls. N. Freed. October 2000. [RFC 2993] Architectural Implications of NAT. T. Hain. November 2000. [RFC 3015] Megaco Protocol 1.0. F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. November 2000. [RFC 3022] Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. [RFC 3027]Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. [CNDP] A Model for CDN Peering, draft-day-cdnp-model-04.txt, work in progress. [DSTM] Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans- dstm-03.txt, work in progress. [H323] ITU-T Recommendation H.323: "Packet Based Multimedia Communication Systems". [HTTPSUB] On the use of HTTP as a Substrate for Other Protocols, draft-moore-using-http-01.txt, work in progress. Carpenter Expires July 2001 [Page 13] Internet Draft Middle boxes: taxonomy and issues January 2001 [MIDARCH] A Middle Box Architectural Framework, draft-lear- middlebox-arch-00.txt, work in progress. [MIDFRAME] Middlebox Communication: Framework and Requirements, draft-kuthan-midcom-framework-00.txt, work in progress. [PILCPEP] Performance Enhancing Proxies, draft-ietf-pilc-pep-05.txt, work in progress. [RSIP] Realm Specific IP: Framework, draft-ietf-nat-rsip-framework- 05.txt, work in progress [SIPFIRE] Framework Draft for Networked Appliances Using the Session Initiation Protocol, draft-moyer-sip-appliances-framework-01.txt,.ps, work in progress. [SOCKS6] A SOCKS-based IPv6/IPv4 Gateway Mechanism, draft-ietf- ngtrans-socks-gateway-05.txt, work in progress. [TRANS64] Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication, draft-ietf-ngtrans-translator-03.txt, work in progress. [WREC] Internet Web Replication and Caching Taxonomy, draft-ietf- wrec-taxonomy-05.txt, work in progress. Authors' Addresses Brian E. Carpenter IBM iCAIR, Suite 150 1890 Maple Avenue Evanston IL 60201, USA Email: brian@icair.org Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be Carpenter Expires July 2001 [Page 14] Internet Draft Middle boxes: taxonomy and issues January 2001 followed, or as required to translate it into languages other than 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 Expires July 2001 [Page 15]