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]