doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7648.txt b/doc/rfc/rfc7648.txt
new file mode 100644
index 0000000..3657ce0
--- /dev/null
+++ b/doc/rfc/rfc7648.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      S. Perreault
+Request for Comments: 7648                           Jive Communications
+Category: Standards Track                                   M. Boucadair
+ISSN: 2070-1721                                           France Telecom
+                                                                R. Penno
+                                                                 D. Wing
+                                                                   Cisco
+                                                             S. Cheshire
+                                                                   Apple
+                                                          September 2015
+
+
+               Port Control Protocol (PCP) Proxy Function
+
+Abstract
+
+   This document specifies a new Port Control Protocol (PCP) functional
+   element: the PCP proxy.  The PCP proxy relays PCP requests received
+   from PCP clients to upstream PCP server(s).  A typical deployment
+   usage of this function is to help establish successful PCP
+   communications for PCP clients that cannot be configured with the
+   address of a PCP server located more than one hop away.
+
+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.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7648.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 1]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Use Case: The NAT Cascade . . . . . . . . . . . . . . . .   4
+     1.2.  Use Case: The PCP Relay . . . . . . . . . . . . . . . . .   5
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Operation of the PCP Proxy  . . . . . . . . . . . . . . . . .   6
+     3.1.  Optimized Hairpin Routing . . . . . . . . . . . . . . . .   8
+     3.2.  Termination of Recursion  . . . . . . . . . . . . . . . .   9
+     3.3.  Source Address for PCP Requests Sent Upstream . . . . . .  10
+     3.4.  Unknown Opcodes and Options . . . . . . . . . . . . . . .  10
+       3.4.1.  No NAT Is Co-located with the PCP Proxy . . . . . . .  10
+       3.4.2.  PCP Proxy Co-located with a NAT Function  . . . . . .  10
+     3.5.  Mapping Repair  . . . . . . . . . . . . . . . . . . . . .  11
+     3.6.  Multiple PCP Servers  . . . . . . . . . . . . . . . . . .  11
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .  13
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 2]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+1.  Introduction
+
+   This document defines a new Port Control Protocol (PCP) [RFC6887]
+   functional element: the PCP proxy.  As shown in Figure 1, the
+   PCP proxy is logically equivalent to a PCP client back-to-back with a
+   PCP server.  The "glue" between the two is what is specified in this
+   document.  Other than that "glue", the server and the client behave
+   exactly like their regular counterparts.
+
+   The PCP proxy is responsible for relaying PCP messages received from
+   PCP clients to upstream PCP servers and vice versa.
+
+   Whether or not the PCP proxy is co-located with a flow-aware function
+   (e.g., NAT, firewall) is deployment specific.
+
+                              .................
+              +------+       : +------+------+ :    +------+
+              |Client|-------:-|Server|Client|-:----|Server|
+              +------+       : +------+------+ :    +------+
+                             :      Proxy      :
+                              .................
+
+                     Figure 1: Reference Architecture
+
+   This document assumes a hop-by-hop PCP authentication scheme.  That
+   is, referring to Figure 1, the leftmost PCP client authenticates with
+   the PCP proxy, while the PCP proxy authenticates with the upstream
+   server.  Note that in some deployments, PCP authentication may only
+   be enabled between the PCP proxy and an upstream PCP server (e.g., a
+   customer premises host may not authenticate with the PCP proxy, but
+   the PCP proxy may authenticate with the PCP server).  The hop-by-hop
+   authentication scheme is more suitable from a deployment standpoint.
+   Furthermore, it allows implementations to easily support a PCP proxy
+   that alters PCP messages (e.g., strips a PCP option, modifies a
+   PCP field).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 3]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+1.1.  Use Case: The NAT Cascade
+
+   In today's world, with public routable IPv4 addresses becoming less
+   readily available, it is increasingly common for customers to receive
+   a private address from their Internet Service Provider (ISP), and the
+   ISP uses a NAT gateway of its own to translate those packets before
+   sending them out onto the public Internet.  This means that there is
+   likely to be more than one NAT on the path between client machines
+   and the public Internet:
+
+   o  If a residential customer receives a translated address from their
+      ISP and then installs their own residential NAT gateway to share
+      that address between multiple client devices in their home, then
+      there are at least two NAT gateways on the path between client
+      devices and the public Internet.
+
+   o  If a mobile phone customer receives a translated address from
+      their mobile phone carrier and uses "Personal Hotspot" or
+      "Internet Sharing" software on their mobile phone to make Wireless
+      LAN (WLAN) Internet access available to other client devices, then
+      there are at least two NAT gateways on the path between those
+      client devices and the public Internet.
+
+   o  If a hotel guest connects a portable WLAN gateway to their hotel
+      room's Ethernet port to share their room's Internet connection
+      between their phone and their laptop computer, then packets from
+      the client devices may traverse the hotel guest's portable NAT,
+      the hotel network's NAT, and the ISP's NAT before reaching the
+      public Internet.
+
+   While it is possible, in theory, that client devices could somehow
+   discover all the NATs on the path and communicate with each one
+   separately using PCP [RFC6887], in practice it is not clear how
+   client devices would reliably learn this information.  Since the NAT
+   gateways are installed and operated by different individuals and
+   organizations, no single entity has knowledge of all the NATs on the
+   path.  Also, even if a client device could somehow know all the NATs
+   on the path, requiring a client device to communicate separately with
+   all of them imposes unreasonable complexity on PCP clients, many of
+   which are expected to be simple low-cost devices.
+
+   In addition, this goes against the spirit of NAT gateways.  The main
+   purpose of a NAT gateway is to make multiple downstream client
+   devices appear, from the point of view of everything upstream of the
+   NAT gateway, to be a single client device.  In the same spirit, it
+   makes sense for a PCP-capable NAT gateway to make multiple downstream
+
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 4]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+   client devices requesting port mappings appear, from the point of
+   view of everything upstream of the NAT gateway, to be a single client
+   device requesting port mappings.
+
+1.2.  Use Case: The PCP Relay
+
+   Another envisioned use case of the PCP proxy is to help establish
+   successful PCP communications for PCP clients that cannot be
+   configured with the address of a PCP server located more than one hop
+   away.  A PCP proxy can, for instance, be embedded in a CPE (Customer
+   Premises Equipment) while the PCP server is located in a network
+   operated by an ISP.  This is illustrated in Figure 2.
+
+                 |
+       +------+  |
+       |Client|--+
+       +------+  |  +-----+                               +------+
+                 +--|Proxy|--------<ISP network>----------|Server|
+       +------+  |  +-----+                               +------+
+       |Client|--+    CPE
+       +------+  |
+                 |
+                LAN
+
+                       Figure 2: PCP Relay Use Case
+
+   This works because the proxy's server side is listening on the
+   address used as a default gateway by the clients.  The clients use
+   that address as a fallback when discovering the PCP server's address.
+   The proxy picks up the requests and forwards them upstream to the
+   ISP's PCP server, with whose address it has been provisioned through
+   regular PCP client provisioning means.
+
+   This particular use case assumes that provisioning the server's
+   address on the CPE is feasible while doing it on the clients in the
+   LAN is not, which is what makes the PCP proxy valuable.
+
+   An alternative way to contact an upstream PCP server that may be
+   several hops away is to use a well-known anycast address
+   [PCP-ANYCAST], but that technique can be problematic when multiple
+   PCP servers are to be contacted [PCP-DEPLOY].
+
+2.  Terminology
+
+   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].
+
+
+
+Perreault, et al.            Standards Track                    [Page 5]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+   Where this document uses the terms "upstream" and "downstream", the
+   term "upstream" refers to the direction outbound packets travel
+   towards the public Internet, and the term "downstream" refers to the
+   direction inbound packets travel from the public Internet towards
+   client systems.  Typically, when a home user views a web site, their
+   computer sends an outbound TCP SYN packet upstream towards the public
+   Internet, and an inbound downstream TCP SYN ACK reply comes back from
+   the public Internet.
+
+3.  Operation of the PCP Proxy
+
+   Upon receipt of a PCP mapping-creation request from a downstream
+   PCP client, a PCP proxy first examines its local mapping table to see
+   if it already has a valid active mapping matching the internal
+   address and internal port (and in the case of PEER requests, the
+   remote peer) given in the request.
+
+   If the PCP proxy does not already have a valid active mapping for
+   this mapping-creation request, then it allocates an available port on
+   its external interface.  We assume for the sake of this description
+   that the address of its external interface is itself a private
+   address, subject to translation by an upstream NAT.  The PCP proxy
+   then constructs an appropriate corresponding PCP request of its own
+   (as described below) and sends it to its upstream NAT, and the newly
+   created local mapping is considered temporary until a confirming
+   reply is received from the upstream PCP server.
+
+   If the PCP proxy does already have a valid active mapping for this
+   mapping-creation request and the lifetime remaining on the local
+   mapping is at least 3/4 of the lifetime requested by the PCP client,
+   then the PCP proxy SHOULD send an immediate reply giving the
+   outermost external address and port (previously learned using PCP
+   recursively, as described below) and the actual lifetime remaining
+   for this mapping.  If the lifetime remaining on the local mapping is
+   less than 3/4 of the lifetime requested by the PCP client, then the
+   PCP proxy MUST generate an upstream request as described below.
+
+   For mapping-deletion requests (lifetime = 0), the local mapping, if
+   any, is deleted, and then (regardless of whether or not a local
+   mapping existed) a corresponding upstream request is generated.
+
+   The PCP proxy knows the destination IP address for its upstream
+   PCP request using the same means that are available for provisioning
+   a PCP client.  In particular, the PCP proxy MUST follow the procedure
+   defined in Section 8.1 of the PCP specification [RFC6887] to discover
+   its PCP server.  This does not preclude other means from being used
+   in addition.
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 6]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+   In the upstream PCP request:
+
+   o  The PCP client's IP address and internal port are the PCP proxy's
+      own external address and port just allocated for this mapping.
+
+   o  The suggested external address and port in the upstream
+      PCP request SHOULD be copied from the original PCP request.  On a
+      typical renewal request, this will be the outermost external
+      address and port previously learned by the client.
+
+   o  The requested lifetime is as requested by the client if it falls
+      within the acceptable range for this PCP server; otherwise, it
+      SHOULD be capped to appropriate minimum and maximum values
+      configured for this PCP server.
+
+   o  The mapping nonce is copied from the original PCP request.
+
+   o  For PEER requests, the remote peer IP address and port are copied
+      from the original PCP request.
+
+   Upon receipt of a PCP reply giving the outermost (i.e., publicly
+   routable) external address, port, and lifetime, the PCP proxy records
+   this information in its own mapping table and relays the information
+   to the requesting downstream PCP client in a PCP reply.  The
+   PCP proxy therefore records, among other things, the following
+   information in its mapping table:
+
+   o  Client's internal address and port.
+
+   o  External address and port allocated by this PCP proxy.
+
+   o  Outermost external address and port allocated by the upstream
+      PCP server.
+
+   o  Mapping lifetime (also dictated by the upstream PCP server).
+
+   o  Mapping nonce.
+
+   In the downstream PCP reply:
+
+   o  The lifetime is as granted by the upstream PCP server, or less if
+      the granted lifetime exceeds the maximum lifetime this PCP server
+      is configured to grant.  If the proxy chooses to grant a
+      downstream lifetime greater than the lifetime granted by the
+      upstream PCP server (which is NOT RECOMMENDED), then this
+      PCP proxy MUST take responsibility for renewing the upstream
+      mapping itself.
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 7]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+   o  The Epoch Time is this PCP proxy's Epoch Time, not the Epoch Time
+      of the upstream PCP server.  Each PCP server has its own
+      independent Epoch Time.  However, if the Epoch Time received from
+      the upstream PCP server indicates a loss of state in that
+      PCP server, the PCP proxy can either (1) recreate the lost
+      mappings itself or (2) reset its own Epoch Time to cause its
+      downstream clients to perform such state repairs themselves.  A
+      PCP proxy MUST NOT simply copy the upstream PCP server's
+      Epoch Time into its downstream PCP replies, because if it suffers
+      its own state loss it needs the ability to communicate that state
+      loss to clients.  Thus, each PCP server has its own independent
+      Epoch Time.  However, as a convenience, a downstream PCP proxy may
+      simply choose to reset its own Epoch Time whenever it detects that
+      its upstream PCP server has lost state.  Thus, in this case, the
+      PCP proxy's Epoch Time always resets whenever its upstream
+      PCP server loses state; it may reset at other times as well.
+
+   o  The mapping nonce is copied from the reply received from the
+      upstream PCP server.
+
+   o  The assigned external port and assigned external IP address are
+      copied from the reply received from the upstream PCP server (i.e.,
+      they are the outermost external IP address and port, not the
+      locally assigned external address and port).  By recursive
+      application of this procedure, the outermost external IP address
+      and port are relayed from the outermost NAT, through one or more
+      intervening PCP proxies, until they ultimately reach the
+      downstream client.
+
+   o  For PEER requests, the remote peer IP address and port are copied
+      from the reply received from the upstream PCP server.
+
+3.1.  Optimized Hairpin Routing
+
+   A PCP proxy SHOULD implement optimized hairpin routing.  What this
+   means is the following:
+
+   o  If a PCP proxy observes an outgoing packet arriving on its
+      internal interface that is addressed to an external address and
+      port appearing in the NAT gateway's own mapping table, then the
+      NAT gateway SHOULD (after creating a new outbound mapping if one
+      does not already exist) rewrite the packet appropriately and
+      deliver it to the internal client to which that external address
+      and port are currently allocated.
+
+
+
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 8]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+   o  Similarly, if a PCP proxy observes an outgoing packet arriving on
+      its internal interface that is addressed to an *outermost*
+      external address and port appearing in the NAT gateway's own
+      mapping table, then the NAT gateway SHOULD do as described above:
+      create a new outbound mapping if one does not already exist, and
+      then rewrite the packet appropriately and deliver it to the
+      internal client to which that outermost external address and port
+      are currently allocated.  This is not necessary for successful
+      communication, but it provides efficiency.  Without this optimized
+      hairpin routing, the packet will be delivered all the way to the
+      outermost NAT gateway, which will then perform standard hairpin
+      translation and send it back.  Using knowledge of the outermost
+      external address and port, this rewriting can be anticipated and
+      performed locally.  This rewriting technique will typically offer
+      higher throughput and lower latency than sending packets all the
+      way to the outermost NAT gateway and back.
+
+   Note that traffic counters maintained by an upstream PCP server will
+   differ from the counters of a PCP proxy implementing optimized
+   hairpin routing.
+
+3.2.  Termination of Recursion
+
+   Any recursive algorithm needs a mechanism to terminate the recursion
+   at the appropriate point.  This termination of recursion can be
+   achieved in a variety of ways.  The following (non-exhaustive)
+   examples are provided for illustration purposes:
+
+   o  An ISP's PCP-controlled gateway (which may embed a NAT, firewall,
+      or any function that can be controlled with PCP) could be
+      configured to know that it is the outermost PCP-controlled
+      gateway, and consequently it does not need to relay PCP requests
+      upstream.
+
+   o  A PCP-controlled gateway could determine automatically that if its
+      external address is not one of the known private addresses
+      [RFC1918] [RFC6598], then its external address is a public
+      routable IP address, and consequently it does not need to relay
+      PCP requests upstream.
+
+   o  Recursion may be terminated if there is no explicit list of
+      PCP servers configured (manually, using DHCP [RFC7291], or
+      otherwise) or if its default router is not responsive to
+      PCP requests.
+
+   o  Recursion may also be terminated if the upstream PCP-controlled
+      device does not embed a PCP proxy.
+
+
+
+
+Perreault, et al.            Standards Track                    [Page 9]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+3.3.  Source Address for PCP Requests Sent Upstream
+
+   As with a regular PCP server, the PCP-controlled device can be a NAT,
+   a firewall, or even some sort of hybrid.  In particular, a PCP proxy
+   that simply relays all requests upstream can be thought of as the
+   degenerate case of a PCP server controlling a wide-open firewall
+   back-to-back with a regular PCP client.
+
+   One important property of the PCP-controlled device will affect the
+   PCP proxy's behavior: when the proxy's server part instructs the
+   device to create a mapping, that mapping's external address may or
+   may not be one that belongs to the proxy node.
+
+   o  When the mapping's external address belongs to the proxy node, as
+      would presumably be the case for a NAT, then the proxy's client
+      side sends out an upstream PCP request using the mapping's
+      external IP address as the source.
+
+   o  When the mapping's external address does not belong to the proxy
+      node, as would presumably be the case for a firewall, then the
+      proxy's client side needs to install upstream mappings on behalf
+      of its downstream clients.  To do this, it MUST insert a
+      THIRD_PARTY option in its upstream PCP request carrying the
+      mapping's external address.
+
+   Note that hybrid PCP-controlled devices may create NAT-like mappings
+   in some circumstances and firewall-like mappings in others.  A proxy
+   controlling such a device would adjust its behavior dynamically,
+   depending on the kind of mapping created.
+
+3.4.  Unknown Opcodes and Options
+
+3.4.1.  No NAT Is Co-located with the PCP Proxy
+
+   When no NAT is co-located with the PCP proxy, the port numbers
+   included in received PCP messages (from the PCP server or
+   PCP client(s)) are not altered by the PCP proxy.  The PCP proxy
+   relays to the PCP server unknown options and Opcodes because there is
+   no reachability failure risk.
+
+3.4.2.  PCP Proxy Co-located with a NAT Function
+
+   By default, the proxy MUST relay unknown Opcodes and mandatory-to-
+   process unknown options.  Rejecting unknown options and Opcodes has
+   the drawback of preventing a PCP client from making use of new
+   capabilities offered by the PCP server but not supported by the
+   PCP proxy, even if no IP address and/or port is included in the
+   option/Opcode.
+
+
+
+Perreault, et al.            Standards Track                   [Page 10]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+   Because PCP messages with an unknown Opcode or mandatory-to-process
+   unknown options can carry a hidden internal address or internal port
+   that will not be translated, a PCP proxy MUST be configurable to
+   disable relaying unknown Opcodes and mandatory-to-process unknown
+   options.  If the PCP proxy is configured to disable relaying unknown
+   Opcodes and mandatory-to-process unknown options, the PCP proxy MUST
+   behave as follows:
+
+   o  a PCP proxy co-located with a NAT MUST reject, via an
+      UNSUPP_OPCODE error response, a received request with an unknown
+      Opcode.
+
+   o  a PCP proxy co-located with a NAT MUST reject, via an
+      UNSUPP_OPTION error response, a received request with a mandatory-
+      to-process unknown option.
+
+3.5.  Mapping Repair
+
+   ANNOUNCE requests received from PCP clients are handled locally; as
+   such, these requests MUST NOT be relayed to the provisioned
+   PCP server.
+
+   Upon receipt of an unsolicited ANNOUNCE response from a PCP server,
+   the PCP proxy proceeds to renew the mappings and checks to see
+   whether or not there are changes compared to a local cache if it is
+   maintained by the PCP proxy.  If no change is detected, no
+   unsolicited ANNOUNCE is generated towards PCP clients.  If a change
+   is detected, the PCP proxy MUST generate unsolicited ANNOUNCE
+   message(s) to appropriate PCP clients.  If the PCP proxy does not
+   maintain a local cache for the mappings, unsolicited multicast
+   ANNOUNCE messages are sent to PCP clients.
+
+   Upon change of its external IP address, the PCP proxy SHOULD renew
+   the mappings it maintained.  If the PCP server assigns a different
+   external port, the PCP proxy SHOULD follow the PCP mapping repair
+   procedure [RFC6887].  This can be achieved only if a full state table
+   is maintained by the PCP proxy.
+
+3.6.  Multiple PCP Servers
+
+   A PCP proxy MAY handle multiple PCP servers at the same time.  Each
+   PCP server is associated with its own epoch value.  PCP clients are
+   not aware of the presence of multiple PCP servers.
+
+   Following the PCP Server Selection process [RFC7488], if several
+   PCP servers are configured to the PCP proxy, it will contact in
+   parallel all these PCP servers.
+
+
+
+
+Perreault, et al.            Standards Track                   [Page 11]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+   In some contexts (e.g., PCP-controlled Carrier-Grade NATs (CGNs)),
+   the PCP proxy MAY load-balance the PCP clients among available
+   PCP servers.  The PCP proxy MUST ensure that requests of a given
+   PCP client are relayed to the same PCP server.
+
+   The PCP proxy MAY rely on some fields (e.g., Zone-ID [PCP-ZONES]) in
+   the PCP request to redirect the request to a given PCP server.
+
+4.  Security Considerations
+
+   The PCP proxy MUST follow the security considerations detailed in the
+   PCP specification [RFC6887] for both the client and server side.
+
+   Section 3.3 specifies the cases where a THIRD_PARTY option is
+   inserted by the PCP proxy.  In those cases, ways to prevent a
+   malicious user from creating mappings on behalf of a third party must
+   be employed as discussed in Section 13.1 of the PCP specification
+   [RFC6887].  In particular, THIRD_PARTY options MUST NOT be enabled
+   unless the network on which the PCP messages are to be sent is fully
+   trusted (via physical or cryptographic security, or both) -- for
+   example, if access control lists (ACLs) are installed on the
+   PCP proxy, the PCP server, and the network between them so that those
+   ACLs allow only communications from a trusted PCP proxy to the
+   PCP server.
+
+   A received request carrying an unknown Opcode or option SHOULD be
+   dropped (or, in the case of an unknown option that is not mandatory
+   to process, the option SHOULD be removed) if it is not compatible
+   with security controls provisioned to the PCP proxy.
+
+   The device embedding the PCP proxy MAY block PCP requests directly
+   sent to the upstream PCP server(s).  This can be enforced using ACLs.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [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>.
+
+
+
+
+
+Perreault, et al.            Standards Track                   [Page 12]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+5.2.  Informative References
+
+   [PCP-ANYCAST]
+              Kiesel, S., Penno, R., and S. Cheshire, "Port Control
+              Protocol (PCP) Anycast Addresses", Work in Progress,
+              draft-ietf-pcp-anycast-07, August 2015.
+
+   [PCP-DEPLOY]
+              Boucadair, M., "Port Control Protocol (PCP) Deployment
+              Models", Work in Progress,
+              draft-boucadair-pcp-deployment-cases-03, July 2014.
+
+   [PCP-ZONES]
+              Penno, R., "PCP Support for Multi-Zone Environments", Work
+              in Progress, draft-penno-pcp-zones-01, October 2011.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
+              <http://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
+              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
+              Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
+              2012, <http://www.rfc-editor.org/info/rfc6598>.
+
+   [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>.
+
+   [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>.
+
+Acknowledgements
+
+   Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and
+   comments.
+
+   Special thanks to F. Dupont, who contributed to this document.
+
+
+
+
+
+
+
+
+
+Perreault, et al.            Standards Track                   [Page 13]
+
+RFC 7648                        PCP Proxy                 September 2015
+
+
+Authors' Addresses
+
+   Simon Perreault
+   Jive Communications
+   Quebec, QC
+   Canada
+
+   Email: sperreault@jive.com
+
+
+   Mohamed Boucadair
+   France Telecom
+   Rennes  35000
+   France
+
+   Email: mohamed.boucadair@orange.com
+
+
+   Reinaldo Penno
+   Cisco
+   United States
+
+   Email: repenno@cisco.com
+
+
+   Dan Wing
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, California  95134
+   United States
+
+   Email: dwing@cisco.com
+
+
+   Stuart Cheshire
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, California  95014
+   United States
+
+   Phone: +1 408 974 3207
+   Email: cheshire@apple.com
+
+
+
+
+
+
+
+
+
+Perreault, et al.            Standards Track                   [Page 14]
+