Internet Engineering Task Force (IETF) S. Perreault
Request for Comments: 7648 Jive Communications
Category: Standards Track M. Boucadair
ISSN: 2070-1721 France Telecom
R. Penno
D. Wing
Cisco
S. Cheshire
Apple
September 2015
Internet Engineering Task Force (IETF) S. Perreault
Request for Comments: 7648 Jive Communications
Category: Standards Track M. Boucadair
ISSN: 2070-1721 France Telecom
R. Penno
D. Wing
Cisco
S. Cheshire
Apple
September 2015
Port Control Protocol (PCP) Proxy Function
端口控制协议（PCP）代理功能
Abstract
摘要
This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.
本文档指定了一个新的端口控制协议（PCP）功能元素：PCP代理。PCP代理将从PCP客户端接收的PCP请求中继到上游PCP服务器。此功能的典型部署用途是帮助为PCP客户端建立成功的PCP通信，这些客户端无法使用位于多个跃点之外的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/rfc7648.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7648.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Case: The NAT Cascade . . . . . . . . . . . . . . . . 4
1.2. Use Case: The PCP Relay . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operation of the PCP Proxy . . . . . . . . . . . . . . . . . 6
3.1. Optimized Hairpin Routing . . . . . . . . . . . . . . . . 8
3.2. Termination of Recursion . . . . . . . . . . . . . . . . 9
3.3. Source Address for PCP Requests Sent Upstream . . . . . . 10
3.4. Unknown Opcodes and Options . . . . . . . . . . . . . . . 10
3.4.1. No NAT Is Co-located with the PCP Proxy . . . . . . . 10
3.4.2. PCP Proxy Co-located with a NAT Function . . . . . . 10
3.5. Mapping Repair . . . . . . . . . . . . . . . . . . . . . 11
3.6. Multiple PCP Servers . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Normative References . . . . . . . . . . . . . . . . . . 12
5.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Case: The NAT Cascade . . . . . . . . . . . . . . . . 4
1.2. Use Case: The PCP Relay . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operation of the PCP Proxy . . . . . . . . . . . . . . . . . 6
3.1. Optimized Hairpin Routing . . . . . . . . . . . . . . . . 8
3.2. Termination of Recursion . . . . . . . . . . . . . . . . 9
3.3. Source Address for PCP Requests Sent Upstream . . . . . . 10
3.4. Unknown Opcodes and Options . . . . . . . . . . . . . . . 10
3.4.1. No NAT Is Co-located with the PCP Proxy . . . . . . . 10
3.4.2. PCP Proxy Co-located with a NAT Function . . . . . . 10
3.5. Mapping Repair . . . . . . . . . . . . . . . . . . . . . 11
3.6. Multiple PCP Servers . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Normative References . . . . . . . . . . . . . . . . . . 12
5.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
This document defines a new Port Control Protocol (PCP) [RFC6887] functional element: the PCP proxy. As shown in Figure 1, the PCP proxy is logically equivalent to a PCP client back-to-back with a PCP server. The "glue" between the two is what is specified in this document. Other than that "glue", the server and the client behave exactly like their regular counterparts.
本文档定义了一个新的端口控制协议（PCP）[RFC6887]功能元素：PCP代理。如图1所示，PCP代理在逻辑上等同于PCP客户端与PCP服务器背靠背。两者之间的“粘合剂”是本文件中规定的。除了“胶水”之外，服务器和客户机的行为与它们的常规对手完全相同。
The PCP proxy is responsible for relaying PCP messages received from PCP clients to upstream PCP servers and vice versa.
PCP代理负责将从PCP客户端接收的PCP消息中继到上游PCP服务器，反之亦然。
Whether or not the PCP proxy is co-located with a flow-aware function (e.g., NAT, firewall) is deployment specific.
PCP代理是否与流量感知功能（如NAT、防火墙）位于同一位置取决于部署。
.................
+------+ : +------+------+ : +------+
|Client|-------:-|Server|Client|-:----|Server|
+------+ : +------+------+ : +------+
: Proxy :
.................
.................
+------+ : +------+------+ : +------+
|Client|-------:-|Server|Client|-:----|Server|
+------+ : +------+------+ : +------+
: Proxy :
.................
Figure 1: Reference Architecture
图1：参考体系结构
This document assumes a hop-by-hop PCP authentication scheme. That is, referring to Figure 1, the leftmost PCP client authenticates with the PCP proxy, while the PCP proxy authenticates with the upstream server. Note that in some deployments, PCP authentication may only be enabled between the PCP proxy and an upstream PCP server (e.g., a customer premises host may not authenticate with the PCP proxy, but the PCP proxy may authenticate with the PCP server). The hop-by-hop authentication scheme is more suitable from a deployment standpoint. Furthermore, it allows implementations to easily support a PCP proxy that alters PCP messages (e.g., strips a PCP option, modifies a PCP field).
本文档采用逐跳PCP身份验证方案。也就是说，参考图1，最左边的PCP客户端使用PCP代理进行身份验证，而PCP代理使用上游服务器进行身份验证。请注意，在某些部署中，PCP身份验证可能仅在PCP代理和上游PCP服务器之间启用（例如，客户场所主机可能不使用PCP代理进行身份验证，但PCP代理可以使用PCP服务器进行身份验证）。从部署的角度来看，逐跳认证方案更合适。此外，它允许实现轻松支持改变PCP消息的PCP代理（例如，去除PCP选项，修改PCP字段）。
In today's world, with public routable IPv4 addresses becoming less readily available, it is increasingly common for customers to receive a private address from their Internet Service Provider (ISP), and the ISP uses a NAT gateway of its own to translate those packets before sending them out onto the public Internet. This means that there is likely to be more than one NAT on the path between client machines and the public Internet:
在当今世界，随着公共可路由IPv4地址变得越来越不容易获得，客户从其互联网服务提供商（ISP）接收私人地址的情况越来越普遍，而ISP使用自己的NAT网关在将这些数据包发送到公共互联网之前对其进行翻译。这意味着在客户端计算机和公共Internet之间的路径上可能有多个NAT：
o If a residential customer receives a translated address from their ISP and then installs their own residential NAT gateway to share that address between multiple client devices in their home, then there are at least two NAT gateways on the path between client devices and the public Internet.
o 如果住宅客户从其ISP接收到转换后的地址，然后安装自己的住宅NAT网关，以便在其家中的多个客户端设备之间共享该地址，则在客户端设备和公共Internet之间的路径上至少有两个NAT网关。
o If a mobile phone customer receives a translated address from their mobile phone carrier and uses "Personal Hotspot" or "Internet Sharing" software on their mobile phone to make Wireless LAN (WLAN) Internet access available to other client devices, then there are at least two NAT gateways on the path between those client devices and the public Internet.
o 如果移动电话客户从其移动电话运营商接收到翻译后的地址，并在其移动电话上使用“个人热点”或“互联网共享”软件，使其他客户端设备可以使用无线局域网（WLAN）互联网接入，然后，在这些客户端设备和公共Internet之间的路径上至少有两个NAT网关。
o If a hotel guest connects a portable WLAN gateway to their hotel room's Ethernet port to share their room's Internet connection between their phone and their laptop computer, then packets from the client devices may traverse the hotel guest's portable NAT, the hotel network's NAT, and the ISP's NAT before reaching the public Internet.
o 如果酒店客人将便携式WLAN网关连接到其酒店房间的以太网端口，以在其手机和笔记本电脑之间共享其房间的互联网连接，则来自客户端设备的数据包可能会在到达公共互联网之前通过酒店客人的便携式NAT、酒店网络的NAT和ISP的NAT。
While it is possible, in theory, that client devices could somehow discover all the NATs on the path and communicate with each one separately using PCP [RFC6887], in practice it is not clear how client devices would reliably learn this information. Since the NAT gateways are installed and operated by different individuals and organizations, no single entity has knowledge of all the NATs on the path. Also, even if a client device could somehow know all the NATs on the path, requiring a client device to communicate separately with all of them imposes unreasonable complexity on PCP clients, many of which are expected to be simple low-cost devices.
虽然从理论上讲，客户端设备可能会以某种方式发现路径上的所有NAT，并使用PCP[RFC6887]分别与每个NAT通信，但实际上，客户端设备如何可靠地学习这些信息尚不清楚。由于NAT网关由不同的个人和组织安装和操作，因此没有一个实体知道路径上的所有NAT。此外，即使客户机设备能够以某种方式知道路径上的所有NAT，要求客户机设备与所有NAT单独通信也会给PCP客户机带来不合理的复杂性，其中许多被认为是简单的低成本设备。
In addition, this goes against the spirit of NAT gateways. The main purpose of a NAT gateway is to make multiple downstream client devices appear, from the point of view of everything upstream of the NAT gateway, to be a single client device. In the same spirit, it makes sense for a PCP-capable NAT gateway to make multiple downstream
此外，这与NAT网关的精神背道而驰。NAT网关的主要目的是使多个下游客户端设备从NAT网关上游的所有设备的角度来看成为单个客户端设备。本着同样的精神，一个支持PCP的NAT网关进行多个下游连接也是有意义的
client devices requesting port mappings appear, from the point of view of everything upstream of the NAT gateway, to be a single client device requesting port mappings.
从NAT网关上游的所有方面来看，请求端口映射的客户端设备似乎是请求端口映射的单个客户端设备。
Another envisioned use case of the PCP proxy is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away. A PCP proxy can, for instance, be embedded in a CPE (Customer Premises Equipment) while the PCP server is located in a network operated by an ISP. This is illustrated in Figure 2.
PCP代理的另一个设想用例是帮助为PCP客户端建立成功的PCP通信，这些PCP客户端无法使用位于多个跃点之外的PCP服务器的地址进行配置。例如，当PCP服务器位于由ISP操作的网络中时，PCP代理可以嵌入到CPE（客户场所设备）中。如图2所示。
|
+------+ |
|Client|--+
+------+ | +-----+ +------+
+--|Proxy|--------<ISP network>----------|Server|
+------+ | +-----+ +------+
|Client|--+ CPE
+------+ |
|
LAN
|
+------+ |
|Client|--+
+------+ | +-----+ +------+
+--|Proxy|--------<ISP network>----------|Server|
+------+ | +-----+ +------+
|Client|--+ CPE
+------+ |
|
LAN
Figure 2: PCP Relay Use Case
图2:PCP继电器用例
This works because the proxy's server side is listening on the address used as a default gateway by the clients. The clients use that address as a fallback when discovering the PCP server's address. The proxy picks up the requests and forwards them upstream to the ISP's PCP server, with whose address it has been provisioned through regular PCP client provisioning means.
这是因为代理服务器端正在侦听客户端用作默认网关的地址。当发现PCP服务器的地址时，客户端将该地址用作备用地址。代理接收请求并将其转发到ISP的PCP服务器的上游，该服务器的地址已通过常规PCP客户端配置方式配置。
This particular use case assumes that provisioning the server's address on the CPE is feasible while doing it on the clients in the LAN is not, which is what makes the PCP proxy valuable.
这个特定的用例假设在CPE上提供服务器地址是可行的，而在LAN中的客户端上提供服务器地址是不可行的，这就是PCP代理的价值所在。
An alternative way to contact an upstream PCP server that may be several hops away is to use a well-known anycast address [PCP-ANYCAST], but that technique can be problematic when multiple PCP servers are to be contacted [PCP-DEPLOY].
联系可能在几跳之外的上游PCP服务器的另一种方法是使用众所周知的选播地址[PCP-anycast]，但当要联系多个PCP服务器[PCP-DEPLOY]时，该技术可能会出现问题。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。
Where this document uses the terms "upstream" and "downstream", the term "upstream" refers to the direction outbound packets travel towards the public Internet, and the term "downstream" refers to the direction inbound packets travel from the public Internet towards client systems. Typically, when a home user views a web site, their computer sends an outbound TCP SYN packet upstream towards the public Internet, and an inbound downstream TCP SYN ACK reply comes back from the public Internet.
如果本文件使用术语“上游”和“下游”，术语“上游”是指出站数据包向公共互联网的方向，术语“下游”是指入站数据包从公共互联网向客户端系统的方向。通常，当家庭用户查看网站时，他们的计算机向公共Internet上游发送出站TCP SYN数据包，并从公共Internet返回入站下游TCP SYN ACK应答。
Upon receipt of a PCP mapping-creation request from a downstream PCP client, a PCP proxy first examines its local mapping table to see if it already has a valid active mapping matching the internal address and internal port (and in the case of PEER requests, the remote peer) given in the request.
从下游PCP客户端接收到PCP映射创建请求后，PCP代理首先检查其本地映射表，以查看其是否已具有与请求中给出的内部地址和内部端口（以及对等请求中的远程对等）匹配的有效活动映射。
If the PCP proxy does not already have a valid active mapping for this mapping-creation request, then it allocates an available port on its external interface. We assume for the sake of this description that the address of its external interface is itself a private address, subject to translation by an upstream NAT. The PCP proxy then constructs an appropriate corresponding PCP request of its own (as described below) and sends it to its upstream NAT, and the newly created local mapping is considered temporary until a confirming reply is received from the upstream PCP server.
如果PCP代理尚未对此映射创建请求具有有效的活动映射，则它会在其外部接口上分配一个可用端口。为了便于描述，我们假设其外部接口的地址本身是私有地址，由上游NAT进行转换。然后，PCP代理构造其自己的相应PCP请求（如下所述），并将其发送到其上游NAT，并且新创建的本地映射被认为是临时的，直到从上游PCP服务器接收到确认应答为止。
If the PCP proxy does already have a valid active mapping for this mapping-creation request and the lifetime remaining on the local mapping is at least 3/4 of the lifetime requested by the PCP client, then the PCP proxy SHOULD send an immediate reply giving the outermost external address and port (previously learned using PCP recursively, as described below) and the actual lifetime remaining for this mapping. If the lifetime remaining on the local mapping is less than 3/4 of the lifetime requested by the PCP client, then the PCP proxy MUST generate an upstream request as described below.
如果PCP代理已对此映射创建请求具有有效的活动映射，并且本地映射上剩余的生存期至少是PCP客户端请求的生存期的3/4，则PCP代理应立即发送一个回复，给出最外层的外部地址和端口（之前使用PCP递归学习，如下所述）和此映射的实际剩余生存期。如果本地映射上剩余的生存期小于PCP客户端请求的生存期的3/4，则PCP代理必须生成如下所述的上游请求。
For mapping-deletion requests (lifetime = 0), the local mapping, if any, is deleted, and then (regardless of whether or not a local mapping existed) a corresponding upstream request is generated.
对于映射删除请求（生存期=0），将删除本地映射（如果有），然后（无论是否存在本地映射）生成相应的上游请求。
The PCP proxy knows the destination IP address for its upstream PCP request using the same means that are available for provisioning a PCP client. In particular, the PCP proxy MUST follow the procedure defined in Section 8.1 of the PCP specification [RFC6887] to discover its PCP server. This does not preclude other means from being used in addition.
PCP代理知道其上游PCP请求的目标IP地址，所使用的方法与提供PCP客户端的方法相同。特别是，PCP代理必须遵循PCP规范[RFC6887]第8.1节中定义的程序来发现其PCP服务器。这并不排除另外使用其他方法。
In the upstream PCP request:
在上游PCP请求中：
o The PCP client's IP address and internal port are the PCP proxy's own external address and port just allocated for this mapping.
o PCP客户端的IP地址和内部端口是PCP代理自己的外部地址和刚刚为此映射分配的端口。
o The suggested external address and port in the upstream PCP request SHOULD be copied from the original PCP request. On a typical renewal request, this will be the outermost external address and port previously learned by the client.
o 上游PCP请求中建议的外部地址和端口应从原始PCP请求中复制。在典型的续订请求中，这将是客户端以前了解到的最外面的外部地址和端口。
o The requested lifetime is as requested by the client if it falls within the acceptable range for this PCP server; otherwise, it SHOULD be capped to appropriate minimum and maximum values configured for this PCP server.
o 如果请求的生存期在该PCP服务器的可接受范围内，则该生存期是客户端请求的；否则，应将其上限设置为为此PCP服务器配置的适当最小值和最大值。
o The mapping nonce is copied from the original PCP request.
o 映射nonce是从原始PCP请求复制的。
o For PEER requests, the remote peer IP address and port are copied from the original PCP request.
o 对于对等请求，将从原始PCP请求复制远程对等IP地址和端口。
Upon receipt of a PCP reply giving the outermost (i.e., publicly routable) external address, port, and lifetime, the PCP proxy records this information in its own mapping table and relays the information to the requesting downstream PCP client in a PCP reply. The PCP proxy therefore records, among other things, the following information in its mapping table:
在收到给出最外层（即，可公开路由的）外部地址、端口和生存期的PCP回复后，PCP代理将此信息记录在自己的映射表中，并在PCP回复中将该信息转发给请求的下游PCP客户端。因此，PCP代理在其映射表中记录以下信息：
o Client's internal address and port.
o 客户端的内部地址和端口。
o External address and port allocated by this PCP proxy.
o 此PCP代理分配的外部地址和端口。
o Outermost external address and port allocated by the upstream PCP server.
o 上游PCP服务器分配的最外层外部地址和端口。
o Mapping lifetime (also dictated by the upstream PCP server).
o 映射生存期（也由上游PCP服务器决定）。
o Mapping nonce.
o 映射nonce。
In the downstream PCP reply:
在下游PCP回复中：
o The lifetime is as granted by the upstream PCP server, or less if the granted lifetime exceeds the maximum lifetime this PCP server is configured to grant. If the proxy chooses to grant a downstream lifetime greater than the lifetime granted by the upstream PCP server (which is NOT RECOMMENDED), then this PCP proxy MUST take responsibility for renewing the upstream mapping itself.
o 此生存期由上游PCP服务器授予，如果授予的生存期超过此PCP服务器配置为授予的最大生存期，则为更短。如果代理选择授予的下游生存期大于上游PCP服务器授予的生存期（不推荐），则此PCP代理必须负责更新上游映射本身。
o The Epoch Time is this PCP proxy's Epoch Time, not the Epoch Time of the upstream PCP server. Each PCP server has its own independent Epoch Time. However, if the Epoch Time received from the upstream PCP server indicates a loss of state in that PCP server, the PCP proxy can either (1) recreate the lost mappings itself or (2) reset its own Epoch Time to cause its downstream clients to perform such state repairs themselves. A PCP proxy MUST NOT simply copy the upstream PCP server's Epoch Time into its downstream PCP replies, because if it suffers its own state loss it needs the ability to communicate that state loss to clients. Thus, each PCP server has its own independent Epoch Time. However, as a convenience, a downstream PCP proxy may simply choose to reset its own Epoch Time whenever it detects that its upstream PCP server has lost state. Thus, in this case, the PCP proxy's Epoch Time always resets whenever its upstream PCP server loses state; it may reset at other times as well.
o Epoch Time是此PCP代理的Epoch Time，而不是上游PCP服务器的Epoch Time。每个PCP服务器都有自己独立的历元时间。但是，如果从上游PCP服务器接收到的历元时间指示该PCP服务器中的状态丢失，则PCP代理可以（1）重新创建丢失的映射本身，或者（2）重置其自己的历元时间，以使其下游客户端自己执行此类状态修复。PCP代理不能简单地将上游PCP服务器的Epoch时间复制到其下游PCP应答中，因为如果它遭受自己的状态丢失，它需要能够将该状态丢失传递给客户端。因此，每个PCP服务器都有自己独立的历元时间。然而，为了方便起见，当下游PCP代理检测到其上游PCP服务器已丢失状态时，可以简单地选择重置其自己的Epoch时间。因此，在这种情况下，每当其上游PCP服务器失去状态时，PCP代理的历元时间总是重置；它也可能在其他时间重置。
o The mapping nonce is copied from the reply received from the upstream PCP server.
o 映射nonce从从上游PCP服务器接收的应答中复制。
o The assigned external port and assigned external IP address are copied from the reply received from the upstream PCP server (i.e., they are the outermost external IP address and port, not the locally assigned external address and port). By recursive application of this procedure, the outermost external IP address and port are relayed from the outermost NAT, through one or more intervening PCP proxies, until they ultimately reach the downstream client.
o 分配的外部端口和分配的外部IP地址是从上游PCP服务器收到的回复中复制的（即，它们是最外层的外部IP地址和端口，而不是本地分配的外部地址和端口）。通过递归应用此过程，最外层的外部IP地址和端口通过一个或多个介入PCP代理从最外层的NAT中继，直到它们最终到达下游客户端。
o For PEER requests, the remote peer IP address and port are copied from the reply received from the upstream PCP server.
o 对于对等请求，远程对等IP地址和端口将从从上游PCP服务器接收的应答中复制。
A PCP proxy SHOULD implement optimized hairpin routing. What this means is the following:
PCP代理应该实现优化的发夹路由。这意味着：
o If a PCP proxy observes an outgoing packet arriving on its internal interface that is addressed to an external address and port appearing in the NAT gateway's own mapping table, then the NAT gateway SHOULD (after creating a new outbound mapping if one does not already exist) rewrite the packet appropriately and deliver it to the internal client to which that external address and port are currently allocated.
o 如果PCP代理观察到到达其内部接口的传出数据包，该数据包被寻址到NAT网关自身映射表中出现的外部地址和端口，则NAT网关应（在创建新的出站映射（如果还不存在）后）适当地重写数据包，并将其发送到当前已分配外部地址和端口的内部客户端。
o Similarly, if a PCP proxy observes an outgoing packet arriving on its internal interface that is addressed to an *outermost* external address and port appearing in the NAT gateway's own mapping table, then the NAT gateway SHOULD do as described above: create a new outbound mapping if one does not already exist, and then rewrite the packet appropriately and deliver it to the internal client to which that outermost external address and port are currently allocated. This is not necessary for successful communication, but it provides efficiency. Without this optimized hairpin routing, the packet will be delivered all the way to the outermost NAT gateway, which will then perform standard hairpin translation and send it back. Using knowledge of the outermost external address and port, this rewriting can be anticipated and performed locally. This rewriting technique will typically offer higher throughput and lower latency than sending packets all the way to the outermost NAT gateway and back.
o 类似地，如果PCP代理观察到到达其内部接口的传出数据包，该数据包被寻址到NAT网关自己的映射表中出现的*最外层*外部地址和端口，则NAT网关应如上所述：如果不存在新的出站映射，则创建新的出站映射，然后适当地重写数据包，并将其传递给当前分配了最外层外部地址和端口的内部客户端。这不是成功沟通的必要条件，但它提供了效率。如果没有这种优化的发夹路由，数据包将一直传送到最外层的NAT网关，然后该网关将执行标准的发夹转换并将其发送回。利用最外层外部地址和端口的知识，可以预期并在本地执行这种重写。这种重写技术通常会提供更高的吞吐量和更低的延迟，而不是将数据包一直发送到最外层的NAT网关并返回。
Note that traffic counters maintained by an upstream PCP server will differ from the counters of a PCP proxy implementing optimized hairpin routing.
请注意，由上游PCP服务器维护的流量计数器将不同于实现优化发夹路由的PCP代理的计数器。
Any recursive algorithm needs a mechanism to terminate the recursion at the appropriate point. This termination of recursion can be achieved in a variety of ways. The following (non-exhaustive) examples are provided for illustration purposes:
任何递归算法都需要一种机制来在适当的点终止递归。递归的终止可以通过多种方式实现。以下（非详尽）示例用于说明：
o An ISP's PCP-controlled gateway (which may embed a NAT, firewall, or any function that can be controlled with PCP) could be configured to know that it is the outermost PCP-controlled gateway, and consequently it does not need to relay PCP requests upstream.
o ISP的PCP控制网关（可嵌入NAT、防火墙或任何可通过PCP控制的功能）可以配置为知道它是最外层的PCP控制网关，因此不需要向上游中继PCP请求。
o A PCP-controlled gateway could determine automatically that if its external address is not one of the known private addresses [RFC1918] [RFC6598], then its external address is a public routable IP address, and consequently it does not need to relay PCP requests upstream.
o PCP控制的网关可以自动确定，如果其外部地址不是已知的专用地址[RFC1918][RFC6598]之一，则其外部地址是公共可路由IP地址，因此不需要向上游中继PCP请求。
o Recursion may be terminated if there is no explicit list of PCP servers configured (manually, using DHCP [RFC7291], or otherwise) or if its default router is not responsive to PCP requests.
o 如果没有配置PCP服务器的明确列表（手动，使用DHCP[RFC7291]或其他方式），或者如果其默认路由器没有响应PCP请求，则递归可能会终止。
o Recursion may also be terminated if the upstream PCP-controlled device does not embed a PCP proxy.
o 如果上游PCP控制设备未嵌入PCP代理，则递归也可终止。
As with a regular PCP server, the PCP-controlled device can be a NAT, a firewall, or even some sort of hybrid. In particular, a PCP proxy that simply relays all requests upstream can be thought of as the degenerate case of a PCP server controlling a wide-open firewall back-to-back with a regular PCP client.
与常规PCP服务器一样，PCP控制的设备可以是NAT、防火墙，甚至是某种混合设备。特别是，简单地将所有请求中继到上游的PCP代理可以被认为是PCP服务器与常规PCP客户端背靠背地控制完全开放的防火墙的退化情况。
One important property of the PCP-controlled device will affect the PCP proxy's behavior: when the proxy's server part instructs the device to create a mapping, that mapping's external address may or may not be one that belongs to the proxy node.
PCP控制设备的一个重要属性将影响PCP代理的行为：当代理服务器部件指示设备创建映射时，该映射的外部地址可能属于代理节点，也可能不属于代理节点。
o When the mapping's external address belongs to the proxy node, as would presumably be the case for a NAT, then the proxy's client side sends out an upstream PCP request using the mapping's external IP address as the source.
o 当映射的外部地址属于代理节点时（可能是NAT的情况），则代理的客户端使用映射的外部IP地址作为源发送上游PCP请求。
o When the mapping's external address does not belong to the proxy node, as would presumably be the case for a firewall, then the proxy's client side needs to install upstream mappings on behalf of its downstream clients. To do this, it MUST insert a THIRD_PARTY option in its upstream PCP request carrying the mapping's external address.
o 当映射的外部地址不属于代理节点时（可能是防火墙的情况），则代理的客户端需要代表其下游客户端安装上游映射。为此，它必须在其上游PCP请求中插入一个第三方选项，其中包含映射的外部地址。
Note that hybrid PCP-controlled devices may create NAT-like mappings in some circumstances and firewall-like mappings in others. A proxy controlling such a device would adjust its behavior dynamically, depending on the kind of mapping created.
请注意，混合PCP控制的设备可能在某些情况下创建类似NAT的映射，而在其他情况下创建类似防火墙的映射。控制此类设备的代理将根据创建的映射类型动态调整其行为。
When no NAT is co-located with the PCP proxy, the port numbers included in received PCP messages (from the PCP server or PCP client(s)) are not altered by the PCP proxy. The PCP proxy relays to the PCP server unknown options and Opcodes because there is no reachability failure risk.
当没有NAT与PCP代理位于同一位置时，PCP代理不会更改接收到的PCP消息（来自PCP服务器或PCP客户端）中包含的端口号。PCP代理将未知选项和操作码中继到PCP服务器，因为不存在可达性故障风险。
By default, the proxy MUST relay unknown Opcodes and mandatory-to-process unknown options. Rejecting unknown options and Opcodes has the drawback of preventing a PCP client from making use of new capabilities offered by the PCP server but not supported by the PCP proxy, even if no IP address and/or port is included in the option/Opcode.
默认情况下，代理必须中继未知操作码，并且必须处理未知选项。拒绝未知选项和操作码的缺点是，即使选项/操作码中不包含IP地址和/或端口，也会阻止PCP客户端使用PCP服务器提供但PCP代理不支持的新功能。
Because PCP messages with an unknown Opcode or mandatory-to-process unknown options can carry a hidden internal address or internal port that will not be translated, a PCP proxy MUST be configurable to disable relaying unknown Opcodes and mandatory-to-process unknown options. If the PCP proxy is configured to disable relaying unknown Opcodes and mandatory-to-process unknown options, the PCP proxy MUST behave as follows:
由于带有未知操作码或必须处理未知选项的PCP消息可能携带隐藏的内部地址或内部端口，而这些地址或端口不会被转换，因此PCP代理必须可配置为禁用中继未知操作码，并必须处理未知选项。如果PCP代理配置为禁用中继未知操作码，并且必须处理未知选项，则PCP代理的行为必须如下所示：
o a PCP proxy co-located with a NAT MUST reject, via an UNSUPP_OPCODE error response, a received request with an unknown Opcode.
o 与NAT共存的PCP代理必须通过UNSUPP_操作码错误响应拒绝接收到的具有未知操作码的请求。
o a PCP proxy co-located with a NAT MUST reject, via an UNSUPP_OPTION error response, a received request with a mandatory-to-process unknown option.
o 与NAT位于同一位置的PCP代理必须通过UNSUPP_选项错误响应拒绝接收到的带有强制处理未知选项的请求。
ANNOUNCE requests received from PCP clients are handled locally; as such, these requests MUST NOT be relayed to the provisioned PCP server.
宣布从PCP客户端收到的请求在本地处理；因此，这些请求不得中继到已配置的PCP服务器。
Upon receipt of an unsolicited ANNOUNCE response from a PCP server, the PCP proxy proceeds to renew the mappings and checks to see whether or not there are changes compared to a local cache if it is maintained by the PCP proxy. If no change is detected, no unsolicited ANNOUNCE is generated towards PCP clients. If a change is detected, the PCP proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate PCP clients. If the PCP proxy does not maintain a local cache for the mappings, unsolicited multicast ANNOUNCE messages are sent to PCP clients.
收到来自PCP服务器的未经请求的通告响应后，PCP代理将继续更新映射，并检查与本地缓存（如果由PCP代理维护）相比是否存在更改。如果未检测到任何更改，则不会向PCP客户端生成未经请求的公告。如果检测到更改，PCP代理必须向相应的PCP客户端生成未经请求的公告消息。如果PCP代理没有为映射维护本地缓存，则会向PCP客户端发送未经请求的多播公告消息。
Upon change of its external IP address, the PCP proxy SHOULD renew the mappings it maintained. If the PCP server assigns a different external port, the PCP proxy SHOULD follow the PCP mapping repair procedure [RFC6887]. This can be achieved only if a full state table is maintained by the PCP proxy.
更改其外部IP地址后，PCP代理应更新其维护的映射。如果PCP服务器分配不同的外部端口，PCP代理应遵循PCP映射修复过程[RFC6887]。只有在PCP代理维护完整的状态表时，才能实现这一点。
A PCP proxy MAY handle multiple PCP servers at the same time. Each PCP server is associated with its own epoch value. PCP clients are not aware of the presence of multiple PCP servers.
一个PCP代理可以同时处理多个PCP服务器。每个PCP服务器都与其自身的历元值相关联。PCP客户端不知道存在多个PCP服务器。
Following the PCP Server Selection process [RFC7488], if several PCP servers are configured to the PCP proxy, it will contact in parallel all these PCP servers.
在PCP服务器选择过程[RFC7488]之后，如果多个PCP服务器配置为PCP代理，它将并行地联系所有这些PCP服务器。
In some contexts (e.g., PCP-controlled Carrier-Grade NATs (CGNs)), the PCP proxy MAY load-balance the PCP clients among available PCP servers. The PCP proxy MUST ensure that requests of a given PCP client are relayed to the same PCP server.
在某些上下文中（例如，PCP控制的载波级nat（cgn）），PCP代理可以在可用PCP服务器之间对PCP客户端进行负载平衡。PCP代理必须确保将给定PCP客户端的请求中继到同一PCP服务器。
The PCP proxy MAY rely on some fields (e.g., Zone-ID [PCP-ZONES]) in the PCP request to redirect the request to a given PCP server.
PCP代理可以依赖PCP请求中的某些字段（例如，区域ID[PCP-ZONES]）将请求重定向到给定PCP服务器。
The PCP proxy MUST follow the security considerations detailed in the PCP specification [RFC6887] for both the client and server side.
对于客户端和服务器端，PCP代理必须遵循PCP规范[RFC6887]中详述的安全注意事项。
Section 3.3 specifies the cases where a THIRD_PARTY option is inserted by the PCP proxy. In those cases, ways to prevent a malicious user from creating mappings on behalf of a third party must be employed as discussed in Section 13.1 of the PCP specification [RFC6887]. In particular, THIRD_PARTY options MUST NOT be enabled unless the network on which the PCP messages are to be sent is fully trusted (via physical or cryptographic security, or both) -- for example, if access control lists (ACLs) are installed on the PCP proxy, the PCP server, and the network between them so that those ACLs allow only communications from a trusted PCP proxy to the PCP server.
第3.3节规定了PCP代理插入第三方期权的情况。在这些情况下，必须采用PCP规范[RFC6887]第13.1节中讨论的防止恶意用户代表第三方创建映射的方法。特别是，除非发送PCP消息的网络完全受信任（通过物理或加密安全，或两者兼而有之），否则不得启用第三方选项，例如，如果PCP代理上安装了访问控制列表（ACL），则PCP服务器，以及它们之间的网络，以便这些ACL只允许从受信任的PCP代理到PCP服务器的通信。
A received request carrying an unknown Opcode or option SHOULD be dropped (or, in the case of an unknown option that is not mandatory to process, the option SHOULD be removed) if it is not compatible with security controls provisioned to the PCP proxy.
如果接收到的带有未知操作码或选项的请求与提供给PCP代理的安全控制不兼容，则应删除该请求（或者，如果未知选项不是必须处理的，则应删除该选项）。
The device embedding the PCP proxy MAY block PCP requests directly sent to the upstream PCP server(s). This can be enforced using ACLs.
嵌入PCP代理的设备可以阻止直接发送到上游PCP服务器的PCP请求。这可以使用ACL强制执行。
[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>.
[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>.
[PCP-ANYCAST] Kiesel, S., Penno, R., and S. Cheshire, "Port Control Protocol (PCP) Anycast Addresses", Work in Progress, draft-ietf-pcp-anycast-07, August 2015.
[PCP-ANYCAST]Kiesel，S.，Penno，R.，和S.Cheshire，“港口控制协议（PCP）选播地址”，正在进行的工作，草案-ietf-PCP-ANYCAST-072015年8月。
[PCP-DEPLOY] Boucadair, M., "Port Control Protocol (PCP) Deployment Models", Work in Progress, draft-boucadair-pcp-deployment-cases-03, July 2014.
[PCP-DEPLOY]Boucadair，M.，“端口控制协议（PCP）部署模型”，正在进行的工作，草稿-Boucadair-PCP-Deployment-cases-032014年7月。
[PCP-ZONES] Penno, R., "PCP Support for Multi-Zone Environments", Work in Progress, draft-penno-pcp-zones-01, October 2011.
[PCP-ZONES]Penno，R.，“多区域环境的PCP支持”，正在进行的工作，草稿-Penno-PCP-ZONES-01，2011年10月。
[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>.
[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>.
[RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", RFC 7291, DOI 10.17487/RFC7291, July 2014, <http://www.rfc-editor.org/info/rfc7291>.
[RFC7291]Boucadair，M.，Penno，R.，和D.Wing，“端口控制协议（PCP）的DHCP选项”，RFC 7291，DOI 10.17487/RFC7291，2014年7月<http://www.rfc-editor.org/info/rfc7291>.
[RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. Reddy, "Port Control Protocol (PCP) Server Selection", RFC 7488, DOI 10.17487/RFC7488, March 2015, <http://www.rfc-editor.org/info/rfc7488>.
[RFC7488]Boucadair，M.，Penno，R.，Wing，D.，Patil，P.，和T.Reddy，“端口控制协议（PCP）服务器选择”，RFC 7488，DOI 10.17487/RFC7488，2015年3月<http://www.rfc-editor.org/info/rfc7488>.
Acknowledgements
致谢
Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and comments.
非常感谢C.Zhou、T.Reddy和D.Thaler的评论和评论。
Special thanks to F. Dupont, who contributed to this document.
特别感谢F.杜邦对本文件的贡献。
Authors' Addresses
作者地址
Simon Perreault Jive Communications Quebec, QC Canada
Simon Perreault Jive Communications魁北克，加拿大QC
Email: sperreault@jive.com
Email: sperreault@jive.com
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com
Reinaldo Penno Cisco United States
美国思科公司
Email: repenno@cisco.com
Email: repenno@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 United States
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
Email: dwing@cisco.com
Email: dwing@cisco.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, California 95014 United States
Stuart Cheshire苹果公司位于美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
Email: cheshire@apple.com
Phone: +1 408 974 3207
Email: cheshire@apple.com