Internet Engineering Task Force (IETF) B. Huang
Request for Comments: 6535 H. Deng
Obsoletes: 2767, 3338 China Mobile
Category: Standards Track T. Savolainen
ISSN: 2070-1721 Nokia
February 2012
Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
Abstract
抽象
Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338.
バンプ・イン・ザ・ホスト（BIH）がIPv6のみのピアと通信するためにNATを介して動作し、IPv4専用アプリケーションのクラスを可能にするホストベースのIPv4からIPv6へのプロトコル変換機構です。アプリケーションが実行されているホストがIPv6のみまたはデュアルスタックアクセスネットワークに接続することができます。 BIHは、IPv6を隠し、IPv4のみのアプリケーションは、彼らがIPv4アドレスのローカル合成することで、IPv4の仲間と話をしていると思わせます。この文書は、RFC 2767およびRFC 3338を廃止します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6535.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6535で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Acknowledgment of Previous Work ............................5
2. Components of the Bump-in-the-Host ..............................6
2.1. Function Mapper ............................................8
2.2. Protocol Translator ........................................8
2.3. Extension Name Resolver ....................................8
2.3.1. Special Exclusion Sets for A and AAAA Records .......9
2.3.2. DNSSEC Support .....................................10
2.3.3. Reverse DNS Lookup .................................10
2.3.4. DNS Caches and Synthetic IPv4 Addresses ............10
2.4. Address Mapper ............................................11
3. Behavior and Network Examples ..................................11
4. Considerations .................................................15
4.1. Socket API Conversion .....................................15
4.2. Socket Bindings ...........................................15
4.3. ICMP Message Handling .....................................15
4.4. IPv4 Address Pool and Mapping Table .......................15
4.5. Multi-Interface ...........................................17
4.6. Multicast .................................................17
5. Application-Level Gateway Requirements Considerations ..........17
6. Security Considerations ........................................17
6.1. Implications on End-to-End Security .......................18
6.2. Filtering .................................................18
6.3. Attacks on BIH ............................................18
6.4. DNS Considerations ........................................19
7. Changes since RFC 2767 and RFC 3338 ............................19
8. Acknowledgments ................................................20
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................21
Appendix A. API List Intercepted by BIH ...........................23
This document describes Bump-in-the-Host (BIH), a successor and combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the-API (BIA) [RFC3338] technologies, which enable IPv4-only legacy applications to communicate with IPv6-only servers by synthesizing IPv4 addresses from AAAA records. Section 7 describes the reasons for making RFC 2767 and RFC 3338 obsolete.
この文書は、バンプ・イン・ホスト（BIH）、後継とバンプ・イン・スタック（BIS）[RFC2767]の組み合わせとバンプ・イン・API（BIA）[RFC3338]の技術を記載していますIPv4のは、AAAAレコードからアドレスを合成することによって、IPv6専用サーバーと通信するIPv4専用のレガシーアプリケーションを有効にします。第7節は、RFC 2767およびRFC 3338は廃止することの理由を説明しています。
The supported class of applications includes those that use DNS for IP address resolution and that do not embed IP address literals in application-protocol payloads. This includes legacy client-server applications using the DNS that are agnostic to the IP address family used by the destination and that are able to do NAT traversal. The synthetic IPv4 addresses shown to applications are taken from the private address pool of [RFC1918] in order to ensure that possible NAT traversal techniques will be initiated.
アプリケーションのサポートクラスは、IPアドレスの解決にDNSを使用し、そのアプリケーションプロトコルペイロードにIPアドレスリテラルを埋め込むないものを含んでいます。これは、宛先が使用するIPアドレスファミリにとらわれないで、それがNATトラバーサルを行うことができますDNSを使用して、従来のクライアントサーバアプリケーションが含まれています。アプリケーションに示される合成のIPv4アドレスが可能なNATトラバーサル技術が開始されることを確実にするために、[RFC1918]のプライベートアドレスプールから取得されます。
The IETF recommends using solutions based on dual stack or tunneling for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180].
IETFは、IPv6への移行のためのデュアルスタックやトンネリングに基づくソリューションを使用することをお勧めします、特に、二重プロトコル変換を利用し展開しないことを推奨します。 NAT64と一緒BIHの使用は[RFC6180]をお勧めしません。
BIH includes two major implementation alternatives: a protocol translator between the IPv4 and the IPv6 stacks of a host or an API translator between the IPv4 socket API module and the TCP/IP module. Essentially, IPv4 is translated into IPv6 at the socket API layer or at the IP layer, the former of which is the recommended implementation alternative.
IPv4とホストまたはIPv4ソケットAPIモジュールおよびTCP / IPモジュール間のAPIトランスレータのIPv6のスタック間のプロトコルトランスレータ：BIHは、2つの主要な実装の選択肢が含まれています。基本的に、IPv4のは、ソケットAPI層で、またはIPレイヤでのIPv6に変換され、前者はその推奨実装の代替手段です。
When BIH is implemented at the socket API layer, the translator intercepts IPv4 socket API function calls and invokes corresponding IPv6 socket API function calls to communicate with IPv6 hosts.
BIHがソケットAPI層で実装されている場合、トランスレータは、IPv4ソケットAPI関数呼び出しをインターセプトし、対応するIPv6のソケットAPI関数は、IPv6ホストと通信するコール呼び出します。
When BIH is implemented at the network layer, the IPv4 packets are intercepted and converted to IPv6 using the IP conversion mechanism defined in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. The protocol translation has the same benefits and drawbacks as SIIT.
BIHは、ネットワーク層で実装されている場合、IPv4パケットを傍受およびステートレスIP / ICMP翻訳アルゴリズム（SIIT）[RFC6145]で定義されたIP変換機構を用いたIPv6に変換されます。プロトコル変換はSIITと同じ利点と欠点があります。
The location of the BIH refers to the location of the protocol translation function. The location of the IPv4 address and DNS A record synthesis function is orthogonal to the location of the protocol translation and may or may not happen at the same location.
BIHの位置は、プロトコル変換機能の位置を指します。 IPv4アドレスの位置とは、記録合成関数は、プロトコル翻訳の場所に直交し、又は同じ場所で発生してもしなくてもよいDNS。
BIH can be used whenever an IPv4-only application needs to communicate with an IPv6-only server, independently of the address families supported by the access network. Hence, the access network can be IPv6-only or dual-stack capable.
BIHは、IPv4専用アプリケーションは、独立してアクセスネットワークによってサポートされているアドレスファミリーの、IPv6専用サーバと通信する必要があるときはいつでも使用することができます。したがって、アクセスネットワークは、IPv6専用またはデュアルスタック対応することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書では[RFC2119]で説明されるように解釈されるべきです。
This document uses terms defined in [RFC2460] and [RFC4213].
この文書では、[RFC2460]と[RFC4213]で定義された用語を使用しています。
DNS synthesis
DNSの合成
The process of creating an A record containing a synthetic IPv4 address.
合成IPv4アドレスを含むAレコードを作成するプロセス。
Real IPv4 address
実IPv4アドレス
An IPv4 address of a remote node a host has learned, for example, from DNS response to an A query.
ホストがクエリにDNS応答から、例えば、学習したリモートノードのIPv4アドレス。
Real IPv6 address
実際のIPv6アドレス
An IPv6 address of a remote node a host has learned, for example, from DNS response to a AAAA query.
リモートノードのIPv6アドレスは、ホストはAAAAクエリにDNS応答から、例えば、学習しています。
Synthetic IPv4 address
合成IPv4アドレス
An IPv4 address that has meaning only inside a host and that is used to provide IPv4 representation of remote node's real IPv6 address.
ホスト内でのみ意味を持ち、それがリモートノードの実際のIPv6アドレスのIPv4の表現を提供するために使用されるIPv4アドレス。
This document is a direct derivative of [RFC2767], "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)" by Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI and of [RFC3338], "Dual Stack Hosts Using "Bump-in-the-API" (BIA)" by Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark, which similarly provides IPv4-only applications on dual-stack hosts the means to operate over IPv6. Section 7 covers the changes since those documents.
このドキュメントは[RFC2767]、バンプ・イン・スタック「技術（BIS） 『和明TSHUCHIYA、秀光樋口、及び善文ATARASHIによって及び[RFC3338]の、』使用してデュアルスタックホスト」「デュアルスタックの直接誘導体でありますSeungyunリー、明博-KI新、同様の手段をホストするデュアルスタック上のIPv4専用アプリケーションを提供・ヨンジンキム、アラン・デュラン、およびエリックNordmarkと、により「（BIA）の "bump-in-the-API" を使用するホストIPv6の上で動作します。第7節は、それらの文書からの変更をカバーしています。
Figure 1 shows the architecture of a host in which BIH is implemented as a socket API-layer translator, i.e., as a "Bump-in-the-API".
図1の「bump-in-the-API」としてBIHは、すなわち、ソケットAPI層トランスレータとして実装されているホストのアーキテクチャを示しています。
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | IPv4 applications | |
| | | |
| +------------------------------------------+ |
| +------------------------------------------+ |
| | Socket API (IPv4, IPv6) | |
| +------------------------------------------+ |
| +-[ API translator]------------------------+ |
| | +-----------+ +---------+ +------------+ | |
| | | Ext. Name | | Address | | Function | | |
| | | Resolver | | Mapper | | Mapper | | |
| | +-----------+ +---------+ +------------+ | |
| +------------------------------------------+ |
| +--------------------+ +-------------------+ |
| | | | | |
| | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | |
| | | | | |
| +--------------------+ +-------------------+ |
+----------------------------------------------+
Figure 1: Architecture of a dual-stack host using protocol translation at the socket layer
図1：ソケット層でプロトコル変換を使用してデュアルスタックホストのアーキテクチャ
Figure 2 shows the architecture of a host in which BIH is implemented as a network-layer translator, i.e., a "Bump-in-the-Stack".
図2は、BIHは、ネットワーク層の翻訳、すなわち「バンプ・イン・スタック」として実装されているホストのアーキテクチャを示しています。
+------------------------------------------------------------+
| +------------------------------------------+ |
| | IPv4 applications | |
| | Host's main DNS resolver | |
| +------------------------------------------+ |
| +------------------------------------------+ |
| | TCP/UDP | |
| +------------------------------------------+ |
| +------------------------------------------+ +---------+ |
| | IPv4 | | | |
| +------------------------------------------+ | Address | |
| +------------------+ +---------------------+ | Mapper | |
| | Protocol | | Extension Name | | | |
| | Translator | | Resolver | | | |
| +------------------+ +---------------------+ | | |
| +------------------------------------------+ | | |
| | IPv4 / IPv6 | | | |
| +------------------------------------------+ +---------+ |
+------------------------------------------------------------+
Figure 2: Architecture of a dual-stack host using protocol translation at the network layer
図2：ネットワーク層でプロトコル変換を使用してデュアルスタックホストのアーキテクチャ
Dual-stack hosts, defined in [RFC4213], need applications, TCP/IP modules, and addresses for both IPv4 and IPv6. The proposed hosts in this document have an API or network-layer translator to allow legacy IPv4 applications to communicate with IPv6-only peers. The BIH architecture consists of an Extension Name Resolver, an address mapper, and depending on implementation either a function mapper or a protocol translator. It is worth noting that the Extension Name Resolver's placement is orthogonal to the placement of protocol translation. For example, the Extension Name Resolver may reside in the socket API while protocol translation takes place at the network layer.
[RFC4213]で定義されたデュアルスタックホストは、アプリケーション、TCP / IPモジュール、およびIPv4とIPv6の両方のアドレスを必要とします。この文書で提案されているホストは、APIまたはネットワーク層のトランスレータは、従来のIPv4アプリケーションがIPv6のみのピアと通信できるようにする必要があります。 BIHアーキテクチャは拡張リゾルバー、アドレスマッパで構成され、実装に機能マッパまたはプロトコルトランスレータのいずれかに依存します。これは、拡張ネームリゾルバの配置は、プロトコル変換の配置に直交していることは注目に値します。プロトコル変換はネットワーク層で行われている間たとえば、拡張ネームリゾルバは、ソケットAPIに常駐してもよいです。
The choice between the socket API- and network-layer architectures varies case by case. While the socket API architecture alternative is the recommended one, it may not always be possible to choose. This may be the case, for example, when the used operating system does not allow modifications to be done for API implementations, but does allow the addition of virtual network interfaces and related software modules. On the other hand, sometimes it may not be possible to introduce protocol translators inside the operating system, but it may be easy to modify implementations behind the API provided for applications. The choice of architecture also depends on who is creating implementation of BIH. For example, an application framework provider, an operating system provider, and a device vendor may all choose different approaches due their different positions.
ソケットAPI-とネットワーク層アーキテクチャとの間の選択は、ケースバイケースで変動します。ソケットAPIのアーキテクチャの選択肢が推奨ですが、常に選択することが可能ではないかもしれません。これは、使用するオペレーティングシステムが変更は、APIの実装のために行うことはできませんが、仮想ネットワークインタフェースと関連するソフトウェアモジュールの追加を許可しない場合、例えば、場合であってもよいです。一方、時にはオペレーティング・システム内のプロトコルトランスレータを導入することが可能ではないかもしれないが、アプリケーションのために提供されているAPIの背後に実装を変更するのは簡単かもしれません。アーキテクチャの選択はまた、BIHの実装を作成している人に依存します。例えば、アプリケーション・フレームワーク・プロバイダ、オペレーティングシステムのプロバイダ、およびデバイスのベンダーは、すべての異なる位置、異なるアプローチを選択することができます。
The function mapper translates an IPv4 socket API function into an IPv6 socket API function.
関数マッパーは、IPv6ソケットAPI関数にIPv4ソケットAPI関数を変換します。
When detecting IPv4 socket API function calls from IPv4 applications, the function mapper MUST intercept the function calls and invoke IPv6 socket API functions that correspond to the IPv4 socket API functions.
検出のIPv4ソケットAPI関数は、IPv4アプリケーションから呼び出すと、関数マッピングは、関数呼び出しをインターセプトし、IPv4ソケットAPI関数に対応するIPv6ソケットAPI関数を呼び出す必要があります。
The function mapper MUST NOT perform function mapping when the application is initiating communications to the address range used by local synthesis and the address mapping table does not have an entry matching the address.
アプリケーションがアドレスと一致するエントリを持たないローカル合成およびアドレスマッピングテーブルによって使用されるアドレス範囲に通信を開始している場合、関数マッパーは関数マッピングを実行してはいけません。
See Appendix A for an informational list of functions that would be appropriate to intercept by the function mapper.
関数マッパーによって傍受するのが適切だろう機能の情報リストについては、付録Aを参照してください。
The protocol translator translates IPv4 into IPv6, and vice versa, using the IP conversion mechanism defined in SIIT [RFC6145]. To avoid unnecessary fragmentation, the host's IPv4 module SHOULD be configured with a small enough MTU (MTU of the IPv6 enabled link - 20 bytes).
プロトコルトランスレータはSIIT [RFC6145]で定義されたIP変換機構を使用して、IPv6、およびその逆へのIPv4を変換します。不必要な断片化を避けるために、ホストのIPv4モジュールは十分に小さいMTU（ - 20バイトのIPv6有効リンクのMTU）を用いて構成されるべきです。
Protocol translation cannot be performed for IPv4 packets sent to the IPv4 address range used by local synthesis and for which a mapping table entry does not exist. The implementation SHOULD attempt to route such packets via IPv4 interfaces instead.
プロトコル変換は、ローカル合成によって、およびマッピングテーブルエントリが存在しないために使用されるIPv4アドレス範囲に送信されたIPv4パケットのために行うことができません。インプリメンテーションではなく、IPv4インタフェースを介してルートそのようなパケットを試みます。
The Extension Name Resolver (ENR) returns an answer in response to the IPv4 application's name resolution request.
拡張ネームリゾルバ（ENR）は、IPv4のアプリケーションの名前解決要求に応じて答えを返します。
In the case of the socket API-layer implementation alternative, when an IPv4 application tries to do a forward lookup to resolve names via the resolver library (e.g., gethostbyname()), BIH intercepts the function call and instead calls the IPv6 equivalent functions (e.g., getaddrinfo()) that will resolve both A and AAAA records. This implementation alternative is name resolution protocol agnostic; hence, it supports techniques such as "hosts-file", NetBIOS, mDNS, and anything else the underlying operating system uses.
IPv4のアプリケーションはリゾルバライブラリを経由して名前を解決するために前方参照を行うにしようとすると、ソケットAPI層の実装の代替の場合（例えば、のgethostbyname（））、BIHは（関数呼び出しをインターセプトし、代わりにIPv6の同等の機能を呼び出します例えば、はgetaddrinfo（））AとAAAAレコードの両方を解決すること。この実装の選択肢はとらわれない名前解決プロトコルです。したがって、そのような「ホスト・ファイル」、NetBIOSの、mDNSの、基礎となるオペレーティングシステムが使用する何か他のもののような技術をサポートしています。
In the case of the network-layer implementation alternative, the ENR intercepts the A query and creates an additional AAAA query with similar content. The ENR will then collect replies to both A and AAAA queries and, depending on results, either return an A reply unmodified or synthesize a new A reply. If no reply for the A query is received after ENR-implementation-specific timeout, after reception of positive AAAA response, the ENR MAY choose to proceed as if there were only a AAAA record available for the destination.
ネットワーク層の実装の代替の場合において、ENRは、クエリをインターセプトし、同様の内容を有する付加的なAAAAクエリを作成します。 ENRは両方AとAAAAクエリへの応答を収集し、その結果に応じて、いずれかの修飾されていない応答、または新しい応答を合成Aを返します。クエリに対する返事はENR-実装固有のタイムアウト後に受信されない場合、正AAAA応答の受信後、ENRは、先に利用可能な唯一のAAAAレコードがあったかのように進行することを選択するかもしれません。
The network-layer implementation alternative will only be able to catch applications' name resolution requests that result in actual DNS queries; hence, it is more limited when compared to the socket API-layer implementation alternative. Hence, the socket API-layer alternative is RECOMMENDED.
ネットワーク層の実装の代替だけで、実際のDNSクエリにつながるアプリケーションの名前解決要求をキャッチすることができるようになります。ソケットAPI層の実装の代替と比較した場合、したがって、それはより限られています。したがって、ソケットAPI層の選択肢をお勧めします。
In either implementation alternative, if a DNS A record reply contains non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 addresses.
レコード応答が非除外実際のIPv4アドレスが含まれているDNS場合は、実装の代替のいずれかで、ENRは、IPv4アドレスを合成してはなりません。
The ENR asks the address mapper to assign a synthetic IPv4 address corresponding to each received IPv6 address if the A record query resulted in a negative response, all received real IPv4 addresses were excluded, or the A query timed out. The timeout value is implementation specific and may be short in order to provide a good user experience.
ENRレコード照会が否定的な応答をもたらした場合にそれぞれに対応する合成IPv4アドレスは、IPv6アドレスを受信割り当てるアドレスマッパを要求、受信した全ての実IPv4アドレスを除外した、またはクエリがタイムアウトになりました。タイムアウト値は、実装固有のものであり、優れたユーザ体験を提供するために短くてもよいです。
In the case of the API-layer implementation alternative, the ENR will simply make the API (e.g., gethostbyname) return the synthetic IPv4 address. In the case of the network-layer implementation alternative, the ENR synthesizes an A record for the assigned synthetic IPv4 address and delivers it up the stack. If the response contains a CNAME or a DNAME record, then the CNAME or DNAME chain is followed until the first terminating A or AAAA record is reached.
API層の実装の代替の場合において、ENRは、単にAPI（例えば、のgethostbyname）が合成IPv4アドレスを返すようになります。ネットワーク層の実装の代替の場合において、ENRは、割り当てられた合成IPv4アドレスのレコードを合成し、スタックをそれを配信します。応答がCNAMEまたはDNAMEレコードが含まれている場合は最初の終端AまたはAAAAレコードに達するまで、次にCNAMEまたはDNAME鎖が続いています。
Application | Network | ENR behavior
query | response |
---------------+-----------------------+----------------------------
IPv4 address(es) | IPv4 address(es) | return real IPv4 address(es)
IPv4 address(es) | IPv6 address(es) | synthesize IPv4 address(es)
IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es)
Figure 3: ENR Behavior Illustration
図3：ENR行動イラスト
An ENR implementation SHOULD, by default, exclude certain real IPv4 and IPv6 addresses seen on received A and AAAA records. The addresses to be excluded by default MAY include addresses such as those that should not appear in the DNS or on the wire (see Section 5.1.4 of [RFC6147] and [RFC5735]). Additional addresses MAY be excluded based on possibly configurable local policies.
ENRの実装では、デフォルトでは、受信AとAAAA記録に見られる特定の本当のIPv4アドレスとIPv6アドレスを除外する必要があります。デフォルトで除外されるアドレスは、DNSでまたはワイヤ上に現れてはならないものとしてのアドレス（[RFC6147]のセクション5.1.4を参照して、[RFC5735]）を含むかもしれません。追加のアドレスは、おそらく、設定のローカルポリシーに基づいて除外することができます。
When the ENR is implemented at the network layer, the A record synthesis can cause similar issues as are described in [RFC6147] section 3. While running BIH, the main resolver of the host SHOULD NOT perform validation of A records, as synthetic A records created by ENR would fail in validation. While not running BIH, a host's resolver can use DNS Security (DNSSEC) in the same way that any other resolver can. The ENR MAY support DNSSEC, in which case the (stub) resolver on a host can be configured to trust validations done by the ENR located at the network layer. In some cases, the host's validating stub resolver can implement the ENR by itself.
ENRは、ネットワーク層で実装される場合BIHの実行中に、[RFC6147]セクション3に記載されているように、レコードの合成は、同様の問題を引き起こす可能性があり、ホストの主リゾルバは、合成のAレコードとして、レコードの検証を実行しないでください検証に失敗するENRが作成しました。 BIHを実行していないが、ホストのリゾルバは、他のリゾルバ缶と同じように、DNSセキュリティ（DNSSEC）を使用することができます。 ENRは、ホスト上の（スタブ）リゾルバは、ネットワーク層に位置するENRによって行わ検証を信頼するように構成することができ、その場合にDNSSECをサポートすることができます。いくつかのケースでは、ホストの検証をスタブリゾルバは、それ自体でENRを実装することができます。
When the ENR is implemented at the socket API level, there are no issues with DNSSEC use, as the ENR itself uses socket APIs for DNS resolution. This approach is RECOMMENDED.
ENRは、ソケットAPIレベルで実装されている場合ENR自体は、DNS解決のためのソケットAPIを使用して、DNSSECの使用には問題は、存在しません。このアプローチをお勧めします。
When an application requests a reverse lookup (PTR query) for an IPv4 address, the ENR MUST check whether the queried IPv4 address can be found in the address mapper's mapping table and if it is a synthetic IPv4 address. If an entry is found and the queried IPv4 address is synthetic, the ENR MUST initiate a corresponding reverse lookup for the real IPv6 address. In the case where the application requested a reverse lookup for an address not part of the synthetic IPv4 address pool, e.g., a global address, the request MUST be passed on unmodified.
アプリケーションがIPv4アドレスの逆引き参照（PTRクエリ）を要求すると、ENRは、照会のIPv4アドレスがアドレスマッパのマッピングテーブルに、それが合成IPv4アドレスである場合に見つけることができるかどうかをチェックしなければなりません。エントリが発見され、照会IPv4アドレスが合成である場合、ENRは、実際のIPv6アドレスに対応する逆引きを開始しなければなりません。アプリケーションがアドレス合成IPv4アドレスプールの一部ではないための逆引きを要求した場合に、例えば、グローバルアドレスは、要求が未修飾で渡さなければなりません。
For example, when an application requests a reverse lookup for a synthetic IPv4 address, the ENR needs to intercept that query. The ENR asks the address mapper for the real IPv6 address that corresponds to the synthetic IPv4 address. The ENR shall perform a reverse lookup procedure for the destination's IPv6 address and return the name received as a response to the application that initiated the IPv4 query.
例えば、アプリケーションは、合成のIPv4アドレスの逆引き参照を要求すると、ENRは、そのクエリを傍受する必要があります。 ENR合成のIPv4アドレスに対応する実際のIPv6アドレスのアドレスマッピングを要求します。 ENRは、宛先のIPv6アドレスの逆引き参照の手順を実行し、IPv4クエリを開始したアプリケーションへの応答として受け取った名前を返還しなければなりません。
When BIH shuts down or address mapping table entries are cleared for any reason, DNS cache entries for synthetic IPv4 addresses MUST be flushed. There may be a DNS cache in the network-layer ENR itself and at the host's stub resolver.
BIHがシャットダウンするか、アドレスマッピングテーブルエントリは、何らかの理由でクリアされた場合、合成IPv4アドレスのDNSキャッシュエントリをフラッシュする必要があります。ネットワーク層ENR自体に、ホストのスタブリゾルバのDNSキャッシュがあるかもしれません。
The address mapper maintains an IPv4 address pool that can be used for IPv4 address synthesis. The pool consists of the IPv4 addresses of [RFC1918] as per Section 4.4. Also, the address mapper maintains a table consisting of pairs of synthetic IPv4 addresses and destinations' real IPv6 addresses.
アドレスマッパは、IPv4アドレスの合成に使用することができるIPv4アドレスプールを維持します。プールはセクション4.4に従って[RFC1918]のIPv4アドレスで構成されています。また、アドレスマッパーは、合成IPv4アドレスと宛先本当のIPv6アドレスのペアからなるテーブルを保持しています。
When the ENR, translator, or the function mapper requests the address mapper to assign a synthetic IPv4 address corresponding to an IPv6 address, the address mapper selects and returns an IPv4 address out of the local pool and registers a new entry into the table. The registration occurs in the following three cases:
ENR、翻訳、または機能マッパーはIPv6アドレスに、アドレスマッパ選択を対応する合成IPv4アドレスを割り当てるアドレスマッパを要求し、ローカルプールからIPv4アドレスを返し、テーブルに新しいエントリを登録します。登録は、以下の3つの場合に発生します。
1. When the ENR gets only IPv6 addresses for the target host name and there is no existing mapping entry for the IPv6 addresses. One or more synthetic IPv4 addresses will be returned to the application and mappings for synthetic IPv4 addresses to real IPv6 addresses are created.
ENRのみを取得すると1は、IPv6は、ターゲットホスト名のアドレスとIPv6アドレスのための既存のマッピングエントリがありません。 1種以上の合成のIPv4アドレスが作成され、実際のIPv6アドレスへの合成IPv4アドレスのためのアプリケーションとのマッピングに返されます。
2. When the ENR gets both real IPv4 and IPv6 addresses, but the real IPv4 addresses contain only excluded IPv4 addresses (e.g., 127.0.0.1). The behavior will follow case (1).
2. ENRが実IPv4およびIPv6アドレスの両方を取得したが、実際のIPv4アドレスが、IPv4アドレスのみを除外含まれている場合（例えば、127.0.0.1）。動作は、ケースに従います（1）。
3. When the function mapper is triggered by a received IPv6 packet and there is no existing mapping entry for the IPv6 source address (for example, the client sent a UDP request to an anycast address, but a response was received from a unicast address).
関数マッパーを受信したIPv6パケットによってトリガとIPv6ソースアドレスのための既存のマッピングエントリは、（例えば、クライアントは、エニーキャストアドレスにUDP要求を送信したが、応答はユニキャストアドレスから受信された）が存在していない3。 。
Other possible combinations are outside of BIH.
他の可能な組み合わせは、BIHの外にあります。
Figure 4 illustrates a very basic network scenario. An IPv4-only application is running on a host attached to the IPv6-only Internet and is talking to an IPv6-only server. Communication is made possible by Bump-in-the-Host.
図4は、非常に基本的なネットワークシナリオを示します。 IPv4専用のアプリケーションがIPv6のみインターネットに接続されたホスト上で実行されていて、IPv6専用サーバーに話しています。通信は、バンプ・イン・ザ・ホストによって可能となります。
+----+ +-------------+
| H1 |----------- IPv6 Internet -------- | IPv6 server |
+----+ +-------------+
v4 only
application
Figure 4: Network Scenario #1
図4：ネットワークシナリオ＃1
Figure 5 illustrates a possible network scenario where an IPv4-only application is running on a host attached to a dual-stack network, but the destination server is running on a private site that is numbered with public IPv6 addresses and not globally reachable IPv4 addresses, such as the addresses of [RFC1918], without port forwarding set up on the NAT44. The only means to contact the server is to use IPv6.
図5は、IPv4専用のアプリケーションがデュアルスタックネットワークに接続されたホスト上で実行されているが、先のサーバーがパブリックIPv6アドレスではなく、グローバルに到達可能なIPv4アドレスと番号付けされた民間のサイト上で実行されている可能なネットワークシナリオを示してそのようなNAT44に設定ポート転送せずに[RFC1918]のアドレス、など。サーバに接続するための唯一の手段は、IPv6を使用することです。
+----------------------+ +------------------------------+
| Dual-Stack Internet | | IPv4 Private site (Net 10) |
| | | IPv6 routed site |
| +---------+ +----------+ |
| +-| NAT44 |-------------+ | |
| +----+ | +---------+ | | |
| | H1 |---------+ | | | Server | |
| +----+ | +-----------+ | | |
| v4-only +-|IPv6 Router|-----------+ | |
| application +-----------+ +----------+ |
| | | Dual Stack |
| | | 10.1.1.1 |
| | | 2001:DB8::1 |
+----------------------+ +------------------------------+
Figure 5: Network Scenario #2
図5：ネットワークシナリオ＃2
Illustrations of host behavior in both implementation alternatives are given here. Figure 6 illustrates a setup where BIH (including the ENR) is implemented at the socket API layer, and Figure 7 illustrates a setup where BIH (including the ENR) is implemented at the network layer.
両方の実装の選択肢でホストの挙動のイラストは、ここで与えられています。図6は、BIHが（ENRを含む）ソケットAPI層で実装されている設定を示し、図7は、BIH（ENRを含む）がネットワーク層で実装されている設定を示しています。
"dual stack" "host6"
IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name
appli- API | ENR Address Function| (v6/v4) Server
cation | Mapper Mapper |
| | | | | | | |
<<Resolve IPv4 addresses for "host6".>> | | |
| | | | | | | |
|------->|------->| Query IPv4 addresses for host6. | |
| | | | | | | |
| | |------------------------------------------------->|
| | | Query 'A' and 'AAAA' records for host6 |
| | | | | | | |
| | |<-------------------------------------------------|
| | | Reply with the 'AAAA' record. | |
| | | | | | |
| | |<<The 'AAAA' record is resolved.>> |
| | | | | | |
| | |+++++++>| Request synthetic IPv4 address |
| | | | corresponding to the IPv6 address.
| | | | | | |
| | | |<<Assign one synthetic IPv4 address.>>
| | | | | | |
| | |<+++++++| Reply with the synthetic IPv4 address.
| | | | | | |
|<-------|<-------| Reply with the IPv4 address |
| | | | | | |
| | | | | | |
<<Call IPv4 Socket API function >> | | |
| | | | | | |
|=======>|=========================>|An IPv4 Socket API action
| | | | | | |
| | | |<+++++++| Request IPv6 addresses|
| | | | | corresponding to the |
| | | | | synthetic IPv4 addresses.
| | | | | | |
| | | |+++++++>| Reply with the IPv6 addresses.
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
| An IPv6 Socket API action |=======================>|
| | | | | | |
| | | | |<<IPv6 data received |
| | | | | from network.>> |
| | | | | | |
| An IPv6 Socket API action |<=======================|
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
| | | |<+++++++| Request synthetic IPv4 addresses
| | | | | corresponding to the |
| | | | | IPv6 addresses. |
| | | | | | |
| | | |+++++++>| Reply with the IPv4 addresses.
| | | | | | |
|<=======|<=========================| An IPv4 Socket API action
| | | | | | |
Figure 6: Example of BIH as API Addition
図6：APIの追加などBIHの例
"dual stack" "host6"
IPv4 stub TCP/ ENR address translator IPv6
app res. IPv4 mapper
| | | | | | | |
<<Resolve an IPv4 address for "host6".>> | |
|-->| | | | | | |
| |----------->| Query 'A' records for "host6". | Name
| | | | | | | | Server
| | | |------------------------------------------->|
| | | | Query 'A' and 'AAAA' records for "host6"
| | | | | | | | |
| | | |<-------------------------------------------|
| | | | Reply only with 'AAAA' record. |
| | | | | | | |
| | | |<<Only 'AAAA' record is resolved.>> |
| | | | | | | |
| | | |-------->| Request synthetic IPv4 address
| | | | | corresponding to each IPv6 address.
| | | | | | | |
| | | | |<<Assign synthetic IPv4 addresses.>>
| | | | | | | |
| | | |<--------| Reply with the synthetic IPv4 address.
| | | | | | | |
| | | |<<Create 'A' record for the IPv4 address.>>
| | | | | | | |
| |<-----------| Reply with the 'A' record. | |
| | | | | | | |
|<--|<<Reply with the IPv4 address | | |
| | | | | | | |
<<Send an IPv4 packet to "host6".>>| | |
| | | | | | | |
|=======>|========================>| An IPv4 packet. |
| | | | | | | |
| | | | |<++++++| Request IPv6 addresses
| | | | | | corresponding to the
| | | | | | synthetic IPv4 addresses.
| | | | | | | |
| | | | |++++++>| Reply with the IPv6|
| | | | | | addresses. |
| | | | | | | |
| | | | | |<<Translate IPv4 into IPv6.>>
| | | | | | | |
| | | |An IPv6 packet. |==========>|========>|
| | | | | | | |
| | | | | <<Reply with an IPv6 packet.>>
| | | | | | | |
| | | |An IPv6 packet. |<==========|<========|
| | | | | | | |
| | | | | |<<Translate IPv6 into IPv4.>>
| | | | | | | |
| | | | |<++++++| Request synthetic IPv4
| | | | | | addresses corresponding
| | | | | | to the IPv6 addresses.
| | | | | | | |
| | | | |++++++>| Reply with the IPv4 addresses.
| | | | | | | |
|<=======|=========================| An IPv4 packet. |
| | | | | | | |
Figure 7: Example of BIH at the Network Layer
図7：ネットワーク層でBIHの例
IPv4 socket API functions are translated into IPv6 socket API functions that are semantically as identical as possible, and vice versa. See Appendix A for the API list intercepted by BIH. However, some IPv4 socket API functions are not fully compatible with IPv6 since IPv4 supports features that are not present in IPv6, such as SO_BROADCAST.
IPv4ソケットAPI関数は、意味論的に可能な限り同一であるIPv6のソケットAPI関数、およびその逆に翻訳されます。 BIHによってインターセプトAPIのリストについては、付録Aを参照してください。 IPv4のは、SO_BROADCASTとしてIPv6の中に存在しない機能を、サポートしているのでしかし、いくつかのIPv4ソケットAPI関数は、IPv6と完全に互換性がありません。
BIH SHOULD select a source address for a socket from the recommended source address pool if a socket used for communications has not been explicitly bound to any IPv4 address.
通信に使用されるソケットは、明示的に任意のIPv4アドレスにバインドされていない場合BIHを推奨送信元アドレスプールからソケットの送信元アドレスを選択する必要があります。
The binding of an explicitly bound socket MUST NOT be changed by the BIH.
明示的にバインドされたソケットの結合BIHによって変更してはいけません。
ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT [RFC6145]. In the network-layer implementation alternative, the protocol translator MUST translate ICMPv6 packets to ICMPv4 and vice versa, and in the socket API implementation alternative, the socket API MUST handle conversions in similar fashion.
SIIT [RFC6145]で定義されるようにICMPv4のとのICMPv6メッセージを変換しなければなりません。ネットワーク層の実装代替では、プロトコルトランスレータはICMPv4の及びその逆へのICMPv6パケットを変換する必要があり、ソケットAPIの実装の代わりに、ソケットAPIは、同様の方法で変換を処理しなければなりません。
The address pool consists of the private IPv4 addresses of [RFC1918]. This pool can be implemented at different granularities in the node, e.g., a single pool per node, or at some finer granularity such as per-user or per-process. In the case of a large number of IPv4 applications communicating with a large number of IPv6 servers, the available address space may be exhausted if the granularity is not fine enough. This should be a rare event and chances will decrease as IPv6 support increases. The applications may use IPv4 addresses they learn for a much longer period than DNS time to live indicates. Therefore, the mapping table entries should be kept active for a long period of time. For example, a web browser may initiate one DNS query and then create multiple TCP sessions over time to the address it learns. When address mapping table clean-up is required, the BIH may utilize techniques used by network address translators, such as described in [RFC2663], [RFC5382], and [RFC5508].
アドレスプールは、[RFC1918]のプライベートIPv4アドレスで構成されています。このプールは、例えば、ノード内の異なる粒度でノードごと、またはいくつかのより細かい粒度で、このようなユーザ単位として、またはプロセスごとの単一のプールを実装することができます。粒度は十分に微細でない場合のIPv6多数のサーバと通信するIPv4アプリケーションが多数の場合には、利用可能なアドレス空間が使い果たされてもよいです。これはまれなイベントである必要があり、チャンスはIPv6サポートの増加に伴って減少します。アプリケーションは、彼らが生きるためのDNS時間が示すよりもはるかに長い期間のために学ぶのIPv4アドレスを使用することができます。したがって、マッピングテーブルエントリは、長時間アクティブ保たれるべきです。たとえば、Webブラウザは、1つのDNSクエリを開始することができるし、それが学習のアドレスに時間をかけて複数のTCPセッションを作成します。アドレスマッピングテーブルのクリーンアップが必要な場合、BIHは、[RFC2663]、[RFC5382]及び[RFC5508]で説明されるように、ネットワークアドレス変換、によって使用される技術を利用することができます。
The address space of RFC 1918 was chosen because legacy applications generally understand it as a private address space. A new dedicated address space would run the risk of not being understood by applications as private. 127/8 and 169.254/16 are rejected due to possible assumptions applications may make when seeing them.
レガシーアプリケーションは、一般的にプライベートアドレス空間としてそれを理解するため、RFC 1918のアドレス空間が選択されました。新しい専用のアドレス空間は、プライベートなどのアプリケーションが理解されていないのリスクを実行します。 8分の127と169.254 / 16が原因それらを見たときにアプリケーションが作ることが可能な仮定に拒否されています。
The addresses of RFC 1918 used by the BIH have a risk of conflicting with addresses used in the host's possible IPv4 interfaces and corresponding local networks. The conflicts can be mitigated, but not fully avoided, by using less commonly used portions of the address space of RFC 1918. Addresses from 172.16/12 are thought to be less likely to be in conflict than addresses from 10/8 or 192.168/16 spaces. A source address can usually be selected in a non-conflicting manner, but a small possibility exists for synthesized destination addresses being in conflict with real addresses used in attached IPv4 networks.
BIHによって使用されるRFC 1918のアドレスは、ホストの可能IPv4インタフェースで使用されるアドレスと競合し、ローカルネットワークに対応するリスクを有しています。競合が軽減するが、完全にはあまり一般的に172.16 / 12から1918のアドレスは10/8又は192.168 / 16からアドレスより競合になりにくいと考えられているRFCのアドレス空間の使用部分を使用することによって、回避することができませんスペース。送信元アドレスは、通常、非競合方法で選択することができるが、小さい可能性は、添付のIPv4ネットワークで使用される実際のアドレスと競合している合成された宛先アドレスのために存在します。
The RECOMMENDED IPv4 addresses are following:
推奨IPv4アドレスは次のとおりです。
Primary source addresses: 172.21.112.0/20.
プライマリ送信元アドレス：172.21.112.0/20。
Source addresses have to be allocated because applications use getsockname() calls and, in the network-layer mode, an IP address of the IPv4 interface has to be shown (e.g., by 'ifconfig'). More than one address is allocated to allow implementation flexibility, e.g., for cases where a host has multiple IPv6 interfaces. The source addresses are from different subnets than destination addresses to ensure applications would not make on-link assumptions and would instead enable NAT traversal functions.
送信元アドレスは、アプリケーションがのgetsockname（）コールを使用して、ネットワーク・レイヤモードで、IPv4インタフェースのIPアドレス（例えば、「ifconfigコマンド」によって）示さなければならないために割り当てられなければなりません。複数のアドレスは、ホストが複数のIPv6インタフェースを有している場合について、例えば、実装の柔軟性を可能にするために割り当てられます。送信元アドレスは、オンリンク仮定をしないと、アプリケーションを確実にするために、宛先アドレスとは異なるサブネットからのものであり、代わりにNATトラバーサル機能を可能にします。
Secondary source addresses: 10.170.224.0/20.
二次元アドレス：10.170.224.0/20。
These addresses are recommended if a host has a conflict with primary source addresses.
ホストがプライマリソースアドレスとの競合を持っている場合、これらのアドレスが推奨されています。
Primary destination addresses: 10.170.160.0/20.
プライマリ宛先アドレス：10.170.160.0/20。
The address mapper will select destination addresses primarily out of this pool.
アドレスマッパーは、主にこのプールのうち、送信先アドレスを選択します。
Secondary destination addresses: 172.21.80.0/20.
二次送信先アドレス：172.21.80.0/20。
The address mapper will select destination addresses out of this pool if the node has a dual-stack connection conflicting with primary destination addresses.
ノードがプライマリ宛先アドレスと競合するデュアルスタック接続している場合、アドレスマッパーは、このプールのうち、送信先アドレスを選択します。
In the case of dual-stack destinations, BIH MUST NOT do protocol translation from IPv4 to IPv6 when the host has any IPv4 interfaces, native or tunneled, available for use.
ホストが使用することが可能な任意のIPv4インタフェース、ネイティブまたはトンネリングさを、持っていたときにデュアルスタック地の場合は、BIHは、IPv4からIPv6へのプロトコル変換を行うてはなりません。
It is possible that an IPv4 interface is activated during BIH operation, for example, if a node moves to a coverage area of an IPv4-enabled network. In such an event, BIH MUST stop initiating protocol translation sessions for new connections, and BIH MAY disconnect active sessions. The choice of disconnection is left for implementations, and it may depend on whether IPv4 address conflict occurs between addresses used by BIH and addresses used by the new IPv4 interface.
ノードがIPv4対応のネットワークのカバレージエリアに移動した場合IPv4インタフェースは、例えば、BIH動作中に活性化されることが可能です。このようなイベントでは、BIHは、新しい接続のためのプロトコル変換セッションを開始するのを止めなければなりません、とBIHは、アクティブなセッションを切断されることがあります。断線の選択は、実装のために残され、それは、IPv4アドレスの競合が新しいIPv4インタフェースによって使用BIHによって使用されるアドレスとアドレスとの間で発生するかどうかに依存してもよいです。
Protocol translation for multicast is not supported.
マルチキャストのためのプロトコル変換がサポートされていません。
No Application-Level Gateway (ALG) functionality is specified herein as ALG design is generally not encouraged for host-based translation and as BIH is intended for applications that do not include IP addresses in protocol payloads.
ALG設計は、一般的に、ホストベース翻訳のためにとBIHは、プロトコルペイロードにIPアドレスが含まれていないアプリケーションのために意図されているよう奨励されていないと何アプリケーションレベルゲートウェイ（ALG）機能は、本明細書に指定されていません。
The security considerations of BIH follows closely, but not completely, those of NAT64 [RFC6146] and DNS64 [RFC6147]. The following sections are copied from RFC 6146 and RFC 6147 and modified for BIH.
BIHのセキュリティ上の考慮事項は、NAT64 [RFC6146]とDNS64 [RFC6147]のものに密接に従いますが、完全ではありません。以下のセクションでは、RFC 6146及びRFC 6147からコピーされ、BIHのために修正されます。
Any protocols that protect IP header information are essentially incompatible with BIH. This implies that end-to-end IPsec verification will fail when the Authentication Header (AH) is used (both transport and tunnel mode) and when ESP is used in transport mode. This is inherent in any network-layer translation mechanism. End-to-end IPsec protection can be restored, using UDP encapsulation as described in [RFC3948]. The actual extensions to support IPsec are out of the scope of this document.
IPヘッダ情報を保護する任意のプロトコルは、本質的にBIHと互換性がありません。これは、認証ヘッダ（AH）は、（両方の輸送とトンネルモード）を使用した場合とESPは、トランスポートモードで使用される場合、エンドツーエンドのIPsec認証が失敗することを意味します。これは、任意のネットワーク層の変換メカニズムに固有のものです。エンドツーエンドのIPsec保護は、[RFC3948]に記載されているようにUDPカプセル化を使用して、復元することができます。 IPsecをサポートするための実際の拡張子は、この文書の範囲外です。
BIH creates binding state using packets flowing from the IPv4 side to the IPv6 side. In accordance with the procedures defined in this document, following the guidelines defined in [RFC4787], a BIH implementation MUST offer "Endpoint-Independent Mapping".
BIHは、IPv6側へのIPv4側から流れるパケットを使用して結合状態を作り出します。この文書で定義された手順に従い、[RFC4787]で定義されたガイドラインに従って、BIHの実装は、「エンドポイント・独立マッピング」を提供しなければなりません。
Implementations MAY also provide support for "Address-Dependent Mapping" following the guidelines defined in [RFC4787].
また、実装は[RFC4787]で定義されたガイドラインに従って、「アドレス依存マッピング」のサポートを提供することができます。
The security properties, however, are determined by which packets the BIH allows in and which it does not. The security properties are determined by the filtering behavior and by the possible filtering configuration in the filtering portions of the BIH, not by the address mapping behavior.
セキュリティプロパティは、しかし、それによってBIHが可能で、それはないパケットに決定されます。セキュリティプロパティはなく、アドレスマッピング動作によってフィルタリング動作によって、およびBIHのフィルタリング部における可能なフィルタリング設定によって決定されます。
The BIH implementation itself is a potential victim of different types of attacks. In particular, the BIH can be a victim of Denial-of-Service (DoS) attacks. The BIH implementation has a limited number of resources that can be consumed by attackers creating a DoS attack. The BIH has a limited number of IPv4 addresses that it uses to create the bindings. Even though the BIH performs address translation, it is possible for an attacker to consume the synthetic IPv4 address pool by triggering a host to issue DNS queries for names that cause ENR to synthesize A records. DoS attacks can also affect other limited resources available in the host running BIH such as memory or link capacity. For instance, it is possible for an attacker to launch a DoS attack on the memory of the BIH running device by sending fragments that the BIH will store for a given period. If the number of fragments is large enough, the memory of the host could be exhausted. BIH implementations MUST implement proper protection against such attacks, for instance, allocating a limited amount of memory for fragmented packet storage.
BIHの実装自体は、攻撃の異なる種類の潜在的な被害者です。特に、BIHは、サービス拒否（DoS）攻撃の被害者することができます。 BIHの実装では、DoS攻撃を作成する攻撃者によって消費できるリソースの数が限られています。 BIHは、IPv4の限られた数は、それがバインディングを作成するために使用するアドレスを持っています。 BIHは、アドレス変換を実行していても、攻撃者はENRがレコードを合成する原因と名のDNSクエリを発行するホストをトリガすることによって合成IPv4アドレスプールを消費することが可能です。 DoS攻撃はまた、メモリやリンク容量としてBIHを実行しているホストで利用可能な他の限られたリソースに影響を与えることができます。攻撃者はBIHを一定期間保存するフラグメントを送信することにより、BIH実行しているデバイスのメモリ上のDoS攻撃を起動するために例えば、それは可能です。断片の数が十分に大きい場合、ホストのメモリが枯渇することができます。 BIH実装は断片化されたパケット記憶用メモリの制限された量を割り当てる、例えば、そのような攻撃に対する適切な保護を実装しなければなりません。
Another consideration related to BIH resource depletion is the preservation of binding state. Attackers may try to keep a binding state alive forever by sending periodic packets that refresh the state. In order to allow the BIH to defend against such attacks, the BIH implementation MAY choose not to extend the session entry lifetime for a specific entry upon the reception of packets for that entry through the external interface. However, such an action would not allow one-way communication sessions to stay alive.
BIH資源の枯渇に関連するもう1つの考慮事項は、結合状態の保存です。攻撃者は、状態をリフレッシュ定期的にパケットを送信することによって、永遠に生きている結合状態を維持しようとするかもしれません。 BIHは、そのような攻撃を防御することを可能にするために、BIH実装は、外部インターフェースを介して、そのエントリのためのパケットを受信すると、特定のエントリのためのセッションエントリの寿命を延長しないことを選んでもよいです。しかし、そのような行動は、片方向通信セッションが生き続けるために許可しませんでした。
BIH operates in combination with the DNS, and it is therefore subject to whatever security considerations are appropriate to the DNS mode in which the BIH is operating (i.e., recursive or stub-resolver mode).
BIHはDNSとの組み合わせで動作し、それはBIH（すなわち、再帰またはスタブリゾルバモード）動作しているDNSモードに適したどのようなセキュリティ考慮することが課題です。
BIH has the potential to interfere with the functioning of DNSSEC, because BIH modifies DNS answers, and DNSSEC is designed to detect such modifications and to treat modified answers as bogus.
BIHはBIHがDNS回答を変更するため、DNSSECの機能を妨害する可能性があり、そしてDNSSECは、そのような変更を検出し、偽のような修飾された回答を治療するために設計されています。
This document combines and obsoletes both [RFC2767] and [RFC3338].
この文書では、結合して、[RFC2767]と[RFC3338]の両方を廃止します。
The changes in this document mainly reflect the following:
このドキュメントの変更は、主に以下を反映します：
RFC 3338 used unassigned IPv4 addresses (e.g., 0.0.0.1 - 0.0.0.255) for synthetic IPv4 addresses. Those addresses should not have been used and that may cause problems with applications. It is preferable to use addresses defined in RFC 1918 instead, as described in Section 4.4.
合成IPv4アドレスの - RFC 3338は、割り当てられていないIPv4アドレス（0.0.0.255例えば、0.0.0.1）を用いました。これらのアドレスが使用されているべきではありません、それはアプリケーションで問題が発生することがあります。セクション4.4で説明したように、代わりに、RFC 1918で定義されたアドレスを使用することが好ましいです。
Neither RFC 2767 nor RFC 3338 included support for reverse (PTR) DNS queries. This document adds the support in Section 2.3.3.
どちらもRFC 2767もRFC 3338は、逆（PTR）DNSクエリーのサポートが含まれています。この文書は、セクション2.3.3でのサポートを追加します。
RFC 2767 did not include DNSSEC considerations, which are now included in Section 2.3.2
RFC 2767は現在2.3.2に含まれているDNSSECの配慮を、含まれていませんでした
This document recommends the socket API-layer implementation option over network layer translation, i.e., it recommends the approach introduced in RFC 2767 over the approach of RFC 3338.
この文書では、ネットワーク層翻訳の上にソケットAPI層の実装オプション、すなわち、それはRFC 3338のアプローチ上のRFC 2767で導入されたアプローチを推奨することをお勧めします。
RFC 2767 is classified as an Informational RFC and RFC 3338 as an Experimental RFC. It was discussed and decided in the IETF that this technology should be on the Standards Track.
RFC 2767は、実験的RFCとしての情報RFCおよびRFC 3338に分類されます。それは、この技術は標準化過程にあるべきことIETFで議論し、決定しました。
A set of lesser extensions, improvements, and clarifications have been introduced. These include but are not limited to IPv4 and IPv6 address exclusion sets at Section 2.3.1, host's DNS cache considerations, ENR behavior updates, updated security considerations, example updates, and deployment scenario updates.
小さい方の拡張、改善、および明確化のセットが導入されています。これらとしては、セクション2.3.1、ホストのDNSキャッシュの考慮事項、ENRの行動の更新、更新されたセキュリティ上の考慮事項、例のアップデート、および展開シナリオの更新でIPv4とIPv6アドレスの除外セットに限定されるものではありません。
The authors are grateful for discussion from Gang Chen, Dapeng Liu, Bo Zhou, Hong Liu, Tao Sun, Zhen Cao, and Feng Cao et al. in the development of this document.
著者はギャング陳、大鵬劉、ボー周、香港劉、タオ日、ジェン曹操、そして風水曹操らからの議論のために感謝しています。このドキュメントの開発インチ
The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco Cortes, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens, Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu, Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and James Woodyatt in reviewing this document are gratefully acknowledged.
モハメドBoucadairの努力、ディーン・チェン、ロレンツォColitti、パコ・コルテス、ラルフDroms、スティーブン・ファレル、フェルナンドGont、マーニックスGoossens、ワッシムハダッド、アラHamarsheh、デイブ・ハリントン、エドJankiewizh、スレシュクリシュナン、ジュリアンLAGANIER、耀輝L.リー、この文書のレビュー1月M.メレン、キボ牛、Pierrick側、クリスチャン・フォークト、マグヌスウェスター、ダン・ウィング、そしてジェームズWoodyattは深く感謝しています。
Special acknowledgments go to Dave Thaler for his extensive review and support.
特別の承認は彼の豊富なレビューと支援のためにデーブターラーに行きます。
The authors of RFC 2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. The authors of RFC 3338 acknowledged implementation contributions by Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation (www.i2soft.net).
RFC 2767の作者は、WIDEプロジェクト和彦山本、ジュン月nechika FREEDOM並河、渡辺謙、および貴久宮本を認めました。 RFC 3338人の実装調整可能・リー（wjlee@arang.miryang.ac.kr）によって認め貢献とi2softコーポレーション（www.i2soft.net）の著者。
The authors of "Bump-in-the-Wire IPv4/IPv6 Translator" (a draft document submitted to the v6ops WG in October 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Some ideas and clarifications from BIW have been adapted to this document.
"Bump-In-The-Wire方式のIPv4 / IPv6トランスレータ"（2006年10月にv6ops WGに提出ドラフト文書）の著者、P. Moster、L.チン、およびD.グリーンは、認知されています。 BIWからいくつかのアイデアと説明は、この文書に適応されています。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、マシューズ、P.、およびI.バンBeijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、サリバン、A.、マシューズ、P.、およびI.バンBeijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNS拡張機能"、RFC 6147、2011年4月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000.
[RFC2767]土屋、K.、樋口、H.、およびY. Atarashi、バンプ・イン・スタック "技術（BIS） "" を使用してデュアルスタックホスト"、RFC 2767、2000年2月。
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002.
[RFC3338]リー、S.、シン、MK。、金、YJ。、Nordmarkと、E.、およびA.デュラン、 "（BIA）の "bump-in-the-API RFC 3338" を用いたデュアルスタックホスト"、 2002年10月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNAT行動要件"、BCP 142、RFC 5382、2008年10月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、 "ICMPのためのNAT行動要件"、BCP 148、RFC 5508、2009年4月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用のIPv4アドレス"、BCP 153、RFC 5735、2010年1月。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RFC6180] Arkko、J.およびF.ベーカー、 "IPv6移行中のIPv6移行メカニズムを使用するためのガイドライン"、RFC 6180、2011年5月。
Appendix A. API List Intercepted by BIH
BIHによってインターセプト付録A. API一覧
The following informational list includes some of the API functions that would be appropriate to intercept by BIH module when implemented at the socket API layer. Please note that this list is not fully exhaustive, as the function names and services that are available on different APIs vary significantly.
次の情報のリストは、ソケットAPI層で実装された場合BIHモジュールによって傍受するのが適切でしょうAPI機能の一部が含まれています。異なるAPIで使用可能な関数名やサービスが大幅に変わるので、このリストは、完全に網羅しているわけではないことに注意してください。
The functions that the application uses to pass addresses into the system are as follows:
次のようにアプリケーションがシステムにアドレスを渡すために使用する関数です。
bind()
練る（）
connect()
接続（）
sendmsg()
sendmsg（）
sendto()
に送る（）
gethostbyaddr()
gethostbyaddr（）
getnameinfo()
getnameinfoを（）
The functions that return an address from the system to an application are as follows:
次のようにシステムからアプリケーションにアドレスを返す関数は以下のとおりです。
accept()
受け入れます（）
recvfrom()
recvfrom（）
recvmsg()
recvmsg（）
getpeername()
getpeername（）
getsockname()
getsockname（）
gethostbyname()
gethostbyname（）
getaddrinfo()
getaddrinfo（）
The functions that are related to socket options are as follows:
次のようにソケット・オプションに関連している機能は以下のとおりです。
getsocketopt()
getsockopt（）
setsocketopt()
setsockopt（）
As well, raw sockets for IPv4 and IPv6 may be intercepted.
同様に、IPv4とIPv6の生のソケットが傍受されてもよいです。
Most of the socket functions require a pointer to the socket address structure as an argument. Each IPv4 argument is mapped into corresponding an IPv6 argument, and vice versa.
ソケット関数のほとんどは、引数としてソケットアドレス構造体へのポインタが必要です。各IPv4の引数は、IPv6引数、およびその逆を対応するにマッピングされます。
According to [RFC3493], the following new IPv6 basic APIs and structures are required.
[RFC3493]によると、以下の新しいIPv6の基本的なAPIと構造が必要とされています。
IPv4 new IPv6
------------------------------------------------
AF_INET AF_INET6
sockaddr_in sockaddr_in6
gethostbyname() getaddrinfo()
gethostbyaddr() getnameinfo()
inet_ntoa()/inet_addr() inet_pton()/inet_ntop()
INADDR_ANY in6addr_any
Figure 8
図8
BIH may intercept inet_ntoa() and inet_addr() and use the address mapper for those. Doing that enables BIH to support literal IP addresses. However, IPv4 address literals can only be used after a mapping entry between the IPv4 address and corresponding IPv6 address has been created.
BIHは（INET_NTOA切片）とのinet_addr（）とそれらのアドレスマッパを使用することができます。こうそれは文字通りのIPアドレスをサポートするために、BIHを可能にします。しかし、IPv4アドレスリテラルのみ作成されたIPv4アドレスとそれに対応するIPv6アドレスの間のマッピングエントリの後に使用することができます。
The gethostbyname() and getaddrinfo() calls return a list of addresses. When the name resolver function invokes getaddrinfo(), and getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6, they should all be represented in the addresses returned by gethostbyname(). Thus, if getaddrinfo() returns multiple IPv6 addresses, this implies that multiple address mappings will be created: one for each IPv6 address.
gethostbyname（）とはgetaddrinfo（）の呼び出しは、アドレスのリストを返します。ネームリゾルバ機能は、それらが全てのgethostbynameによって返されたアドレス（）で表現されるべきIPv4またはIPv6かどうか、複数のIPアドレスを返す（）はgetaddrinfo（）とのgetaddrinfoを呼び出すとき。 getaddrinfo（）は複数のIPv6アドレスを返した場合このように、これは、複数のアドレスマッピングが作成されることを意味します。各IPv6アドレスのための1つを。
Authors' Addresses
著者のアドレス
Bill Huang China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China
ビル・黄中国移動32号宣武門西ストリート西城区北京100053中国
EMail: bill.huang@chinamobile.com
メールアドレス：bill.huang@chinamobile.com
Hui Deng China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China
ホイ鄧小平中国移動NO.32のX uはどこにも西通りX Iチェン区北京100053中国を押してください
EMail: denghui@chinamobile.com
メールアドレス：denghui@chinamobile.com
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 TAMPERE Finland
テームSavolainenのノキアHermiankatu 12 D FI-33720 TAMPEREフィンランド
EMail: teemu.savolainen@nokia.com
メールアドレス：teemu.savolainen@nokia.com