[要約] RFC 7723は、Port Control Protocol（PCP）のAnycastアドレスに関する仕様を提供しています。このRFCの目的は、PCPのAnycastアドレスの使用方法と動作を定義し、ネットワークの効率性と信頼性を向上させることです。
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クライアントは、いくつかの外部チャネルを介してミドルボックスのIPアドレスを学習しなくても、最も近いPCP対応のオンパスNAT、ファイアウォール、またはその他のミドルボックスにシグナリングメッセージを送信できます。このドキュメントでは、1つの既知のIPv4アドレスと1つの既知のIPv6アドレスを確立して、PCPエニーキャストアドレスとして使用します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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サーバーに対して2つの既知のエニーキャストアドレスを確立します。1つはIPv4アドレス、もう1つは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 /ファイアウォール機能がクライアントのデフォルトゲートウェイではなく、Carrier-Grade NAT（CGN）の上流にある場合、デフォルトゲートウェイのIPアドレスにPCP要求を送信しても、期待した効果が得られません。構成ファイルまたはDHCPオプションを使用してPCPサーバーのIPアドレスを学習する場合、このファイルまたはDHCPサーバー構成は、ネットワークトポロジーとルーターおよびCGN構成を反映している必要があります。これは、達成および維持が面倒な場合があります。複数のアップストリームCGNがあり、OSPFなどの動的ルーティングプロトコルを使用してトラフィックがルーティングされる場合、どのCGNと対話するかに関するタイムリーな情報を提供できないため、このアプローチはまったく実行できない可能性があります。対照的に、PCPエニーキャストアドレスを使用する場合、PCP要求は、他のパケットと同じように（つまり、DNS、DHCP、他のルーターなどからの特別なサポートなしで）ネットワークを通過し、PCP対応デバイスに到達します。それを受け取って処理し、応答を送り返します。 DHCPオプションの代わりにエニーキャストアドレスを使用するもう1つの利点は、エニーキャストアドレスをアプリケーションにハードコードできることです。 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クライアントは、デフォルトのルーターリスト（IPv4およびIPv6の場合）の後に、セクション4.1および4.2で定義されているPCPエニーキャストアドレスをPCPサーバーのリストに追加できます（[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]を参照してください。 IPエニーキャストのアーキテクチャに関する考慮事項は、[RFC7094]で説明されています。
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エニーキャスティングを使用すると、追加のメカニズムを使用するか、代わりにDHCP [RFC7291]や構成ファイルなどの他のPCPサーバー検出方法を使用することで克服できる特定の制限がある場合があります。
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.
重要な例の1つは、ネットワークが複数の並列ファイアウォールを介して1つ以上の上流ネットワークに接続されているネットワークトポロジで、それぞれが独自のPCPサーバーによって個別に制御されています。これらのすべてのPCPサーバーがエニーキャスト用に構成されている場合でも、ルーティングテーブルの状態に応じて、特定のクライアントから送信されたメッセージを受信するのは1つだけです。
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応答またはANNOUNCEメッセージ中にエポックフィールドを調べることでそれを検出できます。クライアントはファイアウォールルールを再確立し、パケットフローを再開できます。
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エニーキャスティングを使用してこれら2つのファイアウォールの1つだけでポリシールールを確立すると、双方向接続を許可するという望ましい結果が得られません。この問題を解決する1つのソリューションアプローチは、ネットワークの境界にあるすべてのファイアウォール間で状態を同期する実装固有のメカニズムです。つまり、これらのPCPサーバーのいずれかに送信されるPEERメッセージは、すべてのファイアウォールでルールを確立します。別のアプローチは、PCPクライアントが並列ファイアウォールを制御するすべてのPCPサーバーのリストを取得し、それぞれを個別に構成できるようにする、異なる検出メカニズム（DHCPまたは構成ファイルなど）を使用することです。
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対応のNATまたはファイアウォールを使用するシナリオをサポートするために、PCPプロキシ機能[RFC7648]と組み合わせて使用できます。
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 |
+----------------------+-------------------------------------------+
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 |
+----------------------+-------------------------------------------+
In addition to the security considerations in [RFC6887], [RFC4786], and [RFC7094], two further security issues are considered here.
ここでは、[RFC6887]、[RFC4786]、および[RFC7094]のセキュリティに関する考慮事項に加えて、さらに2つのセキュリティ問題が検討されています。
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.
PCPエニーキャストアドレスを認識するボーダーゲートウェイ、NAT、またはファイアウォールのないネットワークでは、発信PCP要求が外部インターネットに漏れ、内部デバイスに関する情報が漏洩する可能性があります。
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.
プライバシーに影響する可能性のあるパラメータ（IPアドレスやポート番号など）を含むPCP要求をPCPエニーキャストアドレスに送信する前に、PCPクライアントはANNOUNCE要求（パラメータなし、[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エニーキャストを使用した完全自動構成の目的を妨げる可能性があります。したがって、このアプローチは、PCP制御ミドルボックスのオペレーターとすべてのユーザー（たとえば、家族のみが使用するレジデンシャルゲートウェイ）の間の信頼が高いシナリオ、またはミドルボックスの信頼がかなり限定されているシナリオにはあまり適していない可能性があります。正しく動作します（例：空港ラウンジのWi-Fi）。対照的に、このスキームは、多数のユーザーと、大規模な企業ネットワークや大学のキャンパスネットワークなど、複数の並列NATまたはファイアウォールを使用してインターネットに接続する信頼できるネットワークオペレーターがいるシナリオで非常に役立ちます。したがって、特定のネットワークシナリオで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、「Port Control Protocol（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]綿、M。、ベゴダ、L。、ボニカ、R。、エド、およびB.ハーバーマン、「特別な目的の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、「Port Control Protocol（PCP）Server Selection」、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およびファイアウォールキープアライブの最適化」、作業中、draft-ietf-pcp- optimize-keepalives-06、2015年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] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、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]プロンカ、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、「Operation of Anycast Services」、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]マクファーソンD.、オランD.、ターラーD.、およびE.オスターワイル、「IP Anycastのアーキテクチャに関する考慮事項」、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、「Port Control Protocol（PCP）Proxy Function」、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、「Port Control Protocol（PCP）Authentication Mechanism」、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
セバスチャンキーゼルシュトゥットガルト大学情報センターネットワークおよび通信システム学科Allmandring 30シュトゥットガルト70550ドイツ
Email: ietf-pcp@skiesel.de
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 United States
Reinaldo Penno Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134アメリカ合衆国
Email: repenno@cisco.com