Internet Engineering Task Force (IETF) A. Ripke
Request for Comments: 7843 R. Winter
Updates: 6887 T. Dietz
Category: Standards Track J. Quittek
ISSN: 2070-1721 NEC
R. da Silva
Telefonica I+D
May 2016
Internet Engineering Task Force (IETF) A. Ripke
Request for Comments: 7843 R. Winter
Updates: 6887 T. Dietz
Category: Standards Track J. Quittek
ISSN: 2070-1721 NEC
R. da Silva
Telefonica I+D
May 2016
Port Control Protocol (PCP) Third-Party ID Option
端口控制协议（PCP）第三方ID选项
Abstract
摘要
This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.
本文档描述了一个新的端口控制协议（PCP）选项，称为第三方ID选项。其设计与RFC 6887中规定的第三方选项一起使用。
The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.
第三方ID选项用于在第三方选项中包含的第三方IP地址未提供足够信息以在PCP控制的设备中创建请求的映射的情况下识别第三方。
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/rfc7843.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7843.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Target Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Carrier-Hosted UPnP IGD-PCP IWF . . . . . . . . . . . . . 6
3.2. Carrier Web Portal . . . . . . . . . . . . . . . . . . . 7
4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Result Codes . . . . . . . . . . . . . . . . . . . . . . 10
5. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Generating a Request . . . . . . . . . . . . . . . . . . 10
5.2. Processing a Request . . . . . . . . . . . . . . . . . . 11
5.3. Processing a Response . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Target Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Carrier-Hosted UPnP IGD-PCP IWF . . . . . . . . . . . . . 6
3.2. Carrier Web Portal . . . . . . . . . . . . . . . . . . . 7
4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Result Codes . . . . . . . . . . . . . . . . . . . . . . 10
5. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Generating a Request . . . . . . . . . . . . . . . . . . 10
5.2. Processing a Request . . . . . . . . . . . . . . . . . . 11
5.3. Processing a Response . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
The IETF has specified the Port Control Protocol (PCP) [RFC6887] to control how packets are translated and/or forwarded by a PCP-controlled device such as a Network Address Translator (NAT) or a firewall.
IETF已指定端口控制协议（PCP）[RFC6887]来控制由PCP控制的设备（如网络地址转换器（NAT）或防火墙）如何翻译和/或转发数据包。
This document focuses on scenarios where the PCP client sends requests that concern internal addresses other than the address of the PCP client itself.
本文档重点介绍PCP客户端发送与内部地址有关的请求（而非PCP客户端本身的地址）的场景。
There is already an option defined for this purpose in [RFC6887] called the THIRD_PARTY option. The THIRD_PARTY option carries the IP address of a host for which a PCP client requests an action at the PCP server. For example, the THIRD_PARTY option can be used if port mapping requests for a Carrier-Grade NAT (CGN) are not sent from PCP clients at subscriber terminals but instead from a PCP Interworking Function (IWF), which requests port mappings.
[RFC6887]中已经为此定义了一个选项，称为第三方选项。第三方选项包含PCP客户端在PCP服务器上请求操作的主机的IP地址。例如，如果载波级NAT（CGN）的端口映射请求不是从用户终端的PCP客户端发送的，而是从请求端口映射的PCP互通功能（IWF）发送的，则可以使用第三方选项。
In some cases, the THIRD_PARTY option alone is not sufficient and further means are needed for identifying the third party. Such cases are addressed by the THIRD_PARTY_ID option, which is specified in this document.
在某些情况下，仅凭第三方选择是不够的，需要进一步的手段来识别第三方。此类情况由本文件中指定的第三方ID选项解决。
The primary issue addressed by the THIRD_PARTY_ID option is that there are CGN deployments that do not distinguish internal hosts by their IP address alone, but use further identifiers (IDs) for unique subscriber identification. For example, this is the case if a CGN supports overlapping private or shared IP address spaces [RFC1918] [RFC6598] for internal hosts of different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and/or another ID, for example, the ID of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address contained in the THIRD_PARTY option is not sufficient to demultiplex connections from internal hosts. An additional identifier needs to be present in the PCP message in order to uniquely identify an internal host. The THIRD_PARTY_ID option is used to carry this ID.
第三方ID选项解决的主要问题是，有一些CGN部署不单独通过IP地址区分内部主机，而是使用其他标识符（ID）进行唯一订户标识。例如，如果CGN为不同订阅者的内部主机支持重叠的私有或共享IP地址空间[RFC1918][RFC6598]，则会出现这种情况。在这种情况下，不同的内部主机通过其IP地址和/或另一ID（例如，CGN和订户之间的隧道的ID）在CGN处被识别和映射。在这些场景（以及类似场景）中，第三方选项中包含的内部IP地址不足以从内部主机解复用连接。PCP消息中需要有一个附加标识符，以便唯一标识内部主机。第三方ID选项用于携带此ID。
This applies to some of the PCP deployment scenarios that are listed in Section 2.1 of [RFC6887], in particular to a L2-aware NAT, which is described in more detail in Section 3, as well as in other scenarios where overlapping address spaces occur like in [RFC6674] or [RFC6619].
这适用于[RFC6887]第2.1节中列出的一些PCP部署场景，特别是第3节中更详细描述的L2感知NAT，以及[RFC6674]或[RFC6619]中出现重叠地址空间的其他场景。
The THIRD_PARTY_ID option is defined for the PCP opcodes MAP and PEER to be used together with the THIRD_PARTY option, which is specified in [RFC6887].
第三方ID选项是为PCP操作码映射和对等机定义的，与第三方选项一起使用，该选项在[RFC6887]中指定。
The terminology defined in the specification of PCP [RFC6887] applies.
PCP规范[RFC6887]中定义的术语适用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
This section describes two scenarios that illustrate the use of the THIRD_PARTY_ID option:
本节描述了两个说明第三方ID选项使用的场景：
1. A UPnP IGD-PCP IWF (Universal Plug and Play Internet Gateway Device - Port Control Protocol Interworking Function [RFC6970]).
1. UPnP IGD-PCP IWF（通用即插即用互联网网关设备-端口控制协议互通功能[RFC6970]）。
2. A carrier web portal for port mapping.
2. 用于端口映射的运营商web门户。
These are just two examples that illustrate the use and applicability of the THIRD_PARTY_ID option. While these are just two examples, there might be other conceivable use cases. However, the use of the THIRD_PARTY_ID option as specified in this document is restricted to scenarios where the option is needed for the purpose of uniquely identifying an internal host in addition to the information found in the THIRD_PARTY option.
这两个例子说明了第三方ID选项的使用和适用性。虽然这只是两个例子，但可能还有其他可以想象的用例。但是，本文档中指定的第三方ID选项的使用仅限于需要该选项以唯一标识内部主机以及第三方选项中的信息的情况。
Both scenarios elaborated in this document are refinements of the same basic scenario shown in Figure 1 that is considered as a PCP deployment scenario employing L2-aware NATs as listed in Section 2.1 of [RFC6887]. It has a carrier operating a CGN and a Port Control Protocol Interworking Function (PCP IWF) [RFC6970] for subscribers to request port mappings at the CGN. The PCP IWF communicates with the CGN using PCP. For this purpose, the PCP IWF contains a PCP client serving multiple subscribers and the CGN is co-located with a PCP server. The way subscribers interact with the PCP IWF for requesting port mappings for their internal hosts is not specified in this basic scenario, but it is elaborated on more in the specific scenarios in Sections 3.1 and 3.2.
本文档中阐述的两种场景都是对图1中所示的相同基本场景的改进，该场景被视为使用L2感知NAT的PCP部署场景，如[RFC6887]第2.1节所列。它有一个运营商操作CGN和一个端口控制协议互通功能（PCP IWF）[RFC6970]，供用户在CGN请求端口映射。PCP IWF使用PCP与CGN通信。为此，PCP IWF包含一个服务于多个订阅者的PCP客户端，并且CGN与PCP服务器位于同一位置。订阅者与PCP IWF交互以请求其内部主机的端口映射的方式在本基本场景中没有指定，但在第3.1节和第3.2节的特定场景中有详细说明。
The CGN operates as a L2-aware NAT. Unlike a standard NAT, it includes a subscriber identifier in addition to the source IP address in entries of the NAT mapping table.
CGN作为L2感知NAT运行。与标准NAT不同，它在NAT映射表的条目中除了源IP地址之外还包括订户标识符。
+--------------+ +------------------+
| Subscriber | | Carrier | ==== L2 connection(s)
| | | +--------------+ | between subscriber
| +......+ PCP | | and CGN
| +----------+ | | | Interworking | | #### PCP communication
| | Internal | | | | Function | | .... Subscriber-IWF
| | Host | | | +-----#--------+ | interaction
| +----+-----+ | | # | (elaborated
| | | | +-----#--------+ | in specific
| +----+-----+ | | | PCP Server | | scenarios below)
| | CPE | | | | | |
| | +-+======+ CGN L2NAT +--------- Public Internet
| +----------+ | | +--------------+ |
+--------------+ +------------------+
+--------------+ +------------------+
| Subscriber | | Carrier | ==== L2 connection(s)
| | | +--------------+ | between subscriber
| +......+ PCP | | and CGN
| +----------+ | | | Interworking | | #### PCP communication
| | Internal | | | | Function | | .... Subscriber-IWF
| | Host | | | +-----#--------+ | interaction
| +----+-----+ | | # | (elaborated
| | | | +-----#--------+ | in specific
| +----+-----+ | | | PCP Server | | scenarios below)
| | CPE | | | | | |
| | +-+======+ CGN L2NAT +--------- Public Internet
| +----------+ | | +--------------+ |
+--------------+ +------------------+
Figure 1: Carrier Hosted PCP IWF for Port Mapping Requests
图1：用于端口映射请求的运营商托管PCP IWF
Internal hosts in the subscriber's network use private IP addresses [RFC1918]. There is no NAT between the internal host and the CGN, and there is an overlap of addresses used by internal hosts of different subscribers. That is why the CGN needs more than just the internal host's IP address to distinguish internal hosts of different subscribers. A commonly deployed method for solving this issue is using an additional identifier for this purpose. A natural candidate for this additional identifier at the CGN is the ID of the tunnel that connects the CGN to the subscriber's network. The subscriber's Customer Premises Equipment (CPE) operates as a Layer 2 bridge.
用户网络中的内部主机使用专用IP地址[RFC1918]。内部主机和CGN之间没有NAT，不同订户的内部主机使用的地址有重叠。这就是为什么CGN不仅仅需要内部主机的IP地址来区分不同订户的内部主机。解决此问题的常用部署方法是为此目的使用附加标识符。CGN处此附加标识符的自然候选是连接CGN到订户网络的隧道的ID。用户的客户场所设备（CPE）作为第2层网桥运行。
Requests for port mappings from the PCP IWF to the CGN need to uniquely identify the internal host for which a port mapping is to be established or modified. Already existing for this purpose is the THIRD_PARTY option that can be used to specify the internal host's IP address. The THIRD_PARTY_ID option is introduced for carrying the additional third-party information needed to identify the internal host in this scenario.
从PCP IWF到CGN的端口映射请求需要唯一标识要为其建立或修改端口映射的内部主机。已经存在用于此目的的第三方选项，可用于指定内部主机的IP地址。引入第三方ID选项是为了在这种情况下携带识别内部主机所需的附加第三方信息。
The additional identifier for internal hosts needs to be included in MAP requests from the PCP IWF in order to uniquely identify the internal host that should have its address mapped. This is the purpose that the new THIRD_PARTY_ID option serves in this scenario. It carries the additional identifier, that is the tunnel ID, that serves for identifying an internal host in combination with the internal host's (private) IP address. The IP address of the internal host is included in the PCP IWF's mapping requests by using the THIRD_PARTY option.
内部主机的附加标识符需要包含在来自PCP IWF的映射请求中，以便唯一标识应该映射其地址的内部主机。这就是新的第三方ID选项在此场景中的用途。它携带附加标识符，即隧道ID，用于结合内部主机的（专用）IP地址识别内部主机。内部主机的IP地址通过使用第三方选项包含在PCP IWF的映射请求中。
The information carried by the THIRD_PARTY_ID option is not just needed to identify an internal host in a PCP request. The CGN needs this information in its internal mapping tables for translating packet addresses and for forwarding packets to subscriber-specific tunnels.
第三方ID选项携带的信息不仅仅用于在PCP请求中识别内部主机。CGN在其内部映射表中需要此信息，以便转换数据包地址和将数据包转发到特定于订户的隧道。
How the carrier PCP IWF is managing port mappings, such as, for example, automatically extending the lifetime of a mapping, is beyond the scope of this document.
运营商PCP IWF如何管理端口映射（例如，自动延长映射的生存期）超出了本文档的范围。
This scenario further elaborates the basic one above by choosing UPnP-IGD as the communication protocol between the subscriber and the carrier's PCP IWF. Then obviously, the PCP IWF is realized as a UPnP IGD-PCP IWF as specified in [RFC6970].
该场景通过选择UPnP IGD作为用户和运营商的PCP IWF之间的通信协议，进一步阐述了上述基本场景。显然，PCP IWF是按照[RFC6970]中的规定实现为UPnP IGD-PCP IWF的。
As shown in Figure 2, it is assumed here that the UPnP IGD-PCP IWF is not embedded in the subscriber premises router, but offered as a service to the subscriber. Further, it is assumed that the UPnP IGD-PCP IWF is not providing NAT functionality.
如图2所示，此处假设UPnP IGD-PCP IWF未嵌入用户房屋路由器中，而是作为服务提供给用户。此外，假设UPnP IGD-PCP IWF不提供NAT功能。
This requires that the subscriber can connect to the UPnP IGD-PCP IWF to request port mappings at the CGN using UPnP-IGD as specified in [RFC6970]. In this scenario, the connection is provided via (one of the) tunnel(s) connecting the subscriber's network to the Broadband Remote Access Server (BRAS) and an extension of this tunnel from the BRAS to the UPnP IGD-PCP IWF. Note that there are other alternatives that can be used for providing the connection to the UPnP IGD-PCP IWF. The tunnel extension used in this scenario can, for example, be realized by a forwarding function for UPnP messages at the BRAS that forwards such messages through per-subscriber tunnels to the UPnP IGD-PCP IWF. Depending on an actual implementation, the UPnP IGD-PCP IWF can then either use the ID of the tunnel in which the UPnP message arrived directly as the THIRD_PARTY_ID option for PCP requests to the CGN, or it uses the ID of the tunnel to retrieve the THIRD_PARTY_ID option from the Authentication, Authorization, and Accounting (AAA) server.
这要求订户可以连接到UPnP IGD-PCP IWF，以使用[RFC6970]中规定的UPnP IGD在CGN上请求端口映射。在这种情况下，连接通过（其中一个）隧道提供，该隧道将用户网络连接到宽带远程访问服务器（BRAS），并将该隧道从BRAS扩展到UPnP IGD-PCP IWF。请注意，还有其他替代方案可用于提供与UPnP IGD-PCP IWF的连接。例如，该场景中使用的隧道扩展可以通过BRA处的UPnP消息转发功能来实现，该功能通过每个订户隧道将此类消息转发到UPnP IGD-PCP IWF。根据实际实现，UPnP IGD-PCP IWF然后可以使用UPnP消息直接到达的隧道ID作为PCP向CGN请求的第三方ID选项，或者使用隧道ID从认证、授权和计费（AAA）服务器检索第三方ID选项。
To support the latter option, the BRAS needs to register the subscriber's tunnel IDs at the AAA server at the time it contacts the AAA server for authentication and/or authorization of the subscriber. The tunnel IDs to be registered per subscriber at the AAA server may include the tunnel between CPE and BRAS, between BRAS and UPnP IGD-PCP IWF, and between BRAS and CGN. The UPnP IGD-PCP IWF queries the AAA server for the ID of the tunnel between BRAS and CGN, because this is the identifier to be used as the THIRD_PARTY_ID option in the subsequent port mapping request.
为了支持后一个选项，BRAS需要在联系AAA服务器以进行订阅者身份验证和/或授权时，在AAA服务器上注册订阅者的隧道ID。要在AAA服务器上为每个订户注册的隧道ID可以包括CPE和BRA之间、BRA和UPnP IGD-PCP IWF之间以及BRA和CGN之间的隧道。UPnP IGD-PCP IWF向AAA服务器查询BRAS和CGN之间的隧道ID，因为这是在后续端口映射请求中用作第三方ID选项的标识符。
+--------------+ +------------------------------------+
| Subscriber | | Carrier |
| | | +----------------------------+ |
| | | | AAA Server | |
| | | +-----+---------------+------+ |
| | | | | |
| +----------+ | | +-----+---+ +-----+------+ |
| | Internal | | | | +=====+ | |
| | Host | | | | ...........| UPnP IGD | |
| +----+-----+ | | | . +=====+ PCP IWF | |
| | . | | | . | +-----#------+ |
| +----+--.--| | | | . | # |
| | | . +========+ . | +-----#------+ |
| | | .................. +=====+ PCP Server | |
| | +------------------------------| | |
| | CPE +========+ BRAS +=====+ CGN L2NAT +------- Public
| +----------+ | | +---------+ +------------+ | Internet
+--------------+ +------------------------------------+
+--------------+ +------------------------------------+
| Subscriber | | Carrier |
| | | +----------------------------+ |
| | | | AAA Server | |
| | | +-----+---------------+------+ |
| | | | | |
| +----------+ | | +-----+---+ +-----+------+ |
| | Internal | | | | +=====+ | |
| | Host | | | | ...........| UPnP IGD | |
| +----+-----+ | | | . +=====+ PCP IWF | |
| | . | | | . | +-----#------+ |
| +----+--.--| | | | . | # |
| | | . +========+ . | +-----#------+ |
| | | .................. +=====+ PCP Server | |
| | +------------------------------| | |
| | CPE +========+ BRAS +=====+ CGN L2NAT +------- Public
| +----------+ | | +---------+ +------------+ | Internet
+--------------+ +------------------------------------+
==== L2 tunnel borders between subscriber, BRAS, IWF, and CGN
.... UPnP communication
#### PCP communication
==== L2 tunnel borders between subscriber, BRAS, IWF, and CGN
.... UPnP communication
#### PCP communication
Figure 2: UPnP IGD-PCP IWF
图2:UPnP IGD-PCP IWF
A potential extension to [RFC6970] regarding an additional state variable for the THIRD_PARTY_ID option and regarding an additional error code for a mismatched THIRD_PARTY_ID option and its processing might be a logical next step. However, this is not in the scope of this document.
[RFC6970]的潜在扩展涉及第三方ID选项的附加状态变量，以及不匹配的第三方ID选项的附加错误代码及其处理，这可能是合乎逻辑的下一步。但是，这不在本文件的范围内。
This scenario shown in Figure 3 is different from the previous one concerning the protocol used between the subscriber and the IWF. Here, HTTP(S) is the protocol that the subscriber uses for port mapping requests. The subscriber may make requests manually using a web browser or automatically -- as in the previous scenario -- with applications in the subscriber's network issuing port mapping requests on demand. The web portal queries the AAA server for the subscriber's ID of the tunnel (BRAS to CGN) that was reported by the BRAS. The returned ID of the tunnel (BRAS to CGN) is used as the THIRD_PARTY_ID option in the subsequent port mapping request.
图3所示的场景与前一个场景不同，后者涉及订阅者和IWF之间使用的协议。这里，HTTP（S）是订户用于端口映射请求的协议。订户可以使用web浏览器手动发出请求，也可以像前面的场景一样，通过订户网络中的应用程序按需发出端口映射请求自动发出请求。门户网站向AAA服务器查询BRAS报告的隧道（BRAS到CGN）的订户ID。返回的隧道ID（BRAS到CGN）在后续端口映射请求中用作第三方ID选项。
+--------------+ +------------------------------------+
| Subscriber | | Carrier |
| | | +------------+ |
| | | +------------+ | Web Portal | |
| +----------+ | | | AAA Server +--+ +--+ |
| | Internal | | | +-----+------+ | PCP Client | | |
| | Host | | | | +-----#------+ | |
| +----+-----+ | | | # | |
| | | | +-----+---+ +-----#------+ | |
| +----+-----+ | | | | | PCP Server | | |
| | CPE | | | | BRAS | | | | |
| | +-+======+ +=====+ CGN L2NAT +--+---- Public
| +----------+ | | +---------+ +------------+ | Internet
+--------------+ +------------------------------------+
+--------------+ +------------------------------------+
| Subscriber | | Carrier |
| | | +------------+ |
| | | +------------+ | Web Portal | |
| +----------+ | | | AAA Server +--+ +--+ |
| | Internal | | | +-----+------+ | PCP Client | | |
| | Host | | | | +-----#------+ | |
| +----+-----+ | | | # | |
| | | | +-----+---+ +-----#------+ | |
| +----+-----+ | | | | | PCP Server | | |
| | CPE | | | | BRAS | | | | |
| | +-+======+ +=====+ CGN L2NAT +--+---- Public
| +----------+ | | +---------+ +------------+ | Internet
+--------------+ +------------------------------------+
==== L2 tunnel(s) between subscriber, BRAS, and CGN
#### PCP communication
==== L2 tunnel(s) between subscriber, BRAS, and CGN
#### PCP communication
Figure 3: Carrier Web Portal
图3：运营商门户网站
The PCP IWF is realized as a combination of a web server and a PCP client.
PCP IWF实现为web服务器和PCP客户端的组合。
The THIRD_PARTY_ID option as shown in Figure 4 uses the format of PCP options as specified in [RFC6887]:
图4所示的第三方ID选项使用[RFC6887]中指定的PCP选项格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Code=13 | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| THIRD_PARTY_ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Code=13 | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| THIRD_PARTY_ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Name: THIRD_PARTY_ID Option Code: 13 Purpose: Together with the THIRD_PARTY option, the THIRD_PARTY_ID option identifies a third party for which a request for an external IP address and port is made. Valid for Opcodes: MAP, PEER Length: Variable; maximum 1016 octets. May appear in: Request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1
选项名称：第三方ID选项代码：13目的：与第三方选项一起，第三方ID选项标识请求外部IP地址和端口的第三方。对操作码有效：映射，对等长度：变量；最多1016个八位组。可能出现在：请求。仅当它出现在相关请求中时，才可能出现在响应中。最多发生次数：1次
Figure 4: THIRD_PARTY_ID Option
图4：第三方ID选项
The "Reserved" field and the "Option length" field are to be set as specified in Section 7.3 of [RFC6887].
“保留”字段和“选项长度”字段应按照[RFC6887]第7.3节的规定进行设置。
The "THIRD_PARTY_ID" field contains a deployment-specific identifier that identifies a realm of a NAT map entry. Together with a THIRD_PARTY option it can be used to identify a subscriber's session on a PCP-controlled device. It has no other semantics.
“第三方ID”字段包含一个特定于部署的标识符，用于标识NAT映射项的域。它与第三方选项一起可用于识别PCP控制设备上的订户会话。它没有其他语义。
The "THIRD_PARTY_ID" is not bound to any specific identifier. It can contain any deployment-specific value that the PCP client and the PCP server agree on. How this agreement is reached if both PCP server and client are not administered by the same entity is beyond the scope of this document. Also, the client does not need to have an understanding of how the ID is being used at the PCP server.
“第三方ID”未绑定到任何特定标识符。它可以包含PCP客户端和PCP服务器约定的任何部署特定值。如果PCP服务器和客户端不是由同一实体管理，则如何达成此协议超出了本文档的范围。此外，客户端不需要了解PCP服务器上如何使用ID。
If an identifier is used that is based on an existing standard, then the encoding rules of that standard must be followed. As an example, in case a session ID of the Layer 2 Tunneling Protocol version 3
如果使用基于现有标准的标识符，则必须遵循该标准的编码规则。例如，如果第2层隧道协议版本3的会话ID
(L2TPv3) [RFC3931] is being used, then that identifier has to be encoded the same way it would be encoded in the L2TPv3 session header. This allows for a simple octet-by-octet comparison at the PCP-controlled device.
（L2TPv3）[RFC3931]正在使用中，则该标识符的编码方式必须与L2TPv3会话头中的编码方式相同。这允许在PCP控制设备上进行简单的八位字节比较。
[RFC6887] expects option data to always come in multiples of an octet. An ID, however, might not fulfill this criterion. As an example, an MPLS label is 20 bits wide. In these cases, padding is done by appending 0 bits until the byte boundary is reached. After that, the padding rules of [RFC6887] apply.
[RFC6887]期望选项数据总是以八位字节的倍数出现。但是，ID可能不符合此标准。例如，MPLS标签的宽度为20位。在这些情况下，填充是通过追加0位来完成的，直到达到字节边界为止。之后，应用[RFC6887]的填充规则。
The option number is in the mandatory-to-process range (0-127), meaning that a request with a THIRD_PARTY_ID option is processed by the PCP server if and only if the THIRD_PARTY_ID option is supported by the PCP server. Therefore, it should not be included unless the PCP client is certain that a mapping without the THIRD_PARTY_ID is impossible.
选项编号在强制处理范围（0-127）内，这意味着当且仅当PCP服务器支持第三方ID选项时，PCP服务器才会处理具有第三方ID选项的请求。因此，除非PCP客户端确定不可能进行没有第三方ID的映射，否则不应包括该映射。
The following PCP Result Codes are new:
以下PCP结果代码为新代码：
24: THIRD_PARTY_ID_UNKNOWN: The provided identifier in a THIRD_PARTY_ID option is unknown/unavailable to the PCP server. This is a long lifetime error.
24：第三方ID未知：第三方ID选项中提供的标识符对PCP服务器未知/不可用。这是一个长期的错误。
25: THIRD_PARTY_MISSING_OPTION: This error occurs if both THIRD_PARTY and THIRD_PARTY_ID options are expected in a request but one option is missing. This is a long lifetime error.
25：第三方缺少选项：如果请求中同时需要第三方和第三方ID选项，但缺少一个选项，则会发生此错误。这是一个长期的错误。
26: UNSUPP_THIRD_PARTY_ID_LENGTH: The received option length is not supported. This is a long lifetime error.
26:取消批准第三方ID长度：不支持接收的选项长度。这是一个长期的错误。
The following sections describe the operations of a PCP client and a PCP server when generating the request and processing the request and response.
以下各节描述生成请求和处理请求与响应时PCP客户端和PCP服务器的操作。
In addition to generating a PCP request that is described in [RFC6887], the following has to be applied. The THIRD_PARTY_ID option MAY be included either in a PCP MAP or PEER opcode. It MUST be used in combination with the THIRD_PARTY option, which provides an IP address. The THIRD_PARTY_ID option holds an identifier to allow the PCP-controlled device to uniquely identify the internal host
除了生成[RFC6887]中描述的PCP请求外，还必须应用以下内容。第三方ID选项可以包含在PCP映射或对等操作码中。它必须与提供IP地址的第三方选项结合使用。第三方ID选项包含一个标识符，允许PCP控制的设备唯一标识内部主机
(specified in the THIRD_PARTY option) for which the port mapping is to be established or modified. The padding rules described in Section 4 apply.
（在第三方选项中指定）为其建立或修改端口映射。第4节中描述的填充规则适用。
The THIRD_PARTY_ID option is in the mandatory-to-process range; if the PCP server does not support this option, it MUST return an UNSUPP_OPTION response. If the provided identifier in a THIRD_PARTY_ID option is unknown/unavailable, the PCP server MUST return a THIRD_PARTY_ID_UNKNOWN response. If the PCP server receives a request with an unsupported THIRD_PARTY_ID option length, it MUST return an UNSUPP_THIRD_PARTY_ID_LENGTH response. If the PCP server receives a THIRD_PARTY_ID option without a THIRD_PARTY option, it MUST return a THIRD_PARTY_MISSING_OPTION response.
第三方ID选项在强制处理范围内；如果PCP服务器不支持此选项，则必须返回UNSUPP_选项响应。如果第三方ID选项中提供的标识符未知/不可用，PCP服务器必须返回第三方ID未知响应。如果PCP服务器接收到具有不受支持的第三方ID选项长度的请求，则它必须返回一个UNSUPP第三方ID长度响应。如果PCP服务器收到第三方ID选项而没有第三方选项，则必须返回第三方缺少选项响应。
Upon receiving a valid request with a legal THIRD_PARTY_ID option identifier, the message is processed as specified in [RFC6887], except that the identifier contained in the THIRD_PARTY_ID is used in addition when accessing a mapping table. Instead of just using the value contained in the THIRD_PARTY option when accessing the internal Internet address of a mapping table, now the combination of the two values contained in the THIRD_PARTY option and in the THIRD_PARTY_ID option is used to access the combination of the internal Internet address and the internal realm of a NAT map entry.
收到具有合法第三方ID选项标识符的有效请求后，将按照[RFC6887]中的规定处理该消息，但在访问映射表时，将另外使用第三方ID中包含的标识符。在访问映射表的内部Internet地址时，不只是使用第三方选项中包含的值，现在使用第三方选项和第三方ID选项中包含的两个值的组合来访问内部Internet地址和NAT映射项的内部域的组合。
If two or more different tunnel technologies are being used, precautions need to be taken to handle potential overlap of the ID spaces of these technologies. For example, different PCP client/PCP server pairs can be used per tunnel technology.
如果正在使用两种或两种以上不同的隧道技术，则需要采取预防措施来处理这些技术的ID空间的潜在重叠。例如，每个隧道技术可以使用不同的PCP客户端/PCP服务器对。
In addition to the response processing described in [RFC6887], if the PCP client receives a THIRD_PARTY_ID_UNKNOWN or a UNSUPP_THIRD_PARTY_ID_LENGTH or a THIRD_PARTY_MISSING_OPTION response back for its previous request, it SHOULD report an error. Where to report an error is based on policy.
除了[RFC6887]中所述的响应处理外，如果PCP客户端收到第三方ID未知或未批准的第三方ID长度或第三方缺少选项响应，则应报告错误。报告错误的位置取决于策略。
The following PCP Option Code has been allocated in the mandatory-to-process range:
以下PCP选项代码已分配到强制处理范围：
o 13: THIRD_PARTY_ID
o 13：第三方ID
The following PCP Result Codes have been allocated:
已分配以下PCP结果代码：
o 24: THIRD_PARTY_ID_UNKNOWN
o 24：第三方身份不明
o 25: THIRD_PARTY_MISSING_OPTION
o 25：第三方缺少选项
o 26: UNSUPP_THIRD_PARTY_ID_LENGTH
o 26：取消批准第三方ID长度
This option is to be used in combination with the THIRD_PARTY option. Consequently, all corresponding security considerations in Section 18.1.1 of [RFC6887] apply. In particular, the network on which the PCP messages are sent must be sufficiently protected. Further, it is RECOMMENDED to use PCP authentication [RFC7652] unless the network already has appropriate authentication means in place.
此选项将与第三方选项结合使用。因此，[RFC6887]第18.1.1节中的所有相应安全注意事项适用。特别是，发送PCP消息的网络必须得到充分保护。此外，建议使用PCP身份验证[RFC7652]，除非网络已经有适当的身份验证手段。
The THIRD_PARTY_ID option carries a context identifier whose type and length is deployment and implementation dependent. This identifier might carry privacy sensitive information. It is therefore RECOMMENDED to utilize identifiers that do not have such privacy concerns. Means to protect unauthorized access to this information MUST be put in place. In the scenarios described in this document, for example, access to the web portal or UPnP IGD-PCP IWF MUST be authenticated. Generally speaking, the identifier itself MUST only be accessible by the network operator and MUST only be handled on operator equipment. For example, creation of a PCP message on the web portal or the UPnP IGD PCP IWF is triggered by the subscriber, but the actual option filling is done by an operator-controlled entity.
第三方ID选项携带一个上下文标识符，其类型和长度取决于部署和实现。此标识符可能包含隐私敏感信息。因此，建议使用不存在此类隐私问题的标识符。必须采取措施保护未经授权访问此信息。例如，在本文档中描述的场景中，对web门户或UPnP IGD-PCP IWF的访问必须经过身份验证。一般来说，标识符本身只能由网络运营商访问，并且只能在运营商设备上处理。例如，在门户网站或UPnP IGD PCP IWF上创建PCP消息由订户触发，但实际选项填充由运营商控制的实体完成。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[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>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <http://www.rfc-editor.org/info/rfc6598>.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，DOI 10.17487/RFC6598，2012年4月<http://www.rfc-editor.org/info/rfc6598>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，DOI 10.17487/RFC6887，2013年4月<http://www.rfc-editor.org/info/rfc6887>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>.
[RFC3931]Lau，J.，Ed.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 3931，DOI 10.17487/RFC3931，2005年3月<http://www.rfc-editor.org/info/rfc3931>.
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012, <http://www.rfc-editor.org/info/rfc6619>.
[RFC6619]Arkko，J.，Eggert，L.，和M.Townsley，“具有每个接口绑定的地址转换器的可扩展操作”，RFC 6619，DOI 10.17487/RFC66192012年6月<http://www.rfc-editor.org/info/rfc6619>.
[RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, DOI 10.17487/RFC6674, July 2012, <http://www.rfc-editor.org/info/rfc6674>.
[RFC6674]Brockners，F.，Gundavelli，S.，Speicher，S.，和D.Ward，“网关启动的双堆栈Lite部署”，RFC 6674，DOI 10.17487/RFC66742012年7月<http://www.rfc-editor.org/info/rfc6674>.
[RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, DOI 10.17487/RFC6970, July 2013, <http://www.rfc-editor.org/info/rfc6970>.
[RFC6970]Boucadair，M.，Penno，R.，和D.Wing，“通用即插即用（UPnP）互联网网关设备-端口控制协议互通功能（IGD-PCP IWF）”，RFC 6970，DOI 10.17487/RFC6970，2013年7月<http://www.rfc-editor.org/info/rfc6970>.
[RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port Control Protocol (PCP) Authentication Mechanism", RFC 7652, DOI 10.17487/RFC7652, September 2015, <http://www.rfc-editor.org/info/rfc7652>.
[RFC7652]Cullen，M.，Hartman，S.，Zhang，D.，和T.Reddy，“端口控制协议（PCP）认证机制”，RFC 7652，DOI 10.17487/RFC7652，2015年9月<http://www.rfc-editor.org/info/rfc7652>.
Acknowledgments
致谢
Thanks to Mohamed Boucadair for many valuable suggestions, in particular for suggesting a variable length for the THIRD_PARTY_ID option. Thanks to Dave Thaler, Tom Taylor, and Dan Wing for their comments and review.
感谢Mohamed Boucadair提出了许多有价值的建议，特别是为第三方ID选项提供了可变长度的建议。感谢Dave Thaler、Tom Taylor和Dan Wing的评论和评论。
Authors' Addresses
作者地址
Andreas Ripke NEC Heidelberg Germany
Andreas Ripke NEC德国海德堡
Email: ripke@neclab.eu
Email: ripke@neclab.eu
Rolf Winter NEC Heidelberg Germany
德国海德堡Rolf Winter NEC
Email: winter@neclab.eu
Email: winter@neclab.eu
Thomas Dietz NEC Heidelberg Germany
德国海德堡NEC公司托马斯·迪茨
Email: dietz@neclab.eu
Email: dietz@neclab.eu
Juergen Quittek NEC Heidelberg Germany
德国海德堡Juergen QUITEK NEC
Email: quittek@neclab.eu
Email: quittek@neclab.eu
Rafael Lopez da Silva Telefonica I+D Madrid Spain
拉斐尔·洛佩斯·达席尔瓦西班牙马德里电视台I+D
Email: rafaelalejandro.lopezdasilva@telefonica.com
Email: rafaelalejandro.lopezdasilva@telefonica.com