Internet Engineering Task Force (IETF) D. Wing, Ed.
Request for Comments: 6887 Cisco
Category: Standards Track S. Cheshire
ISSN: 2070-1721 Apple
M. Boucadair
France Telecom
R. Penno
Cisco
P. Selkirk
ISC
April 2013
Internet Engineering Task Force (IETF) D. Wing, Ed.
Request for Comments: 6887 Cisco
Category: Standards Track S. Cheshire
ISSN: 2070-1721 Apple
M. Boucadair
France Telecom
R. Penno
Cisco
P. Selkirk
ISC
April 2013
Port Control Protocol (PCP)
端口控制协议（PCP）
Abstract
摘要
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.
端口控制协议允许IPv6或IPv4主机控制通过网络地址转换器（NAT）或简单防火墙转换和转发传入IPv6或IPv4数据包的方式，还允许主机优化其传出NAT keepalive消息。
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/rfc6887.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6887.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括简化的BSD许可证文本，如本规范第4.e节所述
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
如简化的BSD许可证所述，信托法律条款和许可证不提供任何担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5
2.2. Supported Protocols . . . . . . . . . . . . . . . . . . . 5
2.3. Single-Homed Customer Premises Network . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Relationship between PCP Server and Its PCP-Controlled
Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Note on Fixed-Size Addresses . . . . . . . . . . . . . . . . . 10
6. Protocol Design Note . . . . . . . . . . . . . . . . . . . . . 11
7. Common Request and Response Header Format . . . . . . . . . . 13
7.1. Request Header . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Response Header . . . . . . . . . . . . . . . . . . . . . 15
7.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 19
8. General PCP Operation . . . . . . . . . . . . . . . . . . . . 20
8.1. General PCP Client: Generating a Request . . . . . . . . . 21
8.1.1. PCP Client Retransmission . . . . . . . . . . . . . . 22
8.2. General PCP Server: Processing a Request . . . . . . . . . 24
8.3. General PCP Client: Processing a Response . . . . . . . . 25
8.4. Multi-Interface Issues . . . . . . . . . . . . . . . . . . 27
8.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29
10. Introduction to MAP and PEER Opcodes . . . . . . . . . . . . . 30
10.1. For Operating a Server . . . . . . . . . . . . . . . . . . 33
10.2. For Operating a Symmetric Client/Server . . . . . . . . . 35
10.3. For Reducing NAT or Firewall Keepalive Messages . . . . . 37
10.4. For Restoring Lost Implicit TCP Dynamic Mapping State . . 38
11. MAP Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. MAP Operation Packet Formats . . . . . . . . . . . . . . . 40
11.2. Generating a MAP Request . . . . . . . . . . . . . . . . . 43
11.2.1. Renewing a Mapping . . . . . . . . . . . . . . . . . . 44
11.3. Processing a MAP Request . . . . . . . . . . . . . . . . . 44
11.4. Processing a MAP Response . . . . . . . . . . . . . . . . 48
11.5. Address Change Events . . . . . . . . . . . . . . . . . . 49
11.6. Learning the External IP Address Alone . . . . . . . . . . 50
12. PEER Opcode . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. PEER Operation Packet Formats . . . . . . . . . . . . . . 51
12.2. Generating a PEER Request . . . . . . . . . . . . . . . . 54
12.3. Processing a PEER Request . . . . . . . . . . . . . . . . 55
12.4. Processing a PEER Response . . . . . . . . . . . . . . . . 56
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5
2.2. Supported Protocols . . . . . . . . . . . . . . . . . . . 5
2.3. Single-Homed Customer Premises Network . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Relationship between PCP Server and Its PCP-Controlled
Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Note on Fixed-Size Addresses . . . . . . . . . . . . . . . . . 10
6. Protocol Design Note . . . . . . . . . . . . . . . . . . . . . 11
7. Common Request and Response Header Format . . . . . . . . . . 13
7.1. Request Header . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Response Header . . . . . . . . . . . . . . . . . . . . . 15
7.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 19
8. General PCP Operation . . . . . . . . . . . . . . . . . . . . 20
8.1. General PCP Client: Generating a Request . . . . . . . . . 21
8.1.1. PCP Client Retransmission . . . . . . . . . . . . . . 22
8.2. General PCP Server: Processing a Request . . . . . . . . . 24
8.3. General PCP Client: Processing a Response . . . . . . . . 25
8.4. Multi-Interface Issues . . . . . . . . . . . . . . . . . . 27
8.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29
10. Introduction to MAP and PEER Opcodes . . . . . . . . . . . . . 30
10.1. For Operating a Server . . . . . . . . . . . . . . . . . . 33
10.2. For Operating a Symmetric Client/Server . . . . . . . . . 35
10.3. For Reducing NAT or Firewall Keepalive Messages . . . . . 37
10.4. For Restoring Lost Implicit TCP Dynamic Mapping State . . 38
11. MAP Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. MAP Operation Packet Formats . . . . . . . . . . . . . . . 40
11.2. Generating a MAP Request . . . . . . . . . . . . . . . . . 43
11.2.1. Renewing a Mapping . . . . . . . . . . . . . . . . . . 44
11.3. Processing a MAP Request . . . . . . . . . . . . . . . . . 44
11.4. Processing a MAP Response . . . . . . . . . . . . . . . . 48
11.5. Address Change Events . . . . . . . . . . . . . . . . . . 49
11.6. Learning the External IP Address Alone . . . . . . . . . . 50
12. PEER Opcode . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. PEER Operation Packet Formats . . . . . . . . . . . . . . 51
12.2. Generating a PEER Request . . . . . . . . . . . . . . . . 54
12.3. Processing a PEER Request . . . . . . . . . . . . . . . . 55
12.4. Processing a PEER Response . . . . . . . . . . . . . . . . 56
13. Options for MAP and PEER Opcodes . . . . . . . . . . . . . . . 57
13.1. THIRD_PARTY Option for MAP and PEER Opcodes . . . . . . . 57
13.2. PREFER_FAILURE Option for MAP Opcode . . . . . . . . . . . 59
13.3. FILTER Option for MAP Opcode . . . . . . . . . . . . . . . 61
14. Rapid Recovery . . . . . . . . . . . . . . . . . . . . . . . . 63
14.1. ANNOUNCE Opcode . . . . . . . . . . . . . . . . . . . . . 64
14.1.1. ANNOUNCE Operation . . . . . . . . . . . . . . . . . . 65
14.1.2. Generating and Processing a Solicited ANNOUNCE
Message . . . . . . . . . . . . . . . . . . . . . . . 65
14.1.3. Generating and Processing an Unsolicited ANNOUNCE
Message . . . . . . . . . . . . . . . . . . . . . . . 66
14.2. PCP Mapping Update . . . . . . . . . . . . . . . . . . . . 67
15. Mapping Lifetime and Deletion . . . . . . . . . . . . . . . . 69
15.1. Lifetime Processing for the MAP Opcode . . . . . . . . . . 71
16. Implementation Considerations . . . . . . . . . . . . . . . . 72
16.1. Implementing MAP with EDM Port-Mapping NAT . . . . . . . . 72
16.2. Lifetime of Explicit and Implicit Dynamic Mappings . . . . 72
16.3. PCP Failure Recovery . . . . . . . . . . . . . . . . . . . 72
16.3.1. Recreating Mappings . . . . . . . . . . . . . . . . . 73
16.3.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 73
16.3.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 74
16.4. Source Address Replicated in PCP Header . . . . . . . . . 75
16.5. State Diagram . . . . . . . . . . . . . . . . . . . . . . 76
17. Deployment Considerations . . . . . . . . . . . . . . . . . . 77
17.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 77
17.2. Mapping Quota . . . . . . . . . . . . . . . . . . . . . . 77
18. Security Considerations . . . . . . . . . . . . . . . . . . . 78
18.1. Simple Threat Model . . . . . . . . . . . . . . . . . . . 78
18.1.1. Attacks Considered . . . . . . . . . . . . . . . . . . 79
18.1.2. Deployment Examples Supporting the Simple Threat
Model . . . . . . . . . . . . . . . . . . . . . . . . 79
18.2. Advanced Threat Model . . . . . . . . . . . . . . . . . . 80
18.3. Residual Threats . . . . . . . . . . . . . . . . . . . . . 80
18.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 80
18.3.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 81
18.3.3. Mapping Theft . . . . . . . . . . . . . . . . . . . . 81
18.3.4. Attacks against Server Discovery . . . . . . . . . . . 81
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
19.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 82
19.2. Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 82
19.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 82
19.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 82
20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
21.1. Normative References . . . . . . . . . . . . . . . . . . . 84
21.2. Informative References . . . . . . . . . . . . . . . . . . 84
Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . . 87
13. Options for MAP and PEER Opcodes . . . . . . . . . . . . . . . 57
13.1. THIRD_PARTY Option for MAP and PEER Opcodes . . . . . . . 57
13.2. PREFER_FAILURE Option for MAP Opcode . . . . . . . . . . . 59
13.3. FILTER Option for MAP Opcode . . . . . . . . . . . . . . . 61
14. Rapid Recovery . . . . . . . . . . . . . . . . . . . . . . . . 63
14.1. ANNOUNCE Opcode . . . . . . . . . . . . . . . . . . . . . 64
14.1.1. ANNOUNCE Operation . . . . . . . . . . . . . . . . . . 65
14.1.2. Generating and Processing a Solicited ANNOUNCE
Message . . . . . . . . . . . . . . . . . . . . . . . 65
14.1.3. Generating and Processing an Unsolicited ANNOUNCE
Message . . . . . . . . . . . . . . . . . . . . . . . 66
14.2. PCP Mapping Update . . . . . . . . . . . . . . . . . . . . 67
15. Mapping Lifetime and Deletion . . . . . . . . . . . . . . . . 69
15.1. Lifetime Processing for the MAP Opcode . . . . . . . . . . 71
16. Implementation Considerations . . . . . . . . . . . . . . . . 72
16.1. Implementing MAP with EDM Port-Mapping NAT . . . . . . . . 72
16.2. Lifetime of Explicit and Implicit Dynamic Mappings . . . . 72
16.3. PCP Failure Recovery . . . . . . . . . . . . . . . . . . . 72
16.3.1. Recreating Mappings . . . . . . . . . . . . . . . . . 73
16.3.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 73
16.3.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 74
16.4. Source Address Replicated in PCP Header . . . . . . . . . 75
16.5. State Diagram . . . . . . . . . . . . . . . . . . . . . . 76
17. Deployment Considerations . . . . . . . . . . . . . . . . . . 77
17.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 77
17.2. Mapping Quota . . . . . . . . . . . . . . . . . . . . . . 77
18. Security Considerations . . . . . . . . . . . . . . . . . . . 78
18.1. Simple Threat Model . . . . . . . . . . . . . . . . . . . 78
18.1.1. Attacks Considered . . . . . . . . . . . . . . . . . . 79
18.1.2. Deployment Examples Supporting the Simple Threat
Model . . . . . . . . . . . . . . . . . . . . . . . . 79
18.2. Advanced Threat Model . . . . . . . . . . . . . . . . . . 80
18.3. Residual Threats . . . . . . . . . . . . . . . . . . . . . 80
18.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 80
18.3.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 81
18.3.3. Mapping Theft . . . . . . . . . . . . . . . . . . . . 81
18.3.4. Attacks against Server Discovery . . . . . . . . . . . 81
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
19.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 82
19.2. Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 82
19.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 82
19.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 82
20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
21.1. Normative References . . . . . . . . . . . . . . . . . . . 84
21.2. Informative References . . . . . . . . . . . . . . . . . . 84
Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . . 87
The Port Control Protocol (PCP) provides a mechanism to control how incoming packets are forwarded by upstream devices such as Network Address Translator IPv6/IPv4 (NAT64), Network Address Translator IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices, and a mechanism to reduce application keepalive traffic. PCP is designed to be implemented in the context of Carrier-Grade NATs (CGNs) and small NATs (e.g., residential NATs), as well as with dual-stack and IPv6-only Customer Premises Equipment (CPE) routers, and all of the currently known transition scenarios towards IPv6-only CPE routers. PCP allows hosts to operate servers for a long time (e.g., a network-attached home security camera) or a short time (e.g., while playing a game or on a phone call) when behind a NAT device, including when behind a CGN operated by their Internet service provider or an IPv6 firewall integrated in their CPE router.
端口控制协议（PCP）提供了一种机制，用于控制网络地址转换器IPv6/IPv4（NAT64）、网络地址转换器IPv4/IPv4（NAT44）、IPv6和IPv4防火墙设备等上游设备转发传入数据包的方式，以及一种减少应用程序保持通信量的机制。PCP设计用于在运营商级NAT（CGN）和小型NAT（例如住宅NAT）的环境中实施，以及使用双栈和仅限IPv6的客户场所设备（CPE）路由器，以及所有目前已知的向仅限IPv6的CPE路由器过渡的场景。PCP允许主机在NAT设备后长时间（例如，连接网络的家庭安全摄像头）或短时间（例如，在玩游戏或打电话时）运行服务器，包括在其互联网服务提供商操作的CGN或集成在其CPE路由器中的IPv6防火墙后。
PCP allows applications to create mappings from an external IP address, protocol, and port to an internal IP address, protocol, and port. These mappings are required for successful inbound communications destined to machines located behind a NAT or a firewall.
PCP允许应用程序创建从外部IP地址、协议和端口到内部IP地址、协议和端口的映射。这些映射对于发送到位于NAT或防火墙后面的计算机的成功入站通信是必需的。
After creating a mapping for incoming connections, it is necessary to inform remote computers about the IP address, protocol, and port for the incoming connection. This is usually done in an application-specific manner. For example, a computer game might use a rendezvous server specific to that game (or specific to that game developer), a SIP phone would use a SIP proxy, and a client using DNS-Based Service Discovery [RFC6763] would use DNS Update [RFC2136] [RFC3007]. PCP does not provide this rendezvous function. The rendezvous function may support IPv4, IPv6, or both. Depending on that support and the application's support of IPv4 or IPv6, the PCP client may need an IPv4 mapping, an IPv6 mapping, or both.
为传入连接创建映射后，有必要将传入连接的IP地址、协议和端口通知远程计算机。这通常是以特定于应用程序的方式完成的。例如，计算机游戏可能使用特定于该游戏（或特定于该游戏开发者）的会合服务器，SIP电话将使用SIP代理，使用基于DNS的服务发现[RFC6763]的客户端将使用DNS更新[RFC2136][RFC3007]。PCP不提供此会合功能。集合功能可能支持IPv4、IPv6或两者。根据该支持以及应用程序对IPv4或IPv6的支持，PCP客户端可能需要IPv4映射、IPv6映射或两者兼而有之。
Many NAT-friendly applications send frequent application-level messages to ensure that their session will not be timed out by a NAT. These are commonly called "NAT keepalive" messages, even though they are not sent to the NAT itself (rather, they are sent 'through' the NAT). These applications can reduce the frequency of such NAT keepalive messages by using PCP to learn (and influence) the NAT mapping lifetime. This helps reduce bandwidth on the subscriber's access network, traffic to the server, and battery consumption on mobile devices.
许多NAT友好型应用程序频繁发送应用程序级消息，以确保其会话不会被NAT超时。这些消息通常被称为“NAT keepalive”，即使它们不是发送到NAT本身（而是“通过”NAT发送）。这些应用程序可以通过使用PCP学习（并影响）NAT映射生存期来减少此类NAT保持消息的频率。这有助于减少用户接入网络上的带宽、服务器的流量以及移动设备上的电池消耗。
Many NATs and firewalls include Application Layer Gateways (ALGs) to create mappings for applications that establish additional streams or accept incoming connections. ALGs incorporated into NATs may also
许多NAT和防火墙包括应用层网关（ALG），用于为建立附加流或接受传入连接的应用程序创建映射。纳入NAT的ALG也可能
modify the application payload. Industry experience has shown that these ALGs are detrimental to protocol evolution. PCP allows an application to create its own mappings in NATs and firewalls, reducing the incentive to deploy ALGs in NATs and firewalls.
修改应用程序负载。行业经验表明，这些ALG不利于协议演进。PCP允许应用程序在NAT和防火墙中创建自己的映射，从而减少在NAT和防火墙中部署ALG的动机。
PCP can be used in various deployment scenarios, including:
PCP可用于各种部署场景，包括：
o Basic NAT [RFC3022]
o 基本NAT[RFC3022]
o Network Address and Port Translation [RFC3022], such as commonly deployed in residential NAT devices
o 网络地址和端口转换[RFC3022]，例如通常部署在住宅NAT设备中
o Carrier-Grade NAT [RFC6888]
o 承运人级NAT[RFC6888]
o Dual-Stack Lite (DS-Lite) [RFC6333]
o 双栈精简版（DS精简版）[RFC6333]
o NAT that is Layer-2 Aware [L2NAT]
o 第二层感知的NAT[L2NAT]
o Dual-Stack Extra Lite [RFC6619]
o 双栈额外精简版[RFC6619]
o NAT64, both Stateless [RFC6145] and Stateful [RFC6146]
o NAT64，无状态[RFC6145]和有状态[RFC6146]
o IPv4 and IPv6 simple firewall control [RFC6092]
o IPv4和IPv6简单防火墙控制[RFC6092]
o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]
o IPv6到IPv6网络前缀转换（NPTv6）[RFC6296]
The PCP Opcodes defined in this document are designed to support transport-layer protocols that use a 16-bit port number (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], and Datagram Congestion Control Protocol (DCCP) [RFC4340]). Protocols that do not use a port number (e.g., Resource Reservation Protocol (RSVP), IP Encapsulating Security Payload (ESP) [RFC4303], ICMP, and ICMPv6) are supported for IPv4 firewall, IPv6 firewall, and NPTv6 functions, but are out of scope for any NAT functions.
本文档中定义的PCP操作码旨在支持使用16位端口号的传输层协议（例如TCP、UDP、流控制传输协议（SCTP）[RFC4960]和数据报拥塞控制协议（DCCP）[RFC4340]）。IPv4防火墙、IPv6防火墙和NPTv6功能支持不使用端口号的协议（例如，资源保留协议（RSVP）、IP封装安全有效负载（ESP）[RFC4303]、ICMP和ICMPv6），但不适用于任何NAT功能。
PCP assumes a single-homed IP address model. That is, for a given IP address of a host, only one default route exists to reach other hosts on the Internet from that source IP address. This is important because after a PCP mapping is created and an inbound packet (e.g., TCP SYN) is rewritten and delivered to a host, the outbound response
PCP采用单主IP地址模型。也就是说，对于主机的给定IP地址，只有一条默认路由存在，可以从该源IP地址到达Internet上的其他主机。这一点很重要，因为在创建PCP映射并重写入站数据包（例如TCP SYN）并将其交付给主机之后，出站响应
(e.g., TCP SYNACK) has to go through the same (reverse) path so it passes through the same NAT to have the necessary inverse rewrite performed. This restriction exists because otherwise there would need to be a PCP-enabled NAT for every egress (because the host could not reliably determine which egress path packets would take), and the client would need to be able to reliably make the same internal/ external mapping in every NAT gateway, which in general is not possible (because the other NATs might already have the necessary external port mapped to another host).
（例如，TCP SYNACK）必须通过相同的（反向）路径，以便通过相同的NAT执行必要的反向重写。存在此限制的原因是，否则每个出口都需要一个启用PCP的NAT（因为主机无法可靠地确定数据包将采用哪个出口路径），并且客户端需要能够在每个NAT网关中可靠地进行相同的内部/外部映射，这通常是不可能的（因为其他NAT可能已经将必要的外部端口映射到另一台主机）。
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]中的描述进行解释。
Internal Host: A host served by a NAT gateway, or protected by a firewall. This is the host that will receive incoming traffic resulting from a PCP mapping request, or the host that initiated an implicit dynamic outbound mapping (e.g., by sending a TCP SYN) across a firewall or a NAT.
内部主机：由NAT网关提供服务或受防火墙保护的主机。这是将接收由PCP映射请求产生的传入流量的主机，或通过防火墙或NAT启动隐式动态出站映射（例如，通过发送TCP SYN）的主机。
Remote Peer Host: A host with which an internal host is communicating. This can include another internal host (or even the same internal host); if a NAT is involved, the NAT would need to hairpin the traffic [RFC4787].
远程对等主机：内部主机与之通信的主机。这可能包括另一个内部主机（甚至是同一个内部主机）；如果涉及NAT，NAT将需要对流量进行发夹[RFC4787]。
Internal Address: The address of an internal host served by a NAT gateway or protected by a firewall.
内部地址：由NAT网关提供服务或受防火墙保护的内部主机的地址。
External Address: The address of an internal host as seen by other remote peers on the Internet with which the internal host is communicating, after translation by any NAT gateways on the path. An external address is generally a public routable (i.e., non-private) address. In the case of an internal host protected by a pure firewall, with no address translation on the path, its external address is the same as its internal address.
外部地址：通过路径上的任何NAT网关转换后，内部主机与之通信的Internet上其他远程对等方看到的内部主机的地址。外部地址通常是公共可路由（即非私有）地址。对于受纯防火墙保护的内部主机，路径上没有地址转换，其外部地址与其内部地址相同。
Endpoint-Dependent Mapping (EDM): A term applied to NAT operation where an implicit mapping created by outgoing traffic (e.g., TCP SYN) from a single internal address, protocol, and port to different remote peers and ports may be assigned different external ports, and a subsequent PCP mapping request for that
端点相关映射（EDM）：应用于NAT操作的一个术语，其中由传出通信量（例如TCP SYN）创建的从单个内部地址、协议和端口到不同远程对等方和端口的隐式映射可分配给不同的外部端口，以及该端口的后续PCP映射请求
internal address, protocol, and port may be assigned yet another different external port. This term encompasses both Address-Dependent Mapping and Address and Port-Dependent Mapping [RFC4787].
内部地址、协议和端口可以分配给另一个不同的外部端口。该术语包括地址相关映射和地址及端口相关映射[RFC4787]。
Endpoint-Independent Mapping (EIM): A term applied to NAT operation where all mappings from a single internal address, protocol, and port to different remote peers and ports are all assigned the same external address and port.
端点独立映射（EIM）：应用于NAT操作的一个术语，其中从单个内部地址、协议和端口到不同远程对等点和端口的所有映射都分配给相同的外部地址和端口。
Remote Peer Address: The address of a remote peer, as seen by the internal host. A remote address is generally a publicly routable address. In the case of a remote peer that is itself served by a NAT gateway, the remote address may in fact be the remote peer's external address, but since this remote translation is generally invisible to software running on the internal host, the distinction can safely be ignored for the purposes of this document.
远程对等地址：内部主机看到的远程对等地址。远程地址通常是可公开路由的地址。对于本身由NAT网关提供服务的远程对等方，远程地址实际上可能是远程对等方的外部地址，但由于内部主机上运行的软件通常看不到该远程转换，因此出于本文档的目的，可以安全地忽略该区别。
Third Party: In the common case, an internal host manages its own mappings using PCP requests, and the internal address of those mappings is the same as the source IP address of the PCP request packet.
第三方：在常见情况下，内部主机使用PCP请求管理自己的映射，这些映射的内部地址与PCP请求数据包的源IP地址相同。
In the case where one device is managing mappings on behalf of some other device that does not implement PCP, the presence of the THIRD_PARTY option in the MAP request signifies that the specified address, rather than the source IP address of the PCP request packet, should be used as the internal address for the mapping.
在一个设备代表未实现PCP的某个其他设备管理映射的情况下，映射请求中存在第三方选项表示指定的地址（而不是PCP请求数据包的源IP地址）应用作映射的内部地址。
Mapping, Port Mapping, Port Forwarding: A NAT mapping creates a relationship between an internal IP address, protocol, and port, and an external IP address, protocol, and port. More specifically, it creates a translation rule where packets destined *to* the external IP address, protocol, and port have their destination address and port translated to the internal address and port, and conversely, packets *from* the internal IP address, protocol, and port have their source address and port translated to the external address and port. In the case of a pure firewall, the "mapping" is the identity function, translating an internal IP address, protocol, and port number to the same external IP address, protocol, and port number. Firewall filtering, applied in addition to that identity mapping function, is separate from the mapping itself.
映射、端口映射、端口转发：NAT映射创建内部IP地址、协议和端口与外部IP地址、协议和端口之间的关系。更具体地说，它创建了一个转换规则，其中目的地*到*外部IP地址、协议和端口的数据包将其目的地地址和端口转换为内部地址和端口，反之，来自*内部IP地址、协议的数据包，和端口将其源地址和端口转换为外部地址和端口。在纯防火墙的情况下，“映射”是身份功能，将内部IP地址、协议和端口号转换为相同的外部IP地址、协议和端口号。除了身份映射功能之外，应用的防火墙过滤与映射本身是分开的。
Mapping Types: There are three dimensions to classifying mapping types: how they are created (implicitly/explicitly), their primary purpose (outbound/inbound), and how they are deleted (dynamic/static). Implicit mappings are created as a side effect of some other operation; explicit mappings are created by a mechanism explicitly dealing with mappings. Outbound mappings exist primarily to facilitate outbound communication; inbound mappings exist primarily to facilitate inbound communication. Dynamic mappings are deleted when their lifetime expires, or through other protocol action; static mappings are permanent until the user chooses to delete them.
映射类型：映射类型的分类有三个维度：如何创建（隐式/显式）、主要用途（出站/入站）以及如何删除（动态/静态）。隐式映射是作为其他操作的副作用创建的；显式映射由显式处理映射的机制创建。出站映射的存在主要是为了促进出站通信；入站映射的存在主要是为了方便入站通信。动态映射在其生存期到期时或通过其他协议操作删除；静态映射是永久的，直到用户选择删除它们。
* Implicit dynamic mappings are created implicitly as a side effect of traffic such as an outgoing TCP SYN or outgoing UDP packet. Such packets were not originally designed explicitly for creating NAT (or firewall) state, but they can have that effect when they pass through a NAT (or firewall) device. Implicit dynamic mappings usually have a finite lifetime, though this lifetime is generally not known to the client using them.
* 隐式动态映射是作为诸如传出TCP SYN或传出UDP数据包等流量的副作用隐式创建的。这些数据包最初并不是专门为创建NAT（或防火墙）状态而设计的，但当它们通过NAT（或防火墙）设备时，它们可以产生这种效果。隐式动态映射通常有一个有限的生存期，尽管使用它们的客户端通常不知道这个生存期。
* Explicit dynamic mappings are created as a result of explicit PCP MAP and PEER requests. Like a DHCP address lease, explicit dynamic mappings have a finite lifetime, and this lifetime is communicated to the client. As with a DHCP address lease, if the client wants a mapping to persist the client must prove that it is still present by periodically renewing the mapping to prevent it from expiring. If a PCP client goes away, then any mappings it created will be automatically cleaned up when they expire.
* 显式动态映射是显式PCP映射和对等请求的结果。与DHCP地址租约一样，显式动态映射有一个有限的生存期，并且这个生存期将与客户端通信。与DHCP地址租约一样，如果客户端希望映射持久化，则客户端必须通过定期更新映射来证明映射仍然存在，以防止映射过期。如果PCP客户端消失，那么它创建的任何映射在过期时都将自动清除。
* Explicit static mappings are created by manual configuration (e.g., via command-line interface or other user interface) and persist until the user changes that manual configuration.
* 显式静态映射是通过手动配置（例如，通过命令行界面或其他用户界面）创建的，并一直保持到用户更改手动配置为止。
Both implicit and explicit dynamic mappings are dynamic in the sense that they are created on demand, as requested (implicitly or explicitly) by the internal host, and have a lifetime. After the lifetime, the mapping is deleted unless the lifetime is extended by action by the internal host (e.g., sending more traffic or sending another PCP request).
隐式和显式动态映射都是动态的，因为它们是根据内部主机的请求（隐式或显式）按需创建的，并且具有生命周期。在生存期之后，映射将被删除，除非通过内部主机的操作延长生存期（例如，发送更多流量或发送另一个PCP请求）。
Static mappings are, by their nature, always explicit. Static mappings differ from explicit dynamic mappings in that their lifetime is effectively infinite (they exist until manually removed), but otherwise they behave exactly the same as explicit MAP mappings.
静态映射本质上总是显式的。静态映射与显式动态映射的不同之处在于，它们的生命周期实际上是无限的（在手动删除之前它们一直存在），但在其他方面，它们的行为与显式映射完全相同。
While all mappings are, by necessity, bidirectional (most Internet communication requires information to flow in both directions for successful operation), when talking about mappings, it can be helpful to identify them loosely according to their 'primary' purpose.
虽然所有映射都是双向的（大多数Internet通信需要信息在两个方向上流动才能成功运行），但在讨论映射时，根据它们的“主要”用途松散地识别它们可能会有所帮助。
* Outbound mappings exist primarily to enable outbound communication. For example, when a host calls connect() to make an outbound connection, a NAT gateway will create an implicit dynamic outbound mapping to facilitate that outbound communication.
* 出站映射的存在主要是为了支持出站通信。例如，当主机调用connect（）进行出站连接时，NAT网关将创建一个隐式动态出站映射以促进出站通信。
* Inbound mappings exist primarily to enable listening servers to receive inbound connections. Generally, when a client calls listen() to listen for inbound connections, a NAT gateway will not implicitly create any mapping to facilitate that inbound communication. A PCP MAP request can be used explicitly to create a dynamic inbound mapping to enable the desired inbound communication.
* 入站映射的存在主要是为了使侦听服务器能够接收入站连接。通常，当客户端调用listen（）来侦听入站连接时，NAT网关不会隐式创建任何映射以促进入站通信。PCP映射请求可显式用于创建动态入站映射，以启用所需的入站通信。
Explicit static (manual) mappings and explicit dynamic (MAP) mappings both allow internal hosts to receive inbound traffic that is not in direct response to any immediately preceding outbound communication (i.e., to allow internal hosts to operate a "server" that is accessible to other hosts on the Internet).
显式静态（手动）映射和显式动态（MAP）映射都允许内部主机接收不直接响应任何前一次出站通信的入站流量（即，允许内部主机操作Internet上其他主机可以访问的“服务器”）。
PCP Client: A PCP software instance responsible for issuing PCP requests to a PCP server. Several independent PCP clients can exist on the same host. Several PCP clients can be located in the same local network. A PCP client can issue PCP requests on behalf of a third-party device for which it is authorized to do so. An interworking function from Universal Plug and Play Internet Gateway Device (UPnP IGDv1 [IGDv1]) to PCP is another example of a PCP client. A PCP server in a NAT gateway that is itself a client of another NAT gateway (nested NAT) may itself act as a PCP client to the upstream NAT.
PCP客户端：负责向PCP服务器发出PCP请求的PCP软件实例。同一主机上可以存在多个独立的PCP客户端。多个PCP客户端可以位于同一个本地网络中。PCP客户端可以代表其有权发出PCP请求的第三方设备发出PCP请求。从通用即插即用互联网网关设备（UPnP-IGDv1[IGDv1]）到PCP的互通功能是PCP客户端的另一个示例。NAT网关中本身是另一NAT网关（嵌套NAT）的客户端的PCP服务器本身可以充当上游NAT的PCP客户端。
PCP-Controlled Device: A NAT or firewall that controls or rewrites packet flows between internal hosts and remote peer hosts. PCP manages the mappings on this device.
PCP控制设备：控制或重写内部主机和远程对等主机之间的数据包流的NAT或防火墙。PCP管理此设备上的映射。
PCP Server: A PCP software instance that resides on the PCP-Controlled Device that receives PCP requests from the PCP client and creates appropriate state in response to that request.
PCP服务器：驻留在PCP控制设备上的PCP软件实例，该设备接收来自PCP客户端的PCP请求，并创建相应的状态以响应该请求。
Subscriber: The unit of billing for a commercial ISP. A subscriber may have a single IP address from the commercial ISP (which can be shared among multiple hosts using a NAT gateway, thereby making them appear to be a single host to the ISP) or may have multiple IP addresses provided by the commercial ISP. In either case, the IP address or addresses provided by the ISP may themselves be further translated by a Carrier-Grade NAT (CGN) operated by the ISP.
订户：商业ISP的计费单位。订户可以具有来自商业ISP的单个IP地址（可以使用NAT网关在多个主机之间共享，从而使它们看起来是ISP的单个主机），或者可以具有由商业ISP提供的多个IP地址。在任一情况下，ISP提供的IP地址或多个地址本身可由ISP操作的载波级NAT（CGN）进一步翻译。
The PCP server receives and responds to PCP requests. The PCP server functionality is typically a capability of a NAT or firewall device, as shown in Figure 1. It is also possible for the PCP functionality to be provided by some other device, which communicates with the actual NAT(s) or firewall(s) via some other proprietary mechanism, as long as from the PCP client's perspective such split operation is indistinguishable from the integrated case.
PCP服务器接收并响应PCP请求。PCP服务器功能通常是NAT或防火墙设备的功能，如图1所示。PCP功能也可能由其他一些设备提供，这些设备通过其他一些专有机制与实际NAT或防火墙通信，只要从PCP客户端的角度来看，这种拆分操作与集成情况无法区分。
+-----------------+
+------------+ | NAT or firewall |
| PCP client |-<network>-+ with +---<Internet>
+------------+ | PCP server |
+-----------------+
+-----------------+
+------------+ | NAT or firewall |
| PCP client |-<network>-+ with +---<Internet>
+------------+ | PCP server |
+-----------------+
Figure 1: PCP-Enabled NAT or Firewall
图1：启用PCP的NAT或防火墙
A NAT or firewall device, between the PCP client and the Internet, might implement simple or advanced firewall functionality. This may be a side effect of the technology implemented by the device (e.g., a network address and port translator, by virtue of its port rewriting, normally requires connections to be initiated from an inside host towards the Internet), or this might be an explicit firewall policy to deny unsolicited traffic from the Internet. Some firewall devices deny certain unsolicited traffic from the Internet (e.g., TCP, UDP to most ports) but allow certain other unsolicited traffic from the Internet (e.g., UDP port 500 and IP ESP) [RFC6092]. Such default filtering (or lack thereof) is out of scope of PCP itself. If a client device wants to receive traffic and supports PCP, and does not possess prior knowledge of such default filtering policy, it SHOULD use PCP to request the necessary mappings to receive the desired traffic.
PCP客户端和Internet之间的NAT或防火墙设备可能实现简单或高级防火墙功能。这可能是由设备实现的技术的副作用（例如，网络地址和端口转换器，由于其端口重写，通常需要从内部主机向互联网发起连接），或者这可能是一个明确的防火墙策略，以拒绝来自互联网的未经请求的流量。一些防火墙设备拒绝来自Internet的某些未经请求的流量（例如，TCP、UDP到大多数端口），但允许来自Internet的某些其他未经请求的流量（例如，UDP端口500和IP ESP）[RFC6092]。这种默认过滤（或缺少过滤）超出了PCP本身的范围。如果客户端设备希望接收流量并支持PCP，并且事先不知道此类默认过滤策略，则应使用PCP请求必要的映射以接收所需流量。
For simplicity in building and parsing request and response packets, PCP always uses fixed-size 128-bit IP address fields for both IPv6 addresses and IPv4 addresses.
为简化构建和解析请求和响应数据包，PCP始终为IPv6地址和IPv4地址使用固定大小的128位IP地址字段。
When the address field holds an IPv6 address, the fixed-size 128-bit IP address field holds the IPv6 address stored as is.
当地址字段保存IPv6地址时，固定大小的128位IP地址字段保存按原样存储的IPv6地址。
When the address field holds an IPv4 address, an IPv4-mapped IPv6 address [RFC4291] is used (::ffff:0:0/96). This has the first 80 bits set to zero and the next 16 set to one, while its last 32 bits are filled with the IPv4 address. This is unambiguously distinguishable from a native IPv6 address, because an IPv4-mapped IPv6 address [RFC4291] would not be valid for a mapping.
当地址字段包含IPv4地址时，将使用IPv4映射的IPv6地址[RFC4291]（：：ffff:0:0/96）。它的前80位设置为零，下16位设置为1，而其最后32位由IPv4地址填充。这与本机IPv6地址明显不同，因为IPv4映射的IPv6地址[RFC4291]对于映射无效。
When checking for an IPv4-mapped IPv6 address, all of the first 96 bits MUST be checked for the pattern -- it is not sufficient to check for ones in bits 81-96.
在检查IPv4映射的IPv6地址时，必须检查所有前96位的模式——仅检查位81-96中的模式是不够的。
The all-zeros IPv6 address MUST be expressed by filling the fixed-size 128-bit IP address field with all zeros (::).
必须通过使用全零（：）填充固定大小的128位IP地址字段来表示全零IPv6地址。
The all-zeros IPv4 address MUST be expressed by 80 bits of zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0).
全零IPv4地址必须由80位零、16位1和32位零表示（：：ffff:0:0）。
PCP can be viewed as a request/response protocol, much like many other UDP-based request/response protocols, and can be implemented perfectly well as such. It can also be viewed as what might be called a hint/notification protocol, and this observation can help simplify implementations.
PCP可以看作是一种请求/响应协议，与许多其他基于UDP的请求/响应协议非常相似，并且可以很好地实现。它也可以被看作是一个提示/通知协议，这种观察有助于简化实现。
Rather than viewing the message streams between PCP client and PCP server as following a strict request/response pattern, where every response is associated with exactly one request, the message flows can be viewed as two somewhat independent streams carrying information in opposite directions:
与按照严格的请求/响应模式查看PCP客户端和PCP服务器之间的消息流（其中每个响应仅与一个请求关联）不同，消息流可以被视为两个相互独立的流，在相反的方向上承载信息：
o A stream of hints flowing from PCP client to PCP server, where the client indicates to the server what it would like the state of its mappings to be, and
o 从PCP客户机流向PCP服务器的提示流，其中客户机向服务器指示它希望其映射的状态，以及
o A stream of notifications flowing from PCP server to PCP client, where the server informs the clients what the state of its mappings actually is.
o 从PCP服务器流向PCP客户端的通知流，其中服务器通知客户端其映射的实际状态。
To an extent, some of this approach is required anyway in a UDP-based request/response protocol, since UDP packets can be lost, duplicated, or reordered.
在某种程度上，这种方法在基于UDP的请求/响应协议中是必需的，因为UDP数据包可能丢失、复制或重新排序。
In this view of the protocol, the client transmits hints to the server at various intervals signaling its desires, and the server transmits notifications to the client signaling the actual state of its mappings. These two message flows are loosely correlated in that a client request (hint) usually elicits a server response (notification), but only loosely, in that a client request may result in no server response (in the case of packet loss), and a server response may be generated gratuitously without an immediately preceding client request (in the case where server configuration change, e.g., change of external IP address on a NAT gateway, results in a change of mapping state).
在该协议的视图中，客户端以不同的间隔向服务器发送提示，表示其期望，服务器向客户端发送通知，表示其映射的实际状态。这两个消息流是松散相关的，因为客户端请求（提示）通常会引发服务器响应（通知），但只是松散相关，因为客户端请求可能不会导致服务器响应（在数据包丢失的情况下），并且服务器响应可能会免费生成，而不需要前面的客户端请求（在服务器配置更改（例如，NAT网关上的外部IP地址更改）导致映射状态更改的情况下）。
The exact times that client requests are sent are influenced by a client timing state machine taking into account whether (i) the client has not yet received a response from the server for a prior request (retransmission), or (ii) the client has previously received a response from the server saying how long the indicated mapping would remain active (renewal). This design philosophy is the reason why PCP's retransmissions and renewals are exactly the same packet on the wire. Typically, retransmissions are sent with exponentially increasing intervals as the client waits for the server to respond, whereas renewals are sent with exponentially decreasing intervals as the expiry time approaches, but, from the server's point of view, both packets are identical, and both signal the client's desire that the stated mapping exist or continue to exist.
客户机请求发送的确切时间受客户机定时状态机的影响，考虑到（i）客户机是否尚未收到服务器对先前请求的响应（重传），或（ii）客户机以前收到服务器的响应，说明指示的映射将保持活动（续订）多长时间。这种设计理念正是PCP的重新传输和更新与线路上的数据包完全相同的原因。通常，当客户端等待服务器响应时，以指数级递增的间隔发送重传，而当到期时间接近时，以指数级递减的间隔发送续订，但从服务器的角度来看，这两个数据包是相同的，两者都表示客户希望所述映射存在或继续存在。
A PCP server usually sends responses as a direct result of client requests, but not always. For example, if a server is too overloaded to respond, it is allowed to silently ignore a request message and let the client retransmit. Also, if external factors cause a NAT gateway or firewall's configuration to change, then the PCP server can send unsolicited responses to clients informing them of the new state of their mappings. Such reconfigurations are expected to be rare, because of the disruption they can cause to clients, but should they happen, PCP provides a way for servers to communicate the new state to clients promptly, without having to wait for the next periodic renewal request.
PCP服务器通常作为客户端请求的直接结果发送响应，但并不总是这样。例如，如果服务器过载而无法响应，则允许它以静默方式忽略请求消息，并让客户端重新传输。此外，如果外部因素导致NAT网关或防火墙的配置发生更改，则PCP服务器可以向客户端发送未经请求的响应，通知它们映射的新状态。由于这种重新配置可能会对客户端造成中断，因此预计这种重新配置很少见，但如果发生这种情况，PCP将为服务器提供一种方法，使其能够及时向客户端传达新状态，而无需等待下一次定期续订请求。
This design goal helps explain why PCP request and response messages have no transaction ID, because such a transaction ID is unnecessary, and would unnecessarily limit the protocol and unnecessarily complicate implementations. A PCP server response (i.e., notification) is self-describing and complete. It communicates the internal and external addresses, protocol, and ports for a mapping, and its remaining lifetime. If the client does in fact currently want such a mapping to exist, then it can identify the mapping in question from the internal address, protocol, and port, and update its state to reflect the current external address and port, and
这个设计目标有助于解释为什么PCP请求和响应消息没有事务ID，因为这样的事务ID是不必要的，并且会不必要地限制协议，使实现不必要地复杂化。PCP服务器响应（即通知）是自描述且完整的。它通信映射的内部和外部地址、协议和端口及其剩余生存期。如果客户机当前确实希望存在这样的映射，那么它可以从内部地址、协议和端口中识别有问题的映射，并更新其状态以反映当前的外部地址和端口，以及
remaining lifetime. If a client does not currently want such a mapping to exist, then it can safely ignore the message. No client action is required for unexpected mapping notifications. In today's world, a NAT gateway can have a static mapping, and the client device has no explicit knowledge of this, and no way to change the fact. Also, in today's world, a client device can be connected directly to the public Internet, with a globally routable IP address, and, in this case, it effectively has "mappings" for all of its listening ports. Such a device has to be responsible for its own security and cannot rely on assuming that some other network device will be blocking all incoming packets.
剩余寿命。如果客户机当前不希望存在这样的映射，那么它可以安全地忽略该消息。对于意外的映射通知，不需要客户端操作。在当今世界，NAT网关可以有一个静态映射，而客户端设备对此没有明确的了解，也无法改变事实。此外，在当今世界，客户端设备可以直接连接到公共互联网，并具有全局可路由IP地址，在这种情况下，它有效地为其所有侦听端口提供了“映射”。这样的设备必须对自己的安全负责，不能依赖于假设其他网络设备将阻止所有传入的数据包。
All PCP messages are sent over UDP, with a maximum UDP payload length of 1100 octets. The PCP messages contain a request or response header containing an Opcode, any relevant Opcode-specific information, and zero or more options. All numeric quantities larger than a single octet (e.g., result codes, lifetimes, Epoch times, etc.) are represented in conventional IETF network order, i.e., most significant octet first. Non-numeric quantities are represented as is on all platforms, with no byte swapping (e.g., IP addresses and ports are placed in PCP messages using the same representation as when placed in IP or TCP headers).
所有PCP消息都通过UDP发送，UDP有效负载的最大长度为1100个八位字节。PCP消息包含包含操作码的请求或响应头、任何相关操作码特定信息以及零个或多个选项。大于单个八位字节的所有数字量（例如，结果码、寿命、历元时间等）均以传统IETF网络顺序表示，即最重要的八位字节优先。非数字量在所有平台上均按原样表示，无字节交换（例如，IP地址和端口在PCP消息中的表示方式与在IP或TCP标头中的表示方式相同）。
The packet layout for the common header, and operation of the PCP client and PCP server, are described in the following sections. The information in this section applies to all Opcodes. Behavior of the Opcodes defined in this document is described in Sections 10, 11, and 12.
公共报头的数据包布局以及PCP客户端和PCP服务器的操作将在以下部分中描述。本节中的信息适用于所有操作码。本文件中定义的操作码的行为在第10、11和12节中进行了描述。
All requests have the following format:
所有请求的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Common Request Packet Format
图2：公共请求包格式
These fields are described below:
这些字段描述如下：
Version: This document specifies protocol version 2. PCP clients and servers compliant with this document use the value 2. This field is used for version negotiation as described in Section 9.
版本：本文档指定协议版本2。符合本文档要求的PCP客户端和服务器使用值2。该字段用于第9节所述的版本协商。
R: Indicates Request (0) or Response (1).
R：表示请求（0）或响应（1）。
Opcode: A 7-bit value specifying the operation to be performed. MAP and PEER Opcodes are defined in Sections 11 and 12.
操作码：指定要执行的操作的7位值。第11节和第12节定义了MAP和对等操作码。
Reserved: 16 reserved bits. MUST be zero on transmission and MUST be ignored on reception.
保留：16个保留位。传输时必须为零，接收时必须忽略。
Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. This is used by the MAP and PEER Opcodes defined in this document for their requested lifetime.
请求的生存期：一个无符号32位整数，以秒为单位，范围从0到2^32-1秒。本文档中定义的MAP和对等操作码在其请求的生存期内使用此选项。
PCP Client's IP Address: The source IPv4 or IPv6 address in the IP header used by the PCP client when sending this PCP request. An IPv4 address is represented using an IPv4-mapped IPv6 address. The PCP Client IP Address in the PCP message header is used to detect an unexpected NAT on the path between the PCP client and the PCP-controlled NAT or firewall device. See Section 8.1.
PCP客户端的IP地址：发送此PCP请求时，PCP客户端使用的IP头中的源IPv4或IPv6地址。IPv4地址使用IPv4映射的IPv6地址表示。PCP消息头中的PCP客户端IP地址用于检测PCP客户端和PCP控制的NAT或防火墙设备之间路径上的意外NAT。见第8.1节。
Opcode-specific information: Payload data for this Opcode. The length of this data is determined by the Opcode definition.
操作码特定信息：此操作码的有效负载数据。此数据的长度由操作码定义确定。
PCP Options: Zero, one, or more options that are legal for both a PCP request and for this Opcode. See Section 7.3.
PCP选项：对PCP请求和此操作码都合法的零个、一个或多个选项。见第7.3节。
All responses have the following format:
所有答复的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reserved (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) Opcode-specific response data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reserved (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) Opcode-specific response data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Common Response Packet Format
图3：通用响应包格式
These fields are described below:
这些字段描述如下：
Version: Responses from servers compliant with this specification MUST use version 2. This is set by the server.
版本：来自符合此规范的服务器的响应必须使用版本2。这是由服务器设置的。
R: Indicates Request (0) or Response (1). All Responses MUST use 1. This is set by the server.
R：表示请求（0）或响应（1）。所有回复必须使用1。这是由服务器设置的。
Opcode: The 7-bit Opcode value. The server copies this value from the request.
操作码：7位操作码值。服务器从请求中复制此值。
Reserved: 8 reserved bits, MUST be sent as 0, MUST be ignored when received. This is set by the server.
保留：8个保留位，必须作为0发送，接收时必须忽略。这是由服务器设置的。
Result Code: The result code for this response. See Section 7.4 for values. This is set by the server.
结果代码：此响应的结果代码。数值见第7.4节。这是由服务器设置的。
Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. On an error response, this indicates how long clients should assume they'll get the same error response from that PCP server if they repeat the same request. On a success response for the PCP Opcodes that create a mapping (MAP and PEER), the Lifetime field indicates the lifetime for this mapping. This is set by the server.
生存期：一个无符号32位整数，以秒为单位，范围为0到2^32-1秒。在错误响应中，这表示如果客户端重复相同的请求，则客户端应假定从该PCP服务器获得相同的错误响应的时间。在创建映射（映射和对等）的PCP操作码的成功响应中，生存期字段指示此映射的生存期。这是由服务器设置的。
Epoch Time: The server's Epoch Time value. See Section 8.5 for discussion. This value is set by the server, in both success and error responses.
历元时间：服务器的历元时间值。有关讨论，请参见第8.5节。此值由服务器在成功和错误响应中设置。
Reserved: 96 reserved bits. For requests that were successfully parsed, this MUST be sent as 0, MUST be ignored when received. This is set by the server. For requests that were not successfully parsed, the server copies the last 96 bits of the PCP Client's IP Address field from the request message into this corresponding 96-bit field of the response.
保留：96个保留位。对于已成功解析的请求，必须将其作为0发送，接收时必须忽略。这是由服务器设置的。对于未成功解析的请求，服务器将PCP客户端IP地址字段的最后96位从请求消息复制到响应的相应96位字段中。
Opcode-specific information: Payload data for this Opcode. The length of this data is determined by the Opcode definition.
操作码特定信息：此操作码的有效负载数据。此数据的长度由操作码定义确定。
PCP Options: Zero, one, or more options that are legal for both a PCP response and for this Opcode. See Section 7.3.
PCP选项：对PCP响应和此操作码都合法的零个、一个或多个选项。见第7.3节。
A PCP Opcode can be extended with one or more options. Options can be used in requests and responses. The design decisions in this specification about whether to include a given piece of information in the base Opcode format or in an option were an engineering trade-off between packet size and code complexity. For information that is usually (or always) required, placing it in the fixed Opcode data results in simpler code to generate and parse the packet, because the information is a fixed location in the Opcode data, but wastes space in the packet in the event that field is all zeros because the information is not needed or not relevant. For information that is required less often, placing it in an option results in slightly more complicated code to generate and parse packets containing that
PCP操作码可以通过一个或多个选项进行扩展。选项可用于请求和响应。本规范中关于是否将给定信息包含在基本操作码格式或选项中的设计决策是数据包大小和代码复杂性之间的工程权衡。对于通常（或始终）需要的信息，将其放在固定操作码数据中会产生更简单的代码来生成和解析数据包，因为信息在操作码数据中是固定位置，但如果字段全为零，则会浪费数据包中的空间，因为信息不需要或不相关。对于不经常需要的信息，将其放在选项中会导致生成和解析包含该信息的数据包的代码稍微复杂一些
option, but saves space in the packet when that information is not needed. Placing information in an option also means that an implementation that never uses that information doesn't even need to implement code to generate and parse it. For example, a client that never requests mappings on behalf of some other device doesn't need to implement code to generate the THIRD_PARTY option, and a PCP server that doesn't implement the necessary security measures to create third-party mappings safely doesn't need to implement code to parse the THIRD_PARTY option.
选项，但在不需要该信息时可在数据包中节省空间。在选项中放置信息还意味着从未使用该信息的实现甚至不需要实现代码来生成和解析该信息。例如，从不代表其他设备请求映射的客户端不需要实现生成第三方选项的代码，而没有实现安全创建第三方映射所需的安全措施的PCP服务器不需要实现解析第三方选项的代码。
Options use the following Type-Length-Value format:
选项使用以下类型长度值格式：
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 | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Options Header
图4：选项标题
The description of the fields is as follows:
这些字段的说明如下所示：
Option Code: 8 bits. Its most significant bit indicates if this option is mandatory (0) or optional (1) to process.
选项代码：8位。其最高有效位指示此选项是必须（0）还是可选（1）进行处理。
Reserved: 8 bits. MUST be set to 0 on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为0，接收时必须忽略。
Option Length: 16 bits. Indicates the length of the enclosed data, in octets. Options with length of 0 are allowed. Options that are not a multiple of 4 octets long are followed by one, two, or three 0 octets to pad their effective length in the packet to be a multiple of 4 octets. The Option Length reflects the semantic length of the option, not including any padding octets.
选项长度：16位。指示封闭数据的长度，以八位字节为单位。允许使用长度为0的选项。不是4个八位字节的倍数的选项后面跟着一个、两个或三个0八位字节，以将其在数据包中的有效长度填充为4个八位字节的倍数。选项长度反映了选项的语义长度，不包括任何填充八位字节。
Data: Option data.
数据：选项数据。
If several options are included in a PCP request, they MAY be encoded in any order by the PCP client, but MUST be processed by the PCP server in the order in which they appear. It is the responsibility of the PCP client to ensure that the server has sufficient room to reply without exceeding the 1100-octet size limit; if its reply would exceed that size, the server generates an error.
如果PCP请求中包含多个选项，则PCP客户端可以按任意顺序对其进行编码，但PCP服务器必须按其出现的顺序对其进行处理。PCP客户端有责任确保服务器有足够的空间进行回复，而不超过1100个八位字节的大小限制；如果其回复将超过该大小，服务器将生成一个错误。
If, while processing a PCP request, including its options, an error is encountered that causes a PCP error response to be generated, the PCP request MUST cause no state change in the PCP server or the PCP-controlled device (i.e., it rolls back any tentative changes it might have made while processing the request). Such an error response MUST consist of a complete copy of the request packet with the error code and other appropriate fields set in the header.
如果在处理PCP请求（包括其选项）时遇到导致生成PCP错误响应的错误，则PCP请求必须不会导致PCP服务器或PCP控制设备中的状态更改（即，它回滚处理请求时可能做出的任何暂定更改）。此类错误响应必须包含请求数据包的完整副本，其中包含错误代码和在报头中设置的其他适当字段。
An option MAY appear more than once in a request or in a response, if permitted by the definition of the option. If the option's definition allows the option to appear only once but it appears more than once in a request, and the option is understood by the PCP server, the PCP server MUST respond with the MALFORMED_OPTION result code. If the PCP server encounters an invalid option (e.g., PCP option length is longer than the UDP packet length), the error MALFORMED_OPTION SHOULD be returned (rather than MALFORMED_REQUEST), as that helps the client better understand how the packet was malformed. If a PCP response would have exceeded the maximum PCP message size, the PCP server SHOULD respond with MALFORMED_REQUEST.
如果选项的定义允许，选项可能会在请求或响应中出现多次。如果选项的定义允许该选项仅出现一次，但在请求中出现多次，并且PCP服务器可以理解该选项，则PCP服务器必须使用格式错误的_选项结果代码进行响应。如果PCP服务器遇到无效选项（例如，PCP选项长度大于UDP数据包长度），则应返回错误格式错误的_选项（而不是错误格式的_请求），因为这有助于客户端更好地了解数据包的错误格式。如果PCP响应将超过最大PCP消息大小，则PCP服务器应使用格式错误的_请求进行响应。
If the overall option structure of a request cannot successfully be parsed (e.g., a nonsensical option length), the PCP server MUST generate an error response with code MALFORMED_OPTION.
如果无法成功解析请求的整体选项结构（例如，无意义的选项长度），则PCP服务器必须生成一个错误响应，其中包含格式不正确的代码\u选项。
If the overall option structure of a request is valid, then how each individual option is handled is determined by the most significant bit in the option code. If the most significant bit is set, handling this option is optional, and a PCP server MAY process or ignore this option, entirely at its discretion. If the most significant bit is clear, handling this option is mandatory, and a PCP server MUST return the error MALFORMED_OPTION if the option contents are malformed, or UNSUPP_OPTION if the option is unrecognized, unimplemented, or disabled, or if the client is not authorized to use the option. In error responses, all options are returned. In success responses, all processed options are included and unprocessed options are not included.
如果请求的整体选项结构有效，则每个选项的处理方式由选项代码中的最高有效位决定。如果设置了最高有效位，则处理此选项是可选的，PCP服务器可以自行处理或忽略此选项。如果最高有效位已清除，则必须处理此选项。如果选项内容格式不正确，PCP服务器必须返回错误格式的\u选项；如果选项未被识别、未实现或禁用，或者如果客户端未被授权使用该选项，则PCP服务器必须返回错误格式的\u选项。在错误响应中，将返回所有选项。在成功响应中，包括所有已处理的选项，而不包括未处理的选项。
Because the PCP client cannot reject a response containing an Option, PCP clients MUST ignore Options that they do not understand that appear in responses, including Options in the mandatory-to-process range. Naturally, if a client explicitly requests an Option where correct execution of that Option requires processing the Option data in the response, that client SHOULD implement code to do that.
由于PCP客户端无法拒绝包含选项的响应，因此PCP客户端必须忽略响应中出现的他们不理解的选项，包括强制处理范围内的选项。当然，如果客户机显式请求一个选项，而正确执行该选项需要处理响应中的选项数据，那么该客户机应该实现代码来完成该操作。
Different options are valid for different Opcodes. For example:
不同的选项对不同的操作码有效。例如：
o The THIRD_PARTY option is valid for both MAP and PEER Opcodes.
o 第三方选项对MAP和对等操作码都有效。
o The FILTER option is valid only for the MAP Opcode (for the PEER Opcode it would have no meaning).
o 过滤器选项仅对映射操作码有效（对于对等操作码，它没有任何意义）。
o The PREFER_FAILURE option is valid only for the MAP Opcode (for the PEER Opcode, similar semantics are automatically implied).
o prefere_FAILURE选项仅对MAP操作码有效（对于对等操作码，会自动暗示类似的语义）。
The following result codes may be returned as a result of any Opcode received by the PCP server. The only success result code is 0; other values indicate an error. If a PCP server encounters multiple errors during processing of a request, it SHOULD use the most specific error message. Each error code below is classified as either a 'long lifetime' error or a 'short lifetime' error, which provides guidance to PCP server developers for the value of the Lifetime field for these errors. It is RECOMMENDED that short lifetime errors use a 30-second lifetime and long lifetime errors use a 30-minute lifetime.
PCP服务器收到任何操作码后，可能会返回以下结果码。唯一的成功结果代码为0；其他值表示错误。如果PCP服务器在处理请求期间遇到多个错误，则应使用最具体的错误消息。下面的每个错误代码被分类为“长生命周期”错误或“短生命周期”错误，这为PCP服务器开发人员提供了关于这些错误的生命周期字段值的指导。建议短生命周期错误使用30秒的生命周期，而长生命周期错误使用30分钟的生命周期。
0 SUCCESS: Success.
0成功：成功。
1 UNSUPP_VERSION: The version number at the start of the PCP Request header is not recognized by this PCP server. This is a long lifetime error. This document describes PCP version 2.
1 UNSUPP_版本：此PCP服务器无法识别PCP请求标头开头的版本号。这是一个长期的错误。本文档介绍PCP版本2。
2 NOT_AUTHORIZED: The requested operation is disabled for this PCP client, or the PCP client requested an operation that cannot be fulfilled by the PCP server's security policy. This is a long lifetime error.
2未授权：此PCP客户端禁用了请求的操作，或者PCP客户端请求了PCP服务器安全策略无法执行的操作。这是一个长期的错误。
3 MALFORMED_REQUEST: The request could not be successfully parsed. This is a long lifetime error.
3格式错误的_请求：无法成功解析该请求。这是一个长期的错误。
4 UNSUPP_OPCODE: Unsupported Opcode. This is a long lifetime error.
4 UNSUPP_操作码：不支持的操作码。这是一个长期的错误。
5 UNSUPP_OPTION: Unsupported option. This error only occurs if the option is in the mandatory-to-process range. This is a long lifetime error.
5取消支持选项：不支持的选项。此错误仅在选项处于“必须处理”范围内时发生。这是一个长期的错误。
6 MALFORMED_OPTION: Malformed option (e.g., appears too many times, invalid length). This is a long lifetime error.
6格式错误的_选项：格式错误的选项（例如，出现次数太多，长度无效）。这是一个长期的错误。
7 NETWORK_FAILURE: The PCP server or the device it controls is experiencing a network failure of some sort (e.g., has not yet obtained an external IP address). This is a short lifetime error.
7网络故障：PCP服务器或其控制的设备正在经历某种类型的网络故障（例如，尚未获得外部IP地址）。这是一个短暂的生命周期错误。
8 NO_RESOURCES: Request is well-formed and valid, but the server has insufficient resources to complete the requested operation at this time. For example, the NAT device cannot create more mappings at this time, is short of CPU cycles or memory, or is unable to handle the request due to some other temporary condition. The same request may succeed in the future. This is a system-wide error, different from USER_EX_QUOTA. This can be used as a catch-all error, should no other error message be suitable. This is a short lifetime error.
8无资源：请求格式正确且有效，但服务器此时没有足够的资源来完成请求的操作。例如，NAT设备此时无法创建更多映射，CPU周期或内存不足，或者由于某些其他临时条件而无法处理请求。同样的请求将来可能会成功。这是一个系统范围的错误，与用户的EX_配额不同。如果没有其他合适的错误消息，则可以将其用作“全面捕获”错误。这是一个短暂的生命周期错误。
9 UNSUPP_PROTOCOL: Unsupported transport protocol, e.g., SCTP in a NAT that handles only UDP and TCP. This is a long lifetime error.
9 UNSUPP_协议：不受支持的传输协议，例如，NAT中仅处理UDP和TCP的SCTP。这是一个长期的错误。
10 USER_EX_QUOTA: This attempt to create a new mapping would exceed this subscriber's port quota. This is a short lifetime error.
10 USER_EX_配额：尝试创建新映射将超过此订阅服务器的端口配额。这是一个短暂的生命周期错误。
11 CANNOT_PROVIDE_EXTERNAL: The suggested external port and/or external address cannot be provided. This error MUST only be returned for: * MAP requests that included the PREFER_FAILURE option (normal MAP requests will return an available external port) * MAP requests for the SCTP protocol (PREFER_FAILURE is implied) * PEER requests
11无法提供外部：无法提供建议的外部端口和/或外部地址。此错误只能在以下情况下返回：*包含首选\u失败选项的映射请求（正常映射请求将返回可用的外部端口）*SCTP协议的映射请求（暗示首选\u失败）*对等请求
See Section 13.2 for details of the PREFER_FAILURE Option. The error lifetime depends on the reason for the failure.
有关首选故障选项的详细信息，请参见第13.2节。错误生存期取决于失败的原因。
12 ADDRESS_MISMATCH: The source IP address of the request packet does not match the contents of the PCP Client's IP Address field, due to an unexpected NAT on the path between the PCP client and the PCP-controlled NAT or firewall. This is a long lifetime error.
12地址不匹配：由于PCP客户端和PCP控制的NAT或防火墙之间的路径上出现意外NAT，请求数据包的源IP地址与PCP客户端IP地址字段的内容不匹配。这是一个长期的错误。
13 EXCESSIVE_REMOTE_PEERS: The PCP server was not able to create the filters in this request. This result code MUST only be returned if the MAP request contained the FILTER option. See Section 13.3 for details of the FILTER Option. This is a long lifetime error.
13多个远程对等方：PCP服务器无法在此请求中创建筛选器。仅当映射请求包含筛选器选项时，才能返回此结果代码。有关过滤器选项的详细信息，请参见第13.3节。这是一个长期的错误。
PCP messages MUST be sent over UDP [RFC0768]. Every PCP request generates at least one response, so PCP does not need to run over a reliable transport protocol.
PCP消息必须通过UDP[RFC0768]发送。每个PCP请求至少生成一个响应，因此PCP不需要通过可靠的传输协议运行。
When receiving multiple identical requests, the PCP server will generally generate identical responses -- barring cases where the PCP server's state changes between those requests due to other activity. As an example of how such a state change could happen, a request could be received while the PCP-controlled device has no mappings
当接收到多个相同的请求时，PCP服务器通常会生成相同的响应——除非PCP服务器的状态因其他活动而在这些请求之间发生变化。例如，在PCP控制的设备没有映射的情况下，可以接收请求，以说明这种状态更改是如何发生的
available, and the PCP server will generate an error response. If mappings become available and then another copy of that same request arrives (perhaps duplicated in transit in the network), the PCP server will allocate a mapping and generate a non-error response. A PCP client MUST handle such updated responses for any request it sends, most notably to support rapid recovery (Section 14). Also see the Protocol Design Note (Section 6).
可用，并且PCP服务器将生成错误响应。如果映射变得可用，然后相同请求的另一个副本到达（可能在网络传输中复制），PCP服务器将分配映射并生成非错误响应。PCP客户端必须为其发送的任何请求处理此类更新的响应，尤其是为了支持快速恢复（第14节）。另见协议设计说明（第6节）。
This section details operation specific to a PCP client, for any Opcode. Procedures specific to the MAP Opcode are described in Section 11, and procedures specific to the PEER Opcode are described in Section 12.
本节详细介绍了针对任何操作码的特定于PCP客户端的操作。第11节描述了特定于MAP操作码的程序，第12节描述了特定于对等操作码的程序。
Prior to sending its first PCP message, the PCP client determines which server to use. The PCP client performs the following steps to determine its PCP server:
在发送其第一条PCP消息之前，PCP客户端确定要使用哪个服务器。PCP客户端执行以下步骤以确定其PCP服务器：
1. if a PCP server is configured (e.g., in a configuration file or via DHCP), that single configuration source is used as the list of PCP server(s), else
1. 如果配置了PCP服务器（例如，在配置文件中或通过DHCP），则该单一配置源将用作PCP服务器的列表，否则
2. the default router list (for IPv4 and IPv6) is used as the list of PCP server(s). Thus, if a PCP client has both an IPv4 and IPv6 address, it will have an IPv4 PCP server (its IPv4 default router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6 default router) for its IPv6 mappings.
2. 默认路由器列表（用于IPv4和IPv6）用作PCP服务器的列表。因此，如果PCP客户端同时具有IPv4和IPv6地址，则其IPv4映射将具有IPv4 PCP服务器（其IPv4默认路由器），IPv6映射将具有IPv6 PCP服务器（其IPv6默认路由器）。
For the purposes of this document, only a single PCP server address is supported. Should future specifications define configuration methods that provide a longer list of PCP server addresses, those specifications will define how clients select one or more addresses from that list.
在本文档中，仅支持单个PCP服务器地址。如果将来的规范定义了提供较长PCP服务器地址列表的配置方法，则这些规范将定义客户端如何从该列表中选择一个或多个地址。
With that PCP server address, the PCP client formulates its PCP request. The PCP request contains a PCP common header, PCP Opcode and payload, and (possibly) options. As with all UDP client software on any operating system, when several independent PCP clients exist on the same host, each uses a distinct source port number to disambiguate their requests and replies. The PCP client's source port SHOULD be randomly generated [RFC6056].
使用该PCP服务器地址，PCP客户端制定其PCP请求。PCP请求包含PCP公共头、PCP操作码和有效负载，以及（可能的）选项。与任何操作系统上的所有UDP客户端软件一样，当同一主机上存在多个独立的PCP客户端时，每个客户端都使用不同的源端口号来消除其请求和响应的歧义。PCP客户端的源端口应随机生成[RFC6056]。
The PCP client MUST include the source IP address of the PCP message in the PCP request. This is typically its own IP address; see Section 16.4 for how this can be coded. This is used to detect an unexpected NAT on the path between the PCP client and the PCP-controlled NAT or firewall device, to avoid wasting resources on
PCP客户端必须在PCP请求中包含PCP消息的源IP地址。这通常是它自己的IP地址；有关如何对其进行编码，请参见第16.4节。这用于检测PCP客户端和PCP控制的NAT或防火墙设备之间的路径上的意外NAT，以避免在上浪费资源
the PCP-controlled NAT creating pointless non-functional mappings. When such an intervening non-PCP-aware inner NAT is detected, mappings must first be created by some other means in the inner NAT, before mappings can be usefully created in the outer PCP-controlled NAT. Having created mappings in the inner NAT by some other means, the PCP client should then use the inner NAT's external address as the client IP address, to signal to the outer PCP-controlled NAT that the client is aware of the inner NAT, and has taken steps to create mappings in it by some other means, so that mappings created in the outer NAT will not be a pointless waste of resources.
PCP控制NAT创建无意义的非函数映射。当检测到这种介入的非PCP感知的内部NAT时，必须首先在内部NAT中通过某些其他方式创建映射，然后才能在外部PCP控制的NAT中有效地创建映射。在通过其他方式在内部NAT中创建映射后，PCP客户端应使用内部NAT的外部地址作为客户端IP地址，以向外部PCP控制的NAT发送信号，表明客户端知道内部NAT，并已采取步骤通过其他方式在其中创建映射，因此，在外部NAT中创建的映射不会毫无意义地浪费资源。
PCP clients are responsible for reliable delivery of PCP request messages. If a PCP client fails to receive an expected response from a server, the client must retransmit its message. The retransmissions MUST use the same Mapping Nonce value (see Sections 11.1 and 12.1). The client begins the message exchange by transmitting a message to the server. The message exchange continues for as long as the client wishes to maintain the mapping, and terminates when the PCP client is no longer interested in the PCP transaction (e.g., the application that requested the mapping is no longer interested in the mapping) or (optionally) when the message exchange is considered to have failed according to the retransmission mechanism described below.
PCP客户端负责可靠地传递PCP请求消息。如果PCP客户端无法从服务器接收到预期的响应，则该客户端必须重新传输其消息。重传必须使用相同的映射Nonce值（见第11.1节和第12.1节）。客户端通过向服务器发送消息来开始消息交换。只要客户端希望维护映射，消息交换就会继续，并在PCP客户端不再对PCP事务感兴趣（例如，请求映射的应用程序不再对映射感兴趣）或（可选）时终止当根据下面描述的重传机制认为消息交换失败时。
The client retransmission behavior is controlled and described by the following variables:
客户端重传行为由以下变量控制和描述：
RT: Retransmission timeout, calculated as described below
RT：重传超时，如下所述计算
IRT: Initial retransmission time, SHOULD be 3 seconds
IRT：初始重传时间，应为3秒
MRC: Maximum retransmission count, SHOULD be 0 (0 indicates no maximum)
MRC:最大重传计数，应为0（0表示没有最大值）
MRT: Maximum retransmission time, SHOULD be 1024 seconds
MRT：最大重传时间，应为1024秒
MRD: Maximum retransmission duration, SHOULD be 0 (0 indicates no maximum)
MRD：最大重传持续时间，应为0（0表示没有最大值）
RAND: Randomization factor, calculated as described below
RAND：随机化因子，如下所述计算
With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before a response is received, the client retransmits the request and computes a new RT.
在每次消息传输或重传时，客户机根据下面给出的规则设置RT。如果RT在收到响应之前过期，客户端将重新传输请求并计算新的RT。
Each of the computations of a new RT include a new randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.1 and +0.1. The randomization factor is included to minimize synchronization of messages transmitted by PCP clients. The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of random numbers from each invocation of the PCP client.
新RT的每次计算都包括一个新的随机化因子（RAND），它是一个随机数，其均匀分布在-0.1和+0.1之间。包括随机化因子以最小化PCP客户端传输的消息的同步。选择一个随机数的算法不需要在密码上可靠。该算法应该在每次调用PCP客户端时生成不同的随机数序列。
The RT value is initialized based on IRT:
根据IRT初始化RT值：
RT = (1 + RAND) * IRT
RT = (1 + RAND) * IRT
RT for each subsequent message transmission is based on the previous value of RT, subject to the upper bound on the value of RT specified by MRT. If MRT has a value of 0, there is no upper limit on the value of RT, and MRT is treated as "infinity". The new value of RT is calculated as shown below, where RTprev is the current value of RT:
每个后续消息传输的RT基于之前的RT值，以MRT指定的RT值上限为准。如果MRT的值为0，则RT的值没有上限，并且MRT被视为“无穷大”。RT的新值计算如下所示，其中RTprev是RT的当前值：
RT = (1 + RAND) * MIN (2 * RTprev, MRT)
RT = (1 + RAND) * MIN (2 * RTprev, MRT)
MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times.
MRC指定客户端可以重新传输消息的次数上限。除非MRC为零，否则一旦客户机传输消息MRC次，消息交换就会失败。
MRD specifies an upper bound on the length of time a client may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message.
MRD指定客户端可以重新传输消息的时间长度上限。除非MRD为零，否则自客户端首次传输消息以来，一旦MRD秒过去，消息交换就会失败。
If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous two paragraphs are met. If both MRC and MRD are zero, the client continues to transmit the message until it receives a response or the client no longer wants a mapping.
如果MRC和MRD均为非零，则只要满足前两段中指定的任一条件，消息交换就会失败。如果MRC和MRD都为零，则客户端将继续传输消息，直到收到响应或客户端不再需要映射。
Once a PCP client has successfully received a response from a PCP server on that interface, it resets RT to a value randomly selected in the range 1/2 to 5/8 of the mapping lifetime, as described in Section 11.2.1, "Renewing a Mapping", and sends subsequent PCP requests for that mapping to that same server.
一旦PCP客户端在该接口上成功接收到来自PCP服务器的响应，它将RT重置为在映射生存期的1/2到5/8范围内随机选择的值，如第11.2.1节“更新映射”所述，并向该服务器发送该映射的后续PCP请求。
Note: If the server's state changes between retransmissions and the server's response is delayed or lost, the state in the PCP client and server may not be synchronized. This is not unique to PCP, but also occurs with other network protocols (e.g., TCP). In the unlikely event that such de-synchronization occurs, PCP heals itself after lifetime seconds.
注意：如果服务器的状态在重新传输之间发生更改，并且服务器的响应延迟或丢失，则PCP客户端和服务器中的状态可能不同步。这不是PCP独有的，但在其他网络协议（如TCP）中也会发生。在这种不太可能发生的情况下，PCP会在生存期秒后自行恢复。
This section details operation specific to a PCP server. Processing SHOULD be performed in the order of the following paragraphs.
本节详细介绍特定于PCP服务器的操作。应按照以下段落的顺序进行处理。
A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests from a client on the same interface from which it would normally receive packets from that client, and it MUST silently ignore PCP requests arriving on any other interface. For example, a residential NAT gateway accepts PCP requests only when they arrive on its (LAN) interface connecting to the internal network, and silently ignores any PCP requests arriving on its external (WAN) interface. A PCP server that supports THIRD_PARTY requests MAY be configured to accept THIRD_PARTY requests on other configured interfaces (see Section 13.1 for details on the THIRD_PARTY Option).
PCP服务器必须只接受来自同一接口上的客户机的正常（非第三方）PCP请求，该接口通常从该客户机接收数据包，并且必须静默地忽略到达任何其他接口的PCP请求。例如，住宅NAT网关仅在PCP请求到达其连接到内部网络的（LAN）接口时才接受PCP请求，并静默地忽略任何到达其外部（WAN）接口的PCP请求。支持第三方请求的PCP服务器可以配置为在其他配置的接口上接受第三方请求（有关第三方选项的详细信息，请参阅第13.1节）。
Upon receiving a request, the PCP server parses and validates it. A valid request contains a valid PCP common header, one valid PCP Opcode, and zero or more options (which the server might or might not comprehend). If an error is encountered during processing, the server generates an error response that is sent back to the PCP client. Processing of an Opcode and its options is specific to each Opcode.
收到请求后，PCP服务器将对其进行解析和验证。一个有效的请求包含一个有效的PCP公共头、一个有效的PCP操作码和零个或多个选项（服务器可能理解，也可能不理解）。如果在处理过程中遇到错误，服务器将生成错误响应，并将其发送回PCP客户端。操作码及其选项的处理特定于每个操作码。
Error responses have the same packet layout as success responses, with certain fields from the request copied into the response, and other fields assigned by the PCP server set as indicated in Figure 3.
错误响应与成功响应具有相同的数据包布局，请求中的某些字段复制到响应中，PCP服务器设置的其他字段如图3所示。
Copying request fields into the response is important because this is what enables a client to identify to which request a given response pertains. For Opcodes that are understood by the PCP server, it follows the requirements of that Opcode to copy the appropriate fields. For Opcodes that are not understood by the PCP server, it simply generates the UNSUPP_OPCODE response and copies fields from the PCP header and copies the rest of the PCP payload as is (without attempting to interpret it).
将请求字段复制到响应中很重要，因为这使客户端能够识别给定响应所属的请求。对于PCP服务器可以理解的操作码，它会按照该操作码的要求复制相应的字段。对于PCP服务器无法理解的操作码，它只会生成UNSUPP_操作码响应，并从PCP标头复制字段，并按原样复制PCP有效负载的其余部分（而不尝试对其进行解释）。
All responses (both error and success) contain the same Opcode as the request, but with the "R" bit set.
所有响应（错误和成功）包含与请求相同的操作码，但设置了“R”位。
Any error response has a non-zero result code, and is created by:
任何错误响应都有一个非零结果代码，由以下程序创建：
o Copying the entire UDP payload, or 1100 octets, whichever is less, and zero-padding the response to a multiple of 4 octets if necessary o Setting the R bit o Setting the result code o Setting the Lifetime, Epoch Time, and Reserved fields
o 复制整个UDP有效负载或1100个八位字节（以较小者为准），并在必要时将响应零填充为4个八位字节的倍数o设置R位o设置结果代码o设置生存期、历元时间和保留字段
o Updating other fields in the response, as indicated by 'set by the server' in the PCP response field description
o 更新响应中的其他字段，如PCP响应字段说明中的“由服务器设置”所示
A success response has a zero result code, and is created by:
成功响应的结果代码为零，由以下内容创建：
o Copying the first 4 octets of request packet header o Setting the R bit o Setting the result code to zero o Setting the Lifetime, Epoch Time, and Reserved fields o Possibly setting Opcode-specific response data if appropriate o Adding any processed options to the response message
o 复制请求数据包头的前4个八位字节o设置R位o将结果代码设置为零o设置生存期、历元时间和保留字段o可能设置操作码特定的响应数据（如果适用）o向响应消息添加任何已处理选项
If the received PCP request message is less than 2 octets long, it is silently dropped.
如果接收到的PCP请求消息长度小于2个八位字节，则会自动删除该消息。
If the R bit is set, the message is silently dropped.
如果设置了R位，则消息将被静默删除。
If the first octet (version) is a version that is not supported, a response is generated with the UNSUPP_VERSION result code, and the Version Negotiation steps detailed in Section 9 are followed.
如果第一个八位组（版本）是不受支持的版本，则会使用UNSUPP_版本结果代码生成响应，并遵循第9节中详细说明的版本协商步骤。
Otherwise, if the version is supported but the received message is shorter than 24 octets, the message is silently dropped.
否则，如果支持该版本，但收到的消息短于24个八位字节，则消息将被静默删除。
If the server is overloaded by requests (from a particular client or from all clients), it MAY simply silently discard requests, as the requests will be retried by PCP clients, or it MAY generate the NO_RESOURCES error response.
如果服务器因请求（来自特定客户机或所有客户机）而过载，它可能只是默默地放弃请求，因为请求将由PCP客户机重试，或者它可能会生成无资源错误响应。
If the length of the message exceeds 1100 octets, is not a multiple of 4 octets, or is too short for the Opcode in question, it is invalid and a MALFORMED_REQUEST response is generated, and the response message is truncated to 1100 octets.
如果消息长度超过1100个八位字节，不是4个八位字节的倍数，或者对于所讨论的操作码来说太短，则消息无效并生成格式错误的_请求响应，响应消息将被截断为1100个八位字节。
The PCP server compares the source IP address (from the received IP header) with the field PCP Client IP Address. If they do not match, the error ADDRESS_MISMATCH MUST be returned. This is done to detect and prevent accidental use of PCP where a non-PCP-aware NAT exists between the PCP client and PCP server. If the PCP client wants such a mapping, it needs to ensure that the PCP field matches its apparent IP address from the perspective of the PCP server.
PCP服务器将源IP地址（来自接收到的IP头）与字段PCP客户端IP地址进行比较。如果它们不匹配，则必须返回错误地址\u不匹配。这样做是为了在PCP客户端和PCP服务器之间存在非PCP感知NAT的情况下检测并防止意外使用PCP。如果PCP客户端需要这样的映射，它需要确保PCP字段与PCP服务器的外观IP地址相匹配。
The PCP client receives the response and verifies that the source IP address and port belong to the PCP server of a previously sent PCP request. If not, the response is silently dropped.
PCP客户端接收响应并验证源IP地址和端口是否属于先前发送的PCP请求的PCP服务器。如果没有，响应将被静默删除。
If the received PCP response message is less than 4 octets long, it is silently dropped.
如果收到的PCP响应消息长度小于4个八位字节，则会自动删除。
If the R bit is clear, the message is silently dropped.
如果R位是清除的，则消息将被静默删除。
If the error code is UNSUPP_VERSION, Version Negotiation processing continues as described in Section 9.
如果错误代码为Unapp_VERSION，则版本协商处理将继续进行，如第9节所述。
Responses shorter than 24 octets, longer than 1100 octets, or not a multiple of 4 octets are invalid and ignored.
小于24个八位字节、长于1100个八位字节或不是4个八位字节的倍数的响应无效并被忽略。
The PCP client then validates that the Opcode matches a previous PCP request. If the response does not match a previous PCP request, the response is ignored. The response is further matched by comparing fields in the response Opcode-specific data to fields in the request Opcode-specific data, as described by the processing for that Opcode. If that fails, the response is ignored.
然后，PCP客户端验证操作码是否与以前的PCP请求匹配。如果响应与以前的PCP请求不匹配，则忽略响应。通过将响应操作码特定数据中的字段与请求操作码特定数据中的字段进行比较，进一步匹配响应，如对该操作码的处理所述。如果失败，则忽略响应。
After these matches are successful, the PCP client checks the Epoch Time field (see Section 8.5) to determine if it needs to restore its state to the PCP server. A PCP client SHOULD be prepared to receive multiple responses from the PCP server at any time after a single request is sent. This allows the PCP server to inform the client of mapping changes such as an update or deletion. For example, a PCP server might send a SUCCESS response and, after a configuration change on the PCP server, later send a NOT_AUTHORIZED response. A PCP client MUST be prepared to receive responses for requests it never sent (which could have been sent by a previous PCP instance on this same host, or by a previous host that used the same client IP address, or by a malicious attacker) by simply ignoring those unexpected messages.
这些匹配成功后，PCP客户端将检查历元时间字段（参见第8.5节），以确定是否需要将其状态恢复到PCP服务器。PCP客户端应准备在发送单个请求后随时从PCP服务器接收多个响应。这允许PCP服务器通知客户端映射更改，例如更新或删除。例如，PCP服务器可能会发送成功响应，并且在PCP服务器上的配置更改后，稍后会发送未经授权的响应。PCP客户端必须准备好接收从未发送过的请求的响应（这些请求可能是由同一主机上的前一个PCP实例、使用相同客户端IP地址的前一个主机或恶意攻击者发送的），只需忽略这些意外消息。
If the error ADDRESS_MISMATCH is received, it indicates the presence of a NAT between the PCP client and PCP server. Procedures to resolve this problem are beyond the scope of this document.
如果接收到错误地址_不匹配，则表示PCP客户端和PCP服务器之间存在NAT。解决此问题的程序超出了本文件的范围。
For both success and error responses, a Lifetime value is returned. The lifetime indicates how long this response should be considered valid by the client (i.e for success results, how long the mapping will last, and for failure results how long the same failure condition should be expected to persist). The PCP client SHOULD impose an upper limit on this returned value (to protect against absurdly large values, e.g., 5 years), detailed in Section 15, "Mapping Lifetime and Deletion".
对于成功响应和错误响应，都会返回生存期值。生存期表示客户端应将此响应视为有效的时间（即，对于成功结果，映射将持续多长时间，对于失败结果，相同的失败条件应持续多长时间）。PCP客户端应对此返回值施加上限（以防止出现荒谬的大值，例如5年），详情见第15节“映射生存期和删除”。
If the result code is 0 (SUCCESS), the request succeeded.
如果结果代码为0（成功），则请求成功。
If the result code is not 0, the request failed, and the PCP client SHOULD NOT resend the same request for the indicated lifetime of the error (as limited by the sanity checking detailed in Section 15).
如果结果代码不是0，则请求失败，PCP客户端不应在指定的错误生存期内重新发送相同的请求（受第15节中详细说明的健全性检查的限制）。
If the PCP client has discovered a new PCP server (e.g., connected to a new network), the PCP client MAY immediately begin communicating with this PCP server, without regard to hold times from communicating with a previous PCP server.
如果PCP客户端发现了新的PCP服务器（例如，连接到新网络），则PCP客户端可以立即开始与该PCP服务器通信，而不考虑与先前PCP服务器通信的等待时间。
Hosts that desire a PCP mapping might be multi-interfaced (i.e., own several logical/physical interfaces). Indeed, a host can be configured with several IPv4 addresses (e.g., WiFi and Ethernet) or dual-stacked. These IP addresses may have distinct reachability scopes (e.g., if IPv6, they might have global reachability scope as is the case for a Global Unicast Address (GUA) [RFC3587] or limited scope as is the case for a Unique Local Address (ULA) [RFC4193]).
需要PCP映射的主机可能是多接口的（即，拥有多个逻辑/物理接口）。实际上，一台主机可以配置多个IPv4地址（如WiFi和以太网）或双堆叠。这些IP地址可能具有不同的可达范围（例如，如果是IPv6，则它们可能具有全局可达范围，如全局单播地址（GUA）[RFC3587]的情况，或者具有有限范围，如唯一本地地址（ULA）[RFC4193]）。
IPv6 addresses with global reachability (e.g., GUAs) SHOULD be used as the source address when generating a PCP request. IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be used as the source interface when generating a PCP request. If IPv6 privacy addresses [RFC4941] are used for PCP mappings, a new PCP request will need to be issued whenever the IPv6 privacy address is changed. This PCP request SHOULD be sent from the IPv6 privacy address itself. It is RECOMMENDED that the client delete its mappings to the previous privacy address after it no longer needs those old mappings.
生成PCP请求时，应将具有全局可达性的IPv6地址（如GUA）用作源地址。生成PCP请求时，不应将不具有全局可达性（如ULA）的IPv6地址用作源接口。如果IPv6隐私地址[RFC4941]用于PCP映射，则每当更改IPv6隐私地址时，都需要发出新的PCP请求。此PCP请求应从IPv6隐私地址本身发送。建议客户端在不再需要以前的映射后删除到以前隐私地址的映射。
Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope (e.g., private addresses [RFC1918]) MAY be used as the source interface when generating a PCP request.
由于IPv4 NAT的普遍性，在生成PCP请求时，范围有限的IPv4地址（例如，专用地址[RFC1918]）可以用作源接口。
Every PCP response sent by the PCP server includes an Epoch Time field. This time field increments by one every second. Anomalies in the received Epoch Time value provide a hint to PCP clients that a PCP server state loss may have occurred. Clients respond to such state loss hints by promptly renewing their mappings, so as to quickly restore any lost state at the PCP server.
PCP服务器发送的每个PCP响应都包含一个历元时间字段。此时间字段每秒递增一。收到的历元时间值中的异常情况向PCP客户端提示可能已发生PCP服务器状态丢失。客户端通过迅速更新其映射来响应此类状态丢失提示，以便在PCP服务器上快速恢复任何丢失的状态。
If the PCP server resets or loses the state of its explicit dynamic mappings (that is, those mappings created by PCP requests), due to reboot, power failure, or any other reason, it MUST reset its Epoch time to its initial starting value (usually zero) to provide this hint to PCP clients. After resetting its Epoch time, the PCP server resumes incrementing the Epoch Time value by one every second.
如果由于重新启动、电源故障或任何其他原因，PCP服务器重置或丢失其显式动态映射（即由PCP请求创建的映射）的状态，则它必须将其历元时间重置为其初始启动值（通常为零），以向PCP客户端提供此提示。重置其历元时间后，PCP服务器恢复将历元时间值每秒递增一。
Similarly, if the external IP address(es) of the NAT (controlled by the PCP server) changes, the Epoch time MUST be reset. A PCP server MAY maintain one Epoch Time value for all PCP clients or MAY maintain distinct Epoch Time values (per PCP client, per interface, or based on other criteria); this choice is implementation-dependent.
类似地，如果NAT（由PCP服务器控制）的外部IP地址发生变化，则必须重置历元时间。PCP服务器可以为所有PCP客户端维护一个历元时间值，或者可以维护不同的历元时间值（每个PCP客户端、每个接口或基于其他标准）；这种选择取决于实现。
Whenever a client receives a PCP response, the client validates the received Epoch Time value according to the procedure below, using integer arithmetic:
每当客户机接收到PCP响应时，客户机将根据以下过程，使用整数算法验证接收到的历元时间值：
o If this is the first PCP response the client has received from this PCP server, the Epoch Time value is treated as necessarily valid, otherwise
o 如果这是客户端从该PCP服务器接收到的第一个PCP响应，则历元时间值视为必然有效，否则
* If the current PCP server Epoch time (curr_server_time) is less than the previously received PCP server Epoch time (prev_server_time) by more than one second, then the client treats the Epoch time as obviously invalid (time should not go backwards). The server Epoch time apparently going backwards by *up to* one second is not deemed invalid, so that minor packet reordering on the path from PCP server to PCP client does not trigger a cascade of unnecessary mapping renewals. If the server Epoch time passes this check, then further validation checks are performed:
* 如果当前PCP服务器历元时间（curr_server_time）比以前接收的PCP服务器历元时间（prev_server_time）短一秒以上，则客户端将历元时间视为明显无效（时间不应倒转）。服务器纪元时间明显向后*最多*1秒不被视为无效，因此，在从PCP服务器到PCP客户端的路径上的小数据包重新排序不会触发不必要的映射更新级联。如果服务器历元时间通过此检查，则执行进一步的验证检查：
+ The client computes the difference between its current local time (curr_client_time) and the time the previous PCP response was received from this PCP server (prev_client_time): client_delta = curr_client_time - prev_client_time;
+ 客户端计算其当前本地时间（curr_client_time）与从该PCP服务器接收上一个PCP响应的时间（prev_client_time）之间的差值：client_delta=curr_client_time-prev_client_time；
+ The client computes the difference between the current PCP server Epoch time (curr_server_time) and the previously received Epoch time (prev_server_time): server_delta = curr_server_time - prev_server_time;
+ 客户端计算当前PCP服务器历元时间（curr_server_time）和以前接收到的历元时间（prev_server_time）之间的差值：server_delta=curr_server_time-prev_server_time；
+ If client_delta+2 < server_delta - server_delta/16 or server_delta+2 < client_delta - client_delta/16, then the client treats the Epoch Time value as invalid, else the client treats the Epoch Time value as valid.
+ 如果client_delta+2<server_delta-server_delta/16或server_delta+2<client_delta-client_delta/16，则客户端将历元时间值视为无效，否则客户端将历元时间值视为有效。
o The client records the current time values for use in its next comparison: prev_client_time = curr_client_time prev_server_time = curr_server_time
o 客户端记录当前时间值，以便在下次比较中使用：prev\u client\u time=curr\u client\u time prev\u server\u time=curr\u server\u time
If the PCP client determined that the Epoch Time value it received was invalid, then it concludes that the PCP server may have lost state, and promptly renews all its active port mapping leases following the mapping recreation procedure described in Section 16.3.1.
如果PCP客户端确定其接收到的历元时间值无效，则会得出PCP服务器可能已失去状态的结论，并按照第16.3.1节中描述的映射重新创建过程，立即续订其所有活动端口映射租约。
Notes:
笔记：
o The client clock MUST never go backwards. If curr_client_time is found to be less than prev_client_time, then this is a client bug, and how the client deals with this client bug is implementation specific.
o 客户端时钟决不能倒转。如果发现curr_client_time小于prev_client_time，则这是一个客户端错误，客户端处理此客户端错误的方式是特定于实现的。
o The calculations above are constructed to allow client_delta and server_delta to be computed as unsigned integer values.
o 上面的计算构造为允许将客户端_delta和服务器_delta计算为无符号整数值。
o The "+2" in the calculations above is to accommodate quantization errors in client and server clocks (up to one-second quantization error each in server and client time intervals).
o 上述计算中的“+2”用于适应客户机和服务器时钟中的量化误差（服务器和客户机时间间隔中的量化误差高达1秒）。
o The "/16" in the calculations above is to accommodate inaccurate clocks in low-cost devices. This allows for a total discrepancy of up to 1/16 (6.25%) to be considered benign; e.g., if one clock were to run too fast by 3% while the other clock ran too slow by 3%, then the client would not consider this difference to be anomalous or indicative of a restart having occurred. This tolerance is strict enough to be effective at detecting reboots, while not being so strict as to generate false alarms.
o 上述计算中的“/16”是为了适应低成本设备中不准确的时钟。这使得高达1/16（6.25%）的总差异被认为是良性的；例如，如果一个时钟运行速度太快3%，而另一个时钟运行速度太慢3%，则客户端不会认为这种差异是异常的，或者表示已经发生重启。此容差足够严格，可以有效地检测重新启动，但不会严格到生成错误警报。
A PCP client sends its requests using PCP version number 2. Should later updates to this document specify different message formats with a version number greater than 2, it is expected that PCP servers will still support version 2 in addition to the newer version(s). However, in the event that a server returns a response with result code UNSUPP_VERSION, the client MAY log an error message to inform the user that it is too old to work with this server.
PCP客户端使用PCP版本号2发送其请求。如果本文档的后续更新指定了版本号大于2的不同消息格式，则PCP服务器除支持较新版本外，预计还将支持版本2。但是，如果服务器返回结果代码为UNSUPP_VERSION的响应，则客户端可能会记录一条错误消息，通知用户该服务器太旧，无法使用该服务器。
Should later updates to this document specify different message formats with a version number greater than 2, and backwards compatibility be desired, this first octet can be used for forward and backward compatibility.
如果本文档的后续更新指定了版本号大于2的不同消息格式，并且需要向后兼容，则第一个八位组可用于向前和向后兼容。
If future PCP versions greater than 2 are specified, version negotiation proceeds as follows:
如果指定了大于2的未来PCP版本，则版本协商按如下方式进行：
1. The client sends its first request using the highest (i.e., presumably 'best') version number it supports.
1. 客户端使用其支持的最高（即“最佳”）版本号发送其第一个请求。
2. If the server supports that version, it responds normally.
2. 如果服务器支持该版本，它将正常响应。
3. If the server does not support that version, it replies giving a result containing the result code UNSUPP_VERSION, and the closest version number it does support (if the server supports a range of versions higher than the client's requested version, the server returns the lowest of that supported range; if the server supports a range of versions lower than the client's requested version, the server returns the highest of that supported range).
3. 如果服务器不支持该版本，它将给出一个结果，其中包含结果代码UNSUPP_version，以及它支持的最接近的版本号（如果服务器支持的版本范围高于客户端请求的版本，则服务器返回该支持范围的最低版本；如果服务器支持的版本范围低于客户端请求的版本，则服务器返回该支持范围的最高版本）。
4. If the client receives an UNSUPP_VERSION result containing a version it does support, it records this fact and proceeds to use this message version for subsequent communication with this PCP server (until a possible future UNSUPP_VERSION response if the server is later updated, at which point the version negotiation process repeats). If the version number in the UNSUPP_VERSION response is zero then that means this is a NAT-PMP server [RFC6886], and a client MAY choose to communicate with it using the older NAT-PMP protocol, as described in Appendix A.
4. 如果客户端接收到包含其支持的版本的UNSUPP_版本结果，则会记录此事实，并继续使用此消息版本与此PCP服务器进行后续通信（直到服务器稍后更新时可能出现UNSUPP_版本响应，此时版本协商过程会重复）。如果UNSUPP_版本响应中的版本号为零，则表示这是一个NAT-PMP服务器[RFC6886]，客户端可以选择使用较旧的NAT-PMP协议与其通信，如附录a所述。
5. If the client receives an UNSUPP_VERSION result containing a version it does not support, then the client SHOULD try the next-lower version supported by the client. The attempt to use the next-lower version repeats until the client has tried version 2. If using version 2 fails, the client MAY log an error message to inform the user that it is too old to work with this server, and the client SHOULD set a timer to retry its request in 30 minutes or the returned Lifetime value, whichever is smaller. By automatically retrying in 30 minutes, the protocol accommodates an upgrade of the PCP server.
5. 如果客户端收到包含不支持的版本的UNSUPP_版本结果，则客户端应尝试客户端支持的下一个较低版本。重复尝试使用下一个较低版本，直到客户端尝试了版本2。如果使用版本2失败，客户端可能会记录一条错误消息，通知用户该服务器太旧，无法使用该服务器，客户端应设置一个计时器，在30分钟内重试其请求或返回的生存期值（以较小者为准）。通过在30分钟内自动重试，该协议适应了PCP服务器的升级。
There are four uses for the MAP and PEER Opcodes defined in this document:
本文档中定义的MAP和对等操作码有四种用途：
o a host operating a server and wanting an incoming connection (Section 10.1);
o 运行服务器并需要传入连接的主机（第10.1节）；
o a host operating a client and server on the same port (Section 10.2);
o 在同一端口上运行客户端和服务器的主机（第10.2节）；
o a host operating a client and wanting to optimize the application keepalive traffic (Section 10.3); and
o 操作客户端并希望优化应用程序保持流量的主机（第10.3节）；和
o a host operating a client and wanting to restore lost state in its NAT (Section 10.4).
o 操作客户端并希望恢复其NAT中丢失状态的主机（第10.4节）。
These are discussed in the following sections, and a (non-normative) state diagram is provided in Section 16.5.
以下章节将讨论这些问题，第16.5节提供了（非规范性）状态图。
When operating a server (see Sections 10.1 and 10.2), the PCP client knows if it wants an IPv4 listener, IPv6 listener, or both on the Internet. The PCP client also knows if it has an IPv4 address or IPv6 address configured on one of its interfaces. It takes the union of this knowledge to decide to which of its PCP servers to send the request (e.g., an IPv4 address or an IPv6 address), and whether to send one or two MAP requests for each of its interfaces (e.g., if the PCP client has only an IPv4 address but wants both IPv6 and IPv4 listeners, it sends a MAP request containing the all-zeros IPv6 address in the Suggested External Address field, and sends a second MAP request containing the all-zeros IPv4 address in the Suggested External Address field). If the PCP client has both an IPv4 and IPv6 address, and only wants an IPv4 listener, it sends one MAP request from its IPv4 address (if the PCP server supports NAT44 or IPv4 firewall) or one MAP request from its IPv6 address (if the PCP server supports NAT64). The PCP client can simply request the desired mapping to determine if the PCP server supports the desired mapping. Applications that embed IP addresses in payloads (e.g., FTP, SIP) will find it beneficial to avoid address family translation, if possible.
在操作服务器时（请参阅第10.1和10.2节），PCP客户端知道它是否需要Internet上的IPv4侦听器、IPv6侦听器或两者。PCP客户端还知道在其接口之一上是否配置了IPv4地址或IPv6地址。需要结合这些知识来决定向哪个PCP服务器发送请求（例如，IPv4地址或IPv6地址），以及是否为每个接口发送一个或两个映射请求（例如，如果PCP客户端只有一个IPv4地址，但同时需要IPv6和IPv4侦听器，它会在建议的外部地址字段中发送包含全零IPv6地址的映射请求，并在建议的外部地址字段中发送包含全零IPv4地址的第二个映射请求）。如果PCP客户端同时具有IPv4和IPv6地址，并且只需要IPv4侦听器，则它会从其IPv4地址（如果PCP服务器支持NAT44或IPv4防火墙）发送一个映射请求，或从其IPv6地址（如果PCP服务器支持NAT64）发送一个映射请求。PCP客户端可以简单地请求所需的映射，以确定PCP服务器是否支持所需的映射。在有效负载中嵌入IP地址的应用程序（例如FTP、SIP）将发现，如果可能，避免地址族转换是有益的。
The MAP and PEER requests include a Suggested External IP Address field. Some PCP-controlled devices, especially CGN but also multi-homed NPTv6 networks, have a pool of public-facing IP addresses. PCP allows the client to indicate if it wants a mapping assigned on a specific address of that pool or any address of that pool. Some applications will break if mappings are created on different IP addresses (e.g., active mode FTP), so applications should carefully consider the implications of using this capability. Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address, and if the suggested external IP address is the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to the same external address, as this can also help applications using a mix of both static mappings and PCP-created mappings. If, on the other hand, the suggested external IP address contains a non-zero IP address the PCP server SHOULD create a mapping to that external address, even if there are other mappings from that same internal address to a different external address. Once an internal address
映射和对等请求包括建议的外部IP地址字段。一些PCP控制的设备，特别是CGN，但也有多宿NPTv6网络，有一个面向公众的IP地址池。PCP允许客户端指示它是否希望在该池的特定地址或该池的任何地址上分配映射。如果在不同的IP地址（例如，活动模式FTP）上创建映射，则某些应用程序将中断，因此应用程序应仔细考虑使用该能力的含义。该内部地址（例如，由PCP服务器或PCP控制设备上的命令行接口创建的地址）的静态映射可能存在于某个外部地址，如果建议的外部IP地址是IPv4或IPv6全零地址，PCP应将其映射分配到同一个外部地址，因为这也可以帮助混合使用静态映射和PCP创建的映射的应用程序。另一方面，如果建议的外部IP地址包含非零IP地址，则PCP服务器应创建到该外部地址的映射，即使存在从同一内部地址到不同外部地址的其他映射。曾经是一个内部地址
has no implicit dynamic mappings and no explicit dynamic mappings in the PCP-controlled device, a subsequent implicit or explicit mapping for that internal address MAY be assigned to a different External address. Generally, this reassignment would occur when a CGN device is load balancing newly seen internal addresses to its public pool of external addresses.
在PCP控制设备中没有隐式动态映射和显式动态映射，该内部地址的后续隐式或显式映射可分配给不同的外部地址。通常，当CGN设备将新看到的内部地址负载平衡到其外部地址的公共池时，会发生这种重新分配。
The following table summarizes how various common PCP deployments use IPv6 and IPv4 addresses.
下表总结了各种常见PCP部署如何使用IPv6和IPv4地址。
The 'internal' address is implicitly the same as the source IP address of the PCP request, except when the THIRD_PARTY option is used.
“内部”地址与PCP请求的源IP地址隐式相同，除非使用第三方选项。
The 'external' address is the Suggested External Address field of the MAP or PEER request, and its address family is usually the same as the 'internal' address family, except when technologies like NAT64 are used.
“外部”地址是映射或对等请求的建议外部地址字段，其地址族通常与“内部”地址族相同，除非使用NAT64等技术。
The 'remote peer' address is the remote peer IP address of the PEER request or the FILTER option of the MAP request, and is always the same address family as the 'internal' address, even when NAT64 is used. In NAT64, the IPv6 PCP client is not necessarily aware of the NAT64 or aware of the actual IPv4 address of the remote peer, so it expresses the IPv6 address from its perspective, as shown in Figure 5.
“远程对等”地址是对等请求的远程对等IP地址或映射请求的筛选器选项，并且始终与“内部”地址相同，即使使用NAT64也是如此。在NAT64中，IPv6 PCP客户端不一定知道NAT64或远程对等方的实际IPv4地址，因此它从其角度表示IPv6地址，如图5所示。
internal external PCP remote peer actual remote peer
-------- ------- --------------- ------------------
IPv4 firewall IPv4 IPv4 IPv4 IPv4
IPv6 firewall IPv6 IPv6 IPv6 IPv6
NAT44 IPv4 IPv4 IPv4 IPv4
NAT46 IPv4 IPv6 IPv4 IPv6
NAT64 IPv6 IPv4 IPv6 IPv4
NPTv6 IPv6 IPv6 IPv6 IPv6
internal external PCP remote peer actual remote peer
-------- ------- --------------- ------------------
IPv4 firewall IPv4 IPv4 IPv4 IPv4
IPv6 firewall IPv6 IPv6 IPv6 IPv6
NAT44 IPv4 IPv4 IPv4 IPv4
NAT46 IPv4 IPv6 IPv4 IPv6
NAT64 IPv6 IPv4 IPv6 IPv4
NPTv6 IPv6 IPv6 IPv6 IPv6
Figure 5: Address Families with MAP and PEER
图5：使用MAP和PEER的地址族
Note that the internal address and the remote peer address are always the same address family, and the external address and the actual remote peer address are always the same address family.
请注意，内部地址和远程对等地址始终是相同的地址族，而外部地址和实际远程对等地址始终是相同的地址族。
A host operating a server (e.g., a web server) listens for traffic on a port, but the server never initiates traffic from that port. For this to work across a NAT or a firewall, the host needs to (a) create a mapping from a public IP address, protocol, and port to itself using the MAP Opcode, as described in Section 11; (b) publish that public IP address, protocol, and port via some sort of rendezvous server (e.g., DNS, a SIP message, or a proprietary protocol); and (c) ensure that any other non-PCP-speaking packet filtering middleboxes on the path (e.g., host-based firewall, network-based firewall, or other NATs) will also allow the incoming traffic. Publishing the public IP address and port is out of scope of this specification. To accomplish (a), the host follows the procedures described in this section.
操作服务器（例如web服务器）的主机侦听端口上的流量，但服务器从不从该端口发起流量。为了在NAT或防火墙上工作，主机需要（a）使用MAP操作码创建从公共IP地址、协议和端口到自身的映射，如第11节所述；（b） 通过某种集合服务器（例如DNS、SIP消息或专有协议）发布公共IP地址、协议和端口；和（c）确保路径上的任何其他非PCP语音包过滤中间盒（例如，基于主机的防火墙、基于网络的防火墙或其他NAT）也允许传入流量。发布公共IP地址和端口超出了本规范的范围。为了完成（a），主机遵循本节中描述的步骤。
As normal, the application needs to begin listening on a port. Then, the application constructs a PCP message with the MAP Opcode, with the external address set to the appropriate all-zeros address, depending on whether it wants a public IPv4 or IPv6 address.
正常情况下，应用程序需要开始侦听端口。然后，应用程序使用MAP操作码构造PCP消息，外部地址设置为适当的全零地址，具体取决于它想要的是公共IPv4地址还是IPv6地址。
The following pseudocode shows how PCP can be reliably used to operate a server:
以下伪代码显示了如何可靠地使用PCP操作服务器：
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
* The PCP packet sent is identical in all four cases; from
* the PCP server's point of view they are the same operation.
* The suggested external address and port may be updated
* repeatedly during the lifetime of the mapping.
* Other fields in the packet generally remain unchanged.
*/
if (time_to_send_pcp_request())
pcp_send_map_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
* The PCP packet sent is identical in all four cases; from
* the PCP server's point of view they are the same operation.
* The suggested external address and port may be updated
* repeatedly during the lifetime of the mapping.
* Other fields in the packet generally remain unchanged.
*/
if (time_to_send_pcp_request())
pcp_send_map_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
if (pcp_response_received()) update_rendezvous_server("Client Ident", external_sockaddr);
如果（pcp_response_received（））更新_rendezvous_服务器（“客户端标识”，外部_sockaddr）；
if (received_incoming_connection_or_packet()) process_it(s);
如果（接收到\传入\连接\或\数据包（））处理\它；
if (other_work_to_do()) do_it();
如果（其他工作要做）去做它；
/* ... */
/* ... */
block_until_we_need_to_do_something_else();
}
block_until_we_need_to_do_something_else();
}
Figure 6: Pseudocode for Using PCP to Operate a Server
图6：使用PCP操作服务器的伪代码
A host operating a client and server on the same port (e.g., Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) [RFC3581]) first establishes a local listener, (usually) sends the local and public IP addresses, protocol, and ports to a rendezvous service (which is out of scope of this document), and initiates an outbound connection from that same source address and same port. To accomplish this, the application uses the procedure described in this section.
在同一端口（例如，对称RTP[RFC4961]或SIP对称响应路由（rport）[RFC3581]）上操作客户端和服务器的主机首先建立本地侦听器，（通常）将本地和公共IP地址、协议和端口发送到集合服务（不在本文档范围内），并从同一源地址和同一端口启动出站连接。为此，应用程序使用本节中描述的过程。
An application that is using the same port for outgoing connections as well as incoming connections MUST first signal its operation of a server using the PCP MAP Opcode, as described in Section 11, and receive a positive PCP response before it sends any packets from that port.
使用同一端口进行传出连接和传入连接的应用程序必须首先使用PCP MAP操作码（如第11节所述）向服务器发送其操作信号，并在从该端口发送任何数据包之前接收肯定的PCP响应。
Discussion: In general, a PCP client doesn't know in advance if it is behind a NAT or firewall. On detecting that the host has connected to a new network, the PCP client can attempt to request a mapping using PCP; if that succeeds, then the client knows it has successfully created a mapping. If, after multiple retries, it has received no PCP response, then either the client is *not* behind a NAT or firewall and has unfettered connectivity or the client *is* behind a NAT or firewall that doesn't support PCP (and the client may still have working connectivity by virtue of static mappings previously created manually by the user). Retransmitting PCP requests multiple times before giving up and assuming unfettered connectivity adds delay in that case. Initiating outbound TCP connections immediately without waiting for PCP avoids this delay, and will work if the NAT has endpoint-independent mapping (EIM) behavior, but may fail if the NAT has endpoint-dependent mapping (EDM) behavior. Waiting enough time to allow an explicit PCP MAP mapping to be created (if possible) first ensures that the same external port will then be used for all subsequent implicit dynamic mappings (e.g., TCP SYNs) sent from the specified internal address, protocol, and port. PCP supports both EIM and EDM NATs, so clients need to assume they may be dealing with an EDM NAT. In this case, the client will experience more reliable connectivity if it attempts explicit PCP MAP requests first, before initiating any outbound TCP connections from that internal address and port. For further information on using PCP with EDM NATs, see Section 16.1.
讨论：一般来说，PCP客户端事先不知道它是否在NAT或防火墙后面。在检测到主机已连接到新网络时，PCP客户端可尝试使用PCP请求映射；如果成功，则客户端知道它已成功创建映射。如果在多次重试后未收到PCP响应，则客户端*不*在NAT或防火墙后面，并且具有不受限制的连接，或者客户端*在NAT或防火墙后面，不支持PCP（并且客户端可能仍然通过用户先前手动创建的静态映射具有工作连接）。在放弃之前多次重新传输PCP请求，并假设连接不受限制，会在这种情况下增加延迟。在不等待PCP的情况下立即启动出站TCP连接可以避免此延迟，并且在NAT具有端点独立映射（EIM）行为时可以工作，但在NAT具有端点依赖映射（EDM）行为时可能会失败。等待足够的时间以允许首先创建显式PCP映射（如果可能），可确保相同的外部端口随后将用于从指定的内部地址、协议和端口发送的所有后续隐式动态映射（例如TCP SYN）。PCP同时支持EIM和EDM NAT，因此客户端需要假设他们可能正在处理EDM NAT。在这种情况下，如果客户端在从该内部地址和端口启动任何出站TCP连接之前，首先尝试显式PCP MAP请求，那么它将体验到更可靠的连接。有关在EDM NAT中使用PCP的更多信息，请参阅第16.1节。
The following pseudocode shows how PCP can be used to operate a symmetric client and server:
以下伪代码显示了如何使用PCP操作对称客户端和服务器：
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
*/
if (time_to_send_pcp_request())
pcp_send_map_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
*/
if (time_to_send_pcp_request())
pcp_send_map_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
if (pcp_response_received()) update_rendezvous_server("Client Ident", external_sockaddr);
如果（pcp_response_received（））更新_rendezvous_服务器（“客户端标识”，外部_sockaddr）；
if (received_incoming_connection_or_packet()) process_it(s);
如果（接收到\传入\连接\或\数据包（））处理\它；
if (need_to_make_outgoing_connection()) make_outgoing_connection(s, ...);
如果（需要进行输出连接（））进行输出连接；
if (data_to_send()) send_it(s);
如果（数据发送到发送（））发送它；
if (other_work_to_do()) do_it();
如果（其他工作要做）去做它；
/* ... */
/* ... */
block_until_we_need_to_do_something_else();
}
block_until_we_need_to_do_something_else();
}
Figure 7: Pseudocode for Using PCP to Operate a Symmetric Client/Server
图7：使用PCP操作对称客户机/服务器的伪代码
A host operating a client (e.g., XMPP client, SIP client) sends from a port, and may receive responses, but never accepts incoming connections from other remote peers on this port. It wants to ensure that the flow to its remote peer is not terminated (due to inactivity) by an on-path NAT or firewall. To accomplish this, the application uses the procedure described in this section.
操作客户机的主机（例如，XMPP客户机、SIP客户机）从端口发送，并可能接收响应，但从不接受来自该端口上其他远程对等方的传入连接。它希望确保到远程对等方的流不会被路径上的NAT或防火墙终止（由于不活动）。为此，应用程序使用本节中描述的过程。
Middleboxes, such as NATs or firewalls, generally need to see occasional traffic or they will terminate their session state, causing application failures. To avoid this, many applications routinely generate keepalive traffic for the primary (or sole) purpose of maintaining state with such middleboxes. Applications can reduce such application keepalive traffic by using PCP.
诸如NAT或防火墙之类的中间包通常需要看到偶尔的流量，否则它们将终止其会话状态，从而导致应用程序失败。为了避免这种情况，许多应用程序通常会生成keepalive通信量，其主要（或唯一）目的是维护此类中间盒的状态。应用程序可以通过使用PCP减少此类应用程序保持的通信量。
Note: For reasons beyond NAT, an application may find it useful to perform application-level keepalives, such as to detect a broken path between the client and server, keep state alive on the remote peer, or detect a powered-down client. These keepalives are not related to maintaining middlebox state, and PCP cannot do anything useful to reduce those keepalives.
注意：由于NAT以外的原因，应用程序可能会发现执行应用程序级保留非常有用，例如检测客户端和服务器之间的断开路径、保持远程对等机上的状态为活动状态或检测断电的客户端。这些keepalive与维护中间盒状态无关，PCP无法做任何有用的事情来减少这些keepalive。
To use PCP for this function, the application first connects to its server, as normal. Afterwards, it issues a PCP request with the PEER Opcode as described in Section 12 to learn and/or extend the lifetime of its mapping.
要将PCP用于此功能，应用程序首先连接到其服务器，正常情况下。之后，它使用对等操作码发出PCP请求，如第12节所述，以了解和/或延长其映射的生存期。
The following pseudocode shows how PCP can be reliably used with a dynamic socket, for the purposes of reducing application keepalive messages:
以下伪代码显示了如何将PCP与动态套接字可靠地结合使用，以减少应用程序保留消息：
/* make outgoing connection to server */
int s = socket(...);
connect(s, &remote_peer, ...);
/* make outgoing connection to server */
int s = socket(...);
connect(s, &remote_peer, ...);
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
*/
if (time_to_send_pcp_request())
pcp_send_peer_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
remote_peer, requested_lifetime, &assigned_lifetime);
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
*/
if (time_to_send_pcp_request())
pcp_send_peer_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
remote_peer, requested_lifetime, &assigned_lifetime);
if (data_to_send()) send_it(s);
如果（数据发送到发送（））发送它；
if (received_incoming_data()) process_it(s);
如果（接收到的传入数据（））处理它；
if (other_work_to_do()) do_it();
如果（其他工作要做）去做它；
/* ... */
/* ... */
block_until_we_need_to_do_something_else();
}
block_until_we_need_to_do_something_else();
}
Figure 8: Pseudocode Using PCP with a Dynamic Socket
图8：使用带有动态套接字的PCP的伪代码
After a NAT loses state (e.g., because of a crash or power failure), it is useful for clients to re-establish TCP mappings on the NAT. This allows servers on the Internet to see traffic from the same IP address and port, so that sessions can be resumed exactly where they were left off. This can be useful for long-lived connections
NAT失去状态后（例如，由于崩溃或电源故障），客户端在NAT上重新建立TCP映射非常有用。这允许Internet上的服务器查看来自相同IP地址和端口的通信量，以便会话可以在中断的位置恢复。这对于长寿命连接很有用
(e.g., instant messaging) or for connections transferring a lot of data (e.g., FTP). This can be accomplished by first establishing a TCP connection normally and then sending a PEER request/response and remembering the external address and external port. Later, when the NAT has lost state, the client can send a PEER request with the suggested external port and suggested external address remembered from the previous session, which will create a mapping in the NAT that functions exactly as an implicit dynamic mapping. The client then resumes sending TCP data to the server.
（例如，即时消息）或用于传输大量数据的连接（例如，FTP）。这可以通过首先正常建立TCP连接，然后发送对等请求/响应并记住外部地址和外部端口来实现。稍后，当NAT失去状态时，客户端可以发送一个对等请求，其中包含建议的外部端口和从上一个会话中记住的建议的外部地址，这将在NAT中创建一个映射，该映射的功能与隐式动态映射完全相同。然后，客户端继续向服务器发送TCP数据。
Note: This procedure works well for TCP, provided:
注：此过程适用于TCP，前提是：
(i) the NAT creates a new implicit dynamic outbound mapping only for outbound TCP segments with the SYN bit set (i.e., the newly booted NAT silently drops outbound data segments from the client when the NAT does not have an active mapping for those segments), and
(i) NAT仅为设置了SYN位的出站TCP段创建一个新的隐式动态出站映射（即，当NAT没有这些段的活动映射时，新启动的NAT会自动从客户端删除出站数据段），以及
(ii) the newly booted NAT does not send a TCP RST in response to receiving unexpected inbound TCP segments.
（ii）新启动的NAT不会发送TCP RST以响应接收到的意外入站TCP段。
This procedure works less well for UDP, because as soon as outbound UDP traffic is seen by the NAT, a new UDP implicit dynamic outbound mapping will be created (probably on a different port).
此过程对于UDP的效果不太好，因为NAT一旦看到出站UDP流量，就会创建一个新的UDP隐式动态出站映射（可能在不同的端口上）。
This section defines an Opcode that controls inbound forwarding from a NAT (or firewall) to an internal host.
本节定义一个操作码，用于控制从NAT（或防火墙）到内部主机的入站转发。
MAP: Create an explicit dynamic mapping between an Internal Address + Port and an External Address + Port.
映射：在内部地址+端口和外部地址+端口之间创建显式动态映射。
PCP servers SHOULD provide a configuration option to allow administrators to disable MAP support if they wish.
PCP服务器应提供一个配置选项，允许管理员在需要时禁用映射支持。
Mappings created by PCP MAP requests are, by definition, endpoint-independent mappings (EIMs) with endpoint-independent filtering (EIF) (unless the FILTER option is used), even on a NAT that usually creates endpoint-dependent mapping (EDM) or endpoint-dependent filtering (EDF) for outgoing connections, since the purpose of an (unfiltered) MAP mapping is to receive inbound traffic from any remote endpoint, not from only one specific remote endpoint.
根据定义，由PCP映射请求创建的映射是具有端点独立筛选（EIF）的端点独立映射（EIM）（除非使用了筛选选项），即使是在通常为传出连接创建端点依赖映射（EDM）或端点依赖筛选（EDF）的NAT上，因为映射是从任何远程端点接收入站流量，而不仅仅是从一个特定的远程端点。
Note also that all NAT mappings (created by PCP or otherwise) are by necessity bidirectional and symmetric. For any packet going in one direction (in or out) that is translated by the NAT, a reply going in
还要注意，所有NAT映射（由PCP或其他方式创建）都必须是双向和对称的。对于NAT翻译的朝一个方向（输入或输出）的任何数据包，一个进入的应答
the opposite direction needs to have the corresponding opposite translation done so that the reply arrives at the right endpoint. This means that if a client creates a MAP mapping, and then later sends an outgoing packet using the mapping's internal address, protocol, and port, the NAT should translate that packet's internal address and port to the mapping's external address and port, so that replies addressed to the external address and port are correctly translated back to the mapping's internal address and port.
相反的方向需要进行相应的相反的翻译，以便回复到达正确的端点。这意味着，如果客户端创建映射，然后使用映射的内部地址、协议和端口发送传出数据包，NAT应将该数据包的内部地址和端口转换为映射的外部地址和端口，这样，发往外部地址和端口的回复将正确地转换回映射的内部地址和端口。
On operating systems that allow multiple listening servers to bind to the same internal address, protocol, and port, servers MUST ensure that they have exclusive use of that internal address, protocol, and port (e.g., by binding the port using INADDR_ANY, or using SO_EXCLUSIVEADDRUSE or similar) before sending their PCP MAP request, to ensure that no other PCP clients on the same machine are also listening on the same internal protocol and internal port.
在允许多个侦听服务器绑定到同一内部地址、协议和端口的操作系统上，服务器必须确保在发送其PCP映射请求之前独占使用该内部地址、协议和端口（例如，通过使用INADDR_ANY或使用SO_ExclusiveeAddruse或类似工具绑定端口），确保同一台计算机上的其他PCP客户端也在侦听同一内部协议和内部端口。
As a side effect of creating a mapping, ICMP messages associated with the mapping MUST be forwarded (and also translated, if appropriate) for the duration of the mapping's lifetime. This is done to ensure that ICMP messages can still be used by hosts, without application programmers or PCP client implementations needing to use PCP separately to create ICMP mappings for those flows.
作为创建映射的一个副作用，与映射相关联的ICMP消息必须在映射的生存期内转发（并在适当的情况下进行翻译）。这样做是为了确保主机仍然可以使用ICMP消息，而无需应用程序程序员或PCP客户端实现单独使用PCP为这些流创建ICMP映射。
The operation of the MAP Opcode is described in this section.
本节介绍了MAP操作码的操作。
The MAP Opcode has a similar packet layout for both requests and responses. If the assigned external IP address and port in the PCP response always match the internal IP address and port from the PCP request, then the functionality is purely a firewall; otherwise, the functionality is a Network Address Translator that might also perform firewall-like functions.
MAP操作码对于请求和响应都具有类似的数据包布局。如果PCP响应中分配的外部IP地址和端口始终与PCP请求中的内部IP地址和端口匹配，则该功能纯粹是防火墙；否则，该功能是一个网络地址转换器，也可以执行类似防火墙的功能。
The following diagram shows the format of the Opcode-specific information in a request for the MAP Opcode.
下图显示了MAP操作码请求中操作码特定信息的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Suggested External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Suggested External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: MAP Opcode Request
图9：映射操作码请求
These fields are described below:
这些字段描述如下：
Requested lifetime (in common header): Requested lifetime of this mapping, in seconds. The value 0 indicates "delete".
请求的生存期（在公共标头中）：此映射的请求生存期，以秒为单位。值0表示“删除”。
Mapping Nonce: Random value chosen by the PCP client. See Section 11.2, "Generating a MAP Request". Zero is a legal value (but unlikely, occurring in roughly one in 2^96 requests).
映射Nonce：由PCP客户端选择的随机值。参见第11.2节“生成映射请求”。零是一个法定值（但不太可能，大约每2^96个请求中就有一个请求为零）。
Protocol: Upper-layer protocol associated with this Opcode. Values are taken from the IANA protocol registry [proto_numbers]. For example, this field contains 6 (TCP) if the Opcode is intended to create a TCP mapping. This field contains 17 (UDP) if the Opcode is intended to create a UDP mapping. The value 0 has a special meaning for 'all protocols'.
协议：与此操作码关联的上层协议。值取自IANA协议注册表[协议编号]。例如，如果操作码用于创建TCP映射，则此字段包含6（TCP）。如果操作码用于创建UDP映射，则此字段包含17（UDP）。值0对“所有协议”具有特殊意义。
Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored when received.
保留：24个保留位，必须作为0发送，接收时必须忽略。
Internal Port: Internal port for the mapping. The value 0 indicates 'all ports', and is legal when the lifetime is zero (a delete request), if the protocol does not use 16-bit port numbers, or the client is requesting 'all ports'. If the protocol is zero (meaning 'all protocols'), then internal port MUST be zero on transmission and MUST be ignored on reception.
内部端口：映射的内部端口。如果协议不使用16位端口号，或者客户端请求“所有端口”，则值0表示“所有端口”，并且在生存期为零（删除请求）时是合法的。如果协议为零（表示“所有协议”），则内部端口在传输时必须为零，在接收时必须忽略。
Suggested External Port: Suggested external port for the mapping. This is useful for refreshing a mapping, especially after the PCP server loses state. If the PCP client does not know the external port, or does not have a preference, it MUST use 0.
建议的外部端口：映射的建议外部端口。这对于刷新映射非常有用，尤其是在PCP服务器失去状态之后。如果PCP客户端不知道外部端口，或者没有首选项，则必须使用0。
Suggested External IP Address: Suggested external IPv4 or IPv6 address. This is useful for refreshing a mapping, especially after the PCP server loses state. If the PCP client does not know the external address, or does not have a preference, it MUST use the address-family-specific all-zeros address (see Section 5).
建议的外部IP地址：建议的外部IPv4或IPv6地址。这对于刷新映射非常有用，尤其是在PCP服务器失去状态之后。如果PCP客户端不知道外部地址或没有首选项，则必须使用特定于地址系列的全零地址（请参阅第5节）。
The internal address for the request is the source IP address of the PCP request message itself, unless the THIRD_PARTY option is used.
请求的内部地址是PCP请求消息本身的源IP地址，除非使用第三方选项。
The following diagram shows the format of Opcode-specific information in a response packet for the MAP Opcode:
下图显示了MAP操作码响应包中操作码特定信息的格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Assigned External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Assigned External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MAP Opcode Response
图10:MAP操作码响应
These fields are described below:
这些字段描述如下：
Lifetime (in common header): On an error response, this indicates how long clients should assume they'll get the same error response from the PCP server if they repeat the same request. On a success response, this indicates the lifetime for this mapping, in seconds.
生存期（在公共标头中）：在错误响应上，这表示如果客户端重复相同的请求，则客户端应假定从PCP服务器获得相同的错误响应的时间。在成功响应中，这表示此映射的生存期（以秒为单位）。
Mapping Nonce: Copied from the request.
映射Nonce：从请求中复制。
Protocol: Copied from the request.
协议：从请求中复制。
Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored when received.
保留：24个保留位，必须作为0发送，接收时必须忽略。
Internal Port: Copied from the request.
内部端口：从请求复制。
Assigned External Port: On a success response, this is the assigned external port for the mapping. On an error response, the suggested external port is copied from the request.
分配的外部端口：在成功响应时，这是为映射分配的外部端口。在错误响应中，从请求复制建议的外部端口。
Assigned External IP Address: On a success response, this is the assigned external IPv4 or IPv6 address for the mapping. An IPv4 address is encoded using IPv4-mapped IPv6 address. On an error response, the suggested external IP address is copied from the request.
分配的外部IP地址：在成功响应中，这是为映射分配的外部IPv4或IPv6地址。IPv4地址使用IPv4映射的IPv6地址进行编码。在错误响应中，建议的外部IP地址将从请求中复制。
This section describes the operation of a PCP client when sending requests with the MAP Opcode.
本节介绍使用MAP操作码发送请求时PCP客户端的操作。
The request MAY contain values in the Suggested External Port and Suggested External IP Address fields. This allows the PCP client to attempt to rebuild lost state on the PCP server, which improves the chances of existing connections surviving, and helps the PCP client avoid having to change information maintained at its rendezvous server. Of course, due to other activity on the network (e.g., by other users or network renumbering), the PCP server may not be able to grant the suggested external IP address, protocol, and port, and in that case it will assign a different external IP address and port.
请求可能包含建议的外部端口和建议的外部IP地址字段中的值。这允许PCP客户端尝试在PCP服务器上重建丢失状态，从而提高现有连接存活的机会，并帮助PCP客户端避免更改其集合服务器上维护的信息。当然，由于网络上的其他活动（例如，由其他用户或网络重新编号），PCP服务器可能无法授予建议的外部IP地址、协议和端口，在这种情况下，它将分配不同的外部IP地址和端口。
A PCP client MUST be written assuming that it may *never* be assigned the external port it suggests. In the case of recreating state after a NAT gateway crash, the suggested external port, being one that was previously allocated to this client, is likely to be available for this client to continue using. In all other cases, the client MUST assume that it is unlikely that its suggested external port will be granted. For example, when many subscribers are sharing a Carrier-Grade NAT, popular ports such as 80, 443, and 8080 are likely to be in high demand. At most one client can have each of those popular ports for each external IP address, and all the other clients will be assigned other, dynamically allocated, external ports. Indeed, some ISPs may, by policy, choose not to grant those external ports to *anyone*, so that none of their clients are *ever* assigned external ports 80, 443, or 8080.
必须编写PCP客户端，假设它可能“永远”不会被分配到它建议的外部端口。在NAT网关崩溃后重新创建状态的情况下，建议的外部端口（先前分配给此客户端的端口）可能可供此客户端继续使用。在所有其他情况下，客户必须假设其建议的外部端口不太可能被授予。例如，当许多用户共享载波级NAT时，诸如80、443和8080等流行端口的需求量可能很大。对于每个外部IP地址，最多一个客户机可以拥有这些常用端口中的每一个，所有其他客户机将被分配其他动态分配的外部端口。事实上，一些ISP可能会根据政策选择不将这些外部端口授予*任何人*，因此他们的客户机都*从未*分配外部端口80、443或8080。
If the protocol does not use 16-bit port numbers (e.g., RSVP, IP protocol number 46), the port number MUST be zero. This will cause all traffic matching that protocol to be mapped.
如果协议不使用16位端口号（例如RSVP、IP协议号46），则端口号必须为零。这将导致映射与该协议匹配的所有通信量。
If the client wants all protocols mapped, it uses protocol 0 (zero) and internal port 0 (zero).
如果客户端希望映射所有协议，则使用协议0（零）和内部端口0（零）。
The Mapping Nonce value is randomly chosen by the PCP client, following accepted practices for generating unguessable random numbers [RFC4086], and is used as part of the validation of PCP responses (see below) by the PCP client, and validation for mapping refreshes by the PCP server. The client MUST use a different mapping nonce for each PCP server it communicates with, and it is RECOMMENDED to choose a new random mapping nonce whenever the PCP client is initialized. The client MAY use a different mapping nonce for every mapping.
映射Nonce值由PCP客户端按照生成不可用随机数的公认实践[RFC4086]随机选择，并用作PCP客户端验证PCP响应（见下文）和PCP服务器验证映射刷新的一部分。客户端必须为与其通信的每个PCP服务器使用不同的映射nonce，建议在初始化PCP客户端时选择一个新的随机映射nonce。客户机可以对每个映射使用不同的映射nonce。
An existing mapping SHOULD have its lifetime extended by the PCP client for as long as the client wishes to have that mapping continue to exist. To do this, the PCP client sends a new MAP request indicating the internal port. The PCP MAP request SHOULD also include the currently assigned external IP address and port in the Suggested External IP Address and Suggested External Port fields, so if the PCP server has lost state it can recreate the lost mapping with the same parameters.
只要客户端希望映射继续存在，PCP客户端就应该延长现有映射的生存期。为此，PCP客户端发送一个指示内部端口的新映射请求。PCP映射请求还应在建议的外部IP地址和建议的外部端口字段中包括当前分配的外部IP地址和端口，因此，如果PCP服务器已丢失状态，则可以使用相同的参数重新创建丢失的映射。
The PCP client SHOULD renew the mapping before its expiry time; otherwise, it will be removed by the PCP server (see Section 15, "Mapping Lifetime and Deletion"). To reduce the risk of inadvertent synchronization of renewal requests, a random jitter component should be included. It is RECOMMENDED that PCP clients send a single renewal request packet at a time chosen with uniform random distribution in the range 1/2 to 5/8 of expiration time. If no SUCCESS response is received, then the next renewal request should be sent 3/4 to 3/4 + 1/16 to expiration, and then another 7/8 to 7/8 + 1/32 to expiration, and so on, subject to the constraint that renewal requests MUST NOT be sent less than four seconds apart (a PCP client MUST NOT send a flood of ever-closer-together requests in the last few seconds before a mapping expires).
PCP客户应在映射到期前更新映射；否则，它将被PCP服务器删除（请参阅第15节“映射生存期和删除”）。为了减少意外同步续订请求的风险，应包括随机抖动组件。建议PCP客户端在到期时间的1/2到5/8范围内以均匀随机分布选择的时间发送单个续订请求数据包。如果未收到成功响应，则应发送下一个续订请求3/4至3/4+1/16至到期，然后再发送另一个7/8至7/8+1/32至到期，依此类推，但受续订请求间隔不得少于4秒的限制（在映射过期之前的最后几秒钟内，PCP客户端不得发送大量越来越近的请求）。
This section describes the operation of a PCP server when processing a request with the MAP Opcode. Processing SHOULD be performed in the order of the following paragraphs.
本节介绍使用MAP操作码处理请求时PCP服务器的操作。应按照以下段落的顺序进行处理。
The Protocol, Internal Port, and Mapping Nonce fields from the MAP request are copied into the MAP response. The THIRD_PARTY option, if present, and processed by the PCP server, is also copied into the MAP response.
映射请求中的协议、内部端口和映射Nonce字段被复制到映射响应中。第三方选项（如果存在）并由PCP服务器处理，也会复制到MAP响应中。
If the requested lifetime is non-zero, then:
如果请求的生存期非零，则：
o If both the protocol and internal port are non-zero, it indicates a request to create a mapping or extend the lifetime of an existing mapping. If the PCP server or PCP-controlled device does not support the protocol, the UNSUPP_PROTOCOL error MUST be returned.
o 如果协议和内部端口均为非零，则表示请求创建映射或延长现有映射的生存期。如果PCP服务器或PCP控制的设备不支持该协议，则必须返回UNSUPP_协议错误。
o If the protocol is non-zero and the internal port is zero, it indicates a request to create or extend a mapping for all incoming traffic for that entire protocol -- a 'wildcard' (all-ports) mapping for that protocol. If this request cannot be fulfilled in its entirety, the UNSUPP_PROTOCOL error MUST be returned.
o 如果协议为非零且内部端口为零，则表示请求为整个协议的所有传入流量创建或扩展映射——该协议的“通配符”（所有端口）映射。如果无法完全满足此请求，则必须返回UNSUPP_协议错误。
o If both the protocol and internal port are zero, it indicates a request to create or extend a mapping for all incoming traffic for all protocols (commonly called a 'DMZ host'). If this request cannot be fulfilled in its entirety, the UNSUPP_PROTOCOL error MUST be returned.
o 如果协议和内部端口均为零，则表示请求为所有协议（通常称为“DMZ主机”）的所有传入流量创建或扩展映射。如果无法完全满足此请求，则必须返回UNSUPP_协议错误。
o If the protocol is zero and the internal port is non-zero, then the request is invalid and the PCP server MUST return a MALFORMED_REQUEST error to the client.
o 如果协议为零且内部端口为非零，则请求无效，PCP服务器必须向客户端返回格式错误的_请求错误。
If the requested lifetime is zero, it indicates a request to delete an existing mapping.
如果请求的生存期为零，则表示请求删除现有映射。
Further processing of the lifetime is described in Section 15, "Mapping Lifetime and Deletion".
第15节“映射生存期和删除”中描述了生存期的进一步处理。
If operating in the Simple Threat Model (Section 18.1), and the internal port, protocol, and internal address match an existing explicit dynamic mapping, but the mapping nonce does not match, the request MUST be rejected with a NOT_AUTHORIZED error with the lifetime of the error indicating duration of that existing mapping. The PCP server only needs to remember one Mapping Nonce value for each explicit dynamic mapping. This specification makes no statement about mapping nonce with the Advanced Threat Model.
如果在简单威胁模型（第18.1节）中运行，且内部端口、协议和内部地址与现有显式动态映射匹配，但映射nonce不匹配，则必须拒绝请求，并出现未授权错误，错误的生存期表示该现有映射的持续时间。PCP服务器只需要为每个显式动态映射记住一个映射Nonce值。本规范未说明如何使用高级威胁模型映射nonce。
If the internal port, protocol, and internal address match an existing static mapping (which will have no nonce), then a PCP reply is sent giving the external address and port of that static mapping, using the nonce from the PCP request. The server does not record the nonce.
如果内部端口、协议和内部地址与现有静态映射（没有nonce）匹配，则发送PCP应答，使用PCP请求中的nonce给出该静态映射的外部地址和端口。服务器不记录nonce。
If an option with value less than 128 exists (i.e., mandatory to process) but that option does not make sense (e.g., the PREFER_FAILURE option is included in a request with lifetime=0), the request is invalid and generates a MALFORMED_OPTION error.
如果存在一个值小于128的选项（即必须处理），但该选项没有意义（例如，在生存期为0的请求中包含Preference_FAILURE选项），则该请求无效，并生成格式错误的_选项错误。
If the PCP-controlled device is stateless (that is, it does not establish any per-flow state, and simply rewrites the address and/or port in a purely algorithmic fashion, including no rewriting), the PCP server simply returns an answer indicating the external IP address and port yielded by this stateless algorithmic translation. This allows the PCP client to learn its external IP address and port as seen by remote peers. Examples of stateless translators include stateless NAT64, 1:1 NAT44, and NPTv6 [RFC6296], all of which modify addresses but not port numbers, and pure firewalls, which modify neither the address nor the port.
如果PCP控制的设备是无状态的（即，它不建立任何每流状态，并且仅以纯算法方式重写地址和/或端口，包括不重写），则PCP服务器仅返回指示此无状态算法转换产生的外部IP地址和端口的应答。这允许PCP客户端了解远程对等方看到的外部IP地址和端口。无状态转换器的示例包括无状态NAT64、1:1 NAT44和NPTv6[RFC6296]，它们都修改地址，但不修改端口号，以及纯防火墙，它们既不修改地址也不修改端口。
It is possible that a mapping might already exist for a requested internal address, protocol, and port. If so, the PCP server takes the following actions:
请求的内部地址、协议和端口可能已经存在映射。如果是，PCP服务器将执行以下操作：
1. If the MAP request contains the PREFER_FAILURE option, but the suggested external address and port do not match the external address and port of the existing mapping, the PCP server MUST return CANNOT_PROVIDE_EXTERNAL.
1. 如果映射请求包含prefere_FAILURE选项，但建议的外部地址和端口与现有映射的外部地址和端口不匹配，则PCP服务器必须返回CANNOT_PROVIDE_external。
2. If the existing mapping is static (created outside of PCP), the PCP server MUST return the external address and port of the existing mapping in its response and SHOULD indicate a lifetime of 2^32-1 seconds, regardless of the suggested external address and port in the request.
2. 如果现有映射是静态的（在PCP之外创建），则PCP服务器必须在其响应中返回现有映射的外部地址和端口，并且应该指示2^32-1秒的生存期，而不管请求中建议的外部地址和端口如何。
3. If the existing mapping is explicit dynamic inbound (created by a previous MAP request), the PCP server MUST return the existing external address and port in its response, regardless of the suggested external address and port in the request. Additionally, the PCP server MUST update the lifetime of the existing mapping, in accordance with Section 15, "Mapping Lifetime and Deletion".
3. 如果现有映射是显式动态入站（由以前的映射请求创建），则PCP服务器必须在其响应中返回现有的外部地址和端口，而不管请求中建议的外部地址和端口如何。此外，PCP服务器必须根据第15节“映射生存期和删除”更新现有映射的生存期。
4. If the existing mapping is dynamic outbound (created by outgoing traffic or a previous PEER request), the PCP server SHOULD create a new explicit inbound mapping, replicating the ports and addresses from the outbound mapping (but the outbound mapping continues to exist, and remains in effect if the explicit inbound mapping is later deleted).
4. 如果现有映射是动态出站映射（由出站流量或以前的对等请求创建），则PCP服务器应创建新的显式入站映射，复制出站映射中的端口和地址（但出站映射继续存在，并在以后删除显式入站映射时保持有效）。
If no mapping exists for the internal address, protocol, and port, and the PCP server is able to create a mapping using the suggested
如果内部地址、协议和端口不存在映射，并且PCP服务器能够使用建议的
external address and port, it SHOULD do so. This is beneficial for re-establishing state lost in the PCP server (e.g., due to a reboot). There are, however, cases where the PCP server is not able to create a new mapping using the suggested external address and port:
外部地址和端口，它应该这样做。这有利于重新建立PCP服务器中丢失的状态（例如，由于重新启动）。但是，在某些情况下，PCP服务器无法使用建议的外部地址和端口创建新映射：
o The suggested external address, protocol, and port is already assigned to another existing explicit or implicit mapping (i.e., is already forwarding traffic to some other internal address and port).
o 建议的外部地址、协议和端口已分配给另一个现有的显式或隐式映射（即，已将流量转发到其他一些内部地址和端口）。
o The suggested external address, protocol, and port is already used by the NAT gateway for one of its own services, for example, TCP port 80 for the NAT gateway's own configuration web pages, or UDP ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT create client mappings for external UDP ports 5350 or 5351.
o NAT网关已将建议的外部地址、协议和端口用于其自身的一项服务，例如，NAT网关自身配置网页的TCP端口80，或PCP自身使用的UDP端口5350和5351。PCP服务器不得为外部UDP端口5350或5351创建客户端映射。
o The suggested external address, protocol, and port is otherwise prohibited by the PCP server's policy.
o PCP服务器的策略禁止使用建议的外部地址、协议和端口。
o The suggested external IP address, protocol, or suggested port are invalid or invalid combinations (e.g., external address 127.0.0.1, ::1, a multicast address, or the suggested port is not valid for the protocol).
o 建议的外部IP地址、协议或建议的端口无效或组合无效（例如，外部地址127.0.0.1、：：1、多播地址或建议的端口对协议无效）。
o The suggested external address does not belong to the NAT gateway.
o 建议的外部地址不属于NAT网关。
o The suggested external address is not configured to be used as an external address of the firewall or NAT gateway.
o 建议的外部地址未配置为用作防火墙或NAT网关的外部地址。
If the PCP server cannot assign the suggested external address, protocol, and port, then:
如果PCP服务器无法分配建议的外部地址、协议和端口，则：
o If the request contained the PREFER_FAILURE option, then the PCP server MUST return CANNOT_PROVIDE_EXTERNAL.
o 如果请求包含prefere\u FAILURE选项，则PCP服务器必须返回CANNOT\u PROVIDE\u EXTERNAL。
o If the request did not contain the PREFER_FAILURE option, and the PCP server can assign some other external address and port for that protocol, then the PCP server MUST do so and return the newly assigned external address and port in the response. In no case is the client penalized for a 'poor' choice of suggested external address and port. The suggested external address and port may be used by the server to guide its choice of what external address and port to assign, but in no case do they cause the server to fail to allocate an external address and port where otherwise it would have succeeded. The presence of a non-zero suggested external address or port is merely a hint; it never does any harm.
o 如果请求不包含prefere_FAILURE选项，并且PCP服务器可以为该协议分配其他一些外部地址和端口，则PCP服务器必须这样做，并在响应中返回新分配的外部地址和端口。在任何情况下，客户都不会因为对建议的外部地址和端口的“糟糕”选择而受到处罚。服务器可以使用建议的外部地址和端口来指导其选择要分配的外部地址和端口，但在任何情况下，它们都不会导致服务器无法分配外部地址和端口，否则它会成功。建议的非零外部地址或端口的存在只是一个提示；它从来不会造成任何伤害。
A PCP-controlled device MUST NOT create mappings for a protocol not indicated in the request. For example, if the request was for a TCP mapping, an additional corresponding UDP mapping MUST NOT be automatically created.
PCP控制的设备不得为请求中未指明的协议创建映射。例如，如果请求是TCP映射，则不能自动创建其他相应的UDP映射。
Mappings typically consume state on the PCP-controlled device, and it is RECOMMENDED that a per-host and/or per-subscriber limit be enforced by the PCP server to prevent exhausting the mapping state. If this limit is exceeded, the result code USER_EX_QUOTA is returned.
映射通常使用PCP控制设备上的状态，建议PCP服务器强制执行每主机和/或每订户限制，以防止耗尽映射状态。如果超过此限制，则返回结果代码USER_EX_QUOTA。
If all of the preceding operations were successful (did not generate an error response), then the requested mapping is created or refreshed as described in the request and a SUCCESS response is built.
如果前面的所有操作都成功（未生成错误响应），则将按照请求中的说明创建或刷新请求的映射，并生成成功响应。
This section describes the operation of the PCP client when it receives a PCP response for the MAP Opcode.
本节介绍PCP客户端在收到MAP操作码的PCP响应时的操作。
After performing common PCP response processing, the response is further matched with a previously sent MAP request by comparing the internal IP address (the destination IP address of the PCP response, or other IP address specified via the THIRD_PARTY option), the protocol, the internal port, and the mapping nonce. Other fields are not compared, because the PCP server sets those fields. The PCP server will send a Mapping Update (Section 14.2) if the mapping changes (e.g., due to IP renumbering).
在执行公共PCP响应处理之后，通过比较内部IP地址（PCP响应的目标IP地址或通过第三方选项指定的其他IP地址）、协议、内部端口和映射nonce，将响应进一步与先前发送的MAP请求匹配。不会比较其他字段，因为PCP服务器会设置这些字段。如果映射发生变化（例如，由于IP重新编号），PCP服务器将发送映射更新（第14.2节）。
If the result code is NO_RESOURCES and the request was for the creation or renewal of a mapping, then the PCP client SHOULD NOT send further requests for any new mappings to that PCP server for the (limited) value of the lifetime. If the result code is NO_RESOURCES and the request was for the deletion of a mapping, then the PCP client SHOULD NOT send further requests of *any kind* to that PCP server for the (limited) value of the lifetime.
如果结果代码为NO_RESOURCES，且请求用于创建或续订映射，则PCP客户端不应在生存期的（有限）值内向该PCP服务器发送任何新映射的进一步请求。如果结果代码为NO_RESOURCES，且请求是删除映射，则PCP客户端不应在生存期的（有限）值内向该PCP服务器发送进一步的*任何类型的*请求。
On a success response, the PCP client can use the external IP address and port as needed. Typically, the PCP client will communicate the external IP address and port to another host on the Internet using an application-specific rendezvous mechanism such as DNS SRV records.
在成功响应时，PCP客户端可以根据需要使用外部IP地址和端口。通常，PCP客户端将使用特定于应用程序的会合机制（如DNS SRV记录）将外部IP地址和端口与Internet上的另一台主机进行通信。
After a success response, for as long as renewal is desired, the PCP client MUST set a timer or otherwise schedule an event to renew the mapping before its lifetime expires. Renewing a mapping is performed by sending another MAP request, exactly as described in Section 11.2, except that the suggested external address and port SHOULD be set to the values received in the response. From the PCP server's point of
响应成功后，只要需要续订，PCP客户端就必须设置计时器或安排事件，以便在映射的生存期到期之前续订映射。更新映射是通过发送另一个映射请求来执行的，完全如第11.2节所述，但建议的外部地址和端口应设置为响应中接收的值。从PCP服务器的角度
view a MAP request to renew a mapping is identical to a MAP request to create a new mapping, and is handled identically. Indeed, in the event of PCP server state loss, a renewal request from a PCP client will appear to the server to be a request to create a new mapping, with a particular suggested external address and port, which happen to be what the PCP server previously assigned. See also Section 16.3.1, "Recreating Mappings".
查看更新映射的映射请求与创建新映射的映射请求相同，处理方式相同。实际上，在PCP服务器状态丢失的情况下，来自PCP客户端的续订请求在服务器看来似乎是创建新映射的请求，具有特定的建议外部地址和端口，这恰好是PCP服务器以前分配的。另请参见第16.3.1节“重新创建映射”。
On an error response, the client SHOULD NOT repeat the same request to the same PCP server within the lifetime returned in the response.
在错误响应中，客户端不应在响应中返回的生存期内向同一PCP服务器重复相同的请求。
A customer premises router might obtain a new external IP address, for a variety of reasons including a reboot, power outage, DHCP lease expiry, or other action by the ISP. If this occurs, traffic forwarded to a host's previous address might be delivered to another host that now has that address. This affects all mapping types, whether implicit or explicit. This same problem already occurs today when a host's IP address is reassigned, without PCP and without an ISP-operated CGN. The solution is the same as today: the problems associated with host renumbering are caused by host renumbering, and are eliminated if host renumbering is avoided. PCP defined in this document does not provide machinery to reduce the host renumbering problem.
由于各种原因，包括重新启动、断电、DHCP租约到期或ISP采取的其他措施，客户场所路由器可能会获得新的外部IP地址。如果发生这种情况，转发到主机以前地址的流量可能会传递到现在拥有该地址的另一台主机。这会影响所有映射类型，无论是隐式还是显式。今天，在没有PCP和ISP操作的CGN的情况下重新分配主机的IP地址时，同样的问题已经出现。解决方案与今天相同：与主机重新编号相关的问题是由主机重新编号引起的，如果避免主机重新编号，这些问题将被消除。本文件中定义的PCP不提供减少主机重新编号问题的机制。
When an internal host changes its internal IP address (e.g., by having a different address assigned by the DHCP server), the NAT (or firewall) will continue to send traffic to the old IP address. Typically, the internal host will no longer receive traffic sent to that old IP address. Assuming the internal host wants to continue receiving traffic, it needs to install new mappings for its new IP address. The Suggested External Port field will not be fulfilled by the PCP server, in all likelihood, because it is still being forwarded to the old IP address. Thus, a mapping is likely to be assigned a new external port number and/or external IP address. Note that such host renumbering is not expected to happen routinely on a regular basis for most hosts, since most hosts renew their DHCP leases before they expire (or re-request the same address after reboot) and most DHCP servers honor such requests and grant the host the same address it was previously using before the reboot.
当内部主机更改其内部IP地址时（例如，通过DHCP服务器分配不同的地址），NAT（或防火墙）将继续向旧IP地址发送流量。通常，内部主机将不再接收发送到该旧IP地址的流量。假设内部主机希望继续接收流量，它需要为其新IP地址安装新映射。PCP服务器很可能不会满足建议的外部端口字段，因为它仍在转发到旧IP地址。因此，映射可能被分配一个新的外部端口号和/或外部IP地址。请注意，对于大多数主机，此类主机重新编号预计不会定期进行，因为大多数主机在DHCP租约到期之前续订（或在重新启动后重新请求相同的地址），并且大多数DHCP服务器会满足此类请求，并授予主机以前在重新启动前使用的相同地址。
A host might gain or lose interfaces while existing mappings are active (e.g., Ethernet cable plugged in or removed, joining/leaving a WiFi network). Because of this, if the PCP client is sending a PCP request to maintain state in the PCP server, it SHOULD ensure that those PCP requests continue to use the same interface (e.g., when refreshing mappings). If the PCP client is sending a PCP request to
当现有映射处于活动状态时，主机可能会获得或丢失接口（例如，插入或移除以太网电缆，加入/离开WiFi网络）。因此，如果PCP客户端发送PCP请求以维护PCP服务器中的状态，则应确保这些PCP请求继续使用相同的接口（例如，在刷新映射时）。如果PCP客户端正在向发送PCP请求
create new state in the PCP server, it MAY use a different source interface or different source address.
在PCP服务器中创建新状态，它可能使用不同的源接口或不同的源地址。
NAT-PMP [RFC6886] includes a mechanism to allow clients to learn the external IP address alone, without also requesting a port mapping. NAT-PMP was designed for residential NAT gateways, where such an operation makes sense because a typical residential NAT gateway has only one external IP address. PCP has broader scope, and also supports Carrier-Grade NATs (CGNs) that may have a pool of external IP addresses, not just one. A client may not be assigned any particular external IP address from that pool until it has at least one implicit, explicit, or static port mapping, and even then only for as long as that mapping remains valid. Client software that just wishes to display the user's external IP address for cosmetic purposes can achieve that by requesting a short-lived mapping (e.g., to the Discard service (TCP/9 or UDP/9) or some other port) and then displaying the resulting external IP address. However, once that mapping expires a subsequent implicit or explicit dynamic mapping might be mapped to a different external IP address.
NAT-PMP[RFC6886]包括一种机制，允许客户端单独学习外部IP地址，而无需请求端口映射。NAT-PMP是为住宅NAT网关设计的，这种操作是有意义的，因为典型的住宅NAT网关只有一个外部IP地址。PCP的范围更广，还支持运营商级NAT（CGN），该NAT可能有一个外部IP地址池，而不仅仅是一个。在客户端至少有一个隐式、显式或静态端口映射之前，不能从该池向其分配任何特定的外部IP地址，即使这样，也只能在该映射保持有效的情况下分配。仅希望出于装饰目的显示用户外部IP地址的客户端软件可以通过请求短期映射（例如，到丢弃服务（TCP/9或UDP/9）或某些其他端口）然后显示生成的外部IP地址来实现。但是，一旦映射过期，随后的隐式或显式动态映射可能会映射到不同的外部IP地址。
This section defines an Opcode for controlling dynamic outbound mappings.
本节定义用于控制动态出站映射的操作码。
PEER: Create a new dynamic outbound mapping to a remote peer's IP address and port, or extend the lifetime of an existing outbound mapping.
对等：创建到远程对等IP地址和端口的新动态出站映射，或延长现有出站映射的生存期。
The use of this Opcodes is described in this section.
本节介绍了该操作码的使用。
PCP servers SHOULD provide a configuration option to allow administrators to disable PEER support if they wish.
PCP服务器应提供一个配置选项，允许管理员禁用对等支持（如果他们愿意）。
Because a mapping created or managed by PEER behaves almost exactly like an implicit dynamic outbound mapping created as a side effect of a packet (e.g., TCP SYN) sent by the host, mappings created or managed using PCP PEER requests may be endpoint-independent mapping (EIM) or endpoint-dependent mapping (EDM), with endpoint-independent filtering (EIF) or endpoint-dependent filtering (EDF), consistent with the existing behavior of the NAT gateway or firewall in question for implicit outbound mappings it creates automatically as a result of observing outgoing traffic from internal hosts.
由于对等方创建或管理的映射的行为几乎与作为主机发送的数据包（例如TCP SYN）的副作用而创建的隐式动态出站映射完全相同，因此使用PCP对等方请求创建或管理的映射可能是端点独立映射（EIM）或端点依赖映射（EDM），具有端点独立过滤（EIF）或端点相关过滤（EDF），与所讨论的NAT网关或防火墙的现有行为一致，因为它通过观察来自内部主机的传出流量自动创建隐式出站映射。
The PEER Opcode allows a PCP client to create a new explicit dynamic outbound mapping (which functions similarly to an outbound mapping created implicitly when a host sends an outbound TCP SYN) or to extend the lifetime of an existing outbound mapping.
对等操作码允许PCP客户端创建新的显式动态出站映射（其功能类似于主机发送出站TCP SYN时隐式创建的出站映射），或延长现有出站映射的生存期。
The following diagram shows the Opcode layout for the PEER Opcode. The formats for the PEER request and response packets are aligned so that related fields fall at the same offsets in the packet.
下图显示对等操作码的操作码布局。对等请求和响应数据包的格式是对齐的，因此相关字段在数据包中的偏移量相同。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Suggested External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Suggested External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: PEER Opcode Request
图11：对等操作码请求
These fields are described below:
这些字段描述如下：
Requested Lifetime (in common header): Requested lifetime of this mapping, in seconds. Note that it is not possible to reduce the lifetime of a mapping (or delete it, with requested lifetime=0) using PEER.
请求的生存期（在公共标头中）：此映射的请求生存期，以秒为单位。请注意，使用对等映射不可能缩短映射的生存期（或者删除它，请求的生存期为0）。
Mapping Nonce: Random value chosen by the PCP client. See Section 12.2, "Generating a PEER Request". Zero is a legal value (but unlikely, occurring in roughly one in 2^96 requests).
映射Nonce：由PCP客户端选择的随机值。参见第12.2节“生成对等请求”。零是一个法定值（但不太可能，大约每2^96个请求中就有一个请求为零）。
Protocol: Upper-layer protocol associated with this Opcode. Values are taken from the IANA protocol registry [proto_numbers]. For example, this field contains 6 (TCP) if the Opcode is describing a TCP mapping. This field contains 17 (UDP) if the Opcode is describing a UDP mapping. Protocol MUST NOT be zero.
协议：与此操作码关联的上层协议。值取自IANA协议注册表[协议编号]。例如，如果操作码描述TCP映射，则此字段包含6（TCP）。如果操作码描述UDP映射，则此字段包含17（UDP）。协议不能为零。
Reserved: 24 reserved bits, MUST be set to 0 on transmission and MUST be ignored on reception.
保留：24个保留位，传输时必须设置为0，接收时必须忽略。
Internal Port: Internal port for the mapping. Internal port MUST NOT be zero.
内部端口：映射的内部端口。内部端口不得为零。
Suggested External Port: Suggested external port for the mapping. If the PCP client does not know the external port, or does not have a preference, it MUST use 0.
建议的外部端口：映射的建议外部端口。如果PCP客户端不知道外部端口，或者没有首选项，则必须使用0。
Suggested External IP Address: Suggested external IP address for the mapping. If the PCP client does not know the external address, or does not have a preference, it MUST use the address-family-specific all-zeros address (see Section 5).
建议的外部IP地址：映射的建议外部IP地址。如果PCP客户端不知道外部地址或没有首选项，则必须使用特定于地址系列的全零地址（请参阅第5节）。
Remote Peer Port: Remote peer's port for the mapping. Remote peer port MUST NOT be zero.
远程对等端口：映射的远程对等端口。远程对等端口不得为零。
Reserved: 16 reserved bits, MUST be set to 0 on transmission and MUST be ignored on reception.
保留：16个保留位，传输时必须设置为0，接收时必须忽略。
Remote Peer IP Address: Remote peer's IP address. This is from the perspective of the PCP client, so that the PCP client does not need to concern itself with NAT64 or NAT46 (which both cause the client's idea of the remote peer's IP address to differ from the remote peer's actual IP address). This field allows the PCP client and PCP server to disambiguate multiple connections from the same port on the internal host to different servers. An IPv6 address is represented directly, and an IPv4 address is represented using the IPv4-mapped address syntax (Section 5).
远程对等IP地址：远程对等的IP地址。这是从PCP客户端的角度来看的，因此PCP客户端不需要关心NAT64或NAT46（这两种情况都会导致客户端对远程对等方IP地址的想法与远程对等方的实际IP地址不同）。此字段允许PCP客户端和PCP服务器消除从内部主机上同一端口到不同服务器的多个连接的歧义。IPv6地址直接表示，IPv4地址使用IPv4映射地址语法表示（第5节）。
When attempting to re-create a lost mapping, the suggested external IP address and port are set to the External IP Address and Port fields received in a previous PEER response from the PCP server. On an initial PEER request, the external IP address and port are set to zero.
尝试重新创建丢失的映射时，建议的外部IP地址和端口将设置为在先前来自PCP服务器的对等响应中接收的外部IP地址和端口字段。在初始对等请求中，外部IP地址和端口设置为零。
Note that semantics similar to the PREFER_FAILURE option are automatically implied by PEER requests. If the Suggested External IP Address or Suggested External Port fields are non-zero, and the PCP server is unable to honor the suggested external IP address, protocol, or port, then the PCP server MUST return a
请注意，对等请求会自动隐含类似于prefere_FAILURE选项的语义。如果建议的外部IP地址或建议的外部端口字段不为零，并且PCP服务器无法接受建议的外部IP地址、协议或端口，则PCP服务器必须返回
CANNOT_PROVIDE_EXTERNAL error response. The PREFER_FAILURE option is neither required nor allowed in PEER requests, and if a PCP server receives a PEER request containing the PREFER_FAILURE option it MUST return a MALFORMED_REQUEST error response.
无法提供外部错误响应。对等请求中既不需要也不允许使用prefere_FAILURE选项，如果PCP服务器接收到包含prefere_FAILURE选项的对等请求，则必须返回格式错误的_请求错误响应。
The following diagram shows the Opcode response for the PEER Opcode:
下图显示对等操作码的操作码响应：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Assigned External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Assigned External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: PEER Opcode Response
图12：对等操作码响应
Lifetime (in common header): On a success response, this indicates the lifetime for this mapping, in seconds. On an error response, this indicates how long clients should assume they'll get the same error response from the PCP server if they repeat the same request.
生存期（在公共标头中）：在成功响应上，这表示此映射的生存期，以秒为单位。在错误响应中，这表示如果客户端重复相同的请求，则客户端应假定他们将从PCP服务器获得相同的错误响应的时间。
Mapping Nonce: Copied from the request.
映射Nonce：从请求中复制。
Protocol: Copied from the request.
协议：从请求中复制。
Reserved: 24 reserved bits, MUST be set to 0 on transmission, MUST be ignored on reception.
保留：24个保留位，传输时必须设置为0，接收时必须忽略。
Internal Port: Copied from request.
内部端口：从请求复制。
Assigned External Port: On a success response, this is the assigned external port for the mapping. On an error response, the suggested external port is copied from the request.
分配的外部端口：在成功响应时，这是为映射分配的外部端口。在错误响应中，从请求复制建议的外部端口。
Assigned External IP Address: On a success response, this is the assigned external IPv4 or IPv6 address for the mapping. On an error response, the suggested external IP address is copied from the request.
分配的外部IP地址：在成功响应中，这是为映射分配的外部IPv4或IPv6地址。在错误响应中，建议的外部IP地址将从请求中复制。
Remote Peer Port: Copied from request.
远程对等端口：从请求复制。
Reserved: 16 reserved bits, MUST be set to 0 on transmission, MUST be ignored on reception.
保留：16个保留位，传输时必须设置为0，接收时必须忽略。
Remote Peer IP Address: Copied from the request.
远程对等IP地址：从请求中复制。
This section describes the operation of a client when generating a message with the PEER Opcode.
本节介绍使用对等操作码生成消息时客户端的操作。
The PEER Opcode MAY be sent before or after establishing bidirectional communication with the remote peer.
对等操作码可以在与远程对等建立双向通信之前或之后发送。
If sent before, this is considered a PEER-created mapping that creates a new dynamic outbound mapping in the PCP-controlled device.
如果在此之前发送，则认为这是对等创建的映射，在PCP控制的设备中创建新的动态出站映射。
If sent after, this allows the PCP client to learn the IP address, port, and lifetime of the assigned external address and port for the existing implicit dynamic outbound mapping, and potentially to extend this lifetime (for reducing NAT or firewall keepalive messages, as described in Section 10.3).
如果在之后发送，这允许PCP客户端了解现有隐式动态出站映射的指定外部地址和端口的IP地址、端口和生存期，并可能延长此生存期（如第10.3节所述，用于减少NAT或防火墙keepalive消息）。
PEER requests are also useful for restoring mappings after a NAT has lost its mapping state (e.g., due to a crash).
对等请求在NAT失去映射状态（例如，由于崩溃）后恢复映射也很有用。
The Mapping Nonce value is randomly chosen by the PCP client, following accepted practices for generating unguessable random numbers [RFC4086], and is used as part of the validation of PCP responses (see below) by the PCP client, and validation for mapping refreshes by the PCP server. The client MUST use a different mapping nonce for each PCP server it communicates with, and it is RECOMMENDED to choose a new random mapping nonce whenever the PCP client is initialized. The client MAY use a different mapping nonce for every mapping.
映射Nonce值由PCP客户端按照生成不可用随机数的公认实践[RFC4086]随机选择，并用作PCP客户端验证PCP响应（见下文）和PCP服务器验证映射刷新的一部分。客户端必须为与其通信的每个PCP服务器使用不同的映射nonce，建议在初始化PCP客户端时选择一个新的随机映射nonce。客户机可以对每个映射使用不同的映射nonce。
The PEER Opcode contains a Remote Peer Address field, which is always from the perspective of the PCP client. Note that when the PCP-controlled device is performing address family translation (NAT46 or NAT64), the remote peer address from the perspective of the PCP client is different from the remote peer address on the other side of the address family translation device.
对等操作码包含一个远程对等地址字段，该字段始终从PCP客户端的角度显示。注意，当PCP控制的设备正在执行地址族转换（NAT46或NAT64）时，从PCP客户端的角度来看，远程对等地址不同于地址族转换设备另一侧的远程对等地址。
This section describes the operation of a server when receiving a request with the PEER Opcode. Processing SHOULD be performed in the order of the following paragraphs.
本节介绍服务器在接收带有对等操作码的请求时的操作。应按照以下段落的顺序进行处理。
The following fields from a PEER request are copied into the response: Protocol, Internal Port, Remote Peer IP Address, Remote Peer Port, and Mapping Nonce.
对等请求中的以下字段将复制到响应中：协议、内部端口、远程对等IP地址、远程对等端口和映射Nonce。
When an implicit dynamic mapping is created, some NATs and firewalls validate destination addresses and will not create an implicit dynamic mapping if the destination address is invalid (e.g., 127.0.0.1). If a PCP-controlled device does such validation for implicit dynamic mappings, it SHOULD also do a similar validation of the remote peer IP address, protocol, and port for PEER-created explicit dynamic mappings. If the validation determines the remote peer IP address of a PEER request is invalid, then no mapping is created, and a MALFORMED_REQUEST error result is returned.
创建隐式动态映射时，某些NAT和防火墙会验证目标地址，如果目标地址无效（例如127.0.0.1），则不会创建隐式动态映射。如果由PCP控制的设备对隐式动态映射进行此类验证，则它还应该对远程对等IP地址、协议和端口进行类似的验证，以验证对等方创建的显式动态映射。如果验证确定对等请求的远程对等IP地址无效，则不会创建映射，并返回格式错误的\u请求错误结果。
On receiving the PEER Opcode, the PCP server examines the mapping table for a matching five-tuple { Protocol, Internal Address, Internal Port, Remote Peer Address, Remote Peer Port }.
在接收到对等操作码时，PCP服务器检查映射表中是否有匹配的五元组{协议、内部地址、内部端口、远程对等地址、远程对等端口}。
If no matching mapping is found, and the suggested external address and port are either zero or can be honored for the specified Protocol, a new mapping is created. By having the PEER create such a mapping, we avoid a race condition between the PEER request and the initial outgoing packet arriving at the NAT or firewall device first, and allow PEER to be used to recreate a lost outbound dynamic mapping (see Section 16.3.1, "Recreating Mappings"). Thereafter, this PEER-created mapping is treated as if it was an implicit dynamic outbound mapping (e.g., as if the PCP client sent a TCP SYN) and a lifetime appropriate to such a mapping is returned (note: on many NATs and firewalls, such mapping lifetimes are very short until bidirectional traffic is seen by the NAT or firewall).
如果未找到匹配的映射，并且建议的外部地址和端口为零，或者可以为指定的协议使用，则会创建一个新映射。通过让对等方创建这样的映射，我们避免了对等方请求和首先到达NAT或防火墙设备的初始传出数据包之间的竞争条件，并允许对等方用于重新创建丢失的出站动态映射（请参阅第16.3.1节“重新创建映射”）。此后，该对等创建的映射被视为隐式动态出站映射（例如，PCP客户端发送TCP SYN），并返回适合该映射的生存期（注意：在许多NAT和防火墙上，在NAT或防火墙看到双向流量之前，该映射生存期非常短）。
If no matching mapping is found, and the suggested external address and port cannot be honored, then no new state is created, and the error CANNOT_PROVIDE_EXTERNAL is returned.
如果未找到匹配的映射，并且建议的外部地址和端口无法使用，则不会创建新状态，并且返回错误cannot\u PROVIDE\u external。
If a matching mapping is found, and no previous PEER Opcode was successfully processed for this mapping, then the Suggested External Address and Port values in the request are ignored, the lifetime of that mapping is adjusted as described below, and information about the existing mapping is returned. This allows a client to explicitly extend the lifetime of an existing mapping and/or to learn an existing mapping's external address, port, and lifetime. The mapping nonce is remembered for this mapping.
如果找到匹配的映射，并且没有为该映射成功处理以前的对等操作码，则请求中建议的外部地址和端口值将被忽略，该映射的生存期将按如下所述进行调整，并返回有关现有映射的信息。这允许客户端显式延长现有映射的生存期和/或了解现有映射的外部地址、端口和生存期。此映射将记住映射nonce。
If operating in the Simple Threat Model (Section 18.1), and the internal port, protocol, and internal address match a mapping that already exists, but the mapping nonce does not match (that is, a previous PEER request was processed), the request MUST be rejected with a NOT_AUTHORIZED error with the lifetime of the error indicating duration of that existing mapping. The PCP server only needs to remember one Mapping Nonce value for each mapping. This specification makes no statement about mapping nonce with the Advanced Threat Model.
如果在简单威胁模型（第18.1节）中运行，且内部端口、协议和内部地址与已存在的映射匹配，但映射nonce不匹配（即，处理了以前的对等请求），请求必须被拒绝，并且出现未经授权的错误，错误的生存期表示现有映射的持续时间。PCP服务器只需要为每个映射记住一个映射Nonce值。本规范未说明如何使用高级威胁模型映射nonce。
Processing the Lifetime value of the PEER Opcode is described in Section 15, "Mapping Lifetime and Deletion". Sending a PEER request with a very short requested lifetime can be used to query the lifetime of an existing mapping. So that PCP clients can reduce the frequency of their NAT and firewall keepalive messages, it is RECOMMENDED that lifetimes of mappings created or lengthened with PEER be longer than the lifetimes of implicitly created mappings.
第15节“映射生存期和删除”中描述了对等操作码的生存期值的处理。发送请求生存期很短的对等请求可用于查询现有映射的生存期。为了使PCP客户端能够减少其NAT和防火墙保留消息的频率，建议使用PEER创建或延长的映射的生命周期比隐式创建的映射的生命周期长。
If all of the preceding operations were successful (did not generate an error response), then a SUCCESS response is generated, with the Lifetime field containing the lifetime of the mapping.
如果前面的所有操作都成功（没有生成错误响应），则会生成一个成功响应，其中Lifetime字段包含映射的生存期。
If a PEER-created or PEER-managed mapping is not renewed using PEER, then it reverts to the NAT's usual behavior for implicit mappings. For example, continued outbound traffic keeps the mapping alive, as per the NAT or firewall device's existing policy. A PEER-created or PEER-managed mapping may be terminated at any time by action of the TCP client or server (e.g., due to TCP FIN or TCP RST), as per the NAT or firewall device's existing policy.
如果未使用PEER更新对等创建或对等管理的映射，则它将恢复到NAT对于隐式映射的通常行为。例如，根据NAT或防火墙设备的现有策略，持续的出站流量使映射保持活动状态。根据NAT或防火墙设备的现有策略，可随时通过TCP客户端或服务器的操作（例如，由于TCP FIN或TCP RST）终止对等创建或对等管理的映射。
This section describes the operation of a client when processing a response with the PEER Opcode.
本节介绍使用对等操作码处理响应时客户端的操作。
After performing common PCP response processing, the response is further matched with an outstanding PEER request by comparing the internal IP address (the destination IP address of the PCP response, or other IP address specified via the THIRD_PARTY option), the
在执行公共PCP响应处理之后，通过比较内部IP地址（PCP响应的目标IP地址，或通过第三方选项指定的其他IP地址），将响应进一步与未完成的对等请求匹配
protocol, the internal port, the remote peer address, the remote peer port, and the mapping nonce. Other fields are not compared, because the PCP server sets those fields to provide information about the mapping created by the Opcode. The PCP server will send a Mapping Update (Section 14.2) if the mapping changes (e.g., due to IP renumbering).
协议、内部端口、远程对等地址、远程对等端口和映射nonce。不会比较其他字段，因为PCP服务器将这些字段设置为提供有关操作码创建的映射的信息。如果映射发生变化（例如，由于IP重新编号），PCP服务器将发送映射更新（第14.2节）。
If the result code is NO_RESOURCES and the request was for the creation or renewal of a mapping, then the PCP client SHOULD NOT send further requests for any new mappings to that PCP server for the (limited) value of the lifetime.
如果结果代码为NO_RESOURCES，且请求用于创建或续订映射，则PCP客户端不应在生存期的（有限）值内向该PCP服务器发送任何新映射的进一步请求。
On a successful response, the application can use the assigned
Lifetime value to reduce its frequency of application keepalives for
that particular NAT mapping. Of course, there may be other reasons,
specific to the application, to use more frequent application
keepalives. For example, the PCP assigned lifetime could be one hour
but the application may want to maintain state on its server (e.g.,
"busy" / "away") more frequently than once an hour. If the response
indicates an unexpected IP address or port (e.g., due to IP
renumbering), the PCP client will want to re-establish its connection
to its remote server.
On a successful response, the application can use the assigned
Lifetime value to reduce its frequency of application keepalives for
that particular NAT mapping. Of course, there may be other reasons,
specific to the application, to use more frequent application
keepalives. For example, the PCP assigned lifetime could be one hour
but the application may want to maintain state on its server (e.g.,
"busy" / "away") more frequently than once an hour. If the response
indicates an unexpected IP address or port (e.g., due to IP
renumbering), the PCP client will want to re-establish its connection
to its remote server.
If the PCP client wishes to keep this mapping alive beyond the indicated lifetime, it MAY rely on continued inside-to-outside traffic to ensure that the mapping will continue to exist, or it MAY issue a new PCP request prior to the expiration. The recommended timings for renewing PEER mappings are the same as for MAP mappings, as described in Section 11.2.1.
如果PCP客户端希望在指定的生存期之后保持此映射的活动状态，则它可以依赖持续的内部到外部通信来确保映射将继续存在，或者它可以在到期之前发出新的PCP请求。更新对等映射的建议时间与第11.2.1节中描述的映射相同。
Note: Implementations need to expect the PEER response may contain an external IP address with a different family than the remote peer IP address, e.g., when NAT64 or NAT46 are being used.
注意：实现需要预期对等响应可能包含与远程对等IP地址不同系列的外部IP地址，例如，当使用NAT64或NAT46时。
This section describes options for the MAP and PEER Opcodes. These options MUST NOT appear with other Opcodes, unless permitted by those other Opcodes.
本节介绍映射和对等操作码的选项。除非其他操作码允许，否则这些选项不得与其他操作码一起出现。
This option is used when a PCP client wants to control a mapping to an internal host other than itself. This is used with both MAP and PEER Opcodes.
当PCP客户端希望控制到内部主机（而非自身）的映射时，使用此选项。这与映射和对等操作码一起使用。
Due to security concerns with the THIRD_PARTY option, this option MUST NOT be implemented or used unless the network on which the PCP
由于第三方选项的安全问题，不得实施或使用此选项，除非PCP所在的网络
messages are to be sent is fully trusted. For example, if access control lists (ACLs) are installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications from a trusted PCP client to the PCP server.
要发送的消息完全受信任。例如，如果访问控制列表（ACL）安装在PCP客户端、PCP服务器以及它们之间的网络上，那么这些ACL只允许从受信任的PCP客户端到PCP服务器的通信。
A management device would use this option to control a PCP server on behalf of users. For example, a management device located in a network operations center, which presents a user interface to end users or to network operations staff, and issues PCP requests with the THIRD_PARTY option to the appropriate PCP server.
管理设备将使用此选项代表用户控制PCP服务器。例如，位于网络运营中心的管理设备，向最终用户或网络运营人员提供用户界面，并向相应的PCP服务器发出带有第三方选项的PCP请求。
The THIRD_PARTY option is formatted as follows:
第三方选项的格式如下：
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=1 | Reserved | Option Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Internal IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=1 | Reserved | Option Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Internal IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: THIRD_PARTY Option
图13：第三方选择
The fields are described below:
这些字段描述如下：
Internal IP Address: Internal IP address for this mapping.
内部IP地址：此映射的内部IP地址。
Option Name: THIRD_PARTY Number: 1 Purpose: Indicates the MAP or PEER request is for a host other than the host sending the PCP option. Valid for Opcodes: MAP, PEER Length: 16 octets May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1
选项名称：第三方编号：1用途：表示映射或对等请求针对的是发送PCP选项的主机以外的主机。对操作码有效：MAP，对等长度：16个八位字节可能出现在：request中。仅当它出现在相关请求中时，才可能出现在响应中。最多发生次数：1次
A THIRD_PARTY option MUST NOT contain the same address as the source address of the packet. This is because many PCP servers may not implement the THIRD_PARTY option at all, and with those servers a client redundantly using the THIRD_PARTY option to specify its own IP address would cause such mapping requests to fail where they would otherwise have succeeded. A PCP server receiving a THIRD_PARTY option specifying the same address as the source address of the packet MUST return a MALFORMED_REQUEST result code.
第三方选项不得包含与数据包源地址相同的地址。这是因为许多PCP服务器可能根本没有实现第三方选项，而对于这些服务器，客户端冗余地使用第三方选项来指定其自己的IP地址将导致此类映射请求失败，否则它们将成功。接收第三方选项（指定与数据包源地址相同的地址）的PCP服务器必须返回格式错误的请求结果代码。
A PCP server MAY be configured to permit or to prohibit the use of the THIRD_PARTY option. If this option is permitted, properly authorized clients may perform these operations on behalf of other hosts. If this option is prohibited, and a PCP server receives a PCP MAP request with a THIRD_PARTY option, it MUST generate a UNSUPP_OPTION response.
PCP服务器可配置为允许或禁止使用第三方选项。如果允许此选项，经过适当授权的客户端可以代表其他主机执行这些操作。如果此选项被禁止，并且PCP服务器接收到带有第三方选项的PCP映射请求，则必须生成UNSUPP选项响应。
It is RECOMMENDED that customer premises equipment implementing a PCP server be configured to prohibit third-party mappings by default. With this default, if a user wants to create a third-party mapping, the user needs to interact out-of-band with their customer premises router (e.g., using its HTTP administrative interface).
建议将实现PCP服务器的客户场所设备配置为默认情况下禁止第三方映射。使用此默认设置，如果用户希望创建第三方映射，则用户需要与其客户场所路由器进行带外交互（例如，使用其HTTP管理接口）。
It is RECOMMENDED that service provider NAT and firewall devices implementing a PCP server be configured to permit the THIRD_PARTY option, when sent by a properly authorized host. If the packet arrives from an unauthorized host, the PCP server MUST generate an UNSUPP_OPTION error.
建议将实现PCP服务器的服务提供商NAT和防火墙设备配置为允许第三方选项（由经过适当授权的主机发送）。如果数据包来自未经授权的主机，PCP服务器必须生成UNSUPP_选项错误。
Note that the THIRD_PARTY option is not needed for today's common scenario of an ISP offering a single IP address to a customer who is using NAT to share that address locally, since in this scenario all the customer's hosts appear, from the point of view of the ISP, to be a single host.
请注意，对于当前常见的ISP向使用NAT在本地共享该地址的客户提供单一IP地址的场景，不需要第三方选项，因为在这种场景中，从ISP的角度来看，所有客户的主机都是单一主机。
When a PCP client is using the THIRD_PARTY option to make and maintain mappings on behalf of some other device, it may be beneficial if, where possible, the PCP client verifies that the other device is actually present and active on the network. Otherwise, the PCP client risks maintaining those mappings forever, long after the device that required them has gone. This would defeat the purpose of PCP mappings having a finite lifetime so that they can be automatically deleted after they are no longer needed.
当PCP客户端使用第三方选项代表某些其他设备创建和维护映射时，如果PCP客户端在可能的情况下验证其他设备在网络上是否实际存在和处于活动状态，这可能是有益的。否则，PCP客户端可能会在需要这些映射的设备消失很久之后永远维护这些映射。这将破坏具有有限生存期的PCP映射的目的，以便在不再需要它们之后可以自动删除它们。
This option is only used with the MAP Opcode.
此选项仅与MAP操作码一起使用。
This option indicates that if the PCP server is unable to map both the suggested external port and suggested external address, the PCP server should not create a mapping. This differs from the behavior without this option, which is to create a mapping.
此选项表示，如果PCP服务器无法映射建议的外部端口和建议的外部地址，则PCP服务器不应创建映射。这不同于没有此选项的行为，即创建映射。
PREFER_FAILURE is never necessary for a PCP client to manage mappings for itself, and its use causes additional work in the PCP client and in the PCP server. This option exists for interworking with non-PCP mapping protocols that have different semantics than PCP (e.g., UPnP IGDv1 interworking [PNP-IGD-PCP], where the semantics of UPnP IGDv1
PCP客户端永远不需要使用Preference_失败来管理自己的映射，使用它会导致PCP客户端和PCP服务器中的额外工作。此选项用于与非PCP映射协议的互通，这些协议具有与PCP不同的语义（例如，UPnP IGDv1互通[PNP-IGD-PCP]，其中UPnP IGDv1的语义
only allow the UPnP IGDv1 client to dictate mapping a specific port), or separate port allocation systems that allocate ports to a subscriber (e.g., a subscriber-accessed web portal operated by the same ISP that operates the PCP server). A PCP server MAY support this option, if its designers wish to support such downstream devices or separate port allocation systems. PCP servers that are not intended to interface with such systems are not required to support this option. PCP clients other than UPnP IGDv1 interworking clients or other than a separate port allocation system SHOULD NOT use this option because it results in inefficient operation, and they cannot safely assume that all PCP servers will implement it. It is anticipated that this option will be deprecated in the future as more clients adopt PCP natively and the need for this option declines.
仅允许UPnP IGDv1客户端指令映射特定端口），或将端口分配给订阅者的单独端口分配系统（例如，由操作PCP服务器的同一ISP操作的订阅者访问的web门户）。如果PCP服务器的设计者希望支持此类下游设备或单独的端口分配系统，则PCP服务器可以支持此选项。不打算与此类系统接口的PCP服务器不需要支持此选项。除UPnP IGDv1互通客户端或独立端口分配系统以外的PCP客户端不应使用此选项，因为这会导致运行效率低下，并且不能安全地假定所有PCP服务器都将实现此选项。随着越来越多的客户本机采用PCP，并且对该选项的需求下降，预计该选项将在未来被弃用。
The PREFER_FAILURE option is formatted as follows:
首选_失败选项的格式如下：
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=2 | Reserved | Option Length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=2 | Reserved | Option Length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PREFER_FAILURE Option
图14：首选故障选项
Option Name: PREFER_FAILURE Number: 2 Purpose: indicates that the PCP server should not create an alternative mapping if the suggested external port and address cannot be mapped. Valid for Opcodes: MAP Length: 0 May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1
选项名称：Preference_故障编号：2目的：表示如果无法映射建议的外部端口和地址，则PCP服务器不应创建替代映射。对操作码有效：映射长度：0可能出现在：请求中。仅当它出现在相关请求中时，才可能出现在响应中。最多发生次数：1次
The result code CANNOT_PROVIDE_EXTERNAL is returned if the suggested external address, protocol, and port cannot be mapped. This can occur because the external port is already mapped to another host's outbound dynamic mapping, an inbound dynamic mapping, a static mapping, or the same internal address, protocol, and port already have an outbound dynamic mapping that is mapped to a different external port than suggested. This can also occur because the external address is no longer available (e.g., due to renumbering). The server MAY set the lifetime in the response to the remaining lifetime of the conflicting mapping + TIME_WAIT [RFC0793], rounded up to the next larger integer number of seconds.
如果无法映射建议的外部地址、协议和端口，则返回结果代码CANNOT_PROVIDE_EXTERNAL。这可能是因为外部端口已映射到另一台主机的出站动态映射、入站动态映射、静态映射，或者相同的内部地址、协议和端口已具有映射到不同于建议的外部端口的出站动态映射。这也可能是因为外部地址不再可用（例如，由于重新编号）。服务器可以在响应冲突映射的剩余生存期+等待时间[RFC0793]时设置生存期，四舍五入到下一个更大的整数秒数。
If a PCP request contains the PREFER_FAILURE option and has zero in the Suggested External Port field, then it is invalid. The PCP server MUST reject such a message with the MALFORMED_OPTION error code.
如果PCP请求包含Prefere_FAILURE选项，并且在建议的外部端口字段中为零，则该请求无效。PCP服务器必须拒绝包含格式错误的_选项错误代码的此类消息。
PCP servers MAY choose to rate-limit their handling of PREFER_FAILURE requests, to protect themselves from a rapid flurry of 65535 consecutive PREFER_FAILURE requests from clients probing to discover which external ports are available.
PCP服务器可能会选择对其处理首选失败请求的速率进行限制，以保护自己不受来自客户端的65535个连续首选失败请求的快速冲击，从而发现哪些外部端口可用。
There can exist a race condition between the MAP Opcode using the PREFER_FAILURE option and Mapping Update (Section 14.2). For example, a previous host on the local network could have previously had the same internal address, with a mapping for the same internal port. At about the same moment that the current host sends a MAP Request using the PREFER_FAILURE option, the PCP server could send a spontaneous Mapping Update for the old mapping due to an external configuration change, which could appear to be a reply to the new mapping request. Because of this, the PCP client MUST validate that the external IP address, protocol, port, and nonce in a success response match the associated suggested values from the request. If they do not match, it is because the Mapping Update was sent before the MAP request was processed.
使用prefere_FAILURE选项的映射操作码和映射更新之间可能存在竞争条件（第14.2节）。例如，本地网络上以前的主机以前可能具有相同的内部地址，并具有相同内部端口的映射。大约在当前主机使用prefere_FAILURE选项发送映射请求的同时，由于外部配置更改，PCP服务器可以为旧映射发送一个自发的映射更新，这可能是对新映射请求的回复。因此，PCP客户端必须验证成功响应中的外部IP地址、协议、端口和nonce是否与请求中的相关建议值匹配。如果它们不匹配，那是因为映射更新是在处理映射请求之前发送的。
This option is only used with the MAP Opcode.
此选项仅与MAP操作码一起使用。
This option indicates that filtering incoming packets is desired. The protocol being filtered is indicated by the Protocol field in the MAP Request, and the remote peer IP address and remote peer port of the FILTER option indicate the permitted remote peer's source IP address and source port for packets from the Internet; other traffic from other addresses is blocked. The remote peer prefix length indicates the length of the remote peer's IP address that is significant; this allows a single option to permit an entire subnet. After processing this MAP request containing the FILTER option and generating a successful response, the PCP-controlled device will drop packets received on its public-facing interface that don't match the filter fields. After dropping the packet, if its security policy allows, the PCP-controlled device MAY also generate an ICMP error in response to the dropped packet.
此选项表示需要过滤传入数据包。正在过滤的协议由MAP请求中的协议字段表示，过滤器选项的远程对等IP地址和远程对等端口表示允许的远程对等源IP地址和来自Internet的数据包的源端口；来自其他地址的其他通信被阻止。远程对等前缀长度指示远程对等IP地址的有效长度；这允许单个选项允许整个子网。在处理此包含筛选器选项的映射请求并生成成功响应后，PCP控制的设备将丢弃在其面向公众的接口上接收到的与筛选器字段不匹配的数据包。在丢弃数据包之后，如果其安全策略允许，PCP控制的设备还可以生成ICMP错误以响应丢弃的数据包。
The use of the FILTER option can be seen as a performance optimization. Since all software using PCP to receive incoming connections also has to deal with the case where it may be directly connected to the Internet and receive unrestricted incoming TCP connections and UDP packets, if it wishes to restrict incoming
过滤器选项的使用可视为性能优化。由于所有使用PCP接收传入连接的软件也必须处理可能直接连接到Internet并接收不受限制的传入TCP连接和UDP数据包（如果希望限制传入连接）的情况
traffic to a specific source address or group of source addresses, such software already needs to check the source address of incoming traffic and reject unwanted traffic. However, the FILTER option is a particularly useful performance optimization for battery powered wireless devices, because it can enable them to conserve battery power by not having to wake up just to reject unwanted traffic.
到特定源地址或一组源地址的流量，此类软件已经需要检查传入流量的源地址并拒绝不需要的流量。然而，对于电池供电的无线设备来说，过滤器选项是一种特别有用的性能优化，因为它可以使它们不必为了拒绝不需要的流量而醒来，从而节省电池电量。
The FILTER option is formatted as follows:
过滤器选项的格式如下所示：
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=3 | Reserved | Option Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix Length | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=3 | Reserved | Option Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix Length | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: FILTER Option Layout
图15：过滤器选项布局
These fields are described below:
这些字段描述如下：
Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored when received.
保留：8个保留位，必须作为0发送，并且在接收时必须忽略。
Prefix Length: indicates how many bits of the IPv4 or IPv6 address are relevant for this filter. The value 0 indicates "no filter", and will remove all previous filters. See below for detail.
前缀长度：指示IPv4或IPv6地址的多少位与此筛选器相关。值0表示“无过滤器”，并将删除所有以前的过滤器。详情见下文。
Remote Peer Port: the port number of the remote peer. The value 0 indicates "all ports".
远程对等端口：远程对等端口的端口号。值0表示“所有端口”。
Remote Peer IP address: The IP address of the remote peer.
远程对等IP地址：远程对等的IP地址。
Option Name: FILTER Number: 3 Purpose: specifies a filter for incoming packets Valid for Opcodes: MAP Length: 20 octets May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: as many as fit within maximum PCP message size
选项名称：筛选器编号：3用途：指定对操作码有效的传入数据包的筛选器：映射长度：20个八位字节可能出现在：请求中。仅当它出现在相关请求中时，才可能出现在响应中。最大出现次数：在最大PCP消息大小范围内尽可能多
The Prefix Length indicates how many bits of the address are used for the filter. For IPv4 addresses (which are encoded using the IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix lengths are between 96 and 128 bits, inclusive. That is, add 96 to the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are between 0 and 128 bits, inclusive. Values outside those ranges cause the PCP server to return the MALFORMED_OPTION result code.
前缀长度表示用于过滤器的地址位数。对于IPv4地址（使用IPv4映射地址格式（：：FFFF:0:0/96）进行编码），这意味着有效前缀长度介于96位和128位之间（包括96位和128位）。也就是说，将96添加到IPv4前缀长度。对于IPv6地址，有效前缀长度介于0和128位之间（含0和128位）。超出这些范围的值会导致PCP服务器返回格式错误的_选项结果代码。
If multiple occurrences of the FILTER option exist in the same MAP request, they are processed in the order received (as per normal PCP option processing), and they MAY overlap the filtering requested. If there is an existing mapping (with or without a filter) and the server receives a MAP request with FILTER, the filters indicated in the new request are added to any existing filters. If a MAP request has a lifetime of 0 and contains the FILTER option, the error MALFORMED_OPTION is returned.
如果同一映射请求中存在多个过滤器选项，则将按照接收到的顺序处理这些选项（按照正常PCP选项处理），并且它们可能与请求的过滤重叠。如果存在现有映射（带或不带筛选器），并且服务器收到带筛选器的映射请求，则新请求中指示的筛选器将添加到任何现有筛选器中。如果映射请求的生存期为0且包含筛选器选项，则返回错误格式错误的\u选项。
If any occurrences of the FILTER option in a request packet are not successfully processed then an error is returned (e.g., MALFORMED_OPTION if one of the options was malformed) and as with other PCP errors, returning an error causes no state to be changed in the PCP server or in the PCP-controlled device.
如果请求数据包中出现的任何筛选器选项未成功处理，则返回错误（例如，如果其中一个选项的格式不正确，则返回格式不正确的_选项），与其他PCP错误一样，返回错误不会导致PCP服务器或PCP控制设备中的状态发生更改。
To remove all existing filters, the Prefix Length 0 is used. There is no mechanism to remove a specific filter.
要删除所有现有筛选器，请使用前缀长度0。没有拆卸特定过滤器的机制。
To change an existing filter, the PCP client sends a MAP request containing two FILTER options, the first option containing a prefix length of 0 (to delete all existing filters) and the second containing the new remote peer's IP address, protocol, and port. Other FILTER options in that PCP request, if any, add more allowed remote peers.
要更改现有筛选器，PCP客户端将发送一个包含两个筛选器选项的映射请求，第一个选项包含前缀长度0（删除所有现有筛选器），第二个选项包含新远程对等方的IP地址、协议和端口。该PCP请求中的其他筛选器选项（如果有）将添加更多允许的远程对等点。
The PCP server or the PCP-controlled device is expected to have a limit on the number of remote peers it can support. This limit might be as small as one. If a MAP request would exceed this limit, the entire MAP request is rejected with the result code EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged.
PCP服务器或PCP控制的设备预计对其可支持的远程对等机的数量有限制。这个限制可能只有一个。如果MAP请求将超过此限制，则整个MAP请求将被拒绝，结果代码为EXCESS_REMOTE_PEERS，并且PCP服务器上的状态保持不变。
All PCP servers MUST support at least one filter per MAP mapping.
所有PCP服务器必须支持每个映射至少一个筛选器。
PCP includes a rapid recovery feature, which allows PCP clients to repair failed mappings within seconds, rather than the minutes or hours it might take if they relied solely on waiting for the next routine renewal of the mapping. Mapping failures may occur when a NAT gateway is rebooted and loses its mapping state, or when a NAT
PCP包括一个快速恢复功能，它允许PCP客户端在几秒钟内修复失败的映射，而不是仅仅依靠等待映射的下一个例行更新来完成可能需要的几分钟或几小时。当NAT网关重新启动并失去其映射状态时，或者当NAT
gateway has its external IP address changed so that its current mapping state becomes invalid.
网关的外部IP地址已更改，因此其当前映射状态无效。
The PCP rapid recovery feature enables users to, for example, connect to remote machines using ssh, and then reboot their NAT or firewall device (or even replace it with completely new hardware) without losing their established ssh connections.
例如，PCP快速恢复功能允许用户使用ssh连接到远程计算机，然后重新启动NAT或防火墙设备（甚至用全新硬件替换），而不会丢失已建立的ssh连接。
Use of PCP rapid recovery is a performance optimization to PCP's routine self-healing. Without rapid recovery, PCP clients will still recreate their correct state when they next renew their mappings, but this routine self-healing process may take hours rather than seconds, and will probably not happen fast enough to prevent active TCP connections from timing out.
使用PCP快速恢复是对PCP常规自愈的性能优化。如果没有快速恢复，PCP客户端在下次更新映射时仍将重新创建正确的状态，但此例行自愈过程可能需要数小时而不是数秒，并且可能不会发生足够快的速度来防止活动TCP连接超时。
There are two mechanisms to perform rapid recovery, described below. Failing to implement and deploy a rapid recovery mechanism will encourage application developers to feel the need to refresh their PCP state more frequently than necessary, causing more network traffic. Therefore, a PCP server that can lose state (e.g., due to reboot) or might have a mapping change (e.g., due to IP renumbering) MUST implement either the Announce Opcode or the Mapping Update mechanism and SHOULD implement both mechanisms.
有两种机制可以执行快速恢复，如下所述。如果未能实现和部署快速恢复机制，将鼓励应用程序开发人员感到需要更频繁地刷新其PCP状态，从而导致更多的网络流量。因此，可能会丢失状态（例如，由于重新启动）或可能有映射更改（例如，由于IP重新编号）的PCP服务器必须实现公布操作码或映射更新机制，并且应该实现这两种机制。
This rapid recovery mechanism uses the ANNOUNCE Opcode. When the PCP server loses its state (e.g., it lost its state when rebooted), it resets its Epoch time to its initial starting value (usually zero) and sends the ANNOUNCE response to the link-scoped multicast address (specific address explained below) if a multicast network exists on its local interface, or, if configured with the IP address(es) and port(s) of PCP client(s), it sends unicast ANNOUNCE responses to those address(es) and port(s). This means ANNOUNCE may not be available on all networks (such as networks without a multicast link between the PCP server and its PCP clients). Additionally, an ANNOUNCE request can be sent (unicast) by a PCP client that elicits a unicast ANNOUNCE response like any other Opcode.
这种快速恢复机制使用公布操作码。当PCP服务器失去其状态（例如，重新启动时失去其状态）时，如果本地接口上存在多播网络，或者如果配置了IP地址，则PCP服务器将其历元时间重置为其初始启动值（通常为零），并将通告响应发送到链路范围的多播地址（具体地址如下所述）和PCP客户端的端口，它向这些地址和端口发送单播公告响应。这意味着通告可能无法在所有网络上使用（例如，在PCP服务器及其PCP客户端之间没有多播链路的网络）。此外，PCP客户端可以发送（单播）公告请求，该请求与任何其他操作码一样引发单播公告响应。
Upon receiving PCP response packets with an anomalous Epoch time, clients deduce that the PCP server lost state and recreate their lost mappings.
当接收到具有异常历元时间的PCP响应数据包时，客户端推断PCP服务器丢失状态并重新创建丢失的映射。
The PCP ANNOUNCE Opcode requests and responses have no Opcode-specific payload (that is, the length of the Opcode-specific data is zero). The Requested Lifetime field of requests and Lifetime field of responses are both set to 0 on transmission and ignored on reception.
PCP通告操作码请求和响应没有特定于操作码的负载（即特定于操作码的数据长度为零）。请求的生存期字段和响应的生存期字段在传输时都设置为0，在接收时被忽略。
If a PCP server receives an ANNOUNCE request, it first parses it and generates a SUCCESS if parsing and processing of ANNOUNCE is successful. An error is generated if the client's IP Address field does not match the packet source address, or the request packet is otherwise malformed, such as packet length less than 24 octets. Note that, in the future, options MAY be sent with the PCP ANNOUNCE Opcode; PCP clients and servers need to be prepared to receive options with the ANNOUNCE Opcode.
如果PCP服务器接收到公告请求，它首先解析该请求，如果解析和处理公告成功，则生成一个成功。如果客户端的IP地址字段与数据包源地址不匹配，或者请求数据包格式不正确，例如数据包长度小于24个八位字节，则会生成错误。注意，在将来，选项可能与PCP公告操作码一起发送；PCP客户端和服务器需要准备好接收带有宣布操作码的选项。
Discussion: Client-to-server request messages are sent, from any client source port, to listening UDP port 5351 on the server; server-to-client multicast notifications are sent from the server's UDP port (5351) to listening UDP port 5350 on the client. The reason the same listening UDP port is not used for both purposes is that a single device may have multiple roles. For example, a multi-function home gateway that provides NAT service (PCP server) may also provide printer sharing (which wants a PCP client), or a home computer (PCP client) may also provide "Internet Sharing" (NAT) functionality (which needs to offer PCP service). Such devices need to act as both a PCP server and a PCP client at the same time, and the software that implements the PCP server on the device may not be the same software component that implements the PCP client. The software that implements the PCP server needs to listen for unicast client requests, whereas the software that implements the PCP client needs to listen for multicast restart announcements. In many networking APIs it is difficult or impossible to have two independent clients listening for both unicasts and multicasts on the same port at the same time. For this reason, two ports are used.
讨论：从任何客户端源端口向服务器上的侦听UDP端口5351发送客户端到服务器请求消息；服务器到客户端的多播通知从服务器的UDP端口（5351）发送到客户端上的侦听UDP端口5350。同一侦听UDP端口不能同时用于这两个目的的原因是单个设备可能具有多个角色。例如，提供NAT服务的多功能家庭网关（PCP服务器）也可以提供打印机共享（需要PCP客户端），或者家庭计算机（PCP客户端）也可以提供“互联网共享”（NAT）功能（需要提供PCP服务）。此类设备需要同时充当PCP服务器和PCP客户端，并且在设备上实现PCP服务器的软件可能不是实现PCP客户端的同一软件组件。实现PCP服务器的软件需要侦听单播客户端请求，而实现PCP客户端的软件需要侦听多播重启通知。在许多网络API中，很难或不可能让两个独立的客户端同时监听同一端口上的单播和多播。因此，使用了两个端口。
The PCP ANNOUNCE Opcode MAY be sent (unicast) by a PCP client. The Requested Lifetime value MUST be set to zero.
PCP通告操作码可由PCP客户端发送（单播）。请求的生存期值必须设置为零。
When the PCP server receives the ANNOUNCE Opcode and successfully parses and processes it, it generates SUCCESS response with an assigned lifetime of zero.
当PCP服务器接收到通告操作码并成功解析和处理它时，它将生成分配生存期为零的成功响应。
This functionality allows a PCP client to determine a server's Epoch, or to determine if a PCP server is running, without changing the server's state.
此功能允许PCP客户端在不更改服务器状态的情况下确定服务器的历元，或确定PCP服务器是否正在运行。
When sending unsolicited responses, the ANNOUNCE Opcode MUST have result code equal to zero (SUCCESS), and the packet MUST be sent from the unicast IP address and UDP port number on which PCP requests are received (so that the PCP response processing described in Section 8.3 will accept the message). This message is most typically multicast, but can also be unicast. Multicast PCP restart announcements are sent to 224.0.0.1:5350 and/or [ff02::1]:5350, as described below. Sending PCP restart announcements via unicast requires that the PCP server know the IP address(es) and port(s) of its listening clients, which means that sending PCP restart announcements via unicast is only applicable to PCP servers that retain knowledge of the IP address(es) and port(s) of their clients even after they otherwise lose the rest of their state.
发送未经请求的响应时，通告操作码的结果代码必须等于零（成功），并且必须从接收PCP请求的单播IP地址和UDP端口号发送数据包（以便第8.3节中描述的PCP响应处理将接受消息）。此消息通常是多播的，但也可以是单播的。多播PCP重启通知发送至224.0.0.1:5350和/或[ff02:：1]：5350，如下所述。通过单播发送PCP重启通知要求PCP服务器知道其侦听客户端的IP地址和端口，这意味着通过单播发送PCP重启通知仅适用于保留IP地址和端口信息的PCP服务器他们的客户，即使他们失去了其他的状态。
When a PCP server device that implements this functionality reboots, restarts its NAT engine, or otherwise enters a state where it may have lost some or all of its previous mapping state (or enters a state where it doesn't even know whether it may have had prior state that it lost), it MUST inform PCP clients of this fact by unicasting or multicasting a gratuitous PCP ANNOUNCE Opcode response packet, as shown below, via paths over which it accepts PCP requests. If sending a multicast ANNOUNCE message, a PCP server device that accepts PCP requests over IPv4 sends the Restart Announcement to the IPv4 multicast address 224.0.0.1:5350 (224.0.0.1 is the All Hosts multicast group address), and a PCP server device that accepts PCP requests over IPv6 sends the Restart Announcement to the IPv6 multicast address [ff02::1]:5350 (ff02::1 is for all nodes on the local segment). A PCP server device that accepts PCP requests over both IPv4 and IPv6 sends a pair of Restart Announcements, one to each multicast address. If sending a unicast ANNOUNCE messages, it sends ANNOUNCE response message to the IP address(es) and port(s) of its PCP clients. To accommodate packet loss, the PCP server device MAY transmit such packets (or packet pairs) up to ten times (with an appropriate Epoch Time value in each to reflect the passage of time between transmissions) provided that the interval between the first two notifications is at least 250 ms, and the interval between subsequent notification at least doubles.
当实现此功能的PCP服务器设备重新启动、重新启动其NAT引擎或以其他方式进入可能已丢失部分或全部先前映射状态的状态时（或进入甚至不知道其是否已丢失先前状态的状态），它必须通过接收PCP请求的路径，通过单播或多播免费PCP通告操作码响应包（如下所示）来通知PCP客户端这一事实。如果发送多播通告消息，则通过IPv4接受PCP请求的PCP服务器设备将重新启动通告发送到IPv4多播地址224.0.0.1:5350（224.0.0.1是所有主机多播组地址），通过IPv6接受PCP请求的PCP服务器设备将重新启动通告发送到IPv6多播地址[ff02:：1]：5350（ff02:：1适用于本地网段上的所有节点）。通过IPv4和IPv6接受PCP请求的PCP服务器设备将发送一对重新启动通知，每个重新启动通知一个到多播地址。如果发送单播宣布消息，则会将宣布响应消息发送到IP地址和端口为适应数据包丢失，PCP服务器设备最多可传输此类数据包（或数据包对）十次（每个数据包中具有适当的历元时间值，以反映传输之间的时间流逝）前提是前两次通知之间的间隔至少为250 ms，后续通知之间的间隔至少为两倍。
A PCP client that sends PCP requests to a PCP server via a multicast-capable path, and implements the Restart Announcement feature, and wishes to receive these announcements, MUST listen to receive these PCP Restart Announcements (gratuitous PCP ANNOUNCE Opcode response
通过支持多播的路径向PCP服务器发送PCP请求、实现重启公告功能并希望接收这些公告的PCP客户端必须侦听以接收这些PCP重启公告（免费PCP公告操作码响应）
packets) on the appropriate multicast-capable interfaces on which it sends PCP requests, and MAY also listen for unicast announcements from the server too, (using the UDP port it already uses to issue unicast PCP requests to, and receive unicast PCP responses from, that server). A PCP client device that sends PCP requests using IPv4 listens for packets sent to the IPv4 multicast address 224.0.0.1:5350. A PCP client device that sends PCP requests using IPv6 listens for packets sent to the IPv6 multicast address [ff02::1]:5350. A PCP client device that sends PCP requests using both IPv4 and IPv6 listens for both types of Restart Announcement. The SO_REUSEPORT socket option or equivalent should be used for the multicast UDP port, if required by the host OS to permit multiple independent listeners on the same multicast UDP port.
数据包）在适当的支持多播的接口上发送PCP请求，也可以侦听来自服务器的单播通知（使用它已用于向该服务器发出单播PCP请求并从该服务器接收单播PCP响应的UDP端口）。使用IPv4发送PCP请求的PCP客户端设备侦听发送到IPv4多播地址224.0.0.1:5350的数据包。使用IPv6发送PCP请求的PCP客户端设备侦听发送到IPv6多播地址[ff02:：1]：5350的数据包。同时使用IPv4和IPv6发送PCP请求的PCP客户端设备将侦听这两种类型的重启公告。如果主机操作系统要求在同一个多播UDP端口上允许多个独立的侦听器，则应为多播UDP端口使用SO_REUSEPORT socket选项或等效选项。
Upon receiving a unicasted or multicasted PCP ANNOUNCE Opcode response packet, a PCP client MUST (as it does with all received PCP response packets) inspect the announcement's source IP address, and if the Epoch Time value is outside the expected range for that server, it MUST wait a random amount of time between 0 and 5 seconds (to prevent synchronization of all PCP clients), then for all PCP mappings it made at that server address the client issues new PCP requests to recreate any lost mapping state. The use of the Suggested External IP Address and Suggested External Port fields in the client's renewal requests allows the client to remind the restarted PCP server device of what mappings the client had previously been given, so that in many cases the prior state can be recreated. For PCP server devices that reboot relatively quickly it is usually possible to reconstruct lost mapping state fast enough that existing TCP connections and UDP communications do not time out, and continue without failure. As for all PCP response messages, if the Epoch Time value is within the expected range for that server, the PCP client does not recreate its mappings. As for all PCP response messages, after receiving and validating the ANNOUNCE message, the client updates its own Epoch time for that server, as described in Section 8.5.
在接收到单播或多播PCP通告操作码响应数据包后，PCP客户端必须（与接收到的所有PCP响应数据包一样）检查通告的源IP地址，如果历元时间值超出该服务器的预期范围，则必须等待0到5秒之间的随机时间（防止所有PCP客户端同步），然后，对于在该服务器地址进行的所有PCP映射，客户端发出新的PCP请求以重新创建任何丢失的映射状态。在客户端的续订请求中使用建议的外部IP地址和建议的外部端口字段，允许客户端提醒重新启动的PCP服务器设备客户端以前使用过哪些映射n给定，因此在许多情况下可以重新创建先前的状态。对于重新启动相对较快的PCP服务器设备，通常可以足够快地重建丢失的映射状态，以使现有TCP连接和UDP通信不会超时，并继续进行而不会出现故障。对于所有PCP响应消息，如果历元时间值为在该服务器的预期范围内，PCP客户端不会重新创建其映射。对于所有PCP响应消息，在接收并验证公告消息后，客户端将更新该服务器自己的历元时间，如第8.5节所述。
This rapid recovery mechanism is used when the PCP server remembers its state and determines its existing mappings are invalid (e.g., IP renumbering changes the external IP address of a PCP-controlled NAT).
当PCP服务器记住其状态并确定其现有映射无效（例如，IP重新编号会更改PCP控制的NAT的外部IP地址）时，将使用此快速恢复机制。
It is anticipated that servers that are routinely reconfigured by an administrator or have their WAN address changed frequently will implement this feature (e.g., residential CPE routers). It is anticipated that servers that are not routinely reconfigured will not implement this feature (e.g., service provider-operated CGN).
预计由管理员定期重新配置或其WAN地址经常更改的服务器将实现此功能（例如，住宅CPE路由器）。预计未定期重新配置的服务器不会实现此功能（例如，服务提供商操作的CGN）。
If a PCP server device has not forgotten its mapping state, but for some other reason has determined that some or all of its mappings have become unusable (e.g., when a home gateway is assigned a different external IPv4 address by the upstream DHCP server), then the PCP server device automatically repairs its mappings and notifies its clients by following the procedure described below.
如果PCP服务器设备没有忘记其映射状态，但由于某些其他原因已确定其部分或全部映射已变得不可用（例如，当上行DHCP服务器为家庭网关分配了不同的外部IPv4地址时），然后，PCP服务器设备会自动修复其映射，并按照下面描述的过程通知其客户端。
For PCP-managed mappings, for each one the PCP server device should update the external IP address and external port to appropriate available values, and then send unicast PCP MAP or PEER responses (as appropriate for the mapping) to inform the PCP client of the new external IP address and external port. Such unsolicited responses are identical to the MAP or PEER responses normally returned in response to client MAP or PEER requests, containing newly updated External IP Address and External Port values, and are sent to the same client IP address and port that the PCP server used to send the prior response for that mapping. If the earlier associated request contained the THIRD_PARTY option, the THIRD_PARTY option MUST also appear in the Mapping Update as it is necessary for the PCP client to disambiguate the response. If the earlier associated request contained the PREFER_FAILURE option, and the same external IP address, protocol, and port cannot be provided, the error CANNOT_PROVIDE_EXTERNAL SHOULD be sent. If the earlier associated request contained the FILTER option, the filters are moved to the new mapping and the FILTER option is sent in the Mapping Update response. Non-mandatory options SHOULD NOT be sent in the Mapping Update response.
对于PCP管理的映射，对于每一个映射，PCP服务器设备应将外部IP地址和外部端口更新为适当的可用值，然后发送单播PCP映射或对等响应（视映射情况而定），以通知PCP客户端新的外部IP地址和外部端口。此类未经请求的响应与通常为响应客户端映射或对等请求而返回的映射或对等响应相同，包含新更新的外部IP地址和外部端口值，并发送到PCP服务器用于发送该映射的先前响应的同一客户端IP地址和端口。如果先前关联的请求包含第三方选项，则第三方选项也必须出现在映射更新中，因为PCP客户端需要消除响应的歧义。如果先前关联的请求包含prefere_FAILURE选项，并且无法提供相同的外部IP地址、协议和端口，则应发送错误cannot_PROVIDE_external。如果先前关联的请求包含过滤器选项，则过滤器将移动到新映射，并且过滤器选项将在映射更新响应中发送。映射更新响应中不应发送非强制性选项。
Discussion: It could have been possible to design this so that the PCP server (1) sent an ANNOUNCE Opcode to the PCP client, the PCP client reacted by (2) sending a new MAP request and (3) receiving a MAP response. Instead, the server can create a shortcut for that design by simply sending the message it would have sent in (3).
讨论：可以这样设计：PCP服务器（1）向PCP客户端发送通告操作码，PCP客户端通过（2）发送新的MAP请求和（3）接收MAP响应进行响应。相反，服务器可以通过简单地发送本应发送的消息（3）为该设计创建快捷方式。
To accommodate packet loss, the PCP server device SHOULD transmit such packets three times, with an appropriate Epoch Time value in each to reflect the passage of time between transmissions. The interval between the first two notifications MUST be at least 250 ms, and the third packet after a 500-ms interval. Once the PCP server has received a refreshed state for that mapping, the PCP server SHOULD cease those retransmissions for that mapping, as it serves no further purpose to continue sending messages regarding that mapping.
为了适应分组丢失，PCP服务器设备应当发送这样的分组三次，每次发送具有适当的历元时间值以反映发送之间的时间流逝。前两个通知之间的间隔必须至少为250毫秒，第三个数据包的间隔必须在500毫秒之后。一旦PCP服务器接收到该映射的刷新状态，PCP服务器应停止该映射的那些重传，因为继续发送有关该映射的消息没有其他用途。
Upon receipt of such an updated MAP or PEER response, a PCP client uses the information in the response to adjust rendezvous servers or reconnect to servers, respectively. For MAP, this would mean updating the DNS entries or other address and port information
在收到此类更新的映射或对等响应后，PCP客户端使用响应中的信息分别调整集合服务器或重新连接到服务器。对于MAP，这意味着更新DNS条目或其他地址和端口信息
recorded with some kind of application-specific rendezvous server. For PEER responses giving a CANNOT_PROVIDE_EXTERNAL error, this would typically mean establishing new connections to servers. Anytime the external address or port changes, existing TCP and UDP connections will be lost; PCP can't avoid that, but does provide immediate notification of the event to lessen the impact.
用某种特定于应用程序的集合服务器记录。对于发出CANNOT_PROVIDE_外部错误的对等响应，这通常意味着建立到服务器的新连接。无论何时外部地址或端口发生变化，现有的TCP和UDP连接都将丢失；PCP无法避免这种情况，但确实提供了事件的即时通知，以减少影响。
The PCP client requests a certain lifetime, and the PCP server responds with the assigned lifetime. The PCP server MAY grant a lifetime smaller or larger than the requested lifetime. The PCP server SHOULD be configurable for permitted minimum and maximum lifetime, and the minimum value SHOULD be 120 seconds. The maximum value SHOULD be the remaining lifetime of the IP address assigned to the PCP client if that information is available (e.g., from the DHCP server), or half the lifetime of IP address assignments on that network if the remaining lifetime is not available, or 24 hours. Excessively long lifetimes can cause consumption of ports even if the internal host is no longer interested in receiving the traffic or is no longer connected to the network. These recommendations are not strict, and deployments should evaluate the trade-offs to determine their own minimum and maximum Lifetime values.
PCP客户端请求一个特定的生存期，PCP服务器响应指定的生存期。PCP服务器可以授予小于或大于请求的生存期的生存期。PCP服务器应可配置允许的最小和最大生存期，最小值应为120秒。最大值应为分配给PCP客户端的IP地址的剩余生存期（如果该信息可用）（例如，来自DHCP服务器），或该网络上IP地址分配的一半生存期（如果剩余生存期不可用），或24小时。即使内部主机不再对接收流量感兴趣或不再连接到网络，过长的生命周期也可能导致端口消耗。这些建议并不严格，部署应评估权衡，以确定自己的最小和最大生存期值。
Once a PCP server has responded positively to a MAP request for a certain lifetime, the port mapping is active for the duration of the lifetime unless the lifetime is reduced by the PCP client (to a shorter lifetime or to zero) or until the PCP server loses its state (e.g., crashes). Mappings created by PCP MAP requests are not special or different from mappings created in other ways. In particular, it is implementation-dependent if outgoing traffic extends the lifetime of such mappings beyond the PCP-assigned lifetime. PCP clients MUST NOT depend on this behavior to keep mappings active, and MUST explicitly renew their mappings as required by the Lifetime field in PCP response messages.
一旦PCP服务器在某一生存期内对映射请求做出了积极响应，端口映射将在该生存期内处于活动状态，除非PCP客户端将该生存期缩短（缩短到更短的生存期或为零），或者直到PCP服务器失去其状态（例如崩溃）。由PCP映射请求创建的映射与以其他方式创建的映射没有特殊或不同。特别是，如果传出流量将此类映射的生存期延长到PCP分配的生存期之外，则这取决于实现。PCP客户端不能依赖此行为来保持映射处于活动状态，并且必须根据PCP响应消息中的生存期字段的要求显式更新其映射。
Upon receipt of a PCP response with an absurdly long assigned lifetime, the PCP client SHOULD behave as if it received a more sane value (e.g., 24 hours), and renew the mapping accordingly, to ensure that if the static mapping is removed, the client will continue to maintain the mapping it desires.
在收到具有超长的指定生存期的PCP响应后，PCP客户端应表现为接收到更正常的值（例如24小时），并相应地更新映射，以确保如果删除静态映射，客户端将继续保持其所需的映射。
An application that forgets its PCP-assigned mappings (e.g., the application or OS crashes) will request new PCP mappings. This may consume port mappings, if the application binds to a different internal port every time it runs. The application will also likely initiate new outbound TCP connections, which create implicit dynamic outbound mappings without using PCP, which will also consume port
忘记其PCP分配映射的应用程序（例如，应用程序或操作系统崩溃）将请求新的PCP映射。如果应用程序每次运行时都绑定到不同的内部端口，则这可能会使用端口映射。应用程序还可能启动新的出站TCP连接，该连接在不使用PCP的情况下创建隐式动态出站映射，而PCP也将使用端口
mappings. If there is a port mapping quota for the internal host, frequent restarts such as this may exhaust the quota.
映射。如果有内部主机的端口映射配额，则频繁的重启（如这样）可能会耗尽配额。
To help clean PCP state, when the PCP-controlled device is collocated with the address assignment (DHCP) server, such as in a typical residential CPE, it is RECOMMENDED that when an IP address becomes invalid (e.g., the DHCP lease expires, or the DHCP client sends an explicit DHCP RELEASE) the PCP-controlled device SHOULD also discard any dynamic mapping state relating to that expired IP address.
为了帮助清除PCP状态，当PCP控制的设备与地址分配（DHCP）服务器并置时，例如在典型的住宅CPE中，建议在IP地址无效时（例如，DHCP租约到期，或DHCP客户端发送显式DHCP释放）PCP控制的设备还应丢弃与该过期IP地址相关的任何动态映射状态。
When using NAT, the same external port may be assigned for use by different internal hosts at different times. For example, if an internal host using an external port ceases sending traffic using that port, then its mapping may expire, and then later the same external port may be assigned to a new internal host. The new internal host could then receive incoming traffic that was intended for the previous internal host. This generally happens inadvertently, and this reassignment of the external port only happens after the current holder of the external port has ceased using it for some period of time. It would be unacceptable if an attacker could use PCP to intentionally speed up this reassignment of the external port in order to deliberately steal traffic intended for the current holder, by (i) spoofing PCP requests using the current holder's source IP address and mapping nonce to fraudulently delete the mapping or shorten its lifetime, and then (ii) subsequently claiming the external port for itself.
使用NAT时，相同的外部端口可能会分配给不同的内部主机在不同的时间使用。例如，如果使用外部端口的内部主机停止使用该端口发送通信量，则其映射可能会过期，随后可能会将相同的外部端口分配给新的内部主机。然后，新的内部主机可以接收用于前一个内部主机的传入流量。这种情况通常是无意中发生的，外部端口的这种重新分配只有在外部端口的当前持有者停止使用它一段时间后才会发生。如果攻击者可以使用PCP故意加速外部端口的重新分配，以便通过（i）使用当前持有者的源IP地址和映射nonce欺骗PCP请求，以欺诈性地删除映射或缩短其生存期，从而故意窃取针对当前持有者的通信量，这将是不可接受的，然后（ii）随后为其自身申请外部端口。
Therefore, in the simple security model, to protect against this attack, PCP MUST NOT allow a PCP request (even a PCP request that appears to come from the current holder of the mapping) to cause a mapping to expire sooner than it would naturally have expired otherwise by virtue of outbound traffic keeping the mapping active. A PCP server MUST set the lifetime of a mapping to no less than the remaining time before the mapping would expire if no further outbound traffic is seen for that mapping. This means a MAP or PEER request with lifetime of 0 will only set the assigned lifetime to 0 (i.e., delete the mapping) if the internal host had not sent a packet using that mapping for the idle-timeout time, otherwise the assigned lifetime will be the remaining idle-timeout time.
因此，在简单的安全模型中，为了防止这种攻击，PCP不得允许PCP请求（即使是来自映射当前持有者的PCP请求）导致映射提前到期，否则由于出站流量保持映射活动，映射自然会提前到期。如果没有看到映射的进一步出站流量，则PCP服务器必须将映射的生存期设置为不少于映射过期之前的剩余时间。这意味着，如果内部主机在空闲超时时间内没有使用映射发送数据包，则生存期为0的映射或对等请求将仅将分配的生存期设置为0（即删除映射），否则分配的生存期将是剩余的空闲超时时间。
Finally, to reduce unwanted traffic and data corruption for both TCP and UDP, the assigned external port created by the MAP Opcode or PEER Opcode SHOULD NOT be reused for an interval equal to the reuse time limit enforced by the NAT for its implicit dynamic mappings (typically, the maximum TCP segment lifetime of 2 minutes [RFC0793]). Furthermore, to reduce port stealing attacks, the assigned external port also SHOULD NOT be reused for an interval equal to the time the PCP- controlled device would normally maintain an idle (no traffic)
最后，为了减少TCP和UDP不必要的通信量和数据损坏，由映射操作码或对等操作码创建的分配的外部端口不应在等于NAT为其隐式动态映射强制执行的重用时间限制的时间间隔内重用（通常，最大TCP段生存期为2分钟[RFC0793]）。此外，为了减少端口窃取攻击，分配的外部端口也不应在与PCP控制设备正常保持空闲（无流量）的时间间隔相等的时间内重复使用
implicit dynamic mapping (e.g., 2 minutes for UDP [RFC4787] and 124 minutes for TCP [RFC5382]). However, within these time windows, the PCP server SHOULD allow an external port to be reclaimed by the same client, where "same client" means "same internal IP address, internal port, and mapping nonce".
隐式动态映射（例如，UDP[RFC4787]为2分钟，TCP[RFC5382]为124分钟）。但是，在这些时间窗口内，PCP服务器应允许同一客户端回收外部端口，其中“同一客户端”表示“相同的内部IP地址、内部端口和映射nonce”。
If the requested lifetime is zero then:
如果请求的生存期为零，则：
o If both the protocol and internal port are non-zero, it indicates a request to delete the indicated mapping immediately.
o 如果协议和内部端口均为非零，则表示请求立即删除指示的映射。
o If the protocol is non-zero and the internal port is zero, it indicates a request to delete a previous 'wildcard' (all-ports) mapping for that protocol. The nonce MUST match the nonce used to create the 'wildcard' mapping.
o 如果协议为非零且内部端口为零，则表示请求删除该协议以前的“通配符”（所有端口）映射。nonce必须与用于创建“通配符”映射的nonce匹配。
o If both the protocol and internal port are zero, it indicates a request to delete a previous 'DMZ host' (all incoming traffic for all protocols) mapping. The nonce MUST match the nonce used to create the 'DMZ host' mapping.
o 如果协议和内部端口均为零，则表示请求删除以前的“DMZ主机”（所有协议的所有传入流量）映射。nonce必须与用于创建“DMZ主机”映射的nonce匹配。
o If the protocol is zero and the internal port is non-zero, then the request is invalid and the PCP server MUST return a MALFORMED_REQUEST error to the client.
o 如果协议为零且内部端口为非零，则请求无效，PCP服务器必须向客户端返回格式错误的_请求错误。
In requests where the requested Lifetime is 0, the Suggested External Address and Suggested External Port fields MUST be set to zero on transmission and MUST be ignored on reception, and these fields MUST be copied into the assigned external IP address and assigned external port of the response.
在请求的生存期为0的请求中，建议的外部地址和建议的外部端口字段在传输时必须设置为零，在接收时必须忽略，并且这些字段必须复制到响应的分配的外部IP地址和分配的外部端口中。
PCP MAP requests can only delete or shorten lifetimes of MAP-created mappings. If the PCP client attempts to delete a static mapping (i.e., a mapping created outside of PCP itself), or an outbound (implicit or PEER-created) mapping, the PCP server MUST return NOT_AUTHORIZED. If the PCP client attempts to delete a mapping that does not exist, the SUCCESS result code is returned (this is necessary for PCP to return the same response for retransmissions or duplications of the same request). If the deletion request was properly formatted and successfully processed, a SUCCESS response is generated with the protocol and internal port number copied from the request, and the response lifetime set to zero. An inbound mapping (i.e., static mapping or MAP-created dynamic mapping) MUST NOT have its lifetime reduced by transport protocol messages (e.g., TCP RST, TCP FIN). Note the THIRD_PARTY option (Section 13.1), if authorized, can also delete PCP-created MAP mappings.
PCP映射请求只能删除或缩短映射创建的映射的生命周期。如果PCP客户端试图删除静态映射（即，在PCP自身之外创建的映射）或出站（隐式或对等创建的）映射，则PCP服务器必须返回NOT_AUTHORIZED。如果PCP客户端尝试删除不存在的映射，则返回成功结果代码（这对于PCP返回相同请求的重新传输或复制的相同响应是必要的）。如果删除请求已正确格式化并成功处理，则会生成一个成功响应，其中包含从请求复制的协议和内部端口号，并且响应生存期设置为零。入站映射（即静态映射或映射创建的动态映射）的生存期不得因传输协议消息（例如TCP RST、TCP FIN）而缩短。注：第三方选项（第13.1节）如果获得授权，也可以删除PCP创建的映射。
Section 16 provides non-normative guidance that may be useful to implementers.
第16节提供了可能对实施者有用的非规范性指导。
For implicit dynamic outbound mappings, some existing NAT devices have endpoint-independent mapping (EIM) behavior while other NAT devices have endpoint-dependent mapping (EDM) behavior. NATs that have EIM behavior do not suffer from the problem described in this section. The IETF strongly encourages EIM behavior [RFC4787][RFC5382].
对于隐式动态出站映射，一些现有NAT设备具有端点独立映射（EIM）行为，而其他NAT设备具有端点依赖映射（EDM）行为。具有EIM行为的NAT不会遇到本节中描述的问题。IETF强烈鼓励EIM行为[RFC4787][RFC5382]。
In EDM NAT devices, the same external port may be used by an outbound dynamic mapping and an inbound dynamic mapping (from the same internal host or from a different internal host). This complicates the interaction with the MAP Opcode. With such NAT devices, there are two ways envisioned to implement the MAP Opcode:
在EDM NAT设备中，出站动态映射和入站动态映射（来自同一内部主机或不同的内部主机）可以使用相同的外部端口。这使与MAP操作码的交互变得复杂。使用此类NAT设备，有两种实现MAP操作码的方式：
1. Have outbound mappings use a different set of external ports than inbound mappings (e.g., those created with MAP), thus reducing the interaction problem between them; or
1. 让出站映射使用与入站映射不同的一组外部端口（例如，使用MAP创建的端口），从而减少它们之间的交互问题；或
2. On arrival of a packet (inbound from the Internet or outbound from an internal host), first attempt to use a dynamic outbound mapping to process that packet. If none match, attempt to use an inbound mapping to process that packet. This effectively 'prioritizes' outbound mappings above inbound mappings.
2. 数据包到达时（从Internet入站或从内部主机出站），首先尝试使用动态出站映射来处理该数据包。如果没有匹配项，则尝试使用入站映射来处理该数据包。这有效地将出站映射“优先”于入站映射。
No matter if a NAT is EIM or EDM, it is possible that one (or more) outbound mappings, using the same internal port on the internal host, might be created before or after a MAP request. When this occurs, it is important that the NAT honor the lifetime returned in the MAP response. Specifically, if an inbound mapping was created with the MAP Opcode, the implementation needs to ensure that termination of an outbound mapping (e.g., via a TCP FIN handshake) does not prematurely destroy the MAP-created inbound mapping.
无论NAT是EIM还是EDM，都有可能在映射请求之前或之后创建一个（或多个）出站映射，使用内部主机上的相同内部端口。发生这种情况时，NAT必须遵守MAP响应中返回的生存期。具体而言，如果使用映射操作码创建入站映射，则实现需要确保出站映射的终止（例如，通过TCP FIN握手）不会过早地破坏映射创建的入站映射。
If an event occurs that causes the PCP server to lose dynamic mapping state (such as a crash or power outage), the mappings created by PCP are lost. Occasional loss of state may be unavoidable in a residential NAT device that does not write transient information to non-volatile memory. Loss of state is expected to be rare in a
如果发生导致PCP服务器失去动态映射状态（如崩溃或断电）的事件，则PCP创建的映射将丢失。在不向非易失性存储器写入瞬态信息的住宅NAT设备中，偶尔的状态丢失可能是不可避免的。在一个国家里，失去状态的情况预计是罕见的
service provider environment (due to redundant power, disk drives for storage, etc.). Of course, due to outright failure of service provider equipment (e.g., software malfunction), state may still be lost.
服务提供商环境（由于冗余电源、用于存储的磁盘驱动器等）。当然，由于服务提供商设备的彻底故障（例如，软件故障），状态可能仍然会丢失。
The Epoch time allows a client to deduce when a PCP server may have lost its state. When the Epoch Time value is observed to be outside the expected range, the PCP client can attempt to recreate the mappings following the procedures described in this section.
纪元时间允许客户端推断PCP服务器何时可能已失去其状态。当观测到历元时间值超出预期范围时，PCP客户端可以尝试按照本节中描述的步骤重新创建映射。
Further analysis of PCP failure scenarios is planned for a future document [PCP-FAIL].
计划在未来的文件[PCP-FAIL]中进一步分析PCP故障场景。
A mapping renewal packet is formatted identically to an original mapping request; from the point of view of the client, it is a renewal of an existing mapping; however, from the point of view of a newly rebooted PCP server, it appears as a new mapping request. In the normal process of routinely renewing its mappings before they expire, a PCP client will automatically recreate all its lost mappings.
映射更新包的格式与原始映射请求相同；从客户的角度来看，这是对现有地图的更新；但是，从新重新启动的PCP服务器的角度来看，它似乎是一个新的映射请求。在映射到期前例行更新映射的正常过程中，PCP客户端将自动重新创建其所有丢失的映射。
When the PCP server loses state and begins processing new PCP messages, its Epoch time is reset and begins counting again. As the result of receiving a packet where the Epoch Time field is outside the expected range (Section 8.5), indicating that a reboot or similar loss of state has occurred, the client can renew its port mappings sooner, without waiting for the normal routine renewal time.
当PCP服务器失去状态并开始处理新的PCP消息时，其历元时间将重置并再次开始计数。由于接收到一个数据包，其中历元时间字段超出预期范围（第8.5节），表明已发生重新启动或类似的状态丢失，客户端可以更快地更新其端口映射，而无需等待正常的例行程序更新时间。
A PCP client refreshes a mapping by sending a new PCP request containing information learned from the earlier PCP response. The PCP server will respond indicating the new lifetime. It is possible, due to reconfiguration or failure of the PCP server, that the external IP address and/or external port, or the PCP server itself, has changed (due to a new route to a different PCP server). Such events are rare, but not an error. The PCP server will simply return a new external address and/or external port to the client, and the client should record this new external address and port with its rendezvous service. To detect such events more quickly, a server that requires extremely high availability may find it beneficial to use shorter lifetimes in its PCP mappings requests, so that it communicates with the PCP server more often. This is an engineering trade-off based on (i) the acceptable downtime for the service in question, (ii) the expected likelihood of NAT or firewall state loss, and (iii) the amount of PCP maintenance traffic that is acceptable.
PCP客户端通过发送一个新的PCP请求来刷新映射，该请求包含从早期PCP响应中获取的信息。PCP服务器将响应指示新的生存期。由于PCP服务器的重新配置或故障，外部IP地址和/或外部端口或PCP服务器本身可能发生了变化（由于到不同PCP服务器的新路由）。这样的事件很少见，但不是错误。PCP服务器将简单地向客户端返回一个新的外部地址和/或外部端口，客户端应记录此新的外部地址和端口及其会合服务。为了更快地检测此类事件，需要极高可用性的服务器可能会发现在其PCP映射请求中使用更短的生存期是有益的，这样它就可以更频繁地与PCP服务器通信。这是一种工程权衡，基于（i）相关服务的可接受停机时间，（ii）NAT或防火墙状态丢失的预期可能性，以及（iii）可接受的PCP维护通信量。
If the PCP client has several mappings, the Epoch Time value only needs to be retrieved for one of them to determine whether or not it appears the PCP server may have suffered a catastrophic loss of state. If the client wishes to check the PCP server's Epoch time, it sends a PCP request for any one of the client's mappings. This will return the current Epoch Time value. In that request, the PCP client could extend the mapping lifetime (by asking for more time) or maintain the current lifetime (by asking for the same number of seconds that it knows are remaining of the lifetime).
如果PCP客户端有多个映射，则只需检索其中一个映射的历元时间值，以确定PCP服务器是否出现了灾难性的状态丢失。如果客户机希望检查PCP服务器的Epoch时间，它会发送一个PCP请求，请求任何一个客户机映射。这将返回当前历元时间值。在该请求中，PCP客户机可以延长映射生存期（通过请求更多时间）或保持当前生存期（通过请求知道生存期剩余的秒数）。
If a PCP client changes its internal IP address (e.g., because the internal host has moved to a new network), and the PCP client wishes to still receive incoming traffic, it needs create new mappings on that new network. New mappings will typically also require an update to the application-specific rendezvous server if the external address or port is different from the previous values (see Sections 10.1 and 11.5).
如果PCP客户端更改其内部IP地址（例如，因为内部主机已移动到新网络），并且PCP客户端仍希望接收传入流量，则需要在该新网络上创建新映射。如果外部地址或端口与以前的值不同，则新映射通常还需要更新特定于应用程序的集合服务器（请参见第10.1节和第11.5节）。
Although SCTP has port numbers like TCP and UDP, SCTP works differently when behind an address-sharing NAT, in that SCTP port numbers are not changed [SCTPNAT]. Outbound dynamic SCTP mappings use the verification tag of the association instead of the local and remote peer port numbers. As with TCP, explicit outbound mappings can be made to reduce keepalive intervals, and explicit inbound mappings can be made by passive listeners expecting to receive new associations at the external port.
尽管SCTP有TCP和UDP等端口号，但SCTP在地址共享NAT之后的工作方式不同，因为SCTP端口号不会改变[SCTPNAT]。出站动态SCTP映射使用关联的验证标记，而不是本地和远程对等端口号。与TCP一样，可以进行显式出站映射以减少保留间隔，并且可以由期望在外部端口接收新关联的被动侦听器进行显式入站映射。
Because an SCTP-aware NAT does not (currently) rewrite SCTP port numbers, it will not be able to assign an external port that is different from the client's internal port. A PCP client making a MAP request for SCTP should be aware of this restriction. The PCP client SHOULD make its SCTP MAP request just as it would for a TCP MAP request: in its initial PCP MAP request it SHOULD specify zero for the external address and port, and then in subsequent renewals it SHOULD echo the assigned external address and port. However, since a current SCTP-aware NAT can only assign an external port that is the same as the internal port, it may not be able to do that if the external port is already assigned to a different PCP client. This is likely if there is more than one instance of a given SCTP service on the local network, since both instances are likely to listen on the same well-known SCTP port for that service on their respective hosts, but they can't both have the same external port on the NAT gateway's external address. A particular external port may not be assignable for other reasons, such as when it is already in use by the NAT device itself, or otherwise prohibited by policy, as described in Section 11.3, "Processing a MAP Request". In the event that the
由于支持SCTP的NAT（当前）不会重写SCTP端口号，因此无法分配与客户端内部端口不同的外部端口。为SCTP发出MAP请求的PCP客户端应了解此限制。PCP客户端应该像对待TCP映射请求一样发出SCTP映射请求：在初始PCP映射请求中，它应该为外部地址和端口指定零，然后在后续续订中，它应该回显分配的外部地址和端口。但是，由于当前支持SCTP的NAT只能分配与内部端口相同的外部端口，因此如果外部端口已分配给不同的PCP客户端，则可能无法分配。如果在本地网络上有一个以上的给定SCTP服务实例，则很可能出现这种情况，因为两个实例都可能在其各自主机上侦听该服务的同一个众所周知的SCTP端口，但它们不能在NAT网关的外部地址上都具有相同的外部端口。特定外部端口可能因其他原因而不可分配，例如NAT设备本身已在使用该端口，或者如第11.3节“处理映射请求”中所述，被政策禁止。如果
external port matching the internal port cannot be assigned (and the SCTP-aware NAT does not perform SCTP port rewriting), the SCTP-aware NAT MUST return a CANNOT_PROVIDE_EXTERNAL error to the requesting PCP client. Note that this restriction places an extra burden on the SCTP server whose MAP request failed, because it then has to tear down its exiting listening socket and try again with a different internal port, repeatedly until it is successful in finding an external port it can use.
无法分配与内部端口匹配的外部端口（且支持SCTP的NAT不执行SCTP端口重写），支持SCTP的NAT必须向请求的PCP客户端返回“无法提供”外部错误。请注意，此限制会给映射请求失败的SCTP服务器带来额外负担，因为它必须断开其现有侦听套接字并使用不同的内部端口重试，直到成功找到可以使用的外部端口为止。
The SCTP complications described above occur because of address sharing. The SCTP complications are avoided when address sharing is avoided (e.g., 1:1 NAT, firewall).
由于地址共享，出现了上述SCTP复杂性。当避免地址共享（例如，1:1 NAT、防火墙）时，可以避免SCTP复杂性。
All PCP requests include the PCP client's IP address replicated in the PCP header. This is used to detect unexpected address rewriting (NAT) on the path between the PCP client and its PCP server. On operating systems that support the sockets API, the following steps are RECOMMENDED for a PCP client to insert the correct source address in the PCP header:
所有PCP请求都包括在PCP标头中复制的PCP客户端IP地址。这用于检测PCP客户端与其PCP服务器之间路径上的意外地址重写（NAT）。在支持套接字API的操作系统上，建议PCP客户端执行以下步骤，以便在PCP标头中插入正确的源地址：
1. Create a UDP socket. 2. Call "connect" on this UDP socket using the address and port of the desired PCP server. 3. Call the getsockname() function to retrieve a sockaddr containing the source address the kernel will use for UDP packets sent through this socket. 4. If the IP address is an IPv4 address, encode the address into an IPv4-mapped IPv6 address. Place the IPv4-mapped IPv6 address or the native IPv6 address into the PCP Client's IP Address field in the PCP header. 5. Send PCP requests using this connected UDP socket.
1. 创建UDP套接字。2.使用所需PCP服务器的地址和端口在此UDP套接字上调用“connect”。3.调用getsockname（）函数检索sockaddr，其中包含内核将用于通过此套接字发送的UDP数据包的源地址。4.如果IP地址是IPv4地址，请将该地址编码为IPv4映射的IPv6地址。将IPv4映射的IPv6地址或本机IPv6地址放入PCP标头中PCP客户端的IP地址字段中。5.使用此连接的UDP套接字发送PCP请求。
Each mapping entry of the PCP-controlled device would go through the state machine shown below. This state diagram is non-normative.
PCP控制设备的每个映射条目都将经过如下所示的状态机。此状态图是非规范性的。
CLOSE_MSG or
(NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY
+-------------->| |<------------+
| |NO_ENTRY | |
| +-----------| |---------+ |
| | +---------+ | |
| | ^ | | |
| | NO_TRAFFIC | | | |
| | or | | | |
| | CLOSE_MSGS | | | |
| | | | | |
| |PEER request | | MAP request| |
| V | | V |
+---------+ | | +---------+
+-->| "P", | | | M-R | "M", |<--+
P-R | | PEER |-----------|--|-------->| MAP | | M-R or
+---| mapping| | | | mapping|---+ P-R or
+---------+ | | +---------+ CLOSE_MSGS
| ^ | | ^ |
| |PEER request | | MAP request| |
| | | | | |
| | | | | |
| | | | | |
| | | | outbound | |
| | | | TRAFFIC | |
| | | V | |
| | +---------+ | |
| +-----------| "I", |---------+ |
| | implicit| |
+-------------->| mapping |<------------+
TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY
CLOSE_MSG or
(NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY
+-------------->| |<------------+
| |NO_ENTRY | |
| +-----------| |---------+ |
| | +---------+ | |
| | ^ | | |
| | NO_TRAFFIC | | | |
| | or | | | |
| | CLOSE_MSGS | | | |
| | | | | |
| |PEER request | | MAP request| |
| V | | V |
+---------+ | | +---------+
+-->| "P", | | | M-R | "M", |<--+
P-R | | PEER |-----------|--|-------->| MAP | | M-R or
+---| mapping| | | | mapping|---+ P-R or
+---------+ | | +---------+ CLOSE_MSGS
| ^ | | ^ |
| |PEER request | | MAP request| |
| | | | | |
| | | | | |
| | | | | |
| | | | outbound | |
| | | | TRAFFIC | |
| | | V | |
| | +---------+ | |
| +-----------| "I", |---------+ |
| | implicit| |
+-------------->| mapping |<------------+
TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY
Figure 16: PCP State Diagram
图16:PCP状态图
The meanings of the states and events are:
状态和事件的含义如下：
NO_ENTRY: Invalid state represents Entry does not exist. This is the only possible start state.
无项：无效状态表示项不存在。这是唯一可能的启动状态。
M-R: MAP request
M-R：映射请求
P-R: PEER request
P-R：对等请求
M: Mapping entry when created by MAP request
M：由映射请求创建时的映射条目
P: Mapping entry when created/managed by PEER request
P：由对等请求创建/管理时的映射条目
I: Implicit mapping created by an outgoing packet from the client (e.g., TCP SYN), and also the state when a PCP-created mapping's lifetime expires while there is still active traffic.
I：由来自客户端的传出数据包（例如，TCP SYN）创建的隐式映射，以及PCP创建的映射的生存期到期而仍有活动流量时的状态。
EXPIRY: PEER or MAP lifetime expired
过期：对等或映射生存期已过期
TRAFFIC: Traffic seen by PCP-controlled device using this entry within the expiry time for that entry. This traffic may be inbound or outbound.
流量：PCP控制设备在该条目的到期时间内使用该条目看到的流量。此流量可以是入站或出站。
NO_TRAFFIC: Indicates that there is no TRAFFIC.
无流量：表示没有流量。
CLOSE_MSG: Protocol messages from the client or server to close the session (e.g., TCP FIN or TCP RST), as per the NAT or firewall device's handling of such protocol messages.
CLOSE_MSG：根据NAT或防火墙设备对此类协议消息的处理，来自客户端或服务器的协议消息，用于关闭会话（例如，TCP FIN或TCP RST）。
Notes on the diagram:
图表上的注释：
1. The 'and' clause indicates the events on either side of 'and' are required for the state-transition. The 'or' clause indicates either one of the events are enough for the state-transition.
1. and子句表示状态转换需要and两侧的事件。'or'子句表示其中一个事件足以进行状态转换。
2. Transition from state M to state I is implementation dependent.
2. 从状态M到状态I的转换依赖于实现。
As with implicit dynamic mappings created by outgoing TCP SYN packets, explicit dynamic mappings created via PCP use the source IP address of the packet as the internal address for the mappings. Therefore, ingress filtering [RFC2827] SHOULD be used on the path between the internal host and the PCP server to prevent the injection of spoofed packets onto that path.
与传出TCP SYN数据包创建的隐式动态映射一样，通过PCP创建的显式动态映射使用数据包的源IP地址作为映射的内部地址。因此，应在内部主机和PCP服务器之间的路径上使用入口过滤[RFC2827]，以防止向该路径注入伪造数据包。
On PCP-controlled devices that create state when a mapping is created (e.g., NAT), the PCP server SHOULD maintain per-host and/or per-subscriber quotas for mappings. It is implementation specific whether the PCP server uses a separate quotas for implicit, explicit, and static mappings, a combined quota for all of them, or some other policy.
在创建映射时创建状态的PCP控制设备（例如NAT）上，PCP服务器应维护映射的每主机和/或每订户配额。PCP服务器是否对隐式、显式和静态映射使用单独的配额，对所有映射使用组合配额，或者使用其他一些策略，这取决于具体的实现。
The goal of the PCP protocol is to improve the ability of end nodes to control their associated NAT state, and to improve the efficiency and error handling of NAT mappings when compared to existing implicit mapping mechanisms in NAT boxes and stateful firewalls. It is the security goal of the PCP protocol to limit any new denial-of-service opportunities, and to avoid introducing new attacks that can result in unauthorized changes to mapping state. One of the most serious consequences of unauthorized changes in mapping state is traffic theft. All mappings that could be created by a specific host using implicit mapping mechanisms are inherently considered to be authorized. Confidentiality of mappings is not a requirement, even in cases where the PCP messages may transit paths that would not be traveled by the mapped traffic.
PCP协议的目标是提高终端节点控制其相关NAT状态的能力，并与NAT盒和有状态防火墙中现有的隐式映射机制相比，提高NAT映射的效率和错误处理。PCP协议的安全目标是限制任何新的拒绝服务机会，并避免引入可能导致未经授权更改映射状态的新攻击。未经授权更改映射状态的最严重后果之一是流量盗窃。所有可以由特定主机使用隐式映射机制创建的映射本质上都被认为是授权的。映射的机密性不是一项要求，即使在PCP消息可能传输映射流量不会传输的路径的情况下也是如此。
PCP servers are secure against off-path attackers who cannot spoof a packet that the PCP server will view as a packet received from the internal network. PCP clients are secure against off-path attackers who can spoof the PCP server's IP address.
PCP服务器可以抵御无法欺骗PCP服务器将视为从内部网络接收的数据包的非路径攻击者。PCP客户端可安全抵御可欺骗PCP服务器IP地址的非路径攻击者。
Defending against attackers who can modify or drop packets between the internal network and the PCP server, or who can inject spoofed packets that appear to come from the internal network is out of scope. Such an attacker can redirect traffic to a host of their choosing.
防止攻击者修改或丢弃内部网络和PCP服务器之间的数据包，或注入看似来自内部网络的伪造数据包的攻击超出范围。这样的攻击者可以将流量重定向到他们选择的主机。
A PCP server is secure under this threat model if the PCP server is constrained so that it does not configure any explicit mapping that it would not configure implicitly. In most cases, this means that PCP servers running on NAT boxes or stateful firewalls that support the PEER and MAP Opcodes can be secure under this threat model if (1) all of their hosts are within a single administrative domain (or if the internal hosts can be securely partitioned into separate administrative domains, as in the DS-Lite B4 case), (2) explicit mappings are created with the same lifetime as implicit mappings, and (3) the THIRD_PARTY option is not supported. PCP servers can also securely support the MAP Opcode under this threat model if the security policy on the device running the PCP server would permit endpoint-independent filtering of implicit mappings.
如果PCP服务器受到约束，因此不会配置任何其不会隐式配置的显式映射，则在此威胁模型下，PCP服务器是安全的。在大多数情况下，这意味着运行在NAT盒或支持对等操作码和MAP操作码的有状态防火墙上的PCP服务器在这种威胁模型下是安全的，前提是（1）它们的所有主机都在单个管理域内（或者如果内部主机可以安全地划分为单独的管理域，如DS Lite B4的情况），（2）使用与隐式映射相同的生存期创建显式映射，（3）不支持第三方选项。如果运行PCP服务器的设备上的安全策略允许对隐式映射进行端点独立过滤，则PCP服务器还可以在此威胁模型下安全地支持映射操作码。
PCP servers that comply with the Simple Threat Model and do not implement a PCP security mechanism described in Section 18.2 MUST enforce the constraints described in the paragraph above.
符合简单威胁模型且未实施第18.2节所述PCP安全机制的PCP服务器必须强制执行上述段落中所述的约束。
o If you allow multiple administrative domains to send PCP requests to a single PCP server that does not enforce a boundary between the domains, it is possible for a node in one domain to perform a denial-of-service attack on other domains or to capture traffic that is intended for a node in another domain.
o 如果允许多个管理域向单个PCP服务器发送PCP请求，而该PCP服务器不强制域之间的边界，则一个域中的节点可能会对其他域执行拒绝服务攻击，或者捕获另一个域中的节点的通信量。
o If explicit mappings have longer lifetimes than implicit mappings, it makes it easier to perpetrate a denial-of-service attack than it would be if the PCP server was not present.
o 如果显式映射比隐式映射具有更长的生命周期，则与PCP服务器不存在时相比，更容易实施拒绝服务攻击。
o If the PCP server supports deleting or reducing the lifetime of existing mappings, this allows an attacking node to steal an existing mapping and receive traffic that was intended for another node.
o 如果PCP服务器支持删除或缩短现有映射的生存期，则这将允许攻击节点窃取现有映射并接收用于其他节点的通信量。
o If the THIRD_PARTY option is supported, this also allows an attacker to open a window for an external node to attack an internal node, allows an attacker to steal traffic that was intended for another node, or may facilitate a denial-of-service attack. One example of how the THIRD_PARTY option could grant an attacker more capability than a spoofed implicit mapping is that the PCP server (especially if it is running in a service provider's network) may not be aware of internal filtering that would prevent spoofing an equivalent implicit mapping, such as filtering between a guest and corporate network.
o 如果支持第三方选项，这还允许攻击者打开一个窗口，让外部节点攻击内部节点，允许攻击者窃取用于另一个节点的流量，或者可能助长拒绝服务攻击。第三方选项如何授予攻击者比欺骗隐式映射更大的能力的一个示例是，PCP服务器（尤其是在服务提供商的网络中运行的PCP服务器）可能不知道会阻止欺骗等效隐式映射的内部筛选，例如，在来宾和公司网络之间进行过滤。
o If the MAP Opcode is supported by the PCP server in cases where the security policy would not support endpoint-independent filtering of implicit mappings, then the MAP Opcode changes the security properties of the device running the PCP server by allowing explicit mappings that violate the security policy.
o 如果在安全策略不支持隐式映射的端点独立筛选的情况下，PCP服务器支持映射操作码，则映射操作码通过允许违反安全策略的显式映射来更改运行PCP服务器的设备的安全属性。
This section offers two examples of how the Simple Threat Model can be supported in real-world deployment scenarios.
本节提供了两个示例，说明如何在实际部署场景中支持简单威胁模型。
Parity with many currently deployed residential gateways can be achieved using a PCP server that is constrained as described in Section 18.1 above.
可以使用PCP服务器实现与许多当前部署的住宅网关的对等，如上文第18.1节所述，PCP服务器受到限制。
In the Advanced Threat Model, the PCP protocol ensures that attackers (on- or off-path) cannot create unauthorized mappings or make unauthorized changes to existing mappings. The protocol must also limit the opportunity for on- or off-path attackers to perpetrate denial-of-service attacks.
在高级威胁模型中，PCP协议确保攻击者（路径上或路径外）不能创建未经授权的映射或对现有映射进行未经授权的更改。该协议还必须限制路径上或路径外攻击者实施拒绝服务攻击的机会。
The Advanced Threat Model security model will be needed in the following cases:
在以下情况下需要高级威胁模型安全模型：
o Security infrastructure equipment, such as corporate firewalls, that does not create implicit mappings.
o 不创建隐式映射的安全基础设施设备，如公司防火墙。
o Equipment (such as CGNs or service provider firewalls) that serves multiple administrative domains and does not have a mechanism to securely partition traffic from those domains.
o 为多个管理域提供服务的设备（如CGN或服务提供商防火墙），并且没有安全地将流量与这些域划分的机制。
o Any implementation that wants to be more permissive in authorizing explicit mappings than it is in authorizing implicit mappings.
o 任何希望在授权显式映射时比在授权隐式映射时更为宽松的实现。
o Implementations that wish to support any deployment scenario that does not meet the constraints described in Section 18.1.
o 希望支持任何不满足第18.1节所述约束的部署场景的实现。
To protect against attacks under this threat model, a PCP security mechanism that provides an authenticated, integrity-protected signaling channel would need to be specified.
为了防止这种威胁模型下的攻击，需要指定一种PCP安全机制，该机制提供经过身份验证、完整性保护的信令通道。
PCP servers that implement a PCP security mechanism MAY accept unauthenticated requests. In their default configuration, PCP servers implementing the PCP security mechanism MUST still enforce the constraints described in Section 18.1 when processing unauthenticated requests.
实现PCP安全机制的PCP服务器可以接受未经验证的请求。在默认配置中，在处理未经验证的请求时，实现PCP安全机制的PCP服务器仍必须执行第18.1节中描述的约束。
This section describes some threats that are not addressed in either of the above threat models and recommends appropriate mitigation strategies.
本节描述了上述威胁模型中未解决的一些威胁，并建议了适当的缓解策略。
Because of the state created in a NAT or firewall, a per-host and/or per-subscriber quota will likely exist for both implicit dynamic mappings and explicit dynamic mappings. A host might make an excessive number of implicit or explicit dynamic mappings, consuming
由于在NAT或防火墙中创建的状态，隐式动态映射和显式动态映射都可能存在每主机和/或每订户配额。主机可能会生成过多的隐式或显式动态映射，从而消耗
an inordinate number of ports, causing a denial of service to other hosts. Thus, Section 17.2 recommends that hosts be limited to a reasonable number of explicit dynamic mappings.
端口数量过多，导致对其他主机的拒绝服务。因此，第17.2节建议将主机限制为合理数量的显式动态映射。
An attacker, on the path between the PCP client and PCP server, can drop PCP requests, drop PCP responses, or spoof a PCP error, all of which will effectively deny service. Through such actions, the PCP client might not be aware the PCP server might have actually processed the PCP request. An attacker sending a NO_RESOURCES error can cause the PCP client to not send messages to that server for a while. There is no mitigation to this on-path attacker.
在PCP客户端和PCP服务器之间的路径上，攻击者可以丢弃PCP请求、丢弃PCP响应或伪造PCP错误，所有这些都将有效地拒绝服务。通过这些操作，PCP客户端可能不知道PCP服务器可能已经实际处理了PCP请求。发送NO_RESOURCES错误的攻击者可导致PCP客户端暂时不向该服务器发送消息。无法缓解此路径上的攻击者。
It is important to prevent a host from fraudulently creating, deleting, or refreshing a mapping (or filtering) for another host, because this can expose the other host to unwanted traffic, prevent it from receiving wanted traffic, or consume the other host's mapping quota. Both implicit and explicit dynamic mappings are created based on the source IP address in the packet, and hence depend on ingress filtering to guard against spoof source IP addresses.
防止主机欺诈性地创建、删除或刷新另一台主机的映射（或筛选）非常重要，因为这会使另一台主机暴露在不需要的流量中，防止其接收想要的流量，或消耗另一台主机的映射配额。隐式和显式动态映射都是基于数据包中的源IP地址创建的，因此依赖入口过滤来防止伪造源IP地址。
In the time between when a PCP server loses state and the PCP client notices the lower-than-expected Epoch Time value, it is possible that the PCP client's mapping will be acquired by another host (via an explicit dynamic mapping or implicit dynamic mapping). This means incoming traffic will be sent to a different host ("theft"). Rapid recovery reduces this interval, but does not completely eliminate this threat. The PCP client can reduce this interval by using a relatively short lifetime; however, this increases the amount of PCP chatter. This threat is reduced by using persistent storage of explicit dynamic mappings in the PCP server (so it does not lose explicit dynamic mapping state), or by ensuring that the previous external IP address, protocol, and port cannot be used by another host (e.g., by using a different IP address pool).
在PCP服务器失去状态和PCP客户端注意到低于预期的历元时间值之间的时间段内，PCP客户端的映射可能会被另一台主机获取（通过显式动态映射或隐式动态映射）。这意味着传入的流量将被发送到不同的主机（“盗窃”）。快速恢复缩短了这段时间间隔，但并不能完全消除这一威胁。PCP客户端可以通过使用相对较短的生存期来缩短此间隔；然而，这增加了PCP颤振的数量。通过在PCP服务器中使用显式动态映射的持久存储（这样它就不会丢失显式动态映射状态），或者通过确保以前的外部IP地址、协议和端口不能被其他主机使用（例如，通过使用不同的IP地址池），可以减少这种威胁。
This document does not specify server discovery, beyond contacting the default gateway.
除联系默认网关外，本文档未指定服务器发现。
IANA has performed the following actions.
IANA已执行以下操作。
PCP uses ports 5350 and 5351, previously assigned by IANA to NAT-PMP [RFC6886]. IANA has reassigned those ports to PCP.
PCP使用先前由IANA分配给NAT-PMP[RFC6886]的端口5350和5351。IANA已将这些端口重新分配给PCP。
IANA has created a new protocol registry for PCP Opcodes, numbered 0-127, initially populated with the values:
IANA已经为PCP操作码创建了一个新的协议注册表，编号为0-127，最初使用以下值填充：
Value Opcode
----- -------------------------
0 ANNOUNCE
1 MAP
2 PEER
3-31 Standards Action [RFC5226]
32-63 Specification Required [RFC5226]
96-126 Reserved for Private Use [RFC5226]
127 Reserved, Standards Action [RFC5226]
Value Opcode
----- -------------------------
0 ANNOUNCE
1 MAP
2 PEER
3-31 Standards Action [RFC5226]
32-63 Specification Required [RFC5226]
96-126 Reserved for Private Use [RFC5226]
127 Reserved, Standards Action [RFC5226]
The value 127 is Reserved and may be assigned via Standards Action [RFC5226]. The values in the range 3-31 can be assigned via Standards Action [RFC5226], 32-63 via Specification Required [RFC5226], and the range 96-126 is for Private Use [RFC5226].
值127保留，可通过标准操作[RFC5226]分配。范围3-31中的值可通过标准行动[RFC5226]分配，范围32-63可通过所需规范[RFC5226]分配，范围96-126供私人使用[RFC5226]。
IANA has created a new registry for PCP result codes, numbered 0-255, initially populated with the result codes from Section 7.4. The value 255 is Reserved and may be assigned via Standards Action [RFC5226].
IANA为PCP结果代码创建了一个新的注册表，编号为0-255，最初使用第7.4节中的结果代码填充。值255为保留值，可通过标准操作[RFC5226]分配。
The values in the range 14-127 can be assigned via Standards Action [RFC5226], 128-191 via Specification Required [RFC5226], and the range 191-254 is for Private Use [RFC5226].
14-127范围内的值可通过标准行动[RFC5226]分配，128-191范围内的值可通过所需规范[RFC5226]分配，191-254范围内的值供私人使用[RFC5226]。
IANA has created a new registry for PCP options, numbered 0-255, each with an associated mnemonic. The values 0-127 are mandatory to process, and 128-255 are optional to process. The initial registry contains the options described in Section 13. The option values 0, 127, and 255 are Reserved and may be assigned via Standards Action [RFC5226].
IANA为PCP选项创建了一个新的注册表，编号为0-255，每个选项都有一个关联的助记符。值0-127对于处理是必需的，128-255对于处理是可选的。初始注册表包含第13节中描述的选项。选项值0、127和255保留，可通过标准操作[RFC5226]分配。
Additional PCP option codes in the ranges 4-63 and 128-191 can be created via Standards Action [RFC5226], the ranges 64-95 and 192-223 are for Specification Required [RFC5226], and the ranges 96-126 and 224-254 are for Private Use [RFC5226].
范围4-63和128-191中的其他PCP选项代码可通过标准行动[RFC5226]创建，范围64-95和192-223用于规范要求[RFC5226]，范围96-126和224-254用于私人用途[RFC5226]。
Documents describing an option should describe the processing for both the PCP client and server, and the information below:
描述选项的文档应描述PCP客户端和服务器的处理过程，以及以下信息：
Option Name: <mnemonic>
Number: <value>
Purpose: <textual description>
Valid for Opcodes: <list of Opcodes>
Length: <rules for length>
May appear in: <requests/responses/both>
Maximum occurrences: <count>
Option Name: <mnemonic>
Number: <value>
Purpose: <textual description>
Valid for Opcodes: <list of Opcodes>
Length: <rules for length>
May appear in: <requests/responses/both>
Maximum occurrences: <count>
Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani, Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins, Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda Costa, Amit Jain, and Wim Henderickx for their comments and review.
感谢邓晓红、阿兰·杜兰德、克里斯蒂安·雅克内特、贾斯尼·琴、西蒙·佩雷尔特、詹姆斯·余、蒂娜·邹（丁邹）、菲利佩·米兰达·科斯塔、詹姆斯·伍迪亚特、戴夫·泰勒、马萨塔卡·奥塔、维杰·古巴尼、洛亚·安德森、理查德·巴恩斯、罗斯·霍斯利、阿德里安·法雷尔、皮特·雷斯尼克、帕西·萨拉赫蒂、罗伯特·斯帕克斯、韦斯利·艾迪和哈金斯，Peter Saint Andre、Stephen Farrell、Ralph Droms、Felipe Miranda Costa、Amit Jain和Wim Henderickx的评论和评论。
Thanks to Simon Perreault for highlighting the interaction of dynamic connections with PCP-created mappings and for many other review comments.
感谢Simon Perreault强调了动态连接与PCP创建的映射的交互作用，以及许多其他评论。
Thanks to Francis Dupont for his several thorough reviews of the specification, which improved the protocol significantly.
感谢Francis Dupont对规范进行了几次彻底的审查，这大大改进了协议。
Thanks to T. S. Ranganathan for the state diagram.
感谢T.S.Ranganathan提供的状态图。
Thanks to Peter Lothberg for clock skew information, which guided the choice of tolerance levels for deciding when an Epoch time should be considered to be anomalous.
多亏了Peter Lothberg提供的时钟偏差信息，该信息指导了公差水平的选择，以决定何时应将一个历元时间视为异常。
Thanks to Margaret Wasserman and Sam Hartman for writing the Security Considerations section.
感谢Margaret Wasserman和Sam Hartman撰写安全考虑部分。
Thanks to authors of DHCPv6 for retransmission text.
感谢DHCPv6的作者提供的重新传输文本。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]Larsen，M.和F.Gont，“传输协议端口随机化建议”，BCP 156，RFC 6056，2011年1月。
[proto_numbers] IANA, "Protocol Numbers", 2011, <http://www.iana.org/assignments/protocol-numbers>.
[协议编号]IANA，“协议编号”，2011年<http://www.iana.org/assignments/protocol-numbers>.
[IGDv1] UPnP Gateway Committee, "WANIPConnection:1", November 2001, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>.
[IGDv1]UPnP网关委员会，“WANIConnect:1”，2001年11月<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>。
[L2NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in Progress, March 2009.
[L2NAT]Miles，D.和M.Townsley，“第二层感知NAT”，正在进行的工作，2009年3月。
[PCP-FAIL] Boucadair, M., Dupont, F., and R. Penno, "Port Control Protocol (PCP) Failure Scenarios", Work in Progress, August 2012.
[PCP-FAIL]Boucadair，M.，Dupont，F.，和R.Penno，“端口控制协议（PCP）故障场景”，正在进行的工作，2012年8月。
[PNP-IGD-PCP] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)- Port Control Protocol (PCP) Interworking Function", Work in Progress, December 2012.
[PNP-IGD-PCP]Boucadair，M.，Penno，R.，和D.Wing，“通用即插即用（UPnP）互联网网关设备（IGD）-端口控制协议（PCP）互通功能”，正在进行的工作，2012年12月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[RFC3581]Rosenberg，J.和H.Schulzrinne，“对称响应路由会话启动协议（SIP）的扩展”，RFC 3581，2003年8月。
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[RFC3587]Hinden，R.，Deering，S.，和E.Nordmark，“IPv6全球单播地址格式”，RFC 3587，2003年8月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]Wing，D，“对称RTP/RTP控制协议（RTCP）”，BCP 131，RFC 49612007年7月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092]Woodyatt，J.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，2011年1月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", RFC 6619, June 2012.
[RFC6619]Arkko，J.，Eggert，L.，和M.Townsley，“具有每个接口绑定的地址转换器的可扩展操作”，RFC 661192012年6月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, April 2013.
[RFC6886]Cheshire，S.和M.Krochmal，“NAT端口映射协议（NAT-PMP）”，RFC 68862013年4月。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC6888]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，BCP 127，RFC 6888，2013年4月。
[SCTPNAT] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation", Work in Progress, February 2013.
[SCTPNAT]Stewart，R.，Tuexen，M.，和I.Ruengeler，“流控制传输协议（SCTP）网络地址转换”，正在进行的工作，2013年2月。
The Port Control Protocol (PCP) is a successor to the NAT Port Mapping Protocol, NAT-PMP [RFC6886], and shares similar semantics, concepts, and packet formats. Because of this, NAT-PMP and PCP both use the same port and use NAT-PMP and PCP's version negotiation capabilities to determine which version to use. This section describes how an orderly transition from NAT-PMP to PCP may be achieved.
端口控制协议（PCP）是NAT端口映射协议NAT-PMP[RFC6886]的后续协议，具有相似的语义、概念和数据包格式。因此，NAT-PMP和PCP都使用相同的端口，并使用NAT-PMP和PCP的版本协商功能来确定使用哪个版本。本节描述如何实现从NAT-PMP到PCP的有序过渡。
A client supporting both NAT-PMP and PCP SHOULD send its request using the PCP packet format. This will be received by a NAT-PMP server or a PCP server. If received by a NAT-PMP server, the response will be UNSUPP_VERSION, as indicated by the NAT-PMP specification [RFC6886], which will cause the client to downgrade to NAT-PMP and resend its request in NAT-PMP format. If received by a PCP server, the response will be as described by this document and processing continues as expected.
同时支持NAT-PMP和PCP的客户端应使用PCP数据包格式发送其请求。这将由NAT-PMP服务器或PCP服务器接收。如果NAT-PMP服务器接收到响应，响应将为UNSUPP_版本，如NAT-PMP规范[RFC6886]所示，这将导致客户端降级为NAT-PMP，并以NAT-PMP格式重新发送其请求。如果由PCP服务器接收，响应将如本文档所述，处理将按预期继续。
A PCP server supporting both NAT-PMP and PCP can handle requests in either format. The first octet of the packet indicates if it is NAT-PMP (first octet zero) or PCP (first octet non-zero).
同时支持NAT-PMP和PCP的PCP服务器可以处理两种格式的请求。数据包的第一个八位组指示它是NAT-PMP（第一个八位组零）还是PCP（第一个八位组非零）。
A PCP-only gateway receiving a NAT-PMP request (identified by the first octet being zero) will interpret the request as a version mismatch. Normal PCP processing will emit a PCP response that is compatible with NAT-PMP, without any special handling by the PCP server.
接收NAT-PMP请求（第一个八位组为零）的仅PCP网关将把该请求解释为版本不匹配。正常PCP处理将发出与NAT-PMP兼容的PCP响应，而无需PCP服务器进行任何特殊处理。
Authors' Addresses
作者地址
Dan Wing (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
Dan Wing（编辑）思科系统公司，美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, California 95014 USA
Stuart Cheshire Apple Inc.美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号雷纳尔多·佩诺思科系统公司，邮编：95134
EMail: repenno@cisco.com
EMail: repenno@cisco.com
Paul Selkirk Internet Systems Consortium 950 Charter Street Redwood City, California 94063 USA
Paul Selkirk互联网系统联合体950美国加利福尼亚州红木市Charter Street Redwood City 94063
EMail: pselkirk@isc.org
EMail: pselkirk@isc.org