[要約] RFC 6535は、BIH（Bump-in-the-Host）を使用してデュアルスタックホストを実現するための仕様です。その目的は、IPv4とIPv6の両方をサポートするホスト間通信の効率を向上させることです。
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)
「バンプインザホスト」（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.
Bump-in-Host（BIH）は、NATを介してIPv6のみのピアと通信できる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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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]とぶつき（BIA）[RFC3338]テクノロジーの後継者であり組み合わせています。AAAAレコードのIPv4アドレスを合成することにより、IPv4のみのレガシーアプリケーションを有効にしてIPv6のみのサーバーと通信します。セクション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.
BIHには、2つの主要な実装の選択肢が含まれています。IPv4とIPv4スタックの間のプロトコル翻訳者、またはIPv4ソケットAPIモジュールとTCP/IPモジュールの間のAPI翻訳者です。基本的に、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パケットはインターセプトされ、Stateless 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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "not"、 "becommended"、 "bodement"、 ""、 "、" 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応答からAクエリへの応答から学習したリモートノードの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.
ホストがDNS応答からAAAAクエリへの応答から学習したリモートノードのIPv6アドレス。
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]の直接的な導関数です。「カズキチヤ、ヒドミツ島、ヨシフミアタラシと[RFC3338]、カズキアキの「バンプイン」テクニック（BIS）を使用したデュアルスタックホスト」スンユン・リー、ミュング・キ・シン、ヨンジン・キム、アラン・デュランド、エリック・ノルドマークによる「バンプ・イン・アピ」（BIA）を使用してホストは、デュアルスタックでIPv4のみのアプリケーションを提供すると同様に、平均をホストします。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は、BIHがソケットAPI層翻訳者として実装されているホストのアーキテクチャ、つまり「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]で定義されているデュアルスタックホストは、IPv4とIPv6の両方のアプリケーション、TCP/IPモジュール、およびアドレスを必要とします。このドキュメントで提案されているホストには、LEGACY IPv4アプリケーションがIPv6のみのピアと通信できるようにするAPIまたはネットワーク層翻訳者があります。BIHアーキテクチャは、拡張機能のリゾルバー、アドレスマッパー、および機能マッパーまたはプロトコル翻訳者のいずれかに応じて構成されています。拡張子名Resolverの配置がプロトコル翻訳の配置に直交することは注目に値します。たとえば、エクステンション名のリゾルバーはソケット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
ソケットAPI-とネットワークレイヤーのアーキテクチャの選択は、ケースごとに異なります。ソケットAPIアーキテクチャの代替品は推奨されるものですが、常に選択できるとは限りません。これは、たとえば、使用されているオペレーティングシステムでAPI実装の変更を許可しないが、仮想ネットワークインターフェイスと関連ソフトウェアモジュールの追加を許可する場合に当てはまる場合があります。一方、オペレーティングシステム内にプロトコル翻訳者を導入することができない場合がありますが、アプリケーション用に提供されているAPIの背後にある実装を簡単に変更するのは簡単かもしれません。アーキテクチャの選択は、誰がBIHの実装を作成しているかにも依存します。たとえば、an
application framework provider, an operating system provider, and a device vendor may all choose different approaches due their different positions.
アプリケーションフレームワークプロバイダー、オペレーティングシステムプロバイダー、およびデバイスベンダーはすべて、異なるポジションのために異なるアプローチを選択できます。
The function mapper translates an IPv4 socket API function into an IPv6 socket API function.
関数マッパーは、IPv4ソケットAPI関数をIPv6ソケット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アプリケーションからIPv4ソケットAPI関数呼び出しを検出する場合、関数マッパーは関数呼び出しをインターセプトし、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変換メカニズムを使用して、IPv4をIPv6に変換し、その逆も同様です。不要な断片化を回避するには、ホストのIPv4モジュールを、十分な十分なMTU（IPv6対応リンク-20バイトの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.
拡張名Resolver（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.
Socket API-Layerの実装の代替の場合、IPv4アプリケーションがResolverライブラリ（GethostbyName（）などを介して名前を解決するためにフォワードルックアップを実行しようとする場合、BIHは関数呼び出しを傍受し、代わりにIPv6等価関数を呼び出します（たとえば、AとAAAの両方のレコードを解決するgetaddrinfo（））。この実装の代替案は、名前解像度プロトコル不可知論者です。したがって、「ホストファイル」、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はAクエリを傍受し、同様のコンテンツを持つ追加のAAAAクエリを作成します。Enrは、AとAAAAの両方のクエリへの返信を収集し、結果に応じて、修正されていない返信を返すか、新しいA返信を合成します。登録補充固有のタイムアウトの後、A Queryの返信が受信されない場合、肯定的な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.
いずれかの実装の代替案では、DNSが記録的な返信に排除されていないリアルIPv4アドレスが含まれている場合、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は、ADROSDET MAPPERに、受信した各IPv6アドレスに対応する合成IPv4アドレスを割り当てるように依頼します。記録クエリが負の応答をもたらした場合、受信したすべての実際の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-Layerの実装の代替の場合、Enrは単にAPI（Gethostbynameなど）が合成IPv4アドレスを返すだけです。ネットワーク層の実装の代替の場合、ENRは、割り当てられた合成IPv4アドレスのAレコードを合成し、スタックに配信します。応答に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
ENRの実装は、デフォルトでは、受信したAおよびAAAAレコードで見られる特定の実際のIPv4およびIPv6アドレスを除外する必要があります。デフォルトで除外されるアドレスには、
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.
DNSまたはワイヤーに表示されないもの（[RFC6147]および[RFC5735]のセクション5.1.4を参照）。追加のアドレスは、設定可能なローカルポリシーに基づいて除外される場合があります。
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がネットワークレイヤーで実装される場合、Aレコード合成は[RFC6147]セクション3で説明されているように同様の問題を引き起こす可能性があります。BIHを実行している間、ホストのメインリゾルバーは、合成Aレコードとしてレコードの検証を実行してはなりません。ENRによって作成された場合、検証が失敗します。BIHを実行していませんが、ホストのリゾルバーは、他のリゾルバーと同じ方法でDNSセキュリティ（DNSSEC）を使用できます。ENRはDNSSECをサポートする場合があります。この場合、ホストの（スタブ）リゾルバーは、ネットワークレイヤーにあるEnrによって行われた検証を信頼するように構成できます。場合によっては、ホストの検証済みスタブリゾルバーは、それ自体で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自体がDNS解像度にソケットAPIを使用するため、ENRがソケット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クエリ）を要求する場合、entorは、クエリの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が何らかの理由で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.
1. Enrがターゲットホスト名の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).
3. 関数マッパーが受信したIPv6パケットによってトリガーされ、IPv6ソースアドレスの既存のマッピングエントリがない場合（たとえば、クライアントはUDPリクエストをAnycastアドレスに送信しましたが、ユニキャストアドレスから応答が受信されました）。
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のみのサーバーと話しています。コミュニケーションは、Hostの衝突によって可能になります。
+----+ +-------------+
| 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のみのアプリケーションがデュアルスタックネットワークに接続されているホストで実行されているが、宛先サーバーは、グローバルに到達可能なIPv4アドレスではなく、パブリックIPv6アドレスで番号が付けられたプライベートサイトで実行されているネットワークシナリオを示しています。[RFC1918]のアドレスなど、NAT44にポート転送が設定されていません。サーバーに連絡する唯一の手段は、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（ENを含む）が実装されるセットアップを示しています。
"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ソケットAPI関数は、IPv4がSO_BROADCASTなどのIPv6に存在しない機能をサポートするため、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.
BIHは、通信に使用されるソケットがIPv4アドレスに明示的にバインドされていない場合、推奨されるソースアドレスプールからソケットのソケットアドレスを選択する必要があります。
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.
ICMPV4およびICMPV6メッセージは、SIIT [RFC6145]で定義されているように翻訳する必要があります。ネットワーク層の実装の代替案では、プロトコル翻訳者はICMPV6パケットをICMPv4に翻訳し、その逆に翻訳する必要があり、ソケット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
アドレスプールは、[RFC1918]のプライベートIPv4アドレスで構成されています。このプールは、ノードの異なる粒度、たとえばノードごとの単一のプール、またはユーザーごとやプロセスごとなどのより細かい粒度で実装できます。多数のIPv6サーバーと通信する多数のIPv4アプリケーションの場合、
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].
粒度が十分に細かくない場合、利用可能なアドレススペースが使い果たされる場合があります。これはまれなイベントであるはずであり、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の住所スペースが選択されました。これは、レガシーアプリケーションが一般的にプライベートアドレススペースとしてそれを理解しているためです。新しい専用のアドレススペースは、アプリケーションによってプライベートとして理解されないリスクを冒します。127/8および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インターフェイスおよび対応するローカルネットワークで使用されるアドレスと矛盾するリスクがあります。RFC 1918のアドレス空間のあまり一般的に使用されていない部分を使用することにより、競合を軽減できますが、完全には回避できません。スペース。通常、ソースアドレスは非紛争方法で選択できますが、添付の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.
デュアルスタックの宛先の場合、BIHは、ホストに使用可能なIPv4インターフェイス（ネイティブまたはトンネリング）がある場合、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対応ネットワークのカバレッジ領域に移動する場合、BIH操作中にIPv4インターフェイスがアクティブになる可能性があります。このようなイベントでは、BIHは新しい接続のプロトコル翻訳セッションの開始を停止する必要があり、BIHはアクティブセッションを切断する可能性があります。切断の選択は実装のために残されており、BIHで使用されているアドレスと新しいIPv4インターフェイスで使用されるアドレス間でIPv4アドレスの競合が発生するかどうかに依存する場合があります。
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.
アルグ設計は一般にホストベースの翻訳には奨励されていないため、および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検証が失敗することを意味します。これは、ネットワーク層翻訳メカニズムに固有のものです。[RFC3948]で説明されているUDPカプセル化を使用して、エンドツーエンドのIPSEC保護を復元できます。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は、IPv4側からIPv6側に流れるパケットを使用して結合状態を作成します。[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攻撃を開始することができます。フラグメントの数が十分に大きい場合、ホストの記憶は使い果たされる可能性があります。たとえば、このような攻撃に対する適切な保護を実装する必要があります。たとえば、断片化されたパケットストレージに限られた量のメモリを割り当てる必要があります。
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資源の枯渇に関連する別の考慮事項は、結合状態の保存です。攻撃者は、状態をリフレッシュする定期的なパケットを送信することにより、拘束力のある状態を永遠に生き続けようとするかもしれません。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はDNSの回答を変更するため、BIHはDNSSECの機能を妨害する可能性があり、DNSSECはそのような修正を検出し、修正された答えを偽物として扱うように設計されています。
This document combines and obsoletes both [RFC2767] and [RFC3338].
この文書は、[RFC2767]と[RFC3338]の両方を組み合わせて廃止します。
The changes in this document mainly reflect the following:
このドキュメントの変更は、主に以下を反映しています。
1. Addresses of RFC 1918 used for synthesis
1. 合成に使用されるRFC 1918のアドレス
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.
RFC 3338は、合成IPv4アドレスに割り当てられていないIPv4アドレス（0.0.0.1-0.0.0.255など）を使用しました。これらのアドレスは使用されるべきではなく、アプリケーションに問題を引き起こす可能性があります。セクション4.4で説明されているように、代わりにRFC 1918で定義されているアドレスを使用することが望ましい。
2. Support for reverse (PTR) DNS queries
2. リバース（PTR）DNSクエリのサポート
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のサポートを追加します。
3. DNSSEC support
3. DNSSECサポート
RFC 2767 did not include DNSSEC considerations, which are now included in Section 2.3.2
RFC 2767にはDNSSECの考慮事項は含まれていませんでしたが、セクション2.3.2に含まれています。
4. Architectural recommendation
4. 建築の推奨
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-Layer実装オプションを推奨します。つまり、RFC 3338のアプローチに関してRFC 2767で導入されたアプローチを推奨します。
5. Standards-Track document
5. 標準トラックドキュメント
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 3338として実験RFCとして分類されています。IETFで議論され、このテクノロジーは標準の追跡に載るべきであると決定されました。
6. Set of other extensions and improvements
6. その他の拡張機能と改善のセット
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のIPv4およびIPv6アドレスの除外セット、ホストのDNSキャッシュに関する考慮事項、ENRの動作の更新、更新されたセキュリティに関する考慮事項、更新の例、および展開シナリオの更新が含まれますが、これらに限定されません。
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.
モハメド・ブーカデア、ディーン・チェン、ロレンツォ・コリッティ、パコ・コルテス、ラルフ・ドロムズ、スティーブン・ファレル、フェルナンド・ゴント、マルニックス・グッセンズ、ワスシム・ハダッド、アラ・ハマーシェ、デイブ・ハリントン、エド・ジャンキヴィズ、スリシュ・クリシュナン、ジュリエン・ラガニエ、Jan M. Melen、Qibo Niu、Pierrick Seite、Christian Vogt、Magnus Westerlund、Dan Wing、およびJames Woodyattのレビューにおいて、感謝されていることに感謝しています。
Special acknowledgments go to Dave Thaler for his extensive review and support.
特別な謝辞は、彼の広範なレビューとサポートのためにDave Thalerに送られます。
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の著者は、ワイドプロジェクト、Yamamohiko、Jun Murai、Munechika sumikawa、Ken Watanabe、および宮本高子を認めました。RFC 3338の著者は、Wanjik Lee（wjlee@arang.miryang.ac.kr）およびi2soft Corporation（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.
「Bumb-in-the-Wire IPv4/IPv6 Translator」（2006年10月にV6OPS WGに提出されたドラフトドキュメント）、P。Moster、L。Chin、およびD. Greenの著者が認められています。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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 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. Gilligan、「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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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.、Bao、C。、およびF. Baker、「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.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、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.、Sullivan、A.、Matthews、P。、およびI. Van Beijnum、 "DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換の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. Holdrege、「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] Tsuchiya、K.、Higuchi、H。、およびY. atarashi、「Bump-in-the-Stack」テクニック（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] Lee、S.、Shin、M-K。、Kim、Y-J。、Nordmark、E。、およびA. Durand、「Bumb-in-api」（BIA）を使用したデュアルスタックホスト」、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] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「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] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、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.、Ford、B.、Sivakumar、S。、およびS. Guha、「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] Cotton、M。およびL. Vegoda、「Special Use 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. Baker、「IPv6展開中にIPv6遷移メカニズムを使用するためのガイドライン」、RFC 6180、2011年5月。
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（）をインターセプトし、それらにアドレスマッパーを使用できます。それを行うことで、BIHは文字通りのIPアドレスをサポートできます。ただし、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（）呼び出しは、アドレスのリストを返します。名前のResolver関数がgetaddrinfo（）を呼び出し、getaddrinfo（）が複数のIPアドレスを返す場合、IPv4であろうとIPv6であろうと、GethostbyName（）によって返されるアドレスですべて表現する必要があります。したがって、getAddrinfo（）が複数のIPv6アドレスを返す場合、これは複数のアドレスマッピングが作成されることを意味します。1つはIPv6アドレスごとに1つです。
Authors' Addresses
著者のアドレス
Bill Huang China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China
ビル・ハン・チャイナモバイルNo.32 Xuanwumen West Street Xicheng District Beijing 100053 China
EMail: bill.huang@chinamobile.com
Hui Deng China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China
Hui Deng China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China
EMail: denghui@chinamobile.com
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 TAMPERE Finland
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland
EMail: teemu.savolainen@nokia.com