17. Deployment Considerations
17.1. Ingress Filtering
As with implicit dynamic mappings created by outgoing TCP SYN
packets, explicit dynamic mappings created via PCP use the source IP
address of the packet as the internal address for the mappings.
Therefore, ingress filtering [RFC2827] SHOULD be used on the path
between the internal host and the PCP server to prevent the injection
of spoofed packets onto that path.
17.2. Mapping Quota
On PCP-controlled devices that create state when a mapping is created
(e.g., NAT), the PCP server SHOULD maintain per-host and/or per-
subscriber quotas for mappings. It is implementation specific
whether the PCP server uses a separate quotas for implicit, explicit,
and static mappings, a combined quota for all of them, or some other
18. Security Considerations
The goal of the PCP protocol is to improve the ability of end nodes
to control their associated NAT state, and to improve the efficiency
and error handling of NAT mappings when compared to existing implicit
mapping mechanisms in NAT boxes and stateful firewalls. It is the
security goal of the PCP protocol to limit any new denial-of-service
opportunities, and to avoid introducing new attacks that can result
in unauthorized changes to mapping state. One of the most serious
consequences of unauthorized changes in mapping state is traffic
theft. All mappings that could be created by a specific host using
implicit mapping mechanisms are inherently considered to be
authorized. Confidentiality of mappings is not a requirement, even
in cases where the PCP messages may transit paths that would not be
traveled by the mapped traffic.
18.1. Simple Threat Model
PCP servers are secure against off-path attackers who cannot spoof a
packet that the PCP server will view as a packet received from the
internal network. PCP clients are secure against off-path attackers
who can spoof the PCP server's IP address.
Defending against attackers who can modify or drop packets between
the internal network and the PCP server, or who can inject spoofed
packets that appear to come from the internal network is out of
scope. Such an attacker can redirect traffic to a host of their
A PCP server is secure under this threat model if the PCP server is
constrained so that it does not configure any explicit mapping that
it would not configure implicitly. In most cases, this means that
PCP servers running on NAT boxes or stateful firewalls that support
the PEER and MAP Opcodes can be secure under this threat model if
(1) all of their hosts are within a single administrative domain (or
if the internal hosts can be securely partitioned into separate
administrative domains, as in the DS-Lite B4 case), (2) explicit
mappings are created with the same lifetime as implicit mappings, and
(3) the THIRD_PARTY option is not supported. PCP servers can also
securely support the MAP Opcode under this threat model if the
security policy on the device running the PCP server would permit
endpoint-independent filtering of implicit mappings.
PCP servers that comply with the Simple Threat Model and do not
implement a PCP security mechanism described in Section 18.2 MUST
enforce the constraints described in the paragraph above.
18.1.1. Attacks Considered
o If you allow multiple administrative domains to send PCP requests
to a single PCP server that does not enforce a boundary between
the domains, it is possible for a node in one domain to perform a
denial-of-service attack on other domains or to capture traffic
that is intended for a node in another domain.
o If explicit mappings have longer lifetimes than implicit mappings,
it makes it easier to perpetrate a denial-of-service attack than
it would be if the PCP server was not present.
o If the PCP server supports deleting or reducing the lifetime of
existing mappings, this allows an attacking node to steal an
existing mapping and receive traffic that was intended for another
o If the THIRD_PARTY option is supported, this also allows an
attacker to open a window for an external node to attack an
internal node, allows an attacker to steal traffic that was
intended for another node, or may facilitate a denial-of-service
attack. One example of how the THIRD_PARTY option could grant an
attacker more capability than a spoofed implicit mapping is that
the PCP server (especially if it is running in a service
provider's network) may not be aware of internal filtering that
would prevent spoofing an equivalent implicit mapping, such as
filtering between a guest and corporate network.
o If the MAP Opcode is supported by the PCP server in cases where
the security policy would not support endpoint-independent
filtering of implicit mappings, then the MAP Opcode changes the
security properties of the device running the PCP server by
allowing explicit mappings that violate the security policy.
18.1.2. Deployment Examples Supporting the Simple Threat Model
This section offers two examples of how the Simple Threat Model can
be supported in real-world deployment scenarios.
18.104.22.168. Residential Gateway Deployment
Parity with many currently deployed residential gateways can be
achieved using a PCP server that is constrained as described in
Section 18.1 above.
18.2. Advanced Threat Model
In the Advanced Threat Model, the PCP protocol ensures that attackers
(on- or off-path) cannot create unauthorized mappings or make
unauthorized changes to existing mappings. The protocol must also
limit the opportunity for on- or off-path attackers to perpetrate
The Advanced Threat Model security model will be needed in the
o Security infrastructure equipment, such as corporate firewalls,
that does not create implicit mappings.
o Equipment (such as CGNs or service provider firewalls) that serves
multiple administrative domains and does not have a mechanism to
securely partition traffic from those domains.
o Any implementation that wants to be more permissive in authorizing
explicit mappings than it is in authorizing implicit mappings.
o Implementations that wish to support any deployment scenario that
does not meet the constraints described in Section 18.1.
To protect against attacks under this threat model, a PCP security
mechanism that provides an authenticated, integrity-protected
signaling channel would need to be specified.
PCP servers that implement a PCP security mechanism MAY accept
unauthenticated requests. In their default configuration, PCP
servers implementing the PCP security mechanism MUST still enforce
the constraints described in Section 18.1 when processing
18.3. Residual Threats
This section describes some threats that are not addressed in either
of the above threat models and recommends appropriate mitigation
18.3.1. Denial of Service
Because of the state created in a NAT or firewall, a per-host and/or
per-subscriber quota will likely exist for both implicit dynamic
mappings and explicit dynamic mappings. A host might make an
excessive number of implicit or explicit dynamic mappings, consuming
an inordinate number of ports, causing a denial of service to other
hosts. Thus, Section 17.2 recommends that hosts be limited to a
reasonable number of explicit dynamic mappings.
An attacker, on the path between the PCP client and PCP server, can
drop PCP requests, drop PCP responses, or spoof a PCP error, all of
which will effectively deny service. Through such actions, the PCP
client might not be aware the PCP server might have actually
processed the PCP request. An attacker sending a NO_RESOURCES error
can cause the PCP client to not send messages to that server for a
while. There is no mitigation to this on-path attacker.
18.3.2. Ingress Filtering
It is important to prevent a host from fraudulently creating,
deleting, or refreshing a mapping (or filtering) for another host,
because this can expose the other host to unwanted traffic, prevent
it from receiving wanted traffic, or consume the other host's mapping
quota. Both implicit and explicit dynamic mappings are created based
on the source IP address in the packet, and hence depend on ingress
filtering to guard against spoof source IP addresses.
18.3.3. Mapping Theft
In the time between when a PCP server loses state and the PCP client
notices the lower-than-expected Epoch Time value, it is possible that
the PCP client's mapping will be acquired by another host (via an
explicit dynamic mapping or implicit dynamic mapping). This means
incoming traffic will be sent to a different host ("theft"). Rapid
recovery reduces this interval, but does not completely eliminate
this threat. The PCP client can reduce this interval by using a
relatively short lifetime; however, this increases the amount of PCP
chatter. This threat is reduced by using persistent storage of
explicit dynamic mappings in the PCP server (so it does not lose
explicit dynamic mapping state), or by ensuring that the previous
external IP address, protocol, and port cannot be used by another
host (e.g., by using a different IP address pool).
18.3.4. Attacks against Server Discovery
This document does not specify server discovery, beyond contacting
the default gateway.
19. IANA Considerations
IANA has performed the following actions.
19.1. Port Number
PCP uses ports 5350 and 5351, previously assigned by IANA to NAT-PMP
[RFC6886]. IANA has reassigned those ports to PCP.
IANA has created a new protocol registry for PCP Opcodes, numbered
0-127, initially populated with the values:
3-31 Standards Action [RFC5226]
32-63 Specification Required [RFC5226]
96-126 Reserved for Private Use [RFC5226]
127 Reserved, Standards Action [RFC5226]
The value 127 is Reserved and may be assigned via Standards Action
[RFC5226]. The values in the range 3-31 can be assigned via
Standards Action [RFC5226], 32-63 via Specification Required
[RFC5226], and the range 96-126 is for Private Use [RFC5226].
19.3. Result Codes
IANA has created a new registry for PCP result codes, numbered 0-255,
initially populated with the result codes from Section 7.4. The
value 255 is Reserved and may be assigned via Standards Action
The values in the range 14-127 can be assigned via Standards Action
[RFC5226], 128-191 via Specification Required [RFC5226], and the
range 191-254 is for Private Use [RFC5226].
IANA has created a new registry for PCP options, numbered 0-255, each
with an associated mnemonic. The values 0-127 are mandatory to
process, and 128-255 are optional to process. The initial registry
contains the options described in Section 13. The option values 0,
127, and 255 are Reserved and may be assigned via Standards Action
Additional PCP option codes in the ranges 4-63 and 128-191 can be
created via Standards Action [RFC5226], the ranges 64-95 and 192-223
are for Specification Required [RFC5226], and the ranges 96-126 and
224-254 are for Private Use [RFC5226].
Documents describing an option should describe the processing for
both the PCP client and server, and the information below:
Option Name: <mnemonic>
Purpose: <textual description>
Valid for Opcodes: <list of Opcodes>
Length: <rules for length>
May appear in: <requests/responses/both>
Maximum occurrences: <count>
Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni
Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda
Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani,
Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete
Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins,
Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda
Costa, Amit Jain, and Wim Henderickx for their comments and review.
Thanks to Simon Perreault for highlighting the interaction of dynamic
connections with PCP-created mappings and for many other review
Thanks to Francis Dupont for his several thorough reviews of the
specification, which improved the protocol significantly.
Thanks to T. S. Ranganathan for the state diagram.
Thanks to Peter Lothberg for clock skew information, which guided the
choice of tolerance levels for deciding when an Epoch time should be
considered to be anomalous.
Thanks to Margaret Wasserman and Sam Hartman for writing the Security
Thanks to authors of DHCPv6 for retransmission text.
[PNP-IGD-PCP] Boucadair, M., Penno, R., and D. Wing, "Universal
Plug and Play (UPnP) Internet Gateway Device (IGD)-
Port Control Protocol (PCP) Interworking Function",
Work in Progress, December 2012.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP
Network Address Translator (Traditional NAT)",
RFC 3022, January 2001.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to
the Session Initiation Protocol (SIP) for Symmetric
Response Routing", RFC 3581, August 2003.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6
Global Unicast Address Format", RFC 3587,
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
[RFC4787] Audet, F. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for
Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration
in IPv6", RFC 4941, September 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol
(RTCP)", BCP 131, RFC 4961, July 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and
P. Srisuresh, "NAT Behavioral Requirements for TCP",
BCP 142, RFC 5382, October 2008.
[RFC6092] Woodyatt, J., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE)
for Providing Residential IPv6 Internet Service",
RFC 6092, January 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum,
"Stateful NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers",
RFC 6146, April 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network
Prefix Translation", RFC 6296, June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee,
"Dual-Stack Lite Broadband Deployments Following
IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable
Operation of Address Translators with Per-Interface
Bindings", RFC 6619, June 2012.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping
Protocol (NAT-PMP)", RFC 6886, April 2013.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S.,
Nakagawa, A., and H. Ashida, "Common Requirements
for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888,
[SCTPNAT] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream
Control Transmission Protocol (SCTP) Network Address
Translation", Work in Progress, February 2013.
Appendix A. NAT-PMP Transition
The Port Control Protocol (PCP) is a successor to the NAT Port
Mapping Protocol, NAT-PMP [RFC6886], and shares similar semantics,
concepts, and packet formats. Because of this, NAT-PMP and PCP both
use the same port and use NAT-PMP and PCP's version negotiation
capabilities to determine which version to use. This section
describes how an orderly transition from NAT-PMP to PCP may be
A client supporting both NAT-PMP and PCP SHOULD send its request
using the PCP packet format. This will be received by a NAT-PMP
server or a PCP server. If received by a NAT-PMP server, the
response will be UNSUPP_VERSION, as indicated by the NAT-PMP
specification [RFC6886], which will cause the client to downgrade to
NAT-PMP and resend its request in NAT-PMP format. If received by a
PCP server, the response will be as described by this document and
processing continues as expected.
A PCP server supporting both NAT-PMP and PCP can handle requests in
either format. The first octet of the packet indicates if it is
NAT-PMP (first octet zero) or PCP (first octet non-zero).
A PCP-only gateway receiving a NAT-PMP request (identified by the
first octet being zero) will interpret the request as a version
mismatch. Normal PCP processing will emit a PCP response that is
compatible with NAT-PMP, without any special handling by the PCP
Dan Wing (editor)
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
1 Infinite Loop
Cupertino, California 95014
Phone: +1 408 974 3207
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
Internet Systems Consortium
950 Charter Street
Redwood City, California 94063