One document matched: draft-ietf-pcp-base-06.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-06" 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 (target) 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 (or control) 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, removing
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">RFC 2119</xref>.</t>
<t><list style="hanging">
<t hangText="Internal Host, Target
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., 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="Target Address, External Address, Remote Peer Address:"><vspace
blankLines="0" />The address of an Internal Host served by a NAT
gateway (typically a private address <xref target="RFC1918"></xref>)
or an Internal Host protected by a firewall. <vspace
blankLines="1" />An External Address is 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.
<vspace blankLines="1" />A Remote Peer Address is 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 my 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., PCP to PCP proxy, UPnP IGD to PCP proxy) or if
the target host does not implement PCP.</t>
<t hangText="Mapping:"><vspace blankLines="0" />A NAT mapping
creates a relationship between an internal (target) IP transport address and
an external IP transport address. More specifically, it creates a
translation rule where packets destined to the external IP and port
are translated to the target IP and port. 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 vice
versa, and this "Mapping" indicates to the firewall that traffic to
and from this internal port number is permitted to pass. See also
Port Forwarding.</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. Explicit dynamic mappings are created as a result of PCP MAP
requests. 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 are created by
manual configuration (e.g., command language interface or web page)
and differ from dynamic mappings in that their lifetime is typically
infinite (they exist until manually removed) but otherwise they
behave exactly the same as dynamic mappings. 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="Port Forwarding, Port Mapping:"><vspace
blankLines="0" />Port forwarding (or port mapping) allows a host to
receive traffic sent to a specific IP address and port. <vspace
blankLines="1" /> In the context of a NAT or NAPT, the Internal
Address and External Address are different. In the context of a pure
firewall, the Internal Address and External Address are the same. In
both contexts, if an internal host is listening to connections on a
specific port (that is, operating as a server), the external IP
address and port number need to be port forwarded to the internal IP
address and port number, which may be the same, in the case of a
pure firewall. In the context of a NAPT, it is possible that both
the IP address and port are modified. For example with a NAPT, a
webcam might be listening on port 80 on its internal address
192.168.1.1, while its publicly-accessible external address is
192.0.2.1 and port is 12345. The NAT does 'port forwarding' of one
to the other.</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 of a given
subscriber. A PCP Client can issue PCP request on behalf of a third
party device of the same subscriber. 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. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Version = 0 |R| OpCode | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Reserved (48 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="1">A single bit set to 1. This allows DTLS and
non-DTLS to be multiplexed on same port, should a future update to
this specification add DTLS support.</t>
<t hangText="Version:">This document specifies protocol version 0.
Should later updates to this document specify different message
formats with a version number greater than zero, the first two
bytes of those new message formats will still 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>
</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Version = 0 |R| OpCode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) OpCode-specific response data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="1">A single bit set to 1.</t>
<t hangText="Ver:">This document specifies protocol version 0.
Should later updates to this document specify different message
formats with a version number greater than zero, the first four
bytes of those new message formats will still contain the version
number, opcode, and result code, as shown here, so that a PCP
client 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 client is too old and needs to be updated to
work with the PCP server, or whether the PCP server is too old and
needs to be updated to work with this client.</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="Epoch:">The server's Epoch value. See <xref
target="epoch"></xref> for discussion. This value is set 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. It is anticipated that Options will include
information which are associated with the normal function of an
OpCode. For example, an Option could indicate DSCP <xref
target="RFC2474"></xref> markings to apply to incoming or outgoing
traffic associated with a PCP mapping, or an Option could include
descriptive text (e.g., "for my webcam").</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 in units of 4 octets the
length of the enclosed data. 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 or a response,
as permitted by that Option. If a given Option was included in
a request, and understood and processed by the PCP server, it
MUST be included in the response. 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 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>To enhance interoperability, newly defined Options SHOULD
NOT be interdependent with each other. 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:</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">MALFORMED_REQUEST, a general catch-all error.</t>
<t hangText="2">UNSUPP_OPCODE, unsupported OpCode. </t>
<t hangText="3">UNSUPP_OPTION, unsupported Option. This error only
occurs if the Option is in the mandatory-to-process range. </t>
<t hangText="4">MALFORMED_OPTION, malformed Option (e.g., exists
too many times, invalid length).</t>
<t hangText="5">UNSPECIFIED_ERROR, server encountered unspecified
error. </t>
<t hangText="6">UNSUPP_VERSION, unsupported version. </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, and the PCP server MUST
listen for PCP requests on the PCP port number, 44323. 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), the address(es) of the PCP server(s) used as the list of
PCP server(s), else;</t>
<t>if DHCP indicates the PCP server(s), the address(es) of the
indicated PCP server(s) are used as the 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>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. It initializes a retransmission
timer to 4 seconds. (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 sends a PCP message to each server in
sequence, waiting for a response until its timer expires. Once a PCP
client has successfully communicated with a PCP server, it continues
communicating with that PCP server until that PCP server has not
responded to 5 retransmissions, which causes the PCP client to attempt to re-iterate
the procedure starting with the first PCP server on its list. If a
hard ICMP error is received the PCP client SHOULD immediately abort
trying to contact that PCP server (see Section 2 of <xref
target="RFC5461"></xref> for discussion of ICMP and ICMPv6 hard
errors). If no response is received from any of those servers, it
doubles its retransmission timer and tries each server again. This
is repeated 4 times (for a total of 5 transmissions to each server).
If, after these transmissions, the PCP client has still not received
a response, the PCP client SHOULD abort the procedure.</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>Upon receiving a PCP request 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 request is simply dropped. If the
version number is not supported, a response is generated containing
the UNSUPP_VERSION response 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).</t>
<t>If the OpCode is not supported, a response is generated with the
UNSUPP_OPCODE response 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 response 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 response code is 0, the PCP client knows the request was
successful.</t>
<t>If the response code is not 0, the request failed. If
the response code is UNSUPP_VERSION, processing continues as
described in <xref target="version"></xref>. If the
response code is SERVER_OVERLOADED, clients SHOULD NOT send
*any* further requests to that PCP server for the time
indicated by that OpCode's response, if present (e.g., the
lifetime field of a MAP response), or 30 seconds have
elapsed. For other error response codes, The PCP client
SHOULD NOT resend the same request for the time indicated by
that OpCode's response, if present (e.g., the lifetime field
of a MAP response), or 30 seconds have elapsed.</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>Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited
scope (e.g., <xref target="RFC1918"></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 the same global IPv6 prefix.</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 indicates to the
PCP client 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>
</section>
<section anchor="version" title="Version negotiation">
<t>A PCP client sends its requests using PCP version number 0.
Should later updates to this document specify different message
formats with a version number greater than zero it is expected that
PCP servers will still support version 0 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 zero 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
response 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 response 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 response 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. For simplicity, no more than 4 options can be encoded. This
option MUST NOT appear more than once in a PCP response, no matter
how many PCP options appeared in the request and were unprocessed by
the PCP server. If only one Option code was unprocessed, that option
code it is placed in option-code-1 (and the other three fields are
set to zero), if two Option codes were unprocessed, their option
codes are placed in option-code-1 and option-code-2, and so on. 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. This Option MUST NOT appear
more than once.</t>
<figure anchor="fig_unprocessed" title="UNPROCESSED option">
<preamble>The UNPROCESSED option is formatted as
follows:</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 | option-code-3 | option-code-4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code-5 | option-code-6 | option-code-7 | option-code-8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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</t>
<t>may appear in: responses, and only if the response 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
(usually) initiates outbound connections from that same source
address. 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 four OpCodes which control forwarding from a NAT
(or firewall) to an internal target host. They are: <list hangIndent="11"
style="hanging">
<t hangText=" MAP4=0:">create a mapping between an internal target address
and external IPv4 address (e.g., NAT44, NAT64, or firewall)</t>
<t hangText=" MAP6=1:">create a mapping between an internal target address
and external IPv6 address (e.g., NAT46, NAT66, or firewall)</t>
</list></t>
<t>The internal target 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 both match the request's source
IP address and MAP OpCode's internal IP address, the functionality is
purely a firewall; otherwise it pertains to a network address
translator which might also perform firewall 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Requested external IP address (32 or 128, depending on OpCode):
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | requested external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<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 means "all protocols" (supported by the
PCP server), which is useful to create mappings for all protocols
with a <xref target="RFC3022">Basic NAT</xref> or a firewall, and
used to delete mappings for all protocols.</t>
<t hangText="Reserved:">24 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Requested External IP Address:">Requested 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>
<t hangText="Requested lifetime:">Requested lifetime of this
mapping, in seconds.</t>
<t hangText="Internal port:">Internal port for the mapping.
The value 0 MUST NOT be sent.</t>
<t hangText="Requested external port:">requested 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>
</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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Assigned external IP address (32 or 128, depending on OpCode) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Lifetime :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | assigned external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<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="Lifetime:">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="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. IPv4 or IPv6
address is indicated by the OpCode. If the NAT gateway can
allocate the requested 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 requested 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 requested external
port include when the requested external port is prohibited by
policy, already used by the NAT gateway for one of its own
services (e.g., port 80 for the NAT gateway's own configuration
pages) already allocated to another explicit mapping (by static
manual allocation or by a prior PCP request by a different
Internal Host) or the rare case where the requested external port
was already allocated to an implicit mapping which cannot be
'promoted' to an explicit mapping for this Internal Host (a
different Internal Host already made a prior outbound connection
for which the NAT gateway happened to assign the external port
requested in this explicit PCP request). On error responses, this
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, e.g., NAT device has not
obtained a DHCP lease so cannot perform a MAP operation. 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 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">UNABLE_TO_DELETE_ALL, indicates the PCP server
was not able to delete all mappings. This is a short lifetime
error.</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 requested-external-ip-address
and requested-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 IP address and port(s).</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 positive 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 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, the server MUST generate
a MALFORMED_REQUEST error.</t>
<t>If the requested lifetime is 0, it indicates a request to
delete the mapping immediately. On a deletion request, the
requested external port field is ignored by the server. PCP
MAP requests only control mappings created by MAP
requests. So, if the PCP client attempts to delete a static
mapping (i.e., a mapping created outside of PCP itself), the
PCP server deletes all of the PCP-created mappings but MUST
respond with UNABLE_TO_DELETE_ALL result code, with the other
fields encoded as described above. If the PCP client attempts
to delete a mapping that does not exist, the success response
code is returned. If the PCP client is not authorized to
delete this mapping, NOT_AUTHORIZED is returned. If the
deletion request was properly formatted, a positive response
is generated with lifetime of 0 and the server copies the
protocol and internal port number from the request into the
response; this positive response is generated even if there is
no mapping (because the mapping could have been already
deleted by a previous PCP transaction).</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 greater than 128 exists 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 the indicated
target IP address belongs to the same subscriber. 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 does not
belong to the subscriber, 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 response 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
as described in the request and a positive response is built. This
positive result 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 response 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>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 NOT RECOMMENDED that the
server allow lifetimes exceeding 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). However, if the PCP lifetime has
reached zero yet there is still active inside-to-outside traffic,
the PCP server MAY, if it desires, keep the mapping active until the
inside-to-outside traffic has stopped.</t>
<t>An application that forgets its PCP-assigned mappings (e.g., the
application or OS crashes) will request new PCP mappings. This will
consume port mappings. 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 no explicit protection against such
port consumption. In such environments, it is RECOMMENDED that
applications use shorter PCP lifetimes to reduce the impact of
consuming the user's port quota. An operating system or framework
that issues a mapping request to "delete all" (protocol=0, port=0,
lifetime=0) on reboot protects itself against this resource
exhaustion by voluntarily relinquishing all of its old mappings
before beginning to request new ones. The PCP server MAY chose to
allocate the same (recently relinquished) mappings when mappings are
re-requested by the booting OS. 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 target to re-acquire the same port during
that same interval.</t>
<t>When a PCP client first acquires a new IP address, it may want to
remove mappings that may have been instantiated for a previous host.
To do this, the PCP client sends a MAP request with protocol,
external port, internal port, and lifetime set to 0.</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 requested 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="remote_peer_filter" title="REMOTE_PEER_FILTER">
<t>This Option indicates packet filtering 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
simply drop packets with a source IP address, transport, or port
that do not match the fields.</t>
<figure anchor="fig_remote_peer_filter"
title="REMOTE_PEER_FILTER option layout">
<preamble>The REMOTE_PEER_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: REMOTE_PEER_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. Other
use by a PCP client is NOT RECOMMENDED and 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
response code.</t>
<t>If multiple occurrences of REMOTE_PEER_FILTER 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 REMOTE_PEER_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 REMOTE_PEER_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 REMOTE_PEER_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 REMOTE_PEER_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>
<t>If this option appears in a request, the following addition
result code could be returned:<list style="hanging">
<t hangText="27">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_PEER_FILTER Option. This is a long lifetime
error.</t>
</list></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: 2 or 5</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 requested 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 requested. 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.</t>
<t>As the result of receiving a packet where the Epoch field
indicates that a reboot or similar loss of state has occurred, the
client renews its port mappings.</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 port mapping 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>
</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=2:">Set or query lifetime for flow from IPv4
address to a remote peer's IPv4 address.</t>
<t hangText=" PEER6=3:">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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP address (32 bits if PEER4, 128 bits if PEER6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Reserved (128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| remote peer port | reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<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="Remote Peer IP Address:">Remote peer's IP address,
from the perspective of the PCP client.</t>
<t hangText="Reserved:">128 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="Requested lifetime:">Requested lifetime of this
mapping, in seconds. Unlike the MAP OpCode, there is no special
meaning of 0.</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>
</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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP address (32 bits if PEER4, 128 bits if PEER6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: External IP address (always 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| remote peer port | reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<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. Values are from IANA's address family numbers
(IPv4 is 1, IPv6 is 2). For error responses, the value MUST be
0.</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. If 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. For error responses, this MUST be 0.</t>
<t hangText="Assigned Lifetime:">For success responses, this is
the assigned lifetime, in seconds. For error responses, this is
0.s</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>
</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.</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.</t>
<t>The PEER4 and PEER6 OpCodes contain a description of the socket,
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.</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>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 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.
<list style="empty"><t>Note: 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.</t></list></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, 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 positive 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 target host other than itself. This is used with both
MAP and PEER OpCodes.</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 IPv4 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, 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.</t>
<figure>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Target 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="Mapping Internal IP Address:">Internal IP
address of the mapping. If the length of this Option is
1, this is a 32-bit IPv4 address. If the length of this
Option is 4, this is a 128-bit IPv6 address. This can
contain the special value "0" (all zeros), which
indicates "all addresses associated with this
subscriber" 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: 1 if OpCode is MAP4 or PEER4, 4 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
target IP address specified is not permitted (e.g., the address does
not belong to this subscriber, or is otherwise prohibited.). If this
is a MAP request, this is a long-term error.</t>
<t hangText="52">UNAUTH_SOURCE_ADDRESS, indicates
the source address of this PCP message is not authorized by
the PCP server to use the THIRD_PARTY option.</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 on a subscriber's network network can create,
modify, or destroy mappings for another host on the network,
which is generally undesirable. If third party mappings are
restricted, only a certain host on the subscriber's network
can perform these operations. If a PCP server is configured to
restrict third party mappings, and receives a PCP MCP
request with a Target Address that does not match the source
IP address of that request, it MUST generate a UNAUTH_TARGET_ADDRESS
response.</t>
<t>It is RECOMMENDED that PCP servers embedded into customer premise
equipment be configured to restrict 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. 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). This is because the service provider's PCP
server only allows a PEER or MAP request containing the
THIRD_PARTY option if it has the IP address of the
subscriber's customer premise router. To do this, the PCP
server needs certain knowledge about the network's
subscribers. It needs to determine the IP address of the
subscriber's customer premise router and to determine the IP
subnet assigned to the subscriber. This knowledge might be
dynamic (e.g., database query into the service provider's
user database for every incoming PCP request), might be a
table (e.g., subscribers with a certain IPv4 network prefix
all have an IPv4 /24, other IPv4 prefixes have an IPv4 /32,
certain IPv6 prefixes have an have an IPv6 /32, and so on),
or might be very static (e.g., all subscribers have one IPv4
address). In many common deployments, there is only one IPv4
address assigned to a subscriber, and thus the Target
Address will always match the source address of the PCP
message. If there are multiple IPv4 or multiple IPv6
addresses assigned to a subscriber, the PCP server allows
the highest-numbered address to use the THIRD_PARTY
option. Thus, on a network supporting PCP with multiple
addresses assigned to a subscriber, the highest-numbered
host SHOULD be the subscriber's customer premise
router. Upon receiving a MAP or PEER request where the Target
Address does not match the source IP address of the request,
the PCP server determines if the source IP address of the
request is the subscriber's highest numbered address,
following the procedure above. If not, the PCP server MUST
generate an UNAUTH_SOURCE_ADDRESS error. Then the PCP server
determines if the Target Address belongs to the same
subscriber as the source IP address of the PCP packet, using
the procedure described above. If not, 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 dynamic explicit mappings (i.e., those created by PCP) for
all hosts belonging to the same subscriber. This is done by sending a
PCP MAP request including the THIRD_PARTY option with its Target
Address field set to 0.</t>
</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 language 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 title="Per-Subscriber Port Forwarding Quota" anchor="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., TCP
SYNs) and explicit dynamic mappings (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 will necessarily use the
THIRD_PARTY option with the MAP and PEER OpCodes.</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>The PCP client's source port SHOULD be randomly generated <xref
target="RFC6056"></xref>. The PCP server MUST only listen for requests
from its internal interfaces, and MUST NOT listen for requests on its
Internet-facing interfaces.</t>
<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="I-D.ietf-v6ops-cpe-simple-security"></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 Target Address">
<t>The THIRD_PARTY Option contains a Target 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>.</t>
<t>New OpCodes in the range 1-95 can be created via <xref
target="RFC5226">Standards Action</xref>, and the range 96-128 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="remote_peer_filter"></xref>, <xref target="peer_result_codes"></xref>,
and <xref target="third_party"></xref>.</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>, and the option values 0 and 255 are
reserved.</t>
<t>New PCP option codes in the range 0-63 and 128-192 can be created
via <xref target="RFC5226">Standards Action</xref>, and the range
64-127 and 192-255 is for <xref target="RFC5226">Private
Use</xref>.</t>
</section>
</section>
<section title="Acknowledgments">
<t>Thanks to Alain Durand, Christian Jacquenet, Jacni Qin, and
Simon Perreault 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.2474'?>
<?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.I-D.ietf-v6ops-cpe-simple-security'?>
<?rfc include='reference.I-D.bpw-pcp-upnp-igd-interworking'?>
<?rfc include='reference.RFC.6092'?>
<?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>
-->
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='I-D.bpw-pcp-proxy'>
<front>
<title>Port Control Protocol (PCP) Proxy Function</title>
<author initials='M' surname='Boucadair' fullname='Mohammed Boucadair'>
<organization />
</author>
<author initials='R' surname='Penno' fullname='Reinaldo Penno'>
<organization />
</author>
<author initials='D' surname='Wing' fullname='Dan Wing'>
<organization />
</author>
<author initials='F' surname='Dupont' fullname='Francis Dupont'>
<organization />
</author>
<date month='February' day='27' 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 type='TXT'
target='http://www.ietf.org/internet-drafts/draft-bpw-pcp-proxy-00.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="Changes">
<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>Response 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:42 |