[要約] RFC 2767は、Bump-In-the-Stack（BIS）テクニックを使用したデュアルスタックホストに関するものです。このRFCの目的は、IPv4とIPv6の両方をサポートするホストの実装を容易にすることです。
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)
「バンプインザスタック」テクニック（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.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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ホストと通信できます。
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 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ホストに内部的に割り当てられますが、IPv4アドレスはそれらから流出することはありません。さらに、割り当てはDNSプロトコルを使用して自動的に実行されるため、ユーザーはターゲットホストがIPv6のホストであるかどうかを知る必要はありません。つまり、これにより、既存のIPv4アプリケーションを使用して他のIPv6ホストと通信できます。したがって、それらは、IPv4とIPv6の両方にアプリケーションを備えたデュアルスタックホストのようです。そのため、デュアルスタックホストの領域を拡大できます。さらに、彼らの役割が異なるため、彼らは他の翻訳者と共存することができます。
This memo uses the words defined in [IPV4], [IPV6], and [TRANS-MECH].
このメモは、[IPv4]、[IPv6]、および[Trans-Mech]で定義された単語を使用します。
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 |
+----------------------------------------------------------+
Figure. 1 Structure of the proposed dual stack host
形。提案されているデュアルスタックホストの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のヘッダーよりも大きいため）。IPv6ネットワークからIPv6パケットを受信する場合、パケットを断片化する必要がないことを除いて、以前のケースと対称的に機能します。
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」レコードのみが利用可能な場合、Mapperに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アルグ（アプリケーションレイヤーゲートウェイ）のアクションに似ています。[NAT-PT]も参照してください。
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:
ResolverまたはTranslatorがIPv6アドレスに対応するIPv4アドレスを割り当てるように要求すると、Spoolから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ソースアドレスのマッピングエントリがない場合。
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つだけです。テーブルを初期化すると、独自のIPv4アドレスのペアとIPv6アドレスをテーブルに静的に登録します。
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ホストと通信します。
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パケットが翻訳者に届きます。翻訳者は、IPv4パケットをIPv6パケットに変換しようとしますが、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.
注：Mapperは、事前に独自の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パケットに翻訳し、アプリケーションに投げます。
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. | |
| | | | | | |
Figure 2 Action of the originator (1/2)
図2オリジネーターのアクション（1/2）
"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. |
| | | | | | |
Figure 2 Action of the originator (2/2)
図2オリジネーターのアクション（2/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ソースアドレスを翻訳する方法を知りません。そのため、翻訳者はマッパーにマッピングエントリを提供するよう要求します。
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.
注：Mapperは、事前に独自の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.
注：ここに割り当てられたIPv4アドレスによって引き起こされる他のホストへの影響については、サブセクション4.3を参照してください。
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で説明した動作と同じです。
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. |===========|========>|
| | | | | | |
Figure 3 Action of the recipient
図3受信者のアクション
This section considers some issues of the proposed dual stack hosts.
このセクションでは、提案されているデュアルスタックホストのいくつかの問題を検討します。
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アドレスを変換する必要があります。そのため、そのようなすべてのアプリケーションを完全に翻訳することは困難です。
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.
たとえば、スプールはプライベートアドレス[プライベート]で構成されています。そのため、スプールには大きなアドレススペースを使用できます。それにもかかわらず、スプールのIPv4アドレスは使い果たされ、IPv6ターゲットホストに割り当てることはできません。ホストが他の多くのIPv6ホストと通信し、マッパーがマッピングテーブルに1回登録されたエントリをフリーしない場合。たとえば、問題を解決するには、マッパーがマッピングテーブルの最古のエントリを解放し、新しいエントリを作成するために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アドレスは、SpoolからIPv6ターゲットホストを内部的に割り当てられ、ホストから流出することはないため、他のホストに悪影響を及ぼさないでください。
This section considers applicability and limitations of the proposed dual stack hosts.
このセクションでは、提案されたデュアルスタックホストの適用性と制限を検討します。
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ホストと通信することもできます。
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オプションをIPv4に変換することは不可能なため、任意のIPv4オプションを使用するIPv4アプリケーションには適用できません。同様に、フラグメントヘッダーとルーティングヘッダーを除き、IPv6オプションヘッダーをIPv4に変換することは不可能です。したがって、オプションヘッダーを持つ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 [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と結合することはできません。
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に変更されたアプリケーションにアップグレードすることが非常に望ましいです。
[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[SIIT] Nordmark、E。、「Stateless IP/ICMP Translator（SIIT）」、RFC 2765、2000年2月。
[IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[NAT] Kjeld B. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[Nat] Kjeld B.およびP. Francis、「The IP Network Address Translator（Nat）」、RFC 1631、1994年5月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。J.およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[Trans-Mech] Gilligan、R。およびE. Nordmark、「IPv6ホストとルーターの遷移メカニズム」、RFC 1933、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 Systemsのスタック暗号化業者のバンプ」、1996年のネットワークおよび分散システムセキュリティ（SNDSS'96）の手続き。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[Nat-Pt] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス変換 - プロトコル翻訳（NAT-PT）」、RFC 2766、2000年2月。
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.
著者は、ワイドプロジェクトのメンバーである山本和口、ムレイコ、ムレイカ川、ミュンチカ川川、渡辺ケン、宮本大hisoの多くの有益な提案に感謝しています。
Kazuaki TSUCHIYA Enterprise Server Division, Hitachi, Ltd. 810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN
カズアキ・ツキヤ・エンタープライズ・サーバー部門、日立、株式会社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
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
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
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。