Network Working Group B. Aboba, Ed.
Request for Comment: 4924 E. Davies
Category: Informational Internet Architecture Board
July 2007
Network Working Group B. Aboba, Ed.
Request for Comment: 4924 E. Davies
Category: Informational Internet Architecture Board
July 2007
Reflections on 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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts.
本文件回顾了IAB先前关于互联网透明度的声明，并讨论了新的透明度问题。有意或无意阻碍网络透明度的技术影响非但没有降低相关性，反而在互联网支持创新和全球传播的能力方面发挥了关键作用。本文件提供了这些潜在影响的一些具体说明。
Table of Contents
目录
1. Introduction ....................................................2
2. Additional Transparency Issues ..................................4
2.1. Application Restriction ....................................4
2.2. Quality of Service (QoS) ...................................6
2.3. Application Layer Gateways (ALGs) ..........................7
2.4. IPv6 Address Restrictions ..................................8
2.4.1. Allocation of IPv6 Addresses by Providers ...........8
2.4.2. IKEv2 ...............................................8
2.5. DNS Issues .................................................9
2.5.1. Unique Root .........................................9
2.5.2. Namespace Mangling ..................................9
2.6. Load Balancing and Redirection ............................10
3. Security Considerations ........................................11
4. References .....................................................11
4.1. Informative References ....................................11
Acknowledgments ...................................................13
Appendix A - IAB Members at the Time of Approval ..................14
1. Introduction ....................................................2
2. Additional Transparency Issues ..................................4
2.1. Application Restriction ....................................4
2.2. Quality of Service (QoS) ...................................6
2.3. Application Layer Gateways (ALGs) ..........................7
2.4. IPv6 Address Restrictions ..................................8
2.4.1. Allocation of IPv6 Addresses by Providers ...........8
2.4.2. IKEv2 ...............................................8
2.5. DNS Issues .................................................9
2.5.1. Unique Root .........................................9
2.5.2. Namespace Mangling ..................................9
2.6. Load Balancing and Redirection ............................10
3. Security Considerations ........................................11
4. References .....................................................11
4.1. Informative References ....................................11
Acknowledgments ...................................................13
Appendix A - IAB Members at the Time of Approval ..................14
In the past, the IAB has published a number of documents relating to Internet transparency and the end-to-end principle, and other IETF documents have also touched on these issues as well. These documents articulate the general principles on which the Internet architecture is based, as well as the core values that the Internet community seeks to protect going forward. This document reaffirms those principles, describes the concept of "oblivious transport" as developed in the DARPA NewArch project [NewArch], and addresses a number of new transparency issues.
在过去，IAB发布了许多与互联网透明度和端到端原则相关的文件，其他IETF文件也涉及这些问题。这些文件阐明了互联网架构所基于的一般原则，以及互联网社区今后寻求保护的核心价值观。本文件重申了这些原则，描述了DARPA NewArch项目[NewArch]中开发的“不经意运输”概念，并解决了一些新的透明度问题。
A network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.
不过滤或转换其承载的数据的网络可以被称为对分组的内容“透明”或“不经意”。提供不经意传输的网络允许部署新服务，而无需更改核心。正是这种灵活性可能是互联网最基本的特征，也是互联网成功的最重要因素之一。
"Architectural Principles of the Internet" [RFC1958], Section 2 describes the core tenets of the Internet architecture:
“互联网架构原则”[RFC1958]，第2节描述了互联网架构的核心原则：
However, in very general terms, the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.
然而，一般来说，社区认为目标是连通性，工具是互联网协议，智能是端到端的，而不是隐藏在网络中。
The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web. This connectivity requires technical cooperation between service providers, and flourishes in the increasingly liberal and competitive commercial telecommunications environment.
目前网络的指数级增长似乎表明，连通性本身就是一种回报，比邮件或万维网等任何单个应用程序都更有价值。这种连接需要服务提供商之间的技术合作，并在日益自由和竞争激烈的商业电信环境中蓬勃发展。
"The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture" [RFC3724], Section 4.1.1 describes some of the desirable consequences of this approach:
“中部崛起和端到端的未来：对互联网体系结构演变的思考”[RFC3724]，第4.1.1节描述了这种方法的一些理想结果：
One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes. The counterargument - that many end nodes are now essentially closed boxes which are not updatable and that most users don't want to update them anyway - does not apply to all nodes and all users. Many end nodes are still user configurable and a sizable percentage of users are "early adopters," who are willing to put up with a certain amount of technological grief in order to try out a new idea. And, even for
端到端原则的一个可取结果是保护创新。为了部署新服务而需要在网络中进行修改通常比修改终端节点更加困难。相反的论点——许多终端节点现在基本上是封闭的，不可更新，而且大多数用户无论如何都不想更新它们——并不适用于所有节点和所有用户。许多终端节点仍然是用户可配置的，相当大比例的用户是“早期采用者”，他们愿意忍受一定程度的技术痛苦，以尝试新想法。而且，即使是
the closed boxes and uninvolved users, downloadable code that abides by the end-to-end principle can provide fast service innovation. Requiring someone with a new idea for a service to convince a bunch of ISPs or corporate network administrators to modify their networks is much more difficult than simply putting up a Web page with some downloadable software implementing the service.
封闭的盒子和未涉及的用户，遵循端到端原则的可下载代码可以提供快速的服务创新。要求对服务有新想法的人说服一群ISP或公司网络管理员修改他们的网络比简单地在网页上放一些可下载的软件来实现服务要困难得多。
Yet, even while the Internet has greatly expanded both in size and in application diversity, the degree of transparency has diminished. "Internet Transparency" [RFC2775] notes some of the causes for the loss of Internet transparency and analyzes their impact. This includes discussion of Network Address Translators (NATs), firewalls, application level gateways (ALGs), relays, proxies, caches, split Domain Name Service (DNS), load balancers, etc. [RFC2775] also analyzes potential future directions that could lead to the restoration of transparency. Section 6 summarizes the conclusions:
然而，尽管互联网在规模和应用多样性方面都有了极大的扩展，但其透明度却有所下降。“互联网透明度”[RFC2775]指出了互联网透明度丧失的一些原因，并分析了其影响。这包括对网络地址转换器（NAT）、防火墙、应用程序级网关（ALG）、中继、代理、缓存、拆分域名服务（DNS）、负载平衡器等的讨论。[RFC2775]还分析了可能导致恢复透明度的潜在未来方向。第6节总结了结论：
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的部分部署是实现全面部署的必要步骤，也是一件麻烦事，但避免了死路一条。
While full restoration of Internet transparency through the deployment of IPv6 remains a goal, the Internet's growing role in society, the increasing diversity of applications, and the continued growth in security threats has altered the balance between transparency and security, and the disparate goals of interested parties make these tradeoffs inherently complex.
虽然通过部署IPv6全面恢复互联网透明度仍然是一个目标，但互联网在社会中的作用日益增强、应用程序日益多样化以及安全威胁的持续增长改变了透明度和安全性之间的平衡，利益相关方的不同目标使得这些权衡内在地复杂。
While transparency provides great flexibility, it also makes it easier to deliver unwanted as well as wanted traffic. Unwanted traffic is increasingly cited as a justification for limiting transparency. If taken to its logical conclusion, this argument will lead to the development of ever more complex transparency barriers to counter increasingly sophisticated security threats. Transparency, once lost, is hard to regain, so that such an approach, if unsuccessful, would lead to an Internet that is both insecure and lacking in transparency. The alternative is to develop increasingly sophisticated host-based security mechanisms; while such an approach may also fail to keep up with increasingly sophisticated security threats, it is less likely to sacrifice transparency in the process.
虽然透明性提供了极大的灵活性，但它也使交付不想要的和想要的流量变得更加容易。不必要的流量越来越多地被引用为限制透明度的理由。如果从逻辑上得出结论，这一论点将导致制定更加复杂的透明度壁垒，以应对日益复杂的安全威胁。透明度一旦失去，就很难恢复，因此这种方法如果不成功，将导致互联网既不安全又缺乏透明度。另一种选择是开发越来越复杂的基于主机的安全机制；虽然这种方法也可能无法跟上日益复杂的安全威胁，但它不太可能牺牲过程中的透明度。
Since many of the fundamental forces that have led to a reduction in the transparency of the IPv4 Internet also may play a role in the IPv6 Internet, the transparency of the IPv6 Internet is not pre-
由于导致IPv4互联网透明度降低的许多基本因素也可能在IPv6互联网中发挥作用，因此IPv6互联网的透明度并不重要-
ordained, but rather represents an ideal whose maintenance will require significant ongoing effort.
这是注定的，但更确切地说，这代表了一种理想，其维护将需要大量的持续努力。
As noted in [NewArch], the technical cooperation that once characterized the development of the Internet has increasingly given way to a tussle between the interests of subscribers, vendors, providers, and society at large. Oblivious transport may be desired by developers seeking to deploy new services; providers may desire to block unwanted traffic in the core before it impacts subscribers; vendors and providers may wish to enable delivery of "value added" services in the network that enable them to differentiate their offerings; subscribers may be sympathetic to either point of view, depending on their interests; society at large may wish to block "offensive" material and monitor traffic that shows malicious intent.
正如[NewArch]所指出的那样，曾经是互联网发展特征的技术合作已经越来越让位给用户、供应商、提供商和整个社会之间的利益之争。试图部署新服务的开发人员可能需要不经意的传输；提供商可能希望在核心中阻止不必要的流量，以免影响用户；供应商和提供商可能希望能够在网络中提供“增值”服务，使其能够区分其产品；订阅者可能会同情任何一种观点，这取决于他们的利益；整个社会可能希望阻止“攻击性”材料，并监控显示恶意意图的流量。
While there is no architectural "fix" that can restore oblivious transport while satisfying the interests of all parties, it is possible for providers to provide subscribers with information about the nature of the services being provided. Subscribers need to be aware of whether they are receiving oblivious transport, and if not, how the service affects their traffic.
虽然没有体系结构“修复程序”可以在满足各方利益的同时恢复不经意的传输，但提供商可以向订户提供有关所提供服务性质的信息。用户需要知道他们是否正在接收不经意的传输，如果没有，服务如何影响他们的流量。
Since the publication of the previously cited IAB statements, new technologies have been developed, and views on existing technology have changed. In some cases, these new technologies impact oblivious transport, and subscribers need to be aware of the implications for their service.
自从先前引用的IAB声明发表以来，新技术已经开发出来，对现有技术的看法也发生了变化。在某些情况下，这些新技术会影响不经意的传输，用户需要了解其服务的含义。
Since one of the virtues of the Internet architecture is the ease with which new applications can be deployed, practices that restrict the ability to deploy new applications have the potential to reduce innovation.
由于互联网体系结构的优点之一是易于部署新应用程序，因此限制部署新应用程序能力的做法有可能减少创新。
One such practice is filtering designed to block or restrict application usage, implemented without customer consent. This includes Internet, Transport, and Application layer filtering designed to block or restrict traffic associated with one or more applications.
其中一种做法是设计用于阻止或限制应用程序使用的过滤，在未经客户同意的情况下实施。这包括Internet、传输和应用程序层过滤，旨在阻止或限制与一个或多个应用程序关联的流量。
While provider filtering may be useful to address security issues such as attacks on provider infrastructure or denial of service attacks, greater flexibility is provided by allowing filtering to be determined by the customer. Typically, this would be implemented at the edges, such as within provider access routers (e.g., outsourced
虽然提供商筛选可能有助于解决安全问题，如对提供商基础设施的攻击或拒绝服务攻击，但允许客户确定筛选，从而提供了更大的灵活性。通常，这将在边缘实现，例如在提供商访问路由器内（例如，外包）
firewall services), customer premise equipment (e.g., access firewalls), or on hosts (e.g., host firewalls). Deployment of filtering at the edges provides customers with the flexibility to choose which applications they wish to block or restrict, whereas filtering in the core may not permit hosts to communicate, even when the communication would conform to the appropriate use policies of the administrative domains to which those hosts belong.
防火墙服务）、客户现场设备（如访问防火墙）或主机上的设备（如主机防火墙）。在边缘部署过滤为客户提供了选择其希望阻止或限制的应用程序的灵活性，而核心过滤可能不允许主机通信，即使通信符合这些主机所属管理域的适当使用策略。
In practice, filtering intended to block or restrict application usage is difficult to successfully implement without customer consent, since over time developers will tend to re-engineer filtered protocols so as to avoid the filters. Thus over time, filtering is likely to result in interoperability issues or unnecessary complexity. These costs come without the benefit of effective filtering since many application protocols began to use HTTP as a transport protocol after application developers observed that firewalls allow HTTP traffic while dropping packets for unknown protocols.
实际上，未经客户同意，旨在阻止或限制应用程序使用的过滤很难成功实施，因为随着时间的推移，开发人员将倾向于重新设计过滤协议，以避免使用过滤器。因此，随着时间的推移，过滤可能会导致互操作性问题或不必要的复杂性。由于应用程序开发人员发现防火墙允许HTTP通信，同时丢弃未知协议的数据包，因此许多应用程序协议开始使用HTTP作为传输协议，因此这些成本没有得到有效过滤的好处。
In addition to architectural concerns, filtering to block or restrict application usage also raises issues of disclosure and end-user consent. As pointed out in "Terminology for Describing Internet Connectivity" [RFC4084], services advertised as providing "Internet connectivity" differ considerably in their capabilities, leading to confusion. The document defines terminology relating to Internet connectivity, including "Web connectivity", "Client connectivity only, without a public address", "Client only, public address", "Firewalled Internet Connectivity", and "Full Internet Connectivity". With respect to "Full Internet Connectivity" [RFC4084], Section 2 notes:
除了架构方面的考虑外，过滤以阻止或限制应用程序的使用也会引起披露和最终用户同意的问题。正如“描述互联网连接的术语”[RFC4084]中所指出的，广告中所宣传的提供“互联网连接”的服务在功能上存在很大差异，导致混淆。该文件定义了与互联网连接相关的术语，包括“网络连接”、“仅客户端连接，无公共地址”、“仅客户端，公共地址”、“防火墙互联网连接”和“完全互联网连接”。关于“完全互联网连接”[RFC4084]，第2节注释：
Filtering Web proxies, interception proxies, NAT, and other provider-imposed restrictions on inbound or outbound ports and traffic are incompatible with this type of service. Servers ... are typically considered normal. The only compatible restrictions are bandwidth limitations and prohibitions against network abuse or illegal activities.
过滤Web代理、拦截代理、NAT和其他提供商对入站或出站端口和流量施加的限制与此类服务不兼容。服务器。。。通常被认为是正常的。唯一兼容的限制是带宽限制和禁止网络滥用或非法活动。
[RFC4084], Section 4 describes disclosure obligations that apply to all forms of service limitation, whether applied on outbound or inbound traffic:
[RFC4084], Section 4 describes disclosure obligations that apply to all forms of service limitation, whether applied on outbound or inbound traffic:translate error, please retry
More generally, the provider should identify any actions of the service to block, restrict, or alter the destination of, the outbound use (i.e., the use of services not supplied by the provider or on the provider's network) of applications services.
更一般地说，提供商应该识别服务的任何动作，以阻止、限制或改变应用程序服务的出站使用（即，使用非提供商提供的服务或在提供商的网络上的服务）。
In essence, [RFC4084] calls for providers to declare the ways in which the service provided departs from oblivious transport. Since the lack of oblivious transport within transit networks will also affect transparency, this also applies to providers over whose network the subscriber's traffic may travel.
本质上，[RFC4084]要求提供者声明所提供的服务偏离不经意传输的方式。由于公交网络中缺乏不经意的传输也会影响透明度，这也适用于用户流量可能通过其网络传输的提供商。
While [RFC4084] notes that bandwidth limitations are compatible with "Full Internet Connectivity", in some cases QoS restrictions may go beyond simple average or peak bandwidth limitations. When used to restrict the ability to deploy new applications, QoS mechanisms are incompatible with "Full Internet Connectivity" as defined in [RFC4084]. The disclosure and consent obligations referred to in [RFC4084], Section 4 also apply to QoS mechanisms.
虽然[RFC4084]指出带宽限制与“完全互联网连接”兼容，但在某些情况下，QoS限制可能超出简单的平均或峰值带宽限制。当用于限制部署新应用程序的能力时，QoS机制与[RFC4084]中定义的“完全互联网连接”不兼容。[RFC4084]第4节中提及的披露和同意义务也适用于QoS机制。
Deployment of QoS technology has potential implications for Internet transparency, since the QoS experienced by a flow can make the Internet more or less oblivious to that flow. While QoS support is highly desirable in order for real-time services to coexist with elastic services, it is not without impact on packet delivery.
QoS技术的部署对互联网的透明度具有潜在的影响，因为流所经历的QoS会使互联网或多或少地忽略该流。虽然为了使实时服务与弹性服务共存，QoS支持是非常理想的，但它并非对数据包交付没有影响。
Specifically, QoS classes such as "default" [RFC2474] or "lower effort" [RFC3662] may experience higher random-loss rates than others such as "assured forwarding" [RFC2597]. Conversely, bandwidth-limited QoS classes such as "expedited forwarding" [RFC3246] may experience systematic packet loss if they exceed their assigned bandwidth. Other QoS mechanisms such as load balancing may have side-effects such as re-ordering of packets, which may have a serious impact on perceived performance.
具体而言，诸如“默认”[RFC2474]或“较低努力”[RFC3662]之类的QoS类可能会经历比诸如“保证转发”[RFC2597]之类的其他类更高的随机丢失率。相反，带宽有限的QoS类，如“加速转发”[RFC3246]，如果超过其分配的带宽，可能会出现系统性的数据包丢失。诸如负载平衡之类的其他QoS机制可能具有诸如分组重新排序之类的副作用，这可能对感知性能产生严重影响。
QoS implementations that reduce the ability to deploy new applications on the Internet are similar in effect to other transparency barriers. Since arbitrary or severe bandwidth limitations can make an application unusable, the introduction of application-specific bandwidth limitations is equivalent to application blocking or restriction from a user's standpoint.
降低在Internet上部署新应用程序能力的QoS实现实际上与其他透明度障碍类似。由于任意或严重的带宽限制会使应用程序无法使用，因此引入特定于应用程序的带宽限制相当于从用户的角度对应用程序进行阻塞或限制。
Using QoS mechanisms to discriminate against traffic not matching a set of services or addresses has a similar effect to deployment of a highly restrictive firewall. Requiring an authenticated RSVP reservation [RFC2747][RFC3182] for a flow to avoid severe packet loss has a similar effect to deployment of authenticated firewall traversal.
使用QoS机制来区分与一组服务或地址不匹配的流量，其效果与部署高度受限的防火墙类似。要求流具有经过身份验证的RSVP保留[RFC2747][RFC3182]以避免严重的数据包丢失，这与部署经过身份验证的防火墙遍历具有类似的效果。
As with filtering, there may be valid uses for customer-imposed QoS restrictions. For example, a customer may wish to limit the bandwidth consumed by peer-to-peer file sharing services, so as to limit the impact on mission-critical applications.
与过滤一样，客户施加的QoS限制也可能有有效的用途。例如，客户可能希望限制对等文件共享服务所消耗的带宽，以限制对任务关键型应用程序的影响。
The IAB has devoted considerable attention to Network Address Translation (NAT), so that there is little need to repeat that discussion here. However, with the passage of time, it has become apparent that there are problems inherent in the deployment of Application Layer Gateways (ALGs) (frequently embedded within firewalls and devices implementing NAT).
IAB对网络地址转换（NAT）给予了相当大的关注，因此这里不需要重复讨论。然而，随着时间的推移，应用层网关（ALG）（通常嵌入在防火墙和实现NAT的设备中）的部署显然存在固有的问题。
[RFC2775], Section 3.5 states:
[RFC2775]第3.5节规定：
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.
如果要使用全套互联网应用程序，NAT必须与应用程序级网关（ALG）或代理相结合。此外，每当出现新的地址相关应用程序时，必须更新ALG或代理。实际上，许多防火墙产品都内置了NAT功能，所有有用的NAT都有相关的ALG，因此很难区分它们的各种影响。
With the passage of time and development of NAT traversal technologies such as IKE NAT-T [RFC3947], Teredo [RFC4380], and STUN [RFC3489], it has become apparent that ALGs represent an additional barrier to transparency. In addition to posing barriers to the deployment of new applications not yet supported by ALGs, ALGs may create difficulties in the deployment of existing applications as well as updated versions. For example, in the development of IKE NAT-T, additional difficulties were presented by "IPsec Helper" ALGs embedded within NATs.
随着时间的推移和诸如IKE NAT-T[RFC3947]、Teredo[RFC4380]和STUN[RFC3489]等NAT穿越技术的发展，ALG显然是透明度的另一个障碍。除了对ALG尚不支持的新应用程序的部署造成障碍外，ALG还可能对现有应用程序以及更新版本的部署造成困难。例如，在IKE NAT-T的开发中，嵌入NAT中的“IPsec助手”ALG带来了额外的困难。
It should be stressed that these difficulties are inherent in the architecture of ALGs, rather than merely an artifact of poor implementations. No matter how well an ALG is implemented, barriers to transparency will emerge over time, so that the notion of a "transparent ALG" is a contradiction in terms.
应该强调的是，这些困难是ALG架构中固有的，而不仅仅是糟糕实现的产物。无论ALG的实施情况如何，随着时间的推移，透明度的障碍都会出现，因此“透明ALG”的概念在术语上是矛盾的。
In particular, DNS ALGs present a host of issues, including incompatibilities with DNSSEC that prevent deployment of a secure naming infrastructure even if all the endpoints are upgraded. For details, see "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status" [RFC4966], Section 3.
特别是，DNS ALG存在一系列问题，包括与DNSSEC的不兼容性，即使所有端点都已升级，也会妨碍安全命名基础设施的部署。有关详细信息，请参阅“将网络地址转换器-协议转换器（NAT-PT）移动到历史状态的原因”[RFC4966]，第3节。
[RFC2775], Section 5.1 states:
[RFC2775]第5.1节规定：
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.
请注意，IPv6的一个基本假设是，地址的提供不会受到人为的限制，因为地址太多了。当前一些ISP强烈限制每个客户端的IPv4地址数的做法将没有理由存在IPv6。
Constraints on the supply of IPv6 addresses provide an incentive for the deployment of NAT with IPv6. The introduction of NAT for IPv6 would represent a barrier to transparency, and therefore is to be avoided if at all possible.
IPv6地址供应的限制为使用IPv6部署NAT提供了激励。为IPv6引入NAT将成为透明度的障碍，因此，如果可能，应尽量避免。
In order to encourage deployments of IPv6 to provide oblivious transport, it is important that IPv6 networks of all sizes be supplied with a prefix sufficient to enable allocation of addresses and sub-networks for all the hosts and links within their network. Initial address allocation policy suggested allocating a /48 prefix to "small" sites, which should handle typical requirements. Any changes to allocation policy should take into account the transparency reduction that will result from further restriction. For example, provider provisioning of a single /64 without support for prefix delegation or (worse still) a longer prefix (prohibited by [RFC4291], Section 2.5.4 for non-000/3 unicast prefixes) would represent a restriction on the availability of IPv6 addresses that could represent a barrier to transparency.
为了鼓励部署IPv6以提供不经意的传输，重要的是为各种规模的IPv6网络提供足够的前缀，以便为其网络中的所有主机和链路分配地址和子网。初始地址分配策略建议将a/48前缀分配给“小型”站点，这应能处理典型需求。对分配政策的任何更改都应考虑到进一步限制将导致的透明度降低。例如，提供商在不支持前缀委派的情况下提供单个/64，或者（更糟糕的是）提供更长的前缀（被[RFC4291]第2.5.4节禁止，用于非000/3单播前缀），这将限制IPv6地址的可用性，这可能会阻碍透明度。
Issues with IPv6 address assignment mechanisms in IKEv2 [RFC4306] are described in [RFC4718]:
[RFC4718]中描述了IKEv2[RFC4306]中IPv6地址分配机制的问题：
IKEv2 also defines configuration payloads for IPv6. However, they are based on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doing things"... In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery.
IKEv2还定义了IPv6的配置有效负载。然而，它们基于相应的IPv4有效负载，并没有完全遵循“正常的IPv6做事方式”。。。特别是，不使用IPv6无状态自动配置或路由器广告消息；邻居发现也不是。
IKEv2 provides for the assignment of a single IPv6 address, using the INTERNAL_IP6_ADDRESS attribute. If this is the only attribute supported for IPv6 address assignment, then only a single IPv6 address will be available. The INTERNAL_IP6_SUBNET attribute enables the host to determine the sub-networks accessible directly through the secure tunnel created; it could potentially be used to assign one
IKEv2使用内部_IP6_address属性提供单个IPv6地址的分配。如果这是IPv6地址分配支持的唯一属性，则只有一个IPv6地址可用。“内部_IP6_子网”属性使主机能够确定可通过创建的安全隧道直接访问的子网；它可能被用来分配一个
or more prefixes to the IKEv2 initiator that could be used for address creation.
可用于地址创建的IKEv2启动器的一个或多个前缀。
However, this does not enable the host to obtain prefixes that can be delegated. The INTERNAL_IP6_DHCP attribute provides the address of a DHCPv6 server, potentially enabling use of DHCPv6 prefix delegation [RFC3633] to obtain additional prefixes. However, in order for implementers to utilize these options in an interoperable way, clarifications to the IKEv2 specification appear to be needed.
但是，这不允许主机获取可以委派的前缀。INTERNAL_IP6_DHCP属性提供DHCPv6服务器的地址，可能允许使用DHCPv6前缀委派[RFC3633]来获取其他前缀。然而，为了让实现者以可互操作的方式利用这些选项，似乎需要对IKEv2规范进行澄清。
In "IAB Technical Comment on the Unique DNS Root" [RFC2826], the technical arguments for a unique root were presented.
在“关于唯一DNS根的IAB技术评论”[RFC2826]中，介绍了唯一根的技术参数。
One of the premises in [RFC2826] is that a common namespace and common semantics applied to these names is needed for effective communication between two parties. The document argues that this principle can only be met when one unique root is being used and when the domains are maintained by single owners or maintainers.
[RFC2826]中的前提之一是，为了在双方之间进行有效的通信，需要对这些名称应用公共名称空间和公共语义。该文件认为，只有当使用一个唯一的根，并且域由单个所有者或维护者维护时，才能满足这一原则。
Because [RFC4084] targets only IP service terms and does not talk about namespace issues, it does not refer to [RFC2826]. We stress that the use of a unique root for the DNS namespace is essential for proper IP service.
因为[RFC4084]只针对IP服务术语，不讨论名称空间问题，所以它没有提到[RFC2826]。我们强调，为DNS名称空间使用唯一根对于正确的IP服务至关重要。
Since the publication of [RFC2826], there have been reports of providers implementing recursive nameservers and/or DNS forwarders that replace answers that indicate that a name does not exist in the DNS hierarchy with a name and an address record that hosts a Web service that is supposed to be useful for end-users.
自[RFC2826]发布以来，有报告称提供商实施了递归名称服务器和/或DNS转发器，这些转发器将指示DNS层次结构中不存在名称的答案替换为承载对最终用户有用的Web服务的名称和地址记录。
The effect of this modification is similar to placement of a wildcard in top-level domains. Although wildcard labels in top-level domains lead to problems that are described elsewhere (such as "The Role of Wildcards in the Domain Name System" [RFC4592]), they do not strictly violate the DNS protocol. This is not the case where modification of answers takes place in the middle of the path between authoritative servers and the stub resolvers that provide the answers to applications.
此修改的效果类似于在顶级域中放置通配符。尽管顶级域中的通配符标签会导致其他地方描述的问题（如“域名系统中通配符的作用”[RFC4592]），但它们并不严格违反DNS协议。这不是修改答案发生在权威服务器和提供应用程序答案的存根解析器之间的路径中间。
[RFC2826] section 1.3 states:
[RFC2826]第1.3节规定：
Both the design and implementations of the DNS protocol are heavily based on the assumption that there is a single owner or maintainer for every domain, and that any set of resources records associated with a domain is modified in a single-copy serializable fashion.
DNS协议的设计和实现都在很大程度上基于这样的假设：每个域都有一个所有者或维护者，并且与域关联的任何一组资源记录都是以单拷贝可序列化的方式修改的。
In particular, the DNSSEC protocol described in "Protocol Modifications for the DNS Security Extensions" [RFC4035] has been designed to verify that DNS information has not been modified between the moment they have been published on an authoritative server and the moment the validation takes place. Since that verification can take place at the application level, any modification by a recursive forwarder or other intermediary will cause validation failures, disabling the improved security that DNSSEC is intended to provide.
特别是，“DNS安全扩展的协议修改”[RFC4035]中描述的DNSSEC协议旨在验证DNS信息在权威服务器上发布到进行验证之间是否未被修改。由于该验证可以在应用程序级别进行，递归转发器或其他中介的任何修改都将导致验证失败，从而禁用DNSSEC打算提供的改进的安全性。
In order to provide information that is adapted to the locale from which a request is made or to provide a speedier service, techniques have been deployed that result in packets being redirected or taking a different path depending on where the request originates. For example, requests may be distributed among servers using "reverse NAT" (which modifies the destination rather than the source address); responses to DNS requests may be altered; HTTP "gets" may be re-directed; or specific packets may be diverted onto overlay networks.
为了提供适合于发出请求的区域设置的信息或提供更快的服务，已经部署了一些技术，这些技术导致数据包被重定向或采用不同的路径，具体取决于请求的发起地。例如，可以使用“反向NAT”（修改目的地而不是源地址）在服务器之间分发请求；可以更改对DNS请求的响应；HTTP“gets”可能被重新定向；或者，可以将特定分组转移到覆盖网络上。
Provided that these services are well-implemented, they can provide value; however, transparency reduction or service disruption can also result:
只要这些服务得到很好的实施，它们就能提供价值；但是，透明度降低或服务中断也可能导致：
[1] The use of "reverse NAT" to balance load among servers supporting IPv6 would adversely affect the transparency of the IPv6 Internet.
[1] 使用“反向NAT”来平衡支持IPv6的服务器之间的负载将对IPv6 Internet的透明度产生不利影响。
[2] DNS re-direction is typically based on the source address of the query, which may not provide information on the location of the host originating the query. As a result, a host configured with the address of a distant DNS server could find itself pointed to a server near the DNS server, rather than a server near the host. HTTP re-direction does not encounter this issue.
[2] DNS重定向通常基于查询的源地址，该地址可能不提供有关发起查询的主机位置的信息。因此，配置了远程DNS服务器地址的主机可能会发现自己指向DNS服务器附近的服务器，而不是主机附近的服务器。HTTP重新定向不会遇到此问题。
[3] If the packet filters that divert packets onto overlay networks are misconfigured, this can lead to packets being misdirected onto the overlay and delayed or lost if the far end cannot return them to the global Internet.
[3] 如果将数据包转移到覆盖网络上的数据包过滤器配置错误，这可能会导致数据包被错误地定向到覆盖网络上，并且如果远端无法将数据包返回到全球互联网，则会导致数据包延迟或丢失。
[4] The use of anycast needs to be carefully thought out so that service can be maintained in the face of routing changes.
[4] 需要仔细考虑anycast的使用，以便在路由更改时能够维护服务。
Several transparency issues discussed in this document (NATs, transparent proxies, DNS namespace mangling) weaken existing end-to-end security guarantees and interfere with the deployment of protocols that would strengthen end-to-end security.
本文档中讨论的几个透明度问题（NAT、透明代理、DNS名称空间混乱）削弱了现有的端到端安全保障，并干扰了加强端到端安全的协议部署。
[RFC2775], Section 7 states:
[RFC2775]第7节规定：
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受到轻微的攻击。内部网中缺乏端到端的安全性也忽略了内部威胁。
Today, malware has evolved to increasingly take advantage of the application-layer as a rich and financially attractive source of security vulnerabilities, as well as a mechanism for penetration of the Intranet/Internet boundary. This has lessened the security value of existing transparency barriers and made it increasingly difficult to prevent the propagation of malware without imposing restrictions on application behavior. However, as with other approaches to application restriction (see Section 2.1), these limitations are most flexibly imposed at the edge.
如今，恶意软件已经演变为越来越多地利用应用层作为安全漏洞的丰富且具有财务吸引力的来源，以及渗透Intranet/Internet边界的机制。这降低了现有透明屏障的安全价值，使得在不限制应用程序行为的情况下防止恶意软件传播变得越来越困难。然而，与应用限制的其他方法一样（见第2.1节），这些限制是在边缘最灵活地施加的。
[NewArch] Clark, D. et al., "New Arch: Future Generation Internet
Architecture",
http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf
[NewArch] Clark, D. et al., "New Arch: Future Generation Internet
Architecture",
http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]互联网体系结构委员会，“IAB关于唯一DNS根的技术评论”，RFC 2826，2000年5月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，和R.Hess，“RSVP的身份表示”，RFC 31822001年10月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662]Bless，R.，Nichols，K.，和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 36622003年12月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724]Kempf，J.，Ed.，Austein，R.，Ed.，和IAB，“中部崛起和端到端的未来：互联网架构演变的思考”，RFC 37242004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, May 2005.
[RFC4084]Klensin，J.，“描述互联网连接的术语”，BCP 104，RFC 4084，2005年5月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.
[RFC4592]Lewis，E.，“通配符在域名系统中的作用”，RFC4592，2006年7月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718]Erenen，P.和P.Hoffman，“IKEv2澄清和实施指南”，RFC 4718，2006年10月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966]Aoun，C.和E.Davies，“将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因”，RFC 4966，2007年7月。
Acknowledgments
致谢
The authors would like to acknowledge Jari Arkko, Stephane Bortzmeyer, Brian Carpenter, Spencer Dawkins, Stephen Kent, Carl Malamud, Danny McPherson, Phil Roberts and Pekka Savola for contributions to this document.
作者要感谢Jari Arkko、Stephane Bortzmeyer、Brian Carpenter、Spencer Dawkins、Stephen Kent、Carl Malamud、Danny McPherson、Phil Roberts和Pekka Savola对本文件的贡献。
Appendix A - IAB Members at the Time of Approval
附录A-批准时的IAB成员
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B.Davies咨询公司Soham，英国剑桥
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。