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