Network Working Group Editors:
Request for Comments: 3102 M. Borella
Category: Experimental CommWorks
J. Lo
Candlestick Networks
Contributors:
D. Grabelsky
CommWorks
G. Montenegro
Sun Microsystems
October 2001
Network Working Group Editors:
Request for Comments: 3102 M. Borella
Category: Experimental CommWorks
J. Lo
Candlestick Networks
Contributors:
D. Grabelsky
CommWorks
G. Montenegro
Sun Microsystems
October 2001
Realm Specific IP: Framework
领域特定IP：框架
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
IESG Note
IESG注释
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESG指出，描述RSIP技术的一组文档意味着主机和网关的重大更改，以实现完整的实现。此外，端口号的浮动可能会导致某些应用程序出现问题，从而在某些情况下（例如，IPsec）阻止启用RSIP的主机与现有应用程序进行透明的互操作。最后，使用RSIP可能会带来巨大的操作复杂性。RFC 3102第6节以及RFC 3104附录概述了其中一些并发症和其他并发症。因此，使用RSIP的成本和收益应与其他缓解地址短缺的方法仔细权衡。
Abstract
摘要
This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols.
本文研究领域特定IP（RSIP）的一般框架。RSIP旨在作为NAT的替代方案，在NAT中保持数据包的端到端完整性。我们关注实现问题、部署场景以及与其他第三层协议的交互。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . . 5
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Host and Gateway Requirements . . . . . . . . . . . . . . . 7
3.2. Processing of Demultiplexing Fields . . . . . . . . . . . . 8
3.3. RSIP Protocol Requirements and Recommendations . . . . . . 9
3.4. Interaction with DNS . . . . . . . . . . . . . . . . . . . 10
3.5. Locating RSIP Gateways . . . . . . . . . . . . . . . . . . 11
3.6. Implementation Considerations . . . . . . . . . . . . . . . 11
4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . . 12
4.2. Cascaded RSIP and NAT . . . . . . . . . . . . . . . . . . . 14
5. Interaction with Layer-Three Protocols . . . . . . . . . . . 17
5.1. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Differentiated and Integrated Services . . . . . . . . . . 18
5.4. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 21
6. RSIP Complications . . . . . . . . . . . . . . . . . . . . . 23
6.1. Unnecessary TCP TIME_WAIT . . . . . . . . . . . . . . . . . 23
6.2. ICMP State in RSIP Gateway . . . . . . . . . . . . . . . . 23
6.3. Fragmentation and IP Identification Field Collision . . . . 24
6.4. Application Servers on RSAP-IP Hosts . . . . . . . . . . . 24
6.5. Determining Locality of Destinations from an RSIP Host. . . 25
6.6. Implementing RSIP Host Deallocation . . . . . . . . . . . . 26
6.7. Multi-Party Applications . . . . . . . . . . . . . . . . . 26
6.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . . 5
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Host and Gateway Requirements . . . . . . . . . . . . . . . 7
3.2. Processing of Demultiplexing Fields . . . . . . . . . . . . 8
3.3. RSIP Protocol Requirements and Recommendations . . . . . . 9
3.4. Interaction with DNS . . . . . . . . . . . . . . . . . . . 10
3.5. Locating RSIP Gateways . . . . . . . . . . . . . . . . . . 11
3.6. Implementation Considerations . . . . . . . . . . . . . . . 11
4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . . 12
4.2. Cascaded RSIP and NAT . . . . . . . . . . . . . . . . . . . 14
5. Interaction with Layer-Three Protocols . . . . . . . . . . . 17
5.1. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Differentiated and Integrated Services . . . . . . . . . . 18
5.4. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 21
6. RSIP Complications . . . . . . . . . . . . . . . . . . . . . 23
6.1. Unnecessary TCP TIME_WAIT . . . . . . . . . . . . . . . . . 23
6.2. ICMP State in RSIP Gateway . . . . . . . . . . . . . . . . 23
6.3. Fragmentation and IP Identification Field Collision . . . . 24
6.4. Application Servers on RSAP-IP Hosts . . . . . . . . . . . 24
6.5. Determining Locality of Destinations from an RSIP Host. . . 25
6.6. Implementing RSIP Host Deallocation . . . . . . . . . . . . 26
6.7. Multi-Party Applications . . . . . . . . . . . . . . . . . 26
6.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 30
Network Address Translation (NAT) has become a popular mechanism of enabling the separation of addressing spaces. A NAT router must examine and change the network layer, and possibly the transport layer, header of each packet crossing the addressing domains that the NAT router is connecting. This causes the mechanism of NAT to violate the end-to-end nature of the Internet connectivity, and disrupts protocols requiring or enforcing end-to-end integrity of packets.
网络地址转换（NAT）已成为实现寻址空间分离的一种流行机制。NAT路由器必须检查并更改网络层，可能还有传输层，每个跨越NAT路由器连接的寻址域的数据包的报头。这会导致NAT机制违反Internet连接的端到端特性，并破坏要求或强制实现数据包端到端完整性的协议。
While NAT does not require a host to be aware of its presence, it requires the presence of an application layer gateway (ALG) within the NAT router for each application that embeds addressing information within the packet payload. For example, most NATs ship with an ALG for FTP, which transmits IP addresses and port numbers on its control channel. RSIP (Realm Specific IP) provides an alternative to remedy these limitations.
虽然NAT不要求主机知道其存在，但它要求在NAT路由器内为每个将寻址信息嵌入到数据包有效负载中的应用程序提供应用层网关（ALG）。例如，大多数NAT都附带用于FTP的ALG，它在其控制通道上传输IP地址和端口号。RSIP（领域特定IP）提供了一种替代方法来弥补这些限制。
RSIP is based on the concept of granting a host from one addressing realm a presence in another addressing realm by allowing it to use resources (e.g., addresses and other routing parameters) from the second addressing realm. An RSIP gateway replaces the NAT router, and RSIP-aware hosts on the private network are referred to as RSIP hosts. RSIP requires ability of the RSIP gateway to grant such resources to RSIP hosts. ALGs are not required on the RSIP gateway for communications between an RSIP host and a host in a different addressing realm.
RSIP基于这样一个概念：通过允许主机使用第二个寻址域的资源（例如，地址和其他路由参数），从一个寻址域向主机授予另一个寻址域中的存在。RSIP网关取代NAT路由器，专用网络上支持RSIP的主机称为RSIP主机。RSIP要求RSIP网关能够将此类资源授予RSIP主机。RSIP网关上不需要ALG来进行RSIP主机和不同寻址域中主机之间的通信。
RSIP can be viewed as a "fix", of sorts, to NAT. It may ameliorate some IP address shortage problems in some scenarios without some of the limitations of NAT. However, it is not a long-term solution to the IP address shortage problem. RSIP allows a degree of address realm transparency to be achieve between two differently-scoped, or completely different addressing realms. This makes it a useful architecture for enabling end-to-end packet transparency between addressing realms. RSIP is expected to be deployed on privately addresses IPv4 networks and used to grant access to publically addressed IPv4 networks. However, in place of the private IPv4 network, there may be an IPv6 network, or a non-IP network. Thus, RSIP allows IP connectivity to a host with an IP stack and IP applications but no native IP access. As such, RSIP can be used, in conjunction with DNS and tunneling, to bridge IPv4 and IPv6 networks, such that dual-stack hosts can communicate with local or remote IPv4 or IPv6 hosts.
RSIP可以被视为NAT的某种“修复”。它可以改善某些场景中的IP地址不足问题，而不受NAT的限制。然而，这并不是解决IP地址短缺问题的长期办法。RSIP允许在两个范围不同或完全不同的寻址域之间实现一定程度的地址域透明度。这使得它成为一个有用的体系结构，用于实现寻址领域之间的端到端数据包透明性。RSIP预计将部署在私有地址的IPv4网络上，并用于授予对公共地址的IPv4网络的访问权限。但是，代替专用IPv4网络的可能是IPv6网络或非IP网络。因此，RSIP允许IP连接到具有IP堆栈和IP应用程序的主机，但不允许本地IP访问。因此，RSIP可以与DNS和隧道技术结合使用，以桥接IPv4和IPv6网络，从而双栈主机可以与本地或远程IPv4或IPv6主机通信。
It is important to note that, as it is defined here, RSIP does NOT require modification of applications. All RSIP-related modifications to an RSIP host can occur at layers 3 and 4. However, while RSIP does allow end-to-end packet transparency, it may not be transparent to all applications. More details can be found in the section "RSIP complications", below.
需要注意的是，正如这里定义的，RSIP不需要修改应用程序。对RSIP主机的所有RSIP相关修改都可能发生在第3层和第4层。然而，尽管RSIP允许端到端数据包透明，但它可能对所有应用程序都不透明。更多详情见下文“RSIP并发症”一节。
This document provides a framework for RSIP by focusing on four particular areas:
本文件通过关注四个特定领域，为RSIP提供了一个框架：
- Requirements of an RSIP host and RSIP gateway.
- RSIP主机和RSIP网关的要求。
- Likely initial deployment scenarios.
- 可能的初始部署场景。
- Interaction with other layer-three protocols.
- 与其他第三层协议的交互。
- Complications that RSIP may introduce.
- RSIP可能引起的并发症。
The interaction sections will be at an overview level. Detailed modifications that would need to be made to RSIP and/or the interacting protocol are left for separate documents to discuss in detail.
交互部分将处于概述级别。需要对RSIP和/或交互协议进行的详细修改留给单独的文件详细讨论。
Beyond the scope of this document is discussion of RSIP in large, multiple-gateway networks, or in environments where RSIP state would need to be distributed and maintained across multiple redundant entities.
在本文档的范围之外，讨论了大型、多网关网络中的RSIP，或者在需要跨多个冗余实体分布和维护RSIP状态的环境中的RSIP。
Discussion of RSIP solutions that do not use some form of tunnel between the RSIP host and RSIP gateway are also not considered in this document.
本文档中也不考虑在RSIP主机和RSIP网关之间不使用某种形式隧道的RSIP解决方案的讨论。
This document focuses on scenarios that allow privately-addressed IPv4 hosts or IPv6 hosts access to publically-addressed IPv4 networks.
本文档重点介绍允许私人寻址IPv4主机或IPv6主机访问公共寻址IPv4网络的场景。
Private Realm
私人领域
A routing realm that uses private IP addresses from the ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in [RFC1918], or addresses that are non-routable from the Internet.
使用[RFC1918]中指定的范围（10.0.0.0/8172.16.0.0/12192.168.0.0/16）中的专用IP地址或不可从Internet路由的地址的路由领域。
Public Realm
公共领域
A routing realm with globally unique network addresses.
具有全局唯一网络地址的路由域。
RSIP Host
RSIP主机
A host within an addressing realm that uses RSIP to acquire addressing parameters from another addressing realm via an RSIP gateway.
寻址域内的主机，它使用RSIP通过RSIP网关从另一个寻址域获取寻址参数。
RSIP Gateway
RSIP网关
A router or gateway situated on the boundary between two addressing realms that is assigned one or more IP addresses in at least one of the realms. An RSIP gateway is responsible for parameter management and assignment from one realm to RSIP hosts in the other realm. An RSIP gateway may act as a normal NAT router for hosts within the a realm that are not RSIP enabled.
位于两个寻址域之间的边界上的路由器或网关，在至少一个寻址域中分配一个或多个IP地址。RSIP网关负责从一个领域到另一个领域的RSIP主机的参数管理和分配。RSIP网关可以作为域内未启用RSIP的主机的普通NAT路由器。
RSIP Client
RSIP客户端
An application program that performs the client portion of the RSIP client/server protocol. An RSIP client application MUST exist on all RSIP hosts, and MAY exist on RSIP gateways.
执行RSIP客户机/服务器协议的客户机部分的应用程序。RSIP客户端应用程序必须存在于所有RSIP主机上，并且可能存在于RSIP网关上。
RSIP Server
RSIP服务器
An application program that performs the server portion of the RSIP client/server protocol. An RSIP server application MUST exist on all RSIP gateways.
执行RSIP客户机/服务器协议的服务器部分的应用程序。RSIP服务器应用程序必须存在于所有RSIP网关上。
RSA-IP: Realm Specific Address IP
RSA-IP：领域特定地址IP
An RSIP method in which each RSIP host is allocated a unique IP address from the public realm.
一种RSIP方法，其中每个RSIP主机从公共领域分配一个唯一的IP地址。
RSAP-IP: Realm Specific Address and Port IP
RSAP-IP：领域特定地址和端口IP
An RSIP method in which each RSIP host is allocated an IP address (possibly shared with other RSIP hosts) and some number of per-address unique ports from the public realm.
一种RSIP方法，其中每个RSIP主机被分配一个IP地址（可能与其他RSIP主机共享）和一些来自公共领域的每个地址的唯一端口。
Demultiplexing Fields
解复用场
Any set of packet header or payload fields that an RSIP gateway uses to route an incoming packet to an RSIP host.
RSIP网关用于将传入数据包路由到RSIP主机的任何一组数据包头或有效负载字段。
All other terminology found in this document is consistent with that of [RFC2663].
本文件中的所有其他术语与[RFC2663]中的术语一致。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this documents are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In a typical scenario where RSIP is deployed, there are some number of hosts within one addressing realm connected to another addressing realm by an RSIP gateway. This model is diagrammatically represented as follows:
在部署RSIP的典型场景中，一个寻址域中有一些主机通过RSIP网关连接到另一个寻址域。该模型用图表表示如下：
RSIP Host RSIP Gateway Host
RSIP主机RSIP网关主机
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )
Hosts X and Y belong to different addressing realms A and B, respectively, and N is an RSIP gateway (which may also perform NAT functions). N has two interfaces: Na on address space A, and Nb on address space B. N may have a pool of addresses in address space B which it can assign to or lend to X and other hosts in address space A. These addresses are not shown above, but they can be denoted as Nb1, Nb2, Nb3 and so on.
主机X和Y分别属于不同的寻址域A和B，而N是RSIP网关（也可以执行NAT功能）。N有两个接口：地址空间A上的Na和地址空间B上的Nb。N在地址空间B中可能有一个地址池，它可以分配给或借出给地址空间A中的X和其他主机。上面没有显示这些地址，但它们可以表示为Nb1、Nb2、Nb3等。
As is often the case, the hosts within address space A are likely to use private addresses while the RSIP gateway is multi-homed with one or more private addresses from address space A in addition to its public addresses from address space B. Thus, we typically refer to the realm in which the RSIP host resides as "private" and the realm from which the RSIP host borrows addressing parameters as the "public" realm. However, these realms may both be public or private - our notation is for convenience. In fact, address space A may be an IPv6 realm or a non-IP address space.
通常情况下，地址空间A内的主机可能使用专用地址，而RSIP网关除了地址空间B中的公共地址外，还具有地址空间A中的一个或多个专用地址。因此，我们通常将RSIP主机所在的领域称为“专用”RSIP主机从中借用寻址参数的领域称为“公共”领域。然而，这些领域可能是公共的，也可能是私有的——我们的符号是为了方便。事实上，地址空间A可以是IPv6域或非IP地址空间。
Host X, wishing to establish an end-to-end connection to a network entity Y situated within address space B, first negotiates and obtains assignment of the resources (e.g., addresses and other routing parameters of address space B) from the RSIP gateway. Upon assignment of these parameters, the RSIP gateway creates a mapping, referred as a "bind", of X's addressing information and the assigned resources. This binding enables the RSIP gateway to correctly de-multiplex and forward inbound traffic generated by Y for X. If permitted by the RSIP gateway, X may create multiple such bindings on the same RSIP gateway, or across several RSIP gateways. A lease time SHOULD be associated with each bind.
主机X希望建立到位于地址空间B内的网络实体Y的端到端连接，首先协商并从RSIP网关获得资源分配（例如，地址空间B的地址和其他路由参数）。分配这些参数后，RSIP网关将创建X的寻址信息和分配的资源的映射，称为“绑定”。此绑定使RSIP网关能够正确地解复用和转发Y为X生成的入站流量。如果RSIP网关允许，X可以在同一RSIP网关上或跨多个RSIP网关创建多个此类绑定。租赁时间应与每个绑定相关联。
Using the public parameters assigned by the RSIP gateway, RSIP hosts tunnel data packets across address space A to the RSIP gateway. The RSIP gateway acts as the end point of such tunnels, stripping off the outer headers and routing the inner packets onto the public realm. As mentioned above, an RSIP gateway maintains a mapping of the
使用RSIP网关分配的公共参数，RSIP通过地址空间A承载隧道数据包到RSIP网关。RSIP网关充当此类隧道的端点，剥离外部头并将内部数据包路由到公共领域。如上所述，RSIP网关维护
assigned public parameters as demultiplexing fields for uniquely mapping them to RSIP host private addresses. When a packet from the public realm arrives at the RSIP gateway and it matches a given set of demultiplexing fields, then the RSIP gateway will tunnel it to the appropriate RSIP host. The tunnel headers of outbound packets from X to Y, given that X has been assigned Nb, are as follows:
将公共参数指定为解复用字段，以便将其唯一映射到RSIP主机专用地址。当来自公共领域的数据包到达RSIP网关并与给定的解复用字段集匹配时，RSIP网关将通过隧道将其传输到适当的RSIP主机。假设X已被分配Nb，则从X到Y的出站数据包的隧道头如下所示：
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP hosts and gateways MAY support RSA-IP, RSAP-IP, or both.
RSIP有两种基本风格：RSA-IP和RSAP-IP。RSIP主机和网关可能支持RSA-IP、RSAP-IP或两者。
When using RSA-IP, an RSIP gateway maintains a pool of IP addresses to be leased by RSIP hosts. Upon host request, the RSIP gateway allocates an IP address to the host. Once an address is allocated to a particular host, only that host may use the address until the address is returned to the pool. Hosts MAY NOT use addresses that have not been specifically assigned to them. The hosts may use any TCP/UDP port in combination with their assigned address. Hosts may also run gateway applications at any port and these applications will be available to the public network without assistance from the RSIP gateway. A host MAY lease more than one address from the same or different RSIP gateways. The demultiplexing fields of an RSA-IP session MUST include the IP address leased to the host.
当使用RSA-IP时，RSIP网关维护一个由RSIP主机租用的IP地址池。根据主机请求，RSIP网关为主机分配IP地址。将地址分配给特定主机后，只有该主机才能使用该地址，直到该地址返回到池。主机不能使用未专门分配给它们的地址。主机可以将任何TCP/UDP端口与其分配的地址结合使用。主机也可以在任何端口运行网关应用程序，这些应用程序将可用于公共网络，而无需RSIP网关的帮助。主机可以从相同或不同的RSIP网关租用多个地址。RSA-IP会话的解复用字段必须包括租用给主机的IP地址。
When using RSAP-IP, an RSIP gateway maintains a pool of IP addresses as well as pools of port numbers per address. RSIP hosts lease an IP address and one or more ports to use with it. Once an address / port tuple has been allocated to a particular host, only that host may use the tuple until it is returned to the pool(s). Hosts MAY NOT use address / port combinations that have not been specifically assigned to them. Hosts may run gateway applications bound to an allocated tuple, but their applications will not be available to the public network unless the RSIP gateway has agreed to route all traffic destined to the tuple to the host. A host MAY lease more than one tuple from the same or different RSIP gateways. The demultiplexing fields of an RSAP-IP session MUST include the tuple(s) leased to the host.
使用RSAP-IP时，RSIP网关维护IP地址池以及每个地址的端口号池。RSIP主机租用一个IP地址和一个或多个端口来使用它。将地址/端口元组分配给特定主机后，只有该主机才能使用该元组，直到该元组返回到池。主机不能使用未专门分配给它们的地址/端口组合。主机可以运行绑定到已分配元组的网关应用程序，但除非RSIP网关同意将所有发送到元组的流量路由到主机，否则它们的应用程序将不可用于公共网络。主机可以从相同或不同的RSIP网关租用多个元组。RSAP-IP会话的解复用字段必须包括租用给主机的元组。
An RSIP host MUST be able to maintain one or more virtual interfaces for the IP address(es) that it leases from an RSIP gateway. The host MUST also support tunneling and be able to serve as an end-point for
RSIP主机必须能够为从RSIP网关租用的IP地址维护一个或多个虚拟接口。主机还必须支持隧道，并能够作为
one or more tunnels to RSIP gateways. An RSIP host MUST NOT respond to ARPs for a public realm address that it leases.
到RSIP网关的一个或多个隧道。RSIP主机不得对其租用的公共域地址响应ARP。
An RSIP host supporting RSAP-IP MUST be able to maintain a set of one or more ports assigned by an RSIP gateway from which choose ephemeral source ports. If the host's pool does not have any free ports and the host needs to open a new communication session with a public host, it MUST be able to dynamically request one or more additional ports via its RSIP mechanism.
支持RSAP-IP的RSIP主机必须能够维护由RSIP网关分配的一组或多个端口，从中选择临时源端口。如果主机的池没有任何可用端口，并且主机需要打开与公共主机的新通信会话，则必须能够通过其RSIP机制动态请求一个或多个附加端口。
An RSIP gateway is a multi-homed host that routes packets between two or more realms. Often, an RSIP gateway is a boundary router between two or more administrative domains. It MUST also support tunneling and be able to serve as an end-point for tunnels to RSIP hosts. The RSIP gateway MAY be a policy enforcement point, which in turn may require it to perform firewall and packet filtering duties in addition to RSIP. The RSIP gateway MUST reassemble all incoming packet fragments from the public network in order to be able to route and tunnel them to the proper host. As is necessary for fragment reassembly, an RSIP gateway MUST timeout fragments that are never fully reassembled.
RSIP网关是在两个或多个域之间路由数据包的多宿主主机。通常，RSIP网关是两个或多个管理域之间的边界路由器。它还必须支持隧道，并能够作为RSIP主机隧道的端点。RSIP网关可能是一个策略实施点，这反过来又可能要求它执行RSIP之外的防火墙和包过滤职责。RSIP网关必须重新组装来自公共网络的所有传入数据包片段，以便能够将它们路由并通过隧道传输到适当的主机。正如片段重组所必需的那样，RSIP网关必须超时从未完全重组的片段。
An RSIP gateway MAY include NAT functionality so that hosts on the private network that are not RSIP-enabled can still communicate with the public network. An RSIP gateway MUST manage all resources that are assigned to RSIP hosts. This management MAY be done according to local policy.
RSIP网关可包括NAT功能，以便专用网络上未启用RSIP的主机仍可与公用网络通信。RSIP网关必须管理分配给RSIP主机的所有资源。该管理可根据当地政策进行。
Each active RSIP host must have a unique set of demultiplexing fields assigned to it so that an RSIP gateway can route incoming packets appropriately. Depending on the type of mapping used by the RSIP gateway, demultiplexing fields have been defined to be one or more of the following:
每个活动RSIP主机必须具有一组分配给它的唯一解复用字段，以便RSIP网关可以适当地路由传入数据包。根据RSIP网关使用的映射类型，解复用字段定义为以下一个或多个字段：
- destination IP address
- 目标IP地址
- IP protocol
- IP协议
- destination TCP or UDP port
- 目标TCP或UDP端口
- IPSEC SPI present in ESP or AH header (see [RFC3104])
- ESP或AH标头中存在IPSEC SPI（请参阅[RFC3104]）
- others
- 其他
Note that these fields may be augmented by source IP address and source TCP or UDP port.
请注意，这些字段可以通过源IP地址和源TCP或UDP端口进行扩充。
Demultiplexing of incoming traffic can be based on a decision tree. The process begins with the examination of the IP header of the incoming packet, and proceeds to subsequent headers and then the payload.
传入流量的解复用可以基于决策树。该过程从检查传入数据包的IP报头开始，然后进入后续报头和有效负载。
- In the case where a public IP address is assigned for each host, a unique public IP address is mapped to each RSIP host.
- 在为每个主机分配公共IP地址的情况下，将唯一的公共IP地址映射到每个RSIP主机。
- If the same IP address is used for more than one RSIP host, then subsequent headers must have at least one field that will be assigned a unique value per host so that it is usable as a demultiplexing field. The IP protocol field SHOULD be used to determine what in the subsequent headers these demultiplexing fields ought to be.
- 如果同一IP地址用于多个RSIP主机，则后续报头必须至少有一个字段，每个主机将分配一个唯一值，以便它可用作解复用字段。IP协议字段应用于确定这些解复用字段在随后的报头中应该是什么。
- If the subsequent header is TCP or UDP, then destination port number can be used. However, if the TCP/UDP port number is the same for more than one RSIP host, the payload section of the packet must contain a demultiplexing field that is guaranteed to be different for each RSIP host. Typically this requires negotiation of said fields between the RSIP host and gateway so that the RSIP gateway can guarantee that the fields are unique per-host
- 如果后续标头是TCP或UDP，则可以使用目标端口号。但是，如果TCP/UDP端口号对于多个RSIP主机相同，则数据包的有效负载部分必须包含一个解复用字段，该字段保证每个RSIP主机的解复用字段不同。通常，这需要在RSIP主机和网关之间协商所述字段，以便RSIP网关能够保证每个主机的字段是唯一的
- If the subsequent header is anything other than TCP or UDP, there must exist other fields within the IP payload usable as demultiplexing fields. In other words, these fields must be able to be set such that they are guaranteed to be unique per-host. Typically this requires negotiation of said fields between the RSIP host and gateway so that the RSIP gateway can guarantee that the fields are unique per-host.
- 如果后续标头不是TCP或UDP，则IP有效负载中必须存在可用作解复用字段的其他字段。换句话说，必须能够设置这些字段，以确保它们在每个主机上都是唯一的。通常，这需要在RSIP主机和网关之间协商所述字段，以便RSIP网关能够保证每个主机的字段是唯一的。
It is desirable for all demultiplexing fields to occur in well-known fixed locations so that an RSIP gateway can mask out and examine the appropriate fields on incoming packets. Demultiplexing fields that are encrypted MUST NOT be used for routing.
希望所有解复用字段出现在众所周知的固定位置，以便RSIP网关能够屏蔽和检查传入分组上的适当字段。加密的解复用字段不得用于路由。
RSIP gateways and hosts MUST be able to negotiate IP addresses when using RSA-IP, IP address / port tuples when using RSAP-IP, and possibly other demultiplexing fields for use in other modes.
RSIP网关和主机在使用RSA-IP时必须能够协商IP地址，在使用RSAP-IP时必须能够协商IP地址/端口元组，以及在其他模式下可能使用的其他解复用字段。
In this section we discuss the requirements and implementation issues of an RSIP negotiation protocol.
在本节中，我们将讨论RSIP协商协议的要求和实现问题。
For each required demultiplexing field, an RSIP protocol MUST, at the very least, allow for:
对于每个要求的解复用字段，RSIP协议必须至少考虑：
- RSIP hosts to request assignments of demultiplexing fields
- RSIP主机请求分配解复用字段
- RSIP gateways to assign demultiplexing fields with an associated lease time
- RSIP网关分配具有相关租用时间的解复用字段
- RSIP gateways to reclaim assigned demultiplexing fields
- 用于回收分配的解复用字段的RSIP网关
Additionally, it is desirable, though not mandatory, for an RSIP protocol to negotiate an RSIP method (RSA-IP or RSAP-IP) and the type of tunnel to be used across the private network. The protocol SHOULD be extensible and facilitate vendor-specific extensions.
此外，RSIP协议需要协商RSIP方法（RSA-IP或RSAP-IP）和要在专用网络上使用的隧道类型，尽管不是强制性的。该协议应该是可扩展的，并且有助于特定于供应商的扩展。
If an RSIP negotiation protocol is implemented at the application layer, a choice of transport protocol MUST be made. RSIP hosts and gateways may communicate via TCP or UDP. TCP support is required in all RSIP gateways, while UDP support is optional. In RSIP hosts, TCP, UDP, or both may be supported. However, once an RSIP host and gateway have begun communicating using either TCP or UDP, they MAY NOT switch to the other transport protocol. For RSIP implementations and deployments considered in this document, TCP is the recommended transport protocol, because TCP is known to be robust across a wide range of physical media types and traffic loads.
如果在应用层实现RSIP协商协议，则必须选择传输协议。RSIP主机和网关可以通过TCP或UDP进行通信。所有RSIP网关都需要TCP支持，而UDP支持是可选的。在RSIP主机中，可能支持TCP、UDP或两者。但是，一旦RSIP主机和网关开始使用TCP或UDP进行通信，它们可能不会切换到其他传输协议。对于本文档中考虑的RSIP实现和部署，TCP是推荐的传输协议，因为众所周知，TCP在各种物理介质类型和流量负载中都是健壮的。
It is recommended that all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and (with an anti-replay counter) avoid replay attacks. In order for authentication to be supported, each RSIP host and the RSIP gateway MUST either share a secret key (distributed, for example, by Kerberos) or have a private/public key pair. In the latter case, an entity's public key can be computed over each message and a hash function applied to the result to form the message hash.
建议对RSIP主机和网关之间的所有通信进行身份验证。以消息散列的形式附加到每个RSIP协议包的末尾的身份验证可用于相互验证RSIP主机和网关，提供消息完整性，以及（使用反重放计数器）避免重放攻击。为了支持身份验证，每个RSIP主机和RSIP网关必须共享一个密钥（例如，通过Kerberos分发）或拥有一个私钥/公钥对。在后一种情况下，可以对每条消息计算实体的公钥，并对结果应用哈希函数以形成消息哈希。
An RSIP-enabled network has three uses for DNS: (1) public DNS services to map its static public IP addresses (i.e., the public address of the RSIP gateway) and for lookups of public hosts, (2) private DNS services for use only on the private network, and (3) dynamic DNS services for RSIP hosts.
启用RSIP的网络有三种DNS用途：（1）用于映射其静态公共IP地址（即RSIP网关的公共地址）和查找公共主机的公共DNS服务，（2）仅在专用网络上使用的专用DNS服务，以及（3）用于RSIP主机的动态DNS服务。
With respect to (1), public DNS information MUST be propagated onto the private network. With respect to (2), private DNS information MUST NOT be propagated into the public network.
关于（1），公共DNS信息必须传播到专用网络上。关于（2），私有DNS信息不得传播到公共网络中。
With respect to (3), an RSIP-enabled network MAY allow for RSIP hosts with FQDNs to have their A and PTR records updated in the public DNS. These updates are based on address assignment facilitated by RSIP, and should be performed in a fashion similar to DHCP updates to dynamic DNS [DHCP-DNS]. In particular, RSIP hosts should be allowed to update their A records but not PTR records, while RSIP gateways can update both. In order for the RSIP gateway to update DNS records on behalf on an RSIP host, the host must provide the gateway with its FQDN.
关于（3），启用RSIP的网络可允许具有FQDN的RSIP主机在公共DNS中更新其A和PTR记录。这些更新基于RSIP促进的地址分配，应该以类似于动态DNS[DHCP-DNS]的DHCP更新的方式执行。特别是，应该允许RSIP主机更新其A记录，但不能更新PTR记录，而RSIP网关可以同时更新这两个记录。为了使RSIP网关代表RSIP主机更新DNS记录，主机必须向网关提供其FQDN。
Note that when using RSA-IP, the interaction with DNS is completely analogous to that of DHCP because the RSIP host "owns" an IP address for a period of time. In the case of RSAP-IP, the claim that an RSIP host has to an address is only with respect to the port(s) that it has leased along with an address. Thus, two or more RSIP hosts' FQDNs may map to the same IP address. However, a public host may expect that all of the applications running at a particular address are owned by the same logical host, which would not be the case. It is recommended that RSAP-IP and dynamic DNS be integrated with some caution, if at all.
请注意，在使用RSA-IP时，与DNS的交互与DHCP的交互完全类似，因为RSIP主机在一段时间内“拥有”一个IP地址。在RSAP-IP的情况下，RSIP主机必须访问地址的声明仅针对其租用的端口和地址。因此，两个或多个RSIP主机的FQDN可能映射到同一IP地址。但是，公共主机可能期望在特定地址上运行的所有应用程序都属于同一逻辑主机，但实际情况并非如此。建议将RSAP-IP和动态DNS集成在一起，如果需要的话，一定要小心。
When an RSIP host initializes, it requires (among other things) two critical pieces of information. One is a local (private) IP address to use as its own, and the other is the private IP address of an RSIP gateway. This information can be statically configured or dynamically assigned.
RSIP主机初始化时，需要（除其他外）两条关键信息。一个是用作自身的本地（专用）IP地址，另一个是RSIP网关的专用IP地址。此信息可以静态配置或动态分配。
In the dynamic case, the host's private address is typically supplied by DHCP. A DHCP option could provide the IP address of an RSIP gateway in DHCPOFFER messages. Thus, the host's startup procedure would be as follows: (1) perform DHCP, (2) if an RSIP gateway option is present in the DHCPOFFER, record the IP address therein as the RSIP gateway.
在动态情况下，主机的专用地址通常由DHCP提供。DHCP选项可以在DHCPOFFER消息中提供RSIP网关的IP地址。因此，主机的启动过程如下：（1）执行DHCP，（2）如果DHCPOFFER中存在RSIP网关选项，则将其中的IP地址记录为RSIP网关。
Alternatively, the RSIP gateway can be discovered via SLP (Service Location Protocol) as specified in [SLP-RSIP]. The SLP template defined allows for RSIP service provisioning and load balancing.
或者，可以通过[SLP-RSIP]中指定的SLP（服务位置协议）发现RSIP网关。定义的SLP模板允许RSIP服务配置和负载平衡。
RSIP can be accomplished by any one of a wide range of implementation schemes. For example, it can be built into an existing configuration protocol such as DHCP or SOCKS, or it can exist as a separate protocol. This section discusses implementation issues of RSIP in general, regardless of how the RSIP mechanism is implemented.
RSIP可以通过多种实施方案中的任何一种来实现。例如，它可以内置到现有的配置协议（如DHCP或SOCKS）中，也可以作为单独的协议存在。本节一般讨论RSIP的实现问题，不管RSIP机制是如何实现的。
Note that on a host, RSIP is associated with a TCP/IP stack implementation. Modifications to IP tunneling and routing code, as well as driver interfaces may need to be made to support RSA-IP. Support for RSAP-IP requires modifications to ephemeral port selection code as well. If a host has multiple TCP/IP stacks or TCP/IP stacks and other communication stacks, RSIP will only operate on the packets / sessions that are associated with the TCP/IP stack(s) that use RSIP. RSIP is not application specific, and if it is implemented in a stack, it will operate beneath all applications that use the stack.
请注意，在主机上，RSIP与TCP/IP堆栈实现相关联。可能需要修改IP隧道和路由代码以及驱动程序接口，以支持RSA-IP。支持RSAP-IP还需要修改临时端口选择代码。如果主机具有多个TCP/IP堆栈或TCP/IP堆栈和其他通信堆栈，则RSIP将仅对与使用RSIP的TCP/IP堆栈关联的数据包/会话进行操作。RSIP不是特定于应用程序的，如果它在堆栈中实现，它将在使用该堆栈的所有应用程序下运行。
When RSIP is deployed in certain scenarios, the network characteristics of these scenarios will determine the scope of the RSIP solution, and therefore impact the requirements of RSIP. In this section, we examine deployment scenarios, and the impact that RSIP may have on existing networks.
当RSIP部署在某些场景中时，这些场景的网络特性将决定RSIP解决方案的范围，因此会影响RSIP的要求。在本节中，我们将研究部署场景，以及RSIP可能对现有网络产生的影响。
In this section we discuss a number of potential RSIP deployment scenarios. The selection below are not comprehensive and other scenarios may emerge.
在本节中，我们将讨论一些潜在的RSIP部署场景。下面的选择并不全面，可能会出现其他情况。
Up to several hundred hosts will reside behind an RSIP-enabled router. It is likely that there will be only one gateway to the public network and therefore only one RSIP gateway. This RSIP gateway may control only one, or perhaps several, public IP addresses. The RSIP gateway may also perform firewall functions, as well as routing inbound traffic to particular destination ports on to a small number of dedicated gateways on the private network.
多达数百台主机将驻留在支持RSIP的路由器后面。公共网络可能只有一个网关，因此只有一个RSIP网关。这个RSIP网关可能只控制一个或几个公共IP地址。RSIP网关还可以执行防火墙功能，以及将入站流量路由到专用网络上的少量专用网关上的特定目的地端口。
This category includes both networking within just one residence, as well as within multiple-dwelling units. At most several hundred hosts will share the gateway's resources. In particular, many of these devices may be thin hosts or so-called "network appliances" and therefore not require access to the public Internet frequently. The RSIP gateway is likely to be implemented as part of a residential firewall, and it may be called upon to route traffic to particular destination ports on to a small number of dedicated gateways on the private network. It is likely that only one gateway to the public
这一类别既包括一个住宅内的网络，也包括多个住宅单元内的网络。最多数百台主机将共享网关的资源。特别是，其中许多设备可能是瘦主机或所谓的“网络设备”，因此不需要经常访问公共互联网。RSIP网关可能作为住宅防火墙的一部分实现，并且可能需要它将流量路由到专用网络上的少量专用网关上的特定目的地端口。很可能只有一个通向公众的门户
network will be present and that this gateway's RSIP gateway will control only one IP address. Support for secure end-to-end VPN access to corporate intranets will be important.
网络将存在，并且该网关的RSIP网关将仅控制一个IP地址。支持对企业内部网的安全端到端VPN访问将非常重要。
A hospitality network is a general type of "hosting" network that a traveler will use for a short period of time (a few minutes or a few hours). Examples scenarios include hotels, conference centers and airports and train stations. At most several hundred hosts will share the gateway's resources. The RSIP gateway may be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP gateway will control only one IP address. Support for secure end-to-end VPN access to corporate intranets will be important.
酒店网络是旅行者在短时间内（几分钟或几小时）使用的一般类型的“托管”网络。示例场景包括酒店、会议中心、机场和火车站。最多数百台主机将共享网关的资源。RSIP网关可以作为防火墙的一部分实现，它可能不会用于将流量路由到专用网络上专用网关上的特定目标端口。很可能只有一个通向公共网络的网关，并且该网关的RSIP网关将只控制一个IP地址。支持对企业内部网的安全端到端VPN访问将非常重要。
RSIP gateways may be placed in dialup remote access concentrators in order to multiplex IP addresses across dialup users. At most several hundred hosts will share the gateway's resources. The RSIP gateway may or may not be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. Only one gateway to the public network will be present (the remote access concentrator itself) and that this gateway's RSIP gateway will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important.
RSIP网关可以放置在拨号远程访问集中器中，以便跨拨号用户多路传输IP地址。最多数百台主机将共享网关的资源。RSIP网关可能作为防火墙的一部分实施，也可能不作为防火墙的一部分实施，并且它可能不会用于将流量路由到专用网络上专用网关上的特定目标端口。只有一个到公共网络的网关（远程访问集中器本身）存在，并且该网关的RSIP网关将控制少量IP地址。支持对企业内部网的安全端到端VPN访问将非常重要。
Wireless remote access will become very prevalent as more PDA and IP / cellular devices are deployed. In these scenarios, hosts may be changing physical location very rapidly - therefore Mobile IP will play a role. Hosts typically will register with an RSIP gateway for a short period of time. At most several hundred hosts will share the gateway's resources. The RSIP gateway may be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP gateway will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important.
随着PDA和IP/蜂窝设备的部署，无线远程访问将变得非常普遍。在这些场景中，主机可能会非常迅速地改变物理位置，因此移动IP将发挥作用。主机通常会在短时间内向RSIP网关注册。最多数百台主机将共享网关的资源。RSIP网关可以作为防火墙的一部分实现，它可能不会用于将流量路由到专用网络上专用网关上的特定目标端口。很可能只有一个通向公共网络的网关，该网关的RSIP网关将控制少量IP地址。支持对企业内部网的安全端到端VPN访问将非常重要。
It is possible for RSIP to allow for cascading of RSIP gateways as well as cascading of RSIP gateways with NAT boxes. For example, consider an ISP that uses RSIP for address sharing amongst its customers. It might assign resources (e.g., IP addresses and ports) to a particular customer. This customer may use RSIP to further subdivide the port ranges and address(es) amongst individual end hosts. No matter how many levels of RSIP assignment exists, RSIP MUST only assign public IP addresses.
RSIP可以允许RSIP网关的级联以及RSIP网关与NAT盒的级联。例如，考虑一个ISP，它使用RSIP来实现客户之间的地址共享。它可能会将资源（例如IP地址和端口）分配给特定客户。该客户可以使用RSIP在各个终端主机之间进一步细分端口范围和地址。无论存在多少级别的RSIP分配，RSIP都必须只分配公共IP地址。
Note that some of the architectures discussed below may not be useful or desirable. The goal of this section is to explore the interactions between NAT and RSIP as RSIP is incrementally deployed on systems that already support NAT.
请注意，下面讨论的一些体系结构可能没有用处或不可取。本节的目标是探索NAT和RSIP之间的交互，因为RSIP是在已经支持NAT的系统上增量部署的。
A reference architecture is depicted below.
参考体系结构如下所示。
+-----------+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| B |
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ gateway |
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| C |
| |
+-----------+
+-----------+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| B |
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ gateway |
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| C |
| |
+-----------+
RSIP gateway A is in charge of the IP addresses of subnet 149.112.240.0/24. It distributes these addresses to RSIP hosts and RSIP gateways. In the given configuration, it distributes addresses 149.112.240.0 - 149.112.240.127 to RSIP gateway B, and addresses 149.112.240.128 - 149.112.240.254 to RSIP gateway C. Note that the subnet broadcast address, 149.112.240.255, must remain unclaimed, so that broadcast packets can be distributed to arbitrary hosts behind RSIP gateway A. Also, the subnets between RSIP gateway A and RSIP gateways B and C will use private addresses.
RSIP网关A负责子网149.112.240.0/24的IP地址。它将这些地址分发给RSIP主机和RSIP网关。在给定配置中，它将地址149.112.240.0-149.112.240.127分配给RSIP网关B，并将地址149.112.240.128-149.112.240.254分配给RSIP网关C。请注意，子网广播地址149.112.240.255必须保持无人认领，以便广播数据包可以分配给RSIP网关A后面的任意主机。此外，RSIP网关A与RSIP网关B和C之间的子网将使用专用地址。
Due to the tree-like fashion in which addresses will be cascaded, we will refer to RSIP gateways A as the 'parent' of RSIP gateways B and C, and RSIP gateways B and C as 'children' of RSIP gateways A. An arbitrary number of levels of children may exist under a parent RSIP gateway.
由于地址级联的树状方式，我们将RSIP网关A称为RSIP网关B和C的“父级”，RSIP网关B和C称为RSIP网关A的“子级”。父RSIP网关下可能存在任意数量的子级。
A parent RSIP gateway will not necessarily be aware that the address(es) and port blocks that it distributes to a child RSIP gateway will be further distributed. Thus, the RSIP hosts MUST tunnel their outgoing packets to the nearest RSIP gateway. This gateway will then verify that the sending host has used the proper address and port block, and then tunnel the packet on to its parent RSIP gateway.
父RSIP网关不一定知道它分配给子RSIP网关的地址和端口块将被进一步分配。因此，RSIP主机必须通过隧道将其传出的数据包传输到最近的RSIP网关。然后，该网关将验证发送主机是否使用了正确的地址和端口块，然后通过隧道将数据包传输到其父RSIP网关。
For example, in the context of the diagram above, host 10.0.0.1, behind RSIP gateway C will use its assigned external IP address (say, 149.112.240.130) and tunnel its packets over the 10.0.0.0/8 subnet to RSIP gateway C. RSIP gateway C strips off the outer IP header. After verifying that the source public IP address and source port number is valid, RSIP gateway C will tunnel the packets over the 10.0.2.0/8 subnet to RSIP gateway A. RSIP gateway A strips off the outer IP header. After verifying that the source public IP address and source port number is valid, RSIP gateway A transmits the packet on the public network.
例如，在上图的上下文中，RSIP网关C后面的主机10.0.0.1将使用其分配的外部IP地址（例如，149.112.240.130），并通过隧道将其数据包通过10.0.0.0/8子网传输到RSIP网关C。RSIP网关C将剥离外部IP头。在验证源公共IP地址和源端口号有效后，RSIP网关C将通过10.0.2.0/8子网将数据包隧道传输到RSIP网关A。RSIP网关A剥离外部IP头。在验证源公共IP地址和源端口号有效后，RSIP网关A在公共网络上传输数据包。
While it may be more efficient in terms of computation to have a RSIP host tunnel directly to the overall parent of an RSIP gateway tree, this would introduce significant state and administrative difficulties.
尽管在计算方面，将RSIP主机隧道直接连接到RSIP网关树的整个父级可能更有效，但这将带来重大的状态和管理困难。
A RSIP gateway that is a child MUST take into consideration the parameter assignment constraints that it inherits from its parent when it assigns parameters to its children. For example, if a child RSIP gateway is given a lease time of 3600 seconds on an IP address, it MUST compare the current time to the lease time and the time that the lease was assigned to compute the maximum allowable lease time on the address if it is to assign the address to a RSIP host or child RSIP gateway.
作为子级的RSIP网关在向其子级分配参数时，必须考虑从其父级继承的参数分配约束。例如，如果子RSIP网关在IP地址上的租用时间为3600秒，则如果要将地址分配给RSIP主机或子RSIP网关，则必须将当前时间与租用时间以及分配租用的时间进行比较，以计算该地址上允许的最长租用时间。
+--------+ +--------+
| NAT w/ | | RSIP |
hosts ------+ RSIP +------+ gate- +----- public network
| host | | way |
+--------+ +--------+
+--------+ +--------+
| NAT w/ | | RSIP |
hosts ------+ RSIP +------+ gate- +----- public network
| host | | way |
+--------+ +--------+
In this architecture, an RSIP gateway is between a NAT box and the public network. The NAT is also equipped with an RSIP host. The NAT dynamically requests resources from the RSIP gateway as the hosts establish sessions to the public network. The hosts are not aware of the RSIP manipulation. This configuration does not enable the hosts to have end-to-end transparency and thus the NAT still requires ALGs and the architecture cannot support IPSEC.
在这种体系结构中，RSIP网关位于NAT盒和公共网络之间。NAT还配备了RSIP主机。当主机建立到公共网络的会话时，NAT动态地从RSIP网关请求资源。主机不知道RSIP操作。此配置不允许主机具有端到端透明性，因此NAT仍然需要ALG，并且体系结构无法支持IPSEC。
+--------+ +--------+
RSIP | RSIP | | |
hosts ------+ gate- +------+ NAT +----- public network
| way | | |
+--------+ +--------+
+--------+ +--------+
RSIP | RSIP | | |
hosts ------+ gate- +------+ NAT +----- public network
| way | | |
+--------+ +--------+
In this architecture, the RSIP hosts and gateway reside behind a NAT. This configuration does not enable the hosts to have end-to-end transparency and thus the NAT still requires ALGs and the architecture cannot support IPSEC. The hosts may have transparency if there is another gateway to the public network besides the NAT box, and this gateway supports cascaded RSIP behind RSIP.
在这种体系结构中，RSIP主机和网关位于NAT后面。此配置不允许主机具有端到端透明性，因此NAT仍然需要ALG，并且体系结构无法支持IPSEC。如果除了NAT箱之外还有另一个通向公共网络的网关，并且该网关支持RSIP后面的级联RSIP，则主机可能具有透明性。
+--------+ +--------+
RSIP | | | RSIP |
hosts ------+ NAT +------+ gate- +----- public network
| | | way |
+--------+ +--------+
+--------+ +--------+
RSIP | | | RSIP |
hosts ------+ NAT +------+ gate- +----- public network
| | | way |
+--------+ +--------+
In this architecture, the RSIP hosts are separated from the RSIP gateway by a NAT. RSIP signaling may be able to pass through the NAT if an RSIP ALG is installed. The RSIP data flow, however, will have its outer IP address translated by the NAT. The NAT must not translate the port numbers in order for RSIP to work properly. Therefore, only traditional NAT will make sense in this context.
在此架构中，RSIP主机通过NAT与RSIP网关分离。如果安装了RSIP ALG，则RSIP信令可能能够通过NAT。然而，RSIP数据流将由NAT转换其外部IP地址。NAT不得转换端口号以使RSIP正常工作。因此，在这种情况下，只有传统的NAT才有意义。
Since RSIP affects layer-three objects, it has an impact on other layer three protocols. In this section, we outline the impact of RSIP on these protocols, and in each case, how RSIP, the protocol, or both, can be extended to support interaction.
由于RSIP影响第三层对象，因此它会影响其他第三层协议。在本节中，我们将概述RSIP对这些协议的影响，以及在每种情况下，如何扩展RSIP、协议或两者以支持交互。
Each of these sections is an overview and not a complete technical specification. If a full technical specification of how RSIP interacts with a layer-three protocol is necessary, a separate document will contain it.
这些章节都是概述，而不是完整的技术规范。如果需要一份关于RSIP如何与第三层协议交互的完整技术规范，则需要一份单独的文档。
RSIP is a mechanism for allowing end-to-end IPSEC with sharing of IP addresses. Full specification of RSIP/IPSEC details are in [RSIP-IPSEC]. This section provides a brief summary. Since IPSEC may encrypt TCP/UDP port numbers, these objects cannot be used as demultiplexing fields. However, IPSEC inserts an AH or ESP header following the IP header in all IPSEC-protected packets (packets that are transmitted on an IPSEC Security Association (SA)). These headers contain a 32-bit Security Parameter Index (SPI) field, the value of which is determined by the receiving side. The SPI field is always in the clear. Thus, during SA negotiation, an RSIP host can instruct their public peer to use a particular SPI value. This SPI value, along with the assigned IP address, can be used by an RSIP gateway to uniquely identify and route packets to an RSIP host. In order to guarantee that RSIP hosts use SPIs that are unique per address, it is necessary for the RSIP gateway to allocate unique SPIs to hosts along with their address/port tuple.
RSIP是一种允许端到端IPSEC共享IP地址的机制。RSIP/IPSEC详细信息的完整规范见[RSIP-IPSEC]。本节提供了一个简要的总结。由于IPSEC可能会加密TCP/UDP端口号，因此这些对象不能用作解复用字段。但是，IPSEC在所有受IPSEC保护的数据包（在IPSEC安全关联（SA）上传输的数据包）的IP头之后插入AH或ESP头。这些标头包含一个32位安全参数索引（SPI）字段，其值由接收方确定。SPI字段始终处于清除状态。因此，在SA协商期间，RSIP主机可以指示其公共对等方使用特定的SPI值。RSIP网关可以使用此SPI值以及分配的IP地址来唯一标识数据包并将其路由到RSIP主机。为了保证RSIP主机使用每个地址唯一的SPI，RSIP网关必须将唯一的SPI与其地址/端口元组一起分配给主机。
IPSEC SA negotiation takes place using the Internet Key Exchange (IKE) protocol. IKE is designated to use port 500 on at least the destination side. Some host IKE implementations will use source port 500 as well, but this behavior is not mandatory. If two or more RSIP hosts are running IKE at source port 500, they MUST use different initiator cookies (the first eight bytes of the IKE payload) per assigned IP address. The RSIP gateway will be able to route incoming IKE packets to the proper host based on initiator cookie value. Initiator cookies can be negotiated, like ports and SPIs. However, since the likelihood of two hosts assigned the same IP address attempting to simultaneously use the same initiator cookie is very small, the RSIP gateway can guarantee cookie uniqueness by dropping IKE packets with a cookie value that is already in use.
IPSEC SA协商使用Internet密钥交换（IKE）协议进行。IKE被指定至少在目的地侧使用端口500。一些主机IKE实现也将使用源端口500，但此行为不是强制性的。如果两个或多个RSIP主机在源端口500处运行IKE，则它们必须为每个分配的IP地址使用不同的启动器cookie（IKE负载的前八个字节）。RSIP网关将能够根据启动器cookie值将传入的IKE数据包路由到适当的主机。可以协商启动器cookie，如端口和SPI。然而，由于两个分配了相同IP地址的主机尝试同时使用相同启动器cookie的可能性非常小，因此RSIP网关可以通过丢弃具有已在使用的cookie值的IKE数据包来保证cookie的唯一性。
Mobile IP allows a mobile host to maintain an IP address as it moves from network to network. For Mobile IP foreign networks that use private IP addresses, RSIP may be applicable. In particular, RSIP would allow a mobile host to bind to a local private address, while maintaining a global home address and a global care-of address. The global care-of address could, in principle, be shared with other mobile nodes.
移动IP允许移动主机在网络间移动时维护IP地址。对于使用专用IP地址的移动IP外部网络，RSIP可能适用。特别是，RSIP将允许移动主机绑定到本地专用地址，同时维护全局家庭地址和全局转交地址。原则上，全局转交地址可以与其他移动节点共享。
The exact behavior of Mobile IP with respect to private IP addresses has not be settled. Until it is, a proposal to adapt RSIP to such a scenario is premature. Also, such an adaptation may be considerably complex. Thus, integration of RSIP and Mobile IP is a topic of ongoing consideration.
移动IP相对于专用IP地址的确切行为尚未解决。在此之前，让RSIP适应这种情况的建议还为时过早。此外，这种适应可能相当复杂。因此，RSIP和移动IP的集成是一个正在考虑的话题。
To attain the capability of providing quality of service between two communicating hosts in different realms, it is important to consider the interaction of RSIP with different quality of service provisioning models and mechanisms. In the section, RSIP interaction with the integrated service and differentiated service frameworks is discussed.
为了实现在不同领域中的两个通信主机之间提供服务质量的能力，重要的是考虑RSIP与不同的服务质量提供模型和机制的相互作用。本节将讨论RSIP与集成服务和差异化服务框架的交互。
The differentiated services architecture defined in [RFC2475] allows networks to support multiple levels of best-effort service through the use of "markings" of the IP Type-of-Service (now DS) byte. Each value of the DS byte is termed a differentiated services code point (DSCP) and represents a particular per-hop behavior. This behavior may not be the same in all administrative domains. No explicit signaling is necessary to support differentiated services.
[RFC2475]中定义的差异化服务体系结构允许网络通过使用IP服务类型（现在是DS）字节的“标记”来支持多个级别的尽力而为服务。DS字节的每个值称为区分服务代码点（DSCP），表示特定的每跳行为。此行为在所有管理域中可能不相同。不需要显式信令来支持区分服务。
For outbound packets from an edge network, DSCP marking is typically performed and/or enforced on a boundary router. The marked packet is then forwarded onto the public network. In an RSIP-enabled network, a natural place for DSCP marking is the RSIP gateway. In the case of RSAP-IP, the RSIP gateway can apply its micro-flow (address/port tuple) knowledge of RSIP assignments in order to provide different service levels to different RSIP host. For RSA-IP, the RSIP gateway will not necessarily have knowledge of micro-flows, so it must rely on markings made by the RSIP hosts (if any) or apply a default policy to the packets.
对于来自边缘网络的出站数据包，DSCP标记通常在边界路由器上执行和/或强制执行。然后将标记的数据包转发到公共网络上。在支持RSIP的网络中，DSCP标记的自然位置是RSIP网关。在RSAP-IP的情况下，RSIP网关可以应用其RSIP分配的微流（地址/端口元组）知识，以便为不同的RSIP主机提供不同的服务级别。对于RSA-IP，RSIP网关不一定知道微流，因此它必须依赖RSIP主机（如果有）所做的标记，或者对数据包应用默认策略。
When differentiated services is to be performed between RSIP hosts and gateways, it must be done over the tunnel between these entities. Differentiated services over a tunnel is considered in detail in [DS-TUNN], the key points that need to be addressed here are the behaviors of tunnel ingress and egress for both incoming and going packets.
当要在RSIP主机和网关之间执行差异化服务时，必须通过这些实体之间的隧道来完成。[DS-TUNN]中详细考虑了隧道上的区分服务，这里需要解决的关键点是传入和传出数据包的隧道入口和出口行为。
For incoming packets arriving at an RSIP gateway tunnel ingress, the RSIP gateway may either copy the DSCP from the inner header to the outer header, leave the inner header DSCP untouched, but place a different DSCP in the outer header, or change the inner header DSCP while applying either the same or a different DSCP to the outer header.
对于到达RSIP网关隧道入口的传入数据包，RSIP网关可以将DSCP从内部报头复制到外部报头，保持内部报头DSCP不变，但在外部报头中放置不同的DSCP，或者在对外部报头应用相同或不同的DSCP时更改内部报头DSCP。
For incoming packets arriving at an RSIP host tunnel egress, behavior with respect to the DSCP is not necessarily important if the RSIP host not only terminates the tunnel, but consumes the packet as well. If this is not the case, as per some cascaded RSIP scenarios, the RSIP host must apply local policy to determine whether to leave the inner header DSCP as is, overwrite it with the outer header DSCP, or overwrite it with a different value.
对于到达RSIP主机隧道出口的传入数据包，如果RSIP主机不仅终止隧道，而且还使用数据包，则与DSCP相关的行为不一定重要。如果情况并非如此，则根据某些级联RSIP方案，RSIP主机必须应用本地策略，以确定是保持内部标头DSCP不变，还是使用外部标头DSCP覆盖，还是使用其他值覆盖。
For outgoing packets arriving at an RSIP host tunnel ingress, the host may either copy the DSCP from the inner header to the outer header, leave the inner header DSCP untouched, but place a different DSCP in the outer header, or change the inner header DSCP while applying either the same or a different DSCP to the outer header.
对于到达RSIP主机隧道入口的传出数据包，主机可以将DSCP从内部报头复制到外部报头，保持内部报头DSCP不变，但在外部报头中放置不同的DSCP，或者在对外部报头应用相同或不同的DSCP时更改内部报头DSCP。
For outgoing packets arriving at an RSIP gateway tunnel egress, the RSIP gateway must apply local policy to determine whether to leave the inner header DSCP as is, overwrite it with the outer header DSCP, or overwrite it with a different value.
对于到达RSIP网关隧道出口的传出数据包，RSIP网关必须应用本地策略，以确定是保持内部报头DSCP不变，还是用外部报头DSCP覆盖，还是用其他值覆盖。
It is reasonable to assume that in most cases, the diffserv policy applicable on a site will be the same for RSIP and non-RSIP hosts. For this reason, a likely policy is that the DSCP will always be copied between the outer and inner headers in all of the above cases. However, implementations should allow for the more general case.
可以合理地假设，在大多数情况下，适用于站点的区分服务策略对于RSIP和非RSIP主机是相同的。出于这个原因，一个可能的策略是，在上述所有情况下，DSCP总是在外部和内部头之间复制。但是，实现应该考虑更一般的情况。
The integrated services model as defined by [RFC2205] requires signalling using RSVP to setup a resource reservation in intermediate nodes between the communicating endpoints. In the most common scenario in which RSIP is deployed, receivers located within the private realm initiate communication sessions with senders located within the public realm. In this section, we discuss the interaction of RSIP architecture and RSVP in such a scenario. The less common
[RFC2205]定义的集成服务模型要求使用RSVP发送信令，以在通信端点之间的中间节点中设置资源预留。在部署RSIP的最常见场景中，位于私有领域内的接收方发起与位于公共领域内的发送方的通信会话。在本节中，我们将讨论在这种场景中RSIP体系结构和RSVP的交互。不太常见的
case of having senders within the private realm and receivers within the public realm is not discussed although concepts mentioned here may be applicable.
虽然这里提到的概念可能适用，但是在私有领域中有发送者，在公共领域中有接收者的情况没有讨论。
With senders in the public realm, RSVP PATH messages flow downstream from sender to receiver, inbound with respect to the RSIP gateway, while RSVP RESV messages flow in the opposite direction. Since RSIP uses tunneling between the RSIP host and gateway within the private realm, how the RSVP messages are handled within the RSIP tunnel depends on situations elaborated in [RFC2746].
当发送方处于公共领域时，RSVP PATH消息从发送方流向接收方，相对于RSIP网关流入，而RSVP RESV消息流向相反的方向。由于RSIP在专用领域内使用RSIP主机和网关之间的隧道，因此如何在RSIP隧道内处理RSVP消息取决于[RFC2746]中阐述的情况。
Following the terminology of [RFC2476], if Type 1 tunnels exist between the RSIP host and gateway, all intermediate nodes inclusive of the RSIP gateway will be treated as a non-RSVP aware cloud without QoS reserved on these nodes. The tunnel will be viewed as a single (logical) link on the path between the source and destination. End-to-end RSVP messages will be forwarded through the tunnel encapsulated in the same way as normal IP packets. We see this as the most common and applicable deployment scenario.
按照[RFC2476]的术语，如果RSIP主机和网关之间存在类型1隧道，则包括RSIP网关在内的所有中间节点将被视为不支持RSVP的云，这些节点上不保留QoS。隧道将被视为源和目标之间路径上的单个（逻辑）链路。端到端RSVP消息将通过以与普通IP数据包相同的方式封装的隧道进行转发。我们认为这是最常见和最适用的部署场景。
However, should Type 2 or 3 tunnels be deployed between the tunneling endpoints , end-to-end RSVP session has to be statically mapped (Type 2) or dynamically mapped (Type 3) into the tunnel sessions. While the end-to-end RSVP messages will be forwarded through the tunnel encapsulated in the same way as normal IP packets, a tunnel session is established between the tunnel endpoints to ensure QoS reservation within the tunnel for the end-to-end session. Data traffic needing special QoS assurance will be encapsulated in a UDP/IP header while normal traffic will be encapsulated using the normal IP-IP encapsulation. In the type 2 deployment scenario where all data traffic flowing to the RSIP host receiver are given QoS treatment, UDP/IP encapsulation will be rendered in the RSIP gateway for all data flows. The tunnel between the RSIP host and gateway could be seen as a "hard pipe". Traffic exceeding the QoS guarantee of the "hard pipe" would fall back to the best effort IP-IP tunneling.
但是，如果在隧道端点之间部署类型2或3隧道，则端到端RSVP会话必须静态映射（类型2）或动态映射（类型3）到隧道会话中。虽然端到端RSVP消息将通过以与普通IP数据包相同的方式封装的隧道转发，但在隧道端点之间建立隧道会话，以确保隧道内为端到端会话保留QoS。需要特殊QoS保证的数据流量将封装在UDP/IP报头中，而正常流量将使用正常IP-IP封装进行封装。在类型2部署场景中，对流向RSIP主机接收器的所有数据流量进行QoS处理，所有数据流的UDP/IP封装将在RSIP网关中呈现。RSIP主机和网关之间的隧道可视为“硬管道”。超过“硬管道”QoS保证的流量将退回到尽力而为的IP-IP隧道。
In the type 2 deployment scenario where data traffic could be selectively channeled into the UDP/IP or normal IP-IP tunnel, or for type 3 deployment where end-to-end sessions could be dynamically mapped into tunnel sessions, integration with the RSIP model could be complicated and tricky. (Note that these are the cases where the tunnel link could be seen as a expandable soft pipe.) Two main issues are worth considering.
在类型2部署场景中，数据流量可以选择性地引导到UDP/IP或普通IP-IP隧道，或者对于类型3部署，端到端会话可以动态映射到隧道会话，与RSIP模型的集成可能会很复杂和棘手。（注意，在这些情况下，隧道连接可被视为可膨胀软管。）两个主要问题值得考虑。
- For RSIP gateway implementations that does encapsulation of the incoming stream before passing to the IP layer for forwarding, the RSVP daemon has to be explicitly signaled upon reception of incoming RSVP PATH messages. The RSIP implementation has to
- 对于在传递到IP层进行转发之前对传入流进行封装的RSIP网关实现，必须在接收到传入RSVP PATH消息时显式通知RSVP守护进程。RSIP实现必须
recognize RSVP PATH messages and pass them to the RSVP daemon instead of doing the default tunneling. Handling of other RSVP messages would be as described in [RFC2746].
识别RSVP路径消息并将其传递给RSVP守护进程，而不是执行默认的隧道。其他RSVP消息的处理如[RFC2746]所述。
- RSIP enables an RSIP host to have a temporary presence at the RSIP gateway by assuming one of the RSIP gateway's global interfaces. As a result, the RSVP PATH messages would be addressed to the RSIP gateway. Also, the RSVP SESSION object within an incoming RSVP PATH would carry the global destination address, destination port (and protocol) tuples that were leased by the RSIP gateway to the RSIP host. Hence the realm unaware RSVP daemon running on the RSIP gateway has to be presented with a translated version of the RSVP messages. Other approaches are possible, for example making the RSVP daemon realm aware.
- RSIP通过假定RSIP网关的一个全局接口，使RSIP主机能够在RSIP网关上临时存在。因此，RSVP路径消息将被发送到RSIP网关。此外，传入RSVP路径中的RSVP会话对象将携带全局目标地址、目标端口（和协议）元组，这些元组由RSIP网关租给RSIP主机。因此，在RSIP网关上运行的领域不知道的RSVP守护进程必须提供RSVP消息的翻译版本。其他方法也是可能的，例如使RSVP守护程序领域感知。
A simple mechanism would be to have the RSIP module handle the necessary RSVP message translation. For an incoming RSVP signalling flow, the RSIP module does a packet translation of the IP header and RSVP SESSION object before handling the packet over to RSVP. The global address leased to the host is translated to the true private address of the host. (Note that this mechanism works with both RSA-IP and RSAP-IP.) The RSIP module also has to do an opposite translation from private to global parameter (plus tunneling) for end-to-end PATH messages generated by the RSVP daemon towards the RSIP host receiver. A translation on the SESSION object also has to be done for RSVP outbound control messages. Once the RSVP daemon gets the message, it maps them to an appropriate tunnel sessions.
一个简单的机制是让RSIP模块处理必要的RSVP消息翻译。对于传入的RSVP信令流，RSIP模块在将数据包转移到RSVP之前对IP报头和RSVP会话对象进行数据包转换。租用给主机的全局地址被转换为主机的真实私有地址。（请注意，此机制同时适用于RSA-IP和RSAP-IP。）RSIP模块还必须对RSVP守护程序生成的端到端路径消息向RSIP主机接收器进行从私有参数到全局参数的反向转换（加上隧道）。还必须对RSVP出站控制消息进行会话对象的转换。一旦RSVP守护进程获得消息，它就会将它们映射到适当的隧道会话。
Encapsulation of the inbound data traffic needing QoS treatment would be done using UDP-IP encapsulation designated by the tunnel session. For this reason, the RSIP module has to be aware of the UDP-IP encapsulation to use for a particular end-to-end session. Classification and scheduling of the QoS guaranteed end-to-end flow on the output interface of the RSIP gateway would be based on the UDP/IP encapsulation. Mapping between the tunnel session and end-to-end session could continue to use the mechanisms proposed in [RFC2746]. Although [RFC2746] proposes a number of approaches for this purpose, we propose using the SESSION_ASSOC object introduced because of its simplicity.
需要QoS处理的入站数据通信的封装将使用隧道会话指定的UDP-IP封装完成。因此，RSIP模块必须知道用于特定端到端会话的UDP-IP封装。RSIP网关输出接口上QoS保证的端到端流的分类和调度将基于UDP/IP封装。隧道会话和端到端会话之间的映射可以继续使用[RFC2746]中提出的机制。尽管[RFC2746]为此提出了许多方法，但我们建议使用由于简单而引入的SESSION_ASSOC对象。
The amount of specific RSIP/multicast support that is required in RSIP hosts and gateways is dependent on the scope of multicasting in the RSIP-enabled network, and the roles that the RSIP hosts will play. In this section, we discuss RSIP and multicast interactions in a number of scenarios.
RSIP主机和网关中需要的特定RSIP/多播支持的数量取决于启用RSIP的网络中的多播范围以及RSIP主机将扮演的角色。在本节中，我们将在许多场景中讨论RSIP和多播交互。
Note that in all cases, the RSIP gateway MUST be multicast aware because it is on an administrative boundary between two domains that will not be sharing their all of their routing information. The RSIP gateway MUST NOT allow private IP addresses to be propagated on the public network as part of any multicast message or as part of a routing table.
请注意，在所有情况下，RSIP网关都必须支持多播，因为它位于两个域之间的管理边界上，不会共享它们的所有路由信息。RSIP网关不得允许私有IP地址作为任何多播消息的一部分或路由表的一部分在公共网络上传播。
5.4.1. Receiving-Only Private Hosts, No Multicast Routing on Private Network
5.4.1. 只接收专用主机，在专用网络上没有多播路由
In this scenario, private hosts will not source multicast traffic, but they may join multicast groups as recipients. In the private network, there are no multicast-aware routers, except for the RSIP gateway.
在这种情况下，专用主机不会提供多播流量，但它们可以作为收件人加入多播组。在专用网络中，除了RSIP网关外，没有支持多播的路由器。
Private hosts may join and leave multicast groups by sending the appropriate IGMP messages to an RSIP gateway (there may be IGMP proxy routers between RSIP hosts and gateways). The RSIP gateway will coalesce these requests and perform the appropriate actions, whether they be to perform a multicast WAN routing protocol, such as PIM, or to proxy the IGMP messages to a WAN multicast router. In other words, if one or more private hosts request to join a multicast group, the RSIP gateway MUST join in their stead, using one of its own public IP addresses.
专用主机可以通过向RSIP网关发送适当的IGMP消息来加入和离开多播组（RSIP主机和网关之间可能有IGMP代理路由器）。RSIP网关将合并这些请求并执行适当的操作，无论是执行多播WAN路由协议（如PIM），还是将IGMP消息代理到WAN多播路由器。换句话说，如果一个或多个私有主机请求加入一个多播组，RSIP网关必须使用自己的一个公共IP地址代替它们加入。
Note that private hosts do not need to acquire demultiplexing fields and use RSIP to receive multicasts. They may receive all multicasts using their private addresses, and by private address is how the RSIP gateway will keep track of their group membership.
请注意，专用主机不需要获取解复用字段并使用RSIP来接收多播。他们可以使用自己的专用地址接收所有多播，而通过专用地址，RSIP网关将跟踪他们的组成员身份。
5.4.2. Sending and Receiving Private Hosts, No Multicast Routing on Private Network
5.4.2. 发送和接收专用主机，专用网络上无多播路由
This scenarios operates identically to the previous scenario, except that when a private host becomes a multicast source, it MUST use RSIP and acquire a public IP address (note that it will still receive on its private address). A private host sending a multicast will use a public source address and tunnel the packets to the RSIP gateway. The RSIP gateway will then perform typical RSIP functionality, and route the resulting packets onto the public network, as well as back to the private network, if there are any listeners on the private network.
此场景的操作与前一场景相同，只是当专用主机成为多播源时，它必须使用RSIP并获取公共IP地址（请注意，它仍将在其专用地址上接收）。发送多播的私有主机将使用公共源地址，并通过隧道将数据包传输到RSIP网关。然后，RSIP网关将执行典型的RSIP功能，并将产生的数据包路由到公共网络，以及返回到专用网络（如果专用网络上有任何侦听器）。
If there is more than one sender on the private network, then, to the public network it will seem as if all of these senders share the same IP address. If a downstream multicasting protocol identifies sources
如果在专用网络上有多个发送者，那么在公用网络上，所有这些发送者似乎共享相同的IP地址。如果下行多播协议识别源
based on IP address alone and not port numbers, then it is possible that these protocols will not be able to distinguish between the senders.
仅基于IP地址而非端口号，则这些协议可能无法区分发送方。
In this section we document the know complications that RSIP may cause. While none of these complications should be considered "show stoppers" for the majority of applications, they may cause unexpected or undefined behavior. Where it is appropriate, we discuss potential remedial procedures that may reduce or eliminate the deleterious impact of a complication.
在本节中，我们将记录RSIP可能导致的已知并发症。虽然在大多数应用中，这些并发症都不应被视为“显示障碍”，但它们可能会导致意外或未定义的行为。在适当的情况下，我们讨论可能减少或消除并发症有害影响的潜在补救程序。
When TCP disconnects a socket, it enters the TCP TIME_WAIT state for a period of time. While it is in this state it will refuse to accept new connections using the same socket (i.e., the same source address/port and destination address/port). Consider the case in which an RSIP host (using RSAP-IP) is leased an address/port tuple and uses this tuple to contact a public address/port tuple. Suppose that the host terminates the session with the public tuple and immediately returns its leased tuple to the RSIP gateway. If the RSIP gateway immediately allocates this tuple to another RSIP host (or to the same host), and this second host uses the tuple to contact the same public tuple while the socket is still in the TIME_WAIT phase, then the host's connection may be rejected by the public host.
当TCP断开套接字连接时，它会在一段时间内进入TCP TIME_WAIT状态。当它处于这种状态时，它将拒绝接受使用相同套接字（即，相同的源地址/端口和目标地址/端口）的新连接。考虑RSIP主机（使用RSAP-IP）租用地址/端口元组的情况，并使用这个元组与公共地址/端口元组联系。假设主机使用公共元组终止会话，并立即将其租用的元组返回给RSIP网关。如果RSIP网关立即将该元组分配给另一台RSIP主机（或同一台主机），并且第二台主机在套接字仍处于等待阶段时使用该元组联系同一公共元组，则该主机的连接可能会被公共主机拒绝。
In order to mitigate this problem, it is recommended that RSIP gateways hold recently deallocated tuples for at least two minutes, which is the greatest duration of TIME_WAIT that is commonly implemented. In situations where port space is scarce, the RSIP gateway MAY choose to allocate ports in a FIFO fashion from the pool of recently deallocated ports.
为了缓解此问题，建议RSIP网关将最近释放的元组保持至少两分钟，这是通常实现的最长等待时间。在端口空间不足的情况下，RSIP网关可以选择从最近释放的端口池中以FIFO方式分配端口。
Like NAT, RSIP gateways providing RSAP-IP must process ICMP responses from the public network in order to determine the RSIP host (if any) that is the proper recipient. We distinguish between ICMP error packets, which are transmitted in response to an error with an associated IP packet, and ICMP response packets, which are transmitted in response to an ICMP request packet.
与NAT一样，提供RSAP-IP的RSIP网关必须处理来自公共网络的ICMP响应，以确定RSIP主机（如果有）是正确的接收方。我们区分了ICMP错误数据包和ICMP响应数据包，ICMP错误数据包是响应相关IP数据包的错误而传输的，ICMP响应数据包是响应ICMP请求数据包而传输的。
ICMP request packets originating on the private network will typically consist of echo request, timestamp request and address mask request. These packets and their responses can be identified by the tuple of source IP address, ICMP identifier, ICMP sequence number,
源自专用网络的ICMP请求数据包通常包括回送请求、时间戳请求和地址掩码请求。这些数据包及其响应可以通过源IP地址、ICMP标识符、ICMP序列号、，
and destination IP address. An RSIP host sending an ICMP request packet tunnels it to the RSIP gateway, just as it does TCP and UDP packets. The RSIP gateway must use this tuple to map incoming ICMP responses to the private address of the appropriate RSIP host. Once it has done so, it will tunnel the ICMP response to the host. Note that it is possible for two RSIP hosts to use the same values for the tuples listed above, and thus create an ambiguity. However, this occurrence is likely to be quite rare, and is not addressed further in this document.
和目标IP地址。发送ICMP请求数据包的RSIP主机通过隧道将其传输到RSIP网关，就像它传输TCP和UDP数据包一样。RSIP网关必须使用此元组将传入ICMP响应映射到相应RSIP主机的专用地址。一旦完成此操作，它将通过隧道将ICMP响应传送到主机。请注意，两个RSIP主机可能会对上面列出的元组使用相同的值，从而产生歧义。然而，这种情况可能非常罕见，本文件中没有进一步说明。
Incoming ICMP error response messages can be forwarded to the appropriate RSIP host by examining the IP header and port numbers embedded within the ICMP packet. If these fields are not present, the packet should be silently discarded.
通过检查嵌入在ICMP数据包中的IP头和端口号，可以将传入的ICMP错误响应消息转发到相应的RSIP主机。如果这些字段不存在，数据包应该被悄悄地丢弃。
Occasionally, an RSIP host will have to send an ICMP response (e.g., port unreachable). These responses are tunneled to the RSIP gateway, as is done for TCP and UDP packets. All ICMP requests (e.g., echo request) arriving at the RSIP gateway MUST be processed by the RSIP gateway and MUST NOT be forwarded to an RSIP host.
有时，RSIP主机必须发送ICMP响应（例如，端口不可访问）。与TCP和UDP数据包一样，这些响应通过隧道传输到RSIP网关。到达RSIP网关的所有ICMP请求（如回送请求）必须由RSIP网关处理，不得转发到RSIP主机。
If two or more RSIP hosts on the same private network transmit outbound packets that get fragmented to the same public gateway, the public gateway may experience a reassembly ambiguity if the IP header ID fields of these packets are identical.
如果同一专用网络上的两个或多个RSIP主机将碎片化的出站数据包发送到同一公共网关，则如果这些数据包的IP报头ID字段相同，则公共网关可能会经历重组模糊。
For TCP packets, a reasonably small MTU can be set so that fragmentation is guaranteed not to happen, or the likelihood or fragmentation is extremely small. If path MTU discovery works properly, the problem is mitigated. For UDP, applications control the size of packets, and the RSIP host stack may have to fragment UDP packets that exceed the local MTU. These packets may be fragmented by an intermediate router as well.
对于TCP数据包，可以设置一个相当小的MTU，以确保不会发生碎片，或者碎片的可能性非常小。如果路径MTU发现工作正常，则问题会得到缓解。对于UDP，应用程序控制数据包的大小，RSIP主机堆栈可能必须对超过本地MTU的UDP数据包进行分段。这些包也可以由中间路由器分割。
The only completely robust solution to this problem is to assign all RSIP hosts that are sharing the same public IP address disjoint blocks of numbers to use in their IP identification fields. However, whether this modification is worth the effort of implementing is currently unknown.
这个问题唯一完全可靠的解决方案是分配所有共享相同公共IP地址不相交数字块的RSIP主机，以在其IP标识字段中使用。然而，目前还不清楚这一修改是否值得实施。
RSAP-IP hosts are limited by the same constraints as NAT with respect to hosting servers that use a well-known port. Since destination port numbers are used as routing information to uniquely identify an RSAP-IP host, typically no two RSAP-IP hosts sharing the same public
RSAP-IP主机受到与NAT相同的限制，这些限制与使用知名端口的主机服务器有关。由于目标端口号用作唯一标识RSAP-IP主机的路由信息，因此通常不会有两个RSAP-IP主机共享相同的公共端口号
IP address can simultaneously operate publically-available gateways on the same port. For protocols that operate on well-known ports, this implies that only one public gateway per RSAP-IP IP address / port tuple is used simultaneously. However, more than one gateway per RSAP-IP IP address / port tuple may be used simultaneously if and only if there is a demultiplexing field within the payload of all packets that will uniquely determine the identity of the RSAP-IP host, and this field is known by the RSIP gateway.
IP地址可以同时操作同一端口上的公共可用网关。对于在已知端口上运行的协议，这意味着每个RSAP-IP地址/端口元组只能同时使用一个公共网关。然而，每个RSAP-IP地址/端口元组可以同时使用多个网关，当且仅当所有分组的有效载荷中存在一个解复用字段，该字段将唯一地确定RSAP-IP主机的标识，并且该字段由RSIP网关知道时。
In order for an RSAP-IP host to operate a publically-available gateway, the host must inform the RSIP gateway that it wishes to receive all traffic destined to that port number, per its IP address. Such a request MUST be denied if the port in question is already in use by another host.
为了让RSAP-IP主机操作公共可用的网关，主机必须通知RSIP网关，它希望按照其IP地址接收发送到该端口号的所有流量。如果该端口已被其他主机使用，则必须拒绝该请求。
In general, contacting devices behind an RSIP gateway may be difficult. A potential solution to the general problem would be an architecture that allows an application on an RSIP host to register a public IP address / port pair in a public database. Simultaneously, the RSIP gateway would initiate a mapping from this address / port tuple to the RSIP host. A peer application would then be required to contact the database to determine the proper address / port at which to contact the RSIP host's application.
一般来说，联系RSIP网关后面的设备可能很困难。一般问题的一个潜在解决方案是一种允许RSIP主机上的应用程序在公共数据库中注册公共IP地址/端口对的体系结构。同时，RSIP网关将启动从该地址/端口元组到RSIP主机的映射。然后，需要一个对等应用程序与数据库联系，以确定与RSIP主机的应用程序联系的正确地址/端口。
In general, an RSIP host must know, for a particular IP address, whether it should address the packet for local delivery on the private network, or if it has to use an RSIP interface to tunnel to an RSIP gateway (assuming that it has such an interface available).
一般来说，RSIP主机必须知道，对于特定IP地址，它是否应该为专用网络上的本地传递寻址数据包，或者它是否必须使用RSIP接口来隧道到RSIP网关（假设它有这样的接口可用）。
If the RSIP hosts are all on a single subnet, one hop from an RSIP gateway, then examination of the local network and subnet mask will provide the appropriate information. However, this is not always the case.
如果RSIP主机都在一个子网中，从RSIP网关跳一跳，则本地网络和子网掩码的检查将提供适当的信息。然而，情况并非总是如此。
An alternative that will work in general for statically addressed private networks is to store a list of the network and subnet masks of every private subnet at the RSIP gateway. RSIP hosts may query the gateway with a particular target IP address, or for the entire list.
对于静态寻址的专用网络来说，一种通用的替代方法是在RSIP网关上存储每个专用子网的网络和子网掩码列表。RSIP主机可以使用特定的目标IP地址查询网关，或者查询整个列表。
If the subnets on the local side of the network are changing more rapidly than the lifetime of a typical RSIP session, the RSIP host may have to query the location of every destination that it tries to communicate with.
如果网络本地侧的子网的变化速度比典型RSIP会话的生存期更快，则RSIP主机可能必须查询其尝试与之通信的每个目的地的位置。
If an RSIP host transmits a packet addressed to a public host without using RSIP, then the RSIP gateway will apply NAT to the packet (if it supports NAT) or it may discard the packet and respond with and appropriate ICMP message.
如果RSIP主机在不使用RSIP的情况下发送一个发往公共主机的数据包，则RSIP网关将对该数据包应用NAT（如果它支持NAT），或者它可以丢弃该数据包，并使用适当的ICMP消息进行响应。
A robust solution to this problem has proven difficult to develop. Currently, it is not known how severe this problem is. It is likely that it will be more severe on networks where the routing information is changing rapidly that on networks with relatively static routes.
事实证明，很难开发出解决此问题的可靠解决方案。目前还不知道这个问题有多严重。在路由信息变化迅速的网络上，这种情况可能比在路由相对静态的网络上更严重。
An RSIP host MAY free resources that it has determined it no longer requires. For example, on an RSAP-IP subnet with a limited number of public IP addresses, port numbers may become scarce. Thus, if RSIP hosts are able to dynamically deallocate ports that they no longer need, more hosts can be supported.
RSIP主机可以释放其确定不再需要的资源。例如，在公共IP地址数量有限的RSAP-IP子网上，端口号可能会变得稀少。因此，如果RSIP主机能够动态取消分配不再需要的端口，则可以支持更多主机。
However, this functionality may require significant modifications to a vanilla TCP/IP stack in order to implement properly. The RSIP host must be able to determine which TCP or UDP sessions are using RSIP resources. If those resources are unused for a period of time, then the RSIP host may deallocate them. When an open socket's resources are deallocated, it will cause some associated applications to fail. An analogous case would be TCP and UDP sessions that must terminate when an interface that they are using loses connectivity.
但是，为了正确实现此功能，可能需要对普通TCP/IP堆栈进行重大修改。RSIP主机必须能够确定哪些TCP或UDP会话正在使用RSIP资源。如果这些资源在一段时间内未使用，则RSIP主机可能会取消分配它们。当释放开放套接字的资源时，它将导致一些相关应用程序失败。类似的情况是TCP和UDP会话，当它们使用的接口失去连接时，它们必须终止。
On the other hand, this issue can be considered a resource allocation problem. It is not recommended that a large number (hundreds) of hosts share the same IP address, for performance purposes. Even if, say, 100 hosts each are allocated 100 ports, the total number of ports in use by RSIP would be still less than one-sixth the total port space for an IP address. If more hosts or more ports are needed, more IP addresses should be used. Thus, it is reasonable, that in many cases, RSIP hosts will not have to deallocate ports for the lifetime of their activity.
另一方面，这个问题可以看作是一个资源分配问题。出于性能考虑，不建议大量（数百）主机共享同一IP地址。即使（比如）每个100台主机分配了100个端口，RSIP使用的端口总数仍不到IP地址总端口空间的六分之一。如果需要更多主机或端口，则应使用更多IP地址。因此，在许多情况下，RSIP主机在其活动的生命周期内不必取消分配端口是合理的。
Since RSIP demultiplexing fields are leased to hosts, an appropriately chosen lease time can alleviate some port space scarcity issues.
由于RSIP解复用字段租给主机，因此适当选择的租用时间可以缓解一些端口空间不足的问题。
Multi-party applications are defined to have at least one of the following characteristics:
多方应用程序被定义为至少具有以下特征之一：
- A third party sets up sessions or connections between two hosts.
- 第三方在两台主机之间建立会话或连接。
- Computation is distributed over a number of hosts such that the individual hosts may communicate with each other directly.
- 计算分布在多个主机上，使得各个主机可以直接彼此通信。
RSIP has a fundamental problem with multi-party applications. If some of the parties are within the private addressing realm and others are within the public addressing realm, an RSIP host may not know when to use private addresses versus public addresses. In particular, IP addresses may be passed from party to party under the assumption that they are global endpoint identifiers. This may cause multi-party applications to fail.
RSIP在多方应用程序中存在一个基本问题。如果某些参与方在私有寻址域内，而其他参与方在公共寻址域内，则RSIP主机可能不知道何时使用私有地址而不是公共地址。特别地，IP地址可以在假设它们是全局端点标识符的情况下从一方传递到另一方。这可能会导致多方应用程序失败。
There is currently no known solution to this general problem. Remedial measures are available, such as forcing all RSIP hosts to always use public IP addresses, even when communicating only on to other RSIP hosts. However, this can result in a socket set up between two RSIP hosts having the same source and destination IP addresses, which most TCP/IP stacks will consider as intra-host communication.
目前还没有已知的解决这个普遍问题的方法。可以采取补救措施，例如强制所有RSIP主机始终使用公共IP地址，即使仅在与其他RSIP主机通信时也是如此。然而，这可能导致在两个具有相同源和目的IP地址的RSIP主机之间建立一个套接字，其中大多数TCP/IP栈将被视为主机间通信。
The scalability of RSIP is currently not well understood. While it is conceivable that a single RSIP gateway could support hundreds of RSIP hosts, scalability depends on the specific deployment scenario and applications used. In particular, three major constraints on scalability will be (1) RSIP gateway processing requirements, (2) RSIP gateway memory requirements, and (3) RSIP negotiation protocol traffic requirements. It is advisable that all RSIP negotiation protocol implementations attempt to minimize these requirements.
RSIP的可伸缩性目前还没有得到很好的理解。虽然单个RSIP网关可以支持数百台RSIP主机，但可伸缩性取决于特定的部署场景和使用的应用程序。特别是，可伸缩性的三个主要限制将是（1）RSIP网关处理需求，（2）RSIP网关内存需求，以及（3）RSIP协商协议流量需求。建议所有RSIP协商协议实现都尽量减少这些要求。
RSIP, in and of itself, does not provide security. It may provide the illusion of security or privacy by hiding a private address space, but security can only be ensured by the proper use of security protocols and cryptographic techniques.
RSIP本身并不提供安全性。它可能通过隐藏私人地址空间来提供安全或隐私的假象，但安全性只能通过正确使用安全协议和密码技术来确保。
The authors would like to thank Pyda Srisuresh, Dan Nessett, Gary Jaszewski, Ajay Bakre, Cyndi Jung, and Rick Cobb for their input. The IETF NAT working group as a whole has been extremely helpful in the ongoing development of RSIP.
作者要感谢Pyda Srisuresh、Dan Nessett、Gary Jaszewski、Ajay Bakre、Cyndi Jung和Rick Cobb的投入。IETF NAT工作组作为一个整体，在RSIP的持续开发中发挥了极大的作用。
[DHCP-DNS] Stapp, M. and Y. Rekhter, "Interaction Between DHCP and DNS", Work in Progress.
[DHCP-DNS]Stapp，M.和Y.Rekhter，“DHCP和DNS之间的交互”，正在进行中。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3104] Montenegro, G. and M. Borella, "RSIP Support for End-to-End IPSEC", RFC 3104, October 2001.
[RFC3104]黑山G.和M.Borella，“RSIP对端到端IPSEC的支持”，RFC 3104，2001年10月。
[RFC3103] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RFC3103]Borella，M.，Grabelsky，D.，Lo，J.和K.Taniguchi，“领域特定IP：协议规范”，RFC 3103，2001年10月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746]Terzis，A.，Krawczyk，J.，Wroclawski，J.和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.J.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP)", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源保留协议（RSVP）”，RFC 22052997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with SLP", RFC 3105, October 2001.
[RFC3105]Kempf，J.和G.黑山，“使用SLP查找RSIP服务器”，RFC 3105，2001年10月。
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
伊利诺伊州Rolling Meadows高尔夫路3800号Michael Borella CommWorks 60008
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
电话：（847）262-3083电子邮件：迈克_borella@commworks.com
Jeffrey Lo Candlestick Networks, Inc 70 Las Colinas Lane, San Jose, CA 95119
Jeffrey Lo Candlestick Networks，Inc.加利福尼亚州圣何塞市Las Colinas巷70号，邮编95119
Phone: (408) 284 4132 EMail: yidarlo@yahoo.com
电话：（408）2844132电子邮件：yidarlo@yahoo.com
David Grabelsky CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
伊利诺伊州Rolling Meadows高尔夫路3800号David Grabelsky CommWorks 60008
Phone: (847) 222-2483 EMail: david_grabelsky@commworks.com
电话：（847）222-2483电子邮件：david_grabelsky@commworks.com
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
加布里埃尔E.黑山太阳微系统实验室，欧洲29号，法国墨西哥chemin du Vieux Chene 38240
Phone: +33 476 18 80 45
EMail: gab@sun.com
Phone: +33 476 18 80 45
EMail: gab@sun.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。