[要約] RFC 3142は、IPv6からIPv4へのトランスポートリレートランスレーターに関する規格です。その目的は、IPv6ネットワークとIPv4ネットワークの間で通信を可能にするためのトランスレーターの仕組みを提供することです。
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-to-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.
Copyright（c）The Internet Society（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-to-IPV4トランスポートリレー翻訳者（TRT）について説明しています。IPv6のみのホストが{TCP、UDP}トラフィックをIPv4のみのホストと交換できるようにします。中央に位置する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のみのWebサーバーなど、IPv4のみのネットワークリソースを外部にアクセスできるようにする必要があります。この問題を解決するために、主にIETF NGTRANSワーキンググループでは、多くのIPv6からIPV4翻訳技術が提案されています。メモは、同じ問題を解決するためのトランスポートリレー技術に基づいた翻訳者について説明しています。
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-to-IPV4ヘッダーコンバーターは、PATH 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-to-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 TRTは、NATシステムと同様に、通信仲間の間でステートフルな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に適したプロトコルを中継するには、特別なコードが必要です。IPSECを含むNAT不適合プロトコルの一部は、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トラフィックのみをリリーします。（注：図には2つのサブネットしかありません。1つは内側用、もう1つは外側用です。実際、両側はより複雑で、必要なほど多くのサブネットとルーターが存在する可能性があります。）
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リレーシステムが宛先IPアドレス（x）を所有していない場合でも、TCPリレーシステムはパケットを受信および受け入れます。TCPリレーシステムは、IPアドレスXを使用するふりをし、開始ホストとのTCP接続をXとして確立します。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:
したがって、写真には2つの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
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 Systemsのように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-to-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 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で言及されているIPv6プレフィックスを予約します。C6 ::/64は、サイトに割り当てられたIPv6ユニキャストアドレススペースの一部である必要があります。ルーティング情報は、C6 ::/64へのパケットがTRTシステムに向かってルーティングされるように構成する必要があります。次の図は、ネットワーク構成を示しています。「ダミープレフィックス」としてマークされたサブネットは実際には存在しません。また、開始ホストはIPv6のみであり、宛先ホストがIPv4のみであると想定しています。
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システムは、宛先アドレスの最下部32ビット（IPv6アドレスC6 :: x4）を調査して、実際のIPv4宛先（IPv4アドレスX4）を取得します。Y4からX4へのTCP/IPv4接続を作成し、2つの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:
2つのTCP接続があります。1つはTCP/IPv6で、もう1つは写真の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
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 /ホストなど）、特別な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側のPATH MTUの問題を処理する必要があります。良いことは、IPv4とIPv6の間でIPレイヤーパケットを中継しないため、IPv4トラフィックとは独立してIPv6 Path MTUを決定できることです。簡単な解決策は、TRTシステムからUDP/IPv6側、IPv6最小MTU（1280オクテット）までのパケットを常に断片化し、IPv6 Path 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}トラフィックのみをリレーしていますが、A6とC6 :: X4の間のPATH MTUディスカバリーメッセージとその他の通知を認識できるように、C6 :: X4に向けたICMPV6パケットも確認する必要があります。
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.
IPアドレスを変更する翻訳者と同様に、NATの不適合プロトコル[Hain、2000]をリレーするには、TRTシステムがデータコンテンツを変更する必要がある場合があります。
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）ユーザーランドプロセスが転送できる接続の数（プロセスごとのファイルハンドルの数に等しい）、（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サーバーをサイトにインストールすると、DNSサーバーを異なる方法で構成する（3A）異なるダミープレフィックスを返し、異なる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-to-IPV6の翻訳は、翻訳者のテクニックのいずれかでサポートするのがはるかに困難です[Yamamoto、1998]。IPv4-to-IPv6翻訳にTRTシステムを使用することは可能ですが、NAT-PT RFC [Tsirtsis、2000]に示されているように、DNS名間の非自明なマッピングが一時的なIPv4アドレスに必要です。
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システムはIPv6トラフィックをIPv4トラフィックに変換するために、トランスポート層（TCP/UDP）リレー技術を使用します。（1）TRTシステムの実装を非常に簡単に実行できます。（2）TRTシステムパスMTU発見の問題は、IPv4 Path MTUとは独立してIPv6 Path 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ネットワークのどこかでTRTシステムを支援する標準のDNSサーバー、または特別なDNSサーバーを実行する方が理にかなっています。それには2つの理由があります。
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 トランスポートの問題 - TRTシステム全体でDNSクエリ/返信を翻訳するよりも、IPv6を介してアクセス可能な再帰的な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.
悪意のある当事者は、IPv4目的地へのトラフィックのために、SMTPオープンリレー[Lindberg、1999]に似たTRTシステムを使用しようとする場合があります。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.
トランスポートリレーシステムは、2つのノード間の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。、「Stateless IP/ICMP Translator（SIIT）」、RFC 2765、2000年2月。
[Postel, 1981.] Postel, J., "Transmission Control Protocol", STD 7, RFC 793 September 1981.
[Postel、1981。] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793 1981年9月。
[Hain, 2000.] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[Hain、2000。] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[Yamamoto, 1998] K. Yamamoto, A. Kato, M Sumikawa, and J. Murai, "Deployment and Experiences of WIDE 6bone", in Proceedings of INET98, 1998.
[ヤマモト、1998] K. Yamamoto、A。A.Kato、M Sumikawa、およびJ. Murai、INET98、1998の議事録における「広い6boneの展開と経験」。
[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）」、RFC 2766、2000年2月。
[Lindberg, 1999.] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", RFC 2505, February 1999.
[Lindberg、1999。] Lindberg、G。、「SMTP MTAの反スパム推奨」、RFC 2505、1999年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。and 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.
ワイドカメIPv6スタックは、「信仰」と呼ばれるTCPのTRTを実装しています。この実装は、KAME IPv6スタックの祖先の1つであるワイドアジサイ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サーバーの実装は、Yusuke Doiによる「Newbie」DNSサーバーの実装、およびトロムソ大学（ノルウェー）の「TOTD」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 ShimaやMunechika sumikawaなど、Kame Faith翻訳者コードの実装に関与していた人々に感謝したいと思います。
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-Ithiro Itojun Hagino Research Laboratory、Internet Initiative Japan Inc. Takebashi Yasuda Bldg。、3-13 Kanda Nishiki-Cho、Chiyoda-Ku、Tokyo 101-0054、日本
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。