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
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 the Host（BIH）是一种基于主机的IPv4到IPv6协议转换机制，它允许一类通过NAT工作的仅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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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.
本文档描述了Bump in the Host（BIH），它是Bump in the Stack（BIS）[RFC2767]和Bump in the API（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.
受支持的应用程序类别包括那些使用DNS进行IP地址解析的应用程序，以及那些不在应用程序协议有效负载中嵌入IP地址文本的应用程序。这包括使用DNS的传统客户端服务器应用程序，这些应用程序与目标使用的IP地址系列无关，并且能够进行NAT遍历。显示给应用程序的合成IPv4地址取自[RFC1918]的专用地址池，以确保启动可能的NAT穿越技术。
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一起使用[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包括两个主要的实现备选方案：主机的IPv4和IPv6堆栈之间的协议转换器，或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时，使用无状态IP/ICMP转换算法（SIIT）[RFC6145]中定义的IP转换机制拦截IPv4数据包并将其转换为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 A记录合成功能的位置与协议转换的位置正交，可能发生也可能不发生在同一位置。
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.
只要仅IPv4的应用程序需要与仅IPv6的服务器通信，就可以使用BIH，这与访问网络支持的地址系列无关。因此，接入网络可以是仅支持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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[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地址的记录的过程。
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.
例如，主机从对AAAA查询的DNS响应中了解到的远程节点的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.
一个IPv4地址，仅在主机内有意义，用于提供远程节点实际IPv6地址的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）的双堆栈主机（由Kazuaki Tshuchia、Hidemitsu HIGUCHI和Yoshifumi ATARASHI编写）和[RFC3338]、“使用“API中的凹凸”（BIA）的双堆栈主机（由Seungyun Lee、Myung Ki Shin、Yong Jin Kim、Alain Durand和Erik Nordmark编写）的直接衍生，它同样为双栈主机上仅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 | |
| | | | | |
| +--------------------+ +-------------------+ |
+----------------------------------------------+
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | 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 | | | |
| +------------------------------------------+ +---------+ |
+------------------------------------------------------------+
+------------------------------------------------------------+
| +------------------------------------------+ |
| | 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模块和地址。本文档中建议的主机具有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
套接字API和网络层架构之间的选择因情况而异。虽然推荐使用socket API体系结构替代方案，但并不总是可以选择。例如，当所使用的操作系统不允许对API实现进行修改，但允许添加虚拟网络接口和相关软件模块时，可能会出现这种情况。另一方面，有时可能无法在操作系统中引入协议转换器，但在为应用程序提供的API后面修改实现可能很容易。架构的选择还取决于谁在创建波黑的实施方案。例如，一个
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的链路的MTU-20字节）。
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.
在套接字API层实现替代方案的情况下，当IPv4应用程序尝试通过解析程序库（例如gethostbyname（））进行前向查找以解析名称时，BIH会截获函数调用，并调用IPv6等效函数（例如getaddrinfo（）），该函数将解析a和AAAA记录。该实现方案是名称解析协议不可知的；因此，它支持诸如“主机文件”、NetBIOS、MDN以及底层操作系统使用的任何其他技术。
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查询的答复，并根据结果返回未修改的答复或合成新的答复。如果在ENR实施特定超时后未收到对A查询的回复，则在收到肯定的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查询的应用程序名称解析请求；因此，与socketapi层实现方案相比，它更为有限。因此，建议使用套接字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 a记录应答包含非排除的真实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.
如果a记录查询导致否定响应、排除所有接收到的真实IPv4地址或a查询超时，则ENR要求地址映射器分配与每个接收到的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地址合成A记录，并将其发送到堆栈上。如果响应包含CNAME或DNAME记录，则遵循CNAME或DNAME链，直到到达第一个终止CNAME或AAAA记录为止。
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)
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创建的合成A记录将在验证中失败。在不运行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在套接字API级别实现时，DNSSEC的使用没有问题，因为ENR本身使用套接字API进行DNS解析。建议采用这种方法。
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地址，并在表中注册新条目。在以下三种情况下进行注册：
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地址的现有映射条目时。将向应用程序返回一个或多个合成IPv4地址，并创建合成IPv4地址到实际IPv6地址的映射。
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请求，但从单播地址接收响应）。
Other possible combinations are outside of 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 Internet的主机上运行，并且正在与仅IPv6服务器通信。通过主机中的Bump实现通信。
+----+ +-------------+
| H1 |----------- IPv6 Internet -------- | IPv6 server |
+----+ +-------------+
v4 only
application
+----+ +-------------+
| 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地址（例如[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 |
+----------------------+ +------------------------------+
+----------------------+ +------------------------------+
| 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说明了在套接字API层实现BIH（包括ENR）的设置，图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.>> |
| | | | | | |
"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
| | | | | | |
| | |+++++++>| 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添加剂的示例
"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. |<==========|<========|
| | | | | | | |
"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. |
| | | | | | | |
| | | | | |<<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：网络层的波黑示例
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函数，反之亦然。波黑截获的API清单见附录A。但是，某些IPv4套接字API函数与IPv6不完全兼容，因为IPv4支持IPv6中不存在的功能，例如SO_广播。
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.
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地址组成。该池可以在节点中以不同的粒度实现，例如，每个节点一个池，或者以更精细的粒度实现，例如每个用户或每个进程。在大量IPv4应用程序与大量IPv6服务器通信的情况下
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支持的增加，这种可能性会降低。应用程序使用IPv4地址的时间可能比DNS生存时间长得多。因此，映射表条目应保持长时间处于活动状态。例如，web浏览器可能会启动一个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.
之所以选择RFC1918的地址空间，是因为传统应用程序通常将其理解为专用地址空间。一个新的专用地址空间有可能被应用程序理解为私有地址。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.
波黑使用的RFC 1918地址有与主机可能的IPv4接口和相应本地网络中使用的地址冲突的风险。通过使用RFC 1918的地址空间中不太常用的部分，可以减轻但不能完全避免冲突。与10/8或192.168/16空间中的地址相比，172.16/12中的地址发生冲突的可能性较小。通常可以以不冲突的方式选择源地址，但合成的目标地址与连接的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的网络的覆盖区域，则可能在BIH操作期间激活IPv4接口。在这种情况下，波黑必须停止为新连接启动协议转换会话，波黑可能会断开活动会话。断开连接的选择留给实现，这可能取决于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.
本文未规定任何应用级网关（ALG）功能，因为通常不鼓励ALG设计用于基于主机的翻译，并且BIH适用于协议有效负载中不包含IP地址的应用。
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.
波黑的安全考虑与NAT64[RFC6146]和DNS64[RFC6147]的安全考虑密切相关，但并非完全一致。以下章节摘自RFC 6146和RFC 6147，并针对波黑进行了修改。
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]中定义的指南，波黑实施必须提供“端点独立映射”。
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.
波黑的实施本身就是各种攻击的潜在受害者。特别是，波黑可能成为拒绝服务（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防御此类攻击，在通过外部接口接收特定条目的分组时，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.
波黑有可能干扰DNSSEC的功能，因为波黑修改DNS答案，而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. 用于合成的RFC1918地址
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地址（例如，0.0.0.1-0.0.0.255）用于合成IPv4地址。这些地址不应该被使用，这可能会导致应用程序出现问题。最好使用RFC 1918中定义的地址，如第4.4节所述。
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.
本文档推荐socket API层实现选项而非网络层转换，即推荐RFC 2767中引入的方法而非RFC 3338中引入的方法。
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.
Mohamed Boucadair、Cheng院长、Lorenzo Coletti、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、，感谢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).
RFC2767项目的作者，山本和彦、村井俊二、住川明一郎、渡边健和宫本隆久。RFC 3338的作者承认Wanjik Lee的实施贡献(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.
感谢“IPv4/IPv6转换器中的碰撞”（2006年10月提交给v6ops工作组的一份文件草案）的作者P.莫斯特、L.琴和D.格林。白车身的一些想法和澄清已适用于本文件。
[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，“私人互联网地址分配”，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，“互联网协议，第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，“单播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 61452011年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，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年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 61472011年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，“使用“堆栈中的凹凸”技术（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，“使用“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，“特殊用途IPv4地址”，BCP 153，RFC 57352010年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函数，当在套接字API层实现时，这些函数将适合由BIH模块拦截。请注意，此列表并非完全详尽，因为不同API上可用的函数名和服务差异很大。
The functions that the application uses to pass addresses into the system are as follows:
应用程序用于向系统传递地址的功能如下：
bind()
绑定（）
connect()
连接（）
sendmsg()
sendmsg（）
sendto()
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()
getsocketopt（）
setsocketopt()
setsocketopt（）
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
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.
波黑可能会截获inet_ntoa（）和inet_addr（），并使用地址映射器进行这些截获。这样做使波黑能够支持文字IP地址。但是，只有在创建IPv4地址和相应IPv6地址之间的映射条目后，才能使用IPv4地址文本。
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（）调用返回地址列表。当名称解析器函数调用getaddrinfo（）并且getaddrinfo（）返回多个IP地址（无论是IPv4还是IPv6）时，它们都应该在gethostbyname（）返回的地址中表示。因此，如果getaddrinfo（）返回多个IPv6地址，这意味着将创建多个地址映射：每个IPv6地址对应一个地址映射。
Authors' Addresses
作者地址
Bill Huang China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China
中国北京市西城区宣武门西街32号黄比尔中国移动100053
EMail: bill.huang@chinamobile.com
EMail: bill.huang@chinamobile.com
Hui Deng China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China
中国北京市西城区宣武门西街32号惠登中国移动100053
EMail: denghui@chinamobile.com
EMail: denghui@chinamobile.com
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 TAMPERE Finland
Teemu Savolainen诺基亚Hermiankatu 12 D FI-33720坦佩雷芬兰
EMail: teemu.savolainen@nokia.com
EMail: teemu.savolainen@nokia.com