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
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}に{TCP、UDP} / IPv6を変換/ 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専用のネットワークリソースへのアクセスを獲得します。この問題を解決するために、多くの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} / {TCP、UDP} /のIPv4に対するIPv6との間に位置します。
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.
IPv6からIPv4ヘッダコンバータoをパス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 TRTはちょうどNATシステムのように、通信ピア間のステートフルTRTシステムを必要とします。それは（付録Aを参照してください）サイト内の複数のTRTシステムを配置することは可能ですが、トランスポート層接続は特に、単一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つを持って実際に両側がより複雑にすることができ、あなたが望む限り多くのサブネットとルータが存在することができます。）。
destination host |X ==+=======+== outer network |Y TCP relay system |B ==+=======+== inner network |A initiating host
宛先ホスト| X == + ======= + ==外ネットワーク| Y TCP中継システム| B == + ======= + ==内部ネットワーク|開始ホスト
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にYから別のTCP接続を行い、そしてからのトラフィックを中継Xに、そして他の方法で回避X.のTCPリレーシステムとして開始ホストとのTCP接続を確立します。
Thus, two TCP connections are established in the picture: from A to B (as X), and from Y to X, like below:
したがって、2つのTCP接続が画像に確立されている：から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の：開始ホスト（A） - > TCP中継システムのIPv4ヘッダ上のアドレス（Xなど）：A - > X TCP / IPv4の：TCPリレーシステム（Y） - >宛先ホスト（X） IPv4ヘッダ上のアドレス：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 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によって参照されるIPv6プレフィックス:: / 64を予約します。 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接続を作成する必要があります。 0：0：例えば、C6場合:: / 64要するfec0と等しい1 :: / 64、およびX4が10.1.1.1に等しい、使用される宛先アドレスがFEC0ある：0：0：1 :: 10.1.1.1 。パケットは、TRTシステムに向かってルーティングされ、それにより捕捉されます。 TRTシステムは:: A6とC6との間のTCP / IPv6接続を受け入れ、X4、およびTCP / IPv6を使用して、開始するホストと通信します。その後、TRTシステムは、実際のIPv4宛先（IPv4アドレスX4）を取得するための宛先アドレス（IPv6アドレスC6 :: X4）の最下部の32ビットを調査します。これは、2つのTCPコネクション間でTCP / IPv4ののX4へY4からの接続、およびトラフィックを転送します。
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接続があります。一つは、TCP / IPv6のであり、別の画像に、TCP / IPv4のである：A6からB6まで（C6として:: X4）、およびX4にY4、以下のように：
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の：開始ホスト（A6） - > TRTシステムIPv6ヘッダ上のアドレス（C6 :: X4として）：A6 - > C6 :: X4 TCP / IPv4の：TRTシステム（Y4） - >先IPv4ヘッダ上のホスト（X4）アドレス：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.
前のセクションで見られるように、開始ホストは、IPv4宛先ホストに接続するために、IPv6アドレスの特殊な形式を使用しなければなりません。特殊な形態は、（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を決めることができる、ということです。簡単な解決策は、IPv6パスMTU発見のための必要性を排除するために、IPv6の最小MTU（1280オクテット）にUDP / IPv6の側にTRTシステムから常に断片パケットになるであろう。
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}トラフィックが、それは、パスMTUディスカバリメッセージとA6とC6 :: X4の間に他の通知を認識できるように、同様のICMPv6 C6宛てのパケット:: X4をチェックする必要があります。
When forwarding TCP traffic, a TRT system needs to handle urgent data [Postel, 1981] carefully.
TCPトラフィックを転送するとき、TRTシステムは慎重に緊急のデータ[ポステル、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-無愛想なプロトコルを中継するには、[ハイン、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.
あなたが大規模なIPv6サイトにTRTシステムを展開するときにスケーラビリティの問題を慎重に検討する必要があります。スケーラビリティパラメータは、（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サーバーをインストールする場合は、（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.
（IPv6のにIPv4アドレスを変換する）特殊なDNSサーバー実装と組み合わせることで、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変換は、翻訳者技術[山本、1998]のいずれかをサポートすることは非常に困難です。それは、IPv4からIPv6翻訳にTRTシステムを使用することも可能ですがNAT-PT RFC [Tsirtsis、2000]に提示され、それは、一時的なIPv4アドレスをDNS名間の自明でないのマッピングが必要です。
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システムは、IPv4トラフィックにIPv6トラフィックを変換するトランスポート層（TCP / UDP）リレー技術を使用しています。これは、2つの大きな利点を提供します：（1）TRTシステムの実装は非常にシンプルに行うことができ、我々は、IPv4パスMTUとは独立したIPv6パスMTUを決めることができるよう（2）TRTシステムパス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サーバを提供するために、多くの方が簡単です。誰かがDNSパケットを変換するためにTRTを依頼しようとすると、人は/etc/resolv.confのに（C6はTRTは接頭辞を予約されており、Xは、DNSサーバのIPv4アドレスです）C6 :: Xを入れてしまうでしょう。コンフィギュレーションは、私たちが通常必要ではなく、複雑です。
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システム全体で、そのまま返信します。一部のインストールでは、TRTシステムにトラフィックを招待し、レコードのクエリ、およびその逆に（AAAAレコードのクエリなど）のIPv4 DNSクエリを変換するために、より理にかなっています。これは、ユーザーのサイトでインストール/設定に依存します。
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.
悪意のあるパーティは入力フィルタリング[ファーガソン、1998]回避に似ている、またはいくつかの他の不適切な使用を実現するためのIPv4宛先へのトラフィックのためのSMTPオープンリレー[リンドバーグ、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.
RRを修正するDNSプロキシの使用は、それが不可能リゾルバはDNSSECの署名を検証できるようにするためだろう。
References
リファレンス
[Nordmark, 2000.] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[Nordmarkと、2000] Nordmarkと、E.、 "ステートレスIP / ICMPトランスレータ（SIIT）"、RFC 2765、2000年2月。
[Postel, 1981.] Postel, J., "Transmission Control Protocol", STD 7, RFC 793 September 1981.
[ポステル、1981]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793 1981年9月。
[Hain, 2000.] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[ハイン、2000]ハイン、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.
INET98 1998年の議事録における[山本1998] K.山本、A.加藤、M澄川、及びJ.村井、 "WIDEの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.
[リンドバーグ、1999]リンドバーグ、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.
[ファーガソン、1998]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス妨害Attacksを破り"、RFC 2267、1998年1月。
Appendix A. Operational experiences
付録A.運用経験
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.
WIDE KAME IPv6スタックは "FAITH" と呼ばれる、TCPのためのTRTを実装しています。実装は、KAME IPv6スタックの祖先の1つであるWIDEアジサイ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.
FAITHコードは、5年以上のために利用可能で、運用されています。実装はWIDE研究グループのオフサイトミーティングで使用されてきた、とIETFは、1999年の東京暫定会議をipngwg。後者の際、我々はIETFミーティングで行うと同じようにIPv6のみの端末のネットワーククラスタを構成して、外部のIPv4ホストに接続するための会議ネットワーク上の100台の以上のIPv6ホストをサポートするために、TRTシステムを使用していました。統計から、我々は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サーバの実装は雄介DOIによる「初心者」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.
著者は圭健一SHIMAとMunechika澄川含む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
じゅんーいちろ いとじゅん はぎの れせあｒｃｈ ぁぼらとｒｙ、 いんてｒねｔ いにちあちゔぇ じゃぱん いんｃ。 たけばし やすだ Ｂｌｄｇ。、 ３ー１３ かんだ にしきーちょ、 ちよだーく、 ときょ １０１ー００５４、 じゃぱん
Phone: +81-3-5259-6350 Fax: +81-3-5259-6351 EMail: itojun@iijlab.net
電話：+ 81-3-5259-6350ファックス：+ 81-3-5259-6351 Eメール：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
かず やまもと れせあｒｃｈ ぁぼらとｒｙ、 いんてｒねｔ いにちあちゔぇ じゃぱん いんｃ。 たけばし やすだ Ｂｌｄｇ。、 ３ー１３ かんだ にしきーちょ、 ちよだーく、 ときょ １０１ー００５４、 じゃぱん
Phone: +81-3-5259-6350 Fax: +81-3-5259-6351 EMail: kazu@iijlab.net
電話：+ 81-3-5259-6350ファックス：+ 81-3-5259-6351 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。