Network Working Group J. Hagino
Request for Comments: 3142 K. Yamamoto
Category: Informational IIJ Research Laboratory
June 2001
Network Working Group J. Hagino
Request for Comments: 3142 K. Yamamoto
Category: Informational IIJ Research Laboratory
June 2001
An IPv6-to-IPv4 Transport Relay Translator
IPv6到IPv4传输中继转换器
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The document describes an IPv6-to-IPv4 transport relay translator (TRT). It enables IPv6-only hosts to exchange {TCP,UDP} traffic with IPv4-only hosts. A TRT system, which locates in the middle, translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa.
本文档介绍了IPv6到IPv4传输中继转换器（TRT）。它使仅限IPv6的主机能够与仅限IPv4的主机交换{TCP，UDP}流量。位于中间的TRT系统将{TCP，UDP }/IPv6翻译为{TCP，UDP }/IPv4，反之亦然。
The memo talks about how to implement a TRT system using existing technologies. It does not define any new protocols.
备忘录讨论了如何使用现有技术实现TRT系统。它没有定义任何新的协议。
When you deploy an IPv6-only network, you still want to gain access to IPv4-only network resources outside, such as IPv4-only web servers. To solve this problem, many IPv6-to-IPv4 translation technologies are proposed, mainly in the IETF ngtrans working group. The memo describes a translator based on the transport relay technique to solve the same problem.
部署仅限IPv6的网络时，仍希望访问外部仅限IPv4的网络资源，例如仅限IPv4的web服务器。为了解决这个问题，许多IPv6到IPv4的转换技术被提出，主要是在IETF ngtrans工作组中。备忘录描述了一种基于传输中继技术的翻译器，以解决相同的问题。
In this memo, we call this kind of translator "TRT" (transport relay translator). A TRT system locates between IPv6-only hosts and IPv4 hosts and translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, vice versa.
在本备忘录中，我们称这种翻译器为“TRT”（传输中继翻译器）。TRT系统位于仅IPv6主机和IPv4主机之间，并将{TCP，UDP}/IPv6转换为{TCP，UDP}/IPv4，反之亦然。
Advantages of TRT are as follows:
TRT的优点如下：
o TRT is designed to require no extra modification on IPv6-only initiating hosts, nor that on IPv4-only destination hosts. Some other translation mechanisms need extra modifications on IPv6-only initiating hosts, limiting possibility of deployment.
o TRT的设计目的是不需要对仅IPv6启动主机进行额外修改，也不需要对仅IPv4目标主机进行额外修改。其他一些转换机制需要在仅IPv6启动主机上进行额外修改，从而限制了部署的可能性。
o The IPv6-to-IPv4 header converters have to take care of path MTU and fragmentation issues. However, TRT is free from this problem.
o IPv6到IPv4报头转换器必须处理路径MTU和碎片问题。然而，TRT没有这个问题。
Disadvantages of TRT are as follows:
TRT的缺点如下：
o TRT supports bidirectional traffic only. The IPv6-to-IPv4 header converters may be able to support other cases, such as unidirectional multicast datagrams.
o TRT仅支持双向通信。IPv6到IPv4报头转换器可能能够支持其他情况，例如单向多播数据报。
o TRT needs a stateful TRT system between the communicating peers, just like NAT systems. While it is possible to place multiple TRT systems in a site (see Appendix A), a transport layer connection goes through particular, a single TRT system. The TRT system thus can be considered a single point of failure, again like NAT systems. Some other mechanisms, such as SIIT [Nordmark, 2000], use stateless translator systems which can avoid a single point of failure.
o 与NAT系统一样，TRT需要通信对等方之间的有状态TRT系统。虽然可以在一个站点中放置多个TRT系统（见附录a），但传输层连接通过特定的单个TRT系统。因此，TRT系统可被视为单点故障，与NAT系统一样。其他一些机制，如SIIT[Nordmark，2000]，使用无状态翻译系统，可以避免单点故障。
o Special code is necessary to relay NAT-unfriendly protocols. Some of NAT-unfriendly protocols, including IPsec, cannot be used across TRT system.
o 中继NAT不友好协议需要特殊代码。一些NAT不友好的协议，包括IPsec，不能跨TRT系统使用。
This memo assumes that traffic is initiated by an IPv6-only host destined to an IPv4-only host. The memo can be extended to handle opposite direction, if an appropriate address mapping mechanism is introduced.
此备忘录假定流量是由发送到仅IPv4主机的仅IPv6主机发起的。如果引入了适当的地址映射机制，则可以扩展备忘录以处理相反的方向。
To help understanding of the proposal in the next section, here we describe the transport relay in general. The transport relay technique itself is not new, as it has been used in many of firewall-related products.
为了帮助理解下一节中的提案，这里我们将对传输中继进行总体描述。传输中继技术本身并不是新技术，因为它已经在许多防火墙相关产品中使用。
TCP relay systems have been used in firewall-related products. These products are designed to achieve the following goals: (1) disallow forwarding of IP packets across a system, and (2) allow {TCP,UDP} traffic to go through the system indirectly. For example, consider a network constructed like the following diagram. "TCP relay system" in the diagram does not forward IP packet across the inner network to the outer network, vice versa. It only relays TCP traffic on a specific port, from the inner network to the outer network, vice versa. (Note: The diagram has only two subnets, one for inner and one for outer. Actually both sides can be more complex, and there can be as many subnets and routers as you wish.)
TCP中继系统已用于防火墙相关产品。这些产品旨在实现以下目标：（1）不允许跨系统转发IP数据包，（2）允许{TCP，UDP}流量间接通过系统。例如，考虑像下面的图表那样构建的网络。图中的“TCP中继系统”不会将IP数据包通过内网转发到外网，反之亦然。它只在特定端口上中继TCP流量，从内部网络到外部网络，反之亦然。（注意：图中只有两个子网，一个用于内部，一个用于外部。实际上，两侧可能更复杂，并且可以有任意多的子网和路由器。）
destination host
|X
==+=======+== outer network
|Y
TCP relay system
|B
==+=======+== inner network
|A
initiating host
destination host
|X
==+=======+== outer network
|Y
TCP relay system
|B
==+=======+== inner network
|A
initiating host
When the initiating host (whose IP address is A) tries to make a TCP connection to the destination host (X), TCP packets are routed toward the TCP relay system based on routing decision. The TCP relay system receives and accepts the packets, even though the TCP relay system does not own the destination IP address (X). The TCP relay system pretends to having IP address X, and establishes TCP connection with the initiating host as X. The TCP relay system then makes a another TCP connection from Y to X, and relays traffic from A to X, and the other way around.
当发起主机（其IP地址为A）尝试与目标主机（X）建立TCP连接时，TCP数据包将根据路由决定路由到TCP中继系统。TCP中继系统接收并接受数据包，即使TCP中继系统不拥有目标IP地址（X）。TCP中继系统假装拥有IP地址X，并以X的形式与发起主机建立TCP连接。然后，TCP中继系统建立另一个从Y到X的TCP连接，并将流量从a中继到X，反之亦然。
Thus, two TCP connections are established in the picture: from A to B (as X), and from Y to X, like below:
因此，图中建立了两个TCP连接：从A到B（作为X）和从Y到X，如下所示：
TCP/IPv4: the initiating host (A) --> the TCP relay system (as X)
address on IPv4 header: A -> X
TCP/IPv4: the TCP relay system (Y) --> the destination host (X)
address on IPv4 header: Y -> X
TCP/IPv4: the initiating host (A) --> the TCP relay system (as X)
address on IPv4 header: A -> X
TCP/IPv4: the TCP relay system (Y) --> the destination host (X)
address on IPv4 header: Y -> X
The TCP relay system needs to capture some of TCP packets that is not destined to its address. The way to do it is implementation dependent and outside the scope of this memo.
TCP中继系统需要捕获一些并非发送到其地址的TCP数据包。方法取决于实施，不在本备忘录的范围内。
If you can recognize UDP inbound and outbound traffic pair in some way, UDP relay can be implemented in similar manner as TCP relay. An implementation can recognize UDP traffic pair like NAT systems does, by recording address/port pairs onto an table and managing table entries with timeouts.
如果您能够以某种方式识别UDP入站和出站流量对，则UDP中继可以以与TCP中继类似的方式实现。通过将地址/端口对记录到表中并管理带有超时的表条目，实现可以像NAT系统一样识别UDP流量对。
We propose a transport relay translator for IPv6-to-IPv4 protocol translation, TRT. In the following description, TRT for TCP is described. TRT for UDP can be implemented in similar manner.
我们提出了一种用于IPv6到IPv4协议转换的传输中继转换器TRT。在下面的描述中，描述了TCP的TRT。UDP的TRT可以以类似的方式实现。
For address mapping, we reserve an IPv6 prefix referred to by
C6::/64. C6::/64 should be a part of IPv6 unicast address space
For address mapping, we reserve an IPv6 prefix referred to by
C6::/64. C6::/64 should be a part of IPv6 unicast address space
assigned to the site. Routing information must be configured so that packets to C6::/64 are routed toward the TRT system. The following diagram shows the network configuration. The subnet marked as "dummy prefix" does not actually exist. Also, now we assume that the initiating host to be IPv6-only, and the destination host to be IPv4-only.
分配给该站点。必须配置路由信息，以便将发送至C6:：/64的数据包路由至TRT系统。下图显示了网络配置。标记为“伪前缀”的子网实际上不存在。此外，现在我们假设发起主机仅为IPv6，目标主机仅为IPv4。
destination host
|X4
==+=======+== outer network
|Y4
TRT system --- dummy prefix (C6::/64)
|B6
==+=======+== inner network
|A6
initiating host
destination host
|X4
==+=======+== outer network
|Y4
TRT system --- dummy prefix (C6::/64)
|B6
==+=======+== inner network
|A6
initiating host
When the initiating host (whose IPv6 address is A6) wishes to make a connection to the destination host (whose IPv4 address is X4), it needs to make an TCP/IPv6 connection toward C6::X4. For example, if C6::/64 equals to fec0:0:0:1::/64, and X4 equals to 10.1.1.1, the destination address to be used is fec0:0:0:1::10.1.1.1. The packet is routed toward the TRT system, and is captured by it. The TRT system accepts the TCP/IPv6 connection between A6 and C6::X4, and communicate with the initiating host, using TCP/IPv6. Then, the TRT system investigates the lowermost 32bit of the destination address (IPv6 address C6::X4) to get the real IPv4 destination (IPv4 address X4). It makes an TCP/IPv4 connection from Y4 to X4, and forward traffic across the two TCP connections.
当发起主机（其IPv6地址为A6）希望与目标主机（其IPv4地址为X4）建立连接时，它需要与C6:：X4建立TCP/IPv6连接。例如，如果C6:：/64等于fec0:0:0:1:：/64，而X4等于10.1.1.1，则要使用的目标地址是fec0:0:0:1:：10.1.1.1。数据包被路由到TRT系统，并被它捕获。TRT系统接受A6和C6:：X4之间的TCP/IPv6连接，并使用TCP/IPv6与发起主机通信。然后，TRT系统调查目标地址（IPv6地址C6:：X4）的最低32位，以获得真正的IPv4目标（IPv4地址X4）。它建立了从Y4到X4的TCP/IPv4连接，并通过两个TCP连接转发流量。
There are two TCP connections. One is TCP/IPv6 and another is TCP/IPv4, in the picture: from A6 to B6 (as C6::X4), and Y4 to X4, like below:
有两个TCP连接。一个是TCP/IPv6，另一个是TCP/IPv4，如图所示：从A6到B6（如C6:：X4），从Y4到X4，如下所示：
TCP/IPv6: the initiating host (A6) --> the TRT system (as C6::X4)
address on IPv6 header: A6 -> C6::X4
TCP/IPv4: the TRT system (Y4) --> the destination host (X4)
address on IPv4 header: Y4 -> X4
TCP/IPv6: the initiating host (A6) --> the TRT system (as C6::X4)
address on IPv6 header: A6 -> C6::X4
TCP/IPv4: the TRT system (Y4) --> the destination host (X4)
address on IPv4 header: Y4 -> X4
As seen in the previous section, an initiating host must use a special form of IPv6 address to connect to an IPv4 destination host. The special form can be resolved from a hostname by static address mapping table on the initiating host (like /etc/hosts in UNIX), special DNS server implementation, or modified DNS resolver implementation on initiating host.
如前一节所示，发起主机必须使用特殊形式的IPv6地址来连接到IPv4目标主机。可以通过启动主机上的静态地址映射表（如UNIX中的/etc/hosts）、特殊DNS服务器实现或启动主机上修改的DNS解析器实现从主机名解析特殊形式。
TRT for UDP must take care of path MTU issues on the UDP/IPv6 side. The good thing is that, as we do not relay IP layer packets between IPv4 and IPv6, we can decide IPv6 path MTU independently from IPv4 traffic. A simple solution would be to always fragment packets from the TRT system to UDP/IPv6 side to IPv6 minimum MTU (1280 octets), to eliminate the need for IPv6 path MTU discovery.
UDP的TRT必须处理UDP/IPv6端的路径MTU问题。好的是，由于我们不在IPv4和IPv6之间中继IP层数据包，因此我们可以独立于IPv4流量来决定IPv6路径MTU。一个简单的解决方案是始终将从TRT系统到UDP/IPv6端的数据包分段到IPv6最小MTU（1280个八位字节），以消除IPv6路径MTU发现的需要。
Though the TRT system only relays {TCP,UDP} traffic, it needs to check ICMPv6 packets destined to C6::X4 as well, so that it can recognize path MTU discovery messages and other notifications between A6 and C6::X4.
尽管TRT系统仅中继{TCP，UDP}通信量，但它也需要检查发往C6:：X4的ICMPv6数据包，以便能够识别A6和C6:：X4之间的路径MTU发现消息和其他通知。
When forwarding TCP traffic, a TRT system needs to handle urgent data [Postel, 1981] carefully.
在转发TCP流量时，TRT系统需要仔细处理紧急数据[Postel，1981]。
To relay NAT-unfriendly protocols [Hain, 2000] a TRT system may need to modify data content, just like any translators which modifies the IP addresses.
为了中继NAT不友好的协议[Hain，2000]，TRT系统可能需要修改数据内容，就像任何修改IP地址的翻译器一样。
Scalability issues must carefully be considered when you deploy TRT systems to a large IPv6 site. Scalability parameters would be (1) number of connections the operating system kernel can accept, (2) number of connections a userland process can forward (equals to number of filehandles per process), and (3) number of transport relaying processes on a TRT system. Design decision must be made to use proper number of userland processes to support proper number of connections.
在将TRT系统部署到大型IPv6站点时，必须仔细考虑可伸缩性问题。可伸缩性参数包括（1）操作系统内核可以接受的连接数，（2）userland进程可以转发的连接数（等于每个进程的文件句柄数），以及（3）TRT系统上的传输中继进程数。必须做出设计决策，以使用适当数量的用户区进程来支持适当数量的连接。
To make TRT for TCP more scalable in a large site, it is possible to have multiple TRT systems in a site. This can be done by taking the following steps: (1) configure multiple TRT systems, (2) configure different dummy prefix to them, (3) and let the initiating host pick a dummy prefix randomly for load-balancing. (3) can be implemented as follows; If you install special DNS server to the site, you may (3a) configure DNS servers differently to return different dummy prefixes and tell initiating hosts of different DNS servers. Or you can (3b) let DNS server pick a dummy prefix randomly for load-balancing. The load-balancing is possible because you will not be changing destination address (hence the TRT system), once a TCP connection is established.
为了使TCP的TRT在大型站点中更具可伸缩性，可以在一个站点中有多个TRT系统。这可以通过以下步骤完成：（1）配置多个TRT系统，（2）为它们配置不同的虚拟前缀，（3）并让发起主机随机选择一个虚拟前缀进行负载平衡。（3） 可按如下方式实施；如果您在站点上安装了特殊的DNS服务器，您可以（3a）对DNS服务器进行不同的配置，以返回不同的伪前缀，并告知不同DNS服务器的启动主机。或者，您可以（3b）让DNS服务器随机选择一个虚拟前缀进行负载平衡。负载平衡是可能的，因为一旦TCP连接建立，您将不会更改目标地址（因此TRT系统）。
For address mapping, the authors recommend use of a special DNS server for large-scale installation, and static mapping for small-scale installation. It is not always possible to have special resolver on the initiating host, and assuming it would cause deployment problems.
对于地址映射，作者建议在大规模安装时使用特殊的DNS服务器，在小规模安装时使用静态映射。在启动主机上并不总是可能有特殊的解析器，并且假设它会导致部署问题。
Combined with a special DNS server implementation (which translates IPv4 addresses into IPv6), TRT systems support IPv6-to-IPv4 translation very well. It requires no change to existing IPv6 clients, nor IPv4 servers, so the TRT system can be installed very easily to existing IPv6-capable networks.
结合特殊的DNS服务器实现（将IPv4地址转换为IPv6），TRT系统非常支持IPv6到IPv4的转换。它不需要更改现有的IPv6客户端，也不需要更改IPv4服务器，因此可以非常轻松地将TRT系统安装到支持IPv6的现有网络上。
IPv4-to-IPv6 translation is much harder to support with any of the translator techniques [Yamamoto, 1998]. While it is possible to use TRT system for IPv4-to-IPv6 translation, it requires nontrivial mapping between DNS names to temporary IPv4 addresses, as presented in NAT-PT RFC [Tsirtsis, 2000].
任何翻译技术都很难支持IPv4到IPv6的转换[Yamamoto，1998]。虽然可以使用TRT系统进行IPv4到IPv6的转换，但它需要DNS名称到临时IPv4地址之间的非平凡映射，如NAT-PT RFC[Tsirtsis，2000]所示。
As presented in the earlier sections, TRT systems use transport layer (TCP/UDP) relay technique to translate IPv6 traffic to IPv4 traffic. It gives two major benefits: (1) the implementation of the TRT system can be done very simple, (2) with the TRT system path MTU discovery issue is easier to deal with, as we can decide IPv6 path MTU independently from IPv4 path MTU. Even with the simplicity, the TRT system can cover most of the daily applications (HTTP, SMTP, SSH, and many other protocols). For NAT-unfriendly protocols, a TRT system may need to modify data content, just like any translators/NATs. As the TRT system reside in transport layer, it is not possible for the TRT system to translate protocols that are not known to the TRT system.
如前几节所述，TRT系统使用传输层（TCP/UDP）中继技术将IPv6流量转换为IPv4流量。它有两大好处：（1）TRT系统的实现非常简单，（2）使用TRT系统路径MTU发现问题更容易处理，因为我们可以独立于IPv4路径MTU确定IPv6路径MTU。即使简单，TRT系统也可以覆盖大多数日常应用程序（HTTP、SMTP、SSH和许多其他协议）。对于NAT不友好的协议，TRT系统可能需要修改数据内容，就像任何翻译器/NAT一样。由于TRT系统位于传输层，因此TRT系统不可能翻译TRT系统不知道的协议。
Normally users do not want to translate DNS query/reply traffic using the TRT system. Instead, it makes more sense to run standard DNS server, or special DNS server that helps TRT system, somewhere in the site IPv6 network. There are two reasons to it:
通常，用户不希望使用TRT系统转换DNS查询/回复流量。相反，在站点IPv6网络的某处运行标准DNS服务器或帮助TRT系统的特殊DNS服务器更有意义。有两个原因：
o Transport issue - It is a lot easier to provide recursive DNS server, accessible via IPv6, than to translate DNS queries/replies across the TRT system. If someone tries to ask TRT to translate DNS packets, the person would put C6::X (where C6 is TRT reserved prefix and X is an IPv4 address of a DNS server) into /etc/resolv.conf. The configuration is rather complicated than we normally want.
o 传输问题-提供可通过IPv6访问的递归DNS服务器比在整个TRT系统中转换DNS查询/回复容易得多。如果有人试图要求TRT翻译DNS数据包，此人会将C6:：X（其中C6是TRT保留前缀，X是DNS服务器的IPv4地址）放入/etc/resolv.conf。配置比我们通常想要的要复杂得多。
o Payload issue - In some installation it makes more sense to transmit queries/replies unmodified, across the TRT system. In some installation it makes more sense to translate IPv4 DNS queries (like queries for AAAA record) into queries for A record, and vice versa, to invite traffic into the TRT system. It depends on the installation/configuration at the user's site.
o 有效负载问题-在某些安装中，通过TRT系统不经修改地传输查询/回复更有意义。在某些安装中，将IPv4 DNS查询（如AAAA记录查询）转换为记录查询更为合理，反之亦然，以邀请流量进入TRT系统。这取决于用户站点的安装/配置。
Malicious party may try to use TRT systems akin to an SMTP open relay [Lindberg, 1999] for traffic to IPv4 destinations, which is similar to circumventing ingress filtering [Ferguson, 1998] , or to achieve some other improper use. TRT systems should implement some sorts of access control to prevent such improper usage.
恶意方可能会尝试使用类似于SMTP开放中继的TRT系统[Lindberg，1999]用于IPv4目的地的流量，这类似于绕过入口过滤[Ferguson，1998]，或实现其他一些不正当使用。TRT系统应实施某种访问控制，以防止此类不当使用。
A careless TRT implementation may be subject to buffer overflow attack, but this kind of issue is implementation dependent and outside the scope of this memo.
粗心的TRT实现可能会受到缓冲区溢出攻击，但此类问题取决于实现，不在本备忘录的范围内。
Due to the nature of TCP/UDP relaying service, it is not recommended to use TRT for protocols that use authentication based on source IP address (i.e., rsh/rlogin).
由于TCP/UDP中继服务的性质，对于使用基于源IP地址（即rsh/rlogin）的身份验证的协议，不建议使用TRT。
A transport relay system intercepts TCP connection between two nodes. This may not be a legitimate behavior for an IP node. The document does not try to claim it to be legitimate.
传输中继系统拦截两个节点之间的TCP连接。这可能不是IP节点的合法行为。这份文件并不试图声称它是合法的。
IPsec cannot be used across a relay.
IPsec不能跨中继使用。
Use of DNS proxies that modify the RRs will make it impossible for the resolver to verify DNSsec signatures.
使用修改RRs的DNS代理将使解析器无法验证DNSsec签名。
References
工具书类
[Nordmark, 2000.] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[Nordmark，2000.]Nordmark，E.“无状态IP/ICMP转换器（SIIT）”，RFC 27652000年2月。
[Postel, 1981.] Postel, J., "Transmission Control Protocol", STD 7, RFC 793 September 1981.
[Postel，1981.]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[Hain, 2000.] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[Hain，2000.]Hain，T，“NAT的建筑影响”，RFC 29932000年11月。
[Yamamoto, 1998] K. Yamamoto, A. Kato, M Sumikawa, and J. Murai, "Deployment and Experiences of WIDE 6bone", in Proceedings of INET98, 1998.
[Yamamoto，1998]K.Yamamoto，A.Kato，M Sumikawa和J.Murai，“宽6bone的部署和经验”，摘自1998年INET98会议录。
[Tsirtsis, 2000.] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[Tsirtsis，2000.]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC2762000年2月。
[Lindberg, 1999.] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", RFC 2505, February 1999.
[Lindberg，1999.]Lindberg，G.“SMTP MTA的反垃圾邮件建议”，RFC 25051999年2月。
[Ferguson, 1998.] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[Ferguson，1998.]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，RFC 2267，1998年1月。
WIDE KAME IPv6 stack implements TRT for TCP, called "FAITH". The implementation came from WIDE Hydrangea IPv6 stack, which is one of ancestors of the KAME IPv6 stack.
宽KAME IPv6堆栈实现TCP的TRT，称为“FAITH”。该实现来自WIDE Hydrangea IPv6堆栈，它是KAME IPv6堆栈的前身之一。
The FAITH code has been available and operational for more than 5 years. The implementation has been used at WIDE research group offsite meeting, and IETF ipngwg 1999 Tokyo interim meeting. At the latter occasion, we configured IPv6-only terminal network cluster just like we do in IETF meetings, and used a TRT system to support more than 100 IPv6 hosts on the meeting network to connect to outside IPv4 hosts. From statistics we gathered SSH, FTP, HTTP, and POP3 are the most popular protocol we have relayed. The implementation was also used in the terminal cluster IPv6 network at IETF48, IETF49 and IETF50.
《信仰守则》已经面世并运行了5年多。该实施已在广域研究小组场外会议和IETF ipngwg 1999年东京临时会议上使用。在后一种情况下，我们像在IETF会议中一样配置了仅IPv6的终端网络群集，并使用TRT系统支持会议网络上的100多个IPv6主机连接到外部IPv4主机。根据我们收集的统计数据，SSH、FTP、HTTP和POP3是我们中继的最流行的协议。该实现还用于IETF48、IETF49和IETF50的终端集群IPv6网络。
The source code is available as free software, bundled in the KAME IPv6 stack kit.
源代码以自由软件的形式提供，捆绑在KAME IPv6堆栈工具包中。
Special DNS server implementations are available as "newbie" DNS server implementation by Yusuke DOI, and "totd" DNS proxy server from University of Tromso (Norway).
特殊的DNS服务器实现可由Yuuukdoi和“ToTD”DNS代理服务器（特罗姆瑟大学）（挪威）提供的“NexBee”DNS服务器实现。
Acknowledgements
致谢
The authors would like to thank people who were involved in implementing KAME FAITH translator code, including Kei-ichi SHIMA and Munechika SUMIKAWA.
作者要感谢那些参与实施KAME信仰翻译代码的人，包括Kei ichi SHIMA和Munechika SUMIKAWA。
Authors' Addresses
作者地址
Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, JAPAN
Jun ichiro itojun HAGINO研究实验室，互联网倡议日本公司，日本东京千代田区神田西池町3-13号竹桥安田大厦，101-0054
Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: itojun@iijlab.net
Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: itojun@iijlab.net
Kazu YAMAMOTO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, JAPAN
日本东京千代田区神田西池町3-13号竹桥安田大厦互联网倡议日本公司山本和津研究实验室101-0054
Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: kazu@iijlab.net
Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: kazu@iijlab.net
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。