Internet Engineering Task Force (IETF) C. Zhou
Request for Comments: 7678 Huawei Technologies
Category: Standards Track T. Taylor
ISSN: 2070-1721 PT Taylor Consulting
Q. Sun
China Telecom
M. Boucadair
France Telecom
October 2015
Internet Engineering Task Force (IETF) C. Zhou
Request for Comments: 7678 Huawei Technologies
Category: Standards Track T. Taylor
ISSN: 2070-1721 PT Taylor Consulting
Q. Sun
China Telecom
M. Boucadair
France Telecom
October 2015
Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions
用于调配支持IPv4-Over-IPv6过渡解决方案的客户设备的属性值对
Abstract
摘要
During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.
在从IPv4过渡到IPv6的过程中，客户设备可能必须支持为通过IPv6承载IPv4数据包而定义的各种过渡方法之一。本文档列举了需要在客户边缘路由器上提供的信息，以支持基于IPv6中隧道IPv4的转换技术列表，目的是为这些技术之间的合理转换路径定义可重用组件。在动态完成供应的情况下，需要身份验证、授权和记帐（AAA）支持，以将信息提供给负责将信息传递给客户设备的网络服务器。本文件规定了用于该目的的直径（RFC 6733）属性值对（AVP）。
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/rfc7678.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7678.
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Description of the Parameters Required by Each Transition
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Parameters for Dual-Stack Lite (DS-Lite) . . . . . . . . 6
2.2. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . . . 6
2.3. Port Set Specification . . . . . . . . . . . . . . . . . 7
2.4. Mapping of Address and Port with Encapsulation (MAP-E) . 7
2.5. Parameters for Multicast . . . . . . . . . . . . . . . . 8
2.6. Summary and Discussion . . . . . . . . . . . . . . . . . 9
3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . 9
3.1. IP-Prefix-Length AVP . . . . . . . . . . . . . . . . . . 10
3.2. Border-Router-Name AVP . . . . . . . . . . . . . . . . . 10
3.3. 64-Multicast-Attributes AVP . . . . . . . . . . . . . . . 10
3.3.1. ASM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 11
3.3.2. SSM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 11
3.3.3. Delegated-IPv6-Prefix AVP as uPrefix64 . . . . . . . 12
3.4. Tunnel-Source-Pref-Or-Addr AVP . . . . . . . . . . . . . 12
3.4.1. Delegated-IPv6-Prefix as the IPv6 Binding Prefix . . 12
3.4.2. Tunnel-Source-IPv6-Address AVP . . . . . . . . . . . 12
3.5. Port-Set-Identifier . . . . . . . . . . . . . . . . . . . 13
3.6. Lw4o6-Binding AVP . . . . . . . . . . . . . . . . . . . . 13
3.6.1. Lw4o6-External-IPv4-Addr AVP . . . . . . . . . . . . 14
3.7. MAP-E-Attributes . . . . . . . . . . . . . . . . . . . . 14
3.8. MAP-Mesh-Mode . . . . . . . . . . . . . . . . . . . . . . 15
3.9. MAP-Mapping-Rule . . . . . . . . . . . . . . . . . . . . 15
3.9.1. Rule-IPv4-Addr-Or-Prefix AVP . . . . . . . . . . . . 16
3.9.2. Rule-IPv6-Prefix AVP . . . . . . . . . . . . . . . . 16
3.9.3. EA-Field-Length AVP . . . . . . . . . . . . . . . . . 17
4. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Man-In-The-Middle (MITM) Attacks . . . . . . . . . . . . 19
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Description of the Parameters Required by Each Transition
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Parameters for Dual-Stack Lite (DS-Lite) . . . . . . . . 6
2.2. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . . . 6
2.3. Port Set Specification . . . . . . . . . . . . . . . . . 7
2.4. Mapping of Address and Port with Encapsulation (MAP-E) . 7
2.5. Parameters for Multicast . . . . . . . . . . . . . . . . 8
2.6. Summary and Discussion . . . . . . . . . . . . . . . . . 9
3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . 9
3.1. IP-Prefix-Length AVP . . . . . . . . . . . . . . . . . . 10
3.2. Border-Router-Name AVP . . . . . . . . . . . . . . . . . 10
3.3. 64-Multicast-Attributes AVP . . . . . . . . . . . . . . . 10
3.3.1. ASM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 11
3.3.2. SSM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 11
3.3.3. Delegated-IPv6-Prefix AVP as uPrefix64 . . . . . . . 12
3.4. Tunnel-Source-Pref-Or-Addr AVP . . . . . . . . . . . . . 12
3.4.1. Delegated-IPv6-Prefix as the IPv6 Binding Prefix . . 12
3.4.2. Tunnel-Source-IPv6-Address AVP . . . . . . . . . . . 12
3.5. Port-Set-Identifier . . . . . . . . . . . . . . . . . . . 13
3.6. Lw4o6-Binding AVP . . . . . . . . . . . . . . . . . . . . 13
3.6.1. Lw4o6-External-IPv4-Addr AVP . . . . . . . . . . . . 14
3.7. MAP-E-Attributes . . . . . . . . . . . . . . . . . . . . 14
3.8. MAP-Mesh-Mode . . . . . . . . . . . . . . . . . . . . . . 15
3.9. MAP-Mapping-Rule . . . . . . . . . . . . . . . . . . . . 15
3.9.1. Rule-IPv4-Addr-Or-Prefix AVP . . . . . . . . . . . . 16
3.9.2. Rule-IPv6-Prefix AVP . . . . . . . . . . . . . . . . 16
3.9.3. EA-Field-Length AVP . . . . . . . . . . . . . . . . . 17
4. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Man-In-The-Middle (MITM) Attacks . . . . . . . . . . . . 19
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
A number of transition techniques have been defined to allow IPv4 packets to pass between hosts and IPv4 networks over an intervening IPv6 network while minimizing the number of public IPv4 addresses that need to be consumed by the hosts. Different operators will deploy different technologies, and sometimes one operator will use more than one technology depending on what is supported by the available equipment and upon other factors both technical and economic.
已经定义了许多转换技术，以允许IPv4数据包通过干预IPv6网络在主机和IPv4网络之间传递，同时最小化主机需要使用的公共IPv4地址的数量。不同的运营商将部署不同的技术，有时一个运营商将使用多种技术，这取决于可用设备支持的内容以及其他技术和经济因素。
Each technique requires the provisioning of some subscriber-specific information on the customer edge device. The provisioning may be by DHCPv6 [RFC3315] or by some other method. This document is indifferent to the specific provisioning technique used but assumes a deployment in which that information is managed by AAA (Authentication, Authorization, and Accounting) servers. It further assumes that this information is delivered to intermediate network nodes for onward provisioning using the Diameter protocol [RFC6733].
每种技术都需要在客户边缘设备上提供一些特定于订户的信息。供应可以通过DHCPv6[RFC3315]或通过某种其他方法进行。本文档与所使用的特定资源调配技术无关，但假定该信息由AAA（身份验证、授权和记帐）服务器管理。它还假设该信息通过Diameter协议[RFC6733]传递到中间网络节点，以便进行进一步的供应。
As described below, in the particular case where the Lightweight 4over6 (lw4o6) [RFC7596] transition method has been deployed, per-subscriber-site information almost identical to that passed to the subscriber site [RFC7598] also needs to be delivered to the border router serving that site. The Diameter protocol may be used for this purpose too.
如下所述，在已部署轻量级4over6（lw4o6）[RFC7596]转换方法的特定情况下，每个订户站点的信息几乎与传递到订户站点[RFC7598]的信息相同，也需要传递到服务于该站点的边界路由器。直径协议也可用于此目的。
This document analyzes the information required to configure the customer edge equipment for the following set of transition methods:
本文件分析了为以下过渡方法配置客户边缘设备所需的信息：
o Dual-Stack Lite (DS-Lite) [RFC6333],
o 双栈精简版（DS精简版）[RFC6333]，
o Lightweight 4over6 (lw4o6) [RFC7596], and
o 轻质4over6（lw4o6）[RFC7596]，以及
o Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597].
o 地址和端口的封装映射（MAP-E）[RFC7597]。
[DSLITE-MULTICAST] specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution was developed with DS-Lite in mind but it is not limited to DS-Lite. As such, it applies also for lw4o6 and MAP-E. This document analyzes the information required to configure the customer edge equipment for the support of multicast in the context of DS-Lite, MAP-E, and lw4o6 in particular.
[DSLITE-MULTICAST]指定通过IPv6多播网络向IPv4客户端提供IPv4多播服务的通用解决方案。该解决方案是在考虑DS Lite的情况下开发的，但不限于DS Lite。同样，它也适用于lw4o6和MAP-E。本文档分析了在DS Lite、MAP-E和lw4o6环境中配置客户边缘设备以支持多播所需的信息。
On the basis of those analyses, it specifies a number of Attribute-Value Pairs (AVPs) to allow the necessary subscriber-site-specific configuration information to be carried in Diameter.
在这些分析的基础上，它指定了一些属性值对（AVP），以允许在直径中携带必要的订户站点特定配置信息。
This document doesn't specify any new commands or Application IDs. The specified AVPs could be used for any Diameter application suitable for provisioning.
本文档未指定任何新命令或应用程序ID。指定的AVP可用于任何适合供应的Diameter应用程序。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The abbreviation CPE stands for Customer Premise Equipment. It denotes the equipment at the customer edge that terminates the customer end of an IPv6 transitional tunnel. This will usually be a router but could be a host directly connected to the network. In some documents (e.g., [RFC7597]), this functional entity is called CE (Customer Edge).
缩写CPE代表客户场所设备。它表示在客户边缘终止IPv6过渡隧道的客户端的设备。这通常是一个路由器，但也可以是一个直接连接到网络的主机。在某些文档（例如[RFC7597]）中，此功能实体称为CE（客户边缘）。
The term "tunnel source address" is used to denote the IPv6 source address used in the outer header of packets sent from the CPE through an lw4o6 transitional tunnel to the border router.
术语“隧道源地址”用于表示在从CPE通过lw4o6过渡隧道发送到边界路由器的分组的外部报头中使用的IPv6源地址。
This section reviews the parameters that need to be provisioned for each of the transition methods listed above. This enumeration provides the justification for the AVPs defined in the next section.
本节回顾需要为上面列出的每个转换方法设置的参数。此枚举为下一节中定义的AVP提供了理由。
A means is required to indicate which transition method(s) a given subscriber wants to use. The approach taken in this document is to specify Grouped AVPs specific to lw4o6 and MAP-E. The operator can control which of these two transition methods a given subscriber uses by ensuring that AAA passes only the Grouped AVP relevant to that method. A Grouped AVP is unnecessary for DS-Lite since AAA has only to provide the Fully Qualified Domain Name (FQDN) of the DS-Lite Address Family Transition Router (AFTR) (see Section 2.1). Hence, when no Grouped AVP is provided either for lw4o6 or MAP-E and only the AFTR's FQDN is present, this indicates that the subscriber equipment will use the DS-Lite transition method. Provisioning of multicast is an orthogonal activity since it is independent of the transition method.
需要一种方法来指示给定订阅者想要使用的转换方法。本文件中采用的方法是指定特定于lw4o6和MAP-E的分组AVP。运营商可以通过确保AAA仅通过与该方法相关的分组AVP来控制给定订户使用这两种转换方法中的哪一种。DS Lite不需要分组AVP，因为AAA只需提供DS Lite地址系列转换路由器（AFTR）的完全限定域名（FQDN）（见第2.1节）。因此，当lw4o6或MAP-E均未提供分组AVP且仅存在AFTR的FQDN时，这表示订户设备将使用DS-Lite转换方法。提供多播是一种正交活动，因为它独立于转换方法。
DS-Lite is documented in [RFC6333]. The Basic Bridging BroadBand (B4) element at the customer premises needs to discover the IPv6 address of the AFTR (border router). For the reasons discussed in Section 3.2, the AAA server provisions the B4 element with the AFTR's FQDN that is passed to a B4's IP resolution library. The AFTR's FQDN is contained in the Border-Router-Name AVP (see Section 3.2).
DS Lite记录在[RFC6333]中。客户场所的基本桥接宽带（B4）元件需要发现AFTR（边界路由器）的IPv6地址。出于第3.2节中讨论的原因，AAA服务器为B4元素提供AFTR的FQDN，该FQDN传递给B4的IP解析库。AFTR的FQDN包含在边界路由器名称AVP中（见第3.2节）。
The B4 element could also be configured with the IPv4 address of the B4 interface facing the tunnel, with valid values from 192.0.0.2 to 192.0.0.7 and the default value of 192.0.0.2 in the absence of provisioning. Provisioning such information through AAA is problematic because it is most likely used in a case where multiple B4 instances occupy the same device. This document therefore assumes that the B4 interface address is determined by other means than AAA (implementation dependent or static assignment).
B4元素还可以配置为B4接口的IPv4地址面向隧道，有效值从192.0.0.2到192.0.0.7，在没有设置的情况下默认值为192.0.0.2。通过AAA提供此类信息是有问题的，因为它最有可能用于多个B4实例占用同一设备的情况。因此，本文件假设B4接口地址由AAA（依赖于实现或静态分配）以外的其他方式确定。
Lightweight 4over6 (lw4o6) is documented in [RFC7596]. Lw4o6 requires four items to be provisioned to the customer equipment:
[RFC7596]中记录了轻型4over6（lw4o6）。Lw4o6需要向客户设备提供四项：
o an IPv6 address of the border router.
o 边界路由器的IPv6地址。
o an IPv6 prefix used by the CPE to construct the tunnel source address. In the terminology of [RFC7596], this is the IPv6 Binding Prefix.
o CPE用于构造隧道源地址的IPv6前缀。在[RFC7596]的术语中，这是IPv6绑定前缀。
o an IPv4 address to be used on the external side of the CPE.
o CPE外部要使用的IPv4地址。
o if the IPv4 address is shared, a specification of the port set the subscriber site is allowed to use. Please see the description in Section 2.3. For lw4o6, all three of the parameters 'a', 'k', and the Port Set Identifier (PSID) described in that section are required. The default value of the offset parameter 'a' is 0.
o 如果IPv4地址是共享的，则允许订户站点使用端口集的规范。请参见第2.3节中的说明。对于lw4o6，该节中描述的所有三个参数“a”、“k”和端口集标识符（PSID）都是必需的。偏移参数“a”的默认值为0。
As discussed in Section 4 of [RFC7596], it is necessary to synchronize this configuration with corresponding per-subscriber configuration at the border router. The border router information consists of the same public IPv4 address and port set parameters that are passed to the CPE, bound together with the full /128 IPv6 address (not just the Binding Prefix) configured as the tunnel source address at the CPE.
如[RFC7596]第4节所述，有必要在边界路由器上将此配置与相应的每用户配置同步。边界路由器信息由传递给CPE的相同公共IPv4地址和端口集参数组成，与CPE处配置为隧道源地址的完整/128 IPv6地址（不仅仅是绑定前缀）绑定在一起。
When an external IPv4 address is shared, lw4o6 and MAP-E restrict the CPE to use of a subset of all available ports on the external side. Both transition methods use the algorithm defined in Appendix B of [RFC7597] to derive the values of the port numbers in the port set. This algorithm features three parameters, describing the positioning and value of the PSID within each port number of the generated set:
当共享外部IPv4地址时，lw4o6和MAP-E限制CPE使用外部侧所有可用端口的子集。两种转换方法都使用[RFC7597]附录B中定义的算法来推导端口集中的端口号值。此算法具有三个参数，描述生成集的每个端口号内PSID的位置和值：
o an offset 'a' from the beginning of the port number to the first bit of the PSID;
o 从端口号开始到PSID第一位的偏移量“a”；
o the length 'k' of the PSID within the port number, in bits; and
o 端口号内PSID的长度“k”，以位为单位；和
o the value of the PSID itself.
o PSID本身的值。
Mapping of Address and Port with Encapsulation (MAP-E) is described in [RFC7597]. MAP-E requires the provisioning of the following per-subscriber information at the customer edge device:
[RFC7597]中描述了带有封装的地址和端口映射（MAP-E）。MAP-E要求在客户边缘设备上为每个订户提供以下信息：
o the IPv6 address of one or more border routers, or in MAP-E terminology, MAP-E border relays.
o 一个或多个边界路由器的IPv6地址，或在MAP-E术语中，MAP-E边界中继。
o the unique end-user IPv6 prefix for the customer edge device. This may be provided by AAA or acquired by other means.
o 客户边缘设备的唯一最终用户IPv6前缀。这可能由AAA提供或通过其他方式获得。
o the Basic Mapping Rule for the customer edge device. This includes the following parameters:
o 客户边缘设备的基本映射规则。这包括以下参数：
* the Rule IPv6 prefix and length.
* 规则IPv6前缀和长度。
* the Rule IPv4 prefix and length. A prefix length of 0 indicates that the entire IPv4 address or prefix is coded in the Extended Address (EA) bits of the end-user IPv6 prefix rather than in the mapping rule.
* 规则IPv4前缀和长度。前缀长度为0表示整个IPv4地址或前缀在最终用户IPv6前缀的扩展地址（EA）位中编码，而不是在映射规则中编码。
* the number of EA bits included in the end-user IPv6 prefix.
* 最终用户IPv6前缀中包含的EA位数。
* port set parameters giving the set of ports the CPE is allowed to use when the IPv4 address is shared. Please see the description of these parameters in Section 2.3. At a minimum, the offset parameter 'a' is required. For MAP-E, this has the default value 6. The parameters 'k' and PSID are needed if they cannot be derived from the mapping rule information and the EA bits (final case of Section 5.2 of [RFC7597]).
* 端口集参数，提供共享IPv4地址时允许CPE使用的端口集。请参见第2.3节中对这些参数的说明。至少需要偏移参数“a”。对于MAP-E，其默认值为6。如果无法从映射规则信息和EA位（RFC7597第5.2节的最终情况）中导出参数“k”和PSID，则需要这些参数。
o whether the device is to operate in Mesh or Hub-and-Spoke mode.
o 设备是在网状模式还是轮辐式模式下运行。
o in mesh mode only, zero or more Forwarding Mapping Rules described by the same set of parameters as the Basic Mapping Rule.
o 仅在网状模式下，零个或多个转发映射规则由与基本映射规则相同的参数集描述。
As indicated in the first bullet in Section 5 of [RFC7597], a MAP CPE can be provisioned with multiple end-user IPv6 prefixes, each associated with its own Basic Mapping Rule. This does not change the basic requirement for representation of the corresponding information in the form of Diameter AVPs, but adds a potential requirement for multiple instances of this information to be present in the Diameter message, differing in the value of the end-user IPv6 prefix (in contrast to the Forward Mapping Rule instances).
如[RFC7597]第5节中的第一个项目符号所示，可以为MAP CPE提供多个最终用户IPv6前缀，每个前缀都与自己的基本映射规则相关联。这不会改变以Diameter avp形式表示相应信息的基本要求，但增加了在Diameter消息中存在此信息的多个实例的潜在要求，这与最终用户IPv6前缀的值不同（与前向映射规则实例相反）。
The border router needs to be configured with the superset of the Mapping Rules passed to the customer sites it serves. Since this requirement does not require direct coordination with CPE configuration in the way lw4o6 does, it is out of scope of the present document. However, the AVPs defined here may be useful if a separate Diameter application is used to configure the border router.
边界路由器需要配置传递给其服务的客户站点的映射规则的超集。由于该要求不需要像lw4o6那样与CPE配置直接协调，因此不在本文件范围内。但是，如果使用单独的Diameter应用程序来配置边界路由器，则此处定义的AVP可能有用。
[DSLITE-MULTICAST] specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. In particular, the solution can be deployed in a DS-Lite context but is also adaptable to lw4o6 and MAP-E. For example, [PREFIX-OPTION] specifies how DHCPv6 [RFC3315] can be used to provision multicast-related information. The following lists the multicast-related information that needs to be provisioned:
[DSLITE-MULTICAST]指定通过IPv6多播网络向IPv4客户端提供IPv4多播服务的通用解决方案。特别是，该解决方案可以部署在DS Lite上下文中，但也适用于lw4o6和MAP-E。例如，[PREFIX-OPTION]指定如何使用DHCPv6[RFC3315]提供多播相关信息。以下列出了需要设置的多播相关信息：
o ASM-mPrefix64: the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the Any-Source Multicast (ASM) mode. This is achieved by concatenating the ASM-mPrefix64 and an IPv4 multicast address; the IPv4 multicast address is inserted in the last 32 bits of the IPv4-embedded IPv6 multicast address.
o ASM-mPrefix64:用于在任意源多播（ASM）模式下合成多播组的IPv4嵌入IPv6地址的IPv6多播前缀。这是通过连接ASM-MPX64和IPv4多播地址实现的；IPv4多播地址插入IPv4嵌入式IPv6多播地址的最后32位。
o SSM-mPrefix64: the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the Source-Specific Multicast (SSM) [RFC4607] mode. This is achieved by concatenating the SSM-mPrefix64 and an IPv4 multicast address; the IPv4 multicast address is inserted in the last 32 bits of the IPv4-embedded IPv6 multicast address.
o SSM-mPrefix64：用于在源特定多播（SSM）[RFC4607]模式下合成多播组的IPv4嵌入IPv6地址的IPv6多播前缀。这是通过连接SSM-MPX64和IPv4多播地址来实现的；IPv4多播地址插入IPv4嵌入式IPv6多播地址的最后32位。
o uPrefix64: the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. uPrefix64 may also be used to extract the IPv4 address from the received multicast data flows. The address mapping follows the guidelines documented in [RFC6052].
o uPrefix64:在SSM模式中用于构造表示IPv6域中IPv4多播源的IPv4嵌入式IPv6地址的IPv6单播前缀。uPrefix64还可用于从接收的多播数据流中提取IPv4地址。地址映射遵循[RFC6052]中记录的指南。
There are two items that are common to the different transition methods, and the corresponding AVPs to carry them can be reused:
不同转换方法共有两项，可重复使用相应的AVP：
o a representation of the IPv6 address of a border router.
o 边界路由器IPv6地址的表示形式。
o a set of prefixes for delivery of multicast services to IPv4 clients over an IPv6 multicast network.
o 一组前缀，用于通过IPv6多播网络向IPv4客户端提供多播服务。
[RFC6519] sets a precedent for representation of the IPv6 address of a border router as an FQDN. This can be dereferenced to one or more IP addresses by the provisioning system before being passed to the customer equipment or left as an FQDN as it is in [RFC6334].
[RFC6519]开创了将边界路由器的IPv6地址表示为FQDN的先例。在传递给客户设备之前，供应系统可以将其解引用到一个或多个IP地址，或者将其保留为[RFC6334]中的FQDN。
The remaining requirements are transition-method specific:
其余要求是特定于过渡方法的：
o for lw4o6, a representation of a binding between (1) either the IPv6 Binding Prefix or a full /128 IPv6 address, (2) a public IPv4 address, and (3) (if the IPv4 address is shared) a port set identifier.
o 对于lw4o6，表示（1）IPv6绑定前缀或完整/128 IPv6地址，（2）公共IPv4地址和（3）（如果IPv4地址共享）端口集标识符之间的绑定。
o for MAP-E, a representation of the unique end-user IPv6 prefix for the CPE, if not provided by other means.
o 对于MAP-E，表示CPE的唯一最终用户IPv6前缀（如果没有通过其他方式提供）。
o for MAP-E, a representation of a Mapping Rule.
o 对于MAP-E，映射规则的表示形式。
o for MAP-E, an indication of whether Mesh mode or Hub-and-Spoke mode is to be used.
o 对于MAP-E，指示是使用网格模式还是轮辐模式。
This section provides the specifications for the AVPs needed to meet the requirements summarized in Section 2.6.
本节提供了满足第2.6节总结要求所需的AVP规范。
The IP-Prefix-Length AVP (AVP code 632) is of type Unsigned32. It provides the length of an IPv4 or IPv6 prefix. Valid values are from 0 to 32 for IPv4 and from 0 to 128 for IPv6. Tighter limits are given below for particular contexts of use of this AVP.
IP前缀长度AVP（AVP代码632）的类型为Unsigned32。它提供IPv4或IPv6前缀的长度。IPv4的有效值为0到32，IPv6的有效值为0到128。对于本AVP的特定使用环境，下文给出了更严格的限制。
Note that the IP-Prefix-Length AVP is only relevant when associated with an IP-Address AVP in a Grouped AVP.
注意，IP前缀长度AVP仅在与分组AVP中的IP地址AVP相关联时才相关。
Following on the precedent set by [RFC6334] and [RFC6519], this document identifies a border router using an FQDN rather than an address. The Border-Router-Name AVP (AVP Code 633) is of type OctetString. The FQDN encoding MUST follow the Name Syntax defined in [RFC1035], [RFC1123], and [RFC2181] and are represented in ASCII form. Note, if Internationalized Domain Names (IDNs) are used, A-labels defined in [RFC5891] must be used (see Appendix D of [RFC6733]).
根据[RFC6334]和[RFC6519]的先例，本文档使用FQDN而不是地址标识边界路由器。边界路由器名称AVP（AVP代码633）为OctetString类型。FQDN编码必须遵循[RFC1035]、[RFC1123]和[RFC2181]中定义的名称语法，并以ASCII格式表示。注意，如果使用国际化域名（IDN），则必须使用[RFC5891]中定义的A标签（见[RFC6733]的附录D）。
The 64-Multicast-Attributes AVP (AVP Code 634) is of type Grouped. It contains the multicast-related IPv6 prefixes needed for providing IPv4 multicast over IPv6 using DS-Lite, MAP-E, or lw4o6, as mentioned in Section 2.5.
64个多播属性AVP（AVP代码634）属于分组类型。它包含使用DS Lite、MAP-E或lw4o6在IPv6上提供IPv4多播所需的多播相关IPv6前缀，如第2.5节所述。
The syntax is shown in Figure 1.
语法如图1所示。
64-Multicast-Attributes ::= < AVP Header: 634 >
[ ASM-mPrefix64 ]
[ SSM-mPrefix64 ]
[ Delegated-IPv6-Prefix ]
*[ AVP ]
64-Multicast-Attributes ::= < AVP Header: 634 >
[ ASM-mPrefix64 ]
[ SSM-mPrefix64 ]
[ Delegated-IPv6-Prefix ]
*[ AVP ]
Figure 1: 64-Multicast-Attributes AVP
图1:64多播属性AVP
The 64-Multicast-Attributes AVP MUST include the ASM-mPrefix64 AVP or the SSM-mPrefix64 AVP, and it MAY include both.
64个多播属性AVP必须包括ASM-mPrefix64 AVP或SSM-mPrefix64 AVP，并且可能同时包括这两个属性。
The Delegated-IPv6-Prefix AVP MUST be present when the SSM-mPrefix64 AVP is present. The Delegated-IPv6-Prefix AVP MAY be present when the ASM-mPrefix64 AVP is present.
当SSM-mPrefix64 AVP存在时，必须存在委派的-IPv6-前缀AVP。当ASM-mPrefix64 AVP存在时，可能存在委派的IPv6前缀AVP。
The ASM-mPrefix64 AVP (AVP Code 635) conveys the value of ASM-mPrefix64 as mentioned in Section 2.5. The ASM-mPrefix64 AVP is of type Grouped, as shown in Figure 2.
ASM-mPrefix64 AVP（AVP代码635）传递第2.5节中提到的ASM-mPrefix64的值。ASM-mPrefix64 AVP属于分组型，如图2所示。
ASM-mPrefix64 ::= < AVP Header: 635 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
ASM-mPrefix64 ::= < AVP Header: 635 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 2: ASM-mPrefix64 AVP
图2:ASM-mPrefix64 AVP
IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the ASM-mPrefix64 AVP, it provides the value of an IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). The conveyed multicast IPv6 prefix MUST belong to the ASM range. Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IP地址（AVP代码518）在[RFC5777]中定义，属于地址类型。在ASM-mPrefix64 AVP中，它提供IPv6前缀的值。IP地址中的AddressType字段必须具有值2（IPv6）。传送的多播IPv6前缀必须属于ASM范围。IP地址中超出实际前缀的未使用位必须由发送方设置为零，并由接收方忽略。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. Within the ASM-mPrefix64 AVP, valid values of the IP-Prefix-Length AVP are from 24 to 96.
IP前缀长度AVP（AVP代码632）提供包含在IP地址AVP中的前缀的实际长度。在ASM-mPrefix64 AVP中，IP前缀长度AVP的有效值为24到96。
The SSM-mPrefix64 AVP (AVP Code 636) conveys the value of SSM-mPrefix64 as mentioned in Section 2.5. The SSM-mPrefix64 AVP is of type Grouped, as shown in Figure 3.
SSM-mPrefix64 AVP（AVP代码636）传递第2.5节中提到的SSM-mPrefix64的值。SSM-mPrefix64 AVP为分组型，如图3所示。
SSM-mPrefix64 ::= < AVP Header: 636 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
SSM-mPrefix64 ::= < AVP Header: 636 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 3: SSM-mPrefix64 AVP
图3:SSM-mPrefix64 AVP
IP-Address (AVP code 518) provides the value of an IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). The conveyed multicast IPv6 prefix MUST belong to the SSM range. Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IP地址（AVP代码518）提供IPv6前缀的值。IP地址中的AddressType字段必须具有值2（IPv6）。传送的多播IPv6前缀必须属于SSM范围。IP地址中超出实际前缀的未使用位必须由发送方设置为零，并由接收方忽略。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP.
IP前缀长度AVP（AVP代码632）提供包含在IP地址AVP中的前缀的实际长度。
Within the 64-Multicast-Attributes AVP, the Delegated-IPv6-Prefix AVP (AVP Code 123) conveys the value of uPrefix64, a unicast IPv6 prefix, as mentioned in Section 2.5. The Delegated-IPv6-Prefix AVP is defined in [RFC4818]. As specified by [RFC6052], the value in the Prefix-Length field MUST be one of 32, 48, 56, 64, or 96.
在64个多播属性AVP中，委托IPv6前缀AVP（AVP代码123）传递uPrefix64的值，uPrefix64是一个单播IPv6前缀，如第2.5节所述。[RFC4818]中定义了委派的IPv6前缀AVP。根据[RFC6052]的规定，前缀长度字段中的值必须是32、48、56、64或96中的一个。
The Tunnel-Source-Pref-Or-Addr AVP (AVP Code 637) conveys either the IPv6 Binding Prefix or the tunnel source address on the CPE, as described in Section 2.2. The Tunnel-Source-Pref-Or-Addr AVP is of type Grouped with syntax as shown in Figure 4. The Tunnel-Source-Pref-Or-Addr AVP MUST contain either the Delegated-IPv6-Prefix AVP or the Tunnel-Source-IPv6-Address AVP, not both.
隧道源Pref或Addr AVP（AVP代码637）在CPE上传送IPv6绑定前缀或隧道源地址，如第2.2节所述。隧道源Pref或Addr AVP是按语法分组的类型，如图4所示。隧道源Pref或Addr AVP必须包含委派的-IPv6-前缀AVP或隧道源-IPv6-地址AVP，而不能同时包含两者。
Tunnel-Source-Pref-Or-Addr ::= < AVP Header: 637 >
[ Delegated-IPv6-Prefix ]
[ Tunnel-Source-IPv6-Address ]
*[ AVP ]
Tunnel-Source-Pref-Or-Addr ::= < AVP Header: 637 >
[ Delegated-IPv6-Prefix ]
[ Tunnel-Source-IPv6-Address ]
*[ AVP ]
Figure 4: Tunnel-Source-Pref-Or-Addr AVP
图4：隧道源Pref或Addr AVP
This AVP is defined separately from the lw4o6-Binding AVP (which includes it) to provide flexibility in the transport of the tunnel source address from the provisioning system to AAA while also supporting the provision of a complete binding to the lw4o6 border router.
该AVP与lw4o6绑定AVP（包括它）分开定义，以提供将隧道源地址从供应系统传输到AAA的灵活性，同时还支持提供到lw4o6边界路由器的完整绑定。
The Delegated-IPv6-Prefix AVP (AVP code 123) is of type OctetString and is defined in [RFC4818]. Within the Tunnel-Source-Pref-Or-Addr AVP, it conveys the IPv6 Binding Prefix assigned to the CPE. Valid values in the Prefix-Length field are from 0 to 128 (full address).
委派的IPv6前缀AVP（AVP代码123）为OctetString类型，并在[RFC4818]中定义。在隧道源Pref或Addr AVP中，它传递分配给CPE的IPv6绑定前缀。前缀长度字段中的有效值为0到128（完整地址）。
The Tunnel-Source-IPv6-Address AVP (AVP code 638) is of type Address. It provides the address assigned by the CPE to identify its local end of an lw4o6 tunnel. The AddressType field in this AVP MUST be set to 2 (IPv6).
隧道源IPv6地址AVP（AVP代码638）为地址类型。它提供CPE分配的地址，以识别lw4o6隧道的本地端。此AVP中的AddressType字段必须设置为2（IPv6）。
The Port-Set-Identifier AVP (AVP Code 639) is a structured OctetString with four octets of data, hence a total AVP length of 12. The description of the structure that follows refers to the parameters described in Section 2.3 (see Figure 5).
端口集标识符AVP（AVP代码639）是具有四个八位字节数据的结构化八位字节字符串，因此AVP的总长度为12。以下结构描述参考第2.3节中描述的参数（见图5）。
o The first (high-order) octet is the Offset field. It is interpreted as an 8-bit unsigned integer giving the offset 'a' from the beginning of a port number to the beginning of the PSID to which that port belongs. Valid values are from 0 to 15.
o 第一个（高阶）八位组是偏移量字段。它被解释为8位无符号整数，给出从端口号开始到该端口所属PSID开始的偏移量“a”。有效值介于0到15之间。
o The next octet, the PSIDLength, is also interpreted as an 8-bit unsigned integer and gives the length 'k' in bits of the PSID. Valid values are from 0 to (16 - a). A value of 0 indicates that the PSID is not present (probable case for MAP-E, see Section 2.4), and the PSIDValue field MUST be ignored.
o 下一个八位字节PSIDLength也被解释为8位无符号整数，并以PSID的位为单位给出长度“k”。有效值介于0到（16-a）之间。值为0表示PSID不存在（MAP-E的可能情况，见第2.4节），必须忽略PSID值字段。
o The final two octets contain the PSIDValue field. They give the value of the PSID itself, right justified within the field. That is, the value of the PSID occupies the 'k' lowest-order bits of the PSIDValue field.
o 最后两个八位字节包含PSIDValue字段。它们给出了PSID本身的值，在字段内正确对齐。也就是说，PSID的值占据PSIDValue字段的“k”最低阶位。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Length | PSID Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Length | PSID Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Port Set
图5：端口集
The Lw4o6-Binding AVP (AVP Code 640) is of type Grouped. It contains the elements of configuration that constitute the binding between an lw4o6 tunnel and IPv4 packets sent through that tunnel, as described in Section 2.2.
Lw4o6绑定AVP（AVP代码640）属于分组类型。它包含构成lw4o6隧道和通过该隧道发送的IPv4数据包之间的绑定的配置元素，如第2.2节所述。
Lw4o6-Binding ::= < AVP Header: 640 >
{ Tunnel-Source-Pref-Or-Addr }
{ Lw4o6-External-IPv4-Addr }
[ Port-Set-Identifier ]
*[ AVP ]
Lw4o6-Binding ::= < AVP Header: 640 >
{ Tunnel-Source-Pref-Or-Addr }
{ Lw4o6-External-IPv4-Addr }
[ Port-Set-Identifier ]
*[ AVP ]
Figure 6: Lw4o6-Binding AVP
图6:Lw4o6绑定AVP
The Tunnel-Source-Pref-Or-Addr AVP is defined in Section 3.4 and provides either the Binding Prefix or the full IPv6 tunnel source address.
隧道源Pref或Addr AVP在第3.4节中定义，并提供绑定前缀或完整的IPv6隧道源地址。
The Lw4o6-External-IPv4-Addr AVP is defined in Section 3.6.1.
第3.6.1节定义了Lw4o6-External-IPv4-Addr AVP。
The Port-Set-Identifier AVP is defined in Section 3.5. It identifies the specific set of ports assigned to the lw4o6 tunnel when the IPv4 address is being shared.
第3.5节定义了端口集标识符AVP。它标识在共享IPv4地址时分配给lw4o6隧道的特定端口集。
The Lw4o6-External-IPv4-Addr AVP (AVP Code 641) uses the Address derived data format defined in Section 4.3.1 of [RFC6733]. It provides the CPE's external IPv4 address within the lw4o6 tunnel associated with the given binding. The AddressType field MUST be set to 1 (IPv4), and the total length of the AVP MUST be 14 octets.
Lw4o6-External-IPv4-Addr AVP（AVP代码641）使用[RFC6733]第4.3.1节中定义的地址派生数据格式。它在与给定绑定关联的lw4o6隧道内提供CPE的外部IPv4地址。AddressType字段必须设置为1（IPv4），AVP的总长度必须为14个八位字节。
The MAP-E-Attributes AVP (AVP Code 642) is of type Grouped. It contains the configuration data identified in Section 2.4 for all of the mapping rules (Basic and Forwarding) in a single MAP domain. Multiple instances of this AVP will be present if the CPE belongs to multiple MAP domains.
地图电子属性AVP（AVP代码642）属于分组类型。它包含第2.4节中为单个映射域中的所有映射规则（基本和转发）确定的配置数据。如果CPE属于多个MAP域，则将存在此AVP的多个实例。
MAP-E-Attributes ::= < AVP Header: 642 >
1*{ Border-Router-Name }
1*{ MAP-Mapping-Rule }
[ MAP-Mesh-Mode ]
[ Delegated-IPv6-Prefix ]
*[ AVP ]
MAP-E-Attributes ::= < AVP Header: 642 >
1*{ Border-Router-Name }
1*{ MAP-Mapping-Rule }
[ MAP-Mesh-Mode ]
[ Delegated-IPv6-Prefix ]
*[ AVP ]
Figure 7: MAP-E-Attributes AVP
图7：地图电子属性AVP
The Border-Router-Name AVP is defined in Section 3.2. It provides the FQDN of a MAP border relay at the edge of the MAP domain to which the containing MAP-E-Attributes AVP relates. At least one instance of this AVP MUST be present.
第3.2节定义了边界路由器名称AVP。它在包含MAP-E-Attributes AVP的映射域边缘提供映射边界中继的FQDN。此AVP必须至少存在一个实例。
The MAP-Mapping-Rule AVP is defined in Section 3.9. At least one instance of this AVP MUST be present. If the MAP-E domain supports Mesh mode (indicated by the presence of the MAP-Mesh-Mode AVP), additional MAP-Mapping-Rule instances MAY be present. If the MAP-E domain is operating in Hub-and-Spoke mode; additional MAP-Mapping-Rule instances MUST NOT be present.
第3.9节定义了地图映射规则AVP。此AVP必须至少存在一个实例。如果MAP-E域支持网格模式（通过存在MAP Mesh mode AVP指示），则可能存在其他MAP映射规则实例。如果MAP-E域以中心辐射模式运行；不能存在其他映射规则实例。
The MAP-Mesh-Mode AVP is defined in Section 3.8. The absence of the Mesh mode indicator attribute indicates that the CPE is required to operate in Hub-and-Spoke mode.
第3.8节定义了地图网格模式AVP。缺少网状模式指示器属性表示CPE需要在中心辐射模式下运行。
The Delegated-IPv6-Prefix AVP (AVP Code 123) provides the end-user IPv6 prefix assigned to the CPE for the MAP domain to which the containing MAP-E-Attributes AVP relates. The AVP is defined in [RFC4818]. Valid values of the Prefix-Length field range from 0 to 128.
Delegated-IPv6-Prefix AVP（AVP代码123）为包含MAP-E-Attributes AVP的映射域提供分配给CPE的最终用户IPv6前缀。AVP在[RFC4818]中定义。前缀长度字段的有效值范围为0到128。
The Delegated-IPv6-Prefix AVP is optional because, depending on deployment, the end-user IPv6 prefix may be provided by AAA or by other means. If multiple instances of the MAP-E-Attributes AVP containing the Delegated-IPv6-Prefix AVP are present, each instance of the latter MUST have a different value.
委派IPv6前缀AVP是可选的，因为根据部署情况，最终用户IPv6前缀可以由AAA或其他方式提供。如果存在多个包含委派IPv6前缀AVP的MAP-E-Attributes AVP实例，则后者的每个实例必须具有不同的值。
The MAP-Mesh-Mode AVP (AVP Code 643) is of type Enumerated and indicates whether the CPE has to operate in Mesh or Hub-and-Spoke mode when using MAP-E. The following values are supported:
MAP Mesh模式AVP（AVP代码643）属于枚举类型，指示CPE在使用MAP-E时是否必须在网状模式或轮辐模式下运行。支持以下值：
0 MESH
0目
1 HUB_AND_SPOKE
1个轮毂和辐条
The absence of the Mesh mode indicator attribute indicates that the CPE is required to operate in Hub-and-Spoke mode.
缺少网状模式指示器属性表示CPE需要在中心辐射模式下运行。
The MAP-Mapping-Rule AVP (AVP Code 644) is of type Grouped and is used only in conjunction with MAP-based transition methods. Mapping rules are required both by the MAP border relay and by the CPE. The components of the MAP-Mapping-Rule AVP provide the contents of a mapping rule as described in Section 2.4.
地图映射规则AVP（AVP代码644）属于分组类型，仅与基于地图的转换方法结合使用。映射规则是映射边界中继和CPE都需要的。地图映射规则AVP的组件提供了第2.4节所述的映射规则的内容。
The syntax of the MAP-Mapping-Rule AVP is as follows:
地图映射规则AVP的语法如下：
MAP-Mapping-Rule ::= < AVP Header: 644 >
{ Rule-IPv4-Addr-Or-Prefix }
{ Rule-IPv6-Prefix }
{ EA-Field-Length }
{ Port-Set-Identifier }
*[ AVP ]
MAP-Mapping-Rule ::= < AVP Header: 644 >
{ Rule-IPv4-Addr-Or-Prefix }
{ Rule-IPv6-Prefix }
{ EA-Field-Length }
{ Port-Set-Identifier }
*[ AVP ]
Figure 8: MAP-Mapping-Rule AVP
图8：地图映射规则AVP
The Rule-IPv4-Addr-Or-Prefix, Rule-IPv6-Prefix, EA-Field-Length, and Port-Set-Identifier AVPs MUST all be present.
规则-IPv4-Addr-Or-Prefix、规则-IPv6-Prefix、EA字段长度和端口集标识符AVP必须全部存在。
The Port-Set-Identifier AVP provides information to identify the specific set of ports assigned to the CPE. For more information, see Sections 2.4 and 2.3. The Port-Set-Identifier AVP is defined in Section 3.5.
端口集标识符AVP提供识别分配给CPE的特定端口集的信息。有关更多信息，请参见第2.4节和第2.3节。第3.5节定义了端口集标识符AVP。
The Rule-IPv4-Addr-Or-Prefix AVP (AVP Code 645) conveys the Rule IPv4 prefix and length as described in Section 2.4. The Rule-IPv4-Addr-Or-Prefix AVP is of type Grouped, as shown in Figure 9.
规则-IPv4-Addr-Or-Prefix AVP（AVP代码645）传递规则IPv4前缀和长度，如第2.4节所述。规则IPv4-Addr-Or-Prefix AVP属于分组类型，如图9所示。
Rule-IPv4-Addr-Or-Prefix ::= < AVP Header: 645 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Rule-IPv4-Addr-Or-Prefix ::= < AVP Header: 645 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 9: Rule-IPv4-Addr-Or-Prefix AVP
图9:Rule-IPv4-Addr-Or-Prefix AVP
IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the Rule-IPv4-Addr-Or-Prefix AVP, it provides the value of a unicast IPv4 address or prefix. The AddressType field in IP-Address MUST have value 1 (IPv4). Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IP地址（AVP代码518）在[RFC5777]中定义，属于地址类型。在Rule-IPv4-Addr-Or-Prefix AVP中，它提供单播IPv4地址或前缀的值。IP地址中的AddressType字段的值必须为1（IPv4）。IP地址中超出实际前缀的未使用位必须由发送方设置为零，并由接收方忽略。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. Within the Rule-IPv4- Addr-Or-Prefix AVP, valid values of the IP-Prefix-Length AVP are from 0 to 32 (full address) based on the different cases identified in Section 5.2 of [RFC7597].
IP前缀长度AVP（AVP代码632）提供包含在IP地址AVP中的前缀的实际长度。根据[RFC7597]第5.2节中确定的不同情况，在规则-IPv4-Addr或前缀AVP中，IP前缀长度AVP的有效值为0到32（完整地址）。
The Rule-IPv6-Prefix AVP (AVP Code 646) conveys the Rule IPv6 prefix and length as described in Section 2.4. The Rule-IPv6-Prefix AVP is of type Grouped, as shown in Figure 10.
规则-IPv6-前缀AVP（AVP代码646）传达第2.4节所述的规则IPv6前缀和长度。Rule-IPv6-Prefix AVP属于分组类型，如图10所示。
Rule-IPv6-Prefix ::= < AVP Header: 646 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Rule-IPv6-Prefix ::= < AVP Header: 646 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 10: Rule-IPv6-Prefix AVP
图10:Rule-IPv6-Prefix AVP
IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the Rule-IPv6-Prefix AVP, it provides the value of a unicast IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IP地址（AVP代码518）在[RFC5777]中定义，属于地址类型。在Rule-IPv6-Prefix AVP中，它提供了单播IPv6前缀的值。IP地址中的AddressType字段必须具有值2（IPv6）。IP地址中超出实际前缀的未使用位必须由发送方设置为零，并由接收方忽略。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. Within the Rule-IPv6-Prefix AVP, the minimum valid prefix length is 0. The maximum value is bounded by the length of the end-user IPv6 prefix associated with the mapping rule, if present in the form of the Delegated-IPv6-Prefix AVP in the enclosing MAP-E-Attributes AVP. Otherwise, the maximum value is 128.
IP前缀长度AVP（AVP代码632）提供包含在IP地址AVP中的前缀的实际长度。在Rule-IPv6-Prefix AVP中，最小有效前缀长度为0。最大值以与映射规则关联的最终用户IPv6前缀的长度为界，如果该前缀以委托IPv6前缀AVP的形式存在于随附的MAP-E-Attributes AVP中。否则，最大值为128。
The EA-Field-Length AVP (AVP Code 647) is of type Unsigned32. Valid values range from 0 to 48. See Section 5.2 of [RFC7597] for a description of the use of this parameter in deriving IPv4 address and port number configuration.
EA字段长度AVP（AVP代码647）的类型为Unsigned32。有效值的范围为0到48。有关在派生IPv4地址和端口号配置中使用此参数的说明，请参见[RFC7597]的第5.2节。
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+-------------------------------------------------------+----+----+
|IP-Prefix-Length 632 3.1 Unsigned32 | | V |
+-------------------------------------------------------+----+----+
|Border-Router-Name 633 3.2 OctetString | | V |
+-------------------------------------------------------+----+----+
|64-Multicast-Attributes 634 3.3 Grouped | | V |
+-------------------------------------------------------+----+----+
|ASM-mPrefix64 635 3.3.1 Grouped | | V |
+-------------------------------------------------------+----+----+
|SSM-mPrefix64 636 3.3.2 Grouped | | V |
+-------------------------------------------------------+----+----+
|Tunnel-Source-Pref-Or-Addr 637 3.4 Grouped | | V |
+-------------------------------------------------------+----+----+
|Tunnel-Source-IPv6-Address 638 3.4.2 Address | | V |
+-------------------------------------------------------+----+----+
|Port-Set-Identifier 639 3.5 OctetString | | V |
+-------------------------------------------------------+----+----+
|Lw4o6-Binding 640 3.6 Grouped | | V |
+-------------------------------------------------------+----+----+
|Lw4o6-External-IPv4-Addr 641 3.6.1 Address | | V |
+-------------------------------------------------------+----+----+
|MAP-E-Attributes 642 3.7 Grouped | | V |
+-------------------------------------------------------+----+----+
|MAP-Mesh-Mode 643 3.8 Enumerated | | V |
+-------------------------------------------------------+----+----+
|MAP-Mapping-Rule 644 3.9 Grouped | | V |
+-------------------------------------------------------+----+----+
|Rule-IPv4-Addr-Or-Prefix 645 3.9.1 Grouped | | V |
+-------------------------------------------------------+----+----+
|Rule-IPv6-Prefix 646 3.9.2 Grouped | | V |
+-------------------------------------------------------+----+----+
|EA-Field-Length 647 3.9.3 Unsigned32 | | V |
+-------------------------------------------------------+----+----+
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+-------------------------------------------------------+----+----+
|IP-Prefix-Length 632 3.1 Unsigned32 | | V |
+-------------------------------------------------------+----+----+
|Border-Router-Name 633 3.2 OctetString | | V |
+-------------------------------------------------------+----+----+
|64-Multicast-Attributes 634 3.3 Grouped | | V |
+-------------------------------------------------------+----+----+
|ASM-mPrefix64 635 3.3.1 Grouped | | V |
+-------------------------------------------------------+----+----+
|SSM-mPrefix64 636 3.3.2 Grouped | | V |
+-------------------------------------------------------+----+----+
|Tunnel-Source-Pref-Or-Addr 637 3.4 Grouped | | V |
+-------------------------------------------------------+----+----+
|Tunnel-Source-IPv6-Address 638 3.4.2 Address | | V |
+-------------------------------------------------------+----+----+
|Port-Set-Identifier 639 3.5 OctetString | | V |
+-------------------------------------------------------+----+----+
|Lw4o6-Binding 640 3.6 Grouped | | V |
+-------------------------------------------------------+----+----+
|Lw4o6-External-IPv4-Addr 641 3.6.1 Address | | V |
+-------------------------------------------------------+----+----+
|MAP-E-Attributes 642 3.7 Grouped | | V |
+-------------------------------------------------------+----+----+
|MAP-Mesh-Mode 643 3.8 Enumerated | | V |
+-------------------------------------------------------+----+----+
|MAP-Mapping-Rule 644 3.9 Grouped | | V |
+-------------------------------------------------------+----+----+
|Rule-IPv4-Addr-Or-Prefix 645 3.9.1 Grouped | | V |
+-------------------------------------------------------+----+----+
|Rule-IPv6-Prefix 646 3.9.2 Grouped | | V |
+-------------------------------------------------------+----+----+
|EA-Field-Length 647 3.9.3 Unsigned32 | | V |
+-------------------------------------------------------+----+----+
As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application.
如Diameter base protocol[RFC6733]中所述，给定命令中给定AVP的M位使用可由应用程序定义。
IANA has registered the following Diameter AVP codes in the "AVP Codes" registry:
IANA已在“AVP代码”注册表中注册了以下直径AVP代码：
+------+----------------------------+---------------+
| Code | Attribute Name | Reference |
+------+----------------------------+---------------+
| 632 | IP-Prefix-Length | This document |
| 633 | Border-Router-Name | This document |
| 634 | 64-Multicast-Attributes | This document |
| 635 | ASM-mPrefix64 | This document |
| 636 | SSM-mPrefix64 | This document |
| 637 | Tunnel-Source-Pref-Or-Addr | This document |
| 638 | Tunnel-Source-IPv6-Address | This document |
| 639 | Port-Set-Identifier | This document |
| 640 | Lw4o6-Binding | This document |
| 641 | Lw4o6-External-IPv4-Addr | This document |
| 642 | MAP-E-Attributes | This document |
| 643 | MAP-Mesh-Mode | This document |
| 644 | MAP-Mapping-Rule | This document |
| 645 | Rule-IPv4-Addr-Or-Prefix | This document |
| 646 | Rule-IPv6-Prefix | This document |
| 647 | EA-Field-Length | This document |
+------+----------------------------+---------------+
+------+----------------------------+---------------+
| Code | Attribute Name | Reference |
+------+----------------------------+---------------+
| 632 | IP-Prefix-Length | This document |
| 633 | Border-Router-Name | This document |
| 634 | 64-Multicast-Attributes | This document |
| 635 | ASM-mPrefix64 | This document |
| 636 | SSM-mPrefix64 | This document |
| 637 | Tunnel-Source-Pref-Or-Addr | This document |
| 638 | Tunnel-Source-IPv6-Address | This document |
| 639 | Port-Set-Identifier | This document |
| 640 | Lw4o6-Binding | This document |
| 641 | Lw4o6-External-IPv4-Addr | This document |
| 642 | MAP-E-Attributes | This document |
| 643 | MAP-Mesh-Mode | This document |
| 644 | MAP-Mapping-Rule | This document |
| 645 | Rule-IPv4-Addr-Or-Prefix | This document |
| 646 | Rule-IPv6-Prefix | This document |
| 647 | EA-Field-Length | This document |
+------+----------------------------+---------------+
Table 1: Diameter AVP Codes
表1：直径AVP代码
The AVPs defined in this document face two threats, both dependent on man-in-the-middle (MITM) attacks on the Diameter delivery path.
本文档中定义的AVP面临两种威胁，都依赖于Diameter交付路径上的中间人（MITM）攻击。
The first threat is denial-of-service (DoS) through modification of the AVP contents leading to misconfiguration; e.g., a subscriber may fail to access its connectivity service if an invalid IP address was configured, the subscriber's traffic can be intercepted by a misbehaving node if a fake Border Node has been configured, etc.
第一个威胁是拒绝服务（DoS），通过修改AVP内容导致错误配置；e、 例如，如果配置了无效的IP地址，订阅者可能无法访问其连接服务；如果配置了假边界节点，行为不正常的节点可能会拦截订阅者的流量，等等。
The second threat is that Diameter security is currently provided on a hop-by-hop basis (see Section 2.2 of [RFC6733]). At the time of writing, the Diameter end-to-end security problem has not been solved, so MITM attacks by Diameter peers along the path are possible. Diameter-related security considerations are discussed in Section 13 of [RFC6733].
第二个威胁是Diameter安全性目前是逐跳提供的（见[RFC6733]第2.2节）。在撰写本文时，Diameter端到端的安全问题尚未解决，因此Diameter节点沿路径进行MITM攻击是可能的。[RFC6733]第13节讨论了直径相关的安全注意事项。
Given that the AVPs defined in this document reveal privacy-related information (e.g., subscriber addresses) that can be used for tracking proposes, all these AVPs are considered to be security sensitive. Therefore, the considerations discussed in Section 13.3 of [RFC6733] MUST be followed for Diameter messages containing these AVPs.
鉴于本文件中定义的AVP揭示了可用于跟踪提议的隐私相关信息（如订户地址），所有这些AVP均被视为安全敏感型。因此，对于包含这些AVP的DIAMER消息，必须遵循[RFC6733]第13.3节中讨论的注意事项。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<http://www.rfc-editor.org/info/rfc1123>.
[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>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，DOI 10.17487/RFC2181，1997年7月<http://www.rfc-editor.org/info/rfc2181>.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, DOI 10.17487/RFC4818, April 2007, <http://www.rfc-editor.org/info/rfc4818>.
[RFC4818]Salowey，J.和R.Droms，“RADIUS-IPv6-Prefix属性”，RFC 4818，DOI 10.17487/RFC4818，2007年4月<http://www.rfc-editor.org/info/rfc4818>.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, <http://www.rfc-editor.org/info/rfc5777>.
[RFC5777]Korhonen，J.，Tschofenig，H.，Arumaithurai，M.，Jones，M.，Ed.，和A.Lior，“直径的流量分类和服务质量（QoS）属性”，RFC 5777，DOI 10.17487/RFC5777，2010年2月<http://www.rfc-editor.org/info/rfc5777>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<http://www.rfc-editor.org/info/rfc5891>.
[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>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<http://www.rfc-editor.org/info/rfc6733>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7596]Cui，Y.，Sun，Q.，Boucadair，M.，Tsou，T.，Lee，Y.，和I.Farrer，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年7月<http://www.rfc-editor.org/info/rfc7596>.
[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>.
[DSLITE-MULTICAST] Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network", Work in Progress, draft-ietf-softwire-dslite-multicast-10, August 2015.
[DSLITE-MULTICAST]秦，J.，Boucadair，M.，Jacquenet，C.，Lee，Y.，和Q.Wang，“通过IPv6多播网络向IPv4客户端提供IPv4多播服务”，正在进行的工作，草稿-ietf-softwire-DSLITE-MULTICAST-10，2015年8月。
[PREFIX-OPTION] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", Work in Progress, draft-ietf-softwire-multicast-prefix-option-09, August 2015.
[PREFIX-OPTION]Boucadair，M.，Qin，J.，Tsou，T.，和X.Deng，“IPv4嵌入式多播和单播IPv6前缀的DHCPv6选项”，正在进行的工作，草稿-ietf-softwire-Multicast-PREFIX-OPTION-092015年8月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC 4607，DOI 10.17487/RFC4607，2006年8月<http://www.rfc-editor.org/info/rfc4607>.
[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>.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, DOI 10.17487/RFC6334, August 2011, <http://www.rfc-editor.org/info/rfc6334>.
[RFC6334]Hankins，D.和T.Mrugalski，“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”，RFC 6334，DOI 10.17487/RFC6334，2011年8月<http://www.rfc-editor.org/info/rfc6334>.
[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February 2012, <http://www.rfc-editor.org/info/rfc6519>.
[RFC6519]Maglione，R.和A.Durand，“双堆栈Lite的半径扩展”，RFC 6519，DOI 10.17487/RFC6519，2012年2月<http://www.rfc-editor.org/info/rfc6519>.
[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>.
Acknowledgements
致谢
Huawei Technologies funded Tom Taylor's work on earlier draft versions of this document.
华为技术公司资助汤姆·泰勒（Tom Taylor）编写本文件的早期草稿。
Special thanks to Lionel Morand for the detailed review.
特别感谢莱昂内尔·莫兰德的详细评论。
Many thanks to Russ Housley, Tim Chown, Spencer Dawkins, and Ben Campbell for the review and comments.
非常感谢Russ Housley、Tim Chown、Spencer Dawkins和Ben Campbell的评论和评论。
Authors' Addresses
作者地址
Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 China
中国深圳市龙岗区华为技术有限公司坂田区周凯茜518129
Email: cathy.zhou@huawei.com
Email: cathy.zhou@huawei.com
Tom Taylor PT Taylor Consulting Ottawa Canada
汤姆泰勒加拿大渥太华咨询公司
Email: tom.taylor.stds@gmail.com
Email: tom.taylor.stds@gmail.com
Qiong Sun China Telecom China
琼孙中国电信
Phone: 86 10 58552936 Email: sunqiong@ctbri.com.cn
电话：86 10 58552936电子邮件：sunqiong@ctbri.com.cn
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com