Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6887

Port Control Protocol (PCP)

Pages: 88
Proposed Standard
Errata
Updated by:  748876527843
Part 1 of 4 – Pages 1 to 20
None   None   Next

Top   ToC   RFC6887 - Page 1
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)

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. 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/rfc6887. Copyright Notice Copyright (c) 2013 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
Top   ToC   RFC6887 - Page 2
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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
Top   ToC   RFC6887 - Page 3
   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
Top   ToC   RFC6887 - Page 4

1. Introduction

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 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. 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. 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. 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
Top   ToC   RFC6887 - Page 5
   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.

2. Scope

2.1. Deployment Scenarios

PCP can be used in various deployment scenarios, including: o Basic NAT [RFC3022] o Network Address and Port Translation [RFC3022], such as commonly deployed in residential NAT devices o Carrier-Grade NAT [RFC6888] o Dual-Stack Lite (DS-Lite) [RFC6333] o NAT that is Layer-2 Aware [L2NAT] o Dual-Stack Extra Lite [RFC6619] o NAT64, both Stateless [RFC6145] and Stateful [RFC6146] o IPv4 and IPv6 simple firewall control [RFC6092] o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]

2.2. Supported Protocols

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.

2.3. Single-Homed Customer Premises Network

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
Top   ToC   RFC6887 - Page 6
   (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).

3. 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]. 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. 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]. Internal Address: The address of an internal host served by a NAT gateway or protected by a firewall. 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. 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
Top   ToC   RFC6887 - Page 7
      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].

   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.

   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.

   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.

      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.

   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.
Top   ToC   RFC6887 - Page 8
   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.

      *  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.

      *  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).

      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.
Top   ToC   RFC6887 - Page 9
      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.

      *  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.

      *  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.

      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).

   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-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 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.
Top   ToC   RFC6887 - Page 10
   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.

4. Relationship between PCP Server and Its PCP-Controlled Device

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. +-----------------+ +------------+ | NAT or firewall | | PCP client |-<network>-+ with +---<Internet> +------------+ | PCP server | +-----------------+ Figure 1: PCP-Enabled NAT or Firewall 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.

5. Note on Fixed-Size Addresses

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.
Top   ToC   RFC6887 - Page 11
   When the address field holds an IPv6 address, the fixed-size 128-bit
   IP address field holds the IPv6 address stored as is.

   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.

   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.

   The all-zeros IPv6 address MUST be expressed by filling the
   fixed-size 128-bit IP address field with all zeros (::).

   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).

6. Protocol Design Note

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. 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: 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 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. 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.
Top   ToC   RFC6887 - Page 12
   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).

   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.

   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.

   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
Top   ToC   RFC6887 - Page 13
   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.

7. Common Request and Response Header Format

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). 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.
Top   ToC   RFC6887 - Page 14

7.1. Request Header

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 : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Common Request Packet Format 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. R: Indicates Request (0) or Response (1). Opcode: A 7-bit value specifying the operation to be performed. MAP and PEER Opcodes are defined in Sections 11 and 12. Reserved: 16 reserved bits. MUST be zero on transmission and MUST be ignored on reception. 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.
Top   ToC   RFC6887 - Page 15
   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.

   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.

7.2. Response Header

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 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Common Response Packet Format These fields are described below: Version: Responses from servers compliant with this specification MUST use version 2. This is set by the server. R: Indicates Request (0) or Response (1). All Responses MUST use 1. This is set by the server.
Top   ToC   RFC6887 - Page 16
   Opcode:  The 7-bit Opcode value.  The server copies this value from
      the request.

   Reserved:  8 reserved bits, MUST be sent as 0, MUST be ignored when
      received.  This is set by the server.

   Result Code:  The result code for this response.  See Section 7.4 for
      values.  This is set by the server.

   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.

   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.

   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.

   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.

7.3. Options

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
Top   ToC   RFC6887 - Page 17
   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.

   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                         :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: Options Header

   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.

   Reserved:  8 bits.  MUST be set to 0 on transmission and MUST be
      ignored on reception.

   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.

   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.
Top   ToC   RFC6887 - Page 18
   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.

   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.

   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.

   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.

   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.
Top   ToC   RFC6887 - Page 19
   Different options are valid for different Opcodes.  For example:

   o  The THIRD_PARTY option is valid for both MAP and PEER Opcodes.

   o  The FILTER option is valid only for the MAP Opcode (for the PEER
      Opcode it would have no meaning).

   o  The PREFER_FAILURE option is valid only for the MAP Opcode (for
      the PEER Opcode, similar semantics are automatically implied).

7.4. Result Codes

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. 0 SUCCESS: Success. 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. 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. 3 MALFORMED_REQUEST: The request could not be successfully parsed. This is a long lifetime error. 4 UNSUPP_OPCODE: Unsupported Opcode. This is a long lifetime error. 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. 6 MALFORMED_OPTION: Malformed option (e.g., appears too many times, invalid length). This is a long lifetime error. 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.
Top   ToC   RFC6887 - Page 20
   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.

   9  UNSUPP_PROTOCOL: Unsupported transport protocol, e.g., SCTP in a
      NAT that handles only UDP and TCP.  This is a long lifetime error.

   10 USER_EX_QUOTA: This attempt to create a new mapping would exceed
      this subscriber's port quota.  This is a short lifetime error.

   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

      See Section 13.2 for details of the PREFER_FAILURE Option.  The
      error lifetime depends on the reason for the failure.

   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.

   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.



(page 20 continued on part 2)

Next Section