Network Working Group B. Carpenter
Request for Comments: 3234 IBM Zurich Research Laboratory
Category: Informational S. Brim
February 2002
Network Working Group B. Carpenter
Request for Comments: 3234 IBM Zurich Research Laboratory
Category: Informational S. Brim
February 2002
Middleboxes: Taxonomy and Issues
中间盒：分类和问题
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive.
本文件旨在作为IETF关于“中间盒”讨论的一部分，中间盒定义为在源主机和目标主机之间的数据路径上执行IP路由器正常标准功能之外的任何中间盒。本文件建立了中间盒的目录或分类法，引用了先前和当前IETF关于中间盒的工作，并试图确定一些初步结论。然而，它并不声称是确定的。
Table of Contents
目录
1. Introduction and Goals......................................... 3
1.1. Terminology.................................................. 3
1.2. The Hourglass Model, Past and Future......................... 3
1.4. Goals of this Document....................................... 4
2. A catalogue of middleboxes..................................... 5
2.1 NAT........................................................... 6
2.2 NAT-PT........................................................ 7
2.3 SOCKS gateway................................................. 7
2.4 IP Tunnel Endpoints........................................... 8
2.5. Packet classifiers, markers and schedulers................... 8
2.6 Transport relay............................................... 9
2.7. TCP performance enhancing proxies............................ 10
2.8. Load balancers that divert/munge packets..................... 10
2.9. IP Firewalls................................................. 11
2.10. Application Firewalls....................................... 11
2.11. Application-level gateways.................................. 12
2.12. Gatekeepers/ session control boxes.......................... 12
2.13. Transcoders................................................. 12
2.14. Proxies..................................................... 13
2.15. Caches...................................................... 14
2.16. Modified DNS servers........................................ 14
2.17. Content and applications distribution boxes................. 15
2.18. Load balancers that divert/munge URLs....................... 16
2.19. Application-level interceptors.............................. 16
2.20. Application-level multicast................................. 16
2.21. Involuntary packet redirection.............................. 16
2.22. Anonymisers................................................. 17
2.23. Not included................................................ 17
2.24. Summary of facets........................................... 17
3. Ongoing work in the IETF and elsewhere......................... 18
4. Comments and Issues............................................ 19
4.1. The end to end principle under challenge..................... 19
4.2. Failure handling............................................. 20
4.3. Failures at multiple layers.................................. 21
4.4. Multihop application protocols............................... 21
4.5. Common features.............................................. 22
5. Security Considerations........................................ 22
6. Acknowledgements............................................... 23
7. References..................................................... 23
Authors' Addresses................................................ 26
Acknowledgement................................................... 26
Full Copyright Statement.......................................... 27
1. Introduction and Goals......................................... 3
1.1. Terminology.................................................. 3
1.2. The Hourglass Model, Past and Future......................... 3
1.4. Goals of this Document....................................... 4
2. A catalogue of middleboxes..................................... 5
2.1 NAT........................................................... 6
2.2 NAT-PT........................................................ 7
2.3 SOCKS gateway................................................. 7
2.4 IP Tunnel Endpoints........................................... 8
2.5. Packet classifiers, markers and schedulers................... 8
2.6 Transport relay............................................... 9
2.7. TCP performance enhancing proxies............................ 10
2.8. Load balancers that divert/munge packets..................... 10
2.9. IP Firewalls................................................. 11
2.10. Application Firewalls....................................... 11
2.11. Application-level gateways.................................. 12
2.12. Gatekeepers/ session control boxes.......................... 12
2.13. Transcoders................................................. 12
2.14. Proxies..................................................... 13
2.15. Caches...................................................... 14
2.16. Modified DNS servers........................................ 14
2.17. Content and applications distribution boxes................. 15
2.18. Load balancers that divert/munge URLs....................... 16
2.19. Application-level interceptors.............................. 16
2.20. Application-level multicast................................. 16
2.21. Involuntary packet redirection.............................. 16
2.22. Anonymisers................................................. 17
2.23. Not included................................................ 17
2.24. Summary of facets........................................... 17
3. Ongoing work in the IETF and elsewhere......................... 18
4. Comments and Issues............................................ 19
4.1. The end to end principle under challenge..................... 19
4.2. Failure handling............................................. 20
4.3. Failures at multiple layers.................................. 21
4.4. Multihop application protocols............................... 21
4.5. Common features.............................................. 22
5. Security Considerations........................................ 22
6. Acknowledgements............................................... 23
7. References..................................................... 23
Authors' Addresses................................................ 26
Acknowledgement................................................... 26
Full Copyright Statement.......................................... 27
The phrase "middlebox" was coined by Lixia Zhang as a graphic description of a recent phenomenon in the Internet. A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host.
“中间包”一词是由张立霞（Lixia Zhang）创造的，它形象地描述了最近互联网上的一种现象。中间盒被定义为在源主机和目标主机之间的数据报路径上执行IP路由器的正常、标准功能以外的功能的任何中间设备。
In some discussions, especially those concentrating on HTTP traffic, the word "intermediary" is used. For the present document, we prefer the more graphic phrase. Of course, a middlebox can be virtual, i.e., an embedded function of some other box. It should not be interpreted as necessarily referring to a separate physical box. It may be a device that terminates one IP packet flow and originates another, or a device that transforms or diverts an IP packet flow in some way, or a combination. In any case it is never the ultimate end-system of an applications session.
在一些讨论中，特别是那些专注于HTTP流量的讨论中，使用了“中介”一词。在本文件中，我们倾向于使用更形象的措辞。当然，中间盒可以是虚拟的，也就是说，其他一些盒子的嵌入式功能。不应将其解释为必然指单独的物理框。它可以是终止一个IP分组流并发起另一个IP分组流的设备，或者以某种方式转换或转移IP分组流的设备，或者是组合。在任何情况下，它都不是应用程序会话的最终终端系统。
Normal, standard IP routing functions (i.e., the route discovery and selection functions described in [RFC 1812], and their equivalent for IPv6) are not considered to be middlebox functions; a standard IP router is essentially transparent to IP packets. Other functions taking place within the IP layer may be considered to be middlebox functions, but functions below the IP layer are excluded from the definition.
正常的标准IP路由功能（即[RFC 1812]中描述的路由发现和选择功能，以及它们在IPv6中的等效功能）不被视为中间箱功能；标准IP路由器对IP数据包基本上是透明的。在IP层内发生的其他功能可能被视为中间盒功能，但IP层以下的功能不在定义范围内。
There is some discrepancy in the way the word "routing" is used in the community. Some people use it in the narrow, traditional sense of path selection based on IP address, i.e., the decision-making action of an IP router. Others use it in the sense of higher layer decision-making (based perhaps on a URL or other applications layer string). In either case it implies a choice of outbound direction, not the mere forwarding of a packet in the only direction available. In this document, the traditional sense is always qualified as "IP routing."
“路由”一词在社区中的使用方式存在一些差异。有些人在狭义的传统意义上使用它，即基于IP地址的路径选择，即IP路由器的决策行为。其他人在高层决策的意义上使用它（可能基于URL或其他应用程序层字符串）。无论哪种情况，它都意味着选择出站方向，而不仅仅是在唯一可用的方向上转发数据包。在本文档中，传统意义上的路由始终被限定为“IP路由”
The classical description of the Internet architecture is based around the hourglass model [HOURG] and the end-to-end principle [Clark88, Saltzer]. The hourglass model depicts the protocol architecture as a narrow-necked hourglass, with all upper layers riding over a single IP protocol, which itself rides over a variety of hardware layers.
互联网架构的经典描述基于沙漏模型[HOURG]和端到端原则[Clark88，Saltzer]。沙漏模型将协议体系结构描述为一个窄颈沙漏，所有上层都跨在一个IP协议上，该协议本身跨在各种硬件层上。
The end-to-end principle asserts that some functions (such as security and reliability) can only be implemented completely and correctly end-to-end, with the help of the end points. The end-to-end principle notes that providing an incomplete version of such functions in the network itself can sometimes be useful as a performance enhancement, but not as a substitute for the end-to-end implementation of the function. The references above, and [RFC 1958], go into more detail.
端到端原则认为，某些功能（如安全性和可靠性）只有在端点的帮助下才能完全正确地端到端实现。端到端原则指出，在网络本身中提供此类功能的不完整版本有时可以用作性能增强，但不能替代该功能的端到端实现。上述参考文献和[RFC 1958]更为详细。
In this architecture, the only boxes in the neck of the hourglass are IP routers, and their only function is to determine routes and forward packets (while also updating fields necessary for the forwarding process). This is why they are not classed as middleboxes.
在这种架构中，沙漏颈部的唯一盒子是IP路由器，它们唯一的功能是确定路由和转发数据包（同时更新转发过程所需的字段）。这就是为什么它们不被归类为中间箱。
Today, we observe deviations from this model, caused by the insertion in the network of numerous middleboxes performing functions other than IP forwarding. Viewed in one way, these boxes are a challenge to the transparency of the network layer [RFC 2775]. Viewed another way, they are a challenge to the hourglass model: although the IP layer does not go away, middleboxes dilute its significance as the single necessary feature of all communications sessions. Instead of concentrating diversity and function at the end systems, they spread diversity and function throughout the network.
今天，我们观察到与此模型的偏差，这是由于在网络中插入了许多执行IP转发以外功能的中间盒造成的。从一个角度来看，这些框对网络层的透明度是一个挑战[RFC 2775]。从另一个角度看，它们是对沙漏模型的挑战：尽管IP层没有消失，但中间盒淡化了它作为所有通信会话唯一必要功能的重要性。它们不是将多样性和功能集中在终端系统，而是在整个网络中传播多样性和功能。
This is a matter of concern for several reasons:
这是一个令人关注的问题，原因有几个：
* New middleboxes challenge old protocols. Protocols designed without consideration of middleboxes may fail, predictably or unpredictably, in the presence of middleboxes.
* 新的中间盒挑战旧的协议。在没有考虑到中间盒的情况下设计的协议可能会在有中间盒的情况下失败，这是可以预测的，也是不可预测的。
* Middleboxes introduce new failure modes; rerouting of IP packets around crashed routers is no longer the only case to consider. The fate of sessions involving crashed middleboxes must also be considered.
* 中间盒引入了新的故障模式；在崩溃路由器周围重新路由IP包不再是唯一需要考虑的情况。还必须考虑涉及崩溃的中间盒的会话的命运。
* Configuration is no longer limited to the two ends of a session; middleboxes may also require configuration and management.
* 配置不再局限于会话的两端；中间盒也可能需要配置和管理。
* Diagnosis of failures and misconfigurations is more complex.
* 故障和错误配置的诊断更加复杂。
The principle goal of this document is to describe and analyse the current impact of middleboxes on the architecture of the Internet and its applications. From this, we attempt to identify some general conclusions.
本文件的主要目的是描述和分析当前中间包对互联网架构及其应用的影响。由此，我们试图得出一些一般性结论。
Goals that might follow on from this work are:
这项工作可能会带来以下目标：
* to identify harmful and harmless practices,
* 确定有害和无害的做法，
* to suggest architectural guidelines for application protocol and middlebox design,
* 为应用程序协议和中间盒设计提供架构指南，
* to identify requirements and dependencies for common functions in the middlebox environment,
* 为确定中间盒环境中常见功能的需求和依赖关系，
* to derive a system design for standardisation of these functions,
* 为使这些功能标准化，制定系统设计，
* to identify additional work that should be done in the IETF and IRTF.
* 确定IETF和IRTF中应完成的其他工作。
An implied goal is to identify any necessary updates to the Architectural Principles of the Internet [RFC 1958].
隐含的目标是确定互联网架构原则的任何必要更新[RFC 1958]。
The document initially establishes a catalogue of middleboxes, and cites previous or current IETF work concerning middleboxes, before proceeding to discussion and conclusions.
在进行讨论和得出结论之前，本文件首先建立了一个中间箱目录，并引用了IETF先前或当前关于中间箱的工作。
The core of this document is a catalogue of a number of types of middlebox. There is no obvious way of classifying them to form a hierarchy or other simple form of taxonomy. Middleboxes have a number of facets that might be used to classify them in a multidimensional taxonomy.
本文件的核心是一系列中间盒类型的目录。没有明显的方法对它们进行分类以形成层次结构或其他简单的分类形式。中间盒有许多方面，可用于在多维分类法中对其进行分类。
DISCLAIMER: These facets, many of distinctions between different types of middlebox, and the decision to include or exclude a particular type of device, are to some extent subjective. Not everyone who commented on drafts of this document agrees with our classifications and descriptions. We do not claim that the following catalogue is mathematically complete and consistent, and in some cases purely arbitrary choices have been made, or ambiguity remains. Thus, this document makes no claim to be definitive.
免责声明：这些方面，不同类型中间盒之间的许多区别，以及包括或排除特定类型设备的决定，在某种程度上是主观的。并非所有对本文件草稿发表评论的人都同意我们的分类和描述。我们并不声称以下目录在数学上是完整的和一致的，在某些情况下，我们做出了纯粹的任意选择，或者模棱两可。因此，本文件不具有确定性。
The facets considered are:
考虑的方面包括：
1. Protocol layer. Does the box act at the IP layer, the transport layer, the upper layers, or a mixture?
1. 协议层。盒子是在IP层、传输层、上层还是混合层起作用？
2. Explicit versus implicit. Is the middlebox function an explicit design feature of the protocol(s) in use, like an SMTP relay? Or is it an add-on not foreseen by the protocol design, probably attempting to be invisible, like a network address translator?
2. 显性与隐性。中间盒功能是否是所用协议的明确设计功能，如SMTP中继？或者它是协议设计没有预见到的一个附加组件，可能试图不可见，比如网络地址转换器？
3. Single hop versus multi-hop. Can there be only one box in the path, or can there be several?
3. 单跳与多跳。路径中只能有一个框，还是可以有几个框？
4. In-line versus call-out. The middlebox function may be executed in-line on the datapath, or it may involve a call-out to an ancillary box.
4. 排队还是呼喊。中间盒功能可以在数据路径上在线执行，也可以涉及对辅助盒的调用。
5. Functional versus optimising. Does the box perform a function without which the application session cannot run, or is the function only an optimisation?
5. 功能与优化。该框是否执行了应用程序会话无法运行的功能，或者该功能只是一种优化？
6. Routing versus processing. Does the box simply choose which way to send the packets of a session, or does it actually process them in some way (i.e., change them or create a side-effect)?
6. 路由与处理。该框只是选择发送会话数据包的方式，还是以某种方式实际处理它们（即，更改它们或产生副作用）？
7. Soft state versus hard state. If the box loses its state information, does the session continue to run in a degraded mode while reconstructing necessary state (soft state), or does it simply fail (hard state)?
7. 软状态与硬状态。如果长方体丢失其状态信息，会话是在重建必要状态（软状态）时继续以降级模式运行，还是仅仅失败（硬状态）？
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?
8. 故障转移与重启。如果硬状态框出现故障，会话是重定向到具有状态信息副本的备用框，还是强制中止并重新启动？
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.
注意：许多类型的中间盒可能需要执行IP数据包分段和重新组装。这仅在某些情况下提及。
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
网络地址转换器。通常内置在路由器中的一种功能，在主机不知情的情况下，动态地为没有全局唯一地址的主机分配一个全局唯一地址。因此，进出该主机的所有数据包中的适当地址字段都是
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.
即时翻译。因为NAT与具有IP地址依赖关系的应用程序协议不兼容，所以NAT实际上总是伴随着ALG（应用程序级网关-见下文）。它还涉及传输层，以确定校验和。
NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993, RFC 3022, RFC 3027, etc.]
IETF[RFC 2663、RFC 2993、RFC 3022、RFC 3027等]对NAT进行了广泛分析
The experimental RSIP proposal complements NAT with a dynamic tunnel mechanism inserting a stateful RSIP server in place of the NAT [RSIP].
实验性的RSIP方案使用动态隧道机制来补充NAT，插入一个有状态的RSIP服务器来代替NAT[RSIP]。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart}
{1个IP层，2个隐式，3个多跳，4个串联，5个功能，6个处理，7个硬，8个重启}
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与协议转换器。通常内置在路由器中的一种功能，用于在IPv6主机和IPv4网络之间执行NAT，另外在IPv6和IPv4格式之间转换整个IP报头。
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本身的协议转换功能依赖于无状态IP/ICMP转换算法（SIIT）机制[RFC 2765]。实际上，SIIT和NAT-PT都需要关联的ALG，并且需要接触传输校验和。由于IPv4中允许缺少UDP校验和，因此无法将分段的未经校验的UDP从IPv4转换为IPv6。NAT-PT和SIIT还存在其他潜在的碎片化/MTU问题，特别是在处理不进行路径MTU发现的端点时（或在传输中断路径MTU发现的其他中间盒时）。ICMP翻译也有一些难以解决的困难。
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].
NAT-PT是NGTRANS工作组[RFC 2766]提出的标准。双堆栈转换机制添加了第二个相关的中间盒，即DSTM服务器[DSTM]。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart}
{1个IP层，2个隐式，3个多跳，4个串联，5个功能，6个处理，7个硬，8个重启}
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
SOCKSv5[RFC 1928]是一种用于经过身份验证的防火墙穿越的有状态机制，其中客户端主机必须首先与防火墙中的SOCKS服务器通信，然后才能穿越防火墙。决定防火墙外部使用的源IP地址和端口号的是SOCKS服务器，而不是客户端。这个
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.
客户机的堆栈必须“socksify”才能考虑到这一点，地址敏感的应用程序可能会混淆，就像NAT一样。但是，SOCKS网关不需要ALG。
SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.
SOCKS由AFT（认证防火墙穿越）工作组维护。
{1 multi-layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6 routing, 7 hard, 8 restart}
{1多层，2显式，3多跳，4直列，5功能，6路由，7硬，8重启}
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.
隧道端点（包括虚拟专用网络端点）使用基本IP服务与其对等隧道端点（可能位于Internet中的任何位置）建立隧道。隧道基于互联网基础设施创建全新的“虚拟”网络和网络接口，从而开辟了许多新服务。隧道端点的转发决策至少部分基于它们自己的策略，只有部分基于周围路由器可见的信息。
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].
在一定程度上，它们将数据包完好无损地传送到目的地，隧道端点似乎遵循外部互联网中的端到端原则。然而，目的地可能与隧道入口附近的路由器所期望的完全不同。此外，隧道数据包接收的每跳处理，例如在QoS方面，可能不是数据包未被隧道传输时所接收的处理[RFC2983]。
Tunnels also cause difficulties with MTU size (they reduce it) and with ICMP replies (they may lack necessary diagnostic information).
隧道还会导致MTU大小（它们会减小MTU大小）和ICMP回复（它们可能缺少必要的诊断信息）方面的困难。
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.
当隧道因某种原因失败时，这可能会导致用户会话中止，或者可能会证明备用IP路由可用，或者在某些情况下，隧道可能会自动重新建立。
{1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart or failover}
{1多层、2隐式、3多跳、4串联、5功能、6处理、7硬、8重启或故障切换}
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.
数据包分类器根据策略对流经它们的数据包进行分类，或者选择它们进行特殊处理，或者对它们进行标记，特别是针对区分服务[Clark95，RFC 2475]。由于它们控制流量调节器的行为，因此它们可以通过后续跳改变数据包流的顺序。
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.
当分类器或流量调节器失败时，用户会话可能会看到连接完全丧失（所有数据包都被丢弃）、通过尽力而为服务（所有数据包都被赋予默认QOS）到自动恢复原始服务级别之间的任何结果。
{1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6 processing, 7 soft, 8 failover or restart}
{1多层、2隐式、3多跳、4串联、5优化、6处理、7软、8故障切换或重启}
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.
传输继电器基本上相当于ALG的传输层；另一个（不太常见的）名称是TLG。与ALG一样，它们用于各种目的，其中一些目的已经确立，满足了其他方面无法满足的需求。传输中继的早期示例是那些在麻省理工学院的ITS和ARPANET上的TOPS-20 PDP-10s上运行的中继，它们允许仅限Chaosnet的主机从Chaosnet到TCP/IP进行传出连接。后来出现了TCP-TP4中继的一些用途。仅IPv6和仅IPv4主机之间的传输中继是IPv6转换的工具之一[TRANS64]。TLG有时与简单的数据包过滤防火墙结合使用，以强制限制主机与外部世界通信，或对奇怪的IP路由配置进行回避。TLG有时还用于在具有显著不同连接特性的同一传输协议的两个实例之间建立网关；从这个意义上讲，TLG也可以称为TCP或传输欺骗。在这个角色中，TLG可能会变成一个优化而不是一个功能性的中间盒，但它与传输代理（下一节）的区别在于，它只通过创建背靠背连接进行优化，而不是通过修改或重新计时TCP消息。
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
终止一个TCP连接并启动另一个中间路径意味着TCP校验和不覆盖发送方的端到端数据。当数据从第一连接传输到第二连接时，在处理中可能引入数据损坏或修改。有些TCP中继是分离中继，甚至更可能丢失数据完整性，因为可能有两个以上的TCP连接，并且涉及多个节点和网络路径。在所有情况下，发送方对数据完整性的保证都低于TCP可靠字节流服务的预期。注意
this problem is not unique to middleboxes, but can also be caused by checksum offloading TCP implementations within the sender, for example.
这个问题不仅限于中间包，而且也可能是由于发送方内部的校验和卸载TCP实现造成的。
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.
在某些情况下，其他会话层机制（如SSH或HTTPS）会检测到TCP级别的任何数据完整性丢失，从而导致会话失败，而不是像TCP那样重新传输。但是，没有通用的会话机制来添加应用程序数据完整性，因此可以检测或缓解TCP数据完整性的可能缺失。
{1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 functional (mainly), 6 routing, 7 hard, 8 restart}
{1传输层，2隐式，3多跳，4直列，5功能（主要），6路由，7硬，8重启}
"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.
“TCP欺骗”通常被用作中间盒的一个术语，用于修改传输中TCP协议的时间或操作，以提高性能。另一个更准确的名称是TCP性能增强代理（PEP）。许多TCP PEP都是专有的，并且在开放互联网中主要是在它们引入标准TCP的互操作性错误时被描述的。与TLG一样，在某些情况下，TCP PEP被视为满足了其他方面无法满足的需求。例如，TCP PEP可以提供由具有突发服务的链路聚在一起的ack的重新间隔，从而避免不希望的数据段突发。PILC（链路特性的性能影响）工作组分析了TCP PEP的类型及其适用性[PILCPEP]。TCP PEP不仅会导致TCP错误，还会导致TCP自适应行为的意外变化。
{1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6 routing, 7 hard, 8 restart}
{1传输层，2隐式，3多跳，4直列，5优化，6路由，7硬，8重启}
2.8. Load balancers that divert/munge packets.
2.8. 转移/咀嚼数据包的负载均衡器。
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.)
有多种技术可以将数据包从其预期的IP目的地转移，或使该目的地不明确。其动机通常是在服务器之间平衡负载，甚至根据目标端口号通过IP路由在服务器之间拆分应用程序。除了少数一次性UDP协议的实例外，这些技术不可避免地是有状态的，因为来自同一应用程序会话的所有数据包都需要定向到同一物理服务器。（但是，复杂的解决方案也能够处理故障切换。）
To date these techniques are proprietary and can therefore only be applied in closely managed environments.
到目前为止，这些技术是专有的，因此只能应用于管理严密的环境中。
{1 multi-layer, 2 implicit, 3 single hop, 4 in-line, 5 optimising, 6 routing, 7 hard, 8 restart}
{1多层，2隐式，3单跳，4直列，5优化，6路由，7硬，8重启}
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.)
防火墙最简单的形式是一个路由器，它纯粹根据IP和传输头中的字段来屏蔽和拒绝数据包（例如，不允许某些端口号的传入流量，不允许某些子网的任何流量，等等）
Although firewalls have not been the subject of standardisation, some analysis has been done [RFC 2979].
虽然防火墙尚未成为标准化的主题，但已经进行了一些分析[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.
虽然纯IP防火墙不会改变流经它的数据包，但拒绝其中一些数据包可能会导致连接问题，用户很难理解和诊断这些问题。
"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.
“无状态”防火墙通常允许所有IP片段通过，因为它们不包含足够的上层头信息来做出过滤决定。因此，许多“有状态”防火墙重新组装IP片段（并在必要时重新组装片段），以避免泄漏片段，特别是可能利用终端接收器重新组装实现中的漏洞的片段。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6 routing, 7 hard, 8 restart}
{1 IP层，2隐式，3多跳，4直列，5功能，6路由，7硬，8重启}
Application-level firewalls act as a protocol end point and relay (e.g., an SMTP client/server or a Web proxy agent). They may
应用程序级防火墙充当协议端点和中继（例如SMTP客户端/服务器或Web代理）。他们可能
(1) implement a "safe" subset of the protocol,
(1) 实现协议的“安全”子集，
(2) perform extensive protocol validity checks,
(2) 执行广泛的协议有效性检查，
(3) use an implementation methodology designed to minimize the likelihood of bugs,
(3) 使用一种旨在最大限度地减少错误可能性的实施方法，
(4) run in an insulated, "safe" environment, or
(4) 在绝缘的“安全”环境中运行，或
(5) use some combination of these techniques in tandem.
(5) 同时使用这些技术的一些组合。
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].
虽然防火墙尚未成为标准化的主题，但已经进行了一些分析[RFC 2979]。已经讨论了使用HTTP穿越防火墙的问题[HTTPSUB]。
{1 Application layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart}
{1个应用层，2个隐式，3个多跳，4个串联，5个功能，6个处理，7个硬，8个重启}
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.
它们有许多形状和形式。NAT要求某些地址相关协议（如FTP）使用ALG；这些不会改变应用程序协议的语义，而是执行字段的机械替换。在规模的另一端，仍以FTP为例，在FTP和其他文件传输协议（如OSI和DECnet（R）等效协议）之间构建了网关。在任何情况下，这些网关都需要维护它们正在处理的会话的状态，如果该状态丢失，会话通常会不可撤销地中断。
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).
一些ALG的实现方式也会产生碎片问题，尽管在这种情况下，问题可能是故意违反层的结果（例如，通过动态旋转TCP段来破坏FTP控制连接的应用程序数据流）。
{1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart}
{1个应用层，2个隐式或显式，3个多跳，4个串联，5个功能，6个处理，7个硬启动，8个重启}
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].
特别是随着IP电话的兴起，需要创建和管理TCP连接以外的会话。在多媒体环境中，必须处理名称查找、身份验证、授权、记帐、防火墙穿越，有时还要处理媒体转换，通过第三方盒子建立和控制会话似乎是不可避免的解决方案。示例包括H.323网关守卫[H323]、SIP服务器[RFC 2543]和MEGACO控制器[RFC 3015]。
{1 Application layer, 2 explicit, 3 multihop, 4 in-line or call-out, 5 functional, 6 processing, 7 hard, 8 restart?}
{1个应用层，2个显式，3个多跳，4个在线或呼叫，5个功能，6个处理，7个硬启动，8个重启？}
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.
转码器是对应用程序级数据执行某种类型的动态转换的盒子。示例包括用于在手持无线设备上显示的现有网页的转码，以及用于将数字移动电话与IP语音服务互连的各种音频格式之间的转码。在许多情况下，这样的转码不能由终端系统完成，至少在语音的情况下，必须严格实时完成，故障恢复速度极快。
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}
{1个应用层，2个显式或隐式，3个单跳，4个串联，5个功能，6个处理，7个硬？，8个重启或故障转移}
HTTP1.1 [RFC 2616] defines a Web proxy as follows:
HTTP1.1[RFC 2616]对Web代理的定义如下：
"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.
当防火墙不允许传出HTTP数据包时，Web代理可能与防火墙关联。但是，HTTP使用代理是“自愿的”：必须将客户端配置为使用代理。
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.
请注意，HTTP代理实际上会终止IP数据包流并重新创建另一个数据包流，但它们属于第1.1节中给出的“中间包”定义，因为实际的应用程序会话会遍历它们。
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.)
SIP代理[RFC2543]也提出了一些有趣的问题，因为它们可以“弯曲”媒体管道，同时充当媒体转换器。（代理可以修改会话描述，使媒体不再端到端传输，而是传输到指定的中间盒。）
{1 Application layer, 2 explicit (HTTP) or implicit (interception), 3 multihop, 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}.
{1个应用层，2个显式（HTTP）或隐式（拦截），3个多跳，4个串联，5个功能，6个处理，7个软，8个重启}。
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.
注意：一些所谓的Web代理已被实现为“拦截”设备，拦截HTTP数据包并使用自己的源地址重新发布它们；与NAT和SOCKs一样，这可能会干扰对地址敏感的应用程序。不幸的是，一些供应商错误地将这些代理描述为“透明”代理，造成了混乱。截取设备绝不是透明的。有关详细讨论，请参见[WREC]。
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.
当然，缓存在互联网上有多种形式，原则上与代理不同。这里我们主要指的是内容缓存，旨在优化用户响应时间。HTTP通过为缓存内容提供过期和重新验证机制，为代理提供了充当缓存的功能。这些机制可用于确保不缓存特定内容，这是临时内容的要求，尤其是在事务性应用程序中。[RFC 2616]的第13节详细描述了HTTP缓存，在HTTP情况下，缓存和代理是不可分割的混合。
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].
为了改进优化，缓存不是在源服务器和直接为用户服务的代理缓存之间唯一执行的。如果存在缓存网络，则所需内容的最近副本可能位于对等缓存中。为此，需要一个缓存间协议。目前部署最广泛的解决方案是Internet缓存协议（ICP）[RFC 2186]，尽管也有类似[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.
可以说，缓存会终止应用程序会话，不应被算作中间盒（与我们算作SMTP中继一样）。但是，我们武断地选择将它们包括在内，因为它们实际上会在缓存未命中的情况下重新发出客户端的HTTP请求，并且它们不是应用程序数据的最终来源。
{1 Application layer, 2 explicit (if HTTP proxy caches), 3 multihop, 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}
{1个应用程序层，2个显式（如果HTTP代理缓存），3个多跳，4个串联，5个功能，6个处理，7个软启动，8个重启}
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
DNS服务器可以玩游戏。只要它们似乎对每个查询都提供了语法正确的响应，它们就可以修改语义。例如，通过安排名称解析为网络不同部分的不同IP地址，可以将名称转换为“选播”名称。或者，通过让本地DNS服务器返回服务器场的地址，可以在服务器场的不同成员之间共享负载
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").
依次使用不同的服务器。在NAT环境中，FQDN到地址的映射在NAT内外非常不同（“双面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.
修改后的DNS服务器不是感兴趣的应用程序数据流中的中介。这里包括它们是因为它们意味着在一个级别上似乎涉及单个主机的独立会话实际上涉及多个主机，这可能会产生微妙的影响。在主机A中创建的状态（例如，由一个会话创建的状态）可能在显然与同一主机的第二个会话启动时不存在，因为DNS服务器已将第二个会话定向到其他位置。
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.
如果这样的DNS服务器出现故障，用户可能会故障转移到不知道相同技巧的备用DNS服务器，结果无法预测。
{1 Application layer, 2 implicit, 3 multihop, 4 in-line (on DNS query path), 5 functional or optimising, 6 processing, 7 soft, 8 failover}
{1个应用层，2个隐式，3个多跳，4个在线（在DNS查询路径上），5个功能或优化，6个处理，7个软，8个故障切换}
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.
缓存的一个新兴概括是内容分发和应用程序分发。在此模型中，内容（如静态web内容或流媒体内容）提前复制到许多分布广泛的服务器。此外，可以远程复制交互式甚至事务性应用程序及其一些关联数据。由于这是一种最新的模式，因此不能说在这一领域存在行业标准实践。[WREC]中讨论了一些问题，并在此领域提出了一些新的IETF活动。
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.
内容分发解决方案往往以这样或那样的方式使用URL，并且通常涉及一个中间盒系统-例如，使用HTTP重定向将对WWW.example.COM的请求发送到WWW.example.NET，后者的名称可能是上文提到的“anycast”名称，并将在DNS中实际解析到最近的内容分发箱实例。
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?}
{1个应用层，2个隐式或显式，3个多跳，4个在线或呼叫，5个优化，6个路由或处理，7个软，8个重启？}
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.
与DNS技巧一样，URL重定向可用于平衡服务器池之间的负载—本质上是内容分发网络的本地版本。或者，HTTP代理可以重写HTTP请求，将它们定向到服务器池的特定成员。
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}
{1个应用层，2个显式，3个单跳，4个串联，5个功能，6个路由，7个软，8个重启}
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.
某些形式的伪代理截获HTTP数据包并将其传递到本地代理服务器，而不是将其转发到预期的目的地。因此，数据包中的目标IP地址被忽略。很难说明这是功能框（即非标准代理）还是优化框（即强制用户使用缓存的方式）。与任何非标准代理一样，它在动态或不可缓存内容的情况下具有未定义的后果。
{1 Application layer, 2 implicit, 3 single hop, 4 in-line, 5 functional or optimising, 6 routing, 7 hard, 8 restart}
{1个应用层，2个隐式，3个单跳，4个串联，5个功能或优化，6个路由，7个硬，8个重启}
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].
[CHU]中给出了一个例子。
{1 Application layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6 routing, 7 hard, 8 restart}
{1个应用层，2个显式，3个多跳，4个串联，5个功能，6个路由，7个硬，8个重启}
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.
似乎有一些盒子（基于应用程序级内容或网络层上的其他信息）出于功能原因重定向数据包。例如，在酒店房间提供的多个“高速互联网”服务拦截初始HTTP请求，并将其转移到HTTP服务器，该服务器在打开互联网访问之前要求付款。这些盒子通常也执行NAT功能。
{1 multi-layer, 2 implicit, 3 single hop, 4 call-out, 5 functional, 6 routing, 7 hard, 8 restart}
{1多层，2隐式，3单跳，4呼叫，5功能，6路由，7硬，8重启}
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.
匿名器框可以以各种方式实现，以隐藏数据发送方或接收方的IP地址。尽管实现可能不同，但实际上这与NAT+ALG非常相似。
{1 multi-layer, 2 implicit or explicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart}
{1个多层，2个隐式或显式，3个多跳，4个串联，5个函数，6个处理，7个硬启动，8个重启}
Some candidates suggested for the above list were excluded for the reasons given below. In general, they do not fundamentally change the architectural model of packet delivery from source to destination.
出于以下原因，建议列入上述名单的一些候选人被排除在外。一般来说，它们不会从根本上改变从源到目标的数据包交付的体系结构模型。
Bridges and switches that snoop ARP, IGMP etc. These are below the IP layer, but use a layer violation to emulate network layer functions. They do not change IP layer functions.
侦听ARP、IGMP等的网桥和交换机。这些网桥和交换机位于IP层之下，但使用层冲突来模拟网络层功能。它们不会改变IP层功能。
Wiretaps and snoopers in general - if they are working correctly, they have no impact on traffic, so do not require analysis.
一般来说，窃听和窥探——如果它们工作正常，对流量没有影响，因此不需要分析。
Mobile IP home agents are intended to assist packet delivery to the originally desired destination, so they are excluded on the same grounds as standard routers.
移动IP归属代理旨在帮助数据包传送到最初想要的目的地，因此它们被排除在标准路由器之外。
Relays in interplanetary networks - although these would certainly appear to be middleboxes, they are not currently deployed.
行星际网络中的中继——虽然它们看起来肯定是中间盒，但目前尚未部署。
By tabulating the rough classifications above, we observe that of the 22 classes of middlebox described:
通过将上述粗略分类制成表格，我们观察到在所述的22类中间盒中：
17 are application or multi-layer 16 are implicit (and others are explicit OR implicit) 17 are multi-hop 21 are in-line; call-out is rare 18 are functional; pure optimisation is rare Routing & processing are evenly split 16 have hard state 21 must restart session on failure
17为应用或多层16为隐式（其他为显式或隐式）17为多跳21为串联；呼叫是罕见的18个功能；纯粹的优化是罕见的，路由和处理是均匀分配的16具有硬状态21在出现故障时必须重新启动会话
We can deduce that current types of middlebox are predominantly application layer devices not designed as part of the relevant protocol, performing required functions, maintaining hard state, and aborting user sessions when they crash. Indeed this represents a profound challenge to the end-to-end hourglass model.
我们可以推断，当前类型的中间盒主要是应用层设备，它们不是作为相关协议的一部分设计的，它们执行所需的功能，维护硬状态，并在用户会话崩溃时中止用户会话。事实上，这是对端到端沙漏模型的深刻挑战。
Apart from work cited in references above, current or planned work in the IETF includes:
除上述参考文献中引用的工作外，IETF中当前或计划的工作包括：
MIDCOM - a working group with focus on the architectural framework and the requirements for the protocol between a requesting device and a middlebox and the architectural framework for the interface between a middlebox and a policy entity [MIDFRAME, MIDARCH]. This may interact with session control issues [SIPFIRE].
MIDCOM-一个工作组，重点关注请求设备和中间盒之间协议的架构框架和要求，以及中间盒和策略实体之间接口的架构框架[MIDFRAME，MIDARCH]。这可能与会话控制问题[SIPFIRE]相互作用。
Work is also proceeding outside the MIDCOM group on middlebox discovery [MIDDISC].
在MIDCOM小组之外，关于中间包发现[MIDDISC]的工作也在进行中。
WEBI (Web Intermediaries) - a working group that addresses 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.
WEBI（Web中介机构）-一个工作组，通过提供在多个应用领域（例如代理、内容交付代理）中有用的通用机制，解决万维网基础设施中的特定问题（由WREC工作组确定）。具体机制将是中介发现和描述以及资源更新协议。
Intermediaries are also an important focus in the development of XML Protocol by the World-Wide Web Consortium, who have published an interesting analysis [XMLPI].
中介体也是万维网联盟开发XML协议的一个重要焦点，该联盟发表了一篇有趣的分析[XMLPI]。
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.
OPES（开放可插拔扩展服务）——一个提议的工作组，其输出将支持参与的运输中介机构对应用程序数据执行的服务构建。缓存是最基本的中介服务，需要缓存服务器对应用程序语义有基本的理解。
CDI (Content Distribution Internetworking) is a potential working group for allowing cooperation between different Content Distribution Networks and cache clusters [CDNP].
CDI（Content Distribution Internetworking）是一个潜在的工作组，用于允许不同内容分发网络和缓存集群之间的合作[CDNP]。
RSERPOOL (Reliable Server Pooling) is a 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.
RSERPOOL（可靠服务器池）是一个工作组，它将定义管理和访问服务器池的体系结构和要求，包括来自各种应用程序、构建块和接口的要求、不同类型的池、安全要求和性能要求，例如故障切换时间和应对异构延迟。
A review of the list in Section 2 suggests that middleboxes fit into one or more of three broad categories:
对第2节中列表的审查表明，中间盒可分为三大类别中的一个或多个：
1) mechanisms to connect dissimilar networks to enable cross-protocol interoperability;
1) 连接不同网络以实现跨协议互操作性的机制；
2) mechanisms to separate similar networks into zones, especially security zones;
2) 将类似网络划分为区域，特别是安全区域的机制；
3) performance enhancement.
3) 性能增强。
As observed in [RFC 2775], the rise of middleboxes puts into question the general applicability of the end-to-end principle [RFC 1958]. Middleboxes introduce dependencies and hidden 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 middleboxes?
如[RFC 2775]所述，中间盒的兴起使端到端原则的普遍适用性受到质疑[RFC 1958]。中间盒引入的依赖关系和隐藏的故障点违反了端到端原则的命运共享方面。我们能否定义架构原则，以保证在存在中间盒时的健壮性？
Many forms of middlebox are explicitly addressed at the 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.)
许多形式的中间包在IP级别显式寻址，并以正常方式终止传输连接（或充当UDP数据包的最终目的地）。尽管它们是潜在的单点故障，但它们不会干扰端到端原则[RFC 1958]。（此语句不适用于传输中继或TCP欺骗；它们不会以正常方式在预期目的地终止传输连接。）
However, there is a general feeling that middleboxes that divert an 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 involuntary packet redirectors. 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.
然而，人们普遍认为，将IP数据包从其预期目的地转移或实时实质性修改其内容的中间包与正确终止传输连接并在应用程序级别执行操作的中间包有根本的不同。这种转移或修改违反了基本的体系结构假设，即数据包从源流向目的地基本不变（生存时间和QOS相关字段除外）。在一般情况下，此类变化对传输和应用的影响是不可预测的。许多适用于NAT的分析[RFC 2993，RFC 3027]也将适用于RSIP、NAT-PT、DSTM、SOCKS和非自愿数据包重定向器。拦截代理、匿名服务器和某些类型的负载平衡器也会对地址敏感的应用程序产生微妙的影响，因为它们会导致数据包发送到不同的地址或从不同的地址发送。传输中继和TCP欺骗可能通过在TCP套接字上提供不可靠的服务来欺骗应用程序。
We conclude that:
我们的结论是：
Although the rise of middleboxes has negative impact on the end to end principle at the packet level, it does not nullify it as a useful or desirable principle of applications protocol design. However, future application protocols should be designed in recognition of the likely presence of network address translation, packet diversion, and packet level firewalls, along the data path.
尽管中间盒的兴起对数据包级别的端到端原则产生了负面影响，但它并没有使其成为应用程序协议设计的有用或可取的原则。然而，未来的应用程序协议的设计应考虑到沿数据路径可能存在的网络地址转换、数据包转移和数据包级防火墙。
If a middlebox 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" middleboxes 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" middleboxes must be present for the session to continue, so they are candidates for rapid failover or rapid restart mechanisms. We conclude that:
“优化”中间盒似乎是软状态方法和非实时数据流的合适候选，因为中间盒故障的后果对用户来说不是灾难性的。（用作缓存的已配置HTTP代理是一种尴尬的情况，因为它们的故障会导致客户端故障。）另一方面，会话必须存在“功能性”中间盒才能继续，因此它们是快速故障切换或快速重启机制的候选。我们的结论是：
Middlebox design should include a clear mechanism for dealing with failure.
中间盒设计应包括处理故障的明确机制。
Difficulties occur when middlebox functions occur at different layers, for example the following situation, where B and C are not in the same physical box:
当中间盒功能出现在不同的层时会出现困难，例如以下情况，其中B和C不在同一物理盒中：
Apps layer: A ------------------------> C ------> D
Apps layer: A ------------------------> C ------> D
Lower layer: A -----> B -------------------------> D
Lower layer: A -----> B -------------------------> D
When all is well, i.e., there is an IP path from A to B to C to D and both B and C are working, this may appear quite workable. But the failure modes are very challenging. For example, if there is a network failure between C and D, how is B instructed to divert the session to a backup box for C?. Since C and B function at different protocol layers, there is no expectation that they will have coordinated failure recovery mechanisms. Unless this is remedied in some general way, we conclude that
当一切正常时，也就是说，有一条从A到B到C到D的IP路径，并且B和C都在工作时，这看起来是非常可行的。但故障模式非常具有挑战性。例如，如果C和D之间存在网络故障，如何指示B将会话转移到C的备份箱？。由于C和B在不同的协议层上运行，因此不期望它们具有协调的故障恢复机制。除非以某种普遍的方式对此进行补救，否则我们的结论是
Middlebox failure recovery mechanisms cannot currently assume they will get any help from other layers, and must have their own means of dealing with failures in other layers.
Middlebox故障恢复机制目前不能假定它们将从其他层获得任何帮助，必须有自己的方法来处理其他层中的故障。
In the long term future, we should be able to state clearly for each middlebox function what it expects from its environment, and make recommendations about which middlebox functions should be bound together if deployed.
从长远来看，我们应该能够清楚地说明每个中间箱功能对其环境的期望，并就部署时应将哪些中间箱功能绑定在一起提出建议。
We can also observe that protocols such as SMTP, UUCP, and NNTP have always worked hop-by-hop, i.e., via multiple middleboxes. Nobody considers this to be an issue or a problem. Difficulties arise when inserting a middlebox in an application protocol stream that was not designed for it. We conclude that:
我们还可以观察到，诸如SMTP、UUCP和NNTP等协议始终是逐跳工作的，即通过多个中间盒。没有人认为这是一个问题。在应用程序协议流中插入一个不是为其设计的中间盒时，会出现困难。我们的结论是：
New application protocol designs should include explicit mechanisms for the insertion of middleboxes, and should consider the facets identified in Section 2 above as part of the design.
新的应用协议设计应包括用于插入中间盒的显式机制，并且应考虑上述第2节中所标识的方面作为设计的一部分。
A specific challenge is how to make interactive or real-time applications ride smoothly over middleboxes. This will put particular stress on the failure handling aspects.
一个具体的挑战是如何使交互式或实时应用程序顺利通过中间包。这将特别强调故障处理方面。
Given that the IP layer - the neck of the hourglass - is no longer alone in its role supporting end-to-end connectivity, it would be desirable to define requirements and features that are common to middlebox intermediaries. It would then be possible to implement middleboxes, and in particular the protocols that communicate with them, fully from the stance of supporting the end-to-end principle. Conceptually, this would extend the neck of the hourglass upwards to include a set of common features available to all (or many) applications. In the context of middleboxes and multihop protocols, this would require common features addressing at least:
考虑到支持端到端连接的IP层（沙漏的颈部）不再是唯一的角色，因此需要定义中间盒中介体通用的要求和功能。这样就可以完全从支持端到端原则的立场来实现中间盒，特别是与它们通信的协议。从概念上讲，这将向上扩展沙漏的颈部，以包括一组可供所有（或许多）应用程序使用的公共功能。在中间盒和多跳协议的上下文中，这将需要至少解决以下问题的通用功能：
Middlebox discovery and monitoring Middlebox configuration and control Call-out Routing preferences Failover and restart handling Security, including mutual authentication
Middlebox发现和监控Middlebox配置和控制调出路由首选项故障切换和重启处理安全性，包括相互身份验证
As far as possible, the solutions in these areas being developed in the IETF and W3C should be sufficiently general to cover all types of middlebox; if not, the work will be done several times.
IETF和W3C正在开发的这些领域的解决方案应尽可能具有足够的通用性，以涵盖所有类型的中间盒；如果没有，这项工作将进行多次。
Security risks are specific to each type of middlebox, 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 middlebox design requires particular attention to security analysis. A few general points can be made:
每种类型的中间包都有特定的安全风险，因此一般来说几乎没有什么可说的。当然，在通信路径中添加额外的盒子会产生额外的攻击点，降低或消除执行端到端加密的能力，并使信任模型和密钥分发模型复杂化。因此，每个中间盒设计都需要特别注意安全性分析。可以提出以下几点：
1. The interference with end-to-end packet transmission by many types of middlebox is a crippling impediment to generalised use of IPSEC in its present form, and also invalidates transport layer security in many scenarios.
1. 许多类型的中间盒对端到端数据包传输的干扰是目前形式的IPSEC普遍使用的严重障碍，在许多情况下也会使传输层安全性失效。
2. Middleboxes require us to move definitively from a two-way to an N-way approach to trust relationships and key sharing.
2. 中间包要求我们在信任关系和密钥共享方面从双向方式转向N向方式。
3. The management and configuration mechanisms of middleboxes are a tempting point of attack, and must be strongly defended.
3. 中间盒的管理和配置机制是一个诱人的攻击点，必须予以有力的保护。
These points suggest that we need a whole new approach to security solutions as the middlebox paradigm ends up being deployed in lots of different technologies, if only to avoid each new technology
这些观点表明，我们需要一种全新的安全解决方案方法，因为中间件范例最终被部署在许多不同的技术中，即使只是为了避免每一种新技术
designing a end-to-end security solution appropriate to its particular impact on the data stream.
设计适合其对数据流的特定影响的端到端安全解决方案。
Additionally, 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.
此外，内容缓存和内容分发机制还提出了受版权或其他权利约束的内容的访问控制问题。需要分布式身份验证、授权和记帐。
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, and Rob Austein made other substantial contributions. Participants in the MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker, Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen, Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave invaluable input. Mark Nottingham brought the W3C work to our attention. Melinda Shore suggested using a facet-based categorization. Patrik Faltstrom inspired section 4.3.
Steve Bellovin、Jon Crowcroft、Steve Deering、Patrik Faltstrom、Henning Schulzrinne和Lixia Zhang都对本文件的早期版本提供了宝贵的反馈。Rob Austein和Allison Mankin起草了关于传输中继和TCP欺骗的文本，Rob Austein做出了其他重大贡献。第50届IETF中税BOF和中税邮件列表的参与者，包括Harald Alverstrand、Stanislav Shalunov、Michael Smirnov、Jeff Parker、Sandy Murphy、David Martin、Phil Neumiller、Eric Travis、Ed Bowen、Sally Floyd、Ian Cooper、Mike Fisk和Eric Fleischman，提供了宝贵的意见。马克·诺丁汉让我们注意到了W3C的工作。Melinda Shore建议使用基于方面的分类。Patrik Faltstrom启发了第4.3节。
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC 1812]Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", March 1996.
[RFC 1928]Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.和L.Jones，“袜子协议版本5”，1996年3月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958]Carpenter，B.，“互联网的建筑原理”，RFC 19581996年6月。
[RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), version 2", RFC 2186, September 1997.
[RFC 2186]Wessels，D.和K.Claffy，“互联网缓存协议（ICP），版本2”，RFC 2186，1997年9月。
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC 2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC 2543]Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC 2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000.
[RFC 2756]Vixie，P.和D.Wessels，“超文本缓存协议（HTCP/0.0）”，RFC 2756，2000年1月。
[RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC 2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC 2775]Carpenter，B.，“互联网透明度”，RFC 2775，2000年2月。
[RFC 2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC 2979]弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2983]Black，D.，“差异化服务和隧道”，RFC 2983，2000年10月。
[RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC 2993]Hain，T.，“NAT的建筑含义”，RFC 2993，2000年11月。
[RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol 1.0", RFC 3015, November 2000.
[RFC 3015]Cuervo，F.，Greene，N.，Rayhan，A.，Huitema，C.，Rosen，B.和J.Segers，“Megaco协议1.0”，RFC 3015，2000年11月。
[RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC 3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC 3027]Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[CHU] Y. Chu, S. Rao, and H. Zhang, A Case for End System Multicast, SIGMETRICS, June 2000. http://citeseer.nj.nec.com/chu00case.html
[CHU]Yu，S.Rao和H.Zhang，终端系统多播案例，SIGMETRICS，2000年6月。http://citeseer.nj.nec.com/chu00case.html
[CLARK88] The Design Philosophy of the DARPA Internet Protocols, D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995, pages 102-111).
[CLARK88]DARPA互联网协议的设计理念，D.D.Clark，Proc SIGCOMM 88，ACM CCR第18卷第4期，1988年8月，第106-114页（重印于ACM CCR第25卷第1期，1995年1月，第102-111页）。
[CLARK95] "Adding Service Discrimination to the Internet", D.D. Clark, Proceedings of the 23rd Annual Telecommunications Policy Research Conference (TPRC), Solomons, MD, October 1995.
[CLARK95]“在互联网上增加服务歧视”，D.D.Clark，第23届年度电信政策研究会议论文集，马里兰州所罗门群岛，1995年10月。
[CDNP] M. Day, et al., "A Model for Content Internetworking (CDI)", Work in Progress.
[CDNP]M.Day等人，“内容互联（CDI）模型”，正在进行中。
[DSTM] J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A. Durand, "Dual Stack Transition Mechanism (DSTM)", Work in Progress.
[DSTM]J.Bound，L.Toutain，F.Dupont，O.Medina，H.Afifi，A.Durand，“双堆栈转换机制（DSTM）”，正在进行的工作。
[H323] ITU-T Recommendation H.323: "Packet Based Multimedia Communication Systems".
[H323]ITU-T建议H.323：“基于分组的多媒体通信系统”。
[HOURG] "Realizing the Information Future: The Internet and Beyond", Computer Science and Telecommunications Board, National Research Council, Washington, D.C., National Academy Press, 1994. However, the "hourglass" metaphor was first used by John Aschenbrenner in 1979, with reference to the ISO Open Systems Interconnection model.
[HOURG]“实现信息未来：互联网及其以外”，计算机科学和电信委员会，国家研究委员会，华盛顿特区，国家科学院出版社，1994年。然而，“沙漏”这个比喻是约翰·阿斯肯布伦纳在1979年首次使用的，它涉及ISO开放系统互连模型。
[HTTPSUB] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[HTTPSUB]Moore，K.，“关于HTTP作为基板的使用”，BCP 56，RFC 3205，2002年2月。
[MIDARCH] E. Lear, "A Middlebox Architectural Framework", Work in Progress.
[MIDARCH]E.Lear，“中间盒架构框架”，正在进行中。
[MIDDISC] E. Lear, "Requirements for Discovering Middleboxes", Work in Progress.
[MIDDISC]E.Lear，“发现中间包的要求”，正在进行的工作。
[MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "Middlebox Communication: Framework and Requirements", Work in Progress.
[MIDFRAME]P.Srisuresh，J.Kuthan，J.Rosenberg，A.Molitor，A.Rayhan，“中间箱通信：框架和需求”，正在进行的工作。
[PILCPEP] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[PILCPEP]Border，J.，Kojo，M.，Griner，J.，黑山，G.和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 31352001年6月。
[RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP]Borella，M.，Lo，J.，Grabelsky，D.和G.黑山，“特定领域知识产权：框架”，RFC 3102，2001年10月。
[SALTZER] End-To-End Arguments in System Design, J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.
[SALTZER]系统设计中的端到端参数，J.H.SALTZER，D.P.Reed，D.D.Clark，ACM TOCS，第2卷，第4期，1984年11月，第277-288页。
[SIPFIRE] S. Moyer, D. Marples, S. Tsang, J. Katz, P. Gurung, T. Cheng, A. Dutta, H. Schulzrinne, A. Roychowdhury, "Framework Draft for Networked Appliances Using the Session Initiation Protocol", Work in Progress.
[SIPFIRE]S.Moyer，D.Marples，S.Tsang，J.Katz，P.Gurung，T.Cheng，A.Dutta，H.Schulzrinne，A.Roychowdhury，“使用会话启动协议的网络设备框架草案”，正在进行中。
[SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[SOCKS6]Kitamura，H.，“基于SOCKS的IPv6/IPv4网关机制”，RFC 3089，2001年4月。
[TRANS64] "Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication", Work in Progress.
[TRANS64]“仅IPv6与仅IPv4通信的过渡技术概述”，正在进行中。
[WREC] Cooper, I, Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[WREC]Cooper，I，Melve，I.和G.Tomlinson，“互联网Web复制和缓存分类法”，RFC 3040，2001年1月。
[XMLPI] Intermediaries and XML Protocol, Mark Nottingham, Work in
Progress at http://lists.w3.org/Archives/Public/xml-dist-
app/2001Mar/0045.html
[XMLPI] Intermediaries and XML Protocol, Mark Nottingham, Work in
Progress at http://lists.w3.org/Archives/Public/xml-dist-
app/2001Mar/0045.html
Authors' Addresses
作者地址
Brian E. Carpenter IBM Zurich Research Laboratory Saeumerstrasse 4 / Postfach 8803 Rueschlikon Switzerland
Brian E.Carpenter IBM苏黎世研究实验室Saeumerstrasse 4/Postfach 8803瑞士鲁埃施利肯
EMail: brian@hursley.ibm.com
EMail: brian@hursley.ibm.com
Scott W. Brim 146 Honness Lane Ithaca, NY 14850 USA
斯科特W.布里姆美国纽约州伊萨卡Honness Lane 146号，邮编14850
EMail: sbrim@cisco.com
EMail: sbrim@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 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.
RFC编辑功能的资金目前由互联网协会提供。