この文書はRFC2767の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                       K. Tsuchiya
Requests for Comments: 2767                                  H. Higuchi
Category: Informational                                     Y. Atarashi
                                                                Hitachi
                                                          February 2000


     Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
   二重のスタックホストで「Bump-In-the-Stack」(BIS)テクニックを使う

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 (2000).  All Rights Reserved.

Abstract
概要

   In the especially initial stage of the transition from IPv4 to IPv6,
   it is hard to provide a complete set of IPv6 applications.  This memo
   proposes a mechanism of dual stack hosts using the technique called
   "Bump-in-the-Stack" in the IP security area. The mechanism allows the
   hosts to communicate with other IPv6 hosts using existing IPv4
   applications.
   IPv4からIPv6への移行の特に最初の段階で、IPv6アプリケー
   ションの完全なセットを供給することは難しいです。このメモはIPセキュ
   リティエリアで「Bump-in-the-Stack」と呼ばれるテクニックを使う二重ス
   タックのホストの機構を提案します。メカニズムはホストが既存のIPv4
   アプリケーションで他のIPv6ホストと通信を可能にします。

1. Introduction
1. はじめに

   RFC1933 [TRANS-MECH] specifies transition mechanisms, including dual
   stack and tunneling, for the initial stage. Hosts and routers with
   the transition mechanisms are also developed. But there are few
   applications for IPv6 [IPV6] as compared with IPv4 [IPV4] in which a
   great number of applications are available. In order to advance the
   transition smoothly, it is highly desirable to make the availability
   of IPv6 applications increase to the same level as IPv4.
   Unfortunately, however, this is expected to take a very long time.
   RFC1933[TRANS-MECH]が二重のスタックやトンネルを含む最初の段階の移行メ
   カニズムを指定します。移行メカニズムを持つホストとルーターが同じく開
   発されます。しかし、IPv4[IPV4]では多数のアプリケーションが利用可
   能であるが、IPv4と比較してIPv6[IPV6]ではきわめて少数のアプリ
   ケーションしか利用できない。順調な移行を推進するために、アプリケーショ
   ンがIPv4と同じぐらいIPv6アプリケーションが利用可能なことが望
   ましいです。しかしながら不幸にも、これは非常に長い時間がかかると予想
   されます。

   This memo proposes a mechanism of dual stack hosts using the
   technique called "Bump-in-the-Stack" [BUMP] in the IP security area.
   The technique inserts modules, which snoop data flowing between a
   TCP/IPv4 module and network card driver modules and translate IPv4
   into IPv6 and vice versa, into the hosts, and makes them self-
   translators. When they communicate with the other IPv6 hosts, pooled
   IPv4 addresses are assigned to the IPv6 hosts internally, but the
   IPv4 addresses never flow out from them. Moreover, since the
   assignment is automatically carried out using DNS protocol, users do
   not need to know whether target hosts are IPv6 ones. That is, this
   allows them to communicate with other IPv6 hosts using existing IPv4
   applications; thus it seems as if they were dual stack hosts with
   applications for both IPv4 and IPv6. So they can expand the territory
   of dual stack hosts.  Furthermore they can co-exist with other
   translators because their roles are different.
   このメモはIPセキュリティエリアで「Bump-in-the-Stack」[BUMP]と呼ばれ
   るテクニックを使うデュアルスタックホストの機構を提案します。テクニッ
   クはホストに、TCP/IPv4モジュールとネットワークカードドライバモジュー
   ル間に流れているデータを詮索しIPv4をIPv6に変換するモジュール
   を挿入し、自己翻訳します。他のIPv6ホストと通信する時、プールした
   IPv4アドレスが内部的にIPv6ホストに割り当てられます、しかしI
   Pv4アドレスはそこから決して流出しません。さらに、割当が自動的にD
   NSプロトコルを使って実行されるので、ユーザーが目標ホストがIPv6
   かどうか知る必要がありません。すなわち、これは既存のIPv4アプリケー
   ションを使って他のIPv6ホストと通信することを許します;それでホス
   トがIPv4とIPv6両方のアプリケーションを持つデュアルスタックホ
   ストに思われます。それでデュアルスタックホストの領土を広げることがで
   きます。さらに、役割が異なっているから、他の翻訳者と共存することがで
   きます。

   This memo uses the words defined in [IPV4], [IPV6], and [TRANS-MECH].
   このメモは[IPV4]と[IPV6]と[TRANS-MECH]で定義された言葉を使います。

2. Components
2. 構成要素

   Dual stack hosts defined in RFC1933 [TRANS-MECH] need applications,
   TCP/IP modules and addresses for both IPv4 and IPv6. The proposed
   hosts in this memo have 3 modules instead of IPv6 applications, and
   communicate with other IPv6 hosts using IPv4 applications. They are a
   translator, an extension name resolver and an address mapper.
   二重のスタックホストがRFC1933[TRANS-MECH]で定義され、アプリケーション
   とTCP/IPモジュールとIPv4とIPv6両方のアドレスを必要とします。
   このメモでの提案されたホストはIPv6アプリケーションの代わりに3つ
   のモジュールを持ち、IPv4アプリケーションを使っている他のIPv6
   ホストと通信します。それらは翻訳者、拡張名前リゾルバとアドレスマッパ
   です。

   Figure 1 illustrates the structure of the host in which they are
   installed.
   図1がインストールされるホストの構造を例示します。
         +----------------------------------------------------------+
         |  +----------------------------------------------------+  |
         |  | IPv4 applications                                  |  |
         |  | IPv4アプリケーション                           |  |
         |  +----------------------------------------------------+  |
         |  +----------------------------------------------------+  |
         |  | TCP/IPv4                                           |  |
         |  |        +-------------------------------------------+  |
         |  |        |  +-----------+  +---------+  +------------+  |
         |  |        |  | extension |  | address |  | translator |  |
         |  |        |  | name      |  | mapper  |  | 翻訳者     |  |
         |  |        |  | resolver  |  | アドレス|  +------------+  |
         |  |        |  | 拡張      |  | マッパ  |  +------------+  |
         |  |        |  | ネーム    |  |         |  | IPv6       |  |
         |  |        |  | リゾルバ  |  |         |  |            |  |
         |  +--------+  +-----------+  +---------+  +------------+  |
         |  +----------------------------------------------------+  |
         |  | Network card drivers                               |  |
         |  | ネットワークカードドライバ                         |  |
         |  +----------------------------------------------------+  |
         +----------------------------------------------------------+
         +----------------------------------------------------------+
         |    Network cards                                         |
         |    ネットワークカード                                    |
         +----------------------------------------------------------+

               Figure. 1 Structure of the proposed dual stack host
               図1.提案されたデュアルスタックホストの構造

2.1 Translator
2.1 翻訳者

   It translates IPv4 into IPv6 and vice versa using the IP conversion
   mechanism defined in [SIIT].
   これは[SIIT]で定義されたIP変換メカニズムを使いIPv4をIPv6に
   変換します。

   When receiving IPv4 packets from IPv4 applications, it converts IPv4
   packet headers into IPv6 packet headers, then fragments the IPv6
   packets (because header length of IPv6 is typically 20 bytes larger
   than that of IPv4), and sends them to IPv6 networks. When receiving
   IPv6 packets from the IPv6 networks, it works symmetrically to the
   previous case, except that there is no need to fragment the packets.
   IPv4アプリケーションからIPv4パケットを受け取ると、翻訳者はI
   Pv4パケットヘッダーをIPv6パケットヘッダーに変換し、(IPv6
   のヘッダー長さが一般にIPv4より20バイトより大きいから)IPv6
   パケットを断片化し、IPv6ネットワークに送ります。IPv6ネットワー
   クからIPv6パケットを受け取ると、パケットを断片化する必要がないこ
   と以外、前の場合と対称的に動作します。

2.2 Extension Name Resolver
2.2 拡張ネームリゾルバ

   It returns a "proper" answer in response to the IPv4 application's
   request.
   これはIPv4アプリケーションの要請に応えて「適切な」答えを返します。

   The application typically sends a query to a name server to resolve
   'A' records for the target host name. It snoops the query, then
   creates another query to resolve both 'A' and 'AAAA' records for the
   host name, and sends the query to the server. If the 'A' record is
   resolved, it returns the 'A' record to the application as is. In the
   case, there is no need for the IP conversion by the translator.  If
   only the 'AAAA' record is available, it requests the mapper to assign
   an IPv4 address corresponding to the IPv6 address, then creates the
   'A' record for the assigned IPv4 address, and returns the 'A' record
   to the application.
   アプリケーションは通常目標ホスト名の「A」レコードを解決するためにネー
   ムサーバーに問合せを送ります。この拡張リゾルバはれ問合せを横取りし、
   問合せはホスト名の「A」と「AAAA」レコード両方を解決するための問合せ
   を作り、サーバーに問合せを送ります。もし「A」レコードが解決されるな
   ら、アプリケーションに「A」レコードをそのまま返します。この場合翻訳
   者によるIP変換の必要がありません。もし「AAAA」レコードだけが利用可
   能なら、IPv6アドレスに対応しているIPv4アドレスを割り当てるた
   めにマッパーを求め、割り当てられたIPv4アドレスの「A」レコードを
   作り、そしてアプリケーションに「A」レコードを返します。

   NOTE: This action is similar to that of the DNS ALG (Application
   Layer Gateway) used in [NAT-PT]. See also [NAT-PT].
   ノート:この行動は[NAT-PT]で使われたDNS ALG(アプリケーションレイヤ
   ゲートウェイ)に類似しています。[NAT-PT]を参照してください。

2.3 Address mapper
2.3 アドレスマッパ

   It maintains an IPv4 address spool. The spool, for example, consists
   of private addresses [PRIVATE]. Also, it maintains a table which
   consists of pairs of an IPv4 address and an IPv6 address.
   これはIPv4アドレスプールを保守します。プールは、例えば、プライベー
   トのアドレス[PRIVATE]から成り立ちます。同じく、これはIPv4アドレ
   スとIPv6アドレスの対から成り立つテーブルを維持します。

   When the resolver or the translator requests it to assign an IPv4
   address corresponding to an IPv6 address, it selects and returns an
   IPv4 address out of the spool, and registers a new entry into the
   table dynamically. The registration occurs in the following 2 cases:
   リゾルバか翻訳者がIPv6アドレスに対応しているIPv4アドレスを割
   り当てるように要請する時、マッパはプールからIPv4アドレスを選択し
   て、返して、ダイナミックにテーブルの中に新しい項目を登録します。登録
   は次の2つの場合に起こります:

   (1) When the resolver gets only an 'AAAA' record for the target host
       name and there is not a mapping entry for the IPv6 address.
   (1) リゾルバが目標ホスト名に対してただ「AAAA」レコードだけを得てIP
       v6アドレスのマッピング項目がない時。
   (2) When the translator receives an IPv6 packet and there is not a
       mapping entry for the IPv6 source address.
   (2) 翻訳者がIPv6パケットを受信しIPv6ソースアドレスのマップ項
       目がない時。

   NOTE: There is only one exception. When initializing the table, it
   registers a pair of its own IPv4 address and IPv6 address into the
   table statically.
   ノート:ただ1つだけの例外があります。テーブルを初期化する時、マッパ
   はテーブルの中に静的に1対の自分自身のIPv4アドレスとIPv6アド
   レスを登録します。

3. Action Examples
3. 動作例

   This section describes action of the proposed dual stack host called
   "dual stack," which communicates with an IPv6 host called "host6"
   using an IPv4 application.
   この章は「デュアルスタック」と呼ばれる提案されたデュアルスタックホス
   トの動作を記述します、デュアルスタックホストはIPv4アプリケーショ
   ンを使って「host6」と呼ばれるIPv6ホストと通信します。

3.1 Originator behavior
3.1 発信者の行動

   This subsection describes the originator behavior of "dual stack."
   The communication is triggered by "dual stack."
   この章は「デュアルスタック」の発信者行動を記述します。
   通信は「デュアルスタック」によって引き起こされます。

   The application sends a query to its name server to resolve 'A'
   records for "host6."
   アプリケーションは「host6」の「A」レコードを解決するために名前サー
   バーに問合せを送ります。

   The resolver snoops the query, then creates another query to resolve
   both 'A' and 'AAAA' records for the host name, and sends it to the
   server. In this case, only the 'AAAA' record is resolved, so the
   resolver requests the mapper to assign an IPv4 address corresponding
   to the IPv6 address.
   リゾルバがその問合せを横取りし、「ホストへのA」と「AAAA」の両方
   の問合せを作りサーバーに送ります。この例では、「AAAA」レコードだけが
   解決されます、それでリゾルバはIPv6アドレスに対応しているIPv4
   アドレスを割り当てるためにマッパを求めます。

   NOTE: In the case of communication with an IPv4 host, the 'A' record
   is resolved and then the resolver returns it to the application as
   is. There is no need for the IP conversion as shown later.
   ノート:IPv4との通信の場合、「A」レコードが解決され、リゾルバは
   それをそのままアプリケーションに返します。後に示すIP変換が必要があ
   りません。

   The mapper selects an IPv4 address out of the spool and returns it to
   the resolver.
   マッパはプールからIPv4アドレスを選択して、リゾルバに返します。

   The resolver creates the 'A' record for the assigned IPv4 address and
   returns it to the application.
   リゾルバは割り当てられたIPv4アドレスの「A」レコードを作って、ア
   プリケーションに返します。

   NOTE: See subsection 4.3 about the influence on other hosts caused by
   an IPv4 address assigned here.
   ノート:ここで割り当てられたIPv4アドレスによって起こされた他のホ
   ストへの影響については4.3章を見てください。

   The application sends an IPv4 packet to "host6."
   アプリケーションはIPv4パケットを「host6」に送ります。

   The IPv4 packet reaches the translator. The translator tries to
   translate the IPv4 packet into an IPv6 packet but does not know how
   to translate the IPv4 destination address and the IPv4 source
   address. So the translator requests the mapper to provide mapping
   entries for them.
   IPv4パケットは翻訳者に届きます。翻訳者はIPv6パケットの中にI
   Pv4パケットを翻訳しようとします、しかしどのようにIPv4宛先アド
   レスとIPv4ソースアドレスを翻訳するべきか知りません。それで翻訳者
   はそれのマップ項目を得るためにマッパに要求します。

   The mapper checks its mapping table and finds entries for each of
   them, and then returns the IPv6 destination address and the IPv6
   source address to the translator.
   マッパはそのマップテーブルをチェックして、それぞれの項目を見つけだし
   て、次に翻訳者にIPv6宛先アドレスとIPv6ソースアドレスを返します。

   NOTE: The mapper will register its own IPv4 address and IPv6 address
   into the table beforehand. See subsection 2.3.
   ノート:マッパはテーブルの中にあらかじめ自分自身のIPv4アドレスと
   IPv6アドレスを登録するでしょう。2.3章を見てください。

   The translator translates the IPv4 packet into an IPv6 packet then
   fragments the IPv6 packet if necessary and sends it to an IPv6
   network.
   翻訳者はIPv6パケットの中へのIPv4パケットを翻訳します、もし必
   要であるならIPv6パケットを分解し、IPv6ネットワークに送ります。

   The IPv6 packet reaches "host6." Then "host6" sends a new IPv6 packet
   to "dual stack."
   IPv6パケットは「host6」に届きます。 それから「host6」が新しいIP
   v6パケットを「デュアルスタック」に送ります。

   The IPv6 packet reaches the translator in "dual stack."
   IPv6パケットは「デュアルスタック」の翻訳者に届きます。

   The translator gets mapping entries for the IPv6 destination address
   and the IPv6 source address from the mapper in the same way as
   before.
   翻訳者は前と同じようにマッパからIPv6宛先アドレスとIPv6ソース
   アドレスのマップ項目を得ます。

   Then the translator translates the IPv6 packet into an IPv4 packet
   and tosses it up to the application.
   それから翻訳者はIPv4パケットの中にIPv6パケットを翻訳して、ア
   プリケーションへ渡します。

   The following diagram illustrates the action described above:
   次の図は上に記述された行動を説明します:


   "dual stack"                                            "host6"
   "デュアルスタック"                                      "host6"
   IPv4    TCP/  extension  address  translator  IPv6       |
   appli-  IPv4  name       mapper                          |
   cation        resolver                                   |
  IPv4 TCP/  拡張       アドレス 翻訳者      IPv6       |
  アプリケ IPv4  ネーム     マッパ    |           |         |
  ーション  |    リゾルバ     |       |           |         |
     |      |       |         |       |           |         |
   <<Resolve an IPv4 address for "host6".>>       |         |
   <<「host6」のIPv4アドレスを解決する >>         |         |
     |      |       |         |       |           |         | Name
     |------------->|  Query of 'A' records for "host6".    | Server
     |      |       |  「host6」の'A'レコードを問い合わせる | ネーム
     |      |       |         |       |           |         | サーバ
     |      |       |------------------------------------------->|
     |      |       |  Query of 'A' records and 'AAAA' for "host6"
     |      |       |  「host6」の'A'と'AAAA'レコードを問い合わせる
     |      |       |         |       |           |         |    |
     |      |       |<-------------------------------------------|
     |      |       |  Reply only with 'AAAA' record.       |
     |      |       |  'AAAA'レコードだけが返ってくる       |
     |      |       |         |       |           |         |
     |      |       |<<Only 'AAAA' record is resolved.>>    |
     |      |       |<<'AAAA'レコードだけが解決       >>    |
     |      |       |         |       |           |         |
     |      |       |-------->|  Request one IPv4 address   |
     |      |       |         |  corresponding to the IPv6 address.
     |      |       |         |  IPv6アドレスに対応する |
     |      |       |         |  IPv4アドレスを要求     |
     |      |       |         |       |           |         |
     |      |       |         |<<Assign one IPv4 address.>> |
     |      |       |         |<<IPv4アドレスを割り当て>>
     |      |       |         |       |           |         |
     |      |       |<--------|  Reply with the IPv4 address.
     |      |       |         |  IPv4アドレスを返す     |
     |      |       |         |       |           |         |
     |      |       |<<Create 'A' record for the IPv4 address.>>
     |      |       |<<IPv4アドレスのAレコードを生成>> |
     |      |       |         |       |           |         |
     |<-------------|  Reply with the 'A' record. |         |
     |      |       |  Aレコードを返す           |         |
     |      |       |         |       |           |         |

                  Figure 2 Action of the originator (1/2)
                  図2 発信者行動(1/2)


   "dual stack"                                            "host6"
   "デュアルスタック"                                      "host6"
   IPv4    TCP/  extension  address  translator  IPv6       |
   appli-  IPv4  name       mapper                          |
   cation        resolver                                   |
  IPv4 TCP/  拡張       アドレス 翻訳者      IPv6       |
  アプリケ IPv4  ネーム     マッパ    |           |         |
  ーション  |    リゾルバ     |       |           |         |
     |      |       |         |       |           |         |
   <<Send an IPv4 packet to "host6".>>|           |         |
   <<「host6」へIPv4パケットを送る>>          |         |
     |      |       |         |       |           |         |
     |===============================>|  An IPv4 packet.    |
     |      |       |         |       |  IPv4パケット   |
     |      |       |         |       |           |         |
     |      |       |         |<------|  Request IPv6 addresses
     |      |       |         |       |  corresponding to the IPv4
     |      |       |         |       |  addresses.         |
     |      |       |         |       |  IPv4アドレスに対応する
     |      |       |         |       |  IPv6アドレスを求る
     |      |       |         |       |           |         |
     |      |       |         |------>|  Reply with the IPv6|
     |      |       |         |       |  addresses.         |
     |      |       |         |       |  IPv6アドレスを返す
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv4 into IPv6.>>
     |      |       |         |       |<<IPv4をIPv6へ翻訳する>>
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |====================>|
     |      |       |IPv6パケット |           |         |
     |      |       |         |       |           |         |
     |      |       |         |     <<Reply an IPv6 packet to
     |      |       |         |       "dual stack".>>       |
     |      |       |         |     <<「デュアルスタック」へIPv6
     |      |       |         |       パケットを返す>>      |
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |<====================|
     |      |       |IPv6パケット |           |         |
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv6 into IPv4.>>
     |      |       |         |       |<<IPv6をIPv4へ翻訳する>>
     |      |       |         |       |           |         |
     |<===============================|  An IPv4 packet.    |
     |      |       |         |       | IPv4パケット    |
     |      |       |         |       |           |         |

                  Figure 2 Action of the originator (2/2)
                  図2 発信者行動(2/2)

3.2 Recipient behavior
3.2 受信者の振る舞い

   This subsection describes the recipient behavior of "dual stack."
   The communication is triggered by "host6."
   この章はは「デュアルスタック」の受信行動を記述します。通信は「host6」
   によって引き起こされます。

   "host6" resolves the 'AAAA' record for "dual stack" through its name
   server, and then sends an IPv6 packet to the IPv6 address.
   「host6」がネームサーバを通して「デュアルスタック」の「AAAA」レコード
   を解決し、次にIPv6アドレスにIPv6パケットを送ります。

   The IPv6 packet reaches the translator in "dual stack."
   IPv6パケットは「デュアルスタック」の翻訳者に届きます。

   The translator tries to translate the IPv6 packet into an IPv4 packet
   but does not know how to translate the IPv6 destination address and
   the IPv6 source address. So the translator requests the mapper to
   provide mapping entries for them.
   翻訳者はIPv4パケットの中にIPv6パケットを翻訳しようとしますが、
   どのようにIPv6宛先アドレスとIPv6ソースアドレスを翻訳するべき
   か知りません。それで翻訳者はマップ項目を得るためにマッパに要求します。

   The mapper checks its mapping table with each of them and finds a
   mapping entry for the IPv6 destination address.
   マッパはマップテーブルでそれぞれをチェックし、IPv6宛先アドレスの
   マップ項目を見つけます。

   NOTE: The mapper will register its own IPv4 address and IPv6 address
   into the table beforehand. See subsection 2.3.
   メモ:マッパはテーブルの中にあらかじめそれ自身のIPv4アドレスとI
   Pv6アドレスを登録します。2.3章を見てください。

   But there is not a mapping entry for the IPv6 source address, so the
   mapper selects an IPv4 address out of the spool for it, and then
   returns the IPv4 destination address and the IPv4 source address to
   the translator.
   けれどもIPv6ソースアドレスのマップ項目がないので、マッパはプール
   からIPv4アドレスを選択して、翻訳者にIPv4宛先アドレスとIPv
   4ソースアドレスを返します。

   NOTE: See subsection 4.3 about the influence on other hosts caused by
   an IPv4 address assigned here.
   ノート:ここで割り当てられたIPv4アドレスによって起こされる他のホ
   ストへの影響については4.3章を見てください。

   The translator translates the IPv6 packet into an IPv4 packet and
   tosses it up to the application.
   翻訳者はIPv4パケットの中にIPv6パケットを翻訳して、そしてアプ
   リケーションへ渡します。

   The application sends a new IPv4 packet to "host6."
   アプリケーションは新しいIPv4パケットを「host6」に送ります。

   The following behavior is the same as that described in subsection
   3.1.
   次の行動は3.1章で記述したのと同じです。

   The following diagram illustrates the action described above:
   次の図は上記行動を説明します:。

   "dual stack"                                            "host6"
   "デュアルスタック"                                      "host6"
   IPv4    TCP/  extension  address  translator  IPv6       |
   appli-  IPv4  name       mapper                          |
   cation        resolver                                   |
  IPv4 TCP/  拡張       アドレス 翻訳者      IPv6       |
  アプリケ IPv4  ネーム     マッパ    |           |         |
  ーション  |    リゾルバ     |       |           |         |
     |      |       |         |       |           |         |
   <<Receive data from "host6".>>     |           |         |
   <<「host6」からデータの受信 >>     |           |         |
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |<====================|
     |      |       |IPv6パケット |           |         |
     |      |       |         |       |           |         |
     |      |       |         |<------|  Request IPv4 addresses
     |      |       |         |       |  corresponding to the IPv6
     |      |       |         |       |  addresses.         |
     |      |       |         |       |  IPv6アドレスに対応する
     |      |       |         |       |  IPv4アドレスの要求
     |      |       |         |       |           |         |
     |      |       |         |------>|  Reply with the IPv4|
     |      |       |         |       |  addresses.         |
     |      |       |         |       |  IPv4アドレスを返す
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv6 into IPv4.>>
     |      |       |         |       |<<IPv6をIPv4へ翻訳>>
     |      |       |         |       |           |         |
     |<===============================|  An IPv4 packet.    |
     |      |       |         |       |  IPv4パケット   |
     |      |       |         |       |           |         |
   <<Reply an IPv4 packet to "host6".>>           |         |
   <<「host6」へデータの返送 >>       |           |         |
     |      |       |         |       |           |         |
     |===============================>|  An IPv4 packet.    |
     |      |       |         |       |  IPv4パケット   |
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv4 into IPv6.>>
     |      |       |         |       | <<IPv4をIPv6へ翻訳>>
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |====================>|
     |      |       |IPv6パケット |           |         |
     |      |       |         |       |           |         |

                     Figure 3 Action of the recipient

4. Considerations
4. 考察

   This section considers some issues of the proposed dual stack hosts.
   この章は若干の提案されたデュアルスタックホストの問題を考察します。

4.1 IP conversion
4.1 IP変換

   In common with NAT [NAT], IP conversion needs to translate IP
   addresses embedded in application layer protocols, which are
   typically found in FTP [FTP]. So it is hard to translate all such
   applications completely.
   [NAT]と共通で、IP変換がアプリケーションレイヤプロトコルに埋め込まれ
   たIPアドレスを翻訳する必要があり、典型的にFTP[FTP]で問題になりま
   す。そのため完全にすべのアプリケーションを翻訳することは難しいです。

4.2 IPv4 address spool and mapping table
4.2 IPv4アドレスプールとマップテーブル。

   The spool, for example, consists of private addresses [PRIVATE]. So a
   large address space can be used for the spool. Nonetheless, IPv4
   addresses in the spool will be exhausted and cannot be assigned to
   IPv6 target hosts, if the host communicates with a great number of
   other IPv6 hosts and the mapper never frees entries registered into
   the mapping table once. To solve the problem, for example, it is
   desirable for the mapper to free the oldest entry in the mapping
   table and re-use the IPv4 address for creating a new entry.
   プールは、例えば、プライベートのアドレス[PRIVATE]から成り立ちます。
   そのため大きいアドレス空間がプールで使うことができます。にもかかわら
   ず、ホストが多数のIPv6ホストと通信し、マッパがマッピングテーブル
   中のかつて登録された項目を開放しないならば、プールのIPv4アドレス
   は枯渇し、IPv6目標ホストに割り当てられることができません。この問
   題を解くために、例えば、マップテーブルで最も古い項目を開放し、新しい
   項目を作るためにIPv4アドレスを再利用することはマッパに望ましいで
   す。

4.3 Internally assigned IPv4 addresses
4.3 内部で割り当てられたIPv4アドレス

   IPv4 addresses, which are internally assigned to IPv6 target hosts
   out of the spool, never flow out from the host, and so do not
   negatively affect other hosts.
   プールから内部でIPv6目標ホストに割り当てられるIPv4アドレスが
   決してホストから流出し、他のホストに影響を与えてはなりません。

5. Applicability and Limitations
5. 適用性と限界

   This section considers applicability and limitations of the proposed
   dual stack hosts.
   この章は提案されたデュアルスタックホストの適用性と限界を考慮します。

5.1 Applicability
5.1 適用性

   The mechanism can be useful for users in the especially initial stage
   where some applications not modified into IPv6 remain. And it can
   also help users who cannot upgrade their certain applications for
   some reason after all applications have been modified. The reason is
   that it allows hosts to communicate with IPv6 hosts using existing
   IPv4 applications, and that they can get connectivity for both IPv4
   and IPv6 even if they do not have IPv6 applications as a result.
   IPv6に修正してないアプリケーションがあるていどある特に最初の段階
   でこのメカニズムは役立ち得ます。また、すべてのアプリケーションが修正
   された後、なぜかある特定のアプリケーションをアップグレードすることが
   できないユーザーに手を貸すことができます。それはホストに既存のIPv
   4アプリケーションを使ってIPv6ホストと通信を許し、それらがIPv
   6アプリケーションを持っていないとしても、IPv4とIPv6両方のた
   めに接続性を手に入れることができるということです。

   Note that it can also work in conjunction with a complete IPv6 stack.
   They can communicate with both IPv4 hosts and IPv6 hosts using IPv4
   applications via the mechanism, and can also communicate with IPv6
   hosts using IPv6 applications via the complete IPv6 stack.
   完全なIPv6スタックと共存できることに注意してください。このメカニ
   ズムでIPv4ホストとIPv6ホストがIPv4アプリケーションを使っ
   て通信でき、IPv6ホストとIPv6アプリケーションで完全なIPv6
   スタックで通信できます。

5.2 Limitations
5.2 限界

   The mechanism is valid only for unicast communication, but invalid
   for multicast communication. Multicast communication needs another
   mechanism.
   このメカニズムはユニキャスト通信に有効ですが、マルチキャスト通信で無
   効です。マルチキャスト通信には他のメカニズムを必要とします。

   It allows hosts to communicate with IPv6 hosts using existing IPv4
   applications, but this can not be applied to IPv4 applications which
   use any IPv4 option since it is impossible to translate IPv4 options
   into IPv6. Similarly it is impossible to translate any IPv6 option
   headers into IPv4, except for fragment headers and routing headers.
   So IPv6 inbound communication having the option headers may be
   rejected.
   これはホストに既存のIPv4アプリケーションを使ってIPv6ホストと
   通信を許します、しかしIPv4オプションをIPv6に変換することが不
   可能なので、IPv4オプションを使うIPv4アプリケーションに適用で
   きません。同様にIPv4の中に、フラグメントヘッダーとルーティングヘッ
   ダー以外どんなIPv6オプションヘッダーも翻訳できません。それでオプ
   ションヘッダーを持つIPv6内行きの通信は拒絶されるかもしれません。

   In common with NAT [NAT], IP conversion needs to translate IP
   addresses embedded in application layer protocols, which are
   typically found in FTP [FTP]. So it is hard to translate all such
   applications completely.
   [NAT]と共通で、IP変換がアプリケーションレイヤプロトコルに埋め込まれ
   たIPアドレスを翻訳する必要があり、典型的にFTP[FTP]で問題になりま
   す。そのため完全にすべのアプリケーションを翻訳することは難しいです。

   It may be impossible that the hosts using the mechanism utilize the
   security above network layer since the data may carry IP addresses.
   このメカニズムを使っているホストが、データがIPアドレスを伴うかもし
   れないので、ネットワーク層の上でセキュリティを利用することは不可能か
   もしれません。

   Finally it can not combine with secure DNS since the extension name
   resolver can not handle the protocol.
   最終的にそれは、拡張名前リゾルバがプロトコルを処理することができない
   ので、DNSセキュリティと結合できません。

6. Security Considerations
6. セキュリティの考察

   This section considers security of the proposed dual stack hosts.
   この章は提案されたデュアルスタックホストのセキュリティを考慮します。

   The hosts can utilize the security of all layers like ordinary IPv4
   communication when they communicate with IPv4 hosts using IPv4
   applications via the mechanism. Likewise they can utilize the
   security of all layers like ordinary IPv6 communication when they
   communicate with IPv6 hosts using IPv6 applications via the complete
   IPv6 stack. However, unfortunately, they can not utilize the security
   above network layer when they communicate with IPv6 hosts using IPv4
   applications via the mechanism. The reason is that when the protocol
   data with which IP addresses are embedded is encrypted, or when the
   protocol data is encrypted using IP addresses as keys, it is
   impossible for the mechanism to translate the IPv4 data into IPv6 and
   vice versa. Therefore it is highly desirable to upgrade to the
   applications modified into IPv6 for utilizing the security at
   communication with IPv6 hosts.
   ホストは、このメカニズムで、IPv4アプリケーションを使ってIPv4
   ホストと通信する時、普通のIPv4通信のようなすべてのレイヤのセキュ
   リティを利用することができます。同じく完全なIPv6スタックによって
   IPv6アプリケーションを使っているIPv6ホストと通信する時、普通
   のIPv6通信のようなすべてのレイヤのセキュリティを利用することがで
   きます。しかしながら、不幸にも、このメカニズムによってIPv4アプリ
   ケーションを使ってIPv6ホストと通信する時、ネットワーク層の上のセ
   キュリティを利用することができません。理由は、IPアドレスが埋め込ま
   れているプロトコルデータが暗号化される時や、プロトコルデータがキーと
   してIPアドレスを使って暗号化される時に、このメカニズムがIPv6の
   中にIPv4データを翻訳することは不可能で、逆もまた同様です。それ故
   にIPv6ホストとの通信においてセキュリティを利用したいならアプリケー
   ションをIPv6対応に修正することは大いに望ましいです。

7. References
7. 参考文献

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

   [IPV4]       Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.

   [FTP]        Postel, J. and J. Reynolds, "File Transfer Protocol",
                STD 9, RFC 959, October 1985.

   [NAT]        Kjeld B. and P. Francis, "The IP Network Address
                Translator (NAT)", RFC 1631, May 1994.

   [IPV6]       Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, December 1998.

   [PRIVATE]    Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
                J. and E. Lear, "Address Allocation for Private
                Internets", BCP 5, RFC 1918, February 1996.

   [TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
                IPv6 Hosts and Routers", RFC 1933, April 1996.

   [BUMP]       D.A. Wagner and S.M. Bellovin, "A Bump in the Stack
                Encryptor for MS-DOS Systems", The 1996 Symposium on
                Network and Distributed Systems Security (SNDSS'96)
                Proceedings.

   [NAT-PT]     Tsirtsis, G. and P. Srisuresh, "Network Address
                Translation - Protocol Translation (NAT-PT)", RFC 2766,
                February 2000.

8. Acknowledgements
8. 謝辞

   The authors gratefully acknowledge the many helpful suggestions of
   the members of the WIDE Project, Kazuhiko YAMAMOTO, Jun MURAI,
   Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO, at large.
   著者は、WIDEプロジェクトメンバー、Kazuhiko YAMAMOTOとJun MURAIと
   Munechika SUMIKAWAとKen WATANABEとTakahisa  MIYAMOTOの多くの助けにな
   る提案を認め感謝します。

9. Authors' Addresses
9. 著者のアドレス

   Kazuaki TSUCHIYA
   Enterprise Server Division, Hitachi, Ltd.
   810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN

   Phone: +81-462-32-2121
   Fax:   +81-462-35-8324
   EMail: tsuchi@ebina.hitachi.co.jp

   Hidemitsu HIGUCHI
   Enterprise Server Division, Hitachi, Ltd.
   810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN

   Phone: +81-462-32-2121
   Fax:   +81-462-35-8324
   EMail: h-higuti@ebina.hitachi.co.jp

   Yoshifumi ATARASHI
   Enterprise Server Division, Hitachi, Ltd.
   810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN

   Phone: +81-462-32-2121
   Fax:   +81-462-35-8324
   EMail: atarashi@ebina.hitachi.co.jp

10.  Full Copyright Statement
10.  著作権表示全文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.
   著作権(C)インターネット学会(2000)。すべての権利は保留される。

   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エディタ機能のための資金供給が現在インターネット学会によって供
   給されます。

Japanese translation by Ishida So