Internet Engineering Task Force (IETF) S. Kiesel
Request for Comments: 7723 University of Stuttgart
Category: Standards Track R. Penno
ISSN: 2070-1721 Cisco Systems, Inc.
January 2016
Internet Engineering Task Force (IETF) S. Kiesel
Request for Comments: 7723 University of Stuttgart
Category: Standards Track R. Penno
ISSN: 2070-1721 Cisco Systems, Inc.
January 2016
Port Control Protocol (PCP) Anycast Addresses
端口控制协议（PCP）选播地址
Abstract
摘要
The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.
端口控制协议（PCP）选播地址使PCP客户端能够在路径NAT、防火墙或其他中间盒上向其最近的PCP感知发送信令消息，而无需通过某些外部通道了解该中间盒的IP地址。本文档建立了一个众所周知的IPv4地址和一个众所周知的IPv6地址，用作PCP选播地址。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7723.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7723.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. PCP Server Discovery Based on Well-Known IP Address . . . . . 3
2.1. PCP Discovery Client Behavior . . . . . . . . . . . . . . 3
2.2. PCP Discovery Server Behavior . . . . . . . . . . . . . . 3
3. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Registration of an IPv4 Special-Purpose Address . . . . . 5
4.2. Registration of an IPv6 Special-Purpose Address . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Information Leakage through Anycast . . . . . . . . . . . 6
5.2. Hijacking of PCP Messages Sent to Anycast Addresses . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. PCP Server Discovery Based on Well-Known IP Address . . . . . 3
2.1. PCP Discovery Client Behavior . . . . . . . . . . . . . . 3
2.2. PCP Discovery Server Behavior . . . . . . . . . . . . . . 3
3. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Registration of an IPv4 Special-Purpose Address . . . . . 5
4.2. Registration of an IPv6 Special-Purpose Address . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Information Leakage through Anycast . . . . . . . . . . . 6
5.2. Hijacking of PCP Messages Sent to Anycast Addresses . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
The Port Control Protocol (PCP) [RFC6887] provides a mechanism to control how incoming packets are forwarded by upstream devices such as Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), Network Address Translation from IPv4 to IPv4 (NAT44), and IPv6 and IPv4 firewall devices. Furthermore, it provides a mechanism to reduce application keepalive traffic [PCP-OPTIMIZE]. The PCP base protocol document [RFC6887] specifies the message formats used, but the address to which a client sends its request is either assumed to be the default router (which is appropriate in a typical single-link residential network) or has to be configured otherwise via some external mechanism, such as a configuration file or a DHCP option [RFC7291].
端口控制协议（PCP）[RFC6887]提供了一种机制来控制上游设备转发传入数据包的方式，如从IPv6客户端到IPv4服务器的网络地址和协议转换（NAT64）、从IPv4到IPv4的网络地址转换（NAT44）以及IPv6和IPv4防火墙设备。此外，它还提供了一种减少应用程序保持流量的机制[PCP-OPTIMIZE]。PCP基本协议文档[RFC6887]指定了所使用的消息格式，但客户机发送请求的地址被假定为默认路由器（适用于典型的单链路住宅网络），或者必须通过一些外部机制（如配置文件或DHCP选项）进行配置[RFC7291]。
This document follows a different approach: it establishes two well-known anycast addresses for the PCP server, one IPv4 address and one IPv6 address. PCP clients usually send PCP requests to these well-known addresses if no other PCP server addresses are known or after communication attempts to such other addresses have failed. The anycast addresses are allocated from pools of special-purpose IP addresses (see Section 4), in accordance with Section 3.4 of [RFC4085]. Yet, a means to disable or override these well-known addresses (e.g., a configuration file option) should be available in implementations.
本文档采用了不同的方法：它为PCP服务器建立了两个众所周知的选播地址，一个IPv4地址和一个IPv6地址。如果不知道其他PCP服务器地址，或者在与这些地址的通信尝试失败后，PCP客户端通常向这些已知地址发送PCP请求。根据[RFC4085]第3.4节，从专用IP地址池中分配选播地址（见第4节）。然而，应该在实现中提供禁用或覆盖这些已知地址的方法（例如，配置文件选项）。
Using an anycast address is particularly useful in larger network topologies. For example, if the PCP-enabled NAT/firewall function is not located on the client's default gateway but further upstream in a Carrier-Grade NAT (CGN), sending PCP requests to the default gateway's IP address will not have the desired effect. When using a configuration file or the DHCP option to learn the PCP server's IP address, this file or the DHCP server configuration must reflect the network topology and the router and CGN configuration. This may be cumbersome to achieve and maintain. If there is more than one upstream CGN and traffic is routed using a dynamic routing protocol such as OSPF, this approach may not be feasible at all, as it cannot provide timely information regarding which CGN to interact with. In contrast, when using the PCP anycast address, the PCP request will travel through the network like any other packet (i.e., without any special support from DNS, DHCP, other routers, or anything else) until it reaches the PCP-capable device that receives it, handles it, and sends back a reply. A further advantage of using an anycast address instead of a DHCP option is that the anycast address can be hard-coded into the application. There is no need for an application programming interface that passes the PCP server's address from the operating system's DHCP client to the application. For further discussion of deployment considerations, see Section 3.
在较大的网络拓扑中，使用选播地址特别有用。例如，如果启用PCP的NAT/防火墙功能不位于客户端的默认网关上，而是位于运营商级NAT（CGN）的更上游，则向默认网关的IP地址发送PCP请求将不会产生预期效果。当使用配置文件或DHCP选项了解PCP服务器的IP地址时，此文件或DHCP服务器配置必须反映网络拓扑以及路由器和CGN配置。这可能很难实现和维护。如果存在多个上游CGN，并且流量使用动态路由协议（如OSPF）进行路由，则此方法可能根本不可行，因为它无法提供与哪个CGN交互的及时信息。相反，当使用PCP选播地址时，PCP请求将像任何其他数据包一样在网络中传输（即，没有来自DNS、DHCP、其他路由器或其他任何东西的任何特殊支持），直到它到达能够接收它、处理它并发送回应答的PCP设备。使用选播地址而不是DHCP选项的另一个优点是，可以将选播地址硬编码到应用程序中。不需要应用程序编程接口将PCP服务器的地址从操作系统的DHCP客户端传递到应用程序。有关部署注意事项的进一步讨论，请参见第3节。
PCP clients can add the PCP anycast addresses, which are defined in Sections 4.1 and 4.2, after the default router list (for IPv4 and IPv6) to the list of PCP server(s) (see step 2 in Section 8.1 of [RFC6887]). This list is processed as specified in [RFC7488].
PCP客户端可以将第4.1节和第4.2节中定义的PCP选播地址添加到PCP服务器列表（对于IPv4和IPv6）的默认路由器列表之后（请参见[RFC6887]第8.1节中的步骤2）。此列表按照[RFC7488]中的规定进行处理。
Note: If, in some specific scenario, it was desirable to use only the anycast address (and not the default router), this could be achieved by putting the anycast address into the configuration file or DHCP option.
注意：如果在某些特定场景中，希望只使用选播地址（而不是默认路由器），则可以通过将选播地址放入配置文件或DHCP选项中来实现。
PCP servers can be configured to listen on the anycast addresses for incoming PCP requests. When a PCP server receives a PCP request destined for an anycast address it supports, it sends the corresponding PCP replies using that same anycast address as the source address (see the "How UDP and TCP Use Anycasting" section of [RFC1546] for further discussion).
PCP服务器可以配置为侦听传入PCP请求的选播地址。当PCP服务器接收到以其支持的选播地址为目的地的PCP请求时，它会使用与源地址相同的选播地址发送相应的PCP回复（有关详细讨论，请参阅[RFC1546]的“UDP和TCP如何使用选播”一节）。
For general recommendations regarding operation of anycast services, see [RFC4786]. Architectural considerations of IP anycast are discussed in [RFC7094].
有关任意广播服务操作的一般建议，请参阅[RFC4786]。[RFC7094]中讨论了IP选播的架构考虑。
In some deployment scenarios, using PCP anycasting may have certain limitations that can be overcome by using additional mechanisms or by using other PCP server discovery methods instead, such as DHCP [RFC7291] or a configuration file.
在某些部署场景中，使用PCP选播可能有某些限制，可以通过使用其他机制或使用其他PCP服务器发现方法（如DHCP[RFC7291]或配置文件）来克服这些限制。
One important example is a network topology in which a network is connected to one or more upstream network(s) via several parallel firewalls, each individually controlled by its own PCP server. Even if all of these PCP servers are configured for anycasting, only one will receive the messages sent by a given client, depending on the state of the routing tables.
一个重要的例子是网络拓扑，其中网络通过几个并行防火墙连接到一个或多个上游网络，每个防火墙分别由其自己的PCP服务器控制。即使所有这些PCP服务器都配置为任意广播，根据路由表的状态，只有一个服务器将接收给定客户端发送的消息。
As long as routing is always symmetric, i.e., all upstream and downstream packets from/to that client are routed through this very same firewall, communication will be possible as expected. If there is a routing change, a PCP client using PCP anycasting might start interacting with a different PCP server. From the PCP client's point of view, this would be the same as a PCP server reboot and the client could detect it by examining the Epoch field during the next PCP response or ANNOUNCE message. The client would re-establish the firewall rules and packet flows could resume.
只要路由始终是对称的，即从/到该客户机的所有上游和下游数据包都通过同一防火墙路由，通信将如预期的那样成为可能。如果存在路由更改，则使用PCP选播的PCP客户端可能会开始与其他PCP服务器交互。从PCP客户端的角度来看，这与PCP服务器重新启动相同，客户端可以通过在下一个PCP响应或公告消息期间检查Epoch字段来检测到。客户端将重新建立防火墙规则，数据包流可以恢复。
If, however, routing is asymmetric, upstream packets from a client traverse a different firewall than the downstream packets to that client. Establishing policy rules in only one of these two firewalls by means of PCP anycasting will not have the desired result of allowing bidirectional connectivity. One solution approach to overcome this problem is an implementation-specific mechanism to synchronize state between all firewalls at the border of a network, i.e., a PEER message sent to any of these PCP servers would establish rules in all firewalls. Another approach would be to use a different discovery mechanism (e.g., DHCP or a configuration file) that allows a PCP client to acquire a list of all PCP servers controlling the parallel firewalls and configure each of them individually.
但是，如果路由是非对称的，则来自客户端的上游数据包将穿越与该客户端的下游数据包不同的防火墙。通过PCP选播仅在这两个防火墙中的一个中建立策略规则将不会产生允许双向连接的预期结果。克服此问题的一种解决方案方法是一种特定于实现的机制，用于同步网络边界处所有防火墙之间的状态，即，发送到任何这些PCP服务器的对等消息将在所有防火墙中建立规则。另一种方法是使用不同的发现机制（例如，DHCP或配置文件），该机制允许PCP客户端获取控制并行防火墙的所有PCP服务器的列表，并分别配置每个PCP服务器。
PCP anycast as such allows a PCP client to communicate only with its closest upstream PCP server. However, it may be used in conjunction with the PCP proxy function [RFC7648], in order to support scenarios with cascaded PCP-enabled NATs or firewalls.
PCP选播允许PCP客户端仅与其最近的上游PCP服务器通信。但是，它可以与PCP代理功能[RFC7648]结合使用，以支持级联PCP启用NAT或防火墙的场景。
IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix and registered it in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890].
IANA已从192.0.0.0/24前缀分配了一个IPv4地址，并将其注册到“IANA IPv4专用地址注册表”[RFC6890]。
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 192.0.0.9/32 |
| Name | Port Control Protocol Anycast |
| RFC | RFC 7723 (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 192.0.0.9/32 |
| Name | Port Control Protocol Anycast |
| RFC | RFC 7723 (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
IANA has assigned a single IPv6 address from the 2001:0000::/23 prefix and registered it in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890].
IANA已从2001:0000:：/23前缀分配了一个IPv6地址，并将其注册到“IANA IPv6专用地址注册表”[RFC6890]。
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 2001:1::1/128 |
| Name | Port Control Protocol Anycast |
| RFC | RFC 7723 (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 2001:1::1/128 |
| Name | Port Control Protocol Anycast |
| RFC | RFC 7723 (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
In addition to the security considerations in [RFC6887], [RFC4786], and [RFC7094], two further security issues are considered here.
除了[RFC6887]、[RFC4786]和[RFC7094]中的安全注意事项外，这里还考虑了另外两个安全问题。
In a network without any border gateway, NAT, or firewall that is aware of the PCP anycast address, outgoing PCP requests could leak out onto the external Internet, possibly revealing information about internal devices.
在没有任何边界网关、NAT或防火墙知道PCP选播地址的网络中，传出的PCP请求可能泄漏到外部Internet上，可能泄露有关内部设备的信息。
Using an IANA-assigned, well-known PCP anycast address enables border gateways to block such outgoing packets. In the default-free zone, routers should be configured to drop such packets. Such configuration can occur naturally via BGP messages advertising that no route exists to said address.
使用IANA分配的众所周知的PCP选播地址，使边界网关能够阻止此类传出数据包。在默认自由区中，路由器应配置为丢弃此类数据包。这样的配置可以通过BGP消息自然发生，该消息声明不存在到所述地址的路由。
Sensitive clients that do not wish to leak information about their presence can set an IP TTL on their PCP requests that limits how far they can travel towards the public Internet. However, methods for choosing an appropriate TTL value, e.g., based on the assumed radius of the trusted network domain, is beyond the scope of this document.
不希望泄露其存在信息的敏感客户端可以在其PCP请求上设置IP TTL，以限制其向公共互联网的距离。然而，选择适当TTL值的方法（例如，基于可信网络域的假定半径）超出了本文档的范围。
Before sending PCP requests with possibly privacy-sensitive parameters (e.g., IP addresses and port numbers) to the PCP anycast addresses, PCP clients can send an ANNOUNCE request (without parameters; see Section 14.1 of [RFC6887]) in order to probe whether a PCP server consumes and processes PCP requests sent to that anycast address.
在向PCP选播地址发送可能带有隐私敏感参数（例如IP地址和端口号）的PCP请求之前，PCP客户端可以发送公告请求（无参数；请参见[RFC6887]第14.1节），以探测PCP服务器是否使用和处理发送到该选播地址的PCP请求。
The anycast addresses are treated by normal host operating systems as normal unicast addresses, i.e., packets destined for an anycast address are sent to the default router for processing and forwarding. Hijacking such packets in the first network segment would effectively require the attacker to impersonate the default router, e.g., by means of ARP spoofing in an Ethernet network. Once an anycast message is forwarded closer to the core network, routing will likely become subject to dynamic routing protocols such as OSPF or BGP. Anycast messages could be hijacked by announcing counterfeited messages in these routing protocols. When analyzing the risk and possible consequences of such attacks in a given network scenario, the probable impacts on PCP signaling need to be put into proportion with probable impacts on other protocols such as the actual application protocols.
选播地址被正常主机操作系统视为正常单播地址，即，发送给选播地址的包被发送到默认路由器进行处理和转发。在第一个网段劫持此类数据包将有效地要求攻击者模拟默认路由器，例如通过以太网中的ARP欺骗。一旦选播消息被转发到更靠近核心网络的地方，路由很可能会受制于动态路由协议，如OSPF或BGP。通过在这些路由协议中公布伪造消息，可以劫持选播消息。在分析给定网络场景中此类攻击的风险和可能后果时，需要将对PCP信令的可能影响与对其他协议（如实际应用协议）的可能影响成比例。
In addition to following best current practices in first-hop security and routing-protocol security, PCP authentication [RFC7652] may be useful in some scenarios. However, the effort needed for a proper setup of this authentication mechanism (e.g., installing the right shared secrets or cryptographic keys on all involved systems) may thwart the goal of fully automatic configuration by using PCP anycast. Therefore, this approach may be less suitable for scenarios with high trust between the operator of the PCP-controlled middlebox and all users (e.g., a residential gateway used only by family members) or in scenarios in which there is rather limited trust that the middlebox will behave correctly (e.g., the Wi-Fi in an airport lounge). In contrast, this scheme may be highly useful in scenarios with many users and a trusted network operator, such as a large corporate network or a university campus network, which uses several parallel NATs or firewalls to connect to the Internet. Therefore, a thorough analysis of the benefits and costs of using PCP authentication in a given network scenario is recommended.
除了在第一跳安全性和路由协议安全性方面遵循当前最佳实践之外，PCP身份验证[RFC7652]在某些场景中可能会很有用。然而，正确设置此身份验证机制所需的工作（例如，在所有相关系统上安装正确的共享机密或加密密钥）可能会阻碍使用PCP anycast实现全自动配置的目标。因此，这种方法可能不太适用于PCP控制的中间箱操作员和所有用户之间高度信任的场景（例如，仅由家庭成员使用的住宅网关），或者对中间箱正常运行的信任非常有限的场景（例如，机场休息室中的Wi-Fi）。相比之下，此方案在具有许多用户和可信网络运营商的场景中可能非常有用，例如大型企业网络或大学校园网，其使用多个并行NAT或防火墙连接到Internet。因此，建议全面分析在给定网络场景中使用PCP身份验证的好处和成本。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，DOI 10.17487/RFC6887，2013年4月<http://www.rfc-editor.org/info/rfc6887>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 6890，DOI 10.17487/RFC6890，2013年4月<http://www.rfc-editor.org/info/rfc6890>.
[RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. Reddy, "Port Control Protocol (PCP) Server Selection", RFC 7488, DOI 10.17487/RFC7488, March 2015, <http://www.rfc-editor.org/info/rfc7488>.
[RFC7488]Boucadair，M.，Penno，R.，Wing，D.，Patil，P.，和T.Reddy，“端口控制协议（PCP）服务器选择”，RFC 7488，DOI 10.17487/RFC7488，2015年3月<http://www.rfc-editor.org/info/rfc7488>.
[PCP-OPTIMIZE] Reddy, T., Patil, P., Isomaki, M., and D. Wing, "Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)", Work in Progress, draft-ietf-pcp-optimize-keepalives-06, May 2015.
[PCP-OPTIMIZE]Reddy，T.，Patil，P.，Isomaki，M.，和D.Wing，“使用端口控制协议（PCP）优化NAT和防火墙保持”，正在进行的工作，草案-ietf-PCP-OPTIMIZE-Keepalives-062015年5月。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, November 1993, <http://www.rfc-editor.org/info/rfc1546>.
[RFC1546]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC 1546，DOI 10.17487/RFC1546，1993年11月<http://www.rfc-editor.org/info/rfc1546>.
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet Addresses Considered Harmful", BCP 105, RFC 4085, DOI 10.17487/RFC4085, June 2005, <http://www.rfc-editor.org/info/rfc4085>.
[RFC4085]Plonka，D.，“嵌入被认为有害的全球可路由互联网地址”，BCP 105，RFC 4085，DOI 10.17487/RFC4085，2005年6月<http://www.rfc-editor.org/info/rfc4085>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，DOI 10.17487/RFC4786，2006年12月<http://www.rfc-editor.org/info/rfc4786>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <http://www.rfc-editor.org/info/rfc7094>.
[RFC7094]McPherson，D.，Oran，D.，Thaler，D.，和E.Osterweil，“IP选播的架构考虑”，RFC 7094，DOI 10.17487/RFC7094，2014年1月<http://www.rfc-editor.org/info/rfc7094>.
[RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", RFC 7291, DOI 10.17487/RFC7291, July 2014, <http://www.rfc-editor.org/info/rfc7291>.
[RFC7291]Boucadair，M.，Penno，R.，和D.Wing，“端口控制协议（PCP）的DHCP选项”，RFC 7291，DOI 10.17487/RFC7291，2014年7月<http://www.rfc-editor.org/info/rfc7291>.
[RFC7648] Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. Cheshire, "Port Control Protocol (PCP) Proxy Function", RFC 7648, DOI 10.17487/RFC7648, September 2015, <http://www.rfc-editor.org/info/rfc7648>.
[RFC7648]Perreault，S.，Boucadair，M.，Penno，R.，Wing，D.，和S.Cheshire，“端口控制协议（PCP）代理功能”，RFC 7648，DOI 10.17487/RFC7648，2015年9月<http://www.rfc-editor.org/info/rfc7648>.
[RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port Control Protocol (PCP) Authentication Mechanism", RFC 7652, DOI 10.17487/RFC7652, September 2015, <http://www.rfc-editor.org/info/rfc7652>.
[RFC7652]Cullen，M.，Hartman，S.，Zhang，D.，和T.Reddy，“端口控制协议（PCP）认证机制”，RFC 7652，DOI 10.17487/RFC7652，2015年9月<http://www.rfc-editor.org/info/rfc7652>.
Acknowledgements
致谢
The authors would like to thank the members of the PCP working group for contributions and feedback, in particular, Mohamed Boucadair, Charles Eckel, Simon Perreault, Tirumaleswar Reddy, Markus Stenberg, Dave Thaler, and Dan Wing.
作者要感谢PCP工作组成员的贡献和反馈，特别是Mohamed Boucadair、Charles Eckel、Simon Perreault、Tirumaleswar Reddy、Markus Stenberg、Dave Thaler和Dan Wing。
Authors' Addresses
作者地址
Sebastian Kiesel University of Stuttgart Information Center Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany
塞巴斯蒂安KIESEL斯图加特大学信息中心网络与通信系统系ALMANDRIN 30斯图加特70550德国
Email: ietf-pcp@skiesel.de
Email: ietf-pcp@skiesel.de
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 United States
美国加利福尼亚州圣何塞西塔斯曼大道170号雷纳尔多·佩诺思科系统公司，邮编95134
Email: repenno@cisco.com
Email: repenno@cisco.com