Internet Engineering Task Force (IETF) O. Troan, Ed.
Request for Comments: 7597 W. Dec
Category: Standards Track Cisco Systems
ISSN: 2070-1721 X. Li
C. Bao
Tsinghua University
S. Matsushima
SoftBank Telecom
T. Murakami
IP Infusion
T. Taylor, Ed.
Huawei Technologies
July 2015
Internet Engineering Task Force (IETF) O. Troan, Ed.
Request for Comments: 7597 W. Dec
Category: Standards Track Cisco Systems
ISSN: 2070-1721 X. Li
C. Bao
Tsinghua University
S. Matsushima
SoftBank Telecom
T. Murakami
IP Infusion
T. Taylor, Ed.
Huawei Technologies
July 2015
Mapping of Address and Port with Encapsulation (MAP-E)
地址和端口的封装映射（MAP-E）
Abstract
摘要
This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.
本文档描述了使用IP封装在IPv6网络上传输IPv4数据包的机制。它还描述了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/rfc7597.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7597.
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 .....................................................5
3. Terminology .....................................................5
4. Architecture ....................................................7
5. Mapping Algorithm ...............................................8
5.1. Port-Mapping Algorithm ....................................10
5.2. Basic Mapping Rule (BMR) ..................................11
5.3. Forwarding Mapping Rule (FMR) .............................14
5.4. Destinations outside the MAP Domain .......................14
6. The IPv6 Interface Identifier ..................................15
7. MAP Configuration ..............................................15
7.1. MAP CE ....................................................15
7.2. MAP BR ....................................................16
8. Forwarding Considerations ......................................17
8.1. Receiving Rules ...........................................17
8.2. ICMP ......................................................18
8.3. Fragmentation and Path MTU Discovery ......................18
8.3.1. Fragmentation in the MAP Domain ....................18
8.3.2. Receiving IPv4 Fragments on the MAP Domain
Borders ............................................19
8.3.3. Sending IPv4 Fragments to the Outside ..............19
9. NAT44 Considerations ...........................................19
10. Security Considerations .......................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................21
Appendix A. Examples ..............................................25
Appendix B. A More Detailed Description of the Derivation of the
Port-Mapping Algorithm ................................29
B.1. Bit Representation of the Algorithm ........................31
B.2. GMA Examples ...............................................32
Acknowledgements ..................................................32
Contributors ......................................................33
Authors' Addresses ................................................34
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Terminology .....................................................5
4. Architecture ....................................................7
5. Mapping Algorithm ...............................................8
5.1. Port-Mapping Algorithm ....................................10
5.2. Basic Mapping Rule (BMR) ..................................11
5.3. Forwarding Mapping Rule (FMR) .............................14
5.4. Destinations outside the MAP Domain .......................14
6. The IPv6 Interface Identifier ..................................15
7. MAP Configuration ..............................................15
7.1. MAP CE ....................................................15
7.2. MAP BR ....................................................16
8. Forwarding Considerations ......................................17
8.1. Receiving Rules ...........................................17
8.2. ICMP ......................................................18
8.3. Fragmentation and Path MTU Discovery ......................18
8.3.1. Fragmentation in the MAP Domain ....................18
8.3.2. Receiving IPv4 Fragments on the MAP Domain
Borders ............................................19
8.3.3. Sending IPv4 Fragments to the Outside ..............19
9. NAT44 Considerations ...........................................19
10. Security Considerations .......................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................21
Appendix A. Examples ..............................................25
Appendix B. A More Detailed Description of the Derivation of the
Port-Mapping Algorithm ................................29
B.1. Bit Representation of the Algorithm ........................31
B.2. GMA Examples ...............................................32
Acknowledgements ..................................................32
Contributors ......................................................33
Authors' Addresses ................................................34
Mapping of IPv4 addresses in IPv6 addresses has been described in numerous mechanisms dating back to the mid-1990s [RFC1933] [RFC4213]. The "automatic tunneling" mechanism as first described in [RFC1933] assigned a globally unique IPv6 address to a host by combining the host's IPv4 address with a well-known IPv6 prefix. Given an IPv6 packet with a destination address with an embedded IPv4 address, a node could automatically tunnel this packet by extracting the IPv4 tunnel endpoint address from the IPv6 destination address.
IPv6地址中IPv4地址的映射可以追溯到20世纪90年代中期的许多机制[RFC1933][RFC4213]。[RFC1933]中首次描述的“自动隧道”机制通过将主机的IPv4地址与众所周知的IPv6前缀相结合，为主机分配了一个全局唯一的IPv6地址。给定目标地址为嵌入IPv4地址的IPv6数据包，节点可以通过从IPv6目标地址提取IPv4隧道端点地址来自动隧道此数据包。
There are numerous variations of this idea, as described in 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969].
这一想法有许多变体，如6over4[RFC2529]、6to4[RFC3056]、站点内自动隧道寻址协议（ISATAP）[RFC5214]和IPv4基础设施上的IPv6快速部署（6rd）[RFC5969]所述。
The commonalities of all of these IPv6-over-IPv4 mechanisms are as follows:
所有这些IPv6-over-IPv4机制的共同点如下：
o Automatic provisioning of an IPv6 address for a host or an IPv6 prefix for a site.
o 自动设置主机的IPv6地址或站点的IPv6前缀。
o Algorithmic or implicit address resolution of tunnel endpoint addresses. Given an IPv6 destination address, an IPv4 tunnel endpoint address can be calculated.
o 隧道端点地址的算法或隐式地址解析。给定IPv6目标地址，可以计算IPv4隧道端点地址。
o Embedding of an IPv4 address or part thereof into an IPv6 address.
o 将IPv4地址或其一部分嵌入IPv6地址。
In later phases of IPv4-to-IPv6 migration, it is expected that IPv6-only networks will be common, while there will still be a need for residual IPv4 deployment. This document describes a generic mapping of IPv4 to IPv6 and a mechanism for encapsulating IPv4 over IPv6.
在IPv4到IPv6迁移的后期阶段，预计只使用IPv6的网络将很常见，但仍需要剩余的IPv4部署。本文档描述了IPv4到IPv6的通用映射以及通过IPv6封装IPv4的机制。
Just as for the IPv6-over-IPv4 mechanisms referred to above, the residual IPv4-over-IPv6 mechanism must be capable of:
正如上面提到的IPv6-over-IPv4机制一样，剩余的IPv4-over-IPv6机制必须能够：
o Provisioning an IPv4 prefix, an IPv4 address, or a shared IPv4 address.
o 设置IPv4前缀、IPv4地址或共享IPv4地址。
o Algorithmically mapping between an IPv4 prefix, an IPv4 address, or a shared IPv4 address and an IPv6 address.
o IPv4前缀、IPv4地址或共享IPv4地址与IPv6地址之间的算法映射。
The mapping scheme described here supports encapsulation of IPv4 packets in IPv6 in both mesh and hub-and-spoke topologies, including address mappings with full independence between IPv6 and IPv4 addresses.
这里描述的映射方案支持在网状拓扑和集线器辐射拓扑中封装IPv6中的IPv4数据包，包括IPv6和IPv4地址之间完全独立的地址映射。
This document describes the delivery of IPv4 unicast service across an IPv6 infrastructure. IPv4 multicast is not considered in this document.
本文档描述了跨IPv6基础结构的IPv4单播服务的交付。本文档不考虑IPv4多播。
The Address plus Port (A+P) architecture of sharing an IPv4 address by distributing the port space is described in [RFC6346]. Specifically, Section 4 of [RFC6346] covers stateless mapping. The corresponding stateful solution, Dual-Stack Lite (DS-Lite), is described in [RFC6333]. The motivations for this work are described in [Solutions-4v6].
[RFC6346]中描述了通过分配端口空间来共享IPv4地址的地址加端口（A+P）体系结构。具体而言，[RFC6346]第4节介绍了无状态映射。[RFC6333]中描述了相应的有状态解决方案，即双栈Lite（DS Lite）。[Solutions-4v6]中描述了这项工作的动机。
[RFC7598] defines DHCPv6 options for the provisioning of MAP. Other means of provisioning are possible. Deployment considerations are described in [MAP-Deploy].
[RFC7598]定义了用于提供MAP的DHCPv6选项。其他供应方式也是可能的。[MAP Deploy]中介绍了部署注意事项。
MAP relies on IPv6 and is designed to deliver dual-stack service while allowing IPv4 to be phased out within the service provider's (SP's) network. The phasing out of IPv4 within the SP network is independent of whether the end user disables IPv4 service or not. Further, "greenfield" IPv6-only networks may use MAP in order to deliver IPv4 to sites via the IPv6 network.
MAP依赖于IPv6，旨在提供双栈服务，同时允许在服务提供商（SP）的网络中逐步淘汰IPv4。SP网络中IPv4的逐步淘汰与最终用户是否禁用IPv4服务无关。此外，“绿地”纯IPv6网络可以使用MAP，以便通过IPv6网络将IPv4传送到站点。
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 domain: One or more MAP Customer Edge (CE) devices and Border Relays (BRs) connected to the same virtual link. A service provider may deploy a single MAP domain or may utilize multiple MAP domains.
映射域：连接到同一虚拟链路的一个或多个映射客户边缘（CE）设备和边界中继（BR）。服务提供商可以部署单个映射域，也可以使用多个映射域。
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 domain uses a different mapping rule set.
映射规则：描述IPv4前缀、IPv4地址或共享IPv4地址与IPv6前缀或地址之间映射的一组参数。每个域使用不同的映射规则集。
MAP node: A device that implements MAP.
映射节点：实现映射的设备。
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 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 interface and one or more LAN-side interfaces. A MAP CE may also be referred to as simply a "CE" within the context of MAP.
地图客户边缘（CE）：在地图部署中充当客户边缘路由器的设备。采用MAP规则的典型MAP CE将服务于具有一个WAN端接口和一个或多个LAN端接口的住宅站点。在MAP的上下文中，MAP-CE也可以简单地称为“CE”。
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 mapping rule.
规则IPv6前缀：服务提供商为映射规则分配的IPv6前缀。
Rule IPv4 prefix: An IPv4 prefix assigned by a service provider for a mapping 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地址（或其部分）和端口集标识符。
In accordance with the requirements stated above, the MAP mechanism can operate with shared IPv4 addresses, full IPv4 addresses, or IPv4 prefixes. Operation with shared IPv4 addresses is described here, and the differences for full IPv4 addresses and prefixes are described below.
根据上述要求，映射机制可以使用共享IPv4地址、完整IPv4地址或IPv4前缀进行操作。这里描述了使用共享IPv4地址的操作，下面描述了完整IPv4地址和前缀的区别。
The MAP mechanism uses existing standard building blocks. The existing Network Address and Port Translator (NAPT) [RFC2663] on the CE is used with additional support for restricting transport-protocol ports, ICMP identifiers, and fragment identifiers to the configured port set. For packets outbound from the private IPv4 network, the CE NAPT MUST translate transport identifiers (e.g., TCP and UDP port numbers) so that they fall within the CE's assigned port range.
映射机制使用现有的标准构建块。CE上现有的网络地址和端口转换器（NAPT）[RFC2663]与其他支持一起使用，用于将传输协议端口、ICMP标识符和片段标识符限制到配置的端口集。对于从专用IPv4网络出站的数据包，CE NAPT必须转换传输标识符（例如TCP和UDP端口号），以便它们位于CE分配的端口范围内。
The NAPT MUST in turn be connected to a MAP-aware forwarding function that does encapsulation/decapsulation of IPv4 packets in IPv6. MAP supports the encapsulation mode specified in [RFC2473]. In addition, MAP specifies an algorithm to do "address resolution" from an IPv4 address and port to an IPv6 address. This algorithmic mapping is specified in Section 5.
NAPT必须依次连接到地图感知转发功能，该功能在IPv6中对IPv4数据包进行封装/反封装。MAP支持[RFC2473]中指定的封装模式。此外，MAP还指定了一种算法，用于从IPv4地址和端口到IPv6地址进行“地址解析”。第5节规定了该算法映射。
The MAP architecture described here restricts the use of the shared IPv4 address to only be used as the global address (outside) of the NAPT running on the CE. A shared IPv4 address MUST NOT be used to identify an interface. While it is theoretically possible to make host stacks and applications port-aware, it would be a drastic change to the IP model [RFC6250].
此处描述的映射体系结构将共享IPv4地址的使用限制为仅用作CE上运行的NAPT的全局地址（外部）。共享IPv4地址不得用于标识接口。虽然从理论上讲，使主机堆栈和应用程序具有端口感知能力是可能的，但这将是对IP模型的重大改变[RFC6250]。
For full IPv4 addresses and IPv4 prefixes, the architecture just described applies, with two differences: first, a full IPv4 address or IPv4 prefix can be used as it is today, e.g., for identifying an interface or as a DHCP pool, respectively. Second, the NAPT is not required to restrict the ports used on outgoing packets.
对于完整的IPv4地址和IPv4前缀，刚才描述的体系结构适用，但有两个区别：第一，完整的IPv4地址或IPv4前缀可以像现在一样使用，例如，分别用于标识接口或DHCP池。其次，NAPT不需要限制传出数据包上使用的端口。
This architecture is illustrated in Figure 1.
该体系结构如图1所示。
User N
Private IPv4
| Network
|
O--+---------------O
| | MAP CE |
| +-----+--------+ |
| NAPT44| MAP | |
| +-----+ | |\ ,-------. .------.
| +--------+ | \ ,-' `-. ,-' `-.
O------------------O / \ O---------O / Public \
/ IPv6-only \ | MAP | / IPv4 \
( Network --+ Border +- Network )
\ (MAP Domain) / | Relay | \ /
O------------------O \ / O---------O \ /
| MAP CE | /". ,-' `-. ,-'
| +-----+--------+ | / `----+--' ------'
| NAPT44| MAP | |/
| +-----+ | |
| | +--------+ |
O---+--------------O
|
User M
Private IPv4
Network
User N
Private IPv4
| Network
|
O--+---------------O
| | MAP CE |
| +-----+--------+ |
| NAPT44| MAP | |
| +-----+ | |\ ,-------. .------.
| +--------+ | \ ,-' `-. ,-' `-.
O------------------O / \ O---------O / Public \
/ IPv6-only \ | MAP | / IPv4 \
( Network --+ Border +- Network )
\ (MAP Domain) / | Relay | \ /
O------------------O \ / O---------O \ /
| MAP CE | /". ,-' `-. ,-'
| +-----+--------+ | / `----+--' ------'
| NAPT44| MAP | |/
| +-----+ | |
| | +--------+ |
O---+--------------O
|
User M
Private IPv4
Network
Figure 1: Network Topology
图1：网络拓扑
The MAP BR connects one or more MAP domains to external IPv4 networks.
MAP BR将一个或多个MAP域连接到外部IPv4网络。
A MAP node is provisioned with one or more mapping rules.
映射节点配置了一个或多个映射规则。
Mapping rules are used differently, depending on their function. Every MAP node must be provisioned with a Basic Mapping Rule. This is used by the node to configure its IPv4 address, IPv4 prefix, or shared IPv4 address. This same basic rule can also be used for forwarding, where an IPv4 destination address and, optionally, a destination port are mapped into an IPv6 address. Additional mapping rules are specified to allow for multiple different IPv4 subnets to exist within the domain and optimize forwarding between them.
映射规则的使用方式不同，具体取决于它们的功能。必须为每个映射节点提供基本映射规则。节点使用此选项配置其IPv4地址、IPv4前缀或共享IPv4地址。同样的基本规则也可用于转发，其中IPv4目标地址和（可选）目标端口映射到IPv6地址。指定了其他映射规则，以允许域中存在多个不同的IPv4子网，并优化它们之间的转发。
Traffic outside of the domain (i.e., when the destination IPv4 address does not match (using longest matching prefix) any Rule IPv4 prefix in the Rules database) is forwarded to the BR.
域外的流量（即，当目标IPv4地址与规则数据库中的任何规则IPv4前缀不匹配（使用最长匹配前缀）时）被转发到BR。
There are two types of mapping rules:
有两种类型的映射规则：
1. Basic Mapping Rule (BMR) - mandatory. A CE can be provisioned with multiple End-user IPv6 prefixes. There can only be one Basic Mapping Rule per End-user IPv6 prefix. However, all CEs having End-user IPv6 prefixes within (aggregated by) the same Rule IPv6 prefix may share the same Basic Mapping Rule. In combination with the End-user IPv6 prefix, the Basic Mapping Rule is used to derive the IPv4 prefix, address, or shared address and the PSID assigned to the CE.
1. 基本映射规则（BMR）-必需。CE可以配置多个最终用户IPv6前缀。每个最终用户IPv6前缀只能有一个基本映射规则。但是，在相同规则IPv6前缀内（通过聚合）具有最终用户IPv6前缀的所有CE可能共享相同的基本映射规则。结合最终用户IPv6前缀，基本映射规则用于派生IPv4前缀、地址或共享地址以及分配给CE的PSID。
2. Forwarding Mapping Rule (FMR) - optional; used for forwarding. The Basic Mapping Rule may also be a Forwarding Mapping Rule. Each Forwarding Mapping Rule will result in an entry in the rule table for the Rule IPv4 prefix. Given a destination IPv4 address and port within the MAP domain, a MAP node can use the matching FMR to derive the End-user IPv6 address of the interface through which that IPv4 destination address and port combination can be reached. In hub-and-spoke mode, there are no FMRs.
2. 转发映射规则（FMR）-可选；用于转发。基本映射规则也可以是转发映射规则。每个转发映射规则将在规则表中为规则IPv4前缀生成一个条目。给定MAP域中的目标IPv4地址和端口，MAP节点可以使用匹配的FMR派生接口的最终用户IPv6地址，通过该接口可以达到IPv4目标地址和端口组合。在中心辐射模式下，没有FMR。
Both mapping rules share the same parameters:
两个映射规则共享相同的参数：
o Rule IPv6 prefix (including prefix length)
o 规则IPv6前缀（包括前缀长度）
o Rule IPv4 prefix (including prefix length)
o 规则IPv4前缀（包括前缀长度）
o Rule EA-bit length (in bits)
o 规则EA位长度（以位为单位）
A MAP node finds its BMR by doing a longest match between the End-user IPv6 prefix and the Rule IPv6 prefix in the Mapping Rules table. The rule is then used for IPv4 prefix, address, or shared address assignment.
映射节点通过在映射规则表中的最终用户IPv6前缀和规则IPv6前缀之间进行最长匹配来查找其BMR。然后，该规则用于IPv4前缀、地址或共享地址分配。
A MAP IPv6 address is formed from the BMR Rule IPv6 prefix. This address MUST be assigned to an interface of the MAP node and is used to terminate all MAP traffic being sent or received to the node.
映射IPv6地址由BMR规则IPv6前缀形成。此地址必须分配给MAP节点的接口，并用于终止发送或接收到该节点的所有MAP通信。
Port-restricted IPv4 routes are installed in the rule table for all the Forwarding Mapping Rules, and a default route is installed to the MAP BR (see Section 5.4).
端口受限IPv4路由安装在所有转发映射规则的规则表中，默认路由安装到映射BR（请参阅第5.4节）。
Forwarding Mapping Rules are used to allow direct communication between MAP CEs; this is known as "Mesh mode". In hub-and-spoke mode, there are no Forwarding Mapping Rules; all traffic MUST be forwarded directly to the BR.
转发映射规则用于允许MAP CE之间的直接通信；这称为“网格模式”。在中心辐射模式下，没有转发映射规则；所有流量必须直接转发到BR。
While an FMR is optional in the sense that a MAP CE MAY be configured with zero or more FMRs -- depending on the deployment -- all MAP CEs MUST implement support for both rule types.
虽然FMR是可选的，因为MAP CE可能配置有零个或多个FMR（取决于部署），但所有MAP CE必须实现对这两种规则类型的支持。
The port-mapping algorithm is used in domains whose rules allow IPv4 address sharing.
端口映射算法用于规则允许IPv4地址共享的域。
The simplest way to represent a port range is using a notation similar to Classless Inter-Domain Routing (CIDR) [RFC4632]. For example, the first 256 ports are represented as port prefix 0.0/8 and the last 256 ports as 255.0/8. In hexadecimal, these would be 0x0000/8 (PSID = 0) and 0xFF00/8 (PSID = 0xFF), respectively. Using this technique but wishing to avoid allocating the system ports [RFC6335] to the user, one would have to exclude the use of one or more PSIDs (e.g., PSIDs 0 to 3 in the example just given).
表示端口范围的最简单方法是使用类似于无类域间路由（CIDR）[RFC4632]的表示法。例如，前256个端口表示为端口前缀0.0/8，最后256个端口表示为255.0/8。在十六进制中，它们分别是0x0000/8（PSID=0）和0xFF00/8（PSID=0xFF）。使用此技术，但为了避免将系统端口[RFC6335]分配给用户，必须排除使用一个或多个PSID（例如，刚才给出的示例中的PSID 0到3）。
When the PSID is embedded in the End-user IPv6 prefix, it is desirable to minimize the restrictions of possible PSID values in order to minimize dependencies between the End-user IPv6 prefix and the assigned port set. This is achieved by using an infix representation of the port value. Using such a representation, the well-known ports are excluded by restrictions on the value of the high-order bit field (A) rather than the PSID.
当PSID嵌入最终用户IPv6前缀中时，希望最小化可能PSID值的限制，以最小化最终用户IPv6前缀和分配的端口集之间的依赖关系。这是通过使用端口值的中缀表示来实现的。使用这种表示法，通过对高阶位字段（a）而不是PSID的值的限制排除已知端口。
The infix algorithm allocates ports to a given CE as a series of contiguous ranges spaced at regular intervals throughout the complete range of possible port-set values.
中缀算法将端口作为一系列连续范围分配给给定的CE，这些连续范围在整个可能的端口集值范围内以固定间隔隔开。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-----------+-----------+-------+
Ports in | A | PSID | j |
the CE port set | > 0 | | |
+-----------+-----------+-------+
| a bits | k bits |m bits |
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-----------+-----------+-------+
Ports in | A | PSID | j |
the CE port set | > 0 | | |
+-----------+-----------+-------+
| a bits | k bits |m bits |
Figure 2: Structure of a Port-Restricted Port Field
图2：端口受限端口字段的结构
a bits: The number of offset bits -- 6 by default, as this excludes the system ports (0-1023). To guarantee non-overlapping port sets, the offset 'a' MUST be the same for every MAP CE sharing the same address.
a位：偏移位的数量——默认为6，因为这不包括系统端口（0-1023）。为保证端口集不重叠，共享同一地址的每个映射CE的偏移量“a”必须相同。
A: Selects the range of the port number. For 'a' > 0, A MUST be larger than 0. This ensures that the algorithm excludes the system ports. For the default value of 'a' (6), the system ports are excluded by requiring that A be greater than 0. Smaller values of 'a' exclude a larger initial range, e.g., 'a' = 4 will exclude ports 0-4095. The interval between initial port numbers of successive contiguous ranges assigned to the same user is 2^(16 - a).
A：选择端口号的范围。对于'a'>0，a必须大于0。这可确保算法排除系统端口。对于默认值“a”（6），系统端口被排除在外，要求a大于0。较小的“a”值排除较大的初始范围，例如，“a”=4将排除端口0-4095。分配给同一用户的连续范围的初始端口号之间的间隔为2^（16-a）。
k bits: The length in bits of the PSID field. To guarantee non-overlapping port sets, the length 'k' MUST be the same for every MAP CE sharing the same address. The sharing ratio is 2^k. The number of ports assigned to the user is 2^(16 - k) - 2^m (excluded ports).
k位：PSID字段的长度（以位为单位）。为保证端口集不重叠，共享相同地址的每个映射CE的长度“k”必须相同。共享比率为2^k。分配给用户的端口数为2^（16-k）-2^ m（排除的端口）。
PSID: The Port Set Identifier (PSID). Different PSID values guarantee non-overlapping port sets, thanks to the restrictions on 'a' and 'k' stated above, because the PSID always occupies the same bit positions in the port number.
PSID：端口集标识符（PSID）。由于上述对“a”和“k”的限制，不同的PSID值保证了不重叠的端口集，因为PSID在端口号中始终占据相同的位位置。
m bits: The number of contiguous ports is given by 2^m.
m位：连续端口的数量由2^m表示。
j: Selects the specific port within a particular range specified by the concatenation of A and the PSID.
j：在由a和PSID连接指定的特定范围内选择特定端口。
The Basic Mapping Rule is mandatory and is used by the CE to provision itself with an IPv4 prefix, IPv4 address, or shared IPv4 address. Recall from Section 5 that the BMR consists of the following parameters:
基本映射规则是必需的，CE使用该规则为自己配置IPv4前缀、IPv4地址或共享IPv4地址。回想第5节，BMR由以下参数组成：
o Rule IPv6 prefix (including prefix length)
o 规则IPv6前缀（包括前缀长度）
o Rule IPv4 prefix (including prefix length)
o 规则IPv4前缀（包括前缀长度）
o Rule EA-bit length (in bits)
o 规则EA位长度（以位为单位）
Figure 3 shows the structure of the complete MAP IPv6 address as specified in this document.
图3显示了本文档中指定的完整映射IPv6地址的结构。
| n bits | o bits | s bits | 128-n-o-s bits |
+--------------------+-----------+---------+-----------------------+
| Rule IPv6 prefix | EA bits |subnet ID| interface ID |
+--------------------+-----------+---------+-----------------------+
|<--- End-user IPv6 prefix --->|
| n bits | o bits | s bits | 128-n-o-s bits |
+--------------------+-----------+---------+-----------------------+
| Rule IPv6 prefix | EA bits |subnet ID| interface ID |
+--------------------+-----------+---------+-----------------------+
|<--- End-user IPv6 prefix --->|
Figure 3: MAP IPv6 Address Format
图3：映射IPv6地址格式
The Rule IPv6 prefix is common among all CEs using the same Basic Mapping Rule within the MAP domain. The EA bit field encodes the CE-specific IPv4 address and port information. The EA bit field, which is unique for a given Rule IPv6 prefix, can contain a full or partial IPv4 address and, in the shared IPv4 address case, a PSID. An EA bit field length of 0 signifies that all relevant MAP IPv4 addressing information is passed directly in the BMR and is not derived from the EA bit field in the End-user IPv6 prefix.
规则IPv6前缀在映射域内使用相同基本映射规则的所有CE中通用。EA位字段编码特定于CE的IPv4地址和端口信息。EA位字段对于给定的规则IPv6前缀是唯一的，可以包含完整或部分IPv4地址，在共享IPv4地址的情况下，还可以包含PSID。EA位字段长度为0表示所有相关的映射IPv4寻址信息直接在BMR中传递，而不是从最终用户IPv6前缀中的EA位字段派生。
The MAP IPv6 address is created by concatenating the End-user IPv6 prefix with the MAP subnet identifier (if the End-user IPv6 prefix is shorter than 64 bits) and the interface identifier as specified in Section 6.
MAP IPv6地址是通过将最终用户IPv6前缀与MAP子网标识符（如果最终用户IPv6前缀短于64位）和第6节中指定的接口标识符连接而创建的。
The MAP subnet identifier is defined to be the first subnet (s bits set to zero).
映射子网标识符定义为第一个子网（s位设置为零）。
Define:
定义：
r = length of the IPv4 prefix given by the BMR;
r=BMR给出的IPv4前缀的长度；
o = length of the EA bit field as given by the BMR;
o =BMR给出的EA位字段的长度；
p = length of the IPv4 suffix contained in the EA bit field.
p=EA位字段中包含的IPv4后缀的长度。
The length r MAY be zero, in which case the complete IPv4 address or prefix is encoded in the EA bits. If only a part of the IPv4 address / prefix is encoded in the EA bits, the Rule IPv4 prefix is provisioned to the CE by other means (e.g., a DHCPv6 option). To create a complete IPv4 address (or prefix), the IPv4 address suffix (p) from the EA bits is concatenated with the Rule IPv4 prefix (r bits).
长度r可以为零，在这种情况下，完整的IPv4地址或前缀编码在EA位中。如果仅IPv4地址/前缀的一部分编码在EA位中，则通过其他方式（例如，DHCPv6选项）将规则IPv4前缀提供给CE。要创建完整的IPv4地址（或前缀），将EA位中的IPv4地址后缀（p）与规则IPv4前缀（r位）连接起来。
The offset of the EA bit field in the IPv6 address is equal to the BMR Rule IPv6 prefix length. The length of the EA bit field (o) is given by the BMR Rule EA-bit length and can be between 0 and 48. A length of 48 means that the complete IPv4 address and port are
IPv6地址中EA位字段的偏移量等于BMR规则IPv6前缀长度。EA位字段（o）的长度由BMR规则EA位长度给出，可以在0到48之间。长度为48表示完整的IPv4地址和端口为
embedded in the End-user IPv6 prefix (a single port is assigned). A length of 0 means that no part of the IPv4 address or port is embedded in the address. The sum of the Rule IPv6 Prefix length and the Rule EA-bit length MUST be less than or equal to the End-user IPv6 prefix length.
嵌入最终用户IPv6前缀中（分配一个端口）。长度为0表示地址中未嵌入IPv4地址或端口的任何部分。规则IPv6前缀长度和规则EA位长度之和必须小于或等于最终用户IPv6前缀长度。
If o + r < 32 (length of the IPv4 address in bits), then an IPv4 prefix is assigned. This case is shown in Figure 4.
若o+r<32（IPv4地址的长度，以位为单位），则分配IPv4前缀。这个案例如图4所示。
| r bits | o bits = p bits |
+-------------+---------------------+
| Rule IPv4 | IPv4 address suffix |
+-------------+---------------------+
| < 32 bits |
| r bits | o bits = p bits |
+-------------+---------------------+
| Rule IPv4 | IPv4 address suffix |
+-------------+---------------------+
| < 32 bits |
Figure 4: IPv4 Prefix
图4:IPv4前缀
If o + r is equal to 32, then a full IPv4 address is to be assigned. The address is created by concatenating the Rule IPv4 prefix and the EA-bits. This case is shown in Figure 5.
如果o+r等于32，则将分配完整的IPv4地址。地址是通过连接规则IPv4前缀和EA位创建的。这个案例如图5所示。
| r bits | o bits = p bits |
+-------------+---------------------+
| Rule IPv4 | IPv4 address suffix |
+-------------+---------------------+
| 32 bits |
| r bits | o bits = p bits |
+-------------+---------------------+
| Rule IPv4 | IPv4 address suffix |
+-------------+---------------------+
| 32 bits |
Figure 5: Complete IPv4 Address
图5：完整的IPv4地址
If o + r is > 32, then a shared IPv4 address is to be assigned. The number of IPv4 address suffix bits (p) in the EA bits is given by 32 - r bits. The PSID bits are used to create a port set. The length of the PSID bit field within the EA bits is q = o - p.
如果o+r大于32，则将分配共享IPv4地址。EA位中IPv4地址后缀位（p）的数量由32-r位给出。PSID位用于创建端口集。EA位中PSID位字段的长度为q=o-p。
| r bits | p bits | | q bits |
+-------------+---------------------+ +------------+
| Rule IPv4 | IPv4 address suffix | |Port Set ID |
+-------------+---------------------+ +------------+
| 32 bits |
| r bits | p bits | | q bits |
+-------------+---------------------+ +------------+
| Rule IPv4 | IPv4 address suffix | |Port Set ID |
+-------------+---------------------+ +------------+
| 32 bits |
Figure 6: Shared IPv4 Address
图6：共享IPv4地址
The length of r MAY be 32, with no part of the IPv4 address embedded in the EA bits. This results in a mapping with no dependence between the IPv4 address and the IPv6 address. In addition, the length of o MAY be zero (no EA bits embedded in the End-user IPv6 prefix), meaning that the PSID is also provisioned using, for example, DHCP.
r的长度可以是32，在EA位中没有嵌入IPv4地址的任何部分。这导致IPv4地址和IPv6地址之间的映射不存在依赖性。此外，o的长度可以为零（最终用户IPv6前缀中没有嵌入EA位），这意味着还使用例如DHCP来供应PSID。
See Appendix A for an example of the Basic Mapping Rule.
有关基本映射规则的示例，请参见附录A。
The Forwarding Mapping Rule is optional and is used in Mesh mode to enable direct CE-to-CE connectivity.
转发映射规则是可选的，在网状模式下用于启用CE到CE的直接连接。
On adding an FMR rule, an IPv4 route is installed in the rule table for the Rule IPv4 prefix (Figures 4, 5, and 6).
在添加FMR规则时，IPv4路由将安装在规则IPv4前缀的规则表中（图4、图5和图6）。
| 32 bits | | 16 bits |
+--------------------------+ +-------------------+
| IPv4 destination address | | IPv4 dest port |
+--------------------------+ +-------------------+
: : ___/ :
| p bits | / q bits :
+-----------+ +------------+
|IPv4 suffix| |Port Set ID |
+-----------+ +------------+
\ / ____/ ________/
\ : __/ _____/
\ : / /
| n bits | o bits | s bits | 128-n-o-s bits |
+--------------------+-----------+---------+------------+----------+
| Rule IPv6 prefix | EA bits |subnet ID| interface ID |
+--------------------+-----------+---------+-----------------------+
|<--- End-user IPv6 prefix --->|
| 32 bits | | 16 bits |
+--------------------------+ +-------------------+
| IPv4 destination address | | IPv4 dest port |
+--------------------------+ +-------------------+
: : ___/ :
| p bits | / q bits :
+-----------+ +------------+
|IPv4 suffix| |Port Set ID |
+-----------+ +------------+
\ / ____/ ________/
\ : __/ _____/
\ : / /
| n bits | o bits | s bits | 128-n-o-s bits |
+--------------------+-----------+---------+------------+----------+
| Rule IPv6 prefix | EA bits |subnet ID| interface ID |
+--------------------+-----------+---------+-----------------------+
|<--- End-user IPv6 prefix --->|
Figure 7: Derivation of MAP IPv6 Address
图7：映射IPv6地址的推导
See Appendix A for an example of the Forwarding Mapping Rule.
有关转发映射规则的示例，请参见附录A。
IPv4 traffic between MAP nodes that are all within one MAP domain is encapsulated in IPv6, with the sender's MAP IPv6 address as the IPv6 source address and the receiving MAP node's MAP IPv6 address as the IPv6 destination address. To reach IPv4 destinations outside of the MAP domain, traffic is also encapsulated in IPv6, but the destination IPv6 address is set to the configured IPv6 address of the MAP BR.
所有位于一个映射域内的映射节点之间的IPv4通信被封装在IPv6中，发送方的映射IPv6地址作为IPv6源地址，接收映射节点的映射IPv6地址作为IPv6目标地址。要到达映射域之外的IPv4目标，流量也封装在IPv6中，但目标IPv6地址设置为映射的配置IPv6地址BR。
On the CE, the path to the BR can be represented as a point-to-point IPv4-over-IPv6 tunnel [RFC2473] with the source address of the tunnel being the CE's MAP IPv6 address and the BR IPv6 address as the remote tunnel address. When MAP is enabled, a typical CE router will install a default IPv4 route to the BR.
在CE上，BR的路径可以表示为点对点IPv4-over-IPv6隧道[RFC2473]，隧道的源地址为CE的映射IPv6地址，BR IPv6地址为远程隧道地址。启用MAP后，典型的CE路由器将安装到BR的默认IPv4路由。
The BR forwards traffic received from the outside to CEs using the normal MAP forwarding rules.
BR使用普通映射转发规则将从外部接收的流量转发到CEs。
The interface identifier format of a MAP node is described below.
映射节点的接口标识符格式如下所述。
| 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 8: IPv6 Interface Identifier
图8:IPv6接口标识符
In the case of an IPv4 prefix, the IPv4 address field is right-padded with zeros up to 32 bits. The PSID field 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 elements. The configured values for these elements are identical for all CEs and BRs within a given MAP domain.
对于给定的映射域，BR和CE必须配置以下映射元素。对于给定映射域内的所有CE和BR，这些元素的配置值是相同的。
o The Basic Mapping Rule and, optionally, the Forwarding Mapping Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and Length of EA bits.
o 基本映射规则和转发映射规则（可选），包括规则IPv6前缀、规则IPv4前缀和EA位长度。
o Hub-and-spoke mode or Mesh mode (if all traffic should be sent to the BR, or if direct CE-to-CE traffic should be supported).
o 中心辐射模式或网状模式（如果所有流量都应发送到BR，或者如果应支持直接CE到CE流量）。
In addition, the MAP CE MUST be configured with the IPv6 address(es) of the MAP BR (Section 5.4).
此外，MAP CE必须配置MAP BR的IPv6地址（第5.4节）。
The MAP elements are set to values that are the same across all CEs within a MAP domain. The values may be configured in a variety of ways, including provisioning methods such as the Broadband Forum's "TR-69" Residential Gateway management interface [TR069], an XML-based object retrieved after IPv6 connectivity is established, or manual configuration by an administrator. IPv6 DHCP options for MAP
地图元素设置为地图域内所有CE中相同的值。这些值可以多种方式配置，包括宽带论坛的“TR-69”住宅网关管理接口[TR069]等配置方法、建立IPv6连接后检索的基于XML的对象，或管理员手动配置。映射的IPv6 DHCP选项
configuration are defined in [RFC7598]. Other configuration and management methods may use the formats described by these options for consistency and convenience of implementation on CEs that support multiple configuration methods.
配置在[RFC7598]中定义。其他配置和管理方法可以使用这些选项描述的格式，以确保在支持多种配置方法的CEs上实现的一致性和便利性。
The only remaining provisioning information the CE requires in order to calculate the MAP IPv4 address and enable IPv4 connectivity is the IPv6 prefix for the CE. The End-user IPv6 prefix is configured as part of obtaining IPv6 Internet access.
CE计算映射IPv4地址和启用IPv4连接所需的唯一剩余配置信息是CE的IPv6前缀。最终用户IPv6前缀配置为获取IPv6 Internet访问的一部分。
The MAP provisioning parameters, and hence the IPv4 service itself, are tied to the associated End-user IPv6 prefix lifetime; 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 DHCP. Each domain within which a given CE operates 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.
一个MAP CE可以连接到多个MAP域，就像任何路由器都可以具有多个支持IPv4的面向服务提供商的接口和多组由DHCP分配的关联地址一样。给定CE运行的每个域都需要自己的映射配置元素集，并生成自己的IPv4地址。每个映射域都需要不同的最终用户IPv6前缀。
MAP DHCP options are specified in [RFC7598].
[RFC7598]中指定了映射DHCP选项。
The MAP BR MUST be configured with corresponding mapping rules for each MAP domain for which it is acting as a BR.
映射BR必须为其作为BR的每个映射域配置相应的映射规则。
For increased reliability and load balancing, the BR IPv6 address MAY be an anycast address shared across a given MAP domain. As MAP is stateless, any BR may be used at any time. If the BR IPv6 address is anycast, the relay MUST use this anycast IPv6 address as the source address in packets relayed to CEs.
为了提高可靠性和负载平衡，BR IPv6地址可以是跨给定映射域共享的选播地址。由于MAP是无状态的，所以可以随时使用任何BR。如果BR IPv6地址是选播，则中继必须使用此选播IPv6地址作为中继到CEs的数据包中的源地址。
Since MAP uses provider address space, no specific routes need to be advertised externally for MAP to operate in IPv6 or IPv4 BGP. However, if anycast is used for the MAP IPv6 relays, the anycast addresses must be advertised in the service provider's IGP.
由于MAP使用提供商地址空间，所以无需在外部公布特定路由，MAP即可在IPv6或IPv4 BGP中运行。但是，如果选播用于MAP IPv6中继，则必须在服务提供商的IGP中公布选播地址。
Figure 1 depicts the overall MAP architecture with IPv4 users connected to a routed IPv6 network.
图1描述了IPv4用户连接到路由IPv6网络的总体MAP体系结构。
MAP uses encapsulation mode as specified in [RFC2473].
MAP使用[RFC2473]中指定的封装模式。
For a shared IPv4 address, a MAP CE forwarding IPv4 packets from the LAN performs NAT44 functions first and creates appropriate NAT44 bindings. The resulting IPv4 packets MUST contain the source IPv4 address and source transport identifiers specified by the MAP provisioning parameters. The IPv4 packet is forwarded using the CE's MAP forwarding function. The IPv6 source and destination addresses MUST then be derived as per Section 5 of this document.
对于共享IPv4地址，从LAN转发IPv4数据包的映射CE首先执行NAT44功能并创建适当的NAT44绑定。生成的IPv4数据包必须包含由映射设置参数指定的源IPv4地址和源传输标识符。IPv4数据包使用CE的映射转发功能进行转发。然后，必须按照本文档第5节的要求导出IPv6源地址和目标地址。
A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this packet to the CE's MAP function, where it is decapsulated. The resulting IPv4 packet is then forwarded to the CE's NAT44 function, where it is handled according to the NAT's translation table.
接收到IPv6数据包到其MAP IPv6地址的MAP CE将该数据包发送到CE的MAP功能，在该功能中，该数据包被解除封装。然后，生成的IPv4数据包被转发到CE的NAT44函数，在那里根据NAT的转换表进行处理。
A MAP BR receiving IPv6 packets selects a best matching MAP domain rule (Rule IPv6 prefix) based on a longest address match of the packet's IPv6 source address, as well as a match of the packet destination address against the configured BR IPv6 address(es). The selected MAP Rule allows the BR to determine the EA-bits from the source IPv6 address.
接收IPv6数据包的映射BR根据数据包的IPv6源地址的最长地址匹配，以及数据包目标地址与配置的BR IPv6地址的匹配，选择最佳匹配的映射域规则（规则IPv6前缀）。所选映射规则允许BR从源IPv6地址确定EA位。
To prevent spoofing of IPv4 addresses, any MAP node (CE and BR) MUST perform the following validation upon reception of a packet. First, the embedded IPv4 address or prefix, as well as the PSID (if any), are extracted from the source IPv6 address using the matching MAP Rule. These represent the range of what is acceptable as source IPv4 address and port. Second, the node extracts the source IPv4 address and port from the IPv4 packet encapsulated inside the IPv6 packet. If they are found to be outside the acceptable range, the packet MUST be silently discarded and a counter incremented to indicate that a potential spoofing attack may be underway. The source validation checks just described are not done for packets whose source IPv6 address is that of the BR (BR IPv6 address).
为了防止对IPv4地址的欺骗，任何映射节点（CE和BR）在接收到数据包时都必须执行以下验证。首先，使用匹配映射规则从源IPv6地址提取嵌入的IPv4地址或前缀以及PSID（如果有）。这些表示可接受的源IPv4地址和端口的范围。其次，节点从封装在IPv6数据包中的IPv4数据包中提取源IPv4地址和端口。如果发现它们超出可接受的范围，则必须悄悄地丢弃数据包，并增加计数器，以指示可能正在进行潜在的欺骗攻击。对于源IPv6地址为BR（BR IPv6地址）的数据包，不会执行刚才描述的源验证检查。
By default, the CE router MUST drop packets received on the MAP virtual interface (i.e., after decapsulation of IPv6) for IPv4 destinations not for its own IPv4 shared address, full IPv4 address, or IPv4 prefix.
默认情况下，CE路由器必须丢弃IPv4目的地的MAP虚拟接口上接收到的数据包（即，在IPv6解除封装后），而不是其自己的IPv4共享地址、完整IPv4地址或IPv4前缀。
ICMP messages should be supported in MAP domains. Hence, the NAT44 in the MAP CE MUST implement the behavior for ICMP messages conforming to the best current practice documented in [RFC5508].
映射域中应支持ICMP消息。因此，MAP CE中的NAT44必须实现ICMP消息的行为，符合[RFC5508]中记录的最佳当前实践。
If a MAP CE receives an ICMP message having the ICMP Identifier field in the ICMP header, the NAT44 in the MAP CE MUST rewrite this field to a specific value assigned from the port set. BRs and other CEs must handle this field in a way similar to the handling of a port number in the TCP/UDP header upon receiving the ICMP message with the ICMP Identifier field.
如果MAP CE接收到ICMP消息，ICMP头中包含ICMP标识符字段，则MAP CE中的NAT44必须将该字段重写为从端口集分配的特定值。BRs和其他CE必须以类似于在接收到带有ICMP标识符字段的ICMP消息时处理TCP/UDP报头中的端口号的方式处理此字段。
If a MAP node receives an ICMP error message without the ICMP Identifier field for errors that are detected inside an IPv6 tunnel, a node should relay the ICMP error message to the original source. This behavior SHOULD be implemented in accordance with Section 8 of [RFC2473].
如果MAP节点收到一条ICMP错误消息，但没有在IPv6隧道内检测到的错误的ICMP标识符字段，则节点应将ICMP错误消息中继到原始源。该行为应按照[RFC2473]第8节的规定执行。
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 uses all three mechanisms to deal with different cases.
由于IPv4和IPv6报头的大小不同，处理最大数据包大小与连接两个地址系列的任何系统的操作相关。有三种机制来处理此问题：路径MTU发现（PMTUD）、分段和传输层协商，如TCP最大段大小（MSS）选项[RFC879]。MAP使用所有三种机制来处理不同的情况。
Encapsulating an IPv4 packet to carry it across the MAP domain will increase its size (typically by 40 bytes). It is strongly recommended that the MTU in the MAP domain be well managed and that the IPv6 MTU on the CE WAN-side interface be set so that no fragmentation occurs within the boundary of the MAP domain.
封装IPv4数据包以将其跨MAP域传输将增加其大小（通常为40字节）。强烈建议妥善管理MAP域中的MTU，并设置CE WAN侧接口上的IPv6 MTU，以便MAP域边界内不会出现碎片。
For an IPv4 packet entering a MAP domain, fragmentation is performed as described in Section 7.2 of [RFC2473].
对于进入映射域的IPv4数据包，按照[RFC2473]第7.2节所述执行分段。
The use of an anycast source address could lead to an ICMP error message generated on the path being sent to a different BR. Therefore, using a dynamically set tunnel MTU (Section 6.7 of [RFC2473]) is subject to IPv6 Path MTU black holes. A MAP BR using an anycast source address SHOULD NOT by default use Path MTU Discovery across the MAP domain.
使用选播源地址可能导致在发送到其他BR的路径上生成ICMP错误消息。因此，使用动态设置的隧道MTU（RFC2473第6.7节）受IPv6路径MTU黑洞的影响。默认情况下，使用选播源地址的映射BR不应跨映射域使用路径MTU发现。
Multiple BRs using the same anycast source address could send fragmented packets to the same CE at the same time. If the fragmented packets from different BRs happen to use the same fragment ID, incorrect reassembly might occur. See [RFC4459] for an analysis of the problem; Section 3.4 of [RFC4459] suggests solving the problem by fragmenting the inner packet.
使用相同选播源地址的多个BR可以同时向同一CE发送碎片数据包。如果来自不同BRs的碎片数据包恰好使用相同的碎片ID，则可能会发生错误的重新组装。有关问题的分析，请参见[RFC4459]；[RFC4459]第3.4节建议通过分割内部数据包来解决问题。
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 has to reassemble the packet before sending the packet onto the MAP link. 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. Implementers of MAP should be aware that there are a number of well-known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. Implementers should also be aware of additional issues with reassembling packets at high rates, as described in [RFC4963].
转发从映射域外部接收的IPv4数据包需要IPv4目标地址和传输协议目标端口。传输协议信息仅在接收到的第一个片段中可用。如[RFC6346]第5.3.3节所述，从外部接收IPv4碎片数据包的MAP节点必须在将数据包发送到MAP链路之前重新组装数据包。如果接收到的第一个数据包包含传输协议信息，则可以通过使用缓存并转发未更改的片段来优化此行为。MAP的实施者应该意识到存在许多针对IP碎片的众所周知的攻击；参见[RFC1858]和[RFC3128]。如[RFC4963]中所述，实现者还应注意在高速率下重新组装数据包的其他问题。
If two IPv4 hosts behind two different MAP CEs with the same IPv4 address send fragments to an IPv4 destination host outside the domain, those hosts may use the same IPv4 fragmentation identifier, resulting in incorrect reassembly of the fragments at the destination host. Given that the IPv4 fragmentation identifier is a 16-bit field, it could be used similarly to port ranges. A MAP CE could rewrite the IPv4 fragmentation identifier to be within its allocated port set, if the resulting fragment identifier space was large enough related to the rate at which fragments were sent. However, splitting the identifier space in this fashion would increase the probability of reassembly collisions for all connections through the Customer Premises Equipment (CPE). See also [RFC6864].
如果两个具有相同IPv4地址的不同映射CE后面的两个IPv4主机向域外的IPv4目标主机发送碎片，则这些主机可能使用相同的IPv4碎片标识符，从而导致在目标主机上错误地重新组装碎片。考虑到IPv4分段标识符是一个16位字段，它可以类似于端口范围来使用。如果生成的片段标识符空间足够大，与发送片段的速率相关，则映射CE可以将IPv4片段标识符重写为在其分配的端口集中。然而，以这种方式分割标识符空间将增加通过客户场所设备（CPE）的所有连接的重新组装冲突的概率。另见[RFC6864]。
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的操作必须限制为通过基本映射规则导出的可用端口号。
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 DS-Lite and NAT64/DNS64. The best protection against such attacks is to accelerate IPv6 deployment so that address sharing is used less and less where MAP is supported.
拒绝服务攻击：在共享IPv4地址的映射域中，可能需要重新组装IPv4数据报这一事实为DoS攻击提供了机会。这是地址共享的固有特性，与其他地址共享方法（如DS Lite和NAT64/DNS64）相同。针对此类攻击的最佳保护措施是加快IPv6部署，以便在支持MAP的地方越来越少地使用地址共享。
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 [RFC5625] function to handle DNS traffic and source such traffic from IPv6 interfaces not assigned to MAP.
受限端口集促成的攻击：来自不受入口过滤[RFC2827]约束的主机，攻击者可以在正在进行的传输连接[RFC4953][RFC5961][RFC6056]期间注入伪造数据包。攻击取决于猜测目标主机当前使用的端口。最好使用不受限制的端口集，即使用不受映射端口范围限制的本机IPv6连接。为了在使用受限端口集时最小化这些类型的攻击，MAP CE的NAT44过滤行为应为[RFC4787]第5节中所述的“地址相关过滤”。此外，MAP CE应使用DNS传输代理[RFC5625]功能来处理DNS流量，并从未分配给MAP的IPv6接口中获取此类流量。
[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>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，DOI 10.17487/RFC2473，1998年12月<http://www.rfc-editor.org/info/rfc2473>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <http://www.rfc-editor.org/info/rfc5625>.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 5625，DOI 10.17487/RFC5625，2009年8月<http://www.rfc-editor.org/info/rfc5625>.
[MAP-Deploy] Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, "Mapping of Address and Port (MAP) - Deployment Considerations", Work in Progress, draft-ietf-softwire-map-deployment-06, June 2015.
[MAP Deploy]Sun，Q.，Chen，M.，Chen，G.，Tsou，T.，和S.Perreault，“地址和端口映射（MAP）-部署注意事项”，正在进行的工作，草稿-ietf-softwire-MAP-Deployment-062015年6月。
[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>.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, DOI 10.17487/RFC1858, October 1995, <http://www.rfc-editor.org/info/rfc1858>.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，DOI 10.17487/RFC1858，1995年10月<http://www.rfc-editor.org/info/rfc1858>.
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, DOI 10.17487/RFC1933, April 1996, <http://www.rfc-editor.org/info/rfc1933>.
[RFC1933]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 1933，DOI 10.17487/RFC1933，1996年4月<http://www.rfc-editor.org/info/rfc1933>.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, DOI 10.17487/RFC2529, March 1999, <http://www.rfc-editor.org/info/rfc2529>.
[RFC2529]Carpenter，B.和C.Jung，“无显式隧道的IPv4域上IPv6传输”，RFC 2529，DOI 10.17487/RFC2529，1999年3月<http://www.rfc-editor.org/info/rfc2529>.
[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>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, <http://www.rfc-editor.org/info/rfc3056>.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，DOI 10.17487/RFC3056，2001年2月<http://www.rfc-editor.org/info/rfc3056>.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, DOI 10.17487/RFC3128, June 2001, <http://www.rfc-editor.org/info/rfc3128>.
[RFC3128]Miller，I.，“防止微小碎片攻击的变体（RFC 1858）”，RFC 3128，DOI 10.17487/RFC3128，2001年6月<http://www.rfc-editor.org/info/rfc3128>.
[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>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，DOI 10.17487/RFC4213，2005年10月<http://www.rfc-editor.org/info/rfc4213>.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2006, <http://www.rfc-editor.org/info/rfc4459>.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，DOI 10.17487/RFC4459，2006年4月<http://www.rfc-editor.org/info/rfc4459>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，DOI 10.17487/RFC4632，2006年8月<http://www.rfc-editor.org/info/rfc4632>.
[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>.
[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>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, <http://www.rfc-editor.org/info/rfc4963>.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，DOI 10.17487/RFC4963，2007年7月<http://www.rfc-editor.org/info/rfc4963>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 5214，DOI 10.17487/RFC5214，2008年3月<http://www.rfc-editor.org/info/rfc5214>.
[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>.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，DOI 10.17487/RFC5969，2010年8月<http://www.rfc-editor.org/info/rfc5969>.
[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>.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 10.17487/RFC6250, May 2011, <http://www.rfc-editor.org/info/rfc6250>.
[RFC6250]Thaler，D.，“知识产权模型的演变”，RFC 6250，DOI 10.17487/RFC6250，2011年5月<http://www.rfc-editor.org/info/rfc6250>.
[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>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 6333，DOI 10.17487/RFC6333，2011年8月<http://www.rfc-editor.org/info/rfc6333>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[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>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, <http://www.rfc-editor.org/info/rfc6864>.
[RFC6864]Touch，J.，“IPv4 ID字段的更新规范”，RFC 6864，DOI 10.17487/RFC6864，2013年2月<http://www.rfc-editor.org/info/rfc6864>.
[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月。
[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 MAP domain information and an IPv6 address of an endpoint:
给定映射域信息和端点的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: o - 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: o - 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 IPv6 prefix.
BMR信息允许映射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 BR, configured with the following FMR when receiving a packet with the following characteristics:
另一个示例是MAP BR，当接收具有以下特征的数据包时，配置有以下FMR：
IPv4 source address: 1.2.3.4 (0x01020304) IPv4 source port: 80 IPv4 destination address: 192.0.2.18 (0xc0000212) IPv4 destination port: 1232
IPv4源地址：1.2.3.4（0x01020304）IPv4源端口：80 IPv4目标地址：192.0.2.18（0xc0000212）IPv4目标端口：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)}
IPv6 address of MAP BR: 2001:db8:ffff::1
IPv6 address of MAP BR: 2001:db8:ffff::1
The above information allows the BR to derive the mapped destination IPv6 address for the corresponding MAP CE, and also the mapped source IPv6 address for the IPv4 source address, as follows:
上述信息允许BR派生相应映射CE的映射目标IPv6地址，以及IPv4源地址的映射源IPv6地址，如下所示：
IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
PSID length: 8
PSID: 0x34 (1232)
IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
PSID length: 8
PSID: 0x34 (1232)
The resulting IPv6 packet will have the following key fields:
生成的IPv6数据包将具有以下关键字段：
IPv6 source address: 2001:db8:ffff::1
IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
IPv6 source address: 2001:db8:ffff::1
IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
Example 3 - Forwarding Mapping Rule:
示例3-转发映射规则：
An IPv4 host behind the MAP CE (addressed as per the previous examples) corresponding with IPv4 host 1.2.3.4 will have its packets encapsulated by IPv6 using the IPv6 address of the BR configured on the MAP CE as follows:
与IPv4主机1.2.3.4相对应的映射CE后面的IPv4主机（按照前面的示例寻址）将使用映射CE上配置的BR的IPv6地址通过IPv6封装其数据包，如下所示：
IPv6 address of BR: 2001:db8:ffff::1
IPv4 source address: 192.0.2.18
IPv4 destination address: 1.2.3.4
IPv4 source port: 1232
IPv4 destination port: 80
MAP CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034
IPv6 destination address: 2001:db8:ffff::1
IPv6 address of BR: 2001:db8:ffff::1
IPv4 source address: 192.0.2.18
IPv4 destination address: 1.2.3.4
IPv4 source port: 1232
IPv4 destination port: 80
MAP CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034
IPv6 destination address: 2001:db8:ffff::1
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.18/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.18/32 (Rule IPv4 prefix),
0 (Rule EA-bit length)}
PSID length: 0 (sharing ratio is 1)
PSID offset: n/a
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: 0 IPv4 suffix bits (p): Length of IPv4 address (32) - IPv4 prefix length (32) = 0 IPv4 address: 192.0.2.18 (0xc0000212) PSID start: 0 PSID length: 0 PSID: null
EA位偏移量：0 IPv4后缀位（p）：IPv4地址长度（32）-IPv4前缀长度（32）=0 IPv4地址：192.0.2.18（0xc0000212）PSID开始：0 PSID长度：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:0212:0000
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212: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: 8 (from DHCP; sharing ratio of 256)
PSID offset: 6 (default)
PSID: 0x34 (from DHCP)
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: 8 (from DHCP; sharing ratio of 256)
PSID offset: 6 (default)
PSID: 0x34 (from DHCP)
A MAP node can, via the Basic Mapping Rule, determine the IPv4 address and port set as shown below:
映射节点可以通过基本映射规则确定IPv4地址和端口集，如下所示：
EA bits offset: 0 IPv4 suffix bits (p): Length of IPv4 address (32) - IPv4 prefix length (32) = 0 IPv4 address: 192.0.2.18 (0xc0000212) PSID offset: 6 PSID length: 8 PSID: 0x34
EA位偏移量：0 IPv4后缀位（p）：IPv4地址长度（32）-IPv4前缀长度（32）=0 IPv4地址：192.0.2.18（0xc0000212）PSID偏移量：6 PSID长度：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 Basic Mapping Rule 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).
基本映射规则信息允许映射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, DHCP.
请注意，IPv4地址和PSID不是从分配给CE的IPv6前缀派生的，而是使用DHCP等单独设置的。
Appendix B. A More Detailed Description of the Derivation of the Port-Mapping Algorithm
附录B.端口映射算法推导的更详细说明
This appendix describes how the port-mapping algorithm described in Section 5.1 was derived. The algorithm is used in domains whose rules allow IPv4 address sharing.
本附录描述了第5.1节中描述的端口映射算法的推导过程。该算法用于规则允许IPv4地址共享的域。
The basic requirement for a port-mapping algorithm is that the port sets it assigns to different MAP CEs MUST be non-overlapping. A number of other requirements guided the choice of the algorithm:
端口映射算法的基本要求是，它分配给不同映射CE的端口集必须不重叠。许多其他要求指导了算法的选择：
o In keeping with the general MAP algorithm, the port set MUST be derivable from a Port Set identifier (PSID) that can be embedded in the End-user IPv6 prefix.
o 为了与通用映射算法保持一致，端口集必须可以从可嵌入最终用户IPv6前缀中的端口集标识符（PSID）派生。
o The mapping MUST be reversible such that, given the port number, the PSID of the port set to which it belongs can be quickly derived.
o 映射必须是可逆的，以便在给定端口号的情况下，可以快速导出它所属的端口集的PSID。
o The algorithm MUST allow a broad range of address-sharing ratios.
o 该算法必须允许广泛的地址共享比率。
o It SHOULD be possible to exclude subsets of the complete port numbering space from assignment. Most operators would exclude the system ports (0-1023). A conservative operator might exclude all but the transient ports (49152-65535).
o 应该可以从分配中排除完整端口编号空间的子集。大多数运营商将排除系统端口（0-1023）。保守运算符可能排除除瞬态端口（49152-65535）以外的所有端口。
o The effect of port exclusion on the possible values of the End-user IPv6 prefix (i.e., due to restrictions on the PSID value) SHOULD be minimized.
o 端口排除对最终用户IPv6前缀可能值的影响（即，由于对PSID值的限制）应最小化。
o For administrative simplicity, the algorithm SHOULD allocate the same or almost the same number of ports to each CE sharing a given IPv4 address.
o 为了简化管理，算法应该为共享给定IPv4地址的每个CE分配相同或几乎相同数量的端口。
The two extreme cases that an algorithm satisfying those conditions might support are when (1) the port numbers are not contiguous for each PSID but uniformly distributed across the allowed port range and (2) the port numbers are contiguous in a single range for each PSID. The port-mapping algorithm proposed here is called the Generalized Modulus Algorithm (GMA) and supports both of these cases.
满足这些条件的算法可能支持的两种极端情况是：（1）每个PSID的端口号不连续，但均匀分布在允许的端口范围内；（2）每个PSID的端口号在单个范围内连续。这里提出的端口映射算法称为广义模算法（GMA），支持这两种情况。
For a given IPv4 address-sharing ratio (R) and the maximum number of contiguous ports (M) in a port set, the GMA is defined as follows:
对于给定的IPv4地址共享比率（R）和端口集中最大连续端口数（M），GMA定义如下：
a. The port numbers (P) corresponding to a given PSID are generated by:
a. 与给定PSID对应的端口号（P）由以下公式生成：
(1) ... P = (R * M) * i + M * PSID + j
(1) ... P = (R * M) * i + M * PSID + j
where i and j are indices and the ranges of i, j, and the PSID are discussed below.
其中i和j是指数，i、j和PSID的范围如下所述。
b. For any given port number P, the PSID is calculated as:
b. 对于任何给定端口号P，PSID的计算公式为：
(2) ... PSID = trunc((P modulo (R * M)) / M)
(2) ... PSID = trunc((P modulo (R * M)) / M)
where trunc() is the operation of rounding down to the nearest integer.
其中trunc（）是向下舍入到最接近的整数的操作。
Formula (1) can be interpreted as follows. First, the available port space is divided into blocks of size R * M. Each block is divided into R individual ranges of length M. The index i in formula (1) selects a block, PSID selects a range within that block, and the index j selects a specific port value within the range. On the basis of this interpretation:
公式（1）可解释如下。首先，将可用端口空间划分为大小为R*M的块。每个块划分为长度为M的R个单独范围。公式（1）中的索引i选择块，PSID选择该块内的范围，索引j选择该范围内的特定端口值。根据这一解释：
o i ranges from ceil(N / (R * M)) to trunc(65536/(R * M)) - 1, where ceil is the operation of rounding up to the nearest integer and N is the number of ports (e.g., 1024) excluded from the lower end of the range. That is, any block containing excluded values is discarded at the lower end, and if the final block has fewer than R * M values it is discarded. This ensures that the same number of ports is assigned to every PSID.
o i的范围从ceil（N/（R*M））到trunc（65536/（R*M））-1，其中ceil是四舍五入到最接近的整数的运算，N是从范围下限排除的端口数（例如1024个）。也就是说，包含排除值的任何块在低端被丢弃，如果最后一个块的值小于R*M，则丢弃该块。这确保为每个PSID分配相同数量的端口。
o PSID ranges from 0 to R - 1.
o PSID范围从0到R-1。
o j ranges from 0 to M - 1.
o j的范围从0到M-1。
If R and M are powers of 2 (R = 2^k, M = 2^m), formula (1) translates to a computationally convenient structure for any port number represented as a 16-bit binary number. This structure is shown in Figure 9.
如果R和M是2的幂（R=2^k，M=2^M），则公式（1）转换为表示为16位二进制数的任何端口号的计算方便的结构。该结构如图9所示。
0 8 15
+---------------+----------+------+-------------------+
| P |
----------------+-----------------+-------------------+
| i | PSID | j |
+---------------+----------+------+-------------------+
|<----a bits--->|<-----k bits---->|<------m bits----->|
0 8 15
+---------------+----------+------+-------------------+
| P |
----------------+-----------------+-------------------+
| i | PSID | j |
+---------------+----------+------+-------------------+
|<----a bits--->|<-----k bits---->|<------m bits----->|
Figure 9: Bit Representation of a Port Number
图9：端口号的位表示
As shown in the figure, the index value i of formula (1) is given by the first a = 16 - k - m bits of the port number. The PSID value is given by the next k bits, and the index value j is given by the last m bits.
如图所示，公式（1）的索引值i由端口号的前a=16-k-m位给出。PSID值由下一个k位给出，索引值j由最后m位给出。
Because the PSID is always in the same position in the port number and always the same length, different PSID values are guaranteed to generate different sets of port numbers. In the reverse direction, the generating PSID can be extracted from any port number by a bitmask operation.
由于PSID在端口号中始终处于同一位置且长度始终相同，因此不同的PSID值保证生成不同的端口号集。在相反方向上，可以通过位掩码操作从任何端口号提取生成的PSID。
Note that when M and R are powers of 2, 65536 divides evenly by R * M. Hence, the final block is complete, and the upper bound on i is exactly 65536/(R * M) - 1. The lower bound on i is still the minimum required to ensure that the required set of ports is excluded. No port numbers are wasted through the discarding of blocks at the lower end if block size R * M is a factor of N, the number of ports to be excluded.
注意，当M和R是2的幂时，65536除以R*M。因此，最后一个块是完整的，i的上界正好是65536/（R*M）-1。i上的下限仍然是确保排除所需端口集所需的最小值。如果块大小R*M是要排除的端口数N的因子，则不会因丢弃低端的块而浪费端口号。
As a final note, the number of blocks into which the range 0-65535 is being divided in the above representation is given by 2^a. Hence, the case where a = 0 can be interpreted as one where the complete range has been divided into a single block, and individual port sets are contained in contiguous ranges in that block. We cannot throw away the whole block in that case, so port exclusion has to be achieved by putting a lower bound equal to ceil(N / M) on the allowed set of PSID values instead.
最后，在上述表示中，0-65535范围被划分成的块的数量由2^a给出。因此，a＝0的情况可以解释为完整范围被划分为单个块，并且单个端口集包含在该块中的连续范围中。在这种情况下，我们不能丢弃整个块，因此必须通过在允许的PSID值集上设置等于ceil（N/M）的下限来实现端口排除。
For example, for R = 256, PSID = 0, offset: a = 6 and PSID length: k = 8 bits:
例如，对于R=256、PSID=0、偏移量：a=6和PSID长度：k=8位：
Available ports (63 ranges): 1024-1027, 2048-2051, ...... ,
63488-63491, 64512-64515
Available ports (63 ranges): 1024-1027, 2048-2051, ...... ,
63488-63491, 64512-64515
Example 1: with offset = 6 (a = 6)
Example 1: with offset = 6 (a = 6)
For example, for R = 64, PSID = 0, a = 0 (PSID offset = 0 and PSID length = 6 bits), no port exclusion:
例如，对于R=64，PSID=0，a=0（PSID偏移量=0，PSID长度=6位），无端口排除：
Available ports (1 range): 0-1023
可用端口（1个范围）：0-1023
Example 2: with offset = 0 (a = 0) and N = 0
Example 2: with offset = 0 (a = 0) and N = 0
Acknowledgements
致谢
This document is based on the ideas of many, including Masakazu Asama, Mohamed Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni Korhonen, Tomek Mrugalski, Jacni Qin, Chunfa Sun, Qiong Sun, and Leaf Yeh. The authors want in particular to recognize Remi Despres, who has tirelessly worked on generalized mechanisms for stateless address mapping.
本文件基于许多人的想法，包括Asama Masakazu、Mohamed Boucadair、陈刚、陈茂科、Wojciech Dec、邓晓红、Jouni Korhonen、Tomek Mrugalski、Jacni Qin、孙春发、孙琼和叶莉。作者特别希望认识Remi Despres，他不懈地致力于无状态地址映射的通用机制。
The authors would like to thank Lichun Bao, Guillaume Gottard, Dan Wing, Jan Zorz, Necj Scoberne, Tina Tsou, Kristian Poscic, and especially Tom Taylor and Simon Perreault for the thorough review and comments of this document. Useful IETF Last Call comments were received from Brian Weis and Lei Yan.
作者要感谢鲍立春、纪尧姆·戈塔德、丹·荣、扬·佐尔兹、内基·斯科伯恩、蒂娜·邹、克里斯蒂安·波西奇，尤其是汤姆·泰勒和西蒙·佩雷尔特对本文件的全面审查和评论。Brian Weis和Lei Yan提供了有用的IETF上次通话评论。
Contributors
贡献者
This document is the result of the IETF Softwire MAP design team effort and numerous previous individual contributions in this area:
本文件是IETF Softwire地图设计团队努力的结果，以及在此领域的众多个人贡献：
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
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
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
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
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
Authors' Addresses
作者地址
Ole Troan (editor) Cisco Systems Philip Pedersens vei 1 Lysaker 1366 Norway
Ole Troan（编辑）思科系统Philip Pedersens vei 1 Lysaker 1366挪威
Email: ot@cisco.com
Email: ot@cisco.com
Wojciech Dec Cisco Systems Haarlerbergpark Haarlerbergweg 13-19 Amsterdam, NOORD-HOLLAND 1101 CH The Netherlands
Wojciech Dec思科系统哈勒贝格公园哈勒贝格韦格13-19阿姆斯特丹，荷兰诺德1101 CH
Email: wdec@cisco.com
Email: wdec@cisco.com
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
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
Tom Taylor (editor) Huawei Technologies Ottawa Canada
汤姆泰勒（编辑）华为技术加拿大渥太华
Email: tom.taylor.stds@gmail.com
Email: tom.taylor.stds@gmail.com