RFC3142 日本語訳

Network Working Group                                          J. Hagino
Request for Comments: 3142                                   K. Yamamoto
Category: Informational                          IIJ Research Laboratory
                                                               June 2001

Haginoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3142年のK.山本カテゴリ: 情報のIIJ研究所2001年6月

               An IPv6-to-IPv4 Transport Relay Translator

IPv6からIPv4への輸送リレー翻訳者

Status of this Memo

この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)インターネット協会(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から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システムを導入するかに関して話します。 それはどんな新しいプロトコルも定義しません。

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だけネットワーク資源へのアクセスを得ていたがっています、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、/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だけで付加的な変更を必要とします。

Hagino & Yamamoto            Informational                      [Page 1]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[1ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

   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 TRTは交信している同輩の間のstateful TRTシステムを必要とします、まさしくNATシステムのように。サイトの複数のTRTシステムを置くのは可能ですが(Appendix Aを見てください)、トランスポート層接続は特定の状態で通ります、ただ一つのTRTシステム。 その結果、1ポイントの失敗であるとTRTシステムを考えることができます、再びNATシステムのように。SIITなどのある他のメカニズム[Nordmark、2000]は1ポイントの失敗を避けることができる状態がない翻訳者システムを使用します。

   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無愛想なプロトコルをリレーするのに必要です。 TRTシステムの向こう側にIPsecを含むNAT無愛想なプロトコルのいくつかを使用できません。

   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だけホストによって開始されると仮定します。 適切なアドレス・マッピングメカニズムが紹介されるなら、逆方向を扱うためにメモを広げることができます。

2.  IPv4-to-IPv4 transport relay

2. IPv4から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) (2) システムの向こう側にIPパケットの推進を禁じてください、そして、TCP、UDPにトラフィックを許容して、間接的にシステムに直面してください。 例えば、以下のダイヤグラムのように構成されたネットワークを考えてください。 ダイヤグラムによる「TCPリレー方式」が内側のネットワークの向こう側にIPパケットを外側のネットワークに送らない、逆もまた同様です。 それが特定のポートの上で内側のネットワークから外側のネットワークまでTCPトラフィックをリレーするだけである、逆もまた同様です。 (以下に注意してください。 ダイヤグラムには2つのサブネットだけ、より多くのinの間の1、および1つがある、外側です。 実際に両側は、より複雑である場合があります、そして、あなたが願っているように同じくらい多くのサブネットとルータがあることができます。)

Hagino & Yamamoto            Informational                      [Page 2]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[2ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

      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である)がTCP接続をあて先ホスト(X)にしようとするなら、TCPパケットはルーティング決定に基づくTCPリレー方式に向かって発送されます。 TCPリレー方式は、パケットを受けて、受け入れます、TCPリレー方式は送付先IPアドレス(X)を所有していませんが。 TCPリレー方式は、IPアドレスXを持っているのにふりをして、次に、X. TCPリレー方式がX、およびAから逆になりまで別のYから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、同類までのAから:

      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リレー方式(Xとしての)がIPv4ヘッダーの上に扱う>: ->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パケットをキャプチャするシステムの必要性をリレーします。 実装に依存していて、このメモの範囲の外でそれをする方法。

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を認識できるか、そして、アウトバウンドトラフィックは何らかの方法で対にされて、TCPリレーとして同様の方法でUDPリレーは実装することができます。 実装は、トラフィックがNATシステムのように対にするUDPがアドレス/ポート組をテーブルに記録して、タイムアウトでテーブル項目を管理することによってすると認めることができます。

3.  IPv6-to-IPv4 transport relay translator

3. IPv6から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.

TRT、私たちはIPv6からIPv4へのプロトコル変換のために輸送リレー翻訳者を提案します。 以下の記述では、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

アドレス・マッピングに関しては、私たちはC6によって示されたIPv6接頭語を予約します:、:/64. C6:、:/64はIPv6ユニキャストアドレス空間の一部であるべきです。

Hagino & Yamamoto            Informational                      [Page 3]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[3ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

   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

あて先ホスト|X4=+=======+ =外側のネットワーク|Y4 TRTシステム--- ダミーの接頭語(C6: : /64)|B6=+=======+ =内側のネットワーク|ホストを開始するA6

   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である)がa接続をあて先ホスト(IPv4アドレスはX4である)にしたがっているとき、C6に向かってTCP/IPv6接続を作るのが必要です:、:X4。 以下のこと、例えばC6であるなら:/64はfec0: 0:0: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ビットを調査します。 それはY4からX4までのTCP/IPv4接続、および2TCPの向こう側の前進のトラフィックを接続にします。

   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です、そして、別のものは画像で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: 開始は(A6)を接待します--、TRTシステム(C6: : X4としての)がIPv6ヘッダーの上に扱う>: A6->C6:、:X4 TCP/IPv4: TRTシステム(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の/など/ホストのような)、特別なDNSサーバ実装、または変更されたDNSレゾルバ実装の静的なアドレス変換テーブルはホスト名から特別なフォームを決議できます。

Hagino & Yamamoto            Informational                      [Page 4]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[4ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

5.  Notes to implementers

5. implementersへの注意

   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探索の必要性を排除するためにTRTシステムからUDP/IPv6側までIPv6の最小のMTU(1280の八重奏)にパケットをいつも断片化するだろうことです。

   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に運命づけられたチェックICMPv6パケットに以下を必要とします:また、A6とC6の間の経路MTU探索メッセージと他の通知を認識できるためのX4、: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に配布すると、スケーラビリティ問題は慎重に考えなければなりません。 (3) スケーラビリティパラメタはオペレーティングシステムカーネルが受け入れることができる(1)ポートの数でしょう、userlandプロセスが進めることができる(2)ポートの数(1プロセスあたりのfilehandlesの数と等しい)、そして、輸送リレーの数がTRTシステムに処理されます。 適切なポートの数をサポートするのに適切な数のuserlandプロセスを使用するのをデザイン決定をしなければなりません。

   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) (2) 複数のTRTシステムを構成してください、そして、異なったダミーの接頭語をそれらに構成してください、(3)、開始しているホストにダミーの接頭語を手当たりしだいにロードバランシングに選ばせてください。 (3) 以下の通り実装することができます。 特別なDNSサーバをサイトにインストールするなら、あなたはインストールできます。(3a)は、異なったダミーの接頭語を返して、異なったDNSサーバのホストを開始しながら言うためにDNSサーバを異なって構成します。 または、あなたはDNSサーバにダミーの接頭語を手当たりしだいに負荷バランスをとることに選ばせることができます(3b)。 あなたが送付先アドレス(したがって、TRTシステム)を変えないので、負荷分散は可能です、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サーバ、および小さいスケールインストールのための静的なマッピングの使用を推薦します。 特別なレゾルバが開始しているホストの上にあるのが、いつも可能であるというわけではなく、それを仮定するのは展開問題を引き起こすでしょう。

Hagino & Yamamoto            Informational                      [Page 5]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[5ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

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.

特別なDNSサーバ実装(IPv4アドレスをIPv6に翻訳する)に結合されていて、TRTシステムは、IPv6からIPv4が翻訳であると非常によくサポートします。 それが既存のIPv6クライアント、およびIPv4サーバへの変化を全く必要としないので、非常に容易に既存のIPv6できるネットワークにTRTシステムをインストールできます。

   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システムを使用するのが可能ですが、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システムはIPv6トラフィックをIPv4トラフィックに翻訳するのにトランスポート層(TCP/UDP)リレーのテクニックを使用します。 それは2つの主要な利益を与えます: (1) 非常に簡単な状態でTRTシステムの実装ができます、問題はより対処しやすいというTRTシステム経路MTU探索がある(2)、私たちがIPv4経路MTUからIPv6経路MTUについて独自に決めることができるとき。 簡単さがあっても、TRTシステムは毎日のアプリケーション(HTTP、SMTP、SSH、および他の多くのプロトコル)の大部分をカバーできます。 NAT無愛想なプロトコルのために、TRTシステムは、まさしくどんな翻訳者/NATsのようにもデータ内容を変更する必要があるかもしれません。 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サーバを実行するより多くの意味をシステムにします。 それへの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 輸送問題--再帰的なDNSサーバを提供するのははるかに簡単です、IPv6を通してアクセスしやすいです、TRTシステムの向こう側にDNS質問/回答を翻訳するより。 だれかが、DNSパケットを翻訳するようにTRTに頼もうとするなら、人はC6を置くでしょう:、:/etc/resolv.confへの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システムの向こう側に変更されるようになりません。 何らかのインストールでは、それで、IPv4 DNS質問(AAAA記録のための質問のような)をAのための質問に翻訳するより多くの意味が、TRTシステムにトラフィックを招待するために逆もまた同様に記録的になります。 それはユーザのサイトでのインストール/構成に依存します。

Hagino & Yamamoto            Informational                      [Page 6]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[6ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

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の目的地への[ファーガソン、1998]をフィルターにかけるイングレスを回避するのと同様のトラフィックに、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.

RRsを変更するDNSプロキシの使用で、レゾルバがDNSsec署名について確かめるのが不可能になるでしょう。

References

参照

   [Nordmark, 2000.] Nordmark, E., "Stateless IP/ICMP Translator
                     (SIIT)", RFC 2765, February 2000.

[Nordmark、2000。] E.、「状態がないIP/ICMP翻訳者(SIIT)」(RFC2765)2000年2月のNordmark。

   [Postel, 1981.]   Postel, J., "Transmission Control Protocol", STD 7,
                     RFC 793 September 1981.

[ポステル、1981。] ポステル、J.、「通信制御プロトコル」、STD7、RFC793 1981年9月。

   [Hain, 2000.]     Hain, T., "Architectural Implications of NAT", RFC
                     2993, November 2000.

[ハイン、2000。] ハイン、T.、「NATの建築含意」、RFC2993、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.山本、A.加藤、M Sumikawa、J.村井、および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)について議定書の中で述べてください」、RFC2766、2000年2月。

Hagino & Yamamoto            Informational                      [Page 7]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[7ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

   [Lindberg, 1999.] Lindberg, G., "Anti-Spam Recommendations for SMTP
                     MTAs", RFC 2505, February 1999.

[リンドバーグ、1999。] リンドバーグ、G.、「SMTP MTAsのための反スパム推薦」、RFC2505、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を破ります」、RFC2267、1998年1月。

Hagino & Yamamoto            Informational                      [Page 8]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[8ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

Appendix A. Operational experiences

付録A.Operational経験

   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スタックは「信頼」と呼ばれるTCPのためにTRTを実装します。 実装は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.

FAITHコードは、5年間以上利用可能であって、操作上です。 実装はWIDE研究グループオフサイトミーティング、およびIETF ipngwg1999の東京の当座のミーティングで使用されました。 後者の時に、私たちは、私たちがまさしく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.

作者はKAME FAITHが翻訳者コードであると実装するのにかかわった人々に感謝したがっています、Keiichi ShimaとMunechika SUMIKAWAを含んでいて。

Hagino & Yamamoto            Informational                      [Page 9]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[9ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

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

インターネットイニシアティブ株式会社竹橋安田Bldg、6月-ichiro itojun HAGINOが研究所について研究する、3-13 神田西木町、千代田区、東京101-0054(日本)

   Phone: +81-3-5259-6350
   Fax:   +81-3-5259-6351
   EMail: itojun@iijlab.net

以下に電話をしてください。 +81-3-5259-6350 Fax: +81-3-5259-6351 メールしてください: 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

Kazu山本研究所、インターネットイニシアティブ株式会社竹橋安田ビルディング、3-13神田西木町、千代田区、東京101-0054、日本

   Phone: +81-3-5259-6350
   Fax:   +81-3-5259-6351
   EMail: kazu@iijlab.net

以下に電話をしてください。 +81-3-5259-6350 Fax: +81-3-5259-6351 メールしてください: kazu@iijlab.net

Hagino & Yamamoto            Informational                     [Page 10]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001

Haginoと山本情報[10ページ]のRFC3142IPv6からIPv4へのTransportは翻訳者2001年6月をリレーします。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Hagino & Yamamoto            Informational                     [Page 11]

Haginoと山本Informationalです。[11ページ]