この文書はRFC3142の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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. 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 だけのホストが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システムを実行するべきか 話します。これは新しいプロトコルを定義しません。 1. Problem domain 1. 問題範囲 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-to-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はIPv4だけの宛先ホストの修正と、IPv6だけの開始ホスト の余分の修正の、いずれも必要としないよう意図します。他の翻訳メカニ ズムが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ヘッダー変換はパス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参照)、転送レイヤ接続が特定の1つの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. この文書はトラフィックがIPv6のみのホストからIPv4のみのホスト に向かうと想定します。この文書は、もし適切なアドレスマップメカニズム があれば、反対方向の処理をするために拡張できます。 2. IPv4-to-IPv4 transport relay 2. IPv4-to-IPv4転送リレー 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. 次の章での提案の理解に手を貸すため、ここで一般の転送リレーを記述しま す。転送リレーテクニックそれ自身は、ファイアウォール関連のプロダクト の多くで使われてるので、新しくありません。 2.1. TCP relay 2.1. TCPリレー 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トラヒックだけを、内部ネット ワークから外部ネットワークに中継するだけで、逆も同様です。(ノート: 図はただ内部に1つと外部に1つの計2つのサブネットだけがあります。実 際は両側はより複雑であり得て、望むだけ多くのサブネットとルーターがあ り得ます。) destination host 宛先ホスト |X ==+=======+== outer network 外部ネットワーク |Y TCP relay system TCPリレーシステム |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)を持っていないが、パケットを受け取り、受け入れます。TC PリレーシステムはIPアドレスXを持つように見せかけて、Xとして開始 ホストとTCP接続を確立します。リレーシステムがそれからYからXへの ほかの接続を行い、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) TCP/IPv4: 開始ホスト(A) --> TCPリレーシステム(Xをまねて) address on IPv4 header: A -> X IPv4ヘッダのアドレス: A -> X TCP/IPv4: the TCP relay system (Y) --> the destination host (X) TCP/IPv4: TCPリレーシステム(Y) --> 宛先ホスト(X) address on IPv4 header: 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パケットの一部を取り 込む必要があります。その方法は実装に依存し、このメモの範囲の外です。 2.2. UDP relay 2.2. UDPリレー 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トラフィックのどれが対になるかわかるなら、U DPリレーがTCPリレーと類似の方法で実装できます。表にアドレス/ポー ト対を記録しタイムアウトにより表項目を管理することで、実装がNATシ ステムの様にUDPトラヒックペアを認識できます。 3. IPv6-to-IPv4 transport relay translator 3. IPv6-to-IPv4転送リレー翻訳者 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/IP接続を する必要があります。例えば、もしC6::/64がfec0:0:0:1::/64で、X4が 10.1.1.1なら、宛先アドレスとしてはfec0:0:0:1::10.1.1.1を使います。パ ケットはTRTシステムに向かい、TRTに取り込まれます。TRTシステ ムはA6とC6::X4間のTCP/IPv6接続を受け入れ、TCP/IPv6を使用して開始ホ ストと通信します。それから、TRTシステムは宛先アドレス(IPv6ア ドレスC6::X4)の下位32ビットを調査して本当のIPv4宛先(IPv4 アドレスX4)を得ます。TRTは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) TCP/IPv6: 開始ホスト(A6) --> TRTシステム(C6::X4) address on IPv6 header: A6 -> C6::X4 IPv6ヘッダのアドレス: A6 -> C6::X4 TCP/IPv4: the TRT system (Y4) --> the destination host (X4) TCP/IPv4: TRTシステム(Y4)--> 宛先ホスト(X4) address on IPv4 header: Y4 -> X4 IPv4ヘッダのアドレス: Y4 -> X4 4. Address mapping 4. アドレスマッピング 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 リゾルバ実装により変換できます。 5. Notes to implementers 5. 実装者へのノート 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間のパスM TU探索メッセージや他の通知を認識する必要があります。 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. 大きい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)多数のTR Tシステムを配置します、(2)それらに異なったダミープレフィックスを配置 します、(3)そして開始ホストは負荷分散のためランダムにダミープレフィッ クスを選択します。(3)は次のように実行できます;もしあなたがサイトに特 別DNSサーバーをインストールするなら以下が出来ます、(3a)異なるDN Sサーバが異なるダミープレフィックスを返すようにし、開始ホストに異な るDNSサーバーを通知する。あるいは(3b)DNSサーバーが負荷分散のた めランダムにダミープレフィックスを選びます。TCP接続が確立されたら 宛先アドレスを変えていないであろうから負荷分散が可能です。 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 サーバーの使用を、小さな導入には静的マッピングを勧めます。開始ホスト で特別なリゾルバを常に使用可能とは限らず、これは展開上の問題をもらた すと仮定します。 6. Applicability statement 6. 適用性宣言 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. (IPv4アドレスをIPv6に変換する)特別なDNSサーバー実装によ り、TRTシステムが大変上手 IPv6-to-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システムを使うことは可能であるが、それはDN S名から一時的な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システムがIPv6トラフィックをI Pv4トラフィックに翻訳する転送レイヤ(TCP/UDP)リレーテクニックを 使います。それは主に2つの利益を与えます:(1)TRTシステムの実装は非 常に簡単にでき、(2)TRTシステムのパスMTU探索問題は、IPv6パス MTU決定がIPv4パス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問合せ/応答トラフィックを 翻訳することを望みません。代わりにあるサイトで標準DNSサーバを動か すか、TRTシステムを助ける特別な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 転送問題−IPv6によってアクセス可能な再帰DNSサーバーを供給す ることは、TRTシステムでDNS問合/回答を翻訳することより容易で す。もし誰かがTRTにDNSパケットを翻訳を頼もうとするなら、その 人は/etc/resolv.confにC6::Xを設定するでしょう(C6がTRT予約プレ フィックスで、XがDNSサーバーのIPv4アドレスです)。設定は我 々が通常欲するよりどちらかと言うと複雑です。 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システムを通して修正なしに問合せ/ 答えを伝達するためにもっと多くの理解が必要です。ある導入でAレコー ドのIPv4DSN問合せ(AAAAレコードの問い合わせの様に)、あるい はで、TRTシステムにトラフィックを招くために、もっと多くの理解が 必要です。これはユーザーサイトの導入/設定に頼ります。 7. Security Considerations 7. セキュリティの考察 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システムを使おうとするかもしれず、 これは迂回入場フィルター[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. 転送リレーシステムが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. 資源レコードを修正するDNSプロキシの使用がリゾルバのDNSsec署名を 検証不可能にするでしょう。 References 参考文献 [Nordmark, 2000.] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000. [Postel, 1981.] Postel, J., "Transmission Control Protocol", STD 7, RFC 793 September 1981. [Hain, 2000.] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [Yamamoto, 1998] K. Yamamoto, A. Kato, M Sumikawa, and J. Murai, "Deployment and Experiences of WIDE 6bone", in Proceedings of INET98, 1998. [Tsirtsis, 2000.] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [Lindberg, 1999.] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", RFC 2505, February 1999. [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. 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を実装します。 実装はWIDE Hydrangea IPv6スタックから来て、これはKAME IPv6スタックの 先祖の1つです。 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 ipngwg1999東京仮ミーティングで使 われました。後の行事で、IETFミーティングとまったく同じように、IPv6だ けの端末ネットワークの集まりを配置し、ミーティングネットワーク上の 100以上のIPv6ホストが外部IPv4ホストへ接続するのをサポート するため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サーバー実装が、Yusuke DOIの"newbie"DNSサーバ実装と、 Tromso大学(ノルウェー)の"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 FAITH 翻訳者コードを実行することにおいて、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 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 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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。