RFC2767 日本語訳

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

コメントを求めるワーキンググループK.Tsuchiya要求をネットワークでつないでください: 2767時間Higuchiカテゴリ: 情報のY.Atarashi日立2000年2月

     Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)

「スタックでの隆起」のテクニックを使用しているデュアルスタックホスト(BIS)

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

Copyright(C)インターネット協会(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セキュリティ領域の「スタックでの隆起」と呼ばれるテクニックを使用することでデュアルスタックホストのメカニズムを提案します。 メカニズムで、ホストは、既存の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]と比べてわずかしかIPv6[IPV6]においていません。 スムーズに変遷を進めるために、IPv6アプリケーションの有用性をIPv4と同じレベルに増加させるのは、非常に望ましいです。 残念ながら、しかしながら、これが非常に長い時かかると予想されます。

   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

このメモは、IPセキュリティ領域で「スタックでの隆起」[BUMP]と呼ばれるテクニックを使用することでデュアルスタックホストのメカニズムを提案します。 テクニックは、モジュールをホストに挿入して、彼らを自己翻訳者にします。(モジュールは、TCP/IPv4モジュールとネットワークカードドライバーモジュールの間を流れるデータについて詮索して、逆もまた同様にIPv4をIPv6に翻訳します)。 彼らが他のIPv6ホストとコミュニケートするとき、プールされたIPv4アドレスは内部的にIPv6ホストに割り当てられますが、IPv4は彼らからの外で流れを決して扱いません。 そのうえ、課題がDNSプロトコルを使用することで自動的に行われるので、ユーザは行われます。

Tsuchiya, et al.             Informational                      [Page 1]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[1ページ]のRFC2767デュアルスタックホスト

   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.

目標ホストが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]で定義されたデュアルスタックホストはIPv4とIPv6の両方のためのアプリケーション、TCP/IPモジュール、およびアドレスを必要とします。 このメモによる提案されたホストは、IPv6アプリケーションの代わりに3つのモジュールを持って、IPv4アプリケーションを使用することで他のIPv6ホストとコミュニケートします。 それらは、翻訳者と、拡大ネーム・リゾルバとアドレスマッパです。

   Figure 1 illustrates the structure of the host in which they are
   installed.

図1はそれらがインストールされるホストの構造を例証します。

         +----------------------------------------------------------+
         |  +----------------------------------------------------+  |
         |  | IPv4 applications                                  |  |
         |  +----------------------------------------------------+  |
         |  +----------------------------------------------------+  |
         |  | TCP/IPv4                                           |  |
         |  |        +-------------------------------------------+  |
         |  |        |  +-----------+  +---------+  +------------+  |
         |  |        |  | extension |  | address |  | translator |  |
         |  |        |  | name      |  | mapper  |  +------------+  |
         |  |        |  | resolver  |  |         |  +------------+  |
         |  |        |  |           |  |         |  | IPv6       |  |
         |  +--------+  +-----------+  +---------+  +------------+  |
         |  +----------------------------------------------------+  |
         |  | Network card drivers                               |  |
         |  +----------------------------------------------------+  |
         +----------------------------------------------------------+
         +----------------------------------------------------------+
         |    Network cards                                         |
         +----------------------------------------------------------+

+----------------------------------------------------------+ | +----------------------------------------------------+ | | | IPv4アプリケーション| | | +----------------------------------------------------+ | | +----------------------------------------------------+ | | | TCP/IPv4| | | | +-------------------------------------------+ | | | | +-----------+ +---------+ +------------+ | | | | | 拡大| | アドレス| | 翻訳者| | | | | | 名前| | マッパ| +------------+ | | | | | レゾルバ| | | +------------+ | | | | | | | | | IPv6| | | +--------+ +-----------+ +---------+ +------------+ | | +----------------------------------------------------+ | | | ネットワークカードドライバー| | | +----------------------------------------------------+ | +----------------------------------------------------------+ +----------------------------------------------------------+ | ネットワークカード| +----------------------------------------------------------+

               Figure. 1 Structure of the proposed dual stack host

図。 1 提案されたデュアルスタックホストの構造

Tsuchiya, et al.             Informational                      [Page 2]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[2ページ]のRFC2767デュアルスタックホスト

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パケットを受けるとき、それは、IPv4パケットのヘッダーをIPv6パケットのヘッダーに変換して、次に、IPv6パケット(IPv6のヘッダ長がIPv4のものより通常20バイト大きいので)を断片化して、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'と'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]に使用されるDNS ALG(アプリケーションLayerゲートウェイ)のものと同様です。 また、[太平洋標準時のNAT]を見てください。

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アドレススプールを維持します。 例えば、スプールはプライベート・アドレス[兵士]から成ります。 また、それは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.
   (2) When the translator receives an IPv6 packet and there is not a
       mapping entry for the IPv6 source address.

(1) レゾルバが'AAAA'だけ、を得るときには目標ホスト名のために記録してください。そうすれば、IPv6アドレスのためのマッピングエントリーがありません。 (2) 翻訳者がIPv6パケットを受けて、IPv6ソースアドレスのためのマッピングエントリーがないとき。

Tsuchiya, et al.             Informational                      [Page 3]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[3ページ]のRFC2767デュアルスタックホスト

   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"のための記録を決議するために質問をネームサーバに送ります。

   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.

レゾルバは、質問を詮索して、次に、ホスト名のための両方の'''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.

以下に注意してください。 他のホストへの影響に関する小区分4.3がここに割り当てられたIPv4アドレスによって引き起こされるのを見てください。

   The application sends an IPv4 packet to "host6."

アプリケーションは"host6"にIPv4パケットを送ります。

   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パケットは翻訳者に届きます。 翻訳者は、IPv4パケットをIPv6パケットに翻訳しようとしますが、IPv4送付先アドレスとIPv4ソースアドレスを翻訳する方法を知りません。 それで、翻訳者は、それらのためにエントリーを写像しながら提供するようマッパに要求します。

Tsuchiya, et al.             Informational                      [Page 4]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[4ページ]のRFC2767デュアルスタックホスト

   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.

翻訳者はその時、IPv4パケットをIPv6パケットに翻訳します。必要なら、IPv6パケットを断片化して、IPv6ネットワークにそれを送ります。

   The IPv6 packet reaches "host6." Then "host6" sends a new IPv6 packet
   to "dual stack."

IPv6パケットは"host6"に達します。 そして、「host6"は新しいIPv6パケットを「デュアルスタック」に送ります」。

   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.

次に、翻訳者は、IPv6パケットをIPv4パケットに翻訳して、それをアプリケーションまで投げます。

Tsuchiya, et al.             Informational                      [Page 5]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[5ページ]のRFC2767デュアルスタックホスト

   The following diagram illustrates the action described above:

以下のダイヤグラムは以下の上で説明された動作を例証します。

   "dual stack"                                            "host6"
   IPv4    TCP/  extension  address  translator  IPv6
   appli-  IPv4  name       mapper
   cation        resolver
     |      |       |         |       |           |         |
   <<Resolve an IPv4 address for "host6".>>       |         |
     |      |       |         |       |           |         |
     |------|------>|  Query of 'A' records for "host6".    | Name
     |      |       |         |       |           |         | Server
     |      |       |---------|-------|-----------|---------|--->|
     |      |       |  Query of 'A' records and 'AAAA' for "host6"
     |      |       |         |       |           |         |    |
     |      |       |<--------|-------|-----------|---------|----|
     |      |       |  Reply only with 'AAAA' record.       |
     |      |       |         |       |           |         |
     |      |       |<<Only 'AAAA' record is resolved.>>    |
     |      |       |         |       |           |         |
     |      |       |-------->|  Request one IPv4 address   |
     |      |       |         |  corresponding to the IPv6 address.
     |      |       |         |       |           |         |
     |      |       |         |<<Assign one IPv4 address.>> |
     |      |       |         |       |           |         |
     |      |       |<--------|  Reply with the IPv4 address.
     |      |       |         |       |           |         |
     |      |       |<<Create 'A' record for the IPv4 address.>>
     |      |       |         |       |           |         |
     |<-----|-------|  Reply with the 'A' record. |         |
     |      |       |         |       |           |         |

「デュアルスタック」「host6" IPv4 TCP/拡大アドレス変換機構のIPv6 appli- IPv4名前マッパ陽イオンレゾルバ」| | | | | | | <<は"host6""のためのIPv4アドレスを決議します。>>|| | | | | | | | |、-、-、-、-、--、|、-、-、-、-、--、>| "host6""のための記録の質問。 | 名前| | | | | | | サーバ| | |---------|-------|-----------|---------|--->| | | | '"host6""のための''記録とAAAA'の質問| | | | | | | | | | |<--------|-------|-----------|---------|----| | | | 単に'AAAA'記録で、返答してください。 | | | | | | | | | | |'AAAA'だけ、が記録する<<は決議されています。>>|| | | | | | | | | |、-、-、-、-、-、-、--、>| 要求1IPv4アドレス| | | | | IPv6アドレスに対応しています。 | | | | | | | | | | |<<は1つのIPv4アドレスを割り当てます。>>|| | | | | | | | | | <、-、-、-、-、-、-、--、| IPv4アドレスで、返答してください。 | | | | | | | | | |<<はIPv4アドレスのための記録を作成します。>>|| | | | | | | <、-、-、-、--、|、-、-、-、-、-、--、| 'A'記録で、返答してください。 | | | | | | | | |

                  Figure 2 Action of the originator (1/2)

図2 創始者のAction(1/2)

Tsuchiya, et al.             Informational                      [Page 6]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[6ページ]のRFC2767デュアルスタックホスト

   "dual stack"                                           "host6"
   IPv4    TCP/  extension  address  translator  IPv6
   appli-  IPv4  name       mapper
   cation        resolver
     |      |       |         |       |           |         |
   <<Send an IPv4 packet to "host6".>>|           |         |
     |      |       |         |       |           |         |
     |======|=======|=========|======>|  An IPv4 packet.    |
     |      |       |         |       |           |         |
     |      |       |         |<------|  Request IPv6 addresses
     |      |       |         |       |  corresponding to the IPv4
     |      |       |         |       |  addresses.         |
     |      |       |         |       |           |         |
     |      |       |         |------>|  Reply with the IPv6|
     |      |       |         |       |  addresses.         |
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv4 into IPv6.>>
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |===========|========>|
     |      |       |         |       |           |         |
     |      |       |         |     <<Reply an IPv6 packet to
     |      |       |         |       "dual stack".>>       |
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |<==========|=========|
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv6 into IPv4.>>
     |      |       |         |       |           |         |
     |<=====|=======|=========|=======|  An IPv4 packet.    |
     |      |       |         |       |           |         |

「デュアルスタック」「host6" IPv4 TCP/拡大アドレス変換機構のIPv6 appli- IPv4名前マッパ陽イオンレゾルバ」| | | | | | | <<がIPv4パケットを送る、「host6">>|、」| | | | | | | | | |======|=======|=========|======>| IPv4パケット。 | | | | | | | | | | | | <、-、-、-、-、--、| IPv6アドレスを要求してください。| | | | | IPv4に対応しています。| | | | | アドレス。 | | | | | | | | | | | |、-、-、-、-、--、>| IPv6と共に返答してください。| | | | | | アドレス。 | | | | | | | | | | | | |<<はIPv4をIPv6に翻訳します。>>|| | | | | | | | |IPv6パケット。 |===========|========>|、|、|、|、|、|、|、|、|、|、|、| <<回答、IPv6パケット| | | | 「デュアルスタック。」>>|| | | | | | | | | |IPv6パケット。 |<=====|=========| | | | | | | | | | | | |<<はIPv6をIPv4に翻訳します。>>|| | | | | | |<===|=======|=========|=======| IPv4パケット。 | | | | | | | |

                  Figure 2 Action of the originator (2/2)

図2 創始者のAction(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.

翻訳者は、IPv6パケットをIPv4パケットに翻訳しようとしますが、IPv6送付先アドレスとIPv6ソースアドレスを翻訳する方法を知りません。 それで、翻訳者は、それらのためにエントリーを写像しながら提供するようマッパに要求します。

Tsuchiya, et al.             Informational                      [Page 7]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[7ページ]のRFC2767デュアルスタックホスト

   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アドレスとIPv6アドレスをテーブルに登録するでしょう。 小区分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送付先アドレスとIPv4ソースアドレスを翻訳者に返します。

   NOTE: See subsection 4.3 about the influence on other hosts caused by
   an IPv4 address assigned here.

以下に注意してください。 他のホストへの影響に関する小区分4.3がここに割り当てられたIPv4アドレスによって引き起こされるのを見てください。

   The translator translates the IPv6 packet into an IPv4 packet and
   tosses it up to the application.

翻訳者は、IPv6パケットをIPv4パケットに翻訳して、それをアプリケーションまで投げます。

   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で説明されたそれと同じです。

Tsuchiya, et al.             Informational                      [Page 8]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[8ページ]のRFC2767デュアルスタックホスト

   The following diagram illustrates the action described above:

以下のダイヤグラムは以下の上で説明された動作を例証します。

   "dual stack"                                           "host6"
   IPv4    TCP/  extension  address  translator  IPv6
   appli-  IPv4  name       mapper
   cation        resolver
     |      |       |         |       |           |         |
   <<Receive data from "host6".>>     |           |         |
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |<==========|=========|
     |      |       |         |       |           |         |
     |      |       |         |<------|  Request IPv4 addresses
     |      |       |         |       |  corresponding to the IPv6
     |      |       |         |       |  addresses.         |
     |      |       |         |       |           |         |
     |      |       |         |------>|  Reply with the IPv4|
     |      |       |         |       |  addresses.         |
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv6 into IPv4.>>
     |      |       |         |       |           |         |
     |<=====|=======|=========|=======|  An IPv4 packet.    |
     |      |       |         |       |           |         |
   <<Reply an IPv4 packet to "host6".>>           |         |
     |      |       |         |       |           |         |
     |======|=======|=========|======>|  An IPv4 packet.    |
     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv4 into IPv6.>>
     |      |       |         |       |           |         |
     |      |       |An IPv6 packet.  |===========|========>|
     |      |       |         |       |           |         |

「デュアルスタック」「host6" IPv4 TCP/拡大アドレス変換機構のIPv6 appli- IPv4名前マッパ陽イオンレゾルバ」| | | | | | | "host6""からの<<受信データ。>>|| | | | | | | | | | | |IPv6パケット。 |<=====|=========| | | | | | | | | | | | <、-、-、-、-、--、| IPv4アドレスを要求してください。| | | | | IPv6に対応しています。| | | | | アドレス。 | | | | | | | | | | | |、-、-、-、-、--、>| IPv4と共に返答してください。| | | | | | アドレス。 | | | | | | | | | | | | |<<はIPv6をIPv4に翻訳します。>>|| | | | | | |<===|=======|=========|=======| IPv4パケット。 | | | | | | | | <<は返答します。"host6""へのIPv4パケット。>>|| | | | | | | | |======|=======|=========|======>| IPv4パケット。 | | | | | | | | | | | | |<<はIPv4をIPv6に翻訳します。>>|| | | | | | | | |IPv6パケット。 |===========|========>|、|、|、|、|、|、|、|

                     Figure 3 Action of the recipient

図3 受取人のAction

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[NAT]と共用して、IP変換は、FTP[FTP]で通常見つけられる応用層プロトコルに埋め込まれたIPアドレスを翻訳する必要があります。 それで、そのようなすべてのアプリケーションを完全に翻訳しにくいです。

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

例えば、スプールはプライベート・アドレス[兵士]から成ります。 それで、スプールに大きいアドレス空間を使用できます。 それにもかかわらず、IPv4

Tsuchiya, et al.             Informational                      [Page 9]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[9ページ]のRFC2767デュアルスタックホスト

   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.

スプールのアドレスを消耗して、IPv6目標ホストに割り当てることができません、ホストがかなりの数の他の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.

IPv4アドレス(スプールからIPv6目標ホストに内部的に割り当てられる)は、ホストからの外を決して流れないので、否定的に他のホストに影響しません。

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に変更されなかったいくつかのアプリケーションが残っている特に初期の段階のユーザの役に立つ場合があります。 そして、また、それはすべてのアプリケーションが変更されたある理由で後に彼らのあるアプリケーションをアップグレードさせることができないユーザを助けることができます。 理由はホストがそれで既存のIPv4アプリケーションを使用することでIPv6ホストとコミュニケートできて、その結果IPv6アプリケーションがなくても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アプリケーションを使用するIPv4ホストとIPv6ホストの両方で交信できて、また、完全な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アプリケーションにこれを適用できません。 同様に、断片ヘッダーとルーティングヘッダーを除いて、どんなIPv6オプションヘッダーもIPv4に翻訳するのは不可能です。 それで、オプションヘッダーがあるIPv6の本国行きのコミュニケーションは拒絶されるかもしれません。

Tsuchiya, et al.             Informational                     [Page 10]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[10ページ]のRFC2767デュアルスタックホスト

   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[NAT]と共用して、IP変換は、FTP[FTP]で通常見つけられる応用層プロトコルに埋め込まれたIPアドレスを翻訳する必要があります。 それで、そのようなすべてのアプリケーションを完全に翻訳しにくいです。

   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アドレスを使用することで暗号化されているとき、メカニズムが逆もまた同様にIPv4データをIPv6に翻訳するのが、不可能であるということです。 したがって、IPv6ホストとのコミュニケーションにおけるセキュリティを利用するようにIPv6に変更されたアプリケーションにアップグレードするのは非常に望ましいです。

7. References

7. 参照

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

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

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

[IPV4] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

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

[FTP] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。

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

[NAT]Kjeld B.とP.フランシス、「IPネットワークアドレス変換機構(NAT)」(RFC1631)は1994がそうするかもしれません。

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

[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

Tsuchiya, et al.             Informational                     [Page 11]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[11ページ]のRFC2767デュアルスタックホスト

   [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.

[兵士]Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.J.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。

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

[移-MECH] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC1933、1996年4月。

   [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.

[隆起]D.A.ワグナーとS.M.Bellovin、「MS-DOSシステムのためのスタック暗号化する人における隆起」、1996年のネットワークと分散システムセキュリティ(SNDSS96年)議事に関するシンポジウム。

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

[太平洋標準時のNAT]TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べる」、RFC2766、2000年2月。

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 Project、Kazuhiko山本、Jun村井、Munechika SUMIKAWA、ケン・渡辺、およびTakahisaミヤモトのメンバーの多くの役立つ提案を承諾します、詳細に。

9. Authors' Addresses

9. 作者のアドレス

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

和明TSUCHIYAエンタープライズサーバ区画、日立810Shimoimaizumi、海老名市、神奈川県、243-0435日本

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

以下に電話をしてください。 +81-462-32-2121 Fax: +81-462-35-8324 メールしてください: tsuchi@ebina.hitachi.co.jp

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

Hidemitsu HIGUCHIエンタープライズサーバ区画、日立810Shimoimaizumi、海老名市、神奈川県、243-0435日本

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

以下に電話をしてください。 +81-462-32-2121 Fax: +81-462-35-8324 メールしてください: h-higuti@ebina.hitachi.co.jp

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

Yoshifumi ATARASHIエンタープライズサーバ区画、日立810Shimoimaizumi、海老名市、神奈川県、243-0435日本

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

以下に電話をしてください。 +81-462-32-2121 Fax: +81-462-35-8324 メールしてください: atarashi@ebina.hitachi.co.jp

Tsuchiya, et al.             Informational                     [Page 12]

RFC 2767               Dual Stack Hosts using BIS          February 2000

Tsuchiya、他 2000年2月にBISを使用する情報[12ページ]のRFC2767デュアルスタックホスト

10.  Full Copyright Statement

10. 完全な著作権宣言文

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

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

Tsuchiya, et al.             Informational                     [Page 13]

Tsuchiya、他 情報[13ページ]