Network Working Group B. Carpenter
Request for Comments: 2775 IBM
Category: Informational February 2000
Network Working Group B. Carpenter
Request for Comments: 2775 IBM
Category: Informational February 2000
Internet Transparency
互联网透明度
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.
本文档从体系结构的角度描述了Internet的当前状态，重点介绍了端到端连接和透明度问题。最后总结了Internet网络层面临的一些主要架构备选方案。
This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.
本文件被用作1999年7月举行的IAB网络层未来研讨会的投入。因此，它并不声称是完整和确定的，也不提出建议。
Table of Contents
目录
1. Introduction.................................................2
2. Aspects of end-to-end connectivity...........................3
2.1 The end-to-end argument.....................................3
2.2 End-to-end performance......................................4
2.3 End-to-end address transparency.............................4
3. Multiple causes of loss of transparency......................5
3.1 The Intranet model..........................................6
3.2 Dynamic address allocation..................................6
3.2.1 SLIP and PPP..............................................6
3.2.2 DHCP......................................................6
3.3 Firewalls...................................................6
3.3.1 Basic firewalls...........................................6
3.3.2 SOCKS.....................................................7
3.4 Private addresses...........................................7
3.5 Network address translators.................................7
3.6 Application level gateways, relays, proxies, and caches.....8
3.7 Voluntary isolation and peer networks.......................8
1. Introduction.................................................2
2. Aspects of end-to-end connectivity...........................3
2.1 The end-to-end argument.....................................3
2.2 End-to-end performance......................................4
2.3 End-to-end address transparency.............................4
3. Multiple causes of loss of transparency......................5
3.1 The Intranet model..........................................6
3.2 Dynamic address allocation..................................6
3.2.1 SLIP and PPP..............................................6
3.2.2 DHCP......................................................6
3.3 Firewalls...................................................6
3.3.1 Basic firewalls...........................................6
3.3.2 SOCKS.....................................................7
3.4 Private addresses...........................................7
3.5 Network address translators.................................7
3.6 Application level gateways, relays, proxies, and caches.....8
3.7 Voluntary isolation and peer networks.......................8
3.8 Split DNS...................................................9
3.9 Various load-sharing tricks.................................9
4. Summary of current status and impact.........................9
5. Possible future directions..................................11
5.1 Successful migration to IPv6...............................11
5.2 Complete failure of IPv6...................................12
5.2.1 Re-allocating the IPv4 address space.....................12
5.2.2 Exhaustion...............................................13
5.3 Partial deployment of IPv6.................................13
6. Conclusion..................................................13
7. Security Considerations.....................................13
Acknowledgements...............................................14
References.....................................................14
Author's Address...............................................17
Full Copyright Statement.......................................18
3.8 Split DNS...................................................9
3.9 Various load-sharing tricks.................................9
4. Summary of current status and impact.........................9
5. Possible future directions..................................11
5.1 Successful migration to IPv6...............................11
5.2 Complete failure of IPv6...................................12
5.2.1 Re-allocating the IPv4 address space.....................12
5.2.2 Exhaustion...............................................13
5.3 Partial deployment of IPv6.................................13
6. Conclusion..................................................13
7. Security Considerations.....................................13
Acknowledgements...............................................14
References.....................................................14
Author's Address...............................................17
Full Copyright Statement.......................................18
"There's a freedom about the Internet: As long as we accept the rules of sending packets around, we can send packets containing anything to anywhere." [Berners-Lee]
“互联网是自由的：只要我们接受发送数据包的规则，我们就可以将包含任何内容的数据包发送到任何地方。”[Berners Lee]
The Internet is experiencing growing pains which are often referred to as "the end-to-end problem". This document attempts to analyse those growing pains by reviewing the current state of the network layer, especially its progressive loss of transparency. For the purposes of this document, "transparency" refers to the original Internet concept of a single universal logical addressing scheme, and the mechanisms by which packets may flow from source to destination essentially unaltered.
互联网正在经历成长的痛苦，这通常被称为“端到端问题”。本文件试图通过回顾网络层的当前状态，特别是其逐渐丧失的透明度，来分析这些成长的烦恼。在本文件中，“透明性”指单一通用逻辑寻址方案的原始互联网概念，以及数据包从源流向目的地的基本不变的机制。
The causes of this loss of transparency are partly artefacts of parsimonious allocation of the limited address space available to IPv4, and partly the result of broader issues resulting from the widespread use of TCP/IP technology by businesses and consumers. For example, network address translation is an artefact, but Intranets are not.
造成这种透明度损失的部分原因是IPv4可用有限地址空间的吝啬分配造成的，部分原因是企业和消费者广泛使用TCP/IP技术导致的更广泛问题。例如，网络地址转换是一种人工制品，而内部网则不是。
Thus the way forward must recognise the fundamental changes in the usage of TCP/IP that are driving current Internet growth. In one scenario, a complete migration to IPv6 potentially allows the restoration of global address transparency, but without removing firewalls and proxies from the picture. At the other extreme, a total failure of IPv6 leads to complete fragmentation of the network layer, with global connectivity depending on endless patchwork.
因此，前进的道路必须认识到推动当前互联网增长的TCP/IP使用的根本变化。在一种情况下，完全迁移到IPv6可能会恢复全局地址透明度，但不会从图片中删除防火墙和代理。在另一个极端，IPv6的彻底失败导致网络层完全分裂，全球连接依赖于无休止的补丁。
This document does not discuss the routing implications of address space, nor the implications of quality of service management on router state, although both these matters interact with transparency to some extent. It also does not substantively discuss namespace issues.
本文档不讨论地址空间的路由含义，也不讨论服务质量管理对路由器状态的影响，尽管这两个问题在某种程度上与透明度相互作用。它也没有实质性地讨论名称空间问题。
The phrase "end to end", often abbreviated as "e2e", is widely used in architectural discussions of the Internet. For the purposes of this paper, we first present three distinct aspects of end-to-endness.
短语“端到端”，通常缩写为“e2e”，在互联网的架构讨论中被广泛使用。为了本文的目的，我们首先介绍了端到端的三个不同方面。
This is an argument first described in [Saltzer] and reviewed in [RFC 1958], from which an extended quotation follows:
这是一个在[Saltzer]中首次描述并在[RFC 1958]中审查的论点，引文如下：
"The basic argument is that, as a first principle, certain required end-to-end functions can only be performed correctly by the end-systems themselves. A specific case is that any network, however carefully designed, will be subject to failures of transmission at some statistically determined rate. The best way to cope with this is to accept it, and give responsibility for the integrity of communication to the end systems. Another specific case is end-to-end security.
“基本论点是，作为第一个原则，某些必需的端到端功能只能由端系统本身正确执行。具体情况是，任何网络，无论设计多么仔细，都会以某种统计确定的速率发生传输故障。解决这一问题的最佳方法是接受它，即nd负责与终端系统通信的完整性。另一个具体案例是端到端安全。
"To quote from [Saltzer], 'The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)'
“引用[Saltzer]的话，“只有在通信系统端点处的应用程序的知识和帮助下，才能完全正确地实现该功能。因此，将该功能作为通信系统本身的一项功能是不可能的。（有时，通信系统提供的功能的不完整版本可能有助于提高性能。）
"This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes."
“如果我们要求应用程序在部分网络故障下生存，则此原则具有重要影响。端到端协议设计不应依赖于状态维护（即有关端到端通信状态的信息）在网络内部。这样的状态应该只在端点中保持，这样的状态只有在端点本身中断时才能被破坏（称为命运共享）。由此产生的一个直接后果是，数据报优于传统的虚拟电路。网络的工作是尽可能高效灵活地传输数据报。其他一切都应在边缘进行。”
Thus this first aspect of end-to-endness limits what the network is expected to do, and clarifies what the end-system is expected to do. The end-to-end argument underlies the rest of this document.
因此，端到端的第一个方面限制了网络的预期功能，并澄清了终端系统的预期功能。端到端参数是本文档其余部分的基础。
Another aspect, in which the behaviour of the network and that of the end-systems interact in a complex way, is performance, in a generalised sense. This is not a primary focus of the present document, but it is mentioned briefly since it is often referred to when discussing end-to-end issues.
网络行为和终端系统行为以复杂方式相互作用的另一个方面是广义上的性能。这不是本文件的主要重点，但由于在讨论端到端问题时经常提到这一点，因此对其作了简要介绍。
Much work has been done over many years to improve and optimise the performance of TCP. Interestingly, this has led to comparatively minor changes to TCP itself; [STD 7] is still valid apart from minor additions [RFC 1323, RFC 2581, RFC 2018]. However a great deal of knowledge about good practice in TCP implementations has built up, and the queuing and discard mechanisms in routers have been fine-tuned to improve system performance in congested conditions.
多年来，为了改进和优化TCP的性能，已经做了很多工作。有趣的是，这导致了TCP本身相对较小的变化；[STD 7]除少量增加外仍然有效[RFC 1323、RFC 2581、RFC 2018]。然而，关于TCP实现中良好实践的大量知识已经积累起来，路由器中的排队和丢弃机制已经进行了微调，以改善拥塞条件下的系统性能。
Unfortunately all this experience in TCP performance does not help with transport protocols that do not exhibit TCP-like response to congestion [RFC 2309]. Also, the requirement for specified quality of service for different applications and/or customers has led to much new development, especially the Integrated Services [RFC 1633, RFC 2210] and Differentiated Services [RFC 2475] models. At the same time new transport-related protocols have appeared [RFC 1889, RFC 2326] or are in discussion in the IETF. It should also be noted that since the speed of light is not set by an IETF standard, our current notions of end-to-end performance will be largely irrelevant to interplanetary networking.
不幸的是，所有这些TCP性能方面的经验对传输协议都没有帮助，因为这些传输协议没有表现出类似TCP的拥塞响应[RFC 2309]。此外，针对不同应用程序和/或客户的特定服务质量要求带来了许多新的发展，特别是集成服务[RFC 1633、RFC 2210]和差异化服务[RFC 2475]模型。与此同时，新的传输相关协议已经出现[RFC 1889，RFC 2326]，或正在IETF中讨论。还应注意的是，由于光速不是由IETF标准设定的，因此我们目前对端到端性能的概念在很大程度上与星际网络无关。
Thus, despite the fact that performance and congestion issues for TCP are now quite well understood, the arrival of QOS mechanisms and of new transport protocols raise new questions about end-to-end performance, but these are not further discussed here.
因此，尽管TCP的性能和拥塞问题现在已经得到了很好的理解，但QOS机制和新传输协议的出现提出了关于端到端性能的新问题，但这里不再进一步讨论这些问题。
When the catenet concept (a network of networks) was first described by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin in 1974 [CATENET], a clear assumption was that a single logical address space would cover the whole catenet (or Internet as we now know it). This applied not only to the early TCP/IP Internet, but also to the Xerox PUP design, the OSI connectionless network design, XNS, and numerous other proprietary network architectures.
当Cerf在1974年根据Pouzin的早期建议[catenet]于1978年[IEN 48]首次描述catenet概念（网络网络网络）时，一个明确的假设是单个逻辑地址空间将覆盖整个catenet（或我们现在所知的Internet）。这不仅适用于早期的TCP/IP互联网，也适用于Xerox PUP设计、OSI无连接网络设计、XNS和许多其他专有网络架构。
This concept had two clear consequences - packets could flow essentially unaltered throughout the network, and their source and destination addresses could be used as unique labels for the end systems.
这一概念有两个明显的后果——数据包可以在整个网络中基本上不发生变化地流动，并且它们的源地址和目的地址可以用作终端系统的唯一标签。
The first of these consequences is not absolute. In practice changes can be made to packets in transit. Some of these are reversible at the destination (such as fragmentation and compression). Others may be irreversible (such as changing type of service bits or decrementing a hop limit), but do not seriously obstruct the end-to-end principle of Section 2.1. However, any change made to a packet in transit that requires per-flow state information to be kept at an intermediate point would violate the fate-sharing aspect of the end-to-end principle.
第一个后果不是绝对的。实际上，可以对传输中的数据包进行更改。其中一些在目的地是可逆的（例如碎片和压缩）。其他可能是不可逆的（例如改变服务位的类型或减少跃点限制），但不会严重妨碍第2.1节的端到端原则。然而，对传输中的数据包所做的任何更改，如果要求每个流的状态信息保留在中间点，将违反端到端原则的命运共享方面。
The second consequence, using addresses as unique labels, was in a sense a side-effect of the catenet concept. However, it was a side-effect that came to be highly significant. The uniqueness and durability of addresses have been exploited in many ways, in particular by incorporating them in transport identifiers. Thus they have been built into transport checksums, cryptographic signatures, Web documents, and proprietary software licence servers. [RFC 2101] explores this topic in some detail. Its main conclusion is that IPv4 addresses can no longer be assumed to be either globally unique or invariant, and any protocol or applications design that assumes these properties will fail unpredictably. Work in the IAB and the NAT working group [NAT-ARCH] has analysed the impact of one specific cause of non-uniqueness and non-invariance, i.e., network address translators. Again the conclusion is that many applications will fail, unless they are specifically adapted to avoid the assumption of address transparency. One form of adaptation is the insertion of some form of application level gateway, and another form is for the NAT to modify payloads on the fly, but in either case the adaptation is application-specific.
第二个结果是，使用地址作为唯一的标签，从某种意义上说，这是catenet概念的副作用。然而，这是一个非常显著的副作用。地址的唯一性和持久性已在许多方面得到利用，特别是通过将它们合并到传输标识符中。因此，它们已内置于传输校验和、加密签名、Web文档和专有软件许可服务器中。[RFC 2101]详细探讨了这个主题。其主要结论是，IPv4地址不再被认为是全局唯一的或不变的，任何假定这些属性的协议或应用程序设计都将无法预测地失败。IAB和NAT工作组[NAT-ARCH]的工作分析了非唯一性和非不变性的一个具体原因，即网络地址转换器的影响。再次得出的结论是，许多应用程序都会失败，除非它们经过特别调整以避免地址透明的假设。一种形式的自适应是插入某种形式的应用程序级网关，另一种形式是NAT动态修改有效负载，但在任何一种情况下，自适应都是特定于应用程序的。
Non-transparency of addresses is part of a more general phenomenon. We have to recognise that the Internet has lost end-to-end transparency, and this requires further analysis.
地址不透明是更普遍现象的一部分。我们必须认识到，互联网已经失去了端到端的透明度，这需要进一步分析。
This section describes various recent inventions that have led to the loss of end-to-end transparency in the Internet.
本节描述了导致互联网端到端透明性丧失的各种最新发明。
Underlying a number of the specific developments mentioned below is the concept of an "Intranet", loosely defined as a private corporate network using TCP/IP technology, and connected to the Internet at large in a carefully controlled manner. The Intranet is presumed to be used by corporate employees for business purposes, and to interconnect hosts that carry sensitive or confidential information. It is also held to a higher standard of operational availability than the Internet at large. Its usage can be monitored and controlled, and its resources can be better planned and tuned than those of the public network. These arguments of security and resource management have ensured the dominance of the Intranet model in most corporations and campuses.
下面提到的一些具体发展的基础是“内联网”的概念，它被松散地定义为使用TCP/IP技术的私有公司网络，并以谨慎控制的方式连接到整个互联网。假定企业员工将内部网用于商业目的，并将承载敏感或机密信息的主机互连。它的操作可用性标准也高于整个互联网。它的使用可以被监视和控制，它的资源可以比公共网络的资源得到更好的规划和调整。这些关于安全和资源管理的争论确保了Intranet模式在大多数公司和校园中的主导地位。
The emergence of the Intranet model has had a profound effect on the notion of application transparency. Many corporate network managers feel it is for them alone to determine which applications can traverse the Internet/Intranet boundary. In this world view, address transparency may seem to be an unimportant consideration.
Intranet模型的出现对应用程序透明度的概念产生了深远的影响。许多公司网络经理认为，只有他们自己才能确定哪些应用程序可以穿越Internet/Intranet边界。在这个世界观中，解决透明度问题似乎是一个不重要的考虑因素。
It is to be noted that with the advent of vast numbers of dial-up Internet users, whose addresses are allocated at dial-up time, and whose traffic may be tunneled back to their home ISP, the actual IP addresses of such users are purely transient. During their period of validity they can be relied on end-to-end, but they must be forgotten at the end of every session. In particular they can have no permanent association with the domain name of the host borrowing them.
需要注意的是，随着大量拨号互联网用户的出现，这些用户的地址在拨号时分配，其通信量可以通过隧道传回其家庭ISP，这些用户的实际IP地址纯粹是暂时的。在它们的有效期内，可以端到端地依赖它们，但必须在每次会议结束时忘记它们。特别是，它们可能与借用它们的主机的域名没有永久关联。
Similarly, LAN-based users of the Internet today frequently use DHCP to acquire a new address at system restart, so here again the actual value of the address is potentially transient and must not be stored between sessions.
类似地，今天基于局域网的互联网用户经常在系统重新启动时使用DHCP来获取新地址，因此这里地址的实际值可能是暂时的，不能在会话之间存储。
Intranet managers have a major concern about security: unauthorised traffic must be kept out of the Intranet at all costs. This concern led directly to the firewall concept (a system that intercepts all traffic between the Internet and the Intranet, and only lets through
内联网管理人员主要关心安全问题：必须不惜一切代价将未经授权的流量排除在内联网之外。这一担忧直接导致了防火墙概念（一个拦截互联网和内部网之间所有通信的系统，只允许通过）
selected traffic, usually belonging to a very limited set of applications). Firewalls, by their nature, fundamentally limit transparency.
选定的流量，通常属于一组非常有限的应用程序）。防火墙本质上限制了透明度。
A footnote to the effect of firewalls is the SOCKS mechanism [RFC 1928] by which untrusted applications such as telnet and ftp can punch through a firewall. SOCKS requires a shim library in the Intranet client, and a server in the firewall which is essentially an application level relay. As a result, the remote server does not see the real client; it believes that the firewall is the client.
防火墙效果的一个脚注是SOCKS机制[RFC 1928]，通过该机制，不受信任的应用程序（如telnet和ftp）可以穿透防火墙。SOCKS要求Intranet客户端中有一个垫片库，防火墙中有一个服务器，它本质上是一个应用程序级中继。因此，远程服务器看不到真正的客户端；它认为防火墙就是客户端。
When the threat of IPv4 address exhaustion first arose, and in some cases user sites were known to be "pirating" addresses for private use, a set of official private addresses were hurriedly allocated [RFC 1597] and later more carefully defined [BCP 5]. The legitimate existence of such an address allocation proved to very appealing, so Intranets with large numbers of non-global addresses came into existence. Unfortunately, such addresses by their nature cannot be used for communication across the public Internet; without special measures, hosts using private addresses are cut off from the world.
当IPv4地址耗尽的威胁首次出现时，在某些情况下，用户站点被认为是供私人使用的“盗版”地址，一组官方私人地址被匆忙分配[RFC 1597]，后来被更仔细地定义[BCP 5]。这种地址分配的合法存在被证明是非常有吸引力的，因此具有大量非全局地址的内部网应运而生。不幸的是，这些地址就其性质而言不能用于公共互联网上的通信；如果没有特殊措施，使用私有地址的主机将与世界隔绝。
Note that private address space is sometimes asserted to be a security feature, based on the notion that outside knowledge of internal addresses might help intruders. This is a false argument, since it is trivial to hide addresses by suitable access control lists, even if they are globally unique - indeed that is a basic feature of a filtering router, the simplest form of firewall. A system with a hidden address is just as private as a system with a private address. There is of course no possible point in hiding the addresses of servers to which outside access is required.
注意，私有地址空间有时被断言为一种安全特性，这是基于外部对内部地址的了解可能有助于入侵者的概念。这是一个错误的论点，因为通过适当的访问控制列表隐藏地址是微不足道的，即使它们是全局唯一的——事实上，这是过滤路由器（防火墙的最简单形式）的一个基本功能。具有隐藏地址的系统与具有私有地址的系统一样私有。当然，隐藏需要外部访问的服务器地址是没有意义的。
It is also worth noting that the IPv6 equivalent of private addresses, i.e. site-local addresses, have similar characteristics to BCP 5 addresses, but their use will not be forced by a lack of globally unique IPv6 addresses.
还值得注意的是，专用地址（即站点本地地址）的IPv6等价物具有与BCP 5地址类似的特征，但它们的使用不会因为缺少全局唯一的IPv6地址而被迫进行。
Network address translators (NATs) are an almost inevitable consequence of the existence of Intranets using private addresses yet needing to communicate with the Internet at large. Their architectural implications are discussed at length in [NAT-ARCH], the fundamental point being that address translation on the fly destroys end-to-end address transparency and breaks any middleware or
网络地址转换器（NAT）几乎是使用私有地址的内部网存在的必然结果，但需要与整个互联网进行通信。在[NAT-ARCH]中详细讨论了它们的体系结构含义，其基本点是动态地址转换会破坏端到端地址的透明度，并破坏任何中间件或应用程序
applications that depend on it. Numerous protocols, for example H.323, carry IP addresses at application level and fail to traverse a simple NAT box correctly. If the full range of Internet applications is to be used, NATs have to be coupled with application level gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be updated whenever a new address-dependent application comes along. In practice, NAT functionality is built into many firewall products, and all useful NATs have associated ALGs, so it is difficult to disentangle their various impacts.
依赖于它的应用程序。许多协议，例如H.323，在应用程序级别携带IP地址，并且无法正确地穿越简单的NAT盒。如果要使用全套互联网应用程序，NAT必须与应用程序级网关（ALG）或代理相结合。此外，每当出现新的地址相关应用程序时，必须更新ALG或代理。实际上，许多防火墙产品都内置了NAT功能，所有有用的NAT都有相关的ALG，因此很难区分它们的各种影响。
It is reasonable to position application level gateways, relays, proxies, and caches at certain critical topological points, especially the Intranet/Internet boundary. For example, if an Intranet does not use SMTP as its mail protocol, an SMTP gateway is needed. Even in the normal case, an SMTP relay is common, and can perform useful mail routing functions, spam filtering, etc. (It may be observed that spam filtering is in some ways a firewall function, but the store-and-forward nature of electronic mail and the availability of MX records allow it to be a distinct and separate function.)
将应用程序级网关、中继、代理和缓存定位在某些关键拓扑点（特别是Intranet/Internet边界）是合理的。例如，如果内部网不使用SMTP作为其邮件协议，则需要SMTP网关。即使在正常情况下，SMTP中继也是常见的，并且可以执行有用的邮件路由功能、垃圾邮件过滤等（可以观察到，垃圾邮件过滤在某些方面是防火墙功能，但电子邮件的存储转发性质和MX记录的可用性使其成为一种独特和独立的功能。）
Similarly, for a protocol such as HTTP with a well-defined voluntary proxy mechanism, application proxies also serving as caches are very useful. Although these devices interfere with transparency, they do so in a precise way, correctly terminating network, transport and application protocols on both sides. They can however exhibit some shortfalls in ease of configuration and failover.
类似地，对于具有定义良好的自愿代理机制的HTTP等协议，也用作缓存的应用程序代理非常有用。尽管这些设备会干扰透明度，但它们会以精确的方式进行，正确地终止双方的网络、传输和应用程序协议。但是，它们在易于配置和故障切换方面可能存在一些不足。
However, there appear to be cases of "involuntary" applications level devices such as proxies that grab and modify HTTP traffic without using the appropriate mechanisms, sometimes known as "transparent caches", or mail relays that purport to remove undesirable words. These devices are by definition not transparent, and may have totally unforeseeable side effects. (A possible conclusion is that even for non-store-and-forward protocols, a generic diversion mechanism analogous to the MX record would be of benefit. The SRV record [RFC 2052] is a step in this direction.)
然而，似乎存在“非自愿”应用程序级设备的情况，如代理，它们在不使用适当机制（有时称为“透明缓存”）的情况下捕获和修改HTTP流量，或声称删除不需要的字的邮件中继。根据定义，这些设备是不透明的，并且可能有完全不可预见的副作用。（一个可能的结论是，即使对于非存储和转发协议，一个类似于MX记录的通用转移机制也是有益的。SRV记录[RFC 2052]就是朝着这个方向迈出的一步。）
There are communities that think of themselves as being so different that they require isolation via an explicit proxy, and even by using proprietary protocols and addressing schemes within their network. An example is the WAP Forum which targets very small phone-like devices with some capabilities for Internet connectivity. However, it's not
有些社区认为自己与众不同，因此需要通过显式代理进行隔离，甚至需要在网络中使用专有协议和寻址方案。WAP论坛就是一个例子，它的目标是非常小的类似手机的设备，具有一定的互联网连接能力。然而，事实并非如此
the Internet they're connecting directly to. They have to go through a proxy. This could potentially mean that millions of devices will never know the benefits of end-to-end connectivity to the Internet.
他们直接连接的互联网。他们必须通过代理。这可能意味着数以百万计的设备永远不会知道端到端连接到互联网的好处。
A similar effect arises when applications such as telephony span both an IP network and a peer network layer using a different technology. Although the application may work end-to-end, there is no possibility of end-to-end packet transmission.
当电话等应用程序使用不同的技术跨越IP网络和对等网络层时，也会产生类似的效果。尽管应用程序可以端到端地工作，但不存在端到端分组传输的可能性。
Another consequence of the Intranet/Internet split is "split DNS" or "two faced DNS", where a corporate network serves up partly or completely different DNS inside and outside its firewall. There are many possible variants on this; the basic point is that the correspondence between a given FQDN (fully qualified domain name) and a given IPv4 address is no longer universal and stable over long periods.
内联网/互联网拆分的另一个后果是“拆分DNS”或“双面DNS”，即公司网络在其防火墙内外提供部分或完全不同的DNS。在这方面有许多可能的变体；基本点是，给定的FQDN（完全限定域名）和给定的IPv4地址之间的对应关系不再是通用的，也不再是长期稳定的。
IPv4 was not designed to support anycast [RFC 1546], so there is no natural approach to load-sharing when one server cannot do the job. Various tricks have been used to resolve this (multicast to find a free server, the DNS returns different addresses for the same FQDN in a round-robin, a router actually routes packets sent to the same address automatically to different servers, etc.). While these tricks are not particularly harmful in the overall picture, they can be implemented in such a way as to interfere with name or address transparency.
IPv4不是为支持选播而设计的[RFC 1546]，因此当一台服务器无法完成任务时，没有自然的负载共享方法。已经使用了各种技巧来解决这一问题（多播查找空闲服务器，DNS在循环中为同一FQDN返回不同的地址，路由器实际上会将发送到同一地址的数据包自动路由到不同的服务器，等等）。虽然这些伎俩在总体上并不特别有害，但它们的实施方式可能会干扰姓名或地址的透明度。
It is impossible to estimate with any numerical reliability how widely the above inventions have been deployed. Since many of them preserve the illusion of transparency while actually interfering with it, they are extremely difficult to measure.
用任何数字可靠性都无法估计上述发明的应用范围有多广。由于它们中的许多在实际干扰透明度的同时保留了透明度的假象，因此它们极难测量。
However it is certain that all the mechanisms just described are in very widespread use; they are not a marginal phenomenon. In corporate networks, many of them are the norm. Some of them (firewalls, relays, proxies and caches) clearly have intrinsic value given the Intranet concept. The others are largely artefacts and pragmatic responses to various pressures in the operational Internet, and they must be costing the industry very dearly in constant administration and complex fault diagnosis.
然而，可以肯定的是，刚才描述的所有机制都得到了非常广泛的使用；它们不是边缘现象。在企业网络中，很多都是标准的。考虑到内部网的概念，其中一些（防火墙、中继、代理和缓存）显然具有内在价值。其他的主要是人工制品和对运营互联网中各种压力的务实反应，它们必须在不断的管理和复杂的故障诊断方面为行业付出高昂的成本。
In particular, the decline of transparency is having a severe effect on deployment of end-to-end IP security. The Internet security model [SECMECH] calls for security at several levels (roughly, network, applications, and object levels). The current network level security model [RFC 2401] was constructed prior to the recognition that end-to-end address transparency was under severe threat. Although alternative proposals have begun to emerge [HIP] the current reality is that IPSEC cannot be deployed end-to-end in the general case. Tunnel-mode IPSEC can be deployed between corporate gateways or firewalls. Transport-mode IPSEC can be deployed within a corporate network in some cases, but it cannot span from Intranet to Internet and back to another Intranet if there is any chance of a NAT along the way.
特别是，透明度的下降对端到端IP安全的部署产生了严重影响。互联网安全模型[SECMECH]要求在多个级别（大致上是网络、应用程序和对象级别）实现安全。当前的网络级安全模型[RFC 2401]是在认识到端到端地址透明性受到严重威胁之前构建的。尽管替代方案已经开始出现，但目前的现实是，在一般情况下，IPSEC无法端到端部署。隧道模式IPSEC可以部署在公司网关或防火墙之间。在某些情况下，传输模式IPSEC可以部署在公司网络中，但如果途中有可能发生NAT，则它不能从Intranet跨到Internet再跨回到另一Intranet。
Indeed, NAT breaks other security mechanisms as well, such as DNSSEC and Kerberos, since they rely on address values.
事实上，NAT也破坏了其他安全机制，如DNSSEC和Kerberos，因为它们依赖于地址值。
The loss of transparency brought about by private addresses and NATs affects many applications protocols to a greater or lesser extent. This is explored in detail in [NAT-PROT]. A more subtle effect is that the prevalence of dynamic addresses (from DHCP, SLIP and PPP) has fed upon the trend towards client/server computing. Today it is largely true that servers have fixed addresses, clients have dynamic addresses, and servers can in no way assume that a client's IP address identifies the client. On the other hand, clients rely on servers having stable addresses since a DNS lookup is the only generally deployed mechanism by which a client can find a server and solicit service. In this environment, there is little scope for true peer-to-peer applications protocols, and no easy solution for mobile servers. Indeed, the very limited demand for Mobile IP might be partly attributed to the market dominance of client/server applications in which the client's address is of transient significance. We also see a trend towards single points of failure such as media gateways, again resulting from the difficulty of implementing peer-to-peer solutions directly between clients with no fixed address.
私有地址和NAT带来的透明度损失或多或少地影响了许多应用程序协议。[NAT-PROT]对此进行了详细探讨。一个更微妙的影响是，动态地址（来自DHCP、SLIP和PPP）的流行助长了客户机/服务器计算的趋势。如今，服务器有固定地址，客户端有动态地址，服务器绝不能假定客户端的IP地址标识客户端，这在很大程度上是正确的。另一方面，客户端依赖于具有稳定地址的服务器，因为DNS查找是客户端可以找到服务器并请求服务的唯一通常部署的机制。在这种环境中，真正的对等应用程序协议的应用范围很小，移动服务器也没有简单的解决方案。事实上，对移动IP的需求非常有限，部分原因可能是由于客户机/服务器应用程序的市场主导地位，在这些应用程序中，客户机地址具有短暂的重要性。我们还看到了单点故障（如媒体网关）的趋势，这也是由于在没有固定地址的客户端之间直接实现点对点解决方案的困难造成的。
The notion that servers can use precious globally unique addresses from a small pool, because there will always be fewer servers than clients, may become anachronistic when most electrical devices become network-manageable and thus become servers for a management protocol. Similarly, if every PC becomes a telephone (or the converse), capable of receiving unsolicited incoming calls, the lack of stable IP addresses for PCs will be an issue. Another impending paradigm shift is when domestic and small-office subscribers move from dial-up to always-on Internet connectivity, at which point transient address assignment from a pool becomes much less appropriate.
服务器可以从一个小的池中使用宝贵的全局唯一地址的概念，因为服务器总是比客户端少，当大多数电子设备变得可网络管理，从而成为管理协议的服务器时，这种概念可能会变得不合时宜。类似地，如果每台电脑都变成一部电话（反之亦然），能够接收未经请求的来电，那么电脑缺乏稳定的IP地址将是一个问题。另一个迫在眉睫的范式转变是，家庭和小型办公室用户从拨号上网转向始终在线的互联网连接，此时从池中分配临时地址就变得不太合适了。
Many of the inventions described in the previous section lead to the datagram traffic between two hosts being directly or indirectly mediated by at least one other host. For example a client may depend on a DHCP server, a server may depend on a NAT, and any host may depend on a firewall. This violates the fate-sharing principle of [Saltzer] and introduces single points of failure. Worse, most of these points of failure require configuration data, yet another source of operational risk. The original notion that datagrams would find their way around failures, especially around failed routers, has been lost; indeed the overloading of border routers with additional functions has turned them into critical rather than redundant components, even for multihomed sites.
前一节中描述的许多发明导致两个主机之间的数据报通信量直接或间接地由至少一个其他主机介导。例如，客户端可能依赖于DHCP服务器，服务器可能依赖于NAT，任何主机都可能依赖于防火墙。这违反了[Saltzer]的命运共享原则，并引入了单点故障。更糟糕的是，大多数故障点都需要配置数据，这是操作风险的另一个来源。原先认为数据报可以绕过故障，特别是路由器故障的想法已经不复存在；事实上，边界路由器的过载和附加功能已经将它们变成了关键组件，而不是冗余组件，即使对于多宿主站点也是如此。
The loss of address transparency has other negative effects. For example, large scale servers may use heuristics or even formal policies that assign different priorities to service for different clients, based on their addresses. As addresses lose their global meaning, this mechanism will fail. Similarly, any anti-spam or anti-spoofing techniques that rely on reverse DNS lookup of address values can be confused by translated addresses. (Uncoordinated renumbering can have similar disadvantages.)
地址透明度的丧失还有其他负面影响。例如，大型服务器可能会使用试探法，甚至正式的策略，根据不同的客户机的地址为其分配不同的服务优先级。随着地址失去其全局意义，这种机制将失败。类似地，任何依赖于地址值的反向DNS查找的反垃圾邮件或反欺骗技术都可能被翻译的地址混淆。（不协调的重新编号可能有类似的缺点。）
The above issues are not academic. They add up to complexity in applications design, complexity in network configuration, complexity in security mechanisms, and complexity in network management. Specifically, they make fault diagnosis much harder, and by introducing more single points of failure, they make faults more likely to occur.
上述问题不是学术性的。它们增加了应用程序设计的复杂性、网络配置的复杂性、安全机制的复杂性以及网络管理的复杂性。具体而言，它们使故障诊断更加困难，并且通过引入更多单点故障，使故障更容易发生。
In this scenario, IPv6 becomes fully implemented on all hosts and routers, including the adaptation of middleware, applications, and management systems. Since the address space then becomes big enough for all conceivable needs, address transparency can be restored. Transport-mode IPSEC can in principle deploy, given adequate security policy tools and a key infrastructure. However, it is widely believed that the Intranet/firewall model will certainly persist.
在这种情况下，IPv6将在所有主机和路由器上完全实现，包括中间件、应用程序和管理系统的适应。由于地址空间变得足够大，可以满足所有可能的需求，因此可以恢复地址透明度。如果有足够的安全策略工具和关键基础设施，原则上可以部署传输模式IPSEC。然而，人们普遍认为，内联网/防火墙模式肯定会持续下去。
Note that it is a basic assumption of IPv6 that no artificial constraints will be placed on the supply of addresses, given that there are so many of them. Current practices by which some ISPs strongly limit the number of IPv4 addresses per client will have no reason to exist for IPv6. (However, addresses will still be assigned prudently, according to guidelines designed to favour hierarchical routing.)
请注意，IPv6的一个基本假设是，地址的提供不会受到人为的限制，因为地址太多了。当前一些ISP强烈限制每个客户端的IPv4地址数的做法将没有理由存在IPv6。（不过，根据有利于分层路由的指导方针，地址分配仍将谨慎。）
Clearly this is in any case a very long term scenario, since it assumes that IPv4 has declined to the point where IPv6 is required for universal connectivity. Thus, a viable version of Scenario 5.3 is a prerequisite for Scenario 5.1.
显然，这在任何情况下都是一个非常长期的场景，因为它假设IPv4已经下降到需要IPv6才能实现通用连接的程度。因此，场景5.3的可行版本是场景5.1的先决条件。
In this scenario, IPv6 fails to reach any significant level of operational deployment, IPv4 addressing is the only available mechanism, and address transparency cannot be restored. IPSEC cannot be deployed globally in its current form. In the very long term, the pool of globally unique IPv4 addresses will be nearly totally allocated, and new addresses will generally not be available for any purpose.
在这种情况下，IPv6无法达到任何重要的操作部署级别，IPv4寻址是唯一可用的机制，并且无法恢复地址透明度。无法以当前形式全局部署IPSEC。从长远来看，全球唯一IPv4地址池将几乎完全分配，新地址通常不会用于任何目的。
It is unclear exactly what is likely to happen if the Internet continues to rely exclusively on IPv4, because in that eventuality a variety of schemes are likely to promulgated, with a view toward providing an acceptable evolutionary path for the network. However, we can examine two of the more simplistic sub-scenarios which are possible, while realising that the future would be unlikely to match either one exactly:
如果互联网继续完全依赖IPv4，究竟会发生什么还不清楚，因为在这种情况下，可能会颁布各种方案，以期为网络提供一条可接受的进化路径。然而，我们可以研究两种可能的更简单的子场景，同时认识到未来不可能完全匹配其中一种：
Suppose that a mechanism is created to continuously recover and re-allocate IPv4 addresses. A single global address space is maintained, with all sites progressively moving to an Intranet private address model, with global addresses being assigned temporarily from a pool of several billion.
假设创建了一种机制来持续恢复和重新分配IPv4地址。维护一个单一的全局地址空间，所有站点逐步移动到内部网专用地址模型，全局地址从数十亿个池中临时分配。
5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT (NAT with port number translation). This has the disadvantage that the host is unaware of the unique address being used for its traffic, being aware only of its ambiguous private address, with all the problems that this generates. See [NAT-ARCH].
5.2.1.1 其中的一个子场景是NAT和NAPT（具有端口号转换的NAT）的普遍使用。这样做的缺点是，主机不知道用于其流量的唯一地址，只知道其不明确的专用地址，以及由此产生的所有问题。见[NAT-ARCH]。
5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP addressing implemented at the host rather than by a NAT box. See [RSIP]. In this case the host is aware of its unique address, allowing for substantial restoration of the end-to-end usefulness of addresses, e.g. for TCP or cryptographic checksums.
5.2.1.2 另一个子场景是使用在主机上而不是通过NAT盒实现的领域特定IP寻址。见[RSIP]。在这种情况下，主机知道它的唯一地址，允许地址的端到端有用性的实质性恢复，例如TCP或加密校验和。
5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model in which address translation is replaced by systematic encapsulation of all packets for wide-area transport. This model has never been fully developed, although it is completely compatible with end-to-end addressing.
5.2.1.3 最后一个子场景是“映射和封装”模型，其中地址转换被广域传输的所有数据包的系统封装所取代。尽管该模型与端到端寻址完全兼容，但它从未得到充分开发。
Suppose that no mechanism is created to recover addresses (except perhaps black or open market trading). Sites with large address blocks keep them. All the scenarios of 5.2.1 appear but are insufficient. Eventually the global address space is no longer adequate. This is a nightmare scenario - NATs appear within the "global" address space, for example at ISP-ISP boundaries. It is unclear how a global routing system and a global DNS system can be maintained; the Internet is permanently fragmented.
假设没有创建任何机制来恢复地址（可能除了黑市或公开市场交易）。地址块较大的站点会保留它们。5.2.1中的所有场景都出现了，但还不够。最终，全局地址空间不再足够。这是一个噩梦般的场景-NAT出现在“全局”地址空间中，例如ISP-ISP边界处。目前尚不清楚如何维护全球路由系统和全球DNS系统；互联网永远是支离破碎的。
In this scenario, IPv6 is completely implemented but only deploys in certain segments of the network (e.g. in certain countries, or in certain areas of application such as mobile hand-held devices). Instead of being transitional in nature, some of the IPv6 transition techniques become permanent features of the landscape. Sometimes addresses are 32 bits, sometimes they are 128 bits. DNS lookups may return either or both. In the 32 bit world, the scenarios 5.2.1 and 5.2.2 may occur. IPSEC can only deploy partially.
在这种情况下，IPv6完全实现，但仅部署在网络的某些部分（例如，在某些国家或某些应用领域，如移动手持设备）。一些IPv6过渡技术不再是本质上的过渡，而是成为了这一领域的永久特征。有时地址是32位，有时是128位。DNS查找可能返回其中一个或两个。在32位世界中，可能会出现场景5.2.1和5.2.2。IPSEC只能部分部署。
None of the above scenarios is clean, simple and straightforward. Although the pure IPv6 scenario is the cleanest and simplest, it is not straightforward to reach it. The various scenarios without use of IPv6 are all messy and ultimately seem to lead to dead ends of one kind or another. Partial deployment of IPv6, which is a required step on the road to full deployment, is also messy but avoids the dead ends.
上述场景都不是清晰、简单和直接的。尽管纯IPv6方案是最干净、最简单的方案，但实现它并不容易。不使用IPv6的各种场景都很混乱，最终似乎会导致这样或那样的死胡同。IPv6的部分部署是实现全面部署的必要步骤，也是一件麻烦事，但避免了死路一条。
The loss of transparency is both a bug and a feature from the security viewpoint. To the extent that it prevents the end-to-end deployment of IPSEC, it damages security and creates vulnerabilities. For example, if a standard NAT box is in the path, then the best that can be done is to decrypt and re-encrypt IP traffic in the NAT. The traffic will therefore be momentarily in clear text and potentially vulnerable. Furthermore, the NAT will possess many keys and will be a prime target of attack. In environments where this is unacceptable,
从安全角度来看，透明度的丧失既是一个缺陷也是一个特性。在某种程度上，它会阻止IPSEC的端到端部署，从而破坏安全性并创建漏洞。例如，如果路径中有一个标准NAT框，那么最好的办法就是对NAT中的IP流量进行解密和重新加密。因此，流量将暂时以明文形式显示，并且可能很脆弱。此外，NAT将拥有许多密钥，并且将成为攻击的主要目标。在不可接受的环境中，
encryption must be applied above the network layer instead, of course with no usage whatever of IP addresses in data that is cryptographically protected. See section 4 for further discussion.
加密必须应用在网络层之上，当然，在受加密保护的数据中不使用任何IP地址。有关进一步讨论，请参见第4节。
In certain scenarios, i.e. 5.1 (full IPv6) and 5.2.1.2 (RSIP), end-to-end IPSEC would become possible, especially using the "distributed firewalls" model advocated in [Bellovin].
在某些情况下，即5.1（完整IPv6）和5.2.1.2（RSIP），端到端IPSEC将成为可能，特别是使用[Bellovin]中提倡的“分布式防火墙”模型。
The loss of transparency at the Intranet/Internet boundary may be considered a security feature, since it provides a well defined point at which to apply restrictions. This form of security is subject to the "crunchy outside, soft inside" risk, whereby any successful penetration of the boundary exposes the entire Intranet to trivial attack. The lack of end-to-end security applied within the Intranet also ignores insider threats.
内联网/互联网边界的透明度丧失可能被视为一种安全特征，因为它提供了一个明确的应用限制点。这种形式的安全性受到“外部脆弱，内部软”风险的影响，任何成功渗透边界的行为都会使整个Intranet受到轻微的攻击。内部网中缺乏端到端的安全性也忽略了内部威胁。
It should be noted that security applied above the transport level, such as SSL, SSH, PGP or S/MIME, is not affected by network layer transparency issues.
应该注意，应用于传输级别之上的安全性（如SSL、SSH、PGP或S/MIME）不受网络层透明度问题的影响。
Acknowledgements
致谢
This document and the related issues have been discussed extensively by the IAB. Special thanks to Steve Deering for a detailed review and to Noel Chiappa. Useful comments or ideas were also received from Rob Austein, John Bartas, Jim Bound, Scott Bradner, Vint Cerf, Spencer Dawkins, Anoop Ghanwani, Erik Guttmann, Eric A. Hall, Graham Klyne, Dan Kohn, Gabriel Montenegro, Thomas Narten, Erik Nordmark, Vern Paxson, Michael Quinlan, Eric Rosen, Daniel Senie, Henning Schulzrinne, Bill Sommerfeld, and George Tsirtsis.
IAB对本文件及相关问题进行了广泛讨论。特别感谢Steve Deering的详细评论和Noel Chiappa。Rob Austein、John Bartas、Jim Bound、Scott Bradner、Vint Cerf、Spencer Dawkins、Anoop Ghanwani、Erik Guttman、Eric A.Hall、Graham Klyne、Dan Kohn、Gabriel黑山、Thomas Narten、Erik Nordmark、Vern Paxson、Michael Quinlan、Eric Rosen、Daniel Senie、Henning Schulzrinne、Bill Sommerfeld、，还有乔治·齐尔茨。
References
工具书类
[Bellovin] Distributed Firewalls, S. Bellovin, available at http://www.research.att.com/~smb/papers/distfw.pdf or http://www.research.att.com/~smb/papers/distfw.ps (work in progress).
[Bellovin]分布式防火墙，S.Bellovin，可在http://www.research.att.com/~smb/papers/distfw.pdf或http://www.research.att.com/~smb/papers/distfw.ps（正在进行的工作）。
[Berners-Lee] Weaving the Web, T. Berners-Lee, M. Fischetti, HarperCollins, 1999, p 208.
[Berners Lee]编织网络，T.Berners Lee，M.Fischetti，HarperCollins，1999年，第208页。
[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页。
[IEN 48] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
[IEN 48]Cerf，V.，“互联网的Catenet模型”，国防高级研究计划局信息处理技术办公室，IEN 48，1978年7月。
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks," Proceedings of EUROCOMP, Brunel University, May 1974, pp. 1023-36.
[CATENET]Pouzin，L.，“互连分组交换网络的提案”，布鲁内尔大学欧洲公司学报，1974年5月，第1023-36页。
[STD 7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[STD 7]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[RFC 1546] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC 1546]帕特里奇，C.，门德斯，T.和W.米利肯，“主持任意广播服务”，RFC 1546，1993年11月。
[RFC 1597] Rekhter, Y., Moskowitz, B., Karrenberg, D. and G. de Groot, "Address Allocation for Private Internets", RFC 1597, March 1994.
[RFC 1597]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.和G.de Groot，“私人互联网地址分配”，RFC 1597，1994年3月。
[RFC 1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC 1633]Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 1633，1994年6月。
[RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC 1889]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[BCP 5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[BCP 5]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC 1928]Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.和L.Jones，“袜子协议版本5”，RFC 1928，1996年3月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958]Carpenter，B.，“互联网的建筑原理”，RFC 19581996年6月。
[RFC 2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC 2018]Mathis，M.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC 2052]Gulbrandsen，A.和P.Vixie，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2052，1996年10月。
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC 2101]Carpenter，B.，Crowcroft，J.和Y.Rekhter，“今天的IPv4地址行为”，RFC 2101，1997年2月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC 2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC 2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC 2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC 2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC 2326]Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC 2326，1998年4月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC 2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[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 2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC 2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[NAT-ARCH] Hain, T., "Architectural Implications of NAT", Work in Progress.
[NAT-ARCH]Hain，T.，“NAT的建筑含义”，正在进行中。
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", Work in Progress.
[NAT-PROT]Holdrege，M.和P.Srisuresh，“IP网络地址转换器（NAT）的协议复杂性”，正在进行中。
[SECMECH] Bellovin, S., "Security Mechanisms for the Internet", Work in Progress.
[SECMECH]Bellovin，S.，“互联网的安全机制”，正在进行中。
[RSIP] Lo, J., Borella, M. and D. Grabelsky, "Realm Specific IP: A Framework", Work in Progress.
[RSIP]Lo，J.，Borella，M.和D.Grabelsky，“领域特定IP：框架”，正在进行中。
[HIP] Moskowitz, R., "The Host Identity Payload", Work in Progress.
[HIP]Moskowitz，R.，“主机身份有效负载”，工作正在进行中。
Author's Address
作者地址
Brian E. Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
Brian E.Carpenter IBM c/o iCAIR 150套房美国伊利诺伊州埃文斯顿枫叶大道1890号60201
EMail: brian@icair.org
EMail: brian@icair.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。