One document matched: draft-ietf-pcp-base-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pcp-base-07" ipr="trust200902">
<front>
<title abbrev="Port Control Protocol (PCP)">Port Control Protocol
(PCP)</title>
<author fullname="Dan Wing" initials="D." role="editor" surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization abbrev="Apple">Apple, Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 408 974 3207</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>California</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>rpenno@juniper.net</email>
</address>
</author>
<author fullname="Francis Dupont" initials="F." surname="Dupont">
<organization>Internet Systems Consortium</organization>
<address>
<postal>
<street></street>
</postal>
<email>fdupont@isc.org</email>
</address>
</author>
<date />
<workgroup>PCP working group</workgroup>
<abstract>
<t>Port Control Protocol allows a host to control how incoming IPv6 or
IPv4 packets are translated and forwarded by a network address
translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also
allows a host to optimize its NAT keepalive messages.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Port Control Protocol (PCP) provides a mechanism to control how
incoming packets are forwarded by upstream devices such as NAT64, NAT44,
and firewall devices, and a mechanism to reduce application keepalive
traffic. PCP is primarily designed to be implemented in the context of
both Carrier-Grade NATs (CGN) and small NATs (e.g., residential NATs).
PCP allows hosts to operate server for a long time (e.g., a webcam) 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.</t>
<t>PCP allows applications to create mappings from an external IP
address and port to an internal IP address and port. These
mappings are required for successful inbound communications destined to
machines located behind a NAT or a firewall.</t>
<t>After creating a mapping for incoming connections, it is necessary to
inform remote computers about the IP address and port for the incoming
connection. This is usually done in an application-specific manner. For
example, a computer game would use a rendezvous server specific to that
game (or specific to that game developer), and a SIP phone would use a
SIP proxy. PCP does not provide this rendezvous function. The rendezvous
function will support IPv4, IPv6, or both. Depending on that support and
the application's support of IPv4 or IPv6, the PCP client will need an
IPv4 mapping, an IPv6 mapping, or both.</t>
<t>Many NAT-friendly applications send frequent application-level
messages to ensure 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 those 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.</t>
<t>Many NATs and firewalls have included application layer gateways
(ALGs) to create mappings for applications that establish additional
streams or accept incoming connections. ALGs incorporated into NATs
additionally modify the application payload. Industry experience has
shown that these ALGs are detrimental to protocol evolution. PCP allows
an application create its own mappings in NATs and firewalls, reducing
the incentive to deploy ALGs in NATs and firewalls.</t>
<!--
> 1. define new IE, EVEN_PLUS_ONE, which has no payload.
>
> 2. PCP request is sent, with that IE.
>
> 3. PCP server attempts to allocate an even port number, and
> PCP server reserves the adjacent port number (sticks it
> on the TIME_WAIT queue for 5 seconds, and it is only allocatable
> to the same IP address as got the even port number).
>
> Maybe we have PCP server return an IE EVEN_PLUS_ONE if it
> was able to allocate the adjacent port. That seems helpful
> for the next steps.
>
> 4. VoIP endpoint can send its SIP/SDP message now. Total
> delay: one round trip to PCP server.
>
> 5. A second PCP request is sent, without the IE, requesting
> port+1.
>
> Med: I still we can avoid some extra exchanges with the server (for
> instance in your bullet 5, you will need to do it for all the media you
> are negotiating including audio, video, etc.).
If the endpoint needs to do audio and video, it will send two PCP
requests, at the same time, in step 2. This will result in two
PCP responses in step 4.
As soon as the audio+video session is established, there will be
at least 50 packets per second of video and ~20-50 packets per
second of video.
Here are the scenarios:
1. internal host is IPv4 only
2. internal host is IPv6 only
3. internal host is dual stack
For (1), that host can only do PIN44 (to get a public IPv4 address)
or PIN46 (to get a public IPv6 address).
For (2), that host can only do PIN66 (to get a public IPv6 address;
mostly this is for IPv6 firewall. Yes, this needs more fleshing
out. Yes, there is an "Ed. Note" to that effect in the document.
Yes, I am aware of that) or PIN64 (to get a public IPv4 address).
For (3), that host can use any of the four opcodes (PIN44, PIN46,
PIN64, PIN66). If it is being reasonable, it won't do PIN46
or PIN64, because it could just keep the IP address family the
same instead because it is dual stack. But we cannot detect
a dual-stack node and there isn't a reason to block it. So,
yes, I suppose a dual-stack host could attempt all four of
the OpCodes. But it would more reasonably do PIN44 to get
a public IPv4 presence and PIN66 to get a public IPv6 presence.
Besides, on a network with a dual-stack host, that network
is unlikely (not not prohibited) to operate a NAT64, and
also unlikely (but not prohibited) to operate a NAT46. This
seems to warrant some text around
In some scenarios communications may fail if intermediary (non
PCP-controlled) firewalls are not appropriately configured to accept
incoming traffic. Detecting the presence of firewall(s) in the path
and configuring it is out of scope of this document
Add discussion around if, to optimize keepalives, a host
should do PCP first or should do its TCP (or UDP) first.
If PCP is done first, the mapping will be endpoint independent.
If doing TCP (or UDP) first, the mapping could be endpoint
independent or could be endpoint dependent. This is all
tweakable with the PCP option ENDPOINT_DEPENDANT.
Add defintion, for firewall, of ENDPOINT_DEPENDANT. This allows
indicating an IPvM address (which, by necessity, matches the
length of the outside address of the PINxy), and optionally
allows indicating the remote protocol and remote port. Remote
protocol 0 means 'any protocol'. Remote port 0 means 'any
port'. Packets from the public Internet which don't match the
filter SHOULD get an ICMP error.
-->
</section>
<section title="Scope">
<section title="Deployment Scenarios">
<t>PCP can be used in various deployment scenarios, including:<list
style="symbols">
<t><xref target="I-D.ietf-softwire-dual-stack-lite">Dual
Stack-Lite</xref>, and;</t>
<t>NAT64, both <xref
target="I-D.ietf-behave-v6v4-xlate-stateful">Stateful</xref> and
<xref target="I-D.ietf-behave-v6v4-xlate">Stateless </xref>,
and;</t>
<t><xref target="I-D.ietf-behave-lsn-requirements">Carrier-Grade
NAT</xref>, and;</t>
<t><xref target="RFC3022">Basic NAT</xref>, and;</t>
<t><xref target="RFC3022">Network Address and Port Translation
(NAPT)</xref>, such as commonly deployed in residential NAT
devices, and;</t>
<t><xref target="I-D.miles-behave-l2nat">Layer-2 aware NAT</xref>
and <xref target="I-D.arkko-dual-stack-extra-lite">Dual-Stack
Extra Lite</xref>, and;</t>
<t><xref target="RFC6092">IPv6 firewall control</xref>.</t>
</list></t>
</section>
<section title="Supported Transport Protocols">
<t>The PCP OpCodes defined in this document are designed to support
transport protocols that use a 16-bit port number (e.g., TCP, UDP,
SCTP, DCCP). Transport protocols that do not use a port number (e.g.,
IPsec ESP), and the ability to use PCP to forward all traffic to a
single default host (often nicknamed "DMZ"), are beyond the scope of
this document.</t>
</section>
<section anchor="single_homed"
title="Single-homed Customer Premises Network">
<t>The PCP machinery assumes a single-homed host model. That is, for a
given IP version, only one default route exists to reach the Internet.
This is important because after a PCP mapping is created and an
inbound packet (e.g., TCP SYN) arrives at the host, the outbound
response (e.g., TCP SYNACK) has to go through the same path so the
proper address rewriting takes place on that outbound response packet.
This restriction exists because otherwise there would need to be one
PCP server for each egress, because the host could not reliably
determine which egress path packets would take, so 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.</t>
</section>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">"Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
<t><list style="hanging">
<t hangText="Internal Host:"><vspace
blankLines="0" />A host served by a NAT gateway, or protected by a
firewall. This is the host that receives the incoming traffic
created by a PCP MAP request, or the host that initiated an implicit
dynamic mapping (e.g., by sending a TCP SYN) across a firewall or a NAT.</t>
<t hangText="Remote Host:"><vspace blankLines="0" />A host with
which an Internal Host is communicating.</t>
<t hangText="Internal Address:"><vspace blankLines="0" />
The address of an Internal Host served by a NAT
gateway (typically a private address <xref target="RFC1918"></xref>)
or protected by a firewall.</t>
<t hangText="External Address:"><vspace blankLines="0" />
The address of an Internal
Host as seen by other Remote Hosts 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.</t>
<t hangText="Remote Peer Address:"><vspace blankLines="0" />
The address of a
Remote Host, as seen by the Internal Host. A Remote Address is
generally a public routable address. In the case of a Remote Host
that is itself served by a NAT gateway, the Remote Address may in
fact be the Remote Host'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.</t>
<t hangText="Third Party:"><vspace blankLines="0" />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. <vspace blankLines="1" /> In
the case where one device is managing Mappings on behalf of some
other device, the presence of the THIRD_PARTY option in the MAP
request signifies that the specified address, not the source IP
address of the PCP request packet, should be used as the Internal
Address for the Mapping. This can occur when PCP is proxied (e.g.,
UPnP IGD to PCP proxy) or if the internal host does
not implement PCP.</t>
<t hangText="Mapping, Port Mapping, Port Forwarding:">
<vspace blankLines="0" />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 and port are
translated to the internal IP and port, and vice versa. In the case of a
pure firewall, the "Mapping" is the identity function,
translating an internal port number to the same external
port number, and this "Mapping" indicates to
the firewall that traffic to and from this internal port
number is permitted to pass.
The term "Port Forwarding" is sometimes
used instead of "Port Mapping" in the case where the internal and
external ports are the same, e.g. a mapping which forwards
packets addressed to external address:port 192.0.2.1:12345 to
internal address:port 192.168.1.1:12345.
</t>
<t hangText="Mapping Types:"><vspace blankLines="0" />There are
three different ways to create mappings: implicit dynamic mappings,
explicit dynamic mappings, and static mappings. Implicit dynamic
mappings are created as a result of a TCP SYN or outgoing UDP
packet, and allow Internal Hosts to receive replies to their outbound packets.
Explicit dynamic mappings are created as a result of PCP MAP requests.
Static mappings are created by manual configuration (e.g.,
command-line interface or web page).
Explicit and static mappings allow Internal Hosts to receive inbound
traffic that is not in direct response to any immediately preceeding
outbound communication (i.e. allow Internal Hosts to operate a
"server", is accessible to other hosts on the Internet).
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
which they are automatically deleted unless the lifetime is extended
by action by the Internal Host.
Static mappings differ from dynamic mappings in that their lifetime is
typically infinite (they exist until manually removed) but otherwise they
behave exactly the same as an explicit dynamic mapping with infinite lifetime.
For example, a PCP MAP request to create a mapping that already exists
as a static mapping will return a successful result, confirming that
the requested mapping exists.</t>
<t hangText="PCP Client:"><vspace blankLines="0" />A PCP software
instance responsible for issuing PCP requests to a PCP server. One
or several PCP Clients can be embedded in the same host. Several PCP
Clients can be located in the same local network.
A PCP Client can issue PCP request on behalf of a third
party device for which it is authorized to do so. An interworking function, from
UPnP IGD to PCP, or from NAT-PMP <xref
target="I-D.cheshire-nat-pmp"></xref> 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.</t>
<t hangText="PCP Server:"><vspace blankLines="0" />A network element
which receives and processes PCP requests from a PCP client.
Generally this is a PCP-capable NAT gateway or firewall. A NAT gateway
creates mappings determining how it translates packets it forwards,
and PCP enables clients to communicate with the NAT gateway about
those mappings.
In principle it is also possible for the PCP server to be some other
device, which in turn communicates with the NAT gateway using some
other network protocol, but this introduces additional complexity
and fragility into the system, and is a deployment detail which
should be implemented in a way that is invisible to the PCP client.
See also <xref target="relationship"></xref>.</t>
<t hangText="Interworking Function:"><vspace blankLines="0" />a
functional element responsible for interworking another protocol
with PCP. For example interworking between <xref target="IGD">UPnP
IGD</xref> with PCP or NAT-PMP <xref
target="I-D.cheshire-nat-pmp"></xref> and PCP.</t>
<t hangText="subscriber:"><vspace blankLines="0" />an entity
provided access to the network. In the case of a commercial ISP,
this is typically a single home.</t>
<t hangText="host:"><vspace blankLines="0" />a device which can have
packets sent to it, as a result of PCP operations. A host is not
necessarily a PCP client.</t>
<t hangText="5-tuple">The 5 pieces of information that fully
identify a flow: source IP address, destination IP address,
protocol, source port number, destination port number.</t>
</list></t>
</section>
<section anchor="relationship"
title="Relationship of PCP Server and its NAT">
<t>The PCP server receives PCP requests. The PCP server might be
integrated within the NAT or firewall device (as shown in <xref
target="diagram_pcp_server_embedded"></xref>) which is expected to be a
common deployment.</t>
<figure anchor="diagram_pcp_server_embedded"
title="NAT or Firewall with Embedded PCP Server">
<artwork align="center"><![CDATA[
+-----------------+
+------------+ | NAT or firewall |
| PCP client |-<network>-+ with +---<Internet>
+------------+ | PCP server |
+-----------------+]]></artwork>
</figure>
<t>It is also possible to operate the PCP server in a separate device
from the NAT, so long as such operation is indistinguishable from the
PCP client's perspective.</t>
</section>
<section title="Common Request and Response Header Format">
<t>All PCP messages contain a request (or response) header containing an
opcode, any relevant opcode-specific information, and zero or more
options. 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 <xref
target="map_opcodes"></xref> and <xref
target="peer_opcodes"></xref>.</t>
<section title="Request Header">
<figure align="left" anchor="common_request"
title="Common Request Packet Format">
<preamble>All requests have the following format:</preamble>
<artwork align="center"><![CDATA[
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 = 1 |R| OpCode | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Version:">This document specifies protocol version 1.
NAT-PMP, a precursor to PCP, specified protocol version 0.
Should later updates to this document specify different message
formats with a version number greater than 1, the first two
bytes of those new message formats will continue to contain the version
number and opcode as shown here, so that a PCP server receiving a
message format newer or older than the version(s) it understands
can still parse enough of the message to correctly identify the
version number, and determine whether the problem is that this
server is too old and needs to be updated to work with the PCP
client, or whether the PCP client is too old and needs to be
updated to work with this server.</t>
<t hangText="R:">Indicates Request (0) or Response (1). All
Requests MUST use 0.</t>
<t hangText="OpCode:">Opcodes are defined in <xref
target="map_opcodes"></xref> and <xref
target="peer_opcodes"></xref>.</t>
<t hangText="Reserved:">48 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Requested Lifetime:">
The Requested Lifetime field is an unsigned 32-bit integer,
in seconds, ranging from 0 to 4,294,967,295 seconds.
A lifetime of zero is used to signify a "delete" operation.
The currently-defined PCP opcodes -- MAP and PEER -- both have an
associated lifetime, and it is likely that any future opcodes will
also have a lifetime associated with them, so to simplify packet
generation and parsing, this lifetime field is stored in a fixed
location in the common request header.
If future opcodes are defined that do not have a natural lifetime
associated with them, then for these opcodes the Requested Lifetime
MUST be set to zero on transmission and MUST be ignored on reception.</t>
</list></t>
</section>
<section title="Response Header">
<figure align="left" anchor="common_response"
title="Common Response Packet Format">
<preamble>All responses have the following format:</preamble>
<artwork align="center"><![CDATA[
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 = 1 |R| OpCode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) OpCode-specific response data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Version:">Responses MUST use version 1.</t>
<t hangText="R:">Indicates Request (0) or Response (1). All
Responses MUST use 1.</t>
<t hangText="OpCode:">The OpCode value, copied from the
request.</t>
<t hangText="Reserved:">8 reserved bits, MUST be sent as 0, MUST
be ignored when received. This is set by the server.</t>
<t hangText="Result Code:">The result code for this response. See
<xref target="result_codes"></xref> for values. This is set by the
server.</t>
<t hangText="Lifetime:">
The Lifetime field is an unsigned 32-bit integer,
in seconds, ranging from 0 to 4,294,967,295 seconds.
On an error response, this indicates how long clients should assume
they'll get the same error response from the that PCP server if they
repeat the same request.
On a success response for the currently-defined PCP opcodes -- MAP
and PEER -- this indicates the lifetime for this mapping.
To simplify packet generation and parsing, this lifetime field
is stored in a fixed location in the common response header.
If future opcodes are defined that do not have a lifetime associated
with them, then in success responses for these opcodes the Lifetime
MUST be set to zero on transmission and MUST be ignored on reception.</t>
<t hangText="Epoch:">The server's Epoch value. See <xref
target="epoch"></xref> for discussion. This value is set in both
success and error responses.</t>
</list></t>
</section>
<section anchor="pcp_information_elements" title="Options">
<t>A PCP OpCode can be extended with an Option. Options can be used in
requests and responses. The decision about whether to include a given
piece of information in the base opcode format or in an option is 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 that field is
all-zeroes 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 compliated 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.</t>
<figure align="left" anchor="options-layout" title="Options Header">
<preamble>Options use the following Type-Length-Value
format:</preamble>
<artwork align="center"><![CDATA[
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The description of the fields is as follows:<list style="hanging">
<t hangText="Option Code:">Option code, 8 bits. The first bit of
the option code is the "O" (optional) bit. If clear, it indicates
the option is mandatory to process (that is, non-optional). If
set, it indicates the option is optional.</t>
<t hangText="Reserved:">MUST be set to 0 on transmission and MUST
be ignored on reception.</t>
<t hangText="Option-Length:">Indicates the
length of the enclosed data in octets. Options with length of 0 are
allowed.</t>
<t hangText="data:">Option data. The option data MUST end on a 32-bit
boundary, padded with 0's when necessary.</t>
</list></t>
<t>A given Option MAY be included in a request containing a
specific OpCode. The handling of an Option by the PCP client
and PCP server MUST be specified in an appropriate document
and must include whether the PCP Option can appear (one or
more times) in a request, and indicate the contents of the
Option in the request and in the response. If several Options
are included in a PCP request or response, they MUST be
encoded in numeric order by the PCP client and are processed
in the order received. The server MUST reject requests that
have mis-ordered options with the MISORDERED_OPTIONS error,
and this also includes checking optional-to-process options.
</t>
<t>If, while processing an option, an error is encountered that causes
a PCP error response to be generated, the PCP request causes no state
change in the PCP server or the PCP-controlled device (i.e., it rolls
back any changes it might have made while processing the request). The
response MUST encode the Options in the same order, but may omit some
PCP Options in the response, as is necessary to indicate the PCP
server does not understand that Option or that Option is not permitted
to be included in responses by the definition of the Option itself.
Additional Options included in the response (if any) MUST be included
at the end. A certain Option MAY appear more than once in a request or
in a response, if permitted by the definition of the Option itself. If
the Option's definition allows the Option to appear only once but it
appears more than once in a request, the PCP server MUST respond with
the MALFORMED_OPTION result code; if this occurs in a response, the
PCP client processes the first occurrence and ignores the other
occurrences as if they were not present.</t>
<t>If the "O" bit in the OpCode is clear, <list style="symbols">
<t>the PCP server MUST only generate a positive PCP response if it
can successfully process the PCP request and this Option.</t>
<t>if the PCP server does not implement this Option, or cannot
perform the function indicated by this Option (e.g., due to a
parsing error with the option), it MUST generate a failure
response with code UNSUPP_OPTION or MALFORMED_OPTION (as
appropriate) and include the UNPROCESSED option in the response
(<xref target="unprocessed"></xref>).</t>
</list></t>
<t>If the "O" bit is set, the PCP server MAY process or ignore this
Option, entirely at its discretion.</t>
<t>Option definitions MUST include the information below:</t>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>name: <mnemonic></t>
<t>number: <value></t>
<t>purpose: <textual description></t>
<t>is valid for OpCodes: <list of OpCodes></t>
<t>length: <rules for length></t>
<t>may appear in: <requests/responses/both></t>
<t>maximum occurrences: <count></t>
</list></t>
</list></t>
</section>
<section anchor="result_codes" title="Result Codes">
<t>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 has encountered
multiple errors during processing of a request, it SHOULD use the most
specific error message.<list style="hanging">
<t hangText="0">SUCCESS, success</t>
<t hangText="1">UNSUPP_VERSION, unsupported version.</t>
<t hangText="2">MALFORMED_REQUEST, a general catch-all error.</t>
<t hangText="3">UNSUPP_OPCODE, unsupported OpCode.</t>
<t hangText="4">UNSUPP_OPTION, unsupported Option. This error only
occurs if the Option is in the mandatory-to-process range.</t>
<t hangText="5">MALFORMED_OPTION, malformed Option (e.g., exists
too many times, invalid length).</t>
<t hangText="6">UNSPECIFIED_ERROR, server encountered unspecified
error.</t>
<t hangText="7">MISORDERED_OPTIONS, multiple options were in the
request, but were not in the required lower..higher order.</t>
</list></t>
<t>Additional result codes, specific to the OpCodes and Options
defined in this document, are listed in <xref
target="map_result_codes"></xref>, <xref
target="peer_result_codes"></xref>, and <xref
target="third_party"></xref>.</t>
</section>
</section>
<section title="General PCP Operation">
<t>PCP messages MUST be sent over UDP. Every PCP request generates a
response, so PCP does not need to run over a reliable transport
protocol.</t>
<t>PCP is idempotent, so if the PCP client sends the same request
multiple times and the PCP server processes those requests, the same
result occurs. The order of operation is that a PCP client generates and
sends a request to the PCP server, which processes the request and
generates a response back to the PCP client.</t>
<section title="General PCP Client: Generating a Request">
<t>This section details operation specific to a PCP client, for any
OpCode. Procedures specific to the MAP OpCodes are described in <xref
target="map_opcodes"></xref>, and procedures specific to the PEER
OpCodes are described in <xref target="peer_opcodes"></xref>.</t>
<t>Prior to sending its first PCP message, the PCP client determines
which servers to use. The PCP client performs the following steps to
determine its PCP server(s):<list style="numbers">
<t>if a PCP server is configured (e.g., in a configuration file or
DHCP), that single configuration source is used as the list of PCP
server(s), else;</t>
<t>the address of the default router is used as the PCP
server.</t>
</list></t>
<t>[[[[The following text needs further review and consensus.
<list style="empty">
<t>With that list of PCP servers, the PCP client formulates
its PCP request. The PCP request contains a PCP common header,
PCP OpCode and payload, and (possibly) Options. As with all
UDP or TCP clients on any operating system, when several PCP
clients are embedded in the same host, each uses a distinct
source port number to disambiguate their requests and replies.
The PCP client's source port SHOULD be randomly
generated <xref target="RFC6056"></xref>.</t>
<t>The PCP client initializes a timer to 2 seconds. The PCP client
sends a PCP message the first server in the list. If no response is
received before the timer expires, the timer is doubled (to 4 seconds)
and the request is re-transmitted. If no response is received before
the timer expires, the timer is doubled again (to 8 seconds) and the
request is re-transmitted. If still no response is received, PCP
client re-initializes its timer to 2 seconds, and repeats the
procedure with the next PCP server on its list. This is repeated until
a response is received or the until list of PCP servers is
exhausted.</t>
<t>Once a PCP client has successfully communicated with a PCP server,
it initializes its retransmission timer to 2 seconds. The PCP client
ontinues communicating with that PCP server until a response is not
received before the timer expires. When that occurs, the PCP client
doubles its timer, and re-transmits the request.</t>
</list></t>
<t>]]]]</t>
<t>If, during its communication with the PCP server, the PCP client
receives a hard ICMP error
(<xref target="RFC5461"></xref> Section 2),
the PCP client SHOULD immediately abort trying to contact that PCP server,
initialize its retransmission timer, and try communicating
with the next PCP server on its list. </t>
<t>Upon receiving a response (success or error), the PCP client does
not change to a different PCP server. That is, it does not "shop
around" trying to find a PCP server to service its (same) request.</t>
</section>
<section title="General PCP Server: Processing a Request">
<t>This section details operation specific to a PCP server.</t>
<t>A PCP server processes incoming requests on the PCP port
from clients or an operator-configured interface (e.g., from
the ISP's network operations center). The PCP server MUST
drop (ignore) requests that arrive from elsewhere (e.g., the
Internet).</t>
<t>Upon receiving a message, the PCP server parses and validates it. A
valid request contains a valid PCP common header, one valid PCP
Opcode, and zero or more Options (which the server might or might not
comprehend). If an error is encountered during processing, the server
generates an error response which is sent back to the PCP client.
Processing an OpCode and the Options are specific to each OpCode.</t>
<t>If the received message is shorter than 4 octets, has the R bit
set, or the first bit is clear, the message is simply dropped. If the
version number is not supported, a response is generated containing
the UNSUPP_VERSION result code and the protocol version which the
server does understand (if the server understands a range of protocol
versions then it returns the supported version closest to the version
in the request). Version negotiation is detailed in <xref
target="version"></xref>.</t>
<t>If the OpCode is not supported, a response is generated with the
UNSUPP_OPCODE result code. If the length of the request exceeds 1024
octets or is not a multiple of 4 octets, it is invalid. Invalid
requests are handled by copying up to 1024 octets of the request into
the response, setting the result code to MALFORMED_REQUEST, and
zero-padding the response to a multiple of 4 octets if necessary.</t>
<t>Error responses have the same packet layout as success responses,
with fields copied from the request copied into the response, and
other fields assigned by the PCP server MUST be cleared to 0.</t>
</section>
<section title="General PCP Client: Processing a Response">
<t>The PCP client receives the response and verifies the source IP
address and port belong to the PCP server of an outstanding request.
It validates the version number and OpCode matches an outstanding
request. Responses shorter than 12 octets, longer than 1024 octets, or
not a multiple of 4 octets are invalid and ignored, likely causing the
request to be re-transmitted. The response is further matched by
comparing fields in the response OpCode-specific data to fields in the
request OpCode-specific data. After a successful match with an
outstanding request, the PCP client checks the Epoch field to
determine if it needs to restore its state to the PCP server (see
<xref target="epoch"></xref>).</t>
<t>If the result code is 0, the PCP client knows the request was
successful.</t>
<t>If the result code is not 0, the request failed. If the result code
is UNSUPP_VERSION, processing continues as described in <xref
target="version"></xref>. If the result code is SERVER_OVERLOADED,
clients SHOULD NOT send *any* further requests to that PCP server for
the indicated error lifetime. For other error result codes, The PCP
client SHOULD NOT resend the same request for the indicated error lifetime.
If a PCP server indicates an error lifetime in excess of 30 minutes,
A PCP client MAY choose to set its retry timer to 30 minutes.</t>
<t>If the PCP client has discovered a new PCP server (e.g., connected
to a new network), the PCP client MAY immediately begin communicating
with this PCP server, without regard to hold times from communicating
with a previous PCP server.</t>
</section>
<section anchor="mif" title="Multi-Interface Issues">
<t>Hosts which desire a PCP mapping might be multi-interfaced (i.e.,
own several logical/physical interfaces). Indeed, a host can be
configured with several IPv4 addresses (e.g., WiFi and Ethernet) or
dual-stacked. These IP addresses may have distinct reachability scopes
(e.g., if IPv6 they might have global reachability scope as for GUA
(Global Unicast Address) or limited scope such as ULA (Unique Local
Address, <xref target="RFC4193"></xref>)).</t>
<t>IPv6 addresses with global reachability scope SHOULD be used as the
source interface when generating a PCP request. IPv6 addresses with
limited scope (e.g., <xref target="RFC4193">ULA</xref>), SHOULD NOT be
used as the source interface when generating a PCP request. If <xref
target="RFC4941">IPv6 privacy addresses</xref> are used for PCP
mappings, a new PCP request will need to be issued whenever the IPv6
privacy address is changed. This PCP request SHOULD be sent from the
IPv6 privacy address itself. It is RECOMMENDED that mappings to the
previous privacy address be deleted.</t>
<t>A host might gain or lose interfaces while existing
mappings are active (e.g., Ethernet cable plugged in or
removed, joining/leaving a WiFi network). Because of this, if
the PCP client is sending a PCP request to maintain state in
the PCP server, it SHOULD ensure those PCP requests continue
to use the same interface (e.g., when refreshing mappings). If
the PCP client is sending a PCP request to create new state in
the PCP server, it MAY use a different source interface or
different source address.</t>
<t>Due to the ubiquity of IPv4 NAT, IPv4 addresses with
limited scope (e.g., <xref target="RFC1918">private
addresses</xref>) MAY be used as the source interface when
generating a PCP request.</t>
<t>As mentioned in <xref target="single_homed"></xref>, only
single-homed CP routers are in scope. Therefore, there is no viable
scenario where a host located behind a CP router is assigned with two
GUA addresses belonging to different global IPv6 prefixes.</t>
<!--
Section 2.4, "Change of the Internal IP Address"
When a new IP address is assigned to a host embedding a PCP Client,
the PCP Client MUST install on the PCP server all the mappings it
manages, using the new assigned IP address as the internal IP
address.
This needs some additional discussion. Let's take an example where
I have a computer with both WiFi and wired Ethernet connections
and I plug and unplug the Ethernet connection, or go in and out
of range of WiFi. When do we want PCP to do something about
that change of connectivity? Does the answer depend on IPv4,
IPv6, or dual stack running on that interface if we're doing PIN44,
PIN64, PIN46, PIN66?
Med: Good point. IMHO, the address selection should be done according to the-be-completed section: http://tools.ietf.org/html/draft-ietf-pcp-base-02#section-6.1.3. Based on the output of that process, the PCP Client can be triggered accordingly.
Or ... just recommend the internal IP address not be changed!
-->
</section>
<section anchor="epoch" title="Epoch">
<t>Every PCP response sent by the PCP server includes an Epoch field.
This field increments by 1 every second, and is used by the PCP
client to determine if PCP state needs to be restored. If the PCP server resets or
loses the state of its explicit dynamic Mappings (that is, those
mappings created by PCP MAP requests), due to reboot, power failure,
or any other reason, it MUST reset its Epoch time to 0. Similarly, if
the public IP address(es) of the NAT (controlled by the PCP server)
changes, the Epoch MUST be reset to 0. A PCP server MAY maintain one
Epoch value for all PCP clients, or MAY maintain distinct Epoch values
for each PCP client; this choice is implementation-dependent.</t>
<t>Whenever a client receives a PCP response, the client computes its
own conservative estimate of the expected Epoch value by taking the
Epoch value in the last packet it received from the gateway and adding
7/8 (87.5%) of the time elapsed since that packet was received. If the
Epoch value in the newly received packet is less than the client's
conservative estimate by more than one second, then the client
concludes that the PCP server lost state, and the client MUST
immediately renew all its active port mapping leases as described in
<xref target="reboot"></xref>.</t>
<t>When the PCP server reduces its Epoch value, the PCP clients will
send PCP requests to refresh their mappings. The PCP server needs to
be scaled appropriately to accomodate this traffic. Because PCP lacks
a mechanism to simultaneously inform all PCP clients of the Epoch
value, the PCP clients will not flood the PCP server simultaneously
when the PCP server reduces its Epoch value.</t>
<t>In the time between a PCP server loses state and the PCP client
notices the lower-than-expected Epoch 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. A mechanism to
immediately inform the PCP client of state loss would reduce this
interval, but would not eliminate this threat. The PCP client can
reduce this interval by using a relatively short lifetime; however,
this increases the amount of PCP chatter. The use of connection
authentication between peers (e.g., TLS), or persistent storage of
mappings in the PCP server (so it doesn't lose state) eliminates
this threat.</t>
</section>
<section anchor="version" title="Version negotiation">
<t>A PCP client sends its requests using PCP version number 1. Should
later updates to this document specify different message formats with
a version number greater than 1 it is expected that PCP servers
will still support version 1 in addition to the newer version(s).
However, in the event that a server returns a response with error code
UNSUPP_VERSION, the client MAY log an error message to inform the user
that it is too old to work with this server, and the client SHOULD set
a timer to retry its request in 30 minutes (in case this was a
temporary condition and the server configuration is changed to rectify
the situation).</t>
<t>If future PCP versions greater than 1 are specified, version
negotiation is expected to proceed as follows: <list style="numbers">
<t>If a client or server supports more than one version it SHOULD
support a contiguous range of versions -- i.e., a lowest version
and a highest version and all versions in between.</t>
<t>Client sends first request using highest (i.e., presumably
'best') version number it supports.</t>
<t>If server supports that version it responds normally.</t>
<t>If server does not support that version it replies giving a
result containing the error code UNSUPP_VERSION, and the closest
version number it does support (if the server supports a range of
versions higher than the client's requested version, the server
returns the lowest of that supported range; if the server supports
a range of versions lower than the client's requested version, the
server returns the highest of that supported range).</t>
<t>If the client receives an UNSUPP_VERSION result containing a
version it does support, it records this fact and proceeds to use
this message version for subsequent communication with this PCP
server (until a possible future UNSUPP_VERSION response if the
server is later updated, at which point the version negotiation
process repeats).</t>
<t>If the client receives an UNSUPP_VERSION result containing a
version it does not support then the client MAY log an error
message to inform the user that it is too old to work with this
server, and the client SHOULD set a timer to retry its request in
30 minutes.</t>
</list></t>
</section>
<section title="General PCP Options">
<t>The following options can appear in certain PCP responses.</t>
<section anchor="unprocessed" title="UNPROCESSED">
<t>If the PCP server cannot process a mandatory-to-process
option, for whatever reason, it includes the UNPROCESSED
Option in the response, shown
in <xref target="fig_unprocessed"></xref>. This helps with
debugging interactions between the PCP client and PCP
server. This option MUST NOT appear more than once in a PCP
response. The unprocessed options are listed once, and
the option data is zero-filled to the necessary 32 bit boundary.
If a certain Option appeared more than once in the PCP
request, that Option value only appears once in the
option-code fields. The order of the Options in the PCP
request has no relationship with the order of the Option
values in this UNPROCESSED Option. This Option MUST NOT
appear in a response unless the associated request contained
at least one mandatory-to-process Option.</t>
<figure anchor="fig_unprocessed" title="UNPROCESSED option">
<preamble>The UNPROCESSED option is formatted as follows,
showing an example of two option codes that were
unprocessed:</preamble>
<artwork align="center"><![CDATA[
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-1 | option-code-2 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>name: UNPROCESSED</t>
<t>number: 1</t>
<t>purpose: indicates which PCP options in the request are
not supported by the PCP server</t>
<t>is valid for OpCodes: all</t>
<t>length: 1 or more</t>
<t>may appear in: responses, and only if the result code is
non-zero.</t>
<t>maximum occurrences: 1</t>
</list></t>
</list></t>
</section>
</section>
</section>
<section anchor="opcode_introduction"
title="Introduction to MAP and PEER OpCodes">
<t>There are three uses for the MAP and PEER OpCodes defined in this
document: a host operating a server (and wanting an incoming
connection), a host operating a client (and wanting to optimize the
application keepalive traffic), and a host operating a client and server
on the same port. These are discussed in the following sections.</t>
<t>When operating a server (<xref target="operating_a_server"></xref>
and <xref target="pcp_symmetric"></xref>) the PCP client knows if it
wants an IPv4 listener, IPv6 listener, or both on the Internet. The PCP
client also knows if it has an IPv4 interface on itself or an IPv6
interface on itself. It takes the union of this knowledge to decide to
send a one or two MAP requests for each of its interfaces. Applications
that embed IP addresses in payloads (e.g., FTP, SIP) will find it
beneficial to avoid address family translation, if possible.</t>
<!--
<t>On many common platforms (i.e., those making use of the BSD sockets
API), using PCP for purposes of application keepalives by issuing a
PCP request followed by a dynamic connection to the server is
difficult to implement properly. This is therefore NOT RECOMMENDED.
Instead, client applications SHOULD first establish a dynamic
connection to a server, and then issue a PCP request related to that
connection, including the REMOTE_PEER option.</t>
-->
<section anchor="operating_a_server" title="For Operating a Server">
<t>A host operating a server (e.g., a web server) listens for traffic
on a port, but the server never initiates traffic from that port. For
this to work across a NAT or a firewall, the application needs to (a)
create a mapping from a public IP address and port to itself as
described in <xref target="map_opcodes"></xref> and (b) publish that
public IP address and port via some sort of rendezvous server (e.g.,
DNS, a SIP message, a proprietary protocol). Publishing the public IP
address and port is out of scope of this specification. To accomplish
(a), the application follows the procedures described in this
section.</t>
<t>As normal, the application needs to begin listening to a port, and
to ensure that it can get exclusive use of that port it needs to
choose a port that is not in the operating system's ephemeral port
range. Then, the application constructs a PCP message with the
appropriate MAP OpCode depending on if it is listening on an IPv4 or
IPv6 interface and if it wants a public IPv4 or IPv6 address.</t>
<figure anchor="fig_operate_server"
title="Pseudo-code for using PCP to operate a server">
<preamble>The following pseudo-code shows how PCP can be reliably
used to operate a server:</preamble>
<artwork align="center"><![CDATA[
/* start listening on the local server port */
int s = socket(...);
internal_sockaddr = ...;
bind(s, &internal_sockaddr, ...);
listen(s, ...);
requested_external_sockaddr = 0;
pcp_send_map_request(internal_sockaddr,
requested_external_sockaddr, &assigned_external_sockaddr,
requested_lifetime, &assigned_lifetime);
update_rendezvous_server("Client 12345", assigned_external_sockaddr);
while (1) {
int c = accept(s, ...);
/* ... */
}]]></artwork>
</figure>
</section>
<section anchor="keepalives" title="For Reducing NAT Keepalive Messages">
<t>A host operating a client (e.g., XMPP client, SIP client) sends
from a port but never accepts incoming connections on this port. It
wants to ensure the flow to its server is not terminated (due to
inactivity) by an on-path NAT or firewall. To accomplish this, the
applications uses the procedure described in this section.</t>
<t>Middleboxes such as NATs or firewalls need to see occasional
traffic or will terminate their session state, causing application
failures. To avoid this, many applications routinely generate
keepalive traffic for the primary (or sole) purpose of maintaining
state with such middleboxes. Applications can reduce such application
keepalive traffic by using PCP. <list style="empty">
<t>Note: For reasons beyond NAT, an application may find it useful
to perform application-level keepalives, such as to detect a
broken path between the client and server, detect a crashed
server, or detect a powered-down client. These keepalives are not
related to maintaining middlebox state, and PCP cannot do anything
useful to reduce those keepalives.</t>
</list></t>
<t>To use PCP for this function, the applications first connects to
its server, as normal. Afterwards, it issues a PCP request with the
PEER4 or PEER6 OpCode as described in <xref
target="peer_opcodes"></xref>. The PEER4 OpCode is used if the host is
using IPv4 for its communication to its peer; PEER6 if using IPv6. The
same 5-tuple as used for the connection to the server is placed into
the PEER4 or PEER6 payload.</t>
<figure anchor="fig_keepalive_pseudocode"
title="Pseudo-code using PCP with a dynamic socket">
<preamble>The following pseudo-code shows how PCP can be reliably
used with a dynamic socket, for the purposes of reducing application
keepalive messages:</preamble>
<artwork align="center"><![CDATA[
int s = socket(...);
connect(s, &remote_peer, ...);
getsockname(s, &internal_address, ...);
external_address = 0;
pcp_send_peer_request(internal_address,
requested_external_address, &assigned_external_address,
remote_peer, requested_lifetime, &assigned_lifetime);
]]></artwork>
</figure>
</section>
<section anchor="pcp_symmetric"
title="For Operating a Symmetric Client/Server">
<t>A host operating a client and server on the same port
(e.g., <xref target="RFC4961">Symmetric RTP</xref>
or <xref target="RFC3581">SIP Symmetric Response Routing
(rport)</xref>) first establishes a local listener, (usually)
sends the local and public IP addresses and ports to a
rendezvous service (which is out of scope of this document),
and initiates an outbound connection from that same source
address and same port. To accomplish this, the application
uses the procedure described in this section.</t>
<t>An application that is using the same port for outgoing connections
as well as incoming connections MUST first signal its operation of a
server using the PCP MAP OpCode, as described in <xref
target="map_opcodes"></xref>, and receive a positive PCP response
before it sends any packets from that port. <list style="empty">
<t>Discussion: Although reversing those steps is tempting (to
eliminate the PCP round trip before a packet can be sent from that
port) and will work if the NAT has endpoint-independent mappings
(EIM) behavior, reversing the steps will fail if the NAT does not
have EIM behavior. With a non-EIM NAT, the implicit mapping
created by an outgoing TCP SYN and the explicit mapping created
using the MAP OpCode will cause different ports to be assigned
(which is not desirable; after all, the application is using the
same port for outgoing and incoming traffic on purpose) and they
will generally also have different lifetimes. PCP does not attempt
to change or dictate how a NAT creates its mappings (endpoint
independent mapping, or otherwise) so there is no assurance that
an implicit mapping will be EIM or non-EIM. Thus, it is necessary
for applications to first signal its operation of a server using
the PCP MAP OpCode.</t>
</list></t>
<!--
<list style="empty">
<t>[[Ed. Note: And also reversing the steps is complex and
fragile. Do we want to additionally mention the fragility? I
think we don't need to mention the fragility. Reference
http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html.]]</t>
</list></t>
-->
<figure anchor="fig_pseudocode_symmetric"
title="Pseudo-code for using PCP to operate a symmetric client/server">
<preamble>The following pseudo-code shows how PCP can be used to
operate a symmetric client and server:</preamble>
<artwork align="center"><![CDATA[
/* start listening on the local server port */
int s = socket(...);
internal_sockaddr = ...;
bind(s, &internal_sockaddr, ...);
listen(s, ...);
requested_external_sockaddr = 0;
pcp_send_map_request(internal_sockaddr,
requested_external_sockaddr, &assigned_external_sockaddr,
requested_lifetime, &assigned_lifetime);
update_rendezvous_server("Client 12345", assigned_external_sockaddr);
send_packet(s, "Hello World");
while (1) {
int c = accept(s, ...);
/* ... */
}
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<section anchor="map_opcodes" title="MAP OpCodes">
<t>This section defines two OpCodes which control forwarding from a NAT
(or firewall) to an internal host. They are: <list
hangIndent="11" style="hanging">
<t hangText=" MAP4=1:">create a mapping between an internal
address and external IPv4 address (e.g., NAT44, NAT64, or
firewall)</t>
<t hangText=" MAP6=2:">create a mapping between an internal target
address and external IPv6 address (e.g., NAT46, NAT66, or
firewall)</t>
</list></t>
<t>The internal address is the source IP address of the PCP
request message itself, unless the THIRD_PARTY option is used.</t>
<t>The operation of these OpCodes is described in this section.</t>
<section title="OpCode Packet Formats">
<t>The two MAP OpCodes (MAP4, MAP6) share a similar packet layout for
both requests and responses. Because of this similarity, they are
shown together. For both of the MAP OpCodes, if the assigned external
IP address and assigned external port match the request's
Internal IP address and port, the functionality is
purely a firewall; otherwise it pertains to a network address
translator which might also perform firewall-like functions.</t>
<figure anchor="pin_request" title="MAP OpCode Request Packet Format">
<preamble>The following diagram shows the request packet format for
MAP4 and MAP6. This packet format is aligned with the response
packet format:</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal port | Suggested external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Suggested External IP Address (32 or 128, depending on OpCode):
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Requested lifetime (in common header):">
Requested lifetime of this
mapping, in seconds. The value 0 indicates "delete".</t>
<t hangText="Protocol:">indicates protocol associated with this
OpCode. Values are taken from the <xref
target="proto_numbers">IANA protocol registry</xref>. For example,
this field contains 6 (TCP) if the opcode is intended to create a
TCP mapping. The value 0 has a special meaning for 'all
protocols', and is used only for delete requests. This means that
HOPOPT (which is assigned by IANA as protocol 0) cannot have a
mapping deleted by PCP.</t>
<t hangText="Reserved:">24 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Internal port:">Internal port for the mapping. The
value 0 indicates "all ports", and is only legal in a request if
lifetime=0.</t>
<t hangText="Suggested external port:">suggested external port for
the mapping. This is useful for refreshing a mapping, especially
after the PCP server loses state. If the PCP server can fulfill
the request, it will do so. If the PCP client does not know the
external port, or does not have a preference, it uses 0.</t>
<t hangText="Suggested External IP Address:">Suggested external IP
address. This is useful for refreshing a mapping, especially after
the PCP server loses state. If the PCP server can fulfill the
request, it will do so. If the PCP client does not know the
external address, or does not have a preference, it MUST use
0.</t>
</list></t>
<figure anchor="pin_response"
title="MAP OpCode Response Packet Format">
<preamble>The following diagram shows the response packet format for
MAP4 and MAP6 OpCodes:</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Assigned External IP Address (32 or 128, depending on OpCode) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Lifetime (in common header):">
On a success response, this indicates the lifetime for this mapping,
in seconds. On an error response, this indicates how long clients
should assume they'll get the same error response from the that PCP
server if they repeat the same request.</t>
<t hangText="Protocol:">Copied from the request</t>
<t hangText="Reserved:">24 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Assigned External IP Address:">On success responses,
this is the assigned external IPv4 or IPv6 address for the
mapping; IPv4 or IPv6 address is indicated by the OpCode. On error
responses, this MUST be 0.</t>
<t hangText="Internal Port:">Internal port for the mapping, copied
from request.</t>
<t hangText="Assigned External Port:">On success responses, this
is the assigned external port for the mapping. If the NAT gateway can
allocate the suggested external port it SHOULD do so. This is
beneficial for re-establishing state lost when a NAT gateway fails
or loses its state due to reboot. If the NAT gateway cannot
allocate the suggested external port but can allocate some other
port, it MUST do so and return the allocated port in the response.
Cases where a NAT gateway cannot allocate the suggested external
port include:
<list style='symbols'>
<t>Where the suggested external port is already allocated
to another existing explicit, implicit, or static mapping,
already forwarding traffic to some other internal address:port.</t>
<t>Where the suggested external port is already used by the NAT
gateway for one of its own services (e.g., port 80 for the NAT
gateway's own configuration pages)</t>
<t>When the suggested external port is otherwise prohibited by the
NAT gateway's policy</t>
</list></t>
<t>On error responses, the Assigned External Port MUST be 0.</t>
</list></t>
</section>
<section anchor="map_result_codes" title="OpCode-Specific Result Codes">
<t>In addition to the general PCP result codes (<xref
target="result_codes"></xref>), the following additional result codes
may be returned as a result of the four MAP OpCodes received by the
PCP server. These errors are considered 'long lifetime' or 'short
lifetime', 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 30 second lifetime and long lifetime errors
use 30 minute lifetime.<list style="hanging">
<t hangText="19">SERVER_OVERLOADED, server is processing too many
MAP requests from this client or from other clients, and requests
this client delay sending other requests. This is a short lifetime
error.</t>
<t hangText="20">NETWORK_FAILURE, PCP server or the device it
controls are experiencing a network failure of some sort (e.g.,
has not obtained an IP address). This is a short lifetime
error.</t>
<t hangText="21">NO_RESOURCES, e.g., NAT device cannot create more
mappings at this time. This is a system-wide error, and different
from USER_EX_QUOTA. This is a short lifetime error.</t>
<t hangText="22">UNSUPP_PROTOCOL, unsupported Protocol. This is a
long lifetime error.</t>
<t hangText="23">NOT_AUTHORIZED, e.g., PCP server supports
mapping, but the feature is disabled for this PCP client, or the
PCP client requested a mapping that cannot be fulfilled by the PCP
server's security policy. This is a long lifetime error.</t>
<t hangText="24">USER_EX_QUOTA, mapping would exceed user's port
quota. This is a short lifetime error.</t>
<t hangText="25">CANNOT_PROVIDE_EXTERNAL_PORT, indicates the port
is already in use (e.g. already allocated to a previous PCP client)
or otherwise unavailable (e.g., special port
that cannot be allocated by the server's policy). This error is
only returned if the request included the Option PREFER_FAILURE.
This is a short lifetime error.</t>
<t hangText="26">EXCESSIVE_REMOTE_PEERS, indicates 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
REMOTE_FILTER Option. This is a long lifetime error. This only
occurs with the REMOTE_FILTER option.</t>
<t hangText="27">IMPLICIT_MAPPING_EXISTS, indicates a MAP request was
received for a port that already has an implicit mapping.</t>
</list></t>
<t>Additional result codes may be returned if the THIRD_PARTY option
is used, see <xref target="third_party"></xref>.</t>
</section>
<section anchor="pin-opcode_client_operation"
title="OpCode-Specific Client: Generating a Request">
<t>This section describes the operation of a PCP client when sending
requests with OpCodes MAP4 and MAP6.</t>
<t>The request MAY contain values in the suggested-external-ip-address
and suggested-external-port fields. This allows the PCP client to
attempt to rebuild the PCP server's state, so that the PCP client
could avoid having to change information maintained at the rendezvous
server. Of course, due to other activity on the network (e.g., by
other users or network renumbering), the PCP server may not be able to
fulfill the request.</t>
<t>An existing mapping can have its lifetime extended by the PCP client.
To do this, the PCP client sends a new MAP request indicating the
internal port. The PCP MAP request SHOULD also include the currently
allocated external IP address and port as the suggested external IP
address and port, so that if the NAT gateway has lost state it can
recreate the lost mapping with the same parameters.</t>
<t>The PCP client SHOULD renew the mapping before its expiry time,
otherwise it will be removed by the PCP server (see <xref
target="lifetime"></xref>). In order to prevent excessive PCP chatter,
it is RECOMMENDED to send a single renewal request packet when a
mapping is halfway to expiration time, then, if no SUCCESS result is
received, another single renewal request 3/4 of the way to expiration
time, and then another at 7/8 of the way to expiration time, and so
on, subject to the constraint that renewal requests MUST NOT be sent
less than four seconds apart (a PCP client MUST NOT send an infinite
number of ever-closer-together requests in the last few seconds before
a mapping expires).</t>
</section>
<section anchor="map-opcode_server_operation"
title="OpCode-Specific Server: Processing a Request">
<t>This section describes the operation of a PCP server when
processing a request with the OpCodes MAP4 or MAP6.</t>
<t>If the server is overloaded by requests (from a particular client
or from all clients), it MAY simply discard requests, as the requests
will be retried by PCP clients, or MAY generate the SERVER_OVERLOADED
error response, or both.</t>
<t>If the request contains internal-port=0 and the lifetime is
non-zero, the server MUST generate a MALFORMED_REQUEST error.</t>
<t>If the requested lifetime is not zero, it indicates a request to
create a mapping or extend the lifetime of an existing mapping.</t>
<t>Processing of the lifetime is described in <xref
target="lifetime"></xref>.</t>
<t>If the PCP-controlled device is stateless (that is, it does not
establish any per-flow state, and simply rewrites the address and/or
port in a purely algorithmic fashion), the PCP server simply returns
an answer indicating the external IP address and port yielded by this
stateless algorithmic translation. This allows the PCP client to learn
its external IP address and port as seen by remote peers. Examples of
stateless translators include stateless NAT64 and 1:1 NAT44, both of
which modify addresses but not port numbers.</t>
<t>If an Option with value less than 128 exists (i.e. mandatory to process)
but that option does not make sense (e.g., the PREFER_FAILURE option is
included in a request with lifetime=0), the request is invalid and
generates a MALFORMED_OPTION error.</t>
<!--
<t>If the REMOTE_PEER option is not included in the request and it is
impossible for the PCP-controlled device to establish a mapping
because a conflicting dynamic mapping already exists, the PCP server
responds with the error AMBIGUOUS (this is due to interactions with
dynamic mappings, see <xref target="dynamic-interaction"></xref>).</t>
-->
<t>By default, a PCP-controlled device MUST NOT create mappings for a
protocol not indicated in the request. For example, if the request was
for a TCP mapping, a UDP mapping MUST NOT be created.</t>
<t>If the THIRD_PARTY option is not present in the request, the source
IP address of the PCP packet is used when creating the mapping. If the
THIRD_PARTY option is present, the PCP server validates that the client
is authorized to make mappings on behalf of the indicated
internal IP address. This validation
depends on the PCP deployment scenario; see <xref
target="subscriber_identification"></xref> for the validation
procedure. If the internal IP address in the PCP request is not
authorized to make mappings on behalf of the indicated
internal IP address, an error response MUST be generated with
result code NOT_AUTHORIZED.</t>
<t>Mappings typically consume state on the PCP-controlled device, and
it is RECOMMENDED that a per-subscriber or per-host limit be enforced
by the PCP server to prevent exhausting the mapping state. If this
limit is exceeded, the result code USER_EX_QUOTA is returned.</t>
<t>If all of the proceeding operations were successful (did not
generate an error response), then the requested mappings are created
or refreshed
as described in the request and a SUCCESS response is built. This
SUCCESS response contains the same OpCode as the request, but with the
"R" bit set.</t>
<t>As a side-effect of creating a mapping, ICMP messages associated
with the mapping MUST be forwarded (and also translated, if
appropriate) for the duration of the mapping's lifetime. This is done
to ensure that ICMP messages can still be used by hosts, without
application programmers or PCP client implementations needing to
signal PCP separately to create ICMP mappings for those flows.</t>
</section>
<section title="OpCode-Specific Client: Processing a Response">
<t>This section describes the operation of the PCP client when it
receives a PCP response for the OpCodes MAP4 or MAP6.</t>
<t>A response is matched with a request by comparing the protocol,
internal IP address, and internal port. Other fields are not compared,
because the PCP server sets those fields.</t>
<t>If a successful response, the PCP client can use the external IP
address and port(s) as desired. Typically the PCP client will
communicate the external IP address and port(s) to another host on the
Internet using an application-specific rendezvous mechanism such as
DNS SRV records.</t>
<t>If the result code is IMPLICIT_MAPPING_EXISTS, it indicates the PCP
client is attempting to use MAP when an implicit dynamic connection
already exists for the same internal host and internal port. This can
occur with certain types of NATs. When this is received, if the PCP
client still wants to establish a mapping, the PCP client MUST choose
a different internal port and send a new PCP request specifying that
port.</t>
<t><list style="empty"><t>[Editor's note: This is very
bad. Imagine you have an ssh daemon listening internally on
port 22, and then the PCP server tells you
"IMPLICIT_MAPPING_EXISTS" (because a previous owner of that IP
address made an outbound connection from port 22) so your ssh
daemon has to listen on a nonstandard port instead. We need a
better solution. Maybe we should have MAP requests trump
implicit mappings? -- SC]
</t></list></t>
<t>On an error response, clients SHOULD NOT repeat the same request to
the same PCP server within the lifetime returned in the response.</t>
</section>
<section anchor="lifetime" title="Mapping Lifetime and Deletion">
<t>The PCP client requests a certain lifetime, and the PCP server
responds with the assigned lifetime. The PCP server MAY grant a
lifetime smaller or larger than the requested lifetime. The PCP server
SHOULD be configurable for permitted minimum and maximum lifetime, and
the RECOMMENDED values are 120 seconds for the minimum value and 24
hours for the maximum. It is RECOMMENDED that the server restrict
lifetimes to less than 24 hours, because they will consume ports even if
the internal host is no longer interested in receiving the traffic or
no longer connected to the network.</t>
<t>Once a PCP server has responded positively to a mapping request for
a certain lifetime, the port forwarding is active for the duration of
the lifetime unless the lifetime is reduced by the PCP client (to a
shorter lifetime or to zero) or until the PCP server loses its state
(e.g., crashes). This means that even if there is active traffic, the
mapping will be deleted when its lifetime expires.</t>
<t>If the requested lifetime is 0 then:
<list style="symbols">
<t>If the internal port and protocol both are non-zero, it indicates a
request to delete the indicated mapping immediately.</t>
<t>If the internal port is non-zero and the protocol is zero, it
indicates a request to delete all mappings for this Internal Address
for the given internal port for all transport protocols.</t>
<t>If the internal port and protocol both are zero, it indicates a
request to delete all mappings for this Internal Address for all
transport protocols. This is useful when a host reboots or joins
a new network, to clear out prior stale state from the NAT gateway
before beginning to install new mappings.</t>
</list>
The suggested external address and port fields are ignored in requests
where the requested lifetime is 0.</t>
<t>PCP MAP requests cannot delete mappings created by non-MAP
requests. If the PCP client attempts to delete a static mapping (i.e.,
a mapping created outside of PCP itself) or attempts to delete an
implicit dynamic mapping (e.g., created by a TCP SYN), the PCP server
deletes all of the mappings it can and responds with a zero error code.
If the PCP client attempts to delete a mapping that
does not exist, the SUCCESS result code is returned (this is necessary
for PCP to be idempotent). If the deletion
request was properly formatted, a SUCCESS response is generated with
lifetime of 0 and the server copies the protocol and internal port
number from the request into the response.</t>
<t>An application that forgets its PCP-assigned mappings (e.g., the
application or OS crashes) will request new PCP mappings. This may
consume port mappings, if the application binds to a different Internal Port
every time it runs. The application will also likely initiate new
implicit dynamic mappings (e.g., TCP connections) without using PCP,
which will also consume port mappings. If there is a port mapping
quota for the internal host, frequent restarts such as this may
exhaust the quota. PCP provides some protections against such
port consumption:
When a PCP client first acquires a new IP address (e.g., reboots or
joins a new network), it SHOULD remove mappings that may already
be instantiated for that Internal Address. To do this, the PCP client
sends a MAP request with protocol, internal port, and lifetime set to 0.
Some port mapping APIs (such as the
"DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on
Mac OS X, iOS, Windows, Linux, etc.) automatically monitor for process
exit (including application crashes) and automatically send port
mapping deletion requests if the process that requested them goes away
without explicitly relinquishing them.</t>
<t>In order to reduce unwanted traffic and data corruption, a port
that was mapped using the MAP OpCode SHOULD NOT be assigned to another
internal target, or another subscriber, for 120 seconds (MSL, <xref
target="RFC0793"></xref>). However, the PCP server MUST allow the same
internal address to re-acquire the same port during that same
interval.</t>
<t>The following list summarizes the sentinel values when deleting a
mapping using lifetime=0:<list style="hanging">
<t
hangText="all ports, all protocols, all Internal Addresses for which the client is authorized:">internal
address=0, via the THIRD_PARTY option</t>
<t hangText="all ports, all protocols:">internal port=0,
protocol=0</t>
<t hangText="all ports, specific protocol:">internal port=0,
protocol={protocol value} (e.g., protocol=6 for TCP)</t>
<t hangText="one port, specific protocol:">internal port={port
number}, protocol={protocol value} (e.g., port=12345, protocol=6
for TCP)</t>
</list></t>
</section>
<section title="Subscriber Renumbering">
<t>The customer premises router might obtain a new IPv4 address or new
IPv6 prefix. This can occur because of a variety of reasons including
a reboot, power outage, DHCP lease expiry, or other action by the ISP.
If this occurs, traffic forwarded to the subscriber might be delivered
to another customer who now has that address. This affects both
implicit dynamic mappings and explicit dynamic mappings. However, this
same problem occurs today when a subscriber's IP address is
re-assigned, without PCP and without an ISP-operated CGN. The solution
is the same as today: the problems associated with subscriber
renumbering are caused by subscriber renumbering and are eliminated if
subscriber renumbering is avoided. PCP defined in this document does
not provide machinery to reduce the subscriber renumbering
problem.</t>
<t>When a new Internal Address is assigned to a host embedding a PCP
client, the NAT (or firewall) controlled by the PCP server will
continue to send traffic to the old IP address. Assuming the PCP
client wants to continue receiving traffic, it needs to install new
mappings for its new IP address. The suggested external port field
will not be fulfilled by the PCP server, in all likelihood, because it
is still being forwarded to the old IP address. Thus, a mapping is
likely to be assigned a new external port number and/or public IP
address. Note that this scenario is not expected to happen routinely
on a regular basis for most hosts, since most hosts renew their DHCP
leases before they expire (or re-request the same address after
reboot) and most DHCP servers honor such requests and grant the host
the same address it was previously using before the reboot.</t>
</section>
<section anchor="map_options" title="PCP Options for MAP OpCodes">
<!--
<section title="EVEN_PLUS_ONE">
<t><xref target="RFC3550">RTP</xref> has historically used an
even-numbered port, and RTCP the next-higher port (often abbreviated
as "port + 1"). Some equipment still expects RTP/RTCP on adjacent
ports. To accommodate that, the PCP Option EVEN_PLUS_ONE can be used
by the PCP client and server, with the following procedure.</t>
<t><list style="empty">
<t>[Ed. Note: Are there any other protocols that need adjacent
ports?]</t>
</list></t>
<t>The procedure is for the PCP client to bind to two ports on its
local interface. It then sends a PCP request for external port 0
(indicating it will accept any port from the server) for one of those
internal ports and includes the PCP Option EVEN_PLUS_ONE with this
request. If the server understands this option, it will choose an
even-numbered external port and will reserve the next-higher port with
a short timeout (suggested duration is 10 seconds) for this same PCP
client to allocate in a subsequent PCP request. The PCP server sends a
response and indicates it performed that operation by including the
PCP Option EVEN_PLUS_ONE in the response. The PCP client then sends a
second PCP request for the next-higher external port. Refreshing and
deleting the ports works as normal.</t>
<figure anchor="even_plus_one_message_flow"
title="Message Flow, EVEN_PLUS_ONE">
<preamble>A diagram of the message flow:</preamble>
<artwork align="center"><![CDATA[
PCP Client PCP server
| |
|....request ext-port=0, EVEN_PLUS_ONE....>|
|<.response ext-port=23456, EVEN_PLUS_ONE..|
|....request ext-port=23457...............>|
|<-response ext-port=23457.................|
| |
]]></artwork>
</figure>
<t>The PCP Option EVEN_PLUS_ONE always has an Option-Length of 0. When
the PCP client wants an even-numbered port and the next-higher
adjacent port, it includes the PCP Option EVEN_PLUS_ONE in its PCP
request. If the server understands the option, has successfully mapped
an even-numbered external-port, and temporarily reserved the
next-higher port for this PCP client, the server MUST include the
EVEN_PLUS_ONE Option in its response. If the server understands the
option, but was unsuccessful at mapping an even-numbered port or
unsuccessful at temporarily reserving the next-higher port for this
PCP client, the server MUST NOT include the EVEN_PLUS_ONE Option in
its response. If the server receives a PCP request with the
EVEN_PLUS_ONE option for an odd-numbered requested-external-port, it
MUST return an error.</t>
<t>This Option is permitted with the following OpCodes: MAP44, MAP64,
MAP46, MAP66.</t>
</section>
-->
<section anchor="filter" title="FILTER">
<t>This Option indicates filtering incoming packets is desired. The
remote peer port and remote peer IP Address indicate the permitted
remote peer's source IP address and port for packets from the
Internet. The remote peer prefix length indicates the length of the
remote peer's IP address that is significant; this allows a single
Option to permit an entire subnet. After processing this MAP request
and generating a successful response, the PCP-controlled device will
drop packets received on its public-facing interface with a source
IP address (i.e., remote peer address), transport, or port that do
not match the fields, and if its security policy allows MAY generate
an ICMP error in response to that packet.</t>
<figure anchor="fig_filter" title="FILTER option layout">
<preamble>The FILTER packet layout is described below:</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | prefix-length | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP address (32 bits if MAP4, :
: 1 28 bits if MAP6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Reserved:">8 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="prefix-length:">indicates how many bits of the IPv4
or IPv6 address are relevant for this filter. The value 0
indicates "no filter", and will remove all previous filters. See
below for detail.</t>
<t hangText="Remote Peer Port:">the port number of the remote
peer. The value 0 indicates "all ports"</t>
<t hangText="Remote Peer IP address:">The IP address of the
remote peer.</t>
</list></t>
<t>This Option:<list style="empty">
<t>name: FILTER</t>
<t>number: 2</t>
<t>is valid for OpCodes: MAP4, MAP6</t>
<t>is included in responses: MUST, if it appeared in the
request</t>
<t>length: 2 if used with MAP4, 5 if used with MAP6</t>
<t>may appear in: requests</t>
<t>maximum occurrences: as many as fit within maximum PCP
message size</t>
</list></t>
<t>Because of interactions with dynamic ports this Option MUST only
be used by a client that is operating a server (that is, using the
MAP OpCode), as this ensures that no other application will be
assigned the same ephemeral port for its outgoing connection. It
is RECOMMENDED that the PCP client avoid other use, because it
will cause some UNSAF NAT
traversal mechanisms <xref target="RFC3424"></xref> to fail where
they would have otherwise succeeded, breaking other applications
running on this same host.</t>
<t>The prefix-length indicates how many bits of the IPv6 address or
IPv4 address are used for the filter. For MAP4, a prefix-length of
32 indicates the entire IPv4 address is used. For MAP6, a
prefix-length of 128 indicates the entire IPv6 address is used. For
MAP4 the minimum prefix-length value is 0 and the maximum value is
32. For MAP6 the minimum prefix-length value is 0 and the maximum
value is 128. Values outside those range cause an MALFORMED_OPTION
result code.</t>
<t>If multiple occurrences of the FILTER option exist in the same
MAP request, they are processed in the same order received, and they
MUST all be successfully processed or return an error (e.g.,
MALFORMED_OPTION if one of the options was malformed). As with other
PCP errors, returning an error causes no state to be changed in the
PCP server or in the PCP-controlled device. If an existing mapping
exists (with or without a filter) and the server receives a MAP
request with FILTER, the filters indicated in the new request are
added to any existing filters. If a MAP request has a lifetime of 0
and contains the FILTER option, the error MALFORMED_OPTION is
returned.</t>
<t>To remove all existing filters, the prefix-length 0 is used.
There is no mechanism to remove a specific filter.</t>
<t>To change an existing filter, the PCP client sends a MAP request
containing two FILTER options, the first option containing a
prefix-length of 0 (to delete all existing filters) and the second
containing the new remote peer's IP address and port. Other FILTER
options in that PCP request, if any, add more allowed remote
hosts.</t>
<t>The PCP server or the PCP-controlled device is expected to have a
limit on the number of remote peers it can support. This limit might
be as small as one. If a MAP request would exceed this limit, the
entire MAP request is rejected with the result code
EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is
unchanged.</t>
</section>
<!--
<section title="REMOTE_PEER">
<t>Due to a pre-existing dynamic mapping, a PCP server may not be
able to instantiate a filter on a specific port. It is thus
recommended that applications bind to the source port (to prevent
other applications from using that same source port) prior to using
this PCP Option.</t>
<t>In those situations, the Option REMOTE_PEER is necessary to
disambiguate the mappings. This option does not change filtering
behavior of the NAT or firewall.</t>
<figure>
<artwork align="center"><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP address (32 bits if MAP44 or MAP64, :
: 1 28 bits if MAP46 or MAP66) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>value: 129</t>
<t>is valid for OpCodes: MAP44, MAP64, MAP46, or MAP66</t>
<t>is included in responses: MUST</t>
<t>length: 8 or 20</t>
<t>maximum occurrences: 1</t>
</list></t>
</list></t>
</section>
-->
<section title="PREFER_FAILURE">
<t>This option indicates that if the PCP server is unable to
allocate the suggested port, then instead of returning an available
port that it *can* allocate, the PCP server should instead allocate
no port and return result code CANNOT_PROVIDE_EXTERNAL_PORT.</t>
<t>This option is intended solely for use by <xref
target="I-D.bpw-pcp-upnp-igd-interworking">UPnP IGD
interworking</xref>, where the semantics of IGD version 1 do not
provide any way to indicate to an IGD client that any port is
available other than the one it wanted. A PCP server MAY support
this option, if its designers wish to support downstream devices
that perform IGD interworking. PCP servers MAY choose to rate-limit
their handling of PREFER_FAILURE requests, to protect themselves
from a rapid flurry of 65535 consecutive PREFER_FAILURE requests
from clients probing to discover which external ports are available.
PCP servers that are not intended to support downstream devices that
perform IGD interworking are not required to support this option.
PCP clients other than IGD interworking clients SHOULD NOT use this
option because it results in inefficient operation, and they cannot
safely assume that all PCP servers will implement it. The option is
provided only because the semantics of IGD version 1 offer no viable
alternative way to implement an IGD interworking function. It is
anticipated that this option will be deprecated in the future as
more clients adopt PCP natively and the need for IGD interworking
declines.</t>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>name: PREFER_FAILURE</t>
<t>number: 3</t>
<t>is valid for OpCodes: MAP4, MAP6</t>
<t>is included in responses: MUST</t>
<t>length: 0</t>
<t>may appear in: requests</t>
<t>maximum occurrences: no</t>
</list></t>
</list></t>
</section>
<section title="THIRD_PARTY">
<t>The THIRD_PARTY option is used by both the MAP OpCode and the
PEER OpCode, and defined in <xref target="third_party"></xref>.</t>
</section>
</section>
<section title="PCP Mapping State Maintenance">
<t>If an event occurs that causes the PCP server to lose state (such
as a crash or power outage), the mappings created by PCP are lost.
Such loss of state is rare in a service provider environment (due to
redundant power, disk drives for storage, etc.). But such loss of
state is more common in a residential NAT device which does not write
information to its non-volatile memory.</t>
<t>The Epoch allows a client to deduce when a PCP server may have lost
its state. If this occurs, the PCP client can attempt to recreate the
mappings following the procedures described in this section.</t>
<section anchor="reboot" title="Recreating Mappings">
<t>The PCP server SHOULD store mappings in persistent storage so
when it is powered off or rebooted, it remembers the port mapping
state of the network. Due to the physical architecture of some PCP
servers, this is not always achievable (e.g., some non-volatile
memory can withstand only a certain number of writes, so writing PCP
mappings to such memory is generally avoided).</t>
<t>However, maintaining this state is not essential for correct
operation. When the PCP server loses state and begins processing new
PCP messages, its Epoch is reset to zero (per the procedure of <xref
target="epoch"></xref>).</t>
<t>A mapping renewal packet is formatted identically to an original
mapping request; from the point of view of the client it is a
renewal of an existing mapping, but from the point of view of the
PCP server it appears as a new mapping request. In the normal
process of routinely renewing its mappings before they expire,
a PCP client will automatically recreate all its lost mappings.</t>
<t>In addtion, as the result of receiving a packet where the Epoch field
indicates that a reboot or similar loss of state has occurred, the
client can renew its port mappings sooner, without waiting for the
normal routine renewal time.</t>
<t>The discussion in this section focuses on recreating inbound port
mappings after loss of PCP server state, because that is the more
serious problem. Losing port mappings for outgoing connections
destroys those currently active connections, but does not prevent
clients from establishing new outgoing connections. In contrast,
losing inbound port mappings not only destroys all existing inbound
connections, but also prevents the reception of any new inbound
connections until the port mapping is recreated. Accordingly, we
consider recovery of inbound port mappings the more important
priority. However, clients that want outgoing connections to survive
a NAT gateway reboot can also achieve that using PCP. After
initiating an outbound TCP connection (which will cause the NAT
gateway to establish an implicit port mapping) the client should
send the NAT gateway a PEER request for the source port of
its TCP connection, which will cause the NAT gateway to send a
response giving the external port it allocated for that mapping. The
client can then store this information, and use it later to recreate
the mapping if it determines that the NAT gateway has lost its
mapping state.</t>
</section>
<section title="Maintaining Mappings">
<t>A PCP client can refresh a mapping by sending a new PCP request
containing information from the earlier PCP response. The PCP server
will respond indicating the new lifetime. It is possible, due to
failure of the PCP server, that the public IP address and/or public
port, or the PCP server itself, has changed (due to a new route to a
different PCP server). To detect such events more quickly, the PCP
client may find it beneficial to use shorter lifetimes (so that it
communicates with the PCP server more often). If the PCP client has
several mappings, the Epoch value only needs to be retrieved for one
of them to verify the PCP server has not lost port forwarding
state.</t>
<t>If the client wishes to check the PCP server's Epoch, it sends a
PCP request for any one of the client's mappings. This will return
the current Epoch value. In that request the PCP client could extend
the mapping lifetime (by asking for more time) or maintain the
current lifetime (by asking for the same number of seconds that it
knows are remaining of the lifetime).</t>
<t>If a internal IP address is no longer valid (e.g., because the
internal host has moved to a new network), and the PCP client wishes
to still receive incoming traffic, it MUST create a new mapping on
that new network. A new mapping will also require an update to the
application-specific rendezvous server (<xref
target="operating_a_server"></xref>).</t>
</section>
</section>
</section>
<section anchor="peer_opcodes" title="PEER OpCodes">
<t>This section defines two OpCodes for controlling dynamic connections.
They are:<list hangIndent="12" style="hanging">
<t hangText=" PEER4=3:">Set or query lifetime for flow from IPv4
address to a remote peer's IPv4 address.</t>
<t hangText=" PEER6=4:">Set or query lifetime for flow from IPv6
address to a remote peer's IPv6 address.</t>
</list> The operation of these OpCodes is described in this
section.</t>
<section title="OpCode Packet Formats">
<t>The PEER OpCodes provide a single function: the ability for the PCP
client to query and (possibly) extend the lifetime of an existing
mapping.</t>
<t>The two PEER OpCodes (PEER4 and PEER6) share a similar packet
layout for both requests and responses. Because of this similarity,
they are shown together.</t>
<figure anchor="peer_request"
title="PEER OpCode Request Packet Format">
<preamble>The following diagram shows the request packet format for
PEER4 and PEER6. This packet format is aligned with the response
packet format:</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP Address (32 bits if PEER4, 128 bits if PEER6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Reserved (128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Requested Lifetime (in common header):">
Requested lifetime of this
mapping, in seconds. Unlike the MAP OpCode, where 0 means
'delete', there is no special meaning of 0, and the PCP client
cannot reduce the lifetime of an implicit dynamic connection
(<xref target="peer-opcode_server_operation"></xref>).</t>
<t hangText="Protocol:">indicates protocol associated with this
OpCode. Values are taken from the <xref
target="proto_numbers">IANA protocol registry</xref>. For example,
this field contains 6 (TCP) if the OpCode is describing a TCP
peer.</t>
<t hangText="Reserved:">24 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="Internal Port:">Internal port for the of the
5-tuple.</t>
<t hangText="Reserved:">16 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="Remote Peer Port:">Remote peer's port of the
5-tuple.</t>
<t hangText="Reserved:">16 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="Remote Peer IP Address:">This is the Remote
peer's IP address from the perspective of the PCP client
so that the PCP client does not need to concern itself
with NAT64 or NAT46 (which both cause the client's idea of
the remote peer's IP address to differ from the remote
peer's actual IP address). This field allows the PCP
client and PCP server to disambiguate multiple connections
from the same port on the internal host to different
servers. Note this field has no bearing whatsoever on
any filtering associated with the mapping.</t>
<t hangText="Reserved:">128 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
</list></t>
<figure anchor="peer_response"
title="PEER OpCode Response Packet Format">
<preamble>The following diagram shows the response packet format for
PEER4 and PEER6:</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | External_AF | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP Address (32 bits if PEER4, 128 bits if PEER6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: External IP Address (always 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Lifetime (in common header):">
On a success response, this indicates the lifetime for this mapping,
in seconds. On an error response, this indicates how long clients
should assume they'll get the same error response from the that PCP
server if they repeat the same request.</t>
<t hangText="Protocol:">Copied from the request.</t>
<t hangText="External_AF">For success responses, this
contains the address family of the external IP address
associated with this peer connection, to properly decode
the External IP Address. Values are from IANA's address
family numbers (IPv4 is 1, IPv6 is 2). For error responses,
the value MUST be 1.</t>
<t hangText="Reserved:">16 reserved bits, MUST be 0 on
transmission, MUST be ignored on reception.</t>
<t hangText="Internal Port:">copied from request.</t>
<t hangText="External Port:">For success responses, this is the
external port number, assigned by the NAT (or firewall) to this
mapping. If firewall or 1:1 NAT, this will match the internal
port. For error responses, this MUST be 0.</t>
<t hangText="Remote Peer port:">Copied from request.</t>
<t hangText="Reserved:">16 reserved bits, MUST be 0 on
transmission, MUST be ignored on reception.</t>
<t hangText="Remote Peer IP Address">Copied from the request.</t>
<t hangText="External IP Address">For success responses,
this contains the external IP address, assigned by the NAT
(or firewall) to this mapping. This field allows the PCP
client and its remote peer to determine if there is
another NAT between the PCP-controlled NAT and remote
peer. If the PCP-controlled device is a firewall, this will
match the internal IP address. This field is always 128
bits long. If External_AF indicates IPv4, the IPv4 address
is encoded in the first 32 bits of the External IP Address
field and the remaining 96 bits are zero.
the remote peer.</t>
</list></t>
</section>
<section anchor="peer_result_codes" title="OpCode-Specific Result Codes">
<t>In addition to the general PCP result codes (<xref
target="result_codes"></xref>) the following additional result codes
may be returned as a result of the two PEER OpCodes received by the
PCP server.<list style="hanging">
<t hangText="50">NONEXIST_PEER, the connection to that peer does
not exist in the mapping table.
<list style="empty"><t>[Editor's Note: Maybe it should just go ahead and make the mapping, instead of complaining about it? -- SC]</t></list>
</t>
</list></t>
<t>Additional result codes may be returned if the THIRD_PARTY option
is used, see <xref target="third_party"></xref>.</t>
</section>
<section anchor="peer_opcode_client_operation"
title="OpCode-Specific Client: Generating a Request">
<t>This section describes the operation of a client when generating
the OpCodes PEER4 or PEER6.</t>
<t>The PEER4 or PEER6 OpCodes MUST NOT be sent until establishing
bi-directional communication with the remote peer. For TCP, this means
completing the TCP 3-way handshake. This is because the PCP-controlled
device may not be able to extend the lifetime of a mapping until after
bi-directional communications has been established. The Internal Address
for the PEER request is the the PEER request's source IP address.
[Why not? Why not allow the PEER request to make a mapping, just like a TCP SYN does?]
</t>
<t>The PEER4 and PEER6 OpCodes contain a description of the remote peer address,
from the perspective of the PCP client. This is important when the
PCP-controlled device is performing address family translation (NAT46
or NAT64), because the destination address from the perspective of the
PCP client is different from the destination address on the other side
of the address family translation device.</t>
</section>
<section anchor="peer-opcode_server_operation"
title="OpCode-Specific Server: Processing a Request">
<t>This section describes the operation of a server when receiving a
request with the OpCodes PEER4 or PEER6.</t>
<t>On receiving the PEER4 or PEER6 OpCode, the PCP server examines the
mapping table. If a mapping does not exist, the NONEXIST_PEER error is
returned.
[Why not? Why not allow the PEER request to make a mapping, just like a TCP SYN does?]
</t>
<t>The PEER4 or PEER6 OpCodes MUST NOT reduce the lifetime of an
existing mapping. If the mapping is terminated by the TCP client or
server (e.g., TCP FIN or TCP RST), the mapping will eventually be
destroyed normally; the earlier use of PEER does not extend the
lifetime in that case.</t>
<t>If the PCP-controlled device can extend the lifetime of a
mapping, the PCP server uses the smaller of its configured
maximum lifetime value and the requested lifetime from the
PEER request, and sets the lifetime to that value.</t>
<t>If all of the proceeding operations were successful (did not
generate an error response), then a SUCCESS response is generated,
with the assigned-lifetime containing the lifetime of the mapping.</t>
<t>After a successful PEER response is sent, it is
implementation-specific if the PCP-controlled device
destroys the mapping when the lifetime expires, or if
inside->outside traffic keeps the mapping alive. Thus,
if the PCP client wants the mapping to persist beyond the
lifetime, it MUST refresh the mapping (by sending another
PEER message) prior to the expiration of the lifetime.</t>
</section>
<section title="OpCode-Specific Client: Processing a Response">
<t>This section describes the operation of a client when processing a
response with the OpCodes PEER4 or PEER6.</t>
<t>A response is matched with a request by comparing the protocol,
external AF, internal IP address, internal port, remote peer address
and remote peer port. Other fields are not compared, because the PCP
server changes those fields to provide information about the mapping
created by the OpCode.</t>
<t>If the error response NONEXIST_PEER is received, this could
have occurred if the PCP client sent its PEER request before
the PCP-controlled device had installed the mapping, or
because the mapping has been destroyed (e.g., due to a TCP
FIN). If the PCP client believes the mapping should exist, the
PCP client SHOULD retry the request after a brief delay (e.g.,
5 seconds).</t>
<t>Other error responses SHOULD NOT be retried.</t>
<t>If a successful response, the PCP client uses the assigned lifetime
value to reduce its frequency of application keepalives for that
particular NAT mapping. Of course, there may be other reasons,
specific to the application, to use more frequent application
keepalives. For example, the PCP assigned-lifetime could be one hour
but the application may want to ensure the server is still accessible
(e.g., has not crashed) more frequently than once an hour.</t>
<t>If the PCP client wishes to keep this mapping alive beyond the
indicated lifetime, it SHOULD issue a new PCP request prior to the
expiration. That is, inside->outside traffic is not sufficient to
ensure the mapping will continue to exist. It is RECOMMENDED to send a
single renewal request packet when a mapping is halfway to expiration
time, then, if no SUCCESS response is received, another single renewal
request 3/4 of the way to expiration time, and then another at 7/8 of
the way to expiration time, and so on, subject to the constraint that
renewal requests MUST NOT be sent less than four seconds apart (a PCP
client MUST NOT send an infinite number of ever-closer-together
requests in the last few seconds before a mapping expires).</t>
</section>
<section title="PCP Options for PEER OpCodes">
<section title="THIRD_PARTY">
<t>The THIRD_PARTY option is used by both the MAP OpCode and the
PEER OpCode, and defined in <xref target="third_party"></xref>.</t>
</section>
</section>
</section>
<section anchor="third_party"
title="THIRD_PARTY Option for MAP and PEER OpCodes">
<t>This Option is used when a PCP client wants to control a mapping to
an internal host other than itself. This is used with both MAP
and PEER OpCodes.</t>
<t>A THIRD_PARTY Option MUST NOT contain the same address as the source
address of the packet. A PCP server receiving a THIRD_PARTY Option
specifying the same address as the source address of the packet MUST
return a MALFORMED_REQUEST result code. This is because many PCP servers
may not implement the THIRD_PARTY Option at all, and a client using the
THIRD_PARTY Option to specify the same address as the source address of
the packet will cause mapping requests to fail where they would otherwise
have succeeded.</t>
<t>A PCP server will only process this option if sent by an authorized
PCP client, otherwise will return an error. Determining which PCP
clients are authorized to use the THIRD_PARTY option depends on the
deployment scenario. For Dual-Stack Lite deployments, the PCP server
only supports this option if the source IPv6 address is the B4's source
IP address. For other scenarios, the subscriber has only one IPv4
address and this Option serves no purpose (and will only generate error
messages from the server). If a subscriber has more than one IPv4
address (from the same ISP, often called "business-class"), the ISP MUST
determine its own policy for how to identify the trusted device within
the subscriber's home. This might be, for example, the lowest- or
highest-numbered host address for that user's IPv4 prefix.
On the other hand, some credible cryptographic security could be used
to determine whether a PCP client is authorized to make or delete mappings
on behalf of a given Internal Address.</t>
<figure alt="fig_third_party" title="THIRD_PARTY option packet format">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Internal IP Address (32 bits of 128 bits, depending :
: on Option length) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are described below:<list style="hanging">
<t hangText="Internal IP Address:">IP address of this
mapping. If the length of this Option is 4, this is a 32-bit IPv4
address. If the length of this Option is 16, this is a 128-bit IPv6
address. This can contain the special value "0" (all zeros), which
indicates "all Internal Addresses for which this client is authorized" which is
used to delete all pre-existing mappings with the MAP Opcode.</t>
</list></t>
<t>This Option:<list style="empty">
<t>name: THIRD_PARTY</t>
<t>number: 4</t>
<t>purpose: Indicate the MAP or PEER request is for a host other
than the host sending the PCP option.</t>
<t>is valid for OpCodes: MAP4, MAP6, PEER4, PEER6</t>
<t>length: 4 if OpCode is MAP4 or PEER4, 16 if OpCode is MAP6 or
PEER6</t>
<t>may appear in: request. May appear in response only if it
appeared in the associated request.</t>
<t>maximum occurrences: 1</t>
</list></t>
<t>The following additional result codes may be returned as a result of
using this Option. <list style="hanging">
<t hangText="51">UNAUTH_TARGET_ADDRESS, indicting the internal IP
address specified is not permitted (e.g., client is not authorized
to make mappings for this Internal Address, or is otherwise prohibited.). This error
can be returned for both MAP and PEER requests. If this is a MAP
request, this is a long-term error.</t>
</list></t>
<t>A PCP server is configured to permit or to restrict the use of the
THIRD_PARTY option. If this option is permitted, any host
can create, modify, or destroy mappings for
another host on the network, which is generally undesirable. If third
party mappings are restricted, only a authorized clients
can perform these operations. If a PCP server is configured to
restrict third party mappings, and receives a PCP MAP request with a
THIRD_PARTY option, it MUST generate a UNAUTH_TARGET_ADDRESS response.</t>
<t>It is RECOMMENDED that PCP servers embedded into customer premise
equipment be configured to refuse third party mappings. With this
configuration, if a user wants to create a third party mapping, the user
needs to interact out-of-band with their customer premise router (e.g.,
using its HTTP administrative interface).</t>
<t>It is RECOMMENDED that PCP servers embedded into service
provider NAT and firewall devices be configured to permit the
THIRD_PARTY option, when sent by the customer premise router.
With this configuration, if a user wants to create an explicit
dynamic mapping or query an implicit dynamic mapping for another
host within their network, the user needs to interact
out-of-band with their customer premise router (e.g., using its
HTTP administrative interface). To accomplish this, the PCP
server processes requests with the THIRD_PARTY option if they
arrived from the IP address of the customer premise router. In
deployments with only one IP address (e.g., which is common in
residential networks), the PCP messages will -- by necessity --
arrive from the IP address of the customer premise router
router. In networks where users have multiple IPv4 or multiple
IPv6 addresses, the PCP server MUST only allow the THIRD_PARTY
option if the PCP message was sent by the IP address of the
subscriber's customer premise router. In Dual-Stack Lite, this
would be the B4 element's IPv6 address. If the packet arrived
from a different address, the PCP server MUST generate an
UNAUTH_TARGET_ADDRESS error.</t>
<t>If authorized to do so, a PCP client can delete all the PCP-created
explicit dynamic mappings (i.e., those created by PCP MAP requests) for
all hosts belonging to the same subscriber. This is done by sending a
PCP MAP request including the THIRD_PARTY option with its Internal Address
field set to 0.</t>
</section>
<section title="NAT-PMP Transition">
<t>Port Control Protocol (PCP) is a successor to NAT Port
Mapping Protocol (NAT-PMP), and shares similar semantics,
concepts, and packet formats. Because of this NAT-PMP and PCP
can both use the same port, and use the protocol's built-in
version negotiation capabilities to determine which version to
use. It is hoped that in relatively short time most shipping
NAT-PMP clients and gateways will be updated to support PCP as
well, but there will be a transition period. During this
transition period developers updating NAT-PMP clients to add PCP
will still want to work with existing NAT-PMP gateways, and
developers updating NAT-PMP gateways will still want to support
existing NAT-PMP clients. This section describes how an orderly
transition may be achieved.</t>
<section title="NAT-PMP Clients Updated to Add PCP Support">
<t>A client supporting both NAT-PMP and PCP SHOULD optimistically
assume that the gateway supports PCP, since we expect that this will
rapidly become the case, and we want to optimize for better performance
in this case. A dual-mode client SHOULD send all its requests first
using PCP packet format. If the gateway responds with a packet four
or more bytes long, containing the following (NAT-PMP format) data
in the first four bytes, then the dual-mode client SHOULD conclude that
this NAT gateway supports only NAT-PMP, and SHOULD retry its request in
the older NAT-PMP format.</t>
<figure align="left" anchor="PMPGate" title="NAT-PMP Gateway Response to PCP Request">
<preamble>NAT-PMP gateways respond to PCP requests with the following packet.
The first byte (supported version) is zero.
The second byte (opcode) echoes back the request opcode, with the top bit set.
The third byte (high byte of the NAT-PMP error code) is zero.
The fourth byte is 1 (NAT-PMP and PCP error code "Unsupported Version").
</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Version = 0 |R| OP = any | Zero | Result = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="NAT-PMP Gateways Updated to Add PCP Support">
<t>A gateway supporting both NAT-PMP and PCP is able to handle and respond
to requests using both packet formats. If the first byte of the packet is
zero, a dual-mode gateway SHOULD parse the request as a NAT-PMP-format
message and reply using a NAT-PMP-format response. Otherwise it should
parse the request as a PCP-format message and respond accordingly.</t>
<t>A PCP-only gateway receiving a NAT-PMP request (identified by the
first byte being zero) MUST reply with the packet shown below, so that
the NAT-PMP may log an error message informing the user that they need
to update to a PCP-capable client.</t>
<figure align="left" anchor="PCPGate" title="PCP Gateway Response to NAT-PMP Request">
<preamble>PCP gateways respond to NAT-PMP requests (identified by the
first byte being zero) with the following packet.
The first byte (supported version) is 1.
The second byte (opcode) echoes back the request opcode, with the top bit set.
The third byte (high byte of the NAT-PMP error code) is zero.
The fourth byte is 1 (NAT-PMP and PCP error code "Unsupported Version").
</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Version = 1 |R| OP = any | Zero | Result = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
</section>
<section title="Deployment Considerations">
<section title="Maintaining Same External IP Address">
<t>It is REQUIRED that the PCP-controlled device assign the same
external IP address PCP-created explicit dynamic mappings and to
implicit dynamic mappings. It is RECOMMENDED that static mappings
(e.g., those created by a command-line interface on the PCP server
or PCP-controlled device) also be assigned to the same IP address.</t>
<t>Once all internal hosts belonging to a given subscriber have no
implicit dynamic mappings and have no explicit dynamic mappings in the
PCP-controlled device, a subsequent PCP request for that internal host
MAY be assigned to a different external IP address. Generally, this
re-assignment would occur when a CGN device is load balancing
newly-seen hosts to its public IPv4 address pool.</t>
</section>
<section title="Ingress Filtering">
<t>To prevent spoofing of PCP requests, <xref target="RFC2827">ingress
filtering</xref> MUST be performed by devices between the PCP clients
and PCP server. For example, with a PCP server integrated into a
customer premise router, the Ethernet switch needs to perform ingress
filtering. As another example, with a PCP server deployed by a service
provider, the service provider's aggregation router (the first device
connecting to subscribers) needs to do ingress filtering.</t>
</section>
<section anchor="quota" title="Per-Subscriber Port Forwarding Quota">
<t>On PCP-controlled devices that create state when a mapping is
created (e.g., NAPT), the PCP server SHOULD maintain a per-subscriber
mapping quota for PCP-created mappings. It is implementation-specific
if the PCP server has a separate or combined quota for both implicit
dynamic mappings (e.g., created by TCP SYNs) and explicit dynamic mappings
(created using PCP).</t>
</section>
</section>
<section anchor="scenarios" title="Deployment Scenarios">
<section title="Dual Stack-Lite">
<t>The interesting components in a Dual-Stack Lite deployment are the
B4 element (which is the customer premises router) and the AFTR
(Address Family Transition Router) element. The AFTR element
terminates the IPv6-over-IPv4 tunnel and also implements the
Carrier-Grade NAT44 function. The B4 element does not need to perform
a NAT function (and usually does not perform a NAT function), but it
does operate its own DHCP server and is the local network's default
router.</t>
<section title="Overview">
<t>Various PCP deployment scenarios can be considered to control the
PCP server embedded in the AFTR element:<list style="numbers">
<t>UPnP IGD and NAT-PMP <xref
target="I-D.cheshire-nat-pmp"></xref> are used in the LAN: an
interworking function is required to be embedded in the B4
element to ensure interworking between the protocol used in the
LAN and PCP. UPnP IGD-PCP Interworking Function is described in
<xref target="I-D.bpw-pcp-upnp-igd-interworking"></xref>.</t>
<t>Hosts behind the B4 element will either include a PCP client
or UPnP IGD client, or both.<list style="letters">
<t>if a UPnP IGD client, the B4 element will need to include
an interworking function from UPnP IGD to PCP.</t>
<t>if a PCP client, the PCP client will communicate directly
with the PCP server.</t>
</list></t>
<t>The B4 element includes a PCP client which is invoked by an
HTTP-based configuration (as is common today). The internal IP
address field in the PCP payload would be the internal host used
in the port forwarding configuration.</t>
</list></t>
<t>In Dual Stack-Lite, the B4 element encapsulates its PCP messages
into the IPv6 tunnel towards the AFTR element. It is expected the B4
element will also perform as a proxy from PCP to PCP <xref
target="I-D.bpw-pcp-proxy"></xref>, and may also proxy from other
protocols to PCP (e.g., <xref
target="I-D.bpw-pcp-upnp-igd-interworking"></xref>. When proxying
for other hosts, the B4 element might have to use the THIRD_PARTY
option with the MAP and PEER OpCodes if it modifies the packet's source
address before forwarding it upstream.</t>
</section>
</section>
<section title="NAT64">
<t>Hosts behind a NAT64 device can make use of PCP in order to perform
port reservation (to get a publicly routable IPv4 port).</t>
<!--
<t>If the IANA-assigned IP address is used for the discovery of the
PCP server, that IPv4 address can be placed into the IPv6 destination
address following that particular network's well-known prefix or
network-specific prefix, per <xref target="RFC6052"></xref>.</t>
-->
</section>
<section title="NAT44 and NAT444">
<t>Residential subscribers in NAT44 (and NAT444) deployments are
usually given one IPv4 address, but may also be given several IPv4
addresses. These addresses are not routable on the IPv4 Internet, but
are routable between the subscriber's home and the ISP's CGN. To
accommodate multiple hosts within a home, especially when provided
insufficient IPv4 addresses for the number of devices in the home,
subscribers operate a NAPT device. When this occurs in conjunction
with an upstream NAT44, this is nicknamed "NAT444".</t>
<!--
<list style="empty">
<t>[Ed. Note: Does PCP need a mechanism to detect a
non-PCP-supporting NAT between a PCP client and a PCP server? Or
can that problem be detected by relying on the failure of PCP
server Discovery? This is tracked as PCP Issue #25 <xref
target="PCP-Issues"></xref>.]</t>
</list></t>
-->
</section>
<section title="IPv6 Simple Firewall">
<t>Many IPv6 deployments will include a <xref target="RFC6092">simple
firewall</xref>, which permits outgoing packets to initiate
bi-directional communication but blocks unsolicited incoming packets,
which is similar to PCP's security model that allows a host to create
a mapping to itself. In many situations, especially residential
networks that lack an IT staff, the security provided by an IPv6
simple firewall and the security provided by PCP are compatible. In
such situations, the IPv6 simple firewall and the IPv6 host can use
the MAP6 OpCode to allow unsolicited incoming packets, so the host can
operate a server.</t>
</section>
</section>
<!--
<section anchor="upnp-interworking"
title="Interworking with UPnP IGD 1.0 and 2.0">
<t><list style="empty">
<t>[Ed. Note: This UPnP IGD Interworking section will likely be
moved to a separate document which will fully describe how a proxy
needs to translate UPnP IGD messages into PCP messages. This is
tracked as PCP Issue #28 <xref target="PCP-Issues"></xref>.]</t>
</list></t>
<t>The following diagram shows how UPnP IGD can be interworked with PCP,
using an interworking function (IWF).</t>
<figure align="center" anchor="igd-interworking-function"
title="Network Diagram, Interworking UPnP IGD and PCP">
<artwork><![CDATA[
xxx
]]></artwork>
</figure>
<section title="UPnP IGD 1.0 with AddPortMapping Action">
<t>In <xref target="IGD">UPnP IGD 1.0</xref> it is only possible to
request a specific port using the AddPortMapping action. Requiring a
specific port is incompatible with both (1) a Carrier-Grade NAT and
with (2) widely-deployed applications. Regarding (1), another
subscriber is likely to already be using the same port, so it will be
unavailable to this application to operate a server. Regarding (2), if
the same popular application exists on two devices behind the same
NAPT, they cannot both get the same port. PCP cannot correct this
behavior of UPnP IGD:1, but PCP does work with this behavior.</t>
<t>Due to this incompatibility with address sharing and popular
applications, future hosts and applications will either support UPnP
IGD 2.0's AddAnyPortMapping method (see <xref
target="upnp-2-interworking"></xref>) or, more likely, will support
PCP natively.</t>
<t>When a requested port assignment fails, most UPnP IGD control
points will retry the port assignment requesting the next higher port
or requesting a random port. These UPnP IGD requests are translated to
PCP requests and sent to the PCP server. The requests include the
PREFER_FAILURE option, which causes the PCP server to return an error
if it cannot allocate the requested port. The interworking function
translates the PCP error response to a UPnP IGD error response. This
repeats until the UPnP IGD client gives up or until the PCP server is
able to return the requested port.</t>
<figure align="left" anchor="message-flow-upnp-1"
title="Message Flow: Interworking from UPnP IGD 1.0 AddPortMapping action to PCP">
<preamble>Message flow would be similar to this:</preamble>
<artwork align="center"><![CDATA[
UPnP Control Point in-home CPE PCP server
xxx
]]></artwork>
</figure>
</section>
<section anchor="upnp-2-interworking"
title="UPnP IGD 2.0 with AddAnyPortMapping Action">
<t>If the UPnP IGD control point and the UPnP IGD interworking
function both implement <xref target="IGD-2">UPnP IGD 2.0</xref> and
the UPnP IGD control point uses IGD 2's new AddAnyPortMapping action,
only one round-trip is necessary. This is because AddAnyPortMapping
has semantics similar to PCP's semantics, allowing the PCP server to
assign any port.</t>
<figure align="left" anchor="message-flow-upnp-2"
title="Message Flow: Interworking from UPnP IGD 2.0 AddAnyPortMapping action to PCP">
<preamble>Message flow would be similar to this:</preamble>
<artwork align="center"><![CDATA[
UPnP Control Point in-home CPE PCP server
xxx
]]></artwork>
</figure>
</section>
<section title="Lifetime Maintenance">
<t>UPnP IGD 1.0 and 2.0 provide a lifetime (PortMappingLeaseDuration),
but it is seldom used by UPnP IGD control points, and does not allow
the UPnP IGD to override the requested duration. Thus, the UPnP
IGD/PCP interworking function is responsible for extending the
lifetime of mappings that are still interesting to the UPnP IGD
control point.</t>
<t><list style="empty">
<t>Note: It can be an implementation advantage, where possible,
for the UPnP IGD/PCP interworking function to request a port
mapping lifetime only while that client is active and connected.
For example, creating a PCP mapping that is equal to the client's
remaining DHCP lifetime is one useful approach.</t>
</list></t>
</section>
</section>
-->
<section anchor="security" title="Security Considerations">
<t>This document defines Port Control Protocol and two types of OpCodes,
PEER and MAP. The PEER OpCode allows querying and extending (if
permitted) the lifetime of an existing implicit dynamic mapping, so a
host can reduce its keepalive messages. The MAP OpCode allows creating a
mapping so a host can receive incoming unsolicited connections from the
Internet in order to run a server.</t>
<t>The PEER OpCode does not introduce any new security
considerations.</t>
<t>On today's Internet, ISPs do not typically filter incoming traffic
for their subscribers. However, when an ISP introduces stateful address
sharing with a NAPT device, such filtering will occur as a side effect.
Filtering will also occur with IPv6 CPE <xref
target="RFC6092"></xref>. The MAP OpCode
allows a PCP client to create a mapping so that a host can receive
inbound traffic and operate a server. Security considerations for the
MAP OpCode are described in the following sections.</t>
<section title="Denial of Service">
<t>Because the state created in a NAPT or firewall, a per-subscriber
quota will likely exist for both implicit dynamic mappings (e.g.,
outgoing TCP connections) and explicit dynamic mappings (PCP). A
subscriber might make an excessive number of implicit or explicit
dynamic mappings, consuming an inordinate number of ports, causing a
denial of service to other subscribers. Thus, <xref
target="quota"></xref> recommends that subscribers be limited to a
reasonable number of explicit dynamic mappings.</t>
</section>
<section title="Ingress Filtering">
<t>It is important to prevent a subscriber from creating a mapping for
another subscriber, because this allows incoming packets from the
Internet and consumes the other user's mapping quota. Both implicit
dynamic mappings (e.g., outgoing TCP connections) and explicit dynamic
mappings (PCP) need ingress filtering. Thus, PCP does not create a new
requirement for ingress filtering.</t>
</section>
<section anchor="subscriber_identification"
title="Validating the Internal Address">
<t>The THIRD_PARTY Option contains a Internal Address field, which
allows a PCP client to create an explicit dynamic mapping for another
host. Hosts within a subscriber's network cannot create, modify, or
delete mappings of other hosts, except by using the administrative
interface of the customer premise router (e.g., HTTP interface), as
described in <xref target="third_party"></xref>.</t>
<!--
<t>When the Target Address is an IPv4 address, and does not
match the PCP request's source IP address or address family,
the following validation occurs:<list style="hanging">
<t hangText="DS-Lite, Encapsulation Mode:">If the source
address of the PCP request is not 192.0.0.6, the PCP server
MUST generate an UNAUTH_TARGET_ADDRESS response code.</t>
<t hangText="DS-Lite, Plain Mode:">The B4 element is the
terminus of the DS-Lite IPv6 tunnel, and thus any PCP
request received was sent by the B4 element itself.
DS-Lite allows any IPv4 address within the DS-Lite tunnel,
so any IPv4 Target Address is permitted.</t>
<t hangText="NAT44 with one subscriber address:">The PCP server
MUST generate an UNAUTH_TARGET_ADDRESS response code.</t>
<t hangText="NAT44 with multiple subscriber
addresses:">The PCP server determines the address
range for the subscriber that sent this PCP request,
as described for "all other configurations", below.</t>
</list></t>
<t>When the Target Address is an IPv6 address, and does not
match the PCP request's source address or address family, the
following validation occurs:<list style="hanging">
<t hangText="DS-Lite, Encapsulation Mode:">If the source
IPv6 address is not the B4 element's IPv6 address, the PCP server MUST
generate an UNAUTH_TARGET_ADDRESS response code.</t>
</list></t>
<t>All Other Configurations: all other configurations
<t hangText="all other configurations:">
This requires the
PCP server interface with the service provider's database
to determine if the Target Address belongs to the same
subscriber. The specific interaction is beyond the scope
of this document, but might be a database query or might
be a configuration table on the PCP server (e.g.,
subscribers with a certain network prefix all have an IPv4
/24, others have an IPv4 /32, and others have an have an
IPv6 /32). Within that range, if the source IP address of
the PCP request is not the highest-numbered host assigned
to the subscriber, the PCP server MUST generate an
UNAUTH_SOURCE_ADDRESS response code. If the Target
Address does not belong to the same subscriber, the PCP
server MUST generate an UNAUTH_TARGET_ADDRESS response
code.</t>
</list></t>
-->
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to perform the following actions:</t>
<section anchor="iana_port" title="Port Number">
<t>IANA has assigned UDP port 44323 for PCP.</t>
</section>
<section anchor="iana_opcodes" title="OpCodes">
<t>IANA shall create a new protocol registry for PCP OpCodes,
initially populated with the values in <xref
target="map_opcodes"></xref> and <xref target="peer_opcodes"></xref>.
The values 0 and 128 are reserved.</t>
<t>Additional OpCodes in the range 4-95 can be created via <xref
target="RFC5226">Standards Action</xref>, and the range 96-127 is for
<xref target="RFC5226">Private Use</xref>.</t>
</section>
<section anchor="iana_result_codes" title="Result Codes">
<t>IANA shall create a new registry for PCP result codes, numbered
0-255, initially populated with the result codes from <xref
target="result_codes"></xref>, <xref
target="map_result_codes"></xref>, <xref target="filter"></xref>,
<xref target="peer_result_codes"></xref>, and <xref
target="third_party"></xref>. The values 0 and 255 are reserved.</t>
<t>Additional Result Codes can be defined via <xref
target="RFC5226">Specification Required</xref>.</t>
</section>
<section anchor="iana_ie" title="Options">
<t>IANA shall create a new registry for PCP Options, numbered 0-255
with an associated mnemonic. The values 0-128 are
mandatory-to-process, and 128-255 are optional-to-process. The initial
registry contains the options described in <xref
target="map_options"></xref> and <xref target="third_party"></xref>.
The option values values 0 and 255 are reserved.</t>
<t>Additional PCP option codes in the ranges 5-63 and 128-191 can be
created via <xref target="RFC5226">Standards Action</xref>, and the
ranges 64-127 and 192-255 are for <xref target="RFC5226">Private
Use</xref>.</t>
</section>
</section>
<section title="Acknowledgments">
<t>Thanks to Alain Durand, Christian Jacquenet, Jacni Qin, Simon
Perreault, Paul Selkirk, and James Yu for their comments and review.
Thanks to Simon Perreault for highlighting the interaction of dynamic
connections with PCP-created mappings.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.2827"?>
<?rfc include='reference.I-D.ietf-softwire-dual-stack-lite'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate-stateful'?>
<?rfc include='reference.RFC.4193'?>
<?rfc include='reference.RFC.6056'?>
<reference anchor="proto_numbers"
target="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml">
<front>
<title>Protocol Numbers</title>
<author fullname="IANA" surname="IANA">
<organization></organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.0793'?>
<?rfc include='reference.RFC.4941'?>
<?rfc include='reference.RFC.1918'?>
<?rfc include='reference.RFC.4961'?>
<?rfc include='reference.RFC.3581'?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.5461'?>
<?rfc include='reference.RFC.3424'?>
<?rfc include='reference.I-D.miles-behave-l2nat'?>
<?rfc include='reference.RFC.6092'?>
<?rfc include='reference.I-D.bpw-pcp-upnp-igd-interworking'?>
<?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
<?rfc include='reference.I-D.cheshire-nat-pmp'?>
<?rfc include='reference.I-D.arkko-dual-stack-extra-lite'?>
<reference anchor="IGD"
target="http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf">
<front>
<title>WANIPConnection:1</title>
<author fullname="UPnP Gateway Committee"
surname="UPnP Gateway Committee">
<organization>UPnP Forum</organization>
</author>
<date month="November" year="2001" />
</front>
</reference>
<!--
<reference anchor="IGD-2"
target="http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf">
<front>
<title>Internet Gateway Device (IGD) V 2.0</title>
<author fullname="UPnP Gateway Committee"
surname="UPnP Gateway Committee">
<organization>UPnP Forum</organization>
</author>
<date month="September" year="2010" />
</front>
</reference>
-->
<!--
<reference anchor="PCP-Issues"
target="http://trac.tools.ietf.org/wg/pcp/trac/report/1">
<front>
<title>PCP Active Tickets</title>
<author fullname="PCP Working Group" surname="PCP Working Group">
<organization>IETF</organization>
</author>
<date month="January" year="2011" />
</front>
</reference>
-->
<reference anchor="I-D.bpw-pcp-proxy">
<front>
<title>Port Control Protocol (PCP) Proxy Function</title>
<author fullname="Mohammed Boucadair" initials="M"
surname="Boucadair">
<organization></organization>
</author>
<author fullname="Reinaldo Penno" initials="R" surname="Penno">
<organization></organization>
</author>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization></organization>
</author>
<author fullname="Francis Dupont" initials="F" surname="Dupont">
<organization></organization>
</author>
<date day="27" month="February" year="2011" />
<abstract>
<t>This document specifies the behavior of a PCP Proxy element,
for instance embedded in Customer Premise routers.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-bpw-pcp-proxy-00" />
<format target="http://www.ietf.org/internet-drafts/draft-bpw-pcp-proxy-00.txt"
type="TXT" />
</reference>
<!--
<reference anchor="I-D.wing-pcp-nested-nat">
<front>
<title>Using PCP With One Nested NAT</title>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization></organization>
</author>
<date month="January" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-wing-pcp-nested-nat-00" />
<format target="http://www.ietf.org/internet-drafts/draft-wing-pcp-nested-nat-00.txt"
type="TXT" />
</reference>
-->
</references>
<section title="Change History">
<t>[Note to RFC Editor: Please remove this section prior to
publication.]</t>
<section title="Changes from draft-ietf-pcp-base-06 to -07">
<t><list style="symbols">
<t>tightened up THIRD_PARTY security discussion. Removed "highest numbered
address", and left it as simply "the CPE's IP address".</t>
<t>removed UNABLE_TO_DELETE_ALL error.</t>
<t>renumbered Opcodes</t>
<t>renumbered some error codes</t>
<t>assigned value to IMPLICIT_MAPPING_EXISTS.</t>
<t>UNPROCESSED can include arbitrary number of option codes.</t>
<t>Moved lifetime fields into common request/response headers</t>
<t>We've noticed we're having to repeatedly explain to people that the
"requested port" is merely a hint, and the NAT gateway is free to ignore it.
Changed name to "suggested port" to better convey this intention.</t>
<t>Added NAT-PMP transition section</t>
<t>Separated Internal Address, External Address, Remote Peer Address definition</t>
<t>Unified Mapping, Port Mapping, Port Forwarding definition</t>
<t>adjusted so DHCP configuration is non-normative.</t>
<t>mentioned PCP refreshes need to be sent over the same
interface.</t>
<t>renamed the REMOTE_PEER_FILTER option to FILTER.</t>
<t>Clarified FILTER option to allow sending an ICMP error if
policy allows.</t>
<t>for MAP, clarified that if the PCP client changed its IP
address and still wants to receive traffic, it needs to send a new
MAP request.</t>
<t>clarified that PEER requests have to be sent from same
interface as the connection itself.</t>
<t>for MAP opcode, text now requires mapping be deleted when
lifetime expires (per consensus on 8-Mar interim meeting)</t>
<t>PEER OpCode: better description of remote peer's IP address,
specifically that it does not control or establish any filtering,
and explaining why it is 'from the PCP client's perspective'.</t>
<t>Removed latent text allowing DMZ for 'all protocols'
(protocol=0). Which wouldn't have been legal, anyway, as protocol
0 is assigned by IANA to HOPOPT (thanks to James Yu for catching
that one).</t>
<t>clarified that PCP server only listens on its internal
interface.</t>
<t>abandoned 'target' term and reverted to simplier
'internal' term.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-05 to -06">
<t><list style="symbols">
<t>DS-Lite: consensus was encapsulation mode. Included a
suggestion that the B4 will need to proxy PCP-to-PCP and
UPnP-to-PCP.</t>
<t>defined THIRD_PARTY option to work with the PEER OpCode, too.
This meant moving it to its own section, and having both MAP and
PEER OpCodes reference that common section.</t>
<t>used "target" instead of "internal", in the hopes that
clarifies internal address used by PCP itself (for sending its
packets) versus the address for MAPpings.</t>
<t>Options are now required to be ordered in requests, and
ordering has to be validated by the server. Intent is to ease
server processing of mandatory-to-implement options.</t>
<t>Swapped Option values for the mandatory- and
optional-to-process Options, so we can have a simple
lowest..highest ordering.</t>
<t>added MISORDERED_OPTIONS error.</t>
<t>re-ordered some error messages to cause MALFORMED_REQUEST
(which is PCP's most general error response) to be error 1,
instead of buried in the middle of the error numbers.</t>
<t>clarified that, after successfully using a PCP server, that PCP
server is declared to be non-responsive after 5 failed
retransmissions.</t>
<t>tightened up text (which was inaccurate) about how long general
PCP processing is to delay when receiving an error and if it
should honor OpCode-specific error lifetime. Useful for MAP errors
which have an error lifetime. (This all feels awkward to have only
some errors with a lifetime.)</t>
<t>Added better discussion of multiple interfaces, including
highlighting WiFi+Ethernet. Added discussion of using IPv6 Privacy
Addresses and RFC1918 as source addresses for PCP requests. This
should finish the section on multi-interface issues.</t>
<t>added some text about why server might send SERVER_OVERLOADED,
or might simply discard packets.</t>
<t>Dis-allow internal-port=0, which means we dis-allow using PCP
as a DMZ-like function. Instead, ports have to be mapped
individually.</t>
<t>Text describing server's processing of PEER is tightened
up.</t>
<t>Server's processing of PEER now says it is
implementation-specific if a PCP server continues to allow the
mapping to exist after a PEER message. Client's processing of PEER
says that if client wants mapping to continue to exist, client has
to continue to send recurring PEER messages.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-04 to -05">
<t><list style="symbols">
<t>tweaked PCP common header packet layout.</t>
<t>Re-added port=0 (all ports).</t>
<t>minimum size is 12 octets (missed that change in -04).</t>
<t>removed Lifetime from PCP common header.</t>
<t>for MAP error responses, the lifetime indicates how long the
server wants the client to avoid retrying the request.</t>
<t>More clearly indicated which fields are filled by the server on
success responses and error responses.</t>
<t>Removed UPnP interworking section from this document. It will
appear in <xref
target="I-D.bpw-pcp-upnp-igd-interworking"></xref>.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-03 to -04">
<t><list style="symbols">
<t>"Pinhole" and "PIN" changed to "mapping" and "MAP".</t>
<t>Reduced from four MAP OpCodes to two. This was done by
implicitly using the address family of the PCP message itself.</t>
<t>New option THIRD_PARTY, to more carefully split out the case
where a mapping is created to a different host within the
home.</t>
<t>Integrated a lot of editorial changes from Stuart and
Francis.</t>
<t>Removed nested NAT text into another document, including the
IANA-registered IP addresses for the PCP server.</t>
<t>Removed suggestion (MAY) that PCP server reserve UDP when it
maps TCP. Nobody seems to need that.</t>
<t>Clearly added NAT and NAPT, such as in residential NATs, as
within scope for PCP.</t>
<t>HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE</t>
<t>Added 'Lifetime' field to the common PCP header, which replaces
the functions of the 'temporary' and 'permanent' error types of
the previous version.</t>
<t>Allow arbitrary Options to be included in PCP response, so that
PCP server can indicate un-supported PCP Options. Satisfies PCP
Issue #19</t>
<t>Reduced scope to only deal with mapping protocols that have
port numbers.</t>
<t>Reduced scope to not support DMZ-style forwarding.</t>
<t>Clarified version negotiation.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-02 to -03">
<t><list style="symbols">
<t>Adjusted abstract and introduction to make it clear PCP is
intended to forward ports and intended to reduce application
keepalives.</t>
<t>First bit in PCP common header is set. This allows DTLS and
non-DTLS to be multiplexed on same port, should a future update to
this specification add DTLS support.</t>
<t>Moved subscriber identity from common PCP section to MAP*
section.</t>
<t>made clearer that PCP client can reduce mapping lifetime if it
wishes.</t>
<t>Added discussion of host running a server, client, or symmetric
client+server.</t>
<t>Introduced PEER4 and PEER6 OpCodes.</t>
<t>Removed REMOTE_PEER Option, as its function has been replaced
by the new PEER OpCodes.</t>
<t>IANA assigned port 44323 to PCP.</t>
<t>Removed AMBIGUOUS error code, which is no longer needed.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-01 to -02">
<t><list style="symbols">
<t>more error codes</t>
<t>PCP client source port number should be random</t>
<t>PCP message minimum 8 octets, maximum 1024 octets.</t>
<t>tweaked a lot of text in section 7.4, "Opcode-Specific Server
Operation".</t>
<t>opening a mapping also allows ICMP messages associated with
that mapping.</t>
<t>PREFER_FAILURE value changed to the mandatory-to-process
range.</t>
<t>added text recommending applications that are crashing obtain
short lifetimes, to avoid consuming subscriber's port quota.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-00 to -01">
<t><list style="symbols">
<t>Significant document reorganization, primarily to split base
PCP operation from OpCode operation.</t>
<t>packet format changed to move 'protocol' outside of PCP common
header and into the MAP* opcodes</t>
<t>Renamed Informational Elements (IE) to Options.</t>
<t>Added REMOTE_PEER (for disambiguation with dynamic ports),
REMOTE_PEER_FILTER (for simple packet filtering), and
PREFER_FAILURE (to optimize UPnP IGD interworking) options.</t>
<t>Is NAT or router behind B4 in scope?</t>
<t>PCP option MAY be included in a request, in which case it MUST
appear in a response. It MUST NOT appear in a response if it was
not in the request.</t>
<t>Result code most significant bit now indicates
permanent/temporary error</t>
<t>PCP Options are split into mandatory-to-process ("P" bit), and
into Specification Required and Private Use.</t>
<t>Epoch discussion simplified.</t>
</list></t>
</section>
</section>
<!--
<section anchor="discovery_analysis"
title="Analysis of Techniques to Discover PCP Server">
<t><list style="empty">
<t>[Ed. Note: This Appendix will be removed in a later version of
this document. It is included here for reference and discussion
purposes. This is tracked as PCP Issue #8 <xref
target="PCP-Issues"></xref>.]</t>
</list></t>
<t><list style="empty">
<t>Discussion Note: A deployment model is a non-PCP aware NAT in a
home, and a PCP-aware CGN operated by the ISP. For example, the home
users purchased a NAT last year at a computer shop (to extend their
home's WiFi network). This could work by having the host use UPnP
IGD with the in-home NAT, and the host use PCP with the LSN. But
this deployment model is impossible with several of the mechanisms
below. Is this deployment model important, or can we wait for PCP to
be enabled on CPE?</t>
</list></t>
<t>Several mechanisms for discovering the PCP server can be envisaged as
listed below:</t>
<t><list style="numbers">
<t>A special-purpose IPv4 or IPv6 address, assigned by IANA, which
is routed normally until it hits a PCP server, which responds. <list
style="empty">
<t>Analysis: This solution can be deployed in the context of
DS-Lite architecture. Concretely, a well-known IPv4 address can
be used to reach a PCP server embedded in the device that embeds
the AFTR capabilities. Since all IPv4 messages issued by a
DS-Lite CP router will be encapsulated in IPv6, no state
synchronisation issues will be experienced because PCP messages
will be handled by the appropriate PCP server.</t>
<t>In some deployment scenarios (e.g., deployment of several
stateful NAT64/NAT46 in the same domain), the use of this
address is not recommended since PCP messages, issued by a given
host, may be handled by a PCP server embedded in a NAT node
which is not involved to handle IP packets issued from that
host. The use of this special-purpose IP address may induce
session failures and therefore the customer may experience
troubles when accessing its services.</t>
<t>Consequently, the use of a special-purpose IPv4 address is
suitable for DS-Lite NAT44. As for NAT46/NAT64, this is left to
the Service Providers according to their deployment
configuration.</t>
<t>The special-use address MUST NOT be advertised in the global
routing table. Packets with that destination address SHOULD be
filtered so they are not transmitted on the Internet.</t>
</list></t>
<t>Assume the default router is a PCP server, and send PCP packets
to the IP address of the default router. <list style="empty">
<t>Analysis: This solution is not suitable for DS-Lite NAT44 nor
for all variants of NAT64/NAT46. <list style="empty">
<t>In the context of DS-Lite: There is no default IPv4
router configured in the CP router. All outgoing IPv4
traffic is encapsulated in IPv6 and then forwarded to a
pre-configured DS-Lite AFTR device. Furthermore, if IPv6 is
used to reach the PCP server, the first router may not be
the one which embeds the AFTR.</t>
<t>For NAT64/NAT46 scenarios: The NAT function is not
embedded in the first router, therefore this solution
candidate does not allow to discover a valid PCP server.</t>
</list></t>
<t>Therefore, this alternative is not recommended.</t>
</list></t>
<t>Service Location Protocol (<xref
target="RFC2608">SLP</xref>).<list style="empty">
<t>Analysis: This solution is not suitable in scenarios where
multicast is not enabled. SLP is a chatty protocol. Also, as
with UPnP IGD's use of SSDP, SLP will discover NAT gateways
which exist on the local network, but are not actually on the
path that packets will take from the Internal Host to the
Internet, leading to the situation where Internal Hosts create
apparently-successful mappings, which are in fact completely
worthless for the purpose of establishing useful communication
with Remote Hosts on the Internet. This alternative is not
recommended.</t>
</list></t>
<t>NAPTR. The host would issue a DNS query for a NAPTR record,
formed from some bits of the host's IPv4 or IPv6 address. For
example, a host with the IPv6 address 2001:db8:1:2:3:4:567:89ab
would first send an NAPTR query for
3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements,
representing a /64 network prefix), which returns the PCP server's
IPv6 address. A similar scheme can be used with IPv4 using, for
example, the first 24 bits of the IPv4 address.<list style="empty">
<t>Analysis: This solution candidate requires more configuration
effort by the Service Provider so as to redirect a given client
to the appropriate PCP server. Any change of the engineering
policies (e.g., introduce new LSN device, load-based
dimensioning, load-balancing, etc.) would require to update the
zone configuration. This would be a hurdle for the flexibility
of the operational networks. Adherence to DNS is not encouraged
and means which allows for more flexibility are to be
promoted.</t>
<t>Therefore, this mechanism is not recommended.</t>
</list></t>
<t>New DHCPv6/DHCP option and/or a RA option to convey an FQDN of a
PCP server.<list style="empty">
<t>Analysis: Since DS-Lite and NAT64/NAT46 are likely to be
deployed in provider-provisioned environments, DHCP (both DHCPv6
and IPv4 DHCP) is convenient to provision the address/FQDN of
the PCP server.</t>
</list></t>
</list></t>
</section>
-->
<!--
<section title="Contributors' Addresses">
<t>The following individuals contributed substantial text to this
document and are listed in alphabetical order:</t>
<figure>
<artwork align="left"><![CDATA[
Stuart Cheshire
Apple, Inc.
1 Infinite Loop
Cupertino, California 95014
USA
Phone: +1 408 974 3207
Email: cheshire@apple.com
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Reinaldo Penno
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, California 94089
USA
Email: rpenno@juniper.net
Francis Dupont
Internet Systems Consortium
Email: fdupont@isc.org
]]></artwork>
</figure>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:47 |