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)
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.
著作権（C）インターネット協会（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セキュリティエリアに呼ばれる技術を使用したデュアルスタックホストのメカニズムを提案しています。機構は、ホストは、既存の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-スタック」と呼ばれる技術を使用したデュアルスタックホストのメカニズム[BUMP]を提案しています。技術は、スヌープ・データは、ホストに、TCP / IPv4のモジュールとネットワークカードドライバモジュールとの間に流れると、IPv6およびその逆へのIPv4を翻訳モジュールを挿入し、それらを自己翻訳を行います。彼らは他の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].
それは、IPv6にIPv4および[SIIT]で定義されたIP変換機構を使用してその逆に変換します。
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パケットを受信した場合、それは、IPv6パケットヘッダにIPv4パケットのヘッダを変換する（IPv6のヘッダ長は、典型的にはIPv4よりも20バイト大きいため）、次にIPv6パケットを断片化し、IPv6ネットワークに送信します。 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」のレコードを返します。場合は、翻訳者によるIP変換の必要はありません。唯一の「AAAA」レコードが利用可能である場合、それはIPv6アドレスに対応するIPv4アドレスを割り当てるためのマッパーを要求し、その後、割り当てられたIPv4アドレスのための「」レコードを作成し、アプリケーションに 'レコードを返します。
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]を参照してください。
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. (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.
注：一つだけ例外があります。テーブルを初期化するとき、それは静的テーブルに、自身の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。」
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」レコードの両方を解決するために別のクエリを作成し、それをサーバに送信し、クエリをスヌープ。リゾルバは、IPv6アドレスに対応するIPv4アドレスを割り当てるためのマッパーを要求するので、この場合には、唯一の「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.
注：IPv4ホストとの通信の場合、「」レコードが解決されているように、次に、レゾルバは、アプリケーションに返します。後で示すように、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パケットにIPv4パケットを翻訳しようとしますが、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パケットを断片化したIPv6パケットにIPv4パケットを変換し、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.
その後、翻訳者は、IPv4パケットにIPv6パケットを変換し、アプリケーションにそれを投げます。
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.
翻訳者は、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アドレスと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.
翻訳者は、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"
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.
スプールは、例えば、プライベートアドレス[PRIVATE]から構成されています。だから、大規模なアドレス空間は、スプールのために使用することができます。それにもかかわらず、スプールにおけるIPv4アドレスは枯渇され、ホストが他のIPv6ホストの偉大な数と通信し、マッパーが一度マッピングテーブルに登録されたエントリを解放したことがない場合は、IPv6ターゲットホストに割り当てることはできません。マッパーは、マッピングテーブルの最も古いエントリを解放し、新しいエントリを作成するための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アドレスは、ホストから流出したことがない、などマイナス他のホストに影響を与えません。
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に修飾されていないいくつかのアプリケーションが残っ特に初期段階のユーザーのために有用であり得ます。そしてそれはまた、すべてのアプリケーションが変更された後、何らかの理由で彼らの特定のアプリケーションをアップグレードすることはできませんユーザーを支援することができます。その理由は、それがホストがIPv6ホストは既存のIPv4アプリケーションを使用して通信し、そして彼らは、結果として、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ホストとIPv6機構を介してIPv4アプリケーションを使用するホスト、また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ホストと通信することができますが、これは、IPv6にIPv4オプションを翻訳することは不可能であるため、任意の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 [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アドレスを使用して暗号化されたとき、それはIPv6およびその逆へのIPv4データを変換する機構のために不可能であることです。したがって、IPv6ホストとの通信のセキュリティを利用するためのIPv6に変更アプリケーションにアップグレードすることが非常に望ましいです。
[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[SIIT] Nordmarkと、E.、 "ステートレスIP / ICMPトランスレータ（SIIT）"、RFC 2765、2000年2月。
[IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPV4]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP]ポステル、J.とJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[NAT] Kjeld B. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[NAT]ドゥイツB.およびP.フランシス、 "IPネットワークアドレス変換（NAT）"、RFC 1631、1994年5月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.と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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G. J.およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月[PRIVATE]。
[TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[TRANS-MECH]ギリガン、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.
【BUMP] D.A.ワグナーとS.M. Bellovin氏、ネットワーク上の1996シンポジウム「MS-DOSシステム用スタックEncryptorはバンプ」と分散システムセキュリティ（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.
作者は感謝して大でWIDEプロジェクトのメンバー、山本和彦、村井純、Munechika澄川、渡辺謙、および貴久宮本、多くの有益な提案を認めます。
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
電話：+ 81-462-32-2121ファックス：+ 81-462-35-8324 Eメール：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
電話：+ 81-462-32-2121ファックス：+ 81-462-35-8324 Eメール：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
電話：+ 81-462-32-2121ファックス：+ 81-462-35-8324 Eメール：atarashi@ebina.hitachi.co.jp
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 Editor機能のための基金は現在、インターネット協会によって提供されます。