Internet Engineering Task Force (IETF) X. Li
Request for Comments: 7599 C. Bao
Category: Standards Track Tsinghua University
ISSN: 2070-1721 W. Dec, Ed.
O. Troan
Cisco Systems
S. Matsushima
SoftBank Telecom
T. Murakami
IP Infusion
July 2015
Internet Engineering Task Force (IETF) X. Li
Request for Comments: 7599 C. Bao
Category: Standards Track Tsinghua University
ISSN: 2070-1721 W. Dec, Ed.
O. Troan
Cisco Systems
S. Matsushima
SoftBank Telecom
T. Murakami
IP Infusion
July 2015
Mapping of Address and Port using Translation (MAP-T)
使用转换映射地址和端口（MAP-T）
Abstract
摘要
This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.
本文档指定了基于“地址和端口映射”无状态IPv6-IPv4网络地址转换（NAT64）的解决方案体系结构，以提供到IPv6网络的共享或非共享IPv4地址连接。
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/rfc7599.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7599.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Terminology .....................................................5
4. Architecture ....................................................6
5. Mapping Rules ...................................................8
5.1. Destinations outside the MAP Domain ........................8
6. The IPv6 Interface Identifier ...................................9
7. MAP-T Configuration ............................................10
7.1. MAP CE ....................................................10
7.2. MAP BR ....................................................11
8. MAP-T Packet Forwarding ........................................11
8.1. IPv4 to IPv6 at the CE ....................................11
8.2. IPv6 to IPv4 at the CE ....................................12
8.3. IPv6 to IPv4 at the BR ....................................12
8.4. IPv4 to IPv6 at the BR ....................................13
9. ICMP Handling ..................................................13
10. Fragmentation and Path MTU Discovery ..........................14
10.1. Fragmentation in the MAP Domain ..........................14
10.2. Receiving IPv4 Fragments on the MAP Domain Borders .......14
10.3. Sending IPv4 Fragments to the Outside ....................14
11. NAT44 Considerations ..........................................15
12. Usage Considerations ..........................................15
12.1. EA-Bit Length 0 ..........................................15
12.2. Mesh and Hub-and-Spoke Modes .............................15
12.3. Communication with IPv6 Servers in the MAP-T Domain ......15
12.4. Compatibility with Other NAT64 Solutions .................16
13. Security Considerations .......................................16
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................18
Appendix A. Examples of MAP-T Translation .........................21
Appendix B. Port-Mapping Algorithm ................................24
Acknowledgements ..................................................25
Contributors ......................................................25
Authors' Addresses ................................................26
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Terminology .....................................................5
4. Architecture ....................................................6
5. Mapping Rules ...................................................8
5.1. Destinations outside the MAP Domain ........................8
6. The IPv6 Interface Identifier ...................................9
7. MAP-T Configuration ............................................10
7.1. MAP CE ....................................................10
7.2. MAP BR ....................................................11
8. MAP-T Packet Forwarding ........................................11
8.1. IPv4 to IPv6 at the CE ....................................11
8.2. IPv6 to IPv4 at the CE ....................................12
8.3. IPv6 to IPv4 at the BR ....................................12
8.4. IPv4 to IPv6 at the BR ....................................13
9. ICMP Handling ..................................................13
10. Fragmentation and Path MTU Discovery ..........................14
10.1. Fragmentation in the MAP Domain ..........................14
10.2. Receiving IPv4 Fragments on the MAP Domain Borders .......14
10.3. Sending IPv4 Fragments to the Outside ....................14
11. NAT44 Considerations ..........................................15
12. Usage Considerations ..........................................15
12.1. EA-Bit Length 0 ..........................................15
12.2. Mesh and Hub-and-Spoke Modes .............................15
12.3. Communication with IPv6 Servers in the MAP-T Domain ......15
12.4. Compatibility with Other NAT64 Solutions .................16
13. Security Considerations .......................................16
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................18
Appendix A. Examples of MAP-T Translation .........................21
Appendix B. Port-Mapping Algorithm ................................24
Acknowledgements ..................................................25
Contributors ......................................................25
Authors' Addresses ................................................26
Experiences from initial service provider IPv6 network deployments, such as [RFC6219], indicate that successful transition to IPv6 can happen while supporting legacy IPv4 users without a full end-to-end dual-IP-stack deployment. However, due to public IPv4 address exhaustion, this requires an IPv6 technology that supports IPv4 users utilizing shared IPv4 addressing, while also allowing the network operator to optimize their operations around IPv6 network practices. The use of double NAT64 translation-based solutions is an optimal way to address these requirements, especially in combination with stateless translation techniques that minimize operational challenges outlined in [Solutions-4v6].
初始服务提供商IPv6网络部署（如[RFC6219]）的经验表明，在支持旧式IPv4用户而无需完全端到端双IP堆栈部署的情况下，可以成功过渡到IPv6。但是，由于公共IPv4地址耗尽，这需要一种支持IPv4用户使用共享IPv4地址的IPv6技术，同时还允许网络运营商围绕IPv6网络实践优化其操作。使用基于双NAT64翻译的解决方案是解决这些需求的最佳方式，尤其是与无状态翻译技术相结合，可以最大限度地减少[solutions-4v6]中概述的操作挑战。
The Mapping of Address and Port using Translation (MAP-T) architecture specified in this document is such a double stateless NAT64-based solution. It builds on existing stateless NAT64 techniques specified in [RFC6145], along with the stateless algorithmic address and transport-layer port-mapping scheme defined in the Mapping of Address and Port with Encapsulation (MAP-E) specification [RFC7597]. The MAP-T solution differs from MAP-E in that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as the form of IPv6 domain transport. The translation mode is considered advantageous in scenarios where the encapsulation overhead, or IPv6 operational practices (e.g., the use of IPv6-only servers, or reliance on IPv6 + protocol headers for traffic classification) rule out encapsulation. These scenarios are presented in [MAP-T-Use-Cases].
本文档中指定的使用转换（MAP-T）架构的地址和端口映射就是这样一种基于双无状态NAT64的解决方案。它基于[RFC6145]中规定的现有无状态NAT64技术，以及[RFC7597]中定义的无状态算法地址和传输层端口映射方案。MAP-T解决方案与MAP-E的不同之处在于，MAP-T使用IPv4-IPv6转换而不是封装作为IPv6域传输的形式。在封装开销或IPv6操作实践（例如，仅使用IPv6服务器，或依赖IPv6+协议头进行流量分类）排除封装的情况下，转换模式被认为是有利的。这些场景在[MAP-T-Use-Cases]中给出。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
MAP-T: Mapping of Address and Port using Translation.
MAP-T：使用转换映射地址和端口。
MAP Customer Edge (CE): A device functioning as a Customer Edge router in a MAP deployment. A typical MAP CE adopting MAP Rules will serve a residential site with one WAN-side IPv6-addressed interface and one or more LAN-side interfaces addressed using private IPv4 addressing.
地图客户边缘（CE）：在地图部署中充当客户边缘路由器的设备。采用MAP规则的典型MAP CE将服务于具有一个WAN端IPv6寻址接口和一个或多个使用专用IPv4寻址的LAN端接口的住宅站点。
MAP Border Relay (BR): A MAP-enabled router managed by the service provider at the edge of a MAP domain. A BR has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network. A MAP BR may also be referred to as simply a "BR" within the context of MAP.
地图边界中继（BR）：由服务提供商在地图域边缘管理的启用地图的路由器。BR至少有一个启用IPv6的接口和一个连接到本机IPv4网络的IPv4接口。在MAP上下文中，MAP BR也可以简称为“BR”。
MAP domain: One or more MAP CEs and BRs connected by means of an IPv6 network and sharing a common set of MAP Rules. A service provider may deploy a single MAP domain or may utilize multiple MAP domains.
映射域：一个或多个映射CE和BR通过IPv6网络连接，并共享一组公共映射规则。服务提供商可以部署单个映射域，也可以使用多个映射域。
MAP Rule: A set of parameters describing the mapping between an IPv4 prefix, IPv4 address, or shared IPv4 address and an IPv6 prefix or address. Each MAP domain uses a different mapping rule set.
映射规则：描述IPv4前缀、IPv4地址或共享IPv4地址与IPv6前缀或地址之间映射的一组参数。每个映射域使用不同的映射规则集。
MAP rule set: A rule set is composed of all the MAP Rules communicated to a device that are intended to determine the device's IP+port mapping and forwarding operations. The MAP rule set is interchangeably referred to in this document as a MAP rule table or as simply a "rule table". Two specific types of rules -- the Basic Mapping Rule (BMR) and the Forwarding Mapping Rule (FMR) -- are defined in Section 5 of [RFC7597]. The Default Mapping Rule (DMR) is defined in this document.
映射规则集：规则集由与设备通信的所有映射规则组成，这些规则用于确定设备的IP+端口映射和转发操作。地图规则集在本文档中可替换地称为地图规则表或简称为“规则表”。[RFC7597]第5节定义了两种特定类型的规则——基本映射规则（BMR）和转发映射规则（FMR）。默认映射规则（DMR）在本文档中定义。
MAP rule table: See MAP rule set.
映射规则表：请参见映射规则集。
MAP node: A device that implements MAP.
映射节点：实现映射的设备。
Port set: Each node has a separate part of the transport-layer port space; this is denoted as a port set.
端口集：每个节点都有一个单独的传输层端口空间部分；这表示为端口集。
Port Set ID (PSID): Algorithmically identifies a set of ports exclusively assigned to a CE.
端口集ID（PSID）：通过算法识别专门分配给CE的一组端口。
Shared IPv4 address: An IPv4 address that is shared among multiple CEs. Only ports that belong to the assigned port set can be used for communication. Also known as a port-restricted IPv4 address.
共享IPv4地址：在多个CE之间共享的IPv4地址。只有属于指定端口集的端口才能用于通信。也称为端口受限IPv4地址。
End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by means other than MAP itself, e.g., provisioned using DHCPv6 Prefix Delegation (PD) [RFC3633], assigned via Stateless Address Autoconfiguration (SLAAC) [RFC4862], or configured manually. It is unique for each CE.
最终用户IPv6前缀：通过MAP本身以外的方式分配给最终用户CE的IPv6前缀，例如，使用DHCPv6前缀委派（PD）[RFC3633]进行配置，通过无状态地址自动配置（SLAAC）[RFC4862]进行分配，或手动配置。它对于每个CE都是唯一的。
MAP IPv6 address: The IPv6 address used to reach the MAP function of a CE from other CEs and from BRs.
映射IPv6地址：用于从其他CE和BRs到达CE映射功能的IPv6地址。
Rule IPv6 prefix: An IPv6 prefix assigned by a service provider for a MAP Rule.
规则IPv6前缀：服务提供商为映射规则分配的IPv6前缀。
Rule IPv4 prefix: An IPv4 prefix assigned by a service provider for a MAP Rule.
规则IPv4前缀：服务提供商为映射规则分配的IPv4前缀。
Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6 address identify an IPv4 prefix/address (or part thereof) or a shared IPv4 address (or part thereof) and a Port Set Identifier.
嵌入地址（EA）位：IPv6地址中的IPv4 EA位标识IPv4前缀/地址（或其部分）或共享IPv4地址（或其部分）和端口集标识符。
Figure 1 depicts the overall MAP-T architecture, which sees any number of privately addressed IPv4 users (N and M) connected by means of MAP-T CEs to an IPv6 network that is equipped with one or more MAP-T BRs. CEs and BRs that share MAP configuration parameters, referred to as "MAP Rules", form a MAP-T domain.
图1描述了总体MAP-T体系结构，其中任意数量的专用寻址IPv4用户（N和M）通过MAP-T CE连接到配备一个或多个MAP-T BR的IPv6网络。共享MAP配置参数（称为“MAP规则”）的CE和BR构成MAP-T域。
Functionally, the MAP-T CE and BR utilize and extend some well-established technology building blocks to allow the IPv4 users to correspond with nodes on the public IPv4 network or on the IPv6 network as follows:
在功能上，MAP-T CE和BR利用并扩展了一些成熟的技术构建块，以允许IPv4用户与公共IPv4网络或IPv6网络上的节点通信，如下所示：
o A (NAT44) Network Address and Port Translation (NAPT) [RFC2663] function on a MAP CE is extended with support for restricting the allowable TCP/UDP ports for a given IPv4 address. The IPv4 address and port range used are determined by the MAP provisioning process and identical to MAP-E [RFC7597].
o MAP CE上的（NAT44）网络地址和端口转换（NAPT）[RFC2663]功能已扩展，支持限制给定IPv4地址允许的TCP/UDP端口。使用的IPv4地址和端口范围由MAP配置过程确定，与MAP-E[RFC7597]相同。
o A stateless NAT64 function [RFC6145] is extended to allow stateless mapping of IPv4 and transport-layer port ranges to the IPv6 address space.
o 扩展了无状态NAT64函数[RFC6145]，以允许IPv4和传输层端口范围到IPv6地址空间的无状态映射。
User N
Private IPv4
| Network
|
O--+---------------O
| | MAP-T CE |
| +-----+--------+ |
| NAPT44| MAP-T | |
| +-----+ | +-._ ,-------. .------.
| +--------+ | ,-' `-. ,-' `-.
O------------------O / \ O---------O / Public \
/ IPv6-only \ | MAP-T |/ IPv4 \
( Network --+ Border +- Network )
\ / | Relay |\ /
O------------------O \ / O---------O \ /
| MAP-T CE | ;". ,-' `-. ,-'
| +-----+--------+ | ," `----+--' ------'
| NAPT44| MAP-T | |, |
| +-----+ | + IPv6 node(s)
| | +--------+ | (with IPv4-embedded IPv6 address)
O---+--------------O
|
User M
Private IPv4
Network
User N
Private IPv4
| Network
|
O--+---------------O
| | MAP-T CE |
| +-----+--------+ |
| NAPT44| MAP-T | |
| +-----+ | +-._ ,-------. .------.
| +--------+ | ,-' `-. ,-' `-.
O------------------O / \ O---------O / Public \
/ IPv6-only \ | MAP-T |/ IPv4 \
( Network --+ Border +- Network )
\ / | Relay |\ /
O------------------O \ / O---------O \ /
| MAP-T CE | ;". ,-' `-. ,-'
| +-----+--------+ | ," `----+--' ------'
| NAPT44| MAP-T | |, |
| +-----+ | + IPv6 node(s)
| | +--------+ | (with IPv4-embedded IPv6 address)
O---+--------------O
|
User M
Private IPv4
Network
Figure 1: MAP-T Architecture
图1:MAP-T体系结构
Each MAP-T CE is assigned with a regular IPv6 prefix from the operator's IPv6 network. This, in conjunction with MAP domain configuration settings and the use of the MAP procedures, allows the computation of a MAP IPv6 address and a corresponding IPv4 address. To allow for IPv4 address sharing, the CE may also have to be
每个MAP-T CE都分配有来自运营商IPv6网络的常规IPv6前缀。这与映射域配置设置和映射过程的使用相结合，允许计算映射IPv6地址和相应的IPv4地址。要允许IPv4地址共享，CE可能还必须
configured with a TCP/UDP port range that is identified by means of a MAP Port Set Identifier (PSID) value. Each CE is responsible for forwarding traffic between a given user's private IPv4 address space and the MAP domain's IPv6 address space. The IPv4-IPv6 adaptation uses stateless NAT64, in conjunction with the MAP algorithm for address computation.
配置TCP/UDP端口范围，该范围通过映射端口集标识符（PSID）值标识。每个CE负责在给定用户的专用IPv4地址空间和映射域的IPv6地址空间之间转发流量。IPv4-IPv6自适应使用无状态NAT64，并结合MAP算法进行地址计算。
The MAP-T BR connects one or more MAP-T domains to external IPv4 networks using stateless NAT64 as extended by the MAP-T behavior described in this document.
MAP-T BR使用无状态NAT64将一个或多个MAP-T域连接到外部IPv4网络，如本文档中描述的MAP-T行为所扩展。
In contrast to MAP-E, NAT64 technology is used in the architecture for two purposes. First, it is intended to diminish encapsulation overhead and allow IPv4 and IPv6 traffic to be treated as similarly as possible. Second, it is intended to allow IPv4-only nodes to correspond directly with IPv6 nodes in the MAP-T domain that have IPv4-embedded IPv6 addresses as per [RFC6052].
与MAP-E不同，NAT64技术在体系结构中用于两个目的。首先，它旨在减少封装开销，并使IPv4和IPv6流量得到尽可能相似的处理。其次，其目的是允许仅IPv4节点直接对应于MAP-T域中的IPv6节点，这些节点根据[RFC6052]具有IPv4嵌入IPv6地址。
The MAP-T architecture is based on the following key properties:
MAP-T体系结构基于以下关键属性：
1. Algorithmic IPv4-IPv6 address mapping codified as MAP Rules, as described in Section 5
1. 算法IPv4-IPv6地址映射编码为映射规则，如第5节所述
2. A MAP IPv6 address identifier, as described in Section 6
2. 映射IPv6地址标识符，如第6节所述
3. MAP-T IPv4-IPv6 forwarding behavior, as described in Section 8
3. MAP-T IPv4-IPv6转发行为，如第8节所述
The MAP-T algorithmic mapping rules are identical to those in Section 5 of the MAP-E specification [RFC7597], with the following exception: the forwarding of traffic to and from IPv4 destinations outside a MAP-T domain is to be performed as described in this document, instead of Section 5.4 of the MAP-E specification.
MAP-T算法映射规则与MAP-E规范[RFC7597]第5节中的规则相同，但有以下例外：MAP-T域之外的IPv4目的地之间的流量转发将按照本文档中的描述执行，而不是MAP-E规范第5.4节。
IPv4 traffic sent by MAP nodes that are all within one MAP domain is translated to IPv6, with the sender's MAP IPv6 address, derived via the Basic Mapping Rule (BMR), as the IPv6 source address and the recipient's MAP IPv6 address, derived via the Forwarding Mapping Rule (FMR), as the IPv6 destination address.
由全部位于一个映射域内的映射节点发送的IPv4通信量被转换为IPv6，发送方的映射IPv6地址（通过基本映射规则（BMR）派生）作为IPv6源地址，接收方的映射IPv6地址（通过转发映射规则（FMR）派生）作为IPv6目标地址。
IPv4-addressed destinations outside of the MAP domain are represented by means of IPv4-embedded IPv6 addresses as per [RFC6052], using the BR's IPv6 prefix. For a CE sending traffic to any such destination, the source address of the IPv6 packet will be that of the CE's MAP IPv6 address, and the destination IPv6 address will be the
映射域之外的IPv4寻址目的地通过[RFC6052]中的IPv4嵌入IPv6地址表示，并使用BR的IPv6前缀。对于向任何此类目的地发送流量的CE，IPv6数据包的源地址将是CE的MAP IPv6地址的源地址，而目的地IPv6地址将是
destination IPv4-embedded IPv6 address. This address mapping is said to be following the MAP-T Default Mapping Rule (DMR) and is defined in terms of the IPv6 prefix advertised by one or more BRs, which provide external connectivity. A typical MAP-T CE will install an IPv4 default route using this rule. A BR will use this rule when translating all outside IPv4 source addresses to the IPv6 MAP domain.
目标IPv4嵌入IPv6地址。据说此地址映射遵循MAP-T默认映射规则（DMR），并根据一个或多个提供外部连接的BRs发布的IPv6前缀进行定义。典型的MAP-TCE将使用此规则安装IPv4默认路由。BR将所有外部IPv4源地址转换为IPv6映射域时将使用此规则。
The DMR IPv6 prefix length SHOULD be 64 bits long by default and in any case MUST NOT exceed 96 bits. The mapping of the IPv4 destination behind the IPv6 prefix will by default follow the /64 rule as per [RFC6052]. Any trailing bits after the IPv4 address are set to 0x0.
默认情况下，DMR IPv6前缀长度应为64位，并且在任何情况下都不得超过96位。默认情况下，IPv6前缀后面的IPv4目标映射将遵循[RFC6052]中的/64规则。IPv4地址之后的任何尾随位都设置为0x0。
The interface identifier format of a MAP-T node is the same as the format described in Section 6 of [RFC7597]. The format diagram is provided here for convenience:
MAP-T节点的接口标识符格式与[RFC7597]第6节中描述的格式相同。为方便起见，此处提供了格式图：
| 128-n-o-s bits |
| 16 bits| 32 bits | 16 bits|
+--------+----------------+--------+
| 0 | IPv4 address | PSID |
+--------+----------------+--------+
| 128-n-o-s bits |
| 16 bits| 32 bits | 16 bits|
+--------+----------------+--------+
| 0 | IPv4 address | PSID |
+--------+----------------+--------+
Figure 2: IPv6 Interface Identifier
图2:IPv6接口标识符
In the case of an IPv4 prefix, the IPv4 address field is right-padded with zeros up to 32 bits. The PSID is left-padded with zeros to create a 16-bit field. For an IPv4 prefix or a complete IPv4 address, the PSID field is zero.
在IPv4前缀的情况下，IPv4地址字段用最多32位的零进行右填充。PSID用零填充，以创建一个16位字段。对于IPv4前缀或完整的IPv4地址，PSID字段为零。
If the End-user IPv6 prefix length is larger than 64, the most significant parts of the interface identifier are overwritten by the prefix.
如果最终用户IPv6前缀长度大于64，则接口标识符的最重要部分将被前缀覆盖。
For a given MAP domain, the BR and CE MUST be configured with the following MAP parameters. The values for these parameters are identical for all CEs and BRs within a given MAP-T domain.
对于给定的映射域，必须使用以下映射参数配置BR和CE。这些参数的值对于给定MAP-T域内的所有CE和BR都是相同的。
o The Basic Mapping Rule and, optionally, the Forwarding Mapping Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and Length of embedded address bits
o 基本映射规则和转发映射规则（可选），包括规则IPv6前缀、规则IPv4前缀和嵌入地址位的长度
o Use of hub-and-spoke mode or Mesh mode (if all traffic should be sent to the BR, or if direct CE-to-CE correspondence should be supported)
o 使用中心辐射模式或网状模式（如果所有流量都应发送到BR，或者如果应支持直接CE到CE通信）
o Use of IPv4-IPv6 translation (MAP-T)
o IPv4-IPv6转换（MAP-T）的使用
o The BR's IPv6 prefix used in the DMR
o 在DMR中使用的BR的IPv6前缀
For a given MAP domain, the MAP configuration parameters are the same across all CEs within that domain. These values may be conveyed and configured on the CEs using a variety of methods, including DHCPv6, the Broadband Forum's "TR-69" Residential Gateway management interface [TR069], the Network Configuration Protocol (NETCONF), or manual configuration. This document does not prescribe any of these methods but recommends that a MAP CE SHOULD implement DHCPv6 options as per [RFC7598]. Other configuration and management methods may use the data model described by this option for consistency and convenience of implementation on CEs that support multiple configuration methods.
对于给定的映射域，该域内所有CE的映射配置参数都相同。可以使用多种方法在CEs上传送和配置这些值，包括DHCPv6、宽带论坛的“TR-69”住宅网关管理接口[TR069]、网络配置协议（NETCONF）或手动配置。本文件未规定任何这些方法，但建议MAP CE按照[RFC7598]实施DHCPv6选项。为了在支持多种配置方法的CE上实现一致性和方便性，其他配置和管理方法可以使用此选项描述的数据模型。
Besides the MAP configuration parameters, a CE requires an IPv6 prefix to be assigned to the CE. This End-user IPv6 prefix is configured as part of obtaining IPv6 Internet access and is acquired using standard IPv6 means applicable in the network where the CE is located.
除了映射配置参数外，CE还需要向CE分配IPv6前缀。此最终用户IPv6前缀配置为获取IPv6 Internet访问的一部分，并使用适用于CE所在网络的标准IPv6方式获取。
The MAP provisioning parameters, and hence the IPv4 service itself, are tied to the End-user IPv6 prefix; thus, the MAP service is also tied to this in terms of authorization, accounting, etc.
映射配置参数以及IPv4服务本身都与最终用户IPv6前缀相关联；因此，地图服务在授权、记帐等方面也与此相关。
A single MAP CE MAY be connected to more than one MAP domain, just as any router may have more than one IPv4-enabled service-provider-facing interface and more than one set of associated addresses assigned by DHCPv6. Each domain within which a given CE operates
一个MAP CE可以连接到多个MAP域，就像任何路由器都可以具有多个支持IPv4的面向服务提供商的接口和多组由DHCPv6分配的关联地址一样。给定CE运行的每个域
would require its own set of MAP configuration elements and would generate its own IPv4 address. Each MAP domain requires a distinct End-user IPv6 prefix.
将需要自己的一组映射配置元素，并将生成自己的IPv4地址。每个映射域都需要不同的最终用户IPv6前缀。
The MAP BR MUST be configured with the same MAP elements as the MAP CEs operating within the same domain.
映射BR必须配置与在同一域中运行的映射ce相同的映射元素。
For increased reliability and load balancing, the BR IPv6 prefix MAY be shared across a given MAP domain. As MAP is stateless, any BR may be used for forwarding to/from the domain at any time.
为了提高可靠性和负载平衡，BR IPv6前缀可以在给定的映射域中共享。由于MAP是无状态的，因此任何BR都可用于在任何时间向域转发或从域转发。
Since MAP uses provider address space, no specific IPv6 or IPv4 routes need to be advertised externally outside the service provider's network for MAP to operate. However, the BR prefix needs to be advertised in the service provider's IGP.
由于MAP使用提供商地址空间，因此无需在服务提供商网络外部公布特定的IPv6或IPv4路由，MAP即可运行。但是，BR前缀需要在服务提供商的IGP中公布。
The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet being forwarded by a CE or BR in one of two directions for each such case. This section presents a conceptual view of the operations involved in such forwarding.
MAP-T中的端到端分组流涉及由CE或BR在针对每种情况的两个方向之一转发的IPv4或IPv6分组。本节介绍了此类转发中涉及的操作的概念视图。
A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing and create any necessary NAPT44 bindings. The source address and source port range of packets resulting from the NAPT44 processing MUST correspond to the source IPv4 address and source transport port range assigned to the CE by means of the MAP Basic Mapping Rule (BMR).
接收IPv4数据包的MAP-T CE应执行NAPT44处理并创建任何必要的NAPT44绑定。NAPT44处理产生的数据包的源地址和源端口范围必须对应于通过映射基本映射规则（BMR）分配给CE的源IPv4地址和源传输端口范围。
The IPv4 packet is subject to a longest IPv4 destination address + port match MAP Rule selection, which then determines the parameters for the subsequent NAT64 operation. By default, all traffic is matched to the DMR and is subject to the stateless NAT64 operation using the DMR parameters for NAT64 (Section 5.1). Packets that are matched to (optional) Forwarding Mapping Rules (FMRs) are subject to the stateless NAT64 operation using the FMR parameters (Section 5) for the MAP algorithm. In all cases, the CE's MAP IPv6 address (Section 6) is used as a source address.
IPv4数据包受最长IPv4目标地址+端口匹配映射规则选择的约束，该规则随后确定后续NAT64操作的参数。默认情况下，所有通信量都与DMR匹配，并使用NAT64的DMR参数进行无状态NAT64操作（第5.1节）。与（可选）转发映射规则（FMR）匹配的数据包将使用映射算法的FMR参数（第5节）进行无状态NAT64操作。在所有情况下，CE的MAP IPv6地址（第6节）都用作源地址。
A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one or more Forwarding Mapping Rules.
MAP-T CE必须支持默认映射规则，并应支持一个或多个转发映射规则。
A MAP-T CE receiving an IPv6 packet performs its regular IPv6 operations (filtering, pre-routing, etc.). Only packets that are addressed to the CE's MAP-T IPv6 addresses, and with source addresses matching the IPv6 MAP Rule prefixes of a DMR or FMR, are processed by the MAP-T CE, with the DMR or FMR being selected based on a longest match. The CE MUST check that each MAP-T received packet's transport-layer destination port number is in the range allowed for by the CE's MAP BMR configuration. The CE MUST silently drop any nonconforming packet and increment an appropriate counter. When receiving a packet whose source IP address longest matches an FMR prefix, the CE MUST perform a check of consistency of the source address against the allowed values as per the derived allocated source port range. If the source port number of a packet is found to be outside the allocated range, the CE MUST drop the packet and SHOULD respond with an ICMPv6 "Destination Unreachable, source address failed ingress/egress policy" (Type 1, Code 5).
接收IPv6数据包的MAP-TCE执行其常规IPv6操作（过滤、预路由等）。MAP-T CE仅处理发往CE的MAP-T IPv6地址且源地址与DMR或FMR的IPv6 MAP规则前缀匹配的数据包，DMR或FMR基于最长匹配进行选择。CE必须检查每个MAP-T接收数据包的传输层目的地端口号是否在CE的MAP BMR配置允许的范围内。CE必须悄悄地丢弃任何不符合要求的数据包，并增加适当的计数器。当接收到源IP地址最长与FMR前缀匹配的数据包时，CE必须根据派生的分配源端口范围，根据允许值检查源地址的一致性。如果发现数据包的源端口号超出分配的范围，CE必须丢弃该数据包，并应使用ICMPv6“目的地不可到达，源地址失败的入口/出口策略”（类型1，代码5）进行响应。
For each MAP-T processed packet, the CE's NAT64 function MUST compute an IPv4 source and destination address. The IPv4 destination address is computed by extracting relevant information from the IPv6 destination and the information stored in the BMR as per Section 5. The IPv4 source address is formed by classifying a packet's source as longest matching a DMR or FMR rule prefix, and then using the respective rule parameters for the NAT64 operation.
对于每个MAP-T处理的数据包，CE的NAT64函数必须计算IPv4源地址和目标地址。根据第5节，通过从IPv6目标和BMR中存储的信息提取相关信息来计算IPv4目标地址。IPv4源地址是通过将数据包的源分类为与DMR或FMR规则前缀匹配的最长源，然后使用NAT64操作的相应规则参数形成的。
The resulting IPv4 packet is then forwarded to the CE's NAPT44 function, where the destination IPv4 address and port number MUST be mapped to their original value before being forwarded according to the CE's regular IPv4 rules. When the NAPT44 function is not enabled, by virtue of MAP configuration, the traffic from the stateless NAT64 function is directly forwarded according to the CE's IPv4 rules.
然后，生成的IPv4数据包被转发到CE的NAPT44函数，在根据CE的常规IPv4规则转发之前，目标IPv4地址和端口号必须映射到其原始值。当NAPT44功能未启用时，通过映射配置，来自无状态NAT64功能的流量将根据CE的IPv4规则直接转发。
A MAP-T BR receiving an IPv6 packet MUST select a matching MAP Rule based on a longest address match of the packet's source address against the MAP Rules present on the BR. In combination with the Port Set ID derived from the packet's source IPv6 address, the selected MAP Rule allows the BR to verify that the CE is using its allowed address and port range. Thus, the BR MUST perform a validation of the consistency of the source against the allowed values from the identified port range. If the packet's source port number is found to be outside the range allowed, the BR MUST drop the
接收IPv6数据包的MAP-T BR必须根据数据包源地址与BR上存在的MAP规则的最长地址匹配来选择匹配的MAP规则。结合从数据包的源IPv6地址派生的端口集ID，所选映射规则允许BR验证CE是否正在使用其允许的地址和端口范围。因此，BR必须根据识别端口范围中的允许值验证源的一致性。如果发现数据包的源端口号超出允许的范围，BR必须删除
packet and increment a counter to indicate the event. The BR SHOULD also respond with an ICMPv6 "Destination Unreachable, source address failed ingress/egress policy" (Type 1, Code 5).
数据包并递增一个计数器以指示事件。BR还应使用ICMPv6“目标不可到达，源地址失败的入口/出口策略”（类型1，代码5）进行响应。
When constructing the IPv4 packet, the BR MUST derive the source and destination IPv4 addresses as per Section 5 of this document and translate the IPv6-to-IPv4 headers as per [RFC6145]. The resulting IPv4 packet is then passed to regular IPv4 forwarding.
在构造IPv4数据包时，BR必须根据本文档第5节推导出源IPv4地址和目标IPv4地址，并根据[RFC6145]将IPv6头转换为IPv4头。然后将生成的IPv4数据包传递给常规IPv4转发。
A MAP-T BR receiving IPv4 packets uses a longest match IPv4 + transport-layer port lookup to identify the target MAP-T domain and select the FMR and DMR rules. The MAP-T BR MUST then compute and apply the IPv6 destination addresses from the IPv4 destination address and port as per the selected FMR. The MAP-T BR MUST also compute and apply the IPv6 source addresses from the IPv4 source address as per Section 5.1 (i.e., using the IPv4 source and the BR's IPv6 prefix, it forms an IPv6-embedded IPv4 address). The generic IPv4-to-IPv6 header translation procedures outlined in [RFC6145] apply throughout. The resulting IPv6 packets are then passed to regular IPv6 forwarding.
接收IPv4数据包的MAP-T BR使用最长匹配IPv4+传输层端口查找来识别目标MAP-T域并选择FMR和DMR规则。然后，MAP-T BR必须根据所选FMR从IPv4目标地址和端口计算并应用IPv6目标地址。MAP-T BR还必须根据第5.1节从IPv4源地址计算并应用IPv6源地址（即，使用IPv4源和BR的IPv6前缀，形成IPv6嵌入IPv4地址）。[RFC6145]中概述的通用IPv4到IPv6报头转换过程适用于整个过程。生成的IPv6数据包随后被传递到常规IPv6转发。
Note that the operation of a BR, when forwarding to/from MAP-T domains that are defined without IPv4 address sharing, is the same as that of stateless NAT64 IPv4/IPv6 translation.
请注意，在向未定义IPv4地址共享的MAP-T域转发或从MAP-T域转发时，BR的操作与无状态NAT64 IPv4/IPv6转换的操作相同。
MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per [RFC6145]; however, additional behavior is also required due to the presence of NAPT44. Unlike TCP and UDP, which provide two transport-protocol port fields to represent both source and destination, the ICMP/ICMPv6 [RFC792] [RFC4443] Query message header has only one ID field, which needs to be used to identify a sending IPv4 host. When receiving IPv4 ICMP messages, the MAP-T CE MUST rewrite the ID field to a port value derived from the CE's Port Set ID.
MAP-T CE和BRs必须按照[RFC6145]遵循ICMP/ICMPv6翻译；但是，由于NAPT44的存在，还需要其他行为。与TCP和UDP不同，TCP和UDP提供两个传输协议端口字段来表示源和目标，ICMP/ICMPv6[RFC792][RFC4443]查询消息头只有一个ID字段，需要使用该字段来标识发送IPv4的主机。接收IPv4 ICMP消息时，MAP-T CE必须将ID字段重写为从CE的端口集ID派生的端口值。
A MAP-T BR receiving an IPv4 ICMP packet that contains an ID field that is bound for a shared address in the MAP-T domain SHOULD use the ID value as a substitute for the destination port in determining the IPv6 destination address. In all other cases, the MAP-T BR MUST derive the destination IPv6 address by simply mapping the destination IPv4 address without additional port information.
接收到IPv4 ICMP数据包（包含绑定到MAP-T域中共享地址的ID字段）的MAP-T BR在确定IPv6目标地址时，应使用ID值作为目标端口的替代值。在所有其他情况下，MAP-T BR必须通过简单地映射目标IPv4地址而无需其他端口信息来派生目标IPv6地址。
Due to the different sizes of the IPv4 and IPv6 headers, handling the maximum packet size is relevant for the operation of any system connecting the two address families. There are three mechanisms to handle this issue: Path MTU Discovery (PMTUD), fragmentation, and transport-layer negotiation such as the TCP Maximum Segment Size (MSS) option [RFC879]. MAP can use all three mechanisms to deal with different cases.
由于IPv4和IPv6报头的大小不同，处理最大数据包大小与连接两个地址系列的任何系统的操作相关。有三种机制来处理此问题：路径MTU发现（PMTUD）、分段和传输层协商，如TCP最大段大小（MSS）选项[RFC879]。MAP可以使用这三种机制来处理不同的情况。
Note: The NAT64 [RFC6145] mechanism is not lossless. When IPv4-originated communication traverses a double NAT64 function (a.k.a. NAT464), any IPv4-originated ICMP-independent Path MTU Discovery, as specified in [RFC4821], ceases to be entirely reliable. This is because the DF=1/MF=1 combination as defined in [RFC4821] results in DF=0/MF=1 after a double NAT64 translation.
注意：NAT64[RFC6145]机制不是无损的。当源自IPv4的通信通过双NAT64函数（也称为NAT464）时，[RFC4821]中规定的源自IPv4的ICMP独立路径MTU发现将不再完全可靠。这是因为[RFC4821]中定义的DF=1/MF=1组合在双NAT64转换后产生DF=0/MF=1。
Translating an IPv4 packet to carry it across the MAP domain will increase its size (typically by 20 bytes). The MTU in the MAP domain should be well managed, and the IPv6 MTU on the CE WAN-side interface SHOULD be configured so that no fragmentation occurs within the boundary of the MAP domain.
将IPv4数据包转换为在MAP域中传输会增加其大小（通常为20字节）。MAP域中的MTU应得到良好管理，CE WAN端接口上的IPv6 MTU应进行配置，以确保MAP域边界内不会出现碎片。
Fragmentation in MAP-T domains SHOULD be handled as described in Sections 4 and 5 of [RFC6145].
MAP-T域中的碎片应按照[RFC6145]第4节和第5节所述进行处理。
The forwarding of an IPv4 packet received from outside of the MAP domain requires the IPv4 destination address and the transport-protocol destination port. The transport-protocol information is only available in the first fragment received. As described in Section 5.3.3 of [RFC6346], a MAP node receiving an IPv4 fragmented packet from outside SHOULD reassemble the packet before sending the packet onto the MAP domain. If the first packet received contains the transport-protocol information, it is possible to optimize this behavior by using a cache and forwarding the fragments unchanged. A description of such a caching algorithm is outside the scope of this document.
转发从映射域外部接收的IPv4数据包需要IPv4目标地址和传输协议目标端口。传输协议信息仅在接收到的第一个片段中可用。如[RFC6346]第5.3.3节所述，从外部接收IPv4碎片数据包的MAP节点应在将数据包发送到MAP域之前重新组装数据包。如果接收到的第一个数据包包含传输协议信息，则可以通过使用缓存并转发未更改的片段来优化此行为。此类缓存算法的描述不在本文档的范围内。
Two IPv4 hosts behind two different MAP CEs with the same IPv4 address sending fragments to an IPv4 destination host outside the domain may happen to use the same IPv4 fragmentation identifier, resulting in incorrect reassembly of the fragments at the destination
在两个具有相同IPv4地址的不同映射CE后面向域外的IPv4目标主机发送片段的两个IPv4主机可能恰好使用相同的IPv4片段标识符，从而导致在目标主机上错误地重新组装片段
host. Given that the IPv4 fragmentation identifier is a 16-bit field, it can be used similarly to port ranges. Thus, a MAP CE SHOULD rewrite the IPv4 fragmentation identifier to a value equivalent to a port of its allocated port set.
主办考虑到IPv4分段标识符是一个16位字段，它可以类似于端口范围来使用。因此，映射CE应该将IPv4分段标识符重写为与其分配的端口集的端口等效的值。
The NAT44 implemented in the MAP CE SHOULD conform to the behavior and best current practices documented in [RFC4787], [RFC5508], and [RFC5382]. In MAP address-sharing mode (determined by the MAP domain / rule configuration parameters), the operation of the NAT44 MUST be restricted to the available port numbers derived via the Basic Mapping Rule.
MAP CE中实现的NAT44应符合[RFC4787]、[RFC5508]和[RFC5382]中记录的行为和最佳当前实践。在映射地址共享模式下（由映射域/规则配置参数确定），NAT44的操作必须限制为通过基本映射规则导出的可用端口号。
The MAP solution supports the use and configuration of domains where a BMR expresses an EA-bit length of 0. This results in independence between the IPv6 prefix assigned to the CE and the IPv4 address and/or port range used by MAP. The k-bits of PSID information may in this case be derived from the BMR.
MAP解决方案支持使用和配置BMR表示EA位长度为0的域。这将导致分配给CE的IPv6前缀与MAP使用的IPv4地址和/或端口范围之间的独立性。在这种情况下，PSID信息的k位可以从BMR导出。
The constraint imposed is that each such MAP domain be composed of just one MAP CE that has a predetermined IPv6 end-user prefix. The BR would be configured with an FMR for each such Customer Premises Equipment (CPE), where the rule would uniquely associate the IPv4 address + optional PSID and the IPv6 prefix of that given CE.
施加的约束是，每个这样的映射域仅由一个具有预定IPv6最终用户前缀的映射CE组成。BR将为每个此类客户场所设备（CPE）配置FMR，其中规则将唯一地关联IPv4地址+可选PSID和给定CE的IPv6前缀。
The hub-and-spoke mode of communication, whereby all traffic sent by a MAP-T CE is forwarded via a BR, and the Mesh mode, whereby a CE is directly able to forward traffic to another CE, are governed by the activation of Forwarding Mapping Rules that cover the IPv4-prefix destination and port-index range. By default, a MAP CE configured only with a BMR, as per this specification, will use it to configure its IPv4 parameters and IPv6 MAP address without enabling Mesh mode.
集线器辐射式通信模式（MAP-T CE发送的所有通信量通过BR转发）和网状模式（CE可以直接转发通信量到另一个CE）由覆盖IPv4前缀目的地和端口索引范围的转发映射规则的激活控制。默认情况下，根据此规范，仅使用BMR配置的映射CE将使用它来配置其IPv4参数和IPv6映射地址，而不启用网格模式。
By default, MAP-T allows communication between both IPv4-only and any IPv6-enabled devices, as well as with native IPv6-only servers, provided that the servers are configured with an IPv4-mapped IPv6 address. This address could be part of the IPv6 prefix used by the DMR in the MAP-T domain. Such IPv6 servers (e.g., an HTTP server or a web content cache device) are thus able to serve IPv6 users and
默认情况下，MAP-T允许仅IPv4和任何启用IPv6的设备之间以及与仅本机IPv6服务器之间的通信，前提是这些服务器配置了IPv4映射的IPv6地址。此地址可能是MAP-T域中DMR使用的IPv6前缀的一部分。这样的IPv6服务器（例如HTTP服务器或web内容缓存设备）就能够为IPv6用户和用户提供服务
IPv4-only users alike, utilizing IPv6. Any such IPv6-only servers SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147] will be required only when IPv6 servers in the MAP-T domain are themselves expected to initiate communication to external IPv4-only hosts.
仅IPv4用户相同，使用IPv6。任何此类仅限IPv6的服务器在DNS中都应具有A和AAAA记录。只有当MAP-T域中的IPv6服务器本身需要启动与仅限IPv4的外部主机的通信时，才需要DNS64[RFC6147]。
The MAP-T CE's NAT64 function is by default compatible for use with [RFC6146] stateful NAT64 devices that are placed in the operator's network. In such a case, the MAP-T CE's DMR prefix is configured to correspond to the NAT64 device prefix. This in effect allows the use of MAP-T CEs in environments that need to perform statistical multiplexing of IPv4 addresses, while utilizing stateful NAT64 devices, and can take the role of a customer-side translator (CLAT) as defined in [RFC6877].
默认情况下，MAP-T CE的NAT64功能与位于运营商网络中的[RFC6146]有状态NAT64设备兼容。在这种情况下，MAP-tce的DMR前缀被配置为对应于NAT64设备前缀。这实际上允许在需要执行IPv4地址统计多路复用的环境中使用MAP-T CE，同时使用有状态NAT64设备，并且可以扮演[RFC6877]中定义的客户端转换器（CLAT）的角色。
Spoofing attacks: With consistency checks between IPv4 and IPv6 sources that are performed on IPv4/IPv6 packets received by MAP nodes, MAP does not introduce any new opportunity for spoofing attacks that would not already exist in IPv6.
欺骗攻击：通过对MAP节点接收的IPv4/IPv6数据包执行IPv4和IPv6源之间的一致性检查，MAP不会为IPv6中不存在的欺骗攻击带来任何新机会。
Denial-of-service attacks: In MAP domains where IPv4 addresses are shared, the fact that IPv4 datagram reassembly may be necessary introduces an opportunity for DoS attacks. This is inherent in address sharing and is common with other address-sharing approaches such as Dual-Stack Lite (DS-Lite) and NAT64/DNS64. The best protection against such attacks is to accelerate IPv6 support in both clients and servers.
拒绝服务攻击：在共享IPv4地址的映射域中，可能需要重新组装IPv4数据报这一事实为DoS攻击提供了机会。这是地址共享中固有的，与其他地址共享方法（如双栈Lite（DS Lite）和NAT64/DNS64）相同。针对此类攻击的最佳保护措施是加快客户端和服务器对IPv6的支持。
Routing loop attacks: Routing loop attacks may exist in some "automatic tunneling" scenarios and are documented in [RFC6324]. They cannot exist with MAP because each BR checks that the IPv6 source address of a received IPv6 packet is a CE address based on the Forwarding Mapping Rule.
路由循环攻击：路由循环攻击可能存在于某些“自动隧道”场景中，并记录在[RFC6324]中。它们不能与MAP一起存在，因为每个BR根据转发映射规则检查接收到的IPv6数据包的IPv6源地址是否为CE地址。
Attacks facilitated by restricted port set: From hosts that are not subject to ingress filtering [RFC2827], an attacker can inject spoofed packets during ongoing transport connections [RFC4953] [RFC5961] [RFC6056]. The attacks depend on guessing which ports are currently used by target hosts. Using an unrestricted port set is preferable, i.e., using native IPv6 connections that are not subject to MAP port-range restrictions. To minimize these types of attacks when using a restricted port set, the MAP CE's NAT44 filtering behavior SHOULD be "Address-Dependent Filtering" as described in Section 5 of [RFC4787]. Furthermore, the MAP CEs SHOULD use a DNS transport proxy function to handle DNS traffic
受限端口集促成的攻击：来自不受入口过滤[RFC2827]约束的主机，攻击者可以在正在进行的传输连接[RFC4953][RFC5961][RFC6056]期间注入伪造数据包。攻击取决于猜测目标主机当前使用的端口。最好使用不受限制的端口集，即使用不受映射端口范围限制的本机IPv6连接。为了在使用受限端口集时最小化这些类型的攻击，MAP CE的NAT44过滤行为应为[RFC4787]第5节中所述的“地址相关过滤”。此外，MAP CEs应使用DNS传输代理功能来处理DNS流量
and source such traffic from IPv6 interfaces not assigned to MAP-T. Practicalities of these methods are discussed in Section 5.9 of [Stateless-4Via6].
并从未分配给MAP-T的IPv6接口中获取此类流量。这些方法的实用性在[无状态-4Via6]的第5.9节中讨论。
ICMP Flooding: Given the necessity to process and translate ICMP and ICMPv6 messages by the BR and CE nodes, a foreseeable attack vector is that of a flood of such messages leading to a saturation of the node's ICMP computing resources. This attack vector is not specific to MAP, and its mitigation lies in a combination of policing the rate of ICMP messages, policing the rate at which such messages can get processed by the MAP nodes, and of course identifying and blocking off the source(s) of such traffic.
ICMP洪水：由于必须处理和翻译ICP和ICMPv6消息，由BR和CE节点，可预见的攻击向量是这样的消息的洪流导致节点的ICMP计算资源饱和。这种攻击向量不是特定于MAP的，其缓解在于组合ICMP消息的速率，管理这些消息可以由MAP节点处理的速率，当然也识别和阻断这种流量的源。
[RFC6269] outlines general issues with IPv4 address sharing.
[RFC6269]概述了IPv4地址共享的一般问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052，DOI 10.17487/RFC6052，2010年10月<http://www.rfc-editor.org/info/rfc6052>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 6145DOI 10.17487/RFC6145，2011年4月<http://www.rfc-editor.org/info/rfc6145>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.
[RFC6346]Bush，R.，Ed.，“IPv4地址短缺的地址加端口（A+P）方法”，RFC 6346，DOI 10.17487/RFC6346，2011年8月<http://www.rfc-editor.org/info/rfc6346>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.
[RFC7597]Troan，O.，Ed.，Dec，W.，Li，X.，Bao，C.，Matsushima，S.，Murakami，T.，和T.Taylor，Ed.，“地址和端口的封装映射（MAP-E）”，RFC 7597，DOI 10.17487/RFC7597，2015年7月<http://www.rfc-editor.org/info/rfc7597>.
[MAP-T-Use-Cases] Maglione, R., Ed., Dec, W., Leung, I., and E. Mallette, "Use cases for MAP-T", Work in Progress, draft-maglione-softwire-map-t-scenarios-05, October 2014.
[MAP-T-用例]Maglione，R.，Ed.，Dec，W.，Leung，I.，和E.Mallette，“MAP-T的用例”，正在进行的工作，草稿-Maglione-softwire-MAP-T-scenarios-052014年10月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，DOI 10.17487/RFC0792，1981年9月<http://www.rfc-editor.org/info/rfc792>.
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, <http://www.rfc-editor.org/info/rfc879>.
[RFC879]Postel，J.，“TCP最大段大小和相关主题”，RFC 879，DOI 10.17487/RFC0879，1983年11月<http://www.rfc-editor.org/info/rfc879>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，DOI 10.17487/RFC2663，1999年8月<http://www.rfc-editor.org/info/rfc2663>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，DOI 10.17487/RFC4443，2006年3月<http://www.rfc-editor.org/info/rfc4443>.
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，DOI 10.17487/RFC4787，2007年1月<http://www.rfc-editor.org/info/rfc4787>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<http://www.rfc-editor.org/info/rfc4821>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <http://www.rfc-editor.org/info/rfc4953>.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，DOI 10.17487/RFC4953，2007年7月<http://www.rfc-editor.org/info/rfc4953>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，DOI 10.17487/RFC5382，2008年10月<http://www.rfc-editor.org/info/rfc5382>.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, DOI 10.17487/RFC5508, April 2009, <http://www.rfc-editor.org/info/rfc5508>.
[RFC5508]Srisuresh，P.，Ford，B.，Sivakumar，S.，和S.Guha，“ICMP的NAT行为要求”，BCP 148，RFC 5508，DOI 10.17487/RFC5508，2009年4月<http://www.rfc-editor.org/info/rfc5508>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <http://www.rfc-editor.org/info/rfc5961>.
[RFC5961]Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，RFC 5961，DOI 10.17487/RFC5961，2010年8月<http://www.rfc-editor.org/info/rfc5961>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056]Larsen，M.和F.Gont，“运输协议端口随机化建议”，BCP 156，RFC 6056，DOI 10.17487/RFC6056，2011年1月<http://www.rfc-editor.org/info/rfc6056>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<http://www.rfc-editor.org/info/rfc6146>.
[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, DOI 10.17487/RFC6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 6147，DOI 10.17487/RFC6147，2011年4月<http://www.rfc-editor.org/info/rfc6147>.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, DOI 10.17487/RFC6219, May 2011, <http://www.rfc-editor.org/info/rfc6219>.
[RFC6219]Li，X.，Bao，C.，Chen，M.，Zhang，H.，和J.Wu，“针对IPv4/IPv6共存和过渡的中国教育和研究网络（CERNET）IVI翻译设计和部署”，RFC 6219，DOI 10.17487/RFC6219，2011年5月<http://www.rfc-editor.org/info/rfc6219>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年6月<http://www.rfc-editor.org/info/rfc6269>.
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, <http://www.rfc-editor.org/info/rfc6324>.
[RFC6324]Nakbly，G.和F.Templin，“使用IPv6自动隧道的路由循环攻击：问题陈述和建议的缓解措施”，RFC 6324DOI 10.17487/RFC6324，2011年8月<http://www.rfc-editor.org/info/rfc6324>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，DOI 10.17487/RFC6877，2013年4月<http://www.rfc-editor.org/info/rfc6877>.
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, <http://www.rfc-editor.org/info/rfc7598>.
[RFC7598]Mrugalski，T.，Troan，O.，Farrer，I.，Perreault，S.，Dec，W.，Bao，C.，Yeh，L.，和X.Deng，“用于配置软线地址和端口映射客户端的DHCPv6选项”，RFC 7598，DOI 10.17487/RFC7598，2015年7月<http://www.rfc-editor.org/info/rfc7598>.
[Solutions-4v6] Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", Work in Progress, draft-ietf-softwire-stateless-4v6-motivation-05, November 2012.
[Solutions-4v6]Boucadair，M.，Ed.，Matsushima，S.，Lee，Y.，Bonness，O.，Borges，I.，和G.Chen，“基于IPv6的载波端无状态IPv4迁移解决方案的动机”，正在进行中的工作，草稿-ietf-softwire-Stateless-4v6-motive-052012年11月。
[Stateless-4Via6] Dec, W., Asati, R., Bao, C., Deng, H., and M. Boucadair, "Stateless 4Via6 Address Sharing", Work in Progress, draft-dec-stateless-4v6-04, October 2011.
[无状态4Via6]Dec，W.，Asati，R.，Bao，C.，Deng，H.，和M.Boucadair，“无状态4Via6地址共享”，正在进行的工作，草稿-Dec-无状态-4v6-042011年10月。
[TR069] Broadband Forum TR-069, "CPE WAN Management Protocol", Amendment 5, CWMP Version: 1.4, November 2013, <https://www.broadband-forum.org>.
[TR069]宽带论坛TR-069，“CPE WAN管理协议”，修正案5，CWMP版本：1.42013年11月<https://www.broadband-forum.org>.
Example 1 - Basic Mapping Rule:
示例1-基本映射规则：
Given the following MAP domain information and IPv6 end-user prefix assigned to a MAP CE:
给定分配给地图CE的以下地图域信息和IPv6最终用户前缀：
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix),
16 (Rule EA-bit length)}
PSID length: (16 - (32 - 24) = 8 (sharing ratio of 256)
PSID offset: 6 (default)
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix),
16 (Rule EA-bit length)}
PSID length: (16 - (32 - 24) = 8 (sharing ratio of 256)
PSID offset: 6 (default)
A MAP node (CE or BR) can, via the BMR or equivalent FMR, determine the IPv4 address and port set as shown below:
映射节点（CE或BR）可以通过BMR或等效FMR确定IPv4地址和端口集，如下所示：
EA bits offset: 40
IPv4 suffix bits (p): Length of IPv4 address (32) -
IPv4 prefix length (24) = 8
IPv4 address: 192.0.2.18 (0xc0000212)
PSID start: 40 + p = 40 + 8 = 48
PSID length (q): o - p = (End-user prefix len -
Rule IPv6 prefix len) - p
= (56 - 40) - 8 = 8
PSID: 0x34
EA bits offset: 40
IPv4 suffix bits (p): Length of IPv4 address (32) -
IPv4 prefix length (24) = 8
IPv4 address: 192.0.2.18 (0xc0000212)
PSID start: 40 + p = 40 + 8 = 48
PSID length (q): o - p = (End-user prefix len -
Rule IPv6 prefix len) - p
= (56 - 40) - 8 = 8
PSID: 0x34
Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723
Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723
The BMR information allows a MAP CE to determine (complete) its IPv6 address within the indicated End-user IPv6 prefix.
BMR信息允许MAP CE在指定的最终用户IPv6前缀内确定（完成）其IPv6地址。
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
Example 2 - BR:
例2-BR：
Another example is a MAP-T BR configured with the following FMR when receiving a packet with the following characteristics:
另一个示例是在接收具有以下特征的数据包时配置有以下FMR的MAP-T BR：
IPv4 source address: 10.2.3.4 (0x0a020304) TCP source port: 80 IPv4 destination address: 192.0.2.18 (0xc0000212) TCP destination port: 1232
IPv4源地址：10.2.3.4（0x0a020304）TCP源端口：80 IPv4目标地址：192.0.2.18（0xc0000212）TCP目标端口：1232
Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix),
16 (Rule EA-bit length)}
Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix),
16 (Rule EA-bit length)}
MAP-T BR Prefix (DMR): 2001:db8:ffff::/64
MAP-T BR Prefix (DMR): 2001:db8:ffff::/64
The above information allows the BR to derive the mapped destination IPv6 address for the corresponding MAP-T CE, and also the source IPv6 address for the mapped IPv4 source address, as follows:
上述信息允许BR导出对应MAP-T CE的映射目标IPv6地址，以及映射IPv4源地址的源IPv6地址，如下所示：
IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
PSID length: 8
PSID: 0 x34 (1232)
IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
PSID length: 8
PSID: 0 x34 (1232)
The resulting IPv6 packet will have the following header fields:
生成的IPv6数据包将具有以下标头字段：
IPv6 source address: 2001:db8:ffff:0:000a:0203:0400::
IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
TCP source port: 80
TCP destination port: 1232
IPv6 source address: 2001:db8:ffff:0:000a:0203:0400::
IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
TCP source port: 80
TCP destination port: 1232
Example 3 - FMR:
示例3-FMR：
An IPv4 host behind a MAP-T CE (configured as per the previous examples) corresponding with IPv4 host 10.2.3.4 will have its packets converted into IPv6 using the DMR configured on the MAP-T CE as follows:
与IPv4主机10.2.3.4相对应的MAP-T CE（按照前面的示例配置）后面的IPv4主机将使用MAP-T CE上配置的DMR将其数据包转换为IPv6，如下所示：
Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix),
0.0.0.0/0 (Rule IPv4 prefix)}
Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix),
0.0.0.0/0 (Rule IPv4 prefix)}
IPv4 source address: 192.0.2.18 IPv4 destination address: 10.2.3.4 IPv4 source port: 1232 IPv4 destination port: 80 MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034 IPv6 destination address: 2001:db8:ffff:0:000a:0203:0400::
IPv4源地址：192.0.2.18 IPv4目标地址：10.2.3.4 IPv4源端口：1232 IPv4目标端口：80 MAP-T CE IPv6源地址：2001:db8:0012:3400:0000:c000:0212:0034 IPv6目标地址：2001:db8:ffff:0:000a:0203:0400:
Example 4 - Rule with no embedded address bits and no address sharing:
示例4-无嵌入地址位且无地址共享的规则：
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.1/32 (Rule IPv4 prefix),
0 (Rule EA-bit length)}
PSID length: 0 (sharing ratio is 1)
PSID offset: n/a
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.1/32 (Rule IPv4 prefix),
0 (Rule EA-bit length)}
PSID length: 0 (sharing ratio is 1)
PSID offset: n/a
A MAP node can, via the BMR or equivalent FMR, determine the IPv4 address and port set as shown below:
映射节点可以通过BMR或等效FMR确定IPv4地址和端口集，如下所示：
EA bits offset: 0
IPv4 suffix bits (p): Length of IPv4 address -
IPv4 prefix length = 32 - 32 = 0
IPv4 address: 192.0.2.18 (0xc0000212)
PSID start: 0
PSID length: 0
PSID: null
EA bits offset: 0
IPv4 suffix bits (p): Length of IPv4 address -
IPv4 prefix length = 32 - 32 = 0
IPv4 address: 192.0.2.18 (0xc0000212)
PSID start: 0
PSID length: 0
PSID: null
The BMR information allows a MAP CE to also determine (complete) its full IPv6 address by combining the IPv6 prefix with the MAP interface identifier (that embeds the IPv4 address).
BMR信息允许MAP CE通过将IPv6前缀与MAP接口标识符（嵌入IPv4地址）相结合来确定（完成）其完整IPv6地址。
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0201:0000
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0201:0000
Example 5 - Rule with no embedded address bits and address sharing (sharing ratio of 256):
示例5-没有嵌入地址位和地址共享的规则（共享比率为256）：
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.18/32 (Rule IPv4 prefix),
0 (Rule EA-bit length)}
PSID length: (16 - (32 - 24)) = 8 (sharing ratio of 256;
provisioned with DHCPv6)
PSID offset: 6 (default)
PSID: 0x20 (provisioned with DHCPv6)
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.18/32 (Rule IPv4 prefix),
0 (Rule EA-bit length)}
PSID length: (16 - (32 - 24)) = 8 (sharing ratio of 256;
provisioned with DHCPv6)
PSID offset: 6 (default)
PSID: 0x20 (provisioned with DHCPv6)
A MAP node can, via the BMR, determine the IPv4 address and port set as shown below:
映射节点可以通过BMR确定IPv4地址和端口集，如下所示：
EA bits offset: 0
IPv4 suffix bits (p): Length of IPv4 address -
IPv4 prefix length = 32 - 32 = 0
IPv4 address 192.0.2.18 (0xc0000212)
PSID start: 0
PSID length: 8
PSID: 0x34
EA bits offset: 0
IPv4 suffix bits (p): Length of IPv4 address -
IPv4 prefix length = 32 - 32 = 0
IPv4 address 192.0.2.18 (0xc0000212)
PSID start: 0
PSID length: 8
PSID: 0x34
Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723
Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723
The BMR information allows a MAP CE to also determine (complete) its full IPv6 address by combining the IPv6 prefix with the MAP interface identifier (that embeds the IPv4 address and PSID).
BMR信息允许映射CE通过将IPv6前缀与映射接口标识符（嵌入IPv4地址和PSID）相结合来确定（完成）其完整IPv6地址。
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
Note that the IPv4 address and PSID are not derived from the IPv6 prefix assigned to the CE but are provisioned separately, using, for example, MAP options in DHCPv6.
请注意，IPv4地址和PSID不是从分配给CE的IPv6前缀派生的，而是使用DHCPv6中的映射选项等单独设置的。
The driving principles and the mathematical expression of the mapping algorithm used by MAP can be found in Appendix B of [RFC7597].
MAP使用的映射算法的驱动原理和数学表达式见[RFC7597]的附录B。
Acknowledgements
致谢
This document is based on the ideas of many, particularly Remi Despres, who has tirelessly worked on generalized mechanisms for stateless address mapping.
本文档基于许多人的想法，特别是Remi Despres，他不懈地致力于无状态地址映射的通用机制。
The authors would also like to thank Mohamed Boucadair, Guillaume Gottard, Dan Wing, Jan Zorz, Nejc Skoberne, Tina Tsou, Gang Chen, Maoke Chen, Xiaohong Deng, Jouni Korhonen, Tomek Mrugalski, Jacni Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta Maglione, and Hongyu Chen for their review and comments.
作者还要感谢Mohamed Boucadair、Guillaume Gottard、Dan Wing、Jan Zorz、Nejc Skoberne、Tina Tsou、Gang Chen、Maoke Chen、Xiaohong Deng、Jouni Korhonen、Tomek Mrugalski、Jacni Qin、Chunfa Sun、Qiong Sun、Leaf Yeh、Andrew Yourtchenko、Roberta Maglione和Hongyu Chen的评论。
Contributors
贡献者
The following individuals authored major contributions to this document and made the document possible:
以下个人为本文件撰写了重要贡献，并使本文件成为可能：
Chongfeng Xie China Telecom Room 708, No. 118, Xizhimennei Street Beijing 100035 China Phone: +86-10-58552116 Email: xiechf@ctbri.com.cn
中国电信北京西直门内大街118号708室，邮编100035中国电话：+86-10-58552116电子邮件：xiechf@ctbri.com.cn
Qiong Sun China Telecom Room 708, No. 118, Xizhimennei Street Beijing 100035 China Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn
琼孙中国电信北京西直门内大街118号708室100035中国电话：+86-10-58552936电子邮件：sunqiong@ctbri.com.cn
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 United States Email: rajiva@cisco.com
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park，NC 27709美国电子邮件：rajiva@cisco.com
Gang Chen China Mobile 29, Jinrong Avenue Xicheng District, Beijing 100033 China Email: phdgang@gmail.com, chengang@chinamobile.com
陈刚中国移动北京市西城区锦荣大道29号100033中国电子邮件：phdgang@gmail.com, chengang@chinamobile.com
Wentao Shang CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China Email: wentaoshang@gmail.com
尚文涛CERNET中心/清华大学主楼225室北京100084中国电子邮件：wentaoshang@gmail.com
Guoliang Han CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China Email: bupthgl@gmail.com
韩国良CERNET中心/清华大学主楼225室北京100084中国电子邮件：bupthgl@gmail.com
Yu Zhai CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China Email: jacky.zhai@gmail.com
于斋CERNET中心/清华大学主楼225室，北京100084中国电子邮件：jacky。zhai@gmail.com
Authors' Addresses
作者地址
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China
中国北京清华大学兴利赛特中心/清华大学主楼225室，邮编100084
Email: xing@cernet.edu.cn
Email: xing@cernet.edu.cn
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China
中国北京清华大学主楼225室/聪晓宝CERNET中心北京100084
Email: congxiao@cernet.edu.cn
Email: congxiao@cernet.edu.cn
Wojciech Dec (editor) Cisco Systems Haarlerbergpark Haarlerbergweg 13-19 Amsterdam, NOORD-HOLLAND 1101 CH The Netherlands
Wojciech Dec（编辑）Cisco Systems Haarlerbergpark Haarlerbergweg 13-19阿姆斯特丹，荷兰诺德1101 CH
Email: wdec@cisco.com
Email: wdec@cisco.com
Ole Troan Cisco Systems Philip Pedersens vei 1 Lysaker 1366 Norway
Ole Troan Cisco Systems Philip Pedersens vei 1 Lysaker 1366挪威
Email: ot@cisco.com
Email: ot@cisco.com
Satoru Matsushima SoftBank Telecom 1-9-1 Higashi-Shinbashi, Munato-ku Tokyo Japan
松岛佐藤软银电信1-9-1东新桥，日本东京Munato区
Email: satoru.matsushima@g.softbank.co.jp
Email: satoru.matsushima@g.softbank.co.jp
Tetsuya Murakami IP Infusion 1188 East Arques Avenue Sunnyvale, CA 94085 United States
Tetsuya Murakami地址：美国加利福尼亚州森尼维尔市东阿克斯大道1188号，邮编94085
Email: tetsuya@ipinfusion.com
Email: tetsuya@ipinfusion.com