この文書はRFC2767の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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」（ＢＩＳ）テクニックを使う
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.
ＩＰｖ４からＩＰｖ６への移行の特に最初の段階で、ＩＰｖ６アプリケー
ションの完全なセットを供給することは難しいです。このメモはＩＰセキュ
リティエリアで「Bump-in-the-Stack」と呼ばれるテクニックを使う二重ス
タックのホストの機構を提案します。メカニズムはホストが既存のＩＰｖ４
アプリケーションで他のＩＰｖ６ホストと通信を可能にします。
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]では多数のアプリケーションが利用可
能であるが、ＩＰｖ４と比較してＩＰｖ６[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.
このメモはＩＰセキュリティエリアで「Bump-in-the-Stack」[BUMP]と呼ばれ
るテクニックを使うデュアルスタックホストの機構を提案します。テクニッ
クはホストに、TCP/IPv4モジュールとネットワークカードドライバモジュー
ル間に流れているデータを詮索しＩＰｖ４をＩＰｖ６に変換するモジュール
を挿入し、自己翻訳します。他のＩＰｖ６ホストと通信する時、プールした
ＩＰｖ４アドレスが内部的にＩＰｖ６ホストに割り当てられます、しかしＩ
Ｐｖ４アドレスはそこから決して流出しません。さらに、割当が自動的にＤ
ＮＳプロトコルを使って実行されるので、ユーザーが目標ホストがＩＰｖ６
かどうか知る必要がありません。すなわち、これは既存のＩＰｖ４アプリケー
ションを使って他のＩＰｖ６ホストと通信することを許します；それでホス
トがＩＰｖ４とＩＰｖ６両方のアプリケーションを持つデュアルスタックホ
ストに思われます。それでデュアルスタックホストの領土を広げることがで
きます。さらに、役割が異なっているから、他の翻訳者と共存することがで
きます。
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モジュールとＩＰｖ４とＩＰｖ６両方のアドレスを必要とします。
このメモでの提案されたホストはＩＰｖ６アプリケーションの代わりに３つ
のモジュールを持ち、ＩＰｖ４アプリケーションを使っている他のＩＰｖ６
ホストと通信します。それらは翻訳者、拡張名前リゾルバとアドレスマッパ
です。
Figure 1 illustrates the structure of the host in which they are
installed.
図１がインストールされるホストの構造を例示します。
+----------------------------------------------------------+
| +----------------------------------------------------+ |
| | IPv4 applications | |
| | ＩＰｖ４アプリケーション | |
| +----------------------------------------------------+ |
| +----------------------------------------------------+ |
| | TCP/IPv4 | |
| | +-------------------------------------------+ |
| | | +-----------+ +---------+ +------------+ |
| | | | extension | | address | | translator | |
| | | | name | | mapper | | 翻訳者 | |
| | | | resolver | | アドレス| +------------+ |
| | | | 拡張 | | マッパ | +------------+ |
| | | | ネーム | | | | IPv6 | |
| | | | リゾルバ | | | | | |
| +--------+ +-----------+ +---------+ +------------+ |
| +----------------------------------------------------+ |
| | Network card drivers | |
| | ネットワークカードドライバ | |
| +----------------------------------------------------+ |
+----------------------------------------------------------+
+----------------------------------------------------------+
| Network cards |
| ネットワークカード |
+----------------------------------------------------------+
Figure. 1 Structure of the proposed dual stack host
図１．提案されたデュアルスタックホストの構造
2.1 Translator
2.1 翻訳者
It translates IPv4 into IPv6 and vice versa using the IP conversion
mechanism defined in [SIIT].
これは[SIIT]で定義されたＩＰ変換メカニズムを使いＩＰｖ４をＩＰｖ６に
変換します。
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.
ＩＰｖ４アプリケーションからＩＰｖ４パケットを受け取ると、翻訳者はＩ
Ｐｖ４パケットヘッダーをＩＰｖ６パケットヘッダーに変換し、（ＩＰｖ６
のヘッダー長さが一般にＩＰｖ４より２０バイトより大きいから）ＩＰｖ６
パケットを断片化し、ＩＰｖ６ネットワークに送ります。ＩＰｖ６ネットワー
クからＩＰｖ６パケットを受け取ると、パケットを断片化する必要がないこ
と以外、前の場合と対称的に動作します。
2.2 Extension Name Resolver
2.2 拡張ネームリゾルバ
It returns a "proper" answer in response to the IPv4 application's
request.
これはＩＰｖ４アプリケーションの要請に応えて「適切な」答えを返します。
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.
アプリケーションは通常目標ホスト名の「Ａ」レコードを解決するためにネー
ムサーバーに問合せを送ります。この拡張リゾルバはれ問合せを横取りし、
問合せはホスト名の「Ａ」と「AAAA」レコード両方を解決するための問合せ
を作り、サーバーに問合せを送ります。もし「Ａ」レコードが解決されるな
ら、アプリケーションに「Ａ」レコードをそのまま返します。この場合翻訳
者によるＩＰ変換の必要がありません。もし「AAAA」レコードだけが利用可
能なら、ＩＰｖ６アドレスに対応しているＩＰｖ４アドレスを割り当てるた
めにマッパーを求め、割り当てられたＩＰｖ４アドレスの「Ａ」レコードを
作り、そしてアプリケーションに「Ａ」レコードを返します。
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.
これはＩＰｖ４アドレスプールを保守します。プールは、例えば、プライベー
トのアドレス［PRIVATE］から成り立ちます。同じく、これはＩＰｖ４アドレ
スとＩＰｖ６アドレスの対から成り立つテーブルを維持します。
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:
リゾルバか翻訳者がＩＰｖ６アドレスに対応しているＩＰｖ４アドレスを割
り当てるように要請する時、マッパはプールからＩＰｖ４アドレスを選択し
て、返して、ダイナミックにテーブルの中に新しい項目を登録します。登録
は次の２つの場合に起こります：
(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」レコードだけを得てＩＰ
ｖ６アドレスのマッピング項目がない時。
(2) When the translator receives an IPv6 packet and there is not a
mapping entry for the IPv6 source address.
(2) 翻訳者がＩＰｖ６パケットを受信しＩＰｖ６ソースアドレスのマップ項
目がない時。
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.
ノート：ただ１つだけの例外があります。テーブルを初期化する時、マッパ
はテーブルの中に静的に１対の自分自身のＩＰｖ４アドレスとＩＰｖ６アド
レスを登録します。
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.
この章は「デュアルスタック」と呼ばれる提案されたデュアルスタックホス
トの動作を記述します、デュアルスタックホストはＩＰｖ４アプリケーショ
ンを使って「host6」と呼ばれるＩＰｖ６ホストと通信します。
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」レコードだけが
解決されます、それでリゾルバはＩＰｖ６アドレスに対応しているＩＰｖ４
アドレスを割り当てるためにマッパを求めます。
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.
ノート：ＩＰｖ４との通信の場合、「Ａ」レコードが解決され、リゾルバは
それをそのままアプリケーションに返します。後に示すＩＰ変換が必要があ
りません。
The mapper selects an IPv4 address out of the spool and returns it to
the resolver.
マッパはプールからＩＰｖ４アドレスを選択して、リゾルバに返します。
The resolver creates the 'A' record for the assigned IPv4 address and
returns it to the application.
リゾルバは割り当てられたＩＰｖ４アドレスの「Ａ」レコードを作って、ア
プリケーションに返します。
NOTE: See subsection 4.3 about the influence on other hosts caused by
an IPv4 address assigned here.
ノート：ここで割り当てられたＩＰｖ４アドレスによって起こされた他のホ
ストへの影響については４.３章を見てください。
The application sends an IPv4 packet to "host6."
アプリケーションはＩＰｖ４パケットを「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.
ＩＰｖ４パケットは翻訳者に届きます。翻訳者はＩＰｖ６パケットの中にＩ
Ｐｖ４パケットを翻訳しようとします、しかしどのようにＩＰｖ４宛先アド
レスとＩＰｖ４ソースアドレスを翻訳するべきか知りません。それで翻訳者
はそれのマップ項目を得るためにマッパに要求します。
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.
マッパはそのマップテーブルをチェックして、それぞれの項目を見つけだし
て、次に翻訳者にＩＰｖ６宛先アドレスとＩＰｖ６ソースアドレスを返します。
NOTE: The mapper will register its own IPv4 address and IPv6 address
into the table beforehand. See subsection 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.
翻訳者はＩＰｖ６パケットの中へのＩＰｖ４パケットを翻訳します、もし必
要であるならＩＰｖ６パケットを分解し、ＩＰｖ６ネットワークに送ります。
The IPv6 packet reaches "host6." Then "host6" sends a new IPv6 packet
to "dual stack."
ＩＰｖ６パケットは「host6」に届きます。 それから「host6」が新しいＩＰ
ｖ６パケットを「デュアルスタック」に送ります。
The IPv6 packet reaches the translator in "dual stack."
ＩＰｖ６パケットは「デュアルスタック」の翻訳者に届きます。
The translator gets mapping entries for the IPv6 destination address
and the IPv6 source address from the mapper in the same way as
before.
翻訳者は前と同じようにマッパからＩＰｖ６宛先アドレスとＩＰｖ６ソース
アドレスのマップ項目を得ます。
Then the translator translates the IPv6 packet into an IPv4 packet
and tosses it up to the application.
それから翻訳者はＩＰｖ４パケットの中にＩＰｖ６パケットを翻訳して、ア
プリケーションへ渡します。
The following diagram illustrates the action described above:
次の図は上に記述された行動を説明します：
"dual stack" "host6"
"デュアルスタック" "host6"
IPv4 TCP/ extension address translator IPv6 |
appli- IPv4 name mapper |
cation resolver |
ＩＰｖ４ 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.
| | | | ＩＰｖ６アドレスに対応する |
| | | | ＩＰｖ４アドレスを要求 |
| | | | | | |
| | | |<<Assign one IPv4 address.>> |
| | | |<<ＩＰｖ４アドレスを割り当て>>
| | | | | | |
| | |<--------| Reply with the IPv4 address.
| | | | ＩＰｖ４アドレスを返す |
| | | | | | |
| | |<<Create 'A' record for the IPv4 address.>>
| | |<<ＩＰｖ４アドレスのＡレコードを生成>> |
| | | | | | |
|<-------------| Reply with the 'A' record. | |
| | | Ａレコードを返す | |
| | | | | | |
Figure 2 Action of the originator (1/2)
図２ 発信者行動(1/2)
"dual stack" "host6"
"デュアルスタック" "host6"
IPv4 TCP/ extension address translator IPv6 |
appli- IPv4 name mapper |
cation resolver |
ＩＰｖ４ TCP/ 拡張 アドレス 翻訳者 IPv6 |
アプリケ IPv4 ネーム マッパ | | |
ーション | リゾルバ | | | |
| | | | | | |
<<Send an IPv4 packet to "host6".>>| | |
<<「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. |
| | | | | ＩＰｖ４パケット |
| | | | | | |
Figure 2 Action of the originator (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」レコード
を解決し、次にＩＰｖ６アドレスにＩＰｖ６パケットを送ります。
The IPv6 packet reaches the translator in "dual stack."
ＩＰｖ６パケットは「デュアルスタック」の翻訳者に届きます。
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.
翻訳者はＩＰｖ４パケットの中にＩＰｖ６パケットを翻訳しようとしますが、
どのようにＩＰｖ６宛先アドレスとＩＰｖ６ソースアドレスを翻訳するべき
か知りません。それで翻訳者はマップ項目を得るためにマッパに要求します。
The mapper checks its mapping table with each of them and finds a
mapping entry for the IPv6 destination address.
マッパはマップテーブルでそれぞれをチェックし、ＩＰｖ６宛先アドレスの
マップ項目を見つけます。
NOTE: The mapper will register its own IPv4 address and IPv6 address
into the table beforehand. See subsection 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.
けれどもＩＰｖ６ソースアドレスのマップ項目がないので、マッパはプール
からＩＰｖ４アドレスを選択して、翻訳者にＩＰｖ４宛先アドレスとＩＰｖ
４ソースアドレスを返します。
NOTE: See subsection 4.3 about the influence on other hosts caused by
an IPv4 address assigned here.
ノート：ここで割り当てられたＩＰｖ４アドレスによって起こされる他のホ
ストへの影響については４.３章を見てください。
The translator translates the IPv6 packet into an IPv4 packet and
tosses it up to the application.
翻訳者はＩＰｖ４パケットの中にＩＰｖ６パケットを翻訳して、そしてアプ
リケーションへ渡します。
The application sends a new IPv4 packet to "host6."
アプリケーションは新しいＩＰｖ４パケットを「host6」に送ります。
The following behavior is the same as that described in subsection
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 |
ＩＰｖ４ TCP/ 拡張 アドレス 翻訳者 IPv6 |
アプリケ IPv4 ネーム マッパ | | |
ーション | リゾルバ | | | |
| | | | | | |
<<Receive data from "host6".>> | | |
<<「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".>> | |
<<「host6」へデータの返送 >> | | |
| | | | | | |
|===============================>| An IPv4 packet. |
| | | | | ＩＰｖ４パケット |
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | <<ＩＰｖ４をＩＰｖ６へ翻訳>>
| | | | | | |
| | |An IPv6 packet. |====================>|
| | |ＩＰｖ６パケット | | |
| | | | | | |
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 ＩＰ変換
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]と共通で、ＩＰ変換がアプリケーションレイヤプロトコルに埋め込まれ
たＩＰアドレスを翻訳する必要があり、典型的にFTP［FTP］で問題になりま
す。そのため完全にすべのアプリケーションを翻訳することは難しいです。
4.2 IPv4 address spool and mapping table
4.2 ＩＰｖ４アドレスプールとマップテーブル。
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］から成り立ちます。
そのため大きいアドレス空間がプールで使うことができます。にもかかわら
ず、ホストが多数のＩＰｖ６ホストと通信し、マッパがマッピングテーブル
中のかつて登録された項目を開放しないならば、プールのＩＰｖ４アドレス
は枯渇し、ＩＰｖ６目標ホストに割り当てられることができません。この問
題を解くために、例えば、マップテーブルで最も古い項目を開放し、新しい
項目を作るためにＩＰｖ４アドレスを再利用することはマッパに望ましいで
す。
4.3 Internally assigned IPv4 addresses
4.3 内部で割り当てられたＩＰｖ４アドレス
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.
プールから内部でＩＰｖ６目標ホストに割り当てられるＩＰｖ４アドレスが
決してホストから流出し、他のホストに影響を与えてはなりません。
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.
ＩＰｖ６に修正してないアプリケーションがあるていどある特に最初の段階
でこのメカニズムは役立ち得ます。また、すべてのアプリケーションが修正
された後、なぜかある特定のアプリケーションをアップグレードすることが
できないユーザーに手を貸すことができます。それはホストに既存のＩＰｖ
４アプリケーションを使ってＩＰｖ６ホストと通信を許し、それらがＩＰｖ
６アプリケーションを持っていないとしても、ＩＰｖ４とＩＰｖ６両方のた
めに接続性を手に入れることができるということです。
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.
完全なＩＰｖ６スタックと共存できることに注意してください。このメカニ
ズムでＩＰｖ４ホストとＩＰｖ６ホストがＩＰｖ４アプリケーションを使っ
て通信でき、ＩＰｖ６ホストとＩＰｖ６アプリケーションで完全なＩＰｖ６
スタックで通信できます。
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.
これはホストに既存のＩＰｖ４アプリケーションを使ってＩＰｖ６ホストと
通信を許します、しかしＩＰｖ４オプションをＩＰｖ６に変換することが不
可能なので、ＩＰｖ４オプションを使うＩＰｖ４アプリケーションに適用で
きません。同様にＩＰｖ４の中に、フラグメントヘッダーとルーティングヘッ
ダー以外どんなＩＰｖ６オプションヘッダーも翻訳できません。それでオプ
ションヘッダーを持つＩＰｖ６内行きの通信は拒絶されるかもしれません。
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]と共通で、ＩＰ変換がアプリケーションレイヤプロトコルに埋め込まれ
たＩＰアドレスを翻訳する必要があり、典型的に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.
このメカニズムを使っているホストが、データがＩＰアドレスを伴うかもし
れないので、ネットワーク層の上でセキュリティを利用することは不可能か
もしれません。
Finally it can not combine with secure DNS since the extension name
resolver can not handle the protocol.
最終的にそれは、拡張名前リゾルバがプロトコルを処理することができない
ので、ＤＮＳセキュリティと結合できません。
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.
ホストは、このメカニズムで、ＩＰｖ４アプリケーションを使ってＩＰｖ４
ホストと通信する時、普通のＩＰｖ４通信のようなすべてのレイヤのセキュ
リティを利用することができます。同じく完全なＩＰｖ６スタックによって
ＩＰｖ６アプリケーションを使っているＩＰｖ６ホストと通信する時、普通
のＩＰｖ６通信のようなすべてのレイヤのセキュリティを利用することがで
きます。しかしながら、不幸にも、このメカニズムによってＩＰｖ４アプリ
ケーションを使ってＩＰｖ６ホストと通信する時、ネットワーク層の上のセ
キュリティを利用することができません。理由は、ＩＰアドレスが埋め込ま
れているプロトコルデータが暗号化される時や、プロトコルデータがキーと
してＩＰアドレスを使って暗号化される時に、このメカニズムがＩＰｖ６の
中にＩＰｖ４データを翻訳することは不可能で、逆もまた同様です。それ故
にＩＰｖ６ホストとの通信においてセキュリティを利用したいならアプリケー
ションをＩＰｖ６対応に修正することは大いに望ましいです。
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.
著作権（Ｃ）インターネット学会（２０００）。すべての権利は保留される。
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エディタ機能のための資金供給が現在インターネット学会によって供
給されます。