Network Working Group M. Kaat
Request for Comments: 2956 SURFnet ExpertiseCentrum bv
Category: Informational October 2000
Network Working Group M. Kaat
Request for Comments: 2956 SURFnet ExpertiseCentrum bv
Category: Informational October 2000
Overview of 1999 IAB Network Layer Workshop
1999年IAB网络层研讨会概述
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 is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
本文件概述了互联网架构委员会（IAB）于1999年7月7日至9日在荷兰乌得勒支举办的互联网网络层架构研讨会。研讨会的目的是了解网络层的状态及其对互联网持续增长和使用的影响。研究了（可预见的）未来的不同技术情景以及外部影响的影响。本报告列出了互联网工程任务组（IETF）社区的结论和建议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Observations . . . . . . . . . . . . . . . 3
2.1 Transparency. . . . . . . . . . . . . . . . . . . . . . 3
2.2 NAT, Application Level Gateways & Firewalls . . . . . . 4
2.3 Identification and Addressing . . . . . . . . . . . . . 4
2.4 Observations on Address Space . . . . . . . . . . . . . 5
2.5 Routing Issues. . . . . . . . . . . . . . . . . . . . . 5
2.6 Observations on Mobility. . . . . . . . . . . . . . . . 6
2.7 DNS Issues. . . . . . . . . . . . . . . . . . . . . . . 7
2.8 NAT and RSIP. . . . . . . . . . . . . . . . . . . . . . 7
2.9 NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . . 8
2.10 Observations on IPv6. . . . . . . . . . . . . . . . . . 9
3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10
3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10
3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10
3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10
3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Observations . . . . . . . . . . . . . . . 3
2.1 Transparency. . . . . . . . . . . . . . . . . . . . . . 3
2.2 NAT, Application Level Gateways & Firewalls . . . . . . 4
2.3 Identification and Addressing . . . . . . . . . . . . . 4
2.4 Observations on Address Space . . . . . . . . . . . . . 5
2.5 Routing Issues. . . . . . . . . . . . . . . . . . . . . 5
2.6 Observations on Mobility. . . . . . . . . . . . . . . . 6
2.7 DNS Issues. . . . . . . . . . . . . . . . . . . . . . . 7
2.8 NAT and RSIP. . . . . . . . . . . . . . . . . . . . . . 7
2.9 NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . . 8
2.10 Observations on IPv6. . . . . . . . . . . . . . . . . . 9
3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10
3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10
3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10
3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10
3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11
3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11
3.6 Recommendations on Routing . . . . . . . . . . . . . . . 12
3.7 Recommendations on Application Layer and APIs. . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . 12
References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Participants. . . . . . . . . . . . . . . . . . . 15
Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11
3.6 Recommendations on Routing . . . . . . . . . . . . . . . 12
3.7 Recommendations on Application Layer and APIs. . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . 12
References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Participants. . . . . . . . . . . . . . . . . . . 15
Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
From July 7 to July 9, 1999 the Internet Architecture Board (IAB) held a workshop on the architecture of the Internet Network Layer. The Network Layer is usually referred to as the IP layer. The goal of the workshop was to discuss the current state of the Network Layer and the impact various currently deployed or future mechanisms and technologies might have on the continued growth and usage of the Internet.
1999年7月7日至7月9日，互联网架构委员会（IAB）举办了一次关于互联网网络层架构的研讨会。网络层通常称为IP层。研讨会的目标是讨论网络层的现状以及当前部署或未来的各种机制和技术可能对互联网的持续增长和使用产生的影响。
The most important issues to be discussed were:
要讨论的最重要问题是：
o Status of IPv6 deployment and transition issues o Alternative technical strategies in case IPv6 is not adopted o Globally unique addresses and 32 bit address depletion o Global connectivity and reachability o Fragmentation of the Internet o End to end transparency and the progressive loss thereof o End to end security o Complications of address sharing mechanisms (NAT, RSIP) o Separation of identification and location in addressing o Architecture and scaling of the current routing system
o IPv6部署和过渡问题的状态o未采用IPv6时的替代技术策略o全球唯一地址和32位地址耗尽o全球连接性和可达性o互联网的碎片化o端到端的透明性和逐渐丢失o端到端的安全性o地址复杂性共享机制（NAT、RSIP）o寻址中标识和位置的分离o架构和当前路由系统的扩展
The participants looked into several technical scenarios and discussed the feasibility and probability of the deployment of each scenario. Among the scenarios were for example full migration to IPv6, IPv6 deployment only in certain segments of the network, no significant deployment of IPv6 and increased segmentation of the IPv4 address space due to the use of NAT devices.
与会者研究了几个技术场景，并讨论了部署每个场景的可行性和可能性。这些场景包括：例如，完全迁移到IPv6、仅在网络的某些部分部署IPv6、没有重大部署IPv6以及由于使用NAT设备而增加的IPv4地址空间分段。
Based on the discussion of these scenarios several trends and external influences were identified which could have a large impact on the status of the network layer, such as the deployment of wireless network technologies, mobile networked devices and special purpose IP devices.
基于对这些场景的讨论，确定了可能对网络层状态产生重大影响的几个趋势和外部影响，如无线网络技术、移动网络设备和专用IP设备的部署。
The following technical issues were identified to be important goals:
以下技术问题被确定为重要目标：
o Deployment of end to end security o Deployment of end to end transport o Global connectivity and reachability should be maintained o It should be easy to deploy new applications o It should be easy to connect new hosts and networks to the Internet ("plug and ping")
o 部署端到端安全o部署端到端传输o应保持全球连接和可达性o应易于部署新应用程序o应易于将新主机和网络连接到Internet（“即插即用”）
By the notion "deployment of end to end transport" it is meant that it is a goal to be able to deploy new applications that span from any host to any other host without intermediaries, and this requires transport protocols with similar span (see also [1]).
“端到端传输的部署”的概念意味着其目标是能够部署从任何主机到任何其他主机的新应用程序，而无需中介，这需要具有类似跨度的传输协议（另请参见[1]）。
This document summarizes the conclusions and recommendations made by the workshop. It should be noted that not all participants agreed with all of the statements, and it was not clear whether anyone agreed with all of them. The recommendations made however are based on strong consensus among the participants.
本文件总结了研讨会提出的结论和建议。应当指出，并非所有与会者都同意所有发言，也不清楚是否有人同意所有发言。然而，提出的建议是基于与会者之间的强烈共识。
The participants came to a number of conclusions and observations on several of the issues mentioned in section 1. In the following sections 2.1-2.10 these conclusions will be described.
与会者就第1节提到的若干问题得出了一些结论和意见。以下第2.1-2.10节将描述这些结论。
In the discussions transparency was referred to as 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 [1]. This traditional end to end transparency has been lost in the current Internet, specifically the assumption that IPv4 addresses are globally unique or invariant is no longer true.
在讨论中，透明度被称为单一通用逻辑寻址方案的原始互联网概念，以及数据包从源流向目的地的基本不变的机制[1]。这种传统的端到端透明性在当前的互联网中已经消失，特别是IPv4地址全局唯一或不变的假设不再成立。
There are multiple causes for the loss of transparency, for example the deployment of network address translation devices, the use of private addresses, firewalls and application level gateways, proxies and caches. These mechanisms increase fragmentation of the network layer, which causes problems for many applications on the Internet. It adds up to complexity in applications design and inhibits the deployment of new applications. In particular, it has a severe effect on the deployment of end to end IP security.
造成透明度损失的原因有多种，例如网络地址转换设备的部署、专用地址的使用、防火墙和应用程序级网关、代理和缓存。这些机制增加了网络层的碎片化，这会给Internet上的许多应用程序带来问题。它增加了应用程序设计的复杂性，并抑制了新应用程序的部署。特别是，它对端到端IP安全的部署具有严重影响。
Another consequence of fragmentation is the deployment of "split DNS" or "two faced DNS", which means that the correspondence between a given FQDN and an IPv4 address is no longer universal and stable over long periods (see section 2.7).
碎片化的另一个后果是部署“拆分DNS”或“双面DNS”，这意味着给定FQDN和IPv4地址之间的对应关系不再是通用的，并且在较长时间内不再稳定（请参见第2.7节）。
End to end transparency will probably not be restored due to the fact that some of the mechanisms have an intrinsic value (e.g. firewalls, caches and proxies) and the loss of transparency may be considered by some as a security feature. It was however concluded that end to end transparency is desirable and an important issue to pursue. Transparency is further explored in [1].
端到端的透明度可能不会恢复，因为某些机制具有内在价值（例如防火墙、缓存和代理），一些人可能会将失去透明度视为一种安全功能。然而，得出的结论是，端到端的透明度是可取的，也是一个值得探讨的重要问题。[1]进一步探讨了透明度。
The previous section indicated that the deployment of NAT (Network Address Translation), Application Level Gateways and firewalls causes loss of network transparency. Each of them is incompatible with certain applications because they interfere with the assumption of end to end transparency. NAT especially complicates setting up servers, peer to peer communications and "always-on" hosts as the endpoint identifiers, i.e. IP addresses, used to set up connections are globally ambiguous and not stable (see [2]).
上一节指出，NAT（网络地址转换）、应用程序级网关和防火墙的部署导致网络透明度损失。它们中的每一个都与某些应用程序不兼容，因为它们干扰了端到端透明度的假设。NAT尤其使服务器、对等通信和“始终在线”主机的设置复杂化，因为用于建立连接的端点标识符（即IP地址）全局不明确且不稳定（见[2]）。
NAT, application level gateways and firewalls however are being increasingly widely deployed as there are also advantages to each, either real or perceived. Increased deployment causes a further decline of network transparency and this inhibits the deployment of new applications. Many new applications will require specialized Application Level Gateways (ALGs) to be added to NAT devices, before those applications will work correctly when running through a NAT device. However, some applications cannot operate effectively with NAT even with an ALG.
然而，NAT、应用程序级网关和防火墙的部署越来越广泛，因为它们都有各自的优势，无论是真实的还是可感知的。部署的增加会导致网络透明度进一步下降，从而抑制新应用程序的部署。许多新的应用程序需要将专用的应用程序级网关（ALG）添加到NAT设备中，然后这些应用程序才能在NAT设备中正常运行。然而，即使使用ALG，某些应用程序也无法使用NAT有效运行。
In the original IPv4 network architecture hosts are globally, permanently and uniquely identified by an IPv4 address. Such an IP address is used for identification of the node as well as for locating the node on the network. IPv4 in fact mingles the semantics of node identity with the mechanism used to deliver packets to the node. The deployment of mechanisms that separate the network into multiple address spaces breaks the assumption that a host can be uniquely identified by a single IP address. Besides that, hosts may wish to move to a different location in the network but keep their identity the same. The lack of differentiation between the identity and the location of a host leads to a number of problems in the current architecture.
在原始IPv4网络体系结构中，主机由IPv4地址进行全局、永久和唯一标识。这样的IP地址用于识别节点以及在网络上定位节点。IPv4实际上将节点标识的语义与用于向节点传递数据包的机制混合在一起。将网络分隔为多个地址空间的机制的部署打破了主机可以由单个IP地址唯一标识的假设。此外，主机可能希望移动到网络中的不同位置，但保持其身份不变。主机的身份和位置之间缺乏区分导致当前体系结构中存在许多问题。
Several technologies at this moment use tunneling techniques to overcome the problem or cannot be deployed in the case of separate address spaces. If a node could have some sort of a unique identifier or endpoint name this would help in solving a number of problems.
目前有几种技术使用隧道技术来解决这个问题，或者无法在单独的地址空间中部署。如果节点可以具有某种唯一标识符或端点名称，这将有助于解决许多问题。
It was concluded that it may be desirable on theoretical grounds to separate the node identity from the node locator. This is especially true for IPsec, since IP addresses are used (in transport mode) as identifiers which are cryptographically protected and hence MUST remain unchanged during transport. However, such a separation of identity and location will not be available as a near-term solution, and will probably require changes to transport level protocols. However, the current specification of IPsec does allow to use some other identifier than an IP address.
得出的结论是，从理论上讲，将节点标识与节点定位器分离可能是可取的。这对于IPsec尤其如此，因为IP地址（在传输模式下）被用作受加密保护的标识符，因此在传输期间必须保持不变。但是，这种身份和位置分离的短期解决方案将不可用，并且可能需要更改传输级协议。但是，IPsec的当前规范允许使用IP地址以外的其他标识符。
There is a significant risk that a single 32 bit global address space is insufficient for foreseeable needs or desires. The participants' opinions about the time scale over which new IPv4 addresses will still be available for assignment ranged from 2 to 20 years. However, there is no doubt that at the present time, users cannot obtain as much IPv4 address space as they desire. This is partly a result of the current stewardship policies of the Regional Internet Registries (RIRs).
存在一个重大风险，即单个32位全局地址空间不足以满足可预见的需要或期望。参与者对新IPv4地址仍可用于分配的时间范围的意见从2年到20年不等。然而，毫无疑问，目前用户无法获得他们想要的IPv4地址空间。这在一定程度上是区域互联网注册处（RIR）现行管理政策的结果。
It was concluded that it ought to be possible for anybody to have global addresses when required or desired. The absence of this inhibits the deployment of some types of applications. It should however be noted that there will always be administrative boundaries, firewalls and intranets, because of the need for security and the implementation of policies. NAT is seen as a significant complication on these boundaries. It is often perceived as a security feature because people are confusing NATs with firewalls.
得出的结论是，任何人在需要或需要时都应该能够拥有全球地址。缺少这一点会妨碍某些类型应用程序的部署。然而，应该注意的是，由于安全和政策实施的需要，始终存在管理边界、防火墙和内部网。NAT被视为这些边界上的一个重要复杂因素。它通常被认为是一种安全特性，因为人们把NAT和防火墙混淆了。
A number of concerns were raised regarding the scaling of the current routing system. With current technology, the number of prefixes that can be used is limited by the time taken for the routing algorithm to converge, rather than by memory size, lookup time, or some other factor. The limit is unknown, but there is some speculation, of extremely unclear validity, that it is on the order of a few hundred thousand prefixes. Besides the computational load of calculating routing tables, the time it takes to distribute routing updates across the network, the robustness and security of the current routing system are also important issues. The only known addressing
对当前路由系统的扩展提出了一些关注。在当前技术中，可以使用的前缀数量受路由算法收敛所需时间的限制，而不是受内存大小、查找时间或其他因素的限制。限制是未知的，但有一些猜测，其有效性极不明确，它大约有几十万个前缀。除了计算路由表的计算量，在整个网络中分发路由更新所需的时间，当前路由系统的健壮性和安全性也是重要的问题。唯一已知的地址
scheme which produces scalable routing mechanisms depends on topologically aggregated addresses, which requires that sites renumber when their position in the global topology changes. Renumbering remains operationally difficult and expensive ([3], [4]). It is not clear whether the deployment of IPv6 would solve the current routing problems, but it should do so if it makes renumbering easier.
产生可伸缩路由机制的方案依赖于拓扑聚合地址，这要求站点在全局拓扑中的位置发生变化时重新编号。重新编号在操作上仍然困难且昂贵（[3]，[4]）。目前还不清楚IPv6的部署是否能解决当前的路由问题，但如果它能使重新编号更容易的话，就应该这样做。
At least one backbone operator has concerns about the convergence time of internetwork-wide routing during a failover. This operator believes that current convergence times are on the order of half a minute, and possibly getting worse. Others in the routing community did not believe that the convergence times are a current issue. Some, who believe that real-time applications (e.g. telephony) require sub-second convergence, are concerned about the implications of convergence times of a half minute on such applications.
至少有一家骨干网运营商担心故障切换期间全网路由的收敛时间。该操作符认为当前的收敛时间大约为半分钟，并且可能会变得更糟。路由社区的其他人不认为收敛时间是当前的问题。一些人认为实时应用（如电话）需要亚秒级的收敛，他们担心半分钟的收敛时间对此类应用的影响。
Further research is needed on routing mechanisms that might help palliate the current entropy in the routing tables, and can help reduce the convergence time of routing computations.
需要进一步研究路由机制，以减轻路由表中的当前熵，并有助于减少路由计算的收敛时间。
The workshop discussed global routing in a hypothetical scenario with no distinguished root global address space. Nobody had an idea how to make such a system work. There is currently no well-defined proposal for a new routing system that could solve such a problem.
研讨会讨论了一个没有可分辨根全局地址空间的假设场景中的全局路由。没有人知道如何使这样一个系统工作。目前还没有一个明确的建议，一个新的路由系统，可以解决这样的问题。
For IPv6 routing in particular, the GSE/8+8 proposal and IPNG WG analysis of this proposal ([5]) are still being examined by the IESG. There is no consensus in the workshop whether this proposal could be made deployable.
特别是对于IPv6路由，IESG仍在审查GSE/8+8提案和IPNG工作组对该提案的分析（[5]）。研讨会上没有就这项提案是否可以部署达成共识。
Mobility and roaming require a globally unique identifier. This does not have to be an IP address. Mobile nodes must have a widely usable identifier for their location on the network, which is an issue if private IP addresses are used or the IP address is ambiguous (see also section 2.3). Currently tunnels are used to route traffic to a mobile node. Another option would be to maintain state information at intermediate points in the network if changes are made to the packets. This however reduces the flexibility and it breaks the end to end model of the network. Keeping state in the network is usually considered a bad thing. Tunnels on the other hand reduce the MTU size. Mobility was not discussed in detail as a separate IAB workshop is planned on this topic.
移动和漫游需要全局唯一标识符。这不必是IP地址。移动节点在网络上的位置必须有一个广泛可用的标识符，如果使用私有IP地址或IP地址不明确，这是一个问题（另请参见第2.3节）。目前，隧道用于将流量路由到移动节点。另一种选择是，如果对数据包进行更改，则在网络的中间点维护状态信息。然而，这降低了灵活性，打破了网络的端到端模型。在网络中保持状态通常被认为是一件坏事。另一方面，隧道减小了MTU的尺寸。由于计划就此主题举办单独的IAB研讨会，因此未详细讨论机动性。
If IPv6 is widely deployed, the current line of thinking is that site renumbering will be significantly more frequent than today. This will have an impact on DNS updates. It is not clear what the scale of DNS updates might be, but in the most aggressive models it could be millions a day. Deployment of the A6 record type which is defined to map a domain name to an IPv6 address, with the provision for indirection for leading prefix bits, could make this possible ([6]).
如果IPv6得到广泛部署，当前的思路是站点重新编号的频率将大大高于今天。这将对DNS更新产生影响。目前尚不清楚DNS更新的规模，但在最具攻击性的型号中，可能是每天数百万次。部署A6记录类型（定义为将域名映射到IPv6地址，并提供前导前缀位的间接寻址）可以实现这一点（[6]）。
Another issue is the security aspect of frequent updates, as they would have to been done dynamically. Unless we have fully secured DNS, it could increase security risks. Cached TTL values might introduce problems as the cached records of renumbered hosts will not be updated in time. This will become especially a problem if rapid renumbering is needed.
另一个问题是频繁更新的安全方面，因为它们必须动态完成。除非我们有完全安全的DNS，否则可能会增加安全风险。缓存的TTL值可能会带来问题，因为重新编号的主机的缓存记录不会及时更新。如果需要快速重新编号，这将成为一个特别的问题。
Another already mentioned issue is the deployment of split DNS (see section 2.1). This concept is widely used in the Intranet model, where the DNS provides different information to inside and outside queries. This does not necessarily depend on whether private addresses are used on the inside, as firewalls and policies may also make this desirable. The use of split DNS seems inevitable as Intranets will remain widely deployed. But operating a split DNS raises a lot of management and administrative issues. As a work around, a DNS Application Level Gateway ([7]) (perhaps as an extension to a NAT device) may be deployed, which intercepts DNS messages and modifies the contents to provide the appropriate answers. This has the disadvantage that it interferes with the use of DNSSEC ([8]).
另一个已经提到的问题是拆分DNS的部署（参见第2.1节）。这一概念广泛应用于内部网模型，其中DNS为内部和外部查询提供不同的信息。这并不一定取决于内部是否使用了私有地址，因为防火墙和策略也可能会使这一点变得可取。由于内部网将继续广泛部署，拆分DNS的使用似乎不可避免。但是，操作拆分DNS会引发许多管理和管理问题。作为一种解决方法，可以部署DNS应用程序级网关（[7]）（可能作为NAT设备的扩展），该网关拦截DNS消息并修改内容以提供适当的答案。这样做的缺点是会干扰DNSSEC的使用（[8]）。
The deployment of split DNS, or more generally the existence of separate name spaces, makes the use of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complex.
拆分DNS的部署，或者更一般地说，独立名称空间的存在，使得完全限定域名（FQDN）作为端点标识符的使用更加复杂。
Realm-Specific IP (RSIP), a mechanism for use with IPv4, is a work item of the IETF NAT WG. It is intended as an alternative (or as a complement) to network address translation (NAT) for IPv4, but other uses are possible (for example, allowing end to end traffic across firewalls). It is similar to NAT, in that it allows sharing a small number of external IPv4 addresses among a number of hosts in a local address domain (called a 'realm'). However, it differs from NAT in that the hosts know that different externally-visible IPv4 addresses are being used to refer to them outside their local realm, and they
领域特定IP（RSIP），一种用于IPv4的机制，是IETF NAT工作组的一个工作项。它旨在作为IPv4网络地址转换（NAT）的替代（或补充），但也可以用于其他用途（例如，允许跨防火墙的端到端流量）。它类似于NAT，因为它允许在本地地址域（称为“域”）中的多个主机之间共享少量外部IPv4地址。但是，它与NAT的不同之处在于，主机知道不同的外部可见IPv4地址被用于在其本地域之外引用它们，并且
know what their temporary external address is. The addresses and other information are obtained from an RSIP server, and the packets are tunneled across the first routing realm ([9], [10]).
知道他们的临时外部地址是什么。地址和其他信息从RSIP服务器获得，数据包通过第一个路由领域（[9]，[10]）进行隧道传输。
The difference between NAT and RSIP - that an RSIP client is aware of the fact that it uses an IP address from another address space, while with NAT, neither endpoint is aware that the addresses in the packets are being translated - is significant. Unlike NAT, RSIP has the potential to work with protocols that require IP addresses to remain unmodified between the source and destination. For example, whereas NAT gateways preclude the use of IPsec across them, RSIP servers can allow it [11].
NAT和RSIP之间的区别——RSIP客户端知道它使用另一个地址空间的IP地址，而对于NAT，两个端点都不知道数据包中的地址正在被转换——是非常重要的。与NAT不同，RSIP有可能使用要求源和目标之间的IP地址保持不变的协议。例如，虽然NAT网关不允许跨它们使用IPsec，但RSIP服务器可以允许它[11]。
The addition of RSIP to NATs may allow them to support some applications that cannot work with traditional NAT ([12]), but it does require that hosts be modified to act as RSIP clients. It requires changes to the host's TCP/IP stack, any layer-three protocol that needs to be made RSIP-aware will have to be modified (e.g. ICMP) and certain applications may have to be changed. The exact changes needed to host or application software are not quite well known at this moment and further research into RSIP is required.
将RSIP添加到NAT中可能允许它们支持一些不能与传统NAT一起工作的应用程序（[12]），但它确实需要修改主机以充当RSIP客户端。它需要更改主机的TCP/IP堆栈，需要使RSIP知晓的任何第三层协议都必须修改（例如ICMP），并且某些应用程序可能必须更改。主机或应用软件所需的确切更改目前还不太清楚，需要对RSIP进行进一步研究。
Both NAT and RSIP assume that the Internet retains a core of global address space with a coherent DNS. There is no fully prepared model for NAT or RSIP without such a core; therefore NAT and RSIP face an uncertain future whenever the IPv4 address space is finally exhausted (see section 2.4). Thus it is also a widely held view that in the longer term the complications caused by the lack of globally unique addresses, in both NAT and RSIP, might be a serious handicap ([1]).
NAT和RSIP都假设互联网保留了一个具有一致DNS的全局地址空间的核心。没有这样的核心，就没有为NAT或RSIP准备充分的模型；因此，每当IPv4地址空间最终耗尽时，NAT和RSIP将面临一个不确定的未来（见第2.4节）。因此，人们普遍认为，从长远来看，NAT和RSIP中缺乏全球唯一地址所导致的并发症可能是一个严重的障碍（[1]）。
If optimistic assumptions are made about RSIP (it is still being defined and a number of features have not been implemented yet), the combination of NAT and RSIP seems to work in most cases. Whether RSIP introduces specific new problems, as well as removing some of the NAT issues, remains to be determined.
如果对RSIP做出了乐观的假设（它仍在定义中，许多功能尚未实现），那么NAT和RSIP的结合似乎在大多数情况下都有效。RSIP是否会引入特定的新问题，以及消除一些NAT问题，仍有待确定。
Both NAT and RSIP may have trouble with the future killer application, especially when this needs QoS features, security and/or multicast. And if it needs peer to peer communication (i.e. there would be no clear distinction between a server and a client) or assumes "always-on" systems, this would probably be complex with both NAT and RSIP (see also section 2.2).
NAT和RSIP在未来的killer应用程序中都可能遇到问题，特别是在需要QoS功能、安全性和/或多播的情况下。如果它需要点对点通信（即，服务器和客户端之间没有明确的区别）或假设系统“始终处于开启状态”，那么NAT和RSIP可能会很复杂（另请参见第2.2节）。
Assuming IPv6 is going to be widely deployed, network address translation techniques could play an important role in the transition process from IPv4 to IPv6 ([13]). The impact of adding RSIP support
假设IPv6将被广泛部署，网络地址转换技术将在从IPv4到IPv6的过渡过程中发挥重要作用（[13]）。添加RSIP支持的影响
to hosts is not quite clear at this moment, but it is less than adding IPv6 support since most applications probably don't need to be changed. And RSIP needs no changes to the routing infrastructure, but techniques such as automatic tunneling ([14]) and 6to4 ([15]) would also allow IPv6 traffic to be passed over the existing IPv4 routing infrastructure. While RSIP is principally a tool for extending the life of IPv4, it is not a roadblock for the transition to IPv6. The development of RSIP is behind that of IPv6, and more study into RSIP is required to determine what the issues with RSIP might be.
对于主机，目前还不太清楚，但这比添加IPv6支持要少，因为大多数应用程序可能不需要更改。RSIP不需要改变路由基础设施，但自动隧道（[14]）和6to4（[15]）等技术也允许IPv6流量通过现有的IPv4路由基础设施。虽然RSIP主要是延长IPv4寿命的工具，但它并不是向IPv6过渡的障碍。RSIP的发展落后于IPv6，需要对RSIP进行更多的研究，以确定RSIP可能存在的问题。
An important issue in the workshop was whether the deployment of IPv6 is feasible and probable. It was concluded that the transition to IPv6 is plausible modulo certain issues. For example applications need to be ported to IPv6, and production protocol stacks and production IPv6 routers should be released. The core protocols are finished, but other standards need to be pushed forward (e.g. MIBs). A search through all RFCs for dependencies on IPv4 should be made, as was done for the Y2K problem, and if problems are found they must be resolved. As there are serious costs in implementing IPv6 code, good business arguments are needed to promote IPv6.
研讨会上的一个重要问题是部署IPv6是否可行和可能。得出的结论是，在某些问题上，向IPv6过渡似乎是可行的。例如，应用程序需要移植到IPv6，生产协议栈和生产IPv6路由器应该发布。核心协议已经完成，但需要推进其他标准（如MIB）。应该像Y2K问题一样，在所有RFC中搜索对IPv4的依赖关系，如果发现问题，就必须解决。由于实现IPv6代码的成本很高，因此需要良好的商业论据来推广IPv6。
One important question was whether IPv6 could help solve the current problems in the routing system and make the Internet scale better. It was concluded that "automatic" renumbering is really important when prefixes are to be changed periodically to get the addressing topology and routing optimized. This also means that any IP layer and configuration dependencies in protocols and applications will have to be removed ([3]). One example that was mentioned is the use of IP addresses in the PKI (IKE). There might also be security issues with "automatic" renumbering as DNS records have to be updated dynamically (see also section 2.7).
一个重要的问题是IPv6能否帮助解决当前路由系统中的问题，并使互联网规模更好。得出的结论是，当需要定期更改前缀以优化寻址拓扑和路由时，“自动”重新编号非常重要。这也意味着必须删除协议和应用程序中的任何IP层和配置依赖项（[3]）。提到的一个例子是在PKI（IKE）中使用IP地址。“自动”重新编号也可能存在安全问题，因为DNS记录必须动态更新（另请参见第2.7节）。
Realistically, because of the dependencies mentioned, IPv6 renumbering cannot be truly automatic or instantaneous, but it has the potential to be much simpler operationally than IPv4 renumbering, and this is critical to market and ISP acceptance of IPv6.
实际上，由于上述依赖关系，IPv6重新编号不可能是真正的自动或即时的，但在操作上可能比IPv4重新编号简单得多，这对IPv6的市场和ISP接受度至关重要。
Another issue is whether existing TCP connections (using the old address(es)) should be maintained across renumbering. This would make things much more complex and it is foreseen that old and new addresses would normally overlap for a long time.
另一个问题是是否应在重新编号过程中维护现有TCP连接（使用旧地址）。这将使事情变得更加复杂，可以预见，旧地址和新地址通常会重叠很长一段时间。
There was no consensus on how often renumbering would take place or how automatic it can be in practice; there is not much experience with renumbering (maybe only for small sites).
对于重新编号的频率以及在实践中的自动化程度，没有达成共识；在重新编号方面没有太多经验（可能仅适用于小型站点）。
The workshop recommends the IAB to appoint a panel to make specific recommendations to the IETF about:
研讨会建议IAB任命一个小组，就以下方面向IETF提出具体建议：
i) whether we should encourage more parts of the stack to adopt a
namespace for end to end interactions, so that a) NAT works
'better', and b) we have a little more independence between the
internetwork and transport and above layers;
ii) if so, whether we should have a single system-wide namespace
for this function, or whether it makes more sense to allow
various subsystems to chose the namespace that makes sense for
them;
iii) and also, what namespace(s) [depending on the output of the
point above] that ought to be.
i) whether we should encourage more parts of the stack to adopt a
namespace for end to end interactions, so that a) NAT works
'better', and b) we have a little more independence between the
internetwork and transport and above layers;
ii) if so, whether we should have a single system-wide namespace
for this function, or whether it makes more sense to allow
various subsystems to chose the namespace that makes sense for
them;
iii) and also, what namespace(s) [depending on the output of the
point above] that ought to be.
RSIP is an interesting idea, but it needs further refinement and study. It does not break the end to end network model in the same way as NAT, because an RSIP host has explicit knowledge of its temporary global address. Therefore, RSIP could solve some of the issues with NAT. However, it is premature to recommend it as a mainstream direction at this time.
RSIP是一个有趣的想法，但它需要进一步完善和研究。它不像NAT那样破坏端到端网络模型，因为RSIP主机明确知道其临时全局地址。因此，RSIP可以解决NAT的一些问题。然而，现在建议将其作为主流方向还为时过早。
It is recommended that the IETF should actively work on RSIP, develop the details and study the issues.
建议IETF积极开展RSIP工作，制定细节并研究问题。
3.3.1 The current model of TLA-based addressing and routing should be actively pursued. However, straightforward site renumbering using TLA addresses is really needed, should be as nearly automatic as possible, and should be shown to be real and credible by the IPv6 community.
3.3.1 当前基于TLA的寻址和路由模型应该积极采用。然而，确实需要使用TLA地址对站点进行简单的重新编号，应该尽可能自动地重新编号，并且应该被IPv6社区证明是真实可信的。
3.3.2 Network address translation techniques, in addition to their immediate use in pure IPv4 environments, should also be viewed as part of the starting point for migration to IPv6. Also RSIP, if successful, can be a starting point for IPv6 transition.
3.3.2 除了在纯IPv4环境中立即使用网络地址转换技术外，还应将其视为迁移到IPv6的起点的一部分。此外，RSIP如果成功，可以作为IPv6转换的起点。
While the basic concepts of the IPv4 specific mechanisms NAT and RSIP are also being used in elements of the proposed migration path to IPv6 (in NAT-PT for NAT, and SIIT and AIIH for RSIP), NAT and RSIP for IPv4 are not directly part of a documented transition path to IPv6.
虽然IPv4特定机制NAT和RSIP的基本概念也在拟议的IPv6迁移路径的元素中使用（NAT-PT用于NAT，SIIT和AIIH用于RSIP），但IPv4的NAT和RSIP并不是到IPv6的转换路径的直接组成部分。
The exact implications, for transition to IPv6, of having NAT and RSIP for IPv4 deployed, are not well understood. Strategies for transition to IPv6, for use in IPv4 domains using NAT and RSIP for IPv4, should be worked out and documented by the IETF.
对于过渡到IPv6，部署用于IPv4的NAT和RSIP的确切含义尚不清楚。IETF应制定并记录过渡到IPv6的策略，以便在IPv4域中使用NAT和用于IPv4的RSIP。
3.3.3 The draft analysis of the 8+8/GSE proposal should be evaluated by the IESG and accepted or rejected, without disturbing ongoing IPv6 deployment work. The IESG should use broad expertise, including liaison with the endpoint namespace panel (see section 3.1) in their evaluation.
3.3.3 IESG应对8+8/GSE提案的分析草案进行评估，并在不干扰正在进行的IPv6部署工作的情况下予以接受或拒绝。IESG应使用广泛的专业知识，包括在评估中与端点名称空间小组（见第3.1节）联系。
It is urgent that we implement and deploy IPsec using some other identifier than 32-bit IP addresses (see section 2.3). The current IPsec specifications support the use of several different Identity types (e.g. Domain Name, User@Domain Name). The IETF should promote implementation and deployment of non-address Identities with IPsec. We strongly urge the IETF to completely deprecate the use of the binary 32-bit IP addresses within IPsec, except in certain very limited circumstances, such as router to router tunnels; in particular any IP address dependencies should be eliminated from ISAKMP and IKE.
我们迫切需要使用32位IP地址以外的其他标识符来实现和部署IPsec（请参见第2.3节）。当前的IPsec规范支持使用几种不同的标识类型（例如域名、，User@Domain姓名）。IETF应促进使用IPsec实现和部署非地址标识。我们强烈敦促IETF完全反对在IPsec中使用二进制32位IP地址，除非在某些非常有限的情况下，如路由器到路由器隧道；特别是，应该从ISAKMP和IKE中消除任何IP地址依赖关系。
Ubiquitous deployment of the Secure DNS Extensions ([8]) should be strongly encouraged to facilitate widespread deployment of IPsec (including IKE) without address-based Identity types.
应大力鼓励无处不在的安全DNS扩展部署（[8]），以促进IPsec（包括IKE）的广泛部署，而无需基于地址的标识类型。
Operational stability of DNS is paramount, especially during a transition of the network layer, and both IPv6 and some network address translation techniques place a heavier burden on DNS. It is therefore recommended to the IETF that, except for those changes that are already in progress and will support easier renumbering of networks and improved security, no fundamental changes or additions to the DNS be made for the foreseeable future.
DNS的操作稳定性至关重要，尤其是在网络层过渡期间，IPv6和一些网络地址转换技术都给DNS带来了更大的负担。因此，建议IETF在可预见的将来，除了那些已经在进行中并将支持更容易的网络重新编号和改进的安全性的更改外，不要对DNS进行根本性的更改或添加。
In order to encourage widespread deployment of IPsec, rapid deployment of DNSSEC is recommended to the operational community.
为了鼓励广泛部署IPsec，建议运营社区快速部署DNSSEC。
The only known addressing scheme which produces scalable routing mechanisms depends on topologically aggregated addresses, which requires that sites renumber when their position in the global topology changes. Thus recommendation 3.3.1 is vital for routing IPv6.
唯一已知的产生可伸缩路由机制的寻址方案依赖于拓扑聚合地址，这要求站点在全局拓扑中的位置发生变化时重新编号。因此，建议3.3.1对于路由IPv6至关重要。
Although the same argument applies to IPv4, the installed base is simply too large and the PIER working group showed that little can be done to improve renumbering procedures for IPv4. However, NAT and/or RSIP may help.
尽管同样的观点也适用于IPv4，但安装基数实在太大，PIER工作组表明，在改进IPv4的重新编号过程方面几乎没有什么可以做的。然而，NAT和/或RSIP可能会有所帮助。
In the absence of a new addressing model to replace topological aggregation, and of clear and substantial demand from the user community for a new routing architecture (i.e. path-selection mechanism) there is no reason to start work on standards for a "next generation" routing system in the IETF. Therefore, we recommend that work should continue in the IRTF Routing Research Group.
在没有新的寻址模型来取代拓扑聚合的情况下，以及用户群体对新路由体系结构（即路径选择机制）的明确而实质性的需求，没有理由开始制定IETF中“下一代”路由系统的标准。因此，我们建议IRTF路由研究小组继续开展工作。
Most current APIs such as sockets are an obstacle to migration to a new network layer of any kind, since they expose network layer internal details such as addresses.
大多数当前的API（如套接字）都是迁移到任何类型的新网络层的障碍，因为它们公开了网络层的内部细节，如地址。
It is therefore recommended, as originally recommended in RFC 1900 [3], that IETF protocols, and third-party applications, avoid any explicit awareness of IP addresses, when efficient operation of the protocol or application is feasible in the absence of such awareness. Some applications and services may continue to need to be aware of IP addresses. Until we once again have a uniform address space for the Internet, such applications and services will necessarily have limited deployability, and/or require ALG support in NATs.
因此，正如RFC 1900[3]中最初建议的那样，建议IETF协议和第三方应用程序避免任何明确的IP地址意识，如果在没有这种意识的情况下协议或应用程序的有效运行是可行的。一些应用程序和服务可能仍然需要知道IP地址。在我们再次为互联网提供统一的地址空间之前，此类应用程序和服务的部署能力必然有限，并且/或者需要NAT中的ALG支持。
Also we recommend an effort in the IETF to generalize APIs to offer abstraction from all network layer dependencies, perhaps as a side-effect of the namespace study of section 3.1.
此外，我们建议IETF努力推广API，以提供所有网络层依赖的抽象，这可能是第3.1节名称空间研究的副作用。
The workshop did not address security as a separate topic, but the role of firewalls, and the desirability of end to end deployment of IPsec, were underlying assumptions. Specific recommendations on security are covered in sections 3.4 and 3.5.
研讨会没有将安全作为单独的主题进行讨论，但防火墙的作用以及端到端部署IPsec的可取性是基本假设。第3.4节和第3.5节介绍了关于安全性的具体建议。
References
工具书类
[1] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[1] Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[2] Hain, T., "Architectural Implications of NAT", Work in Progress.
[2] Hain，T，“NAT的建筑含义”，正在进行中。
[3] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[3] Carpenter，B.和Y.Rekhter，“重新编号需要工作”，RFC 1900，1996年2月。
[4] Ferguson, P and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[4] Ferguson，P和H.Berkowitz，“网络重新编号概述：我为什么想要它以及它到底是什么？”，RFC 2071，1997年1月。
[5] M. Crawford, A. Mankin, T. Narten, J.W. Stewart, III, L. Zhang, "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6", Work in Progress.
[5] M.Crawford，A.Mankin，T.Narten，J.W.Stewart，III，L.Zhang，“分离地址中的标识符和定位器：对IPv6 GSE提案的分析”，正在进行的工作。
[6] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[6] Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。
[7] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[7] Srisuresh，P.，Tsirtsis，G.，Akkiraju，P.和A.Heffernan，“网络地址转换器的DNS扩展（DNS_ALG）”，RFC 26941999年9月。
[8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8] Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[9] M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific IP: Protocol Specification", Work in Progress.
[9] M.Borella，D.Grabelsky，J.Lo，K.Tuniguchi“领域特定IP：协议规范”，正在进行的工作。
[10] M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific IP: Framework", Work in Progress.
[10] M.Borella，J.Lo，D.Grabelsky，G.黑山“特定领域知识产权：框架”，正在进行的工作。
[11] G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec", Work in Progress.
[11] G.黑山，M.Borella，“RSIP对端到端IPsec的支持”，正在进行的工作。
[12] M. Holdrege, P. Srisuresh, "Protocol Complications with the IP Network Address Translator", Work in Progress.
[12] M.Holdrege，P.Srisuresh，“IP网络地址转换器的协议复杂性”，正在进行中。
[13] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[13] Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[14] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[14] Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 28932000年8月。
[15] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", Work in Progress.
[15] B.Carpenter，K.Moore，“通过IPv4云连接IPv6域”，正在进行中。
Harald Alvestrand harald@alvestrand.no Ran Atkinson rja@corp.home.net Rob Austein sra@hactrn.net Steve Bellovin smb@research.att.com Randy Bush randy@psg.com Brian E Carpenter brian@hursley.ibm.com Vint Cerf vcerf@MCI.NET Noel Chiappa jnc@lcs.mit.edu Matt Crawford crawdad@fnal.gov Robert Elz kre@munnari.OZ.AU Tony Hain tonyhain@microsoft.com Matt Holdrege matt@ipverse.com Erik Huizer huizer@cs.utwente.nl Geoff Huston gih@telstra.net Van Jacobson van@cisco.com Marijke Kaat Marijke.Kaat@surfnet.nl Daniel Karrenberg Daniel.Karrenberg@ripe.net John Klensin klensin@jck.com Peter Lothberg roll@Stupi.SE Olivier H. Martin Olivier.Martin@cern.ch Gabriel Montenegro gab@sun.com Keith Moore moore@cs.utk.edu Robert (Bob) Moskowitz rgm@htt-consult.com Philip J. Nesser II pjnesser@nesser.com Kathleen Nichols kmn@cisco.com Erik Nordmark nordmark@eng.sun.com Dave Oran oran@cisco.com Yakov Rekhter yakov@cisco.com Bill Sommerfeld sommerfeld@alum.mit.edu Bert Wijnen wijnen@vnet.ibm.com Lixia Zhang lixia@cs.ucla.edu
哈拉尔·阿尔韦斯特兰harald@alvestrand.no阿特金森rja@corp.home.net罗伯·奥斯汀sra@hactrn.net史蒂夫·贝洛文smb@research.att.com兰迪·布什randy@psg.com布莱恩·卡彭特brian@hursley.ibm.com文特瑟夫vcerf@MCI.NET诺埃尔·基亚帕jnc@lcs.mit.edu马特·克劳福德crawdad@fnal.gov罗伯特·埃尔兹kre@munnari.OZ.AU托尼·海恩tonyhain@microsoft.com马特Holdregematt@ipverse.com埃里克·惠泽huizer@cs.utwente.nl杰夫·休斯顿gih@telstra.net范雅各布森van@cisco.com马里克·卡特·马里克。Kaat@surfnet.nl丹尼尔·卡伦伯格，丹尼尔。Karrenberg@ripe.net约翰·克莱辛klensin@jck.com彼得·洛斯伯格roll@Stupi.SE奥利维尔·马丁·奥利维尔。Martin@cern.ch加布里埃尔黑山gab@sun.com基思摩尔moore@cs.utk.edu罗伯特（鲍勃）莫斯科维茨rgm@htt-咨询网站Philip J.Nesser IIpjnesser@nesser.com凯瑟琳·尼科尔斯kmn@cisco.com埃里克·诺德马克nordmark@eng.sun.com戴夫·奥兰oran@cisco.com亚科夫·雷赫特yakov@cisco.com比尔·索末菲sommerfeld@alum.mit.edu伯特·维宁wijnen@vnet.ibm.com张丽霞lixia@cs.ucla.edu
Author's Address
作者地址
Marijke Kaat SURFnet ExpertiseCentrum bv P.O. Box 19115 3501 DC Utrecht The Netherlands
Marijke Kaat SURFnet ExpertiseCentrum bv，邮政信箱19115 3501，荷兰乌得勒支特区
Phone: +31 30 230 5305
Fax: +31 30 230 5329
EMail: Marijke.Kaat@surfnet.nl
Phone: +31 30 230 5305
Fax: +31 30 230 5329
EMail: Marijke.Kaat@surfnet.nl
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编辑功能的资金目前由互联网协会提供。