RFC 6887
Port Control Protocol (PCP)
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
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
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
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
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
(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
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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)
