One document matched: draft-ietf-pcp-base-08.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-08" 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>The Port Control Protocol (PCP) provides a mechanism to control how
incoming packets are forwarded by upstream devices such as NAT64, NAT44,
and firewall devices, and a mechanism to reduce application keepalive
traffic. PCP is primarily designed to be implemented in the context of
both Carrier-Grade NATs (CGN) and small NATs (e.g., residential NATs).
PCP allows hosts to operate server for a long time (e.g., a webcam) or a
short time (e.g., while playing a game or on a phone call) when behind a
NAT device, including when behind a CGN operated by their Internet
service provider.</t>
<t>PCP allows applications to create mappings from an external IP
address and port to an internal IP address and port. These mappings are
required for successful inbound communications destined to machines
located behind a NAT or a firewall.</t>
<t>After creating a mapping for incoming connections, it is necessary to
inform remote computers about the IP address and port for the incoming
connection. This is usually done in an application-specific manner. For
example, a computer game would use a rendezvous server specific to that
game (or specific to that game developer), and a SIP phone would use a
SIP proxy. PCP does not provide this rendezvous function. The rendezvous
function will support IPv4, IPv6, or both. Depending on that support and
the application's support of IPv4 or IPv6, the PCP client will need an
IPv4 mapping, an IPv6 mapping, or both.</t>
<t>Many NAT-friendly applications send frequent application-level
messages to ensure their session will not be timed out by a NAT. These
are commonly called "NAT keepalive" messages, even though they are not
sent to the NAT itself (rather, they are sent 'through' the NAT). These
applications can reduce the frequency of those NAT keepalive messages by
using PCP to learn (and influence) the NAT mapping lifetime. This helps
reduce bandwidth on the subscriber's access network, traffic to the
server, and battery consumption on mobile devices.</t>
<t>Many NATs and firewalls have included application layer gateways
(ALGs) to create mappings for applications that establish additional
streams or accept incoming connections. ALGs incorporated into NATs
additionally modify the application payload. Industry experience has
shown that these ALGs are detrimental to protocol evolution. PCP allows
an application to create its own mappings in NATs and firewalls,
reducing the incentive to deploy ALGs in NATs and firewalls.</t>
</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 (DS-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>IPv4 and <xref target="RFC6092">IPv6 simple firewall
control</xref>.</t>
</list></t>
</section>
<section title="Supported Protocols">
<t>The PCP OpCodes defined in this document are designed to support
transport-layer protocols that use a 16-bit port number (e.g., TCP, UDP,
SCTP, DCCP). 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 a "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 it is
seen by the firewall or rewritten by the NAT. 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 (because the other NATs would likely
have the necessary port mapped to another host).</t>
</section>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">"Key words for use in RFCs to Indicate Requirement
Levels"</xref>.</t>
<t><list style="hanging">
<t hangText="Internal Host:"><vspace blankLines="0" />A host served
by a NAT gateway, or protected by a firewall. This is the host that
receives the incoming traffic created by a PCP MAP request, or the
host that initiated an implicit dynamic mapping (e.g., by sending a
TCP SYN) across a firewall or a NAT.</t>
<t hangText="Remote Host:"><vspace blankLines="0" />A host with
which an Internal Host is communicating.</t>
<t hangText="Internal Address:"><vspace blankLines="0" /> The
address of an Internal Host served by a NAT gateway (typically a
private address <xref target="RFC1918"></xref>) or protected by a
firewall.</t>
<t hangText="External Address:"><vspace blankLines="0" /> The
address of an Internal Host as seen by other Remote Hosts on the
Internet with which the Internal Host is communicating, after
translation by any NAT gateways on the path. An External Address is
generally a public routable (i.e., non-private) address. In the case
of an Internal Host protected by a pure firewall, with no address
translation on the path, its External Address is the same as its
Internal Address.</t>
<t hangText="Remote Peer Address:"><vspace blankLines="0" /> The
address of a Remote Host, as seen by the Internal Host. A Remote
Address is generally a public routable address. In the case of a
Remote Host that is itself served by a NAT gateway, the Remote
Address may in fact be the Remote Host's External Address, but since
this remote translation is generally invisible to software running
on the Internal Host, the distinction can safely be ignored for the
purposes of this document.</t>
<t hangText="Third Party:"><vspace blankLines="0" />In the
common case, an Internal Host manages its own Mappings using
PCP requests, and the Internal Address of those Mappings is
the same as the source IP address of the PCP request
packet. <vspace blankLines="1" /> In the case where one
device is managing Mappings on behalf of some other device,
the presence of the THIRD_PARTY option in the MAP request
signifies that the specified address, not the source IP
address of the PCP request packet, should be used as the
Internal Address for the Mapping. For example, this can
occur if the internal host does not implement PCP.</t>
<t hangText="Mapping, Port Mapping, Port Forwarding:"><vspace
blankLines="0" />A NAT mapping creates a relationship between an
internal IP address, protocol, and port and an external IP address,
protocol, and port. More specifically, it creates a translation rule
where packets destined to the external IP and port are translated to
the internal IP and port, and vice versa. In the case of a pure
firewall, the "Mapping" is the identity function, translating an
internal port number to the same external port number, and this
"Mapping" indicates to the firewall that traffic to and from this
internal port number is permitted to pass.</t>
<t hangText="Mapping Types:"><vspace blankLines="0" />There are
three different ways to create mappings: implicit dynamic mappings,
explicit dynamic mappings, and static mappings. Implicit dynamic
mappings are created as a result of a TCP SYN or outgoing UDP
packet, and allow Internal Hosts to receive replies to their
outbound packets. Explicit dynamic mappings are created as a result
of PCP MAP requests. Static mappings are created by manual
configuration (e.g., command-line interface or web page). Explicit
and static mappings allow Internal Hosts to receive inbound traffic
that is not in direct response to any immediately preceding
outbound communication (i.e., allow Internal Hosts to operate a
"server" that is accessible to other hosts on the Internet). Both
implicit and explicit dynamic mappings are dynamic in the sense that
they are created on demand, as requested (implicitly or explicitly)
by the Internal Host, and have a lifetime. After the lifetime, the
mapping is deleted unless the lifetime is extended by action by the
Internal Host (e.g., sending more traffic or sending a new PCP MAP
request). Static mappings differ from dynamic mappings in that their
lifetime is typically infinite (they exist until manually removed)
but otherwise they behave exactly the same as an explicit dynamic
mapping with an infinite lifetime. For example, a PCP MAP request to
create a mapping that already exists as a static mapping will return
a successful result, confirming that the requested mapping
exists.</t>
<t hangText="PCP Client:"><vspace blankLines="0" />A PCP
software instance responsible for issuing PCP requests to a
PCP server. One or several PCP Clients can be embedded in
the same host. Several PCP Clients can be located in the
same local network. A PCP Client can issue PCP request on
behalf of a third party device for which it is authorized to
do so. An interworking function from Universal Plug and Play
Internet Gateway Device (UPnP
IGD, <xref target="IGD"></xref>) to PCP is another example
of a PCP Client. A PCP server in a NAT gateway that is
itself a client of another NAT gateway (nested NAT) may
itself act as a PCP client to the upstream NAT.</t>
<t hangText="PCP Server:"><vspace blankLines="0" />A network element
which receives and processes PCP requests from a PCP client.
Generally this is a PCP-capable NAT gateway or firewall. A NAT
gateway creates mappings determining how it translates packets it
forwards, and PCP enables clients to communicate with the NAT
gateway about those mappings. In principle it is also possible for
the PCP server to be some other device, which in turn communicates
with the NAT gateway using some other network protocol, but this
introduces additional complexity and fragility into the system, and
is a deployment detail which should be implemented in a way that is
invisible to the PCP client. See also <xref
target="relationship"></xref>.</t>
<t hangText="Interworking Function:"><vspace blankLines="0" />a
functional element responsible for interworking another protocol
with PCP. For example interworking between <xref target="IGD">UPnP
IGD</xref> with PCP.</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, from the perspective of a subscriber: source IP
address, destination IP address, protocol, source port number,
destination port number. From the perspective of a NAPT device, in
certain deployments an additional piece of information is necessary
to distinguish subscribers with overlapping IP addresses. This
additional information depends on the deployment scenario, but
examples of the information include the subscriber's IPv6 address
(for the subscriber's Dual-Stack Lite tunnel) or the subscriber's Virtual
LAN number (<xref target="I-D.miles-behave-l2nat"></xref>), or other
similar identifier.</t>
</list></t>
</section>
<section anchor="relationship"
title="Relationship between PCP Server and its NAT/firewall">
<t>The PCP server receives PCP requests. The PCP server might be
integrated within the NAT or firewall device (as shown in <xref
target="diagram_pcp_server_embedded"></xref>) which is expected to be a
common deployment.</t>
<figure anchor="diagram_pcp_server_embedded"
title="NAT or Firewall with Embedded PCP Server">
<artwork align="center"><![CDATA[
+-----------------+
+------------+ | NAT or firewall |
| PCP client |-<network>-+ with +---<Internet>
+------------+ | PCP server |
+-----------------+]]></artwork>
</figure>
<t>It is also possible to operate the PCP server in a separate device
from the NAT, so long as such operation is indistinguishable from the
PCP client's perspective.</t>
</section>
<section title="Common Request and Response Header Format">
<t>All PCP messages contain a request (or response) header containing an
opcode, any relevant opcode-specific information, and zero or more
options. The packet layout for the common header, and operation of the
PCP client and PCP server are described in the following sections. The
information in this section applies to all OpCodes. Behavior of the
OpCodes defined in this document is described in <xref
target="map_opcodes"></xref> and <xref
target="peer_opcodes"></xref>.</t>
<section title="Request Header">
<figure align="left" anchor="common_request"
title="Common Request Packet Format">
<preamble>All requests have the following format:</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 |R| OpCode | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP address (always 128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Version:">This document specifies protocol version 1.
NAT-PMP, a precursor to PCP, specified protocol version 0. Should
later updates to this document specify different message formats
with a version number greater than 1, the first two bytes of those
new message formats will continue to contain the version number
and opcode as shown here, so that a PCP server receiving a message
format newer or older than the version(s) it understands can still
parse enough of the message to correctly identify the version
number, and determine whether the problem is that this server is
too old and needs to be updated to work with the PCP client, or
whether the PCP client is too old and needs to be updated to work
with this server.</t>
<t hangText="R:">Indicates Request (0) or Response (1). All
Requests MUST use 0.</t>
<t hangText="OpCode:">Opcodes are defined in <xref
target="map_opcodes"></xref> and <xref
target="peer_opcodes"></xref>.</t>
<t hangText="Reserved:">16 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Requested Lifetime:">The Requested Lifetime field is
an unsigned 32-bit integer, in seconds, ranging from 0 to
4,294,967,295 seconds. This is used by the MAP and PEER OpCodes
defined in this document for their requested lifetime. Future
OpCodes which don't need this field MUST set the field to zero on
transmission and ignore on reception.</t>
<t hangText="Reserved:">32 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="PCP Client's IP Address:">The IP address of the PCP
client, from the PCP client's perspective. If IPv4, only the first
32 bits are used, the other bits MUST be set to 0.</t>
</list></t>
</section>
<section title="Response Header">
<figure align="left" anchor="common_response"
title="Common Response Packet Format">
<preamble>All responses have the following format:</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 |R| OpCode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP address (always 128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) OpCode-specific response data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Version:">Responses MUST use version 1.</t>
<t hangText="R:">Indicates Request (0) or Response (1). All
Responses MUST use 1.</t>
<t hangText="OpCode:">The OpCode value, copied from the
request.</t>
<t hangText="Reserved:">8 reserved bits, MUST be sent as 0, MUST
be ignored when received. This is set by the server.</t>
<t hangText="Result Code:">The result code for this response. See
<xref target="result_codes"></xref> for values. This is set by the
server.</t>
<t hangText="Lifetime:">The Lifetime field is an unsigned 32-bit
integer, in seconds, ranging from 0 to 4,294,967,295 seconds. On
an error response, this indicates how long clients should assume
they'll get the same error response from that PCP server if they
repeat the same request. On a success response for the
currently-defined PCP OpCodes -- MAP and PEER -- this indicates
the lifetime for this mapping. If future OpCodes are defined that
do not have a lifetime associated with them, then in success
responses for those OpCodes the Lifetime MUST be set to zero on
transmission and MUST be ignored on reception.</t>
<t hangText="Epoch:">The server's Epoch value. See <xref
target="epoch"></xref> for discussion. This value is set in both
success and error responses.</t>
<t hangText="PCP Client's IP Address:">The IP address of the PCP
client, from the PCP server's perspective. If IPv4, only the first
32 bits are used, the other bits MUST be set to 0.</t>
</list></t>
</section>
<section anchor="options" title="Options">
<t>A PCP OpCode can be extended with an Option. Options can be used in
requests and responses. The decision about whether to include a given
piece of information in the base opcode format or in an option is an
engineering trade-off between packet size and code complexity. For
information that is usually (or always) required, placing it in the
fixed opcode data results in simpler code to generate and parse the
packet, because the information is a fixed location in the opcode
data, but wastes space in the packet in the event that that field is
all-zeroes because the information is not needed or not relevant. For
information that is required less often, placing it in an option
results in slightly more complicated code to generate and parse packets
containing that option, but saves space in the packet when that
information is not needed. Placing information in an option also means
that an implementation that never uses that information doesn't even
need to implement code to generate and parse it. For example, a client
that never requests mappings on behalf of some other device doesn't
need to implement code to generate the THIRD_PARTY option, and a PCP
server that doesn't implement the necessary security measures to
create third-party mappings safely doesn't need to implement code to
parse the THIRD_PARTY option.</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:">8 bits. Its highest bit is the "O" bit
and indicates if this Option is mandatory (0) or optional (1) to
process.</t>
<t hangText="Reserved:">8 bits. MUST be set to 0 on transmission
and MUST be ignored on reception.</t>
<t hangText="Option-Length:">16 bits. Indicates the length of the
enclosed data in octets. Options with length of 0 are allowed.</t>
<t hangText="data:">Option data. The option data MUST end on a
32-bit boundary, padded with 0's when necessary.</t>
</list></t>
<t>A given Option MAY be included in a request containing a specific
OpCode. The handling of an Option by the PCP client and PCP server
MUST be specified in an appropriate document and MUST include whether
the PCP Option can appear (one or more times) in a request and/or
response, 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 MAY be encoded in any order by the PCP client and are
processed in the order received.</t>
<t>If, while processing an option, an error is encountered
that causes a PCP error response to be generated, the PCP
request MUST cause no state change in the PCP server or the
PCP-controlled device (i.e., it rolls back any changes it
might have made while processing the request). The response
MUST encode the Options in the same order, but may omit some
PCP Options in the response, as is necessary to indicate the
PCP server does not understand that Option or that Option is
not permitted to be included in responses by the definition of
the Option itself. Additional Options included in the
response (if any) MUST be included at the end. A certain
Option MAY appear more than once in a request or in a
response, if permitted by the definition of the Option
itself. If the Option's definition allows the Option to appear
only once but it appears more than once in a request, the PCP
server MUST respond with the MALFORMED_OPTION result code; if
this occurs in a response, the PCP client processes the first
occurrence and ignores the other occurrences as if they were
not present.</t>
<t>If the "O" bit (high bit) in the OpCode is
clear, <list style="symbols">
<t>the PCP server MUST only generate a positive PCP response if it
can successfully process the PCP request and this Option.</t>
<t>if the PCP server does not implement this Option, or cannot
perform the function indicated by this Option (e.g., due to a
parsing error with the option), it MUST generate a failure
response with code UNSUPP_OPTION or MALFORMED_OPTION (as
appropriate) and include the UNPROCESSED option in the response
(<xref target="unprocessed"></xref>).</t>
</list></t>
<t>If the "O" bit is set, the PCP server MAY process or ignore this
Option, entirely at its discretion.</t>
<t>Option definitions MUST include the information below:</t>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>name: <mnemonic></t>
<t>number: <value></t>
<t>purpose: <textual description></t>
<t>is valid for OpCodes: <list of OpCodes></t>
<t>length: <rules for length></t>
<t>may appear in: <requests/responses/both></t>
<t>maximum occurrences: <count></t>
</list></t>
</list></t>
</section>
<section anchor="result_codes" title="Result Codes">
<t>The following result codes may be returned as a result of any
OpCode received by the PCP server. The only success result code is 0,
other values indicate an error. If a PCP server has encountered
multiple errors during processing of a request, it SHOULD use the most
specific error message.<list style="hanging">
<t hangText="0">SUCCESS, success</t>
<t hangText="1">UNSUPP_VERSION, unsupported version.</t>
<t hangText="2">MALFORMED_REQUEST, indicating the request could
not be successfully parsed.</t>
<t hangText="3">UNSUPP_OPCODE, unsupported OpCode.</t>
<t hangText="4">UNSUPP_OPTION, unsupported Option. This error only
occurs if the Option is in the mandatory-to-process range.</t>
<t hangText="5">MALFORMED_OPTION, malformed Option (e.g., exists
too many times, invalid length).</t>
<t hangText="6">PROCESSING_ERROR, server encountered an error
after parsing while attempting to process a request.</t>
<t hangText="7">SERVER_OVERLOADED, server is processing
too many PCP requests from this client or from other
clients, and requests this client delay sending any other
requests for the time indicated in Lifetime.</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> and <xref
target="third_party"></xref>.</t>
</section>
</section>
<section title="General PCP Operation">
<t>PCP messages MUST be sent over <xref target="RFC0768">UDP</xref>.
Every PCP request generates a response, so PCP does not need to run over
a reliable transport protocol.</t>
<t>PCP is idempotent, so if the PCP client sends the same request
multiple times and the PCP server processes those requests, the same
result occurs. The order of operation is that a PCP client generates and
sends a request to the PCP server, which processes the request and
generates a response back to the PCP client.</t>
<section title="General PCP Client: Generating a Request">
<t>This section details operation specific to a PCP client, for any
OpCode. Procedures specific to the MAP OpCodes are described in <xref
target="map_opcodes"></xref>, and procedures specific to the PEER
OpCodes are described in <xref target="peer_opcodes"></xref>.</t>
<t>Prior to sending its first PCP message, the PCP client determines
which servers to use. The PCP client performs the following steps to
determine its PCP server(s):<list style="numbers">
<t>if a PCP server is configured (e.g., in a configuration file or
DHCP), that single configuration source is used as the list of PCP
server(s), else;</t>
<t>the address of the default router is used as the PCP
server.</t>
</list></t>
<t>With that list of PCP servers, the PCP client formulates its PCP
request. The PCP request contains a PCP common header, PCP OpCode and
payload, and (possibly) Options. As with all UDP or TCP clients on any
operating system, when several PCP clients are embedded in the same
host, each uses a distinct source port number to disambiguate their
requests and replies. The PCP client's source port SHOULD be randomly
generated <xref target="RFC6056"></xref>.</t>
<t>When attempting to contact a PCP server, the PCP client
initializes a timer to 2 seconds. The PCP client sends a PCP
message the first server in its list of PCP servers. If no
response is received before the timer expires, the timer is
doubled (to 4 seconds) and the request is re-transmitted. If
no response is received before the timer expires, the timer is
doubled again (to 8 seconds) and the request is
re-transmitted. This procedure is repeated in parallel or in
series to each PCP server in the list, on each interface,
until a response is received from a PCP server. If the
requests are sent in parallel and responses from multiple PCP
servers are received, only the PCP server closest to the top
of the list, on that interface, is used for subsequent
requests; PCP requests which received a positive response and
create state (e.g., MAP) SHOULD have their state cleared
(e.g., lifetime set to 0).
</t>
<t>Once a PCP client has successfully received a response from
a PCP server on that interface, it sends subsequent PCP
requests to that same server, with a retransmission timer of 2
seconds. If, after 2 seconds, a response is not received from
that PCP server, the same back-off algorithm described above
is performed.</t>
<!--
<t>If, during its transmissions to a PCP server, the PCP client
receives a hard or soft ICMP error (<xref target="RFC5461"></xref>),
the ICMP error SHOULD be ignored.</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. Processing
SHOULD be performed in the order of the following paragraphs.</t>
<t>A PCP server processes incoming requests on the PCP port from
clients or an operator-configured interface (e.g., from the ISP's
network operations center). The PCP server MUST drop (ignore) requests
that arrive from elsewhere (e.g., the Internet).</t>
<t>Upon receiving a message, the PCP server parses and validates it. A
valid request contains a valid PCP common header, one valid PCP
Opcode, and zero or more Options (which the server might or might not
comprehend). If an error is encountered during processing, the server
generates an error response which is sent back to the PCP client.
Processing an OpCode and the Options are specific to each OpCode.</t>
<t>If the received message is shorter than 4 octets or has the
R bit set the message is simply dropped. If the length of the
request exceeds 1024 octets or is not a multiple of 4 octets,
it is invalid. Invalid requests are handled by copying up to
1024 octets of the request into the response, setting the
result code to MALFORMED_REQUEST, and zero-padding the
response to a multiple of 4 octets if necessary. If the
version number is not supported, a response is generated with
the UNSUPP_VERSION result code and the other steps detailed
in <xref target="version"></xref>. If the OpCode is not
supported, a response is generated with the UNSUPP_OPCODE
result code.</t>
<t>If the source IP address of the received packet does not match the
contents of the PCP Client IP Address field, a response is generated
with the ADDRESS_MISMATCH result code. This is done to detect and
prevent accidental use of PCP where a non-PCP-aware NAT or NAPT exists
between the PCP client and PCP server.</t>
<t>Error responses have the same packet layout as success responses,
with fields from the request copied into the response, and fields
assigned by the PCP server are set as indicated in <xref
target="common_response"></xref></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 PCP request. It validates the OpCode matches an
outstanding PCP 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, as described by the processing
for that OpCode. After these matches are successful, the PCP
client checks the Epoch field to determine if it needs to
restore its state to the PCP server
(see <xref target="epoch"></xref>).</t>
<t>If the result code is 0, the PCP client knows the request was
successful.</t>
<t>If the result code is not 0, the request failed. If the result code
is UNSUPP_VERSION, processing continues as described in <xref
target="version"></xref>. If the result code is SERVER_OVERLOADED,
clients SHOULD NOT send *any* further requests to that PCP server for
the indicated error lifetime. For other error result codes, The PCP
client SHOULD NOT resend the same request for the indicated error
lifetime. If a PCP server indicates an error lifetime in excess of 30
minutes, A PCP client MAY choose to set its retry timer to 30
minutes.</t>
<t>If the PCP client has discovered a new PCP server (e.g., connected
to a new network), the PCP client MAY immediately begin communicating
with this PCP server, without regard to hold times from communicating
with a previous PCP server.</t>
</section>
<section anchor="mif" title="Multi-Interface Issues">
<t>Hosts which desire a PCP mapping might be multi-interfaced
(i.e., own several logical/physical interfaces). Indeed, a
host can be configured with several IPv4 addresses (e.g., WiFi
and Ethernet) or dual-stacked. These IP addresses may have
distinct reachability scopes (e.g., if IPv6 they might have
global reachability scope as for Global Unicast Address
(GUA, <xref target="RFC3587"></xref>) or limited scope as
for <xref target="RFC4193">Unique Local Address (ULA)</xref>).</t>
<t>IPv6 addresses with global reachability (e.g., GUA) SHOULD
be used as the source address when generating a PCP
request. IPv6 addresses without global reachability
(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">private addresses</xref>) MAY be used as
the source interface when generating a PCP request.</t>
<t>As mentioned in <xref target="single_homed"></xref>, only
single-homed CP routers are in scope. Therefore, there is no viable
scenario where a host located behind a CP router is assigned with two
Global Unicast Addresses belonging to different global IPv6
prefixes.</t>
<!--
Section 2.4, "Change of the Internal IP Address"
When a new IP address is assigned to a host embedding a PCP Client,
the PCP Client MUST install on the PCP server all the mappings it
manages, using the new assigned IP address as the internal IP
address.
This needs some additional discussion. Let's take an example where
I have a computer with both WiFi and wired Ethernet connections
and I plug and unplug the Ethernet connection, or go in and out
of range of WiFi. When do we want PCP to do something about
that change of connectivity? Does the answer depend on IPv4,
IPv6, or dual stack running on that interface if we're doing PIN44,
PIN64, PIN46, PIN66?
Med: Good point. IMHO, the address selection should be done according to the-be-completed section: http://tools.ietf.org/html/draft-ietf-pcp-base-02#section-6.1.3. Based on the output of that process, the PCP Client can be triggered accordingly.
Or ... just recommend the internal IP address not be changed!
-->
</section>
<section anchor="epoch" title="Epoch">
<t>Every PCP response sent by the PCP server includes an Epoch field.
This field increments by 1 every second, and is used by the PCP client
to determine if PCP state needs to be restored. If the PCP server
resets or loses the state of its explicit dynamic Mappings (that is,
those mappings created by PCP MAP requests), due to reboot, power
failure, or any other reason, it MUST reset its Epoch time to 0.
Similarly, if the public IP address(es) of the NAT (controlled by the
PCP server) changes, the Epoch MUST be reset to 0. A PCP server MAY
maintain one Epoch value for all PCP clients, or MAY maintain distinct
Epoch values for each PCP client; this choice is
implementation-dependent.</t>
<t>Whenever a client receives a PCP response, the client computes its
own conservative estimate of the expected Epoch value by taking the
Epoch value in the last packet it received from the gateway and adding
7/8 (87.5%) of the time elapsed since that packet was received. If the
Epoch value in the newly received packet is less than the client's
conservative estimate by more than one second, then the client
concludes that the PCP server lost state, and the client MUST
immediately renew all its active port mapping leases as described in
<xref target="reboot"></xref>.</t>
<t>When a client notices that the PCP server reduced its Epoch value,
the PCP clients will send PCP requests to refresh their mappings. The
PCP server needs to be scaled appropriately to accommodate this
traffic. Because PCP lacks a mechanism to simultaneously inform all
PCP clients of the Epoch value, the PCP clients will only flood the
PCP server simultaneously when a power outage and restoration event
causes state loss in both the PCP clients and PCP server.</t>
</section>
<section anchor="version" title="Version Negotiation">
<t>A PCP client sends its requests using PCP version number 1. Should
later updates to this document specify different message formats with
a version number greater than 1 it is expected that PCP servers will
still support version 1 in addition to the newer version(s). However,
in the event that a server returns a response with error code
UNSUPP_VERSION, the client MAY log an error message to inform the user
that it is too old to work with this server.</t>
<t>When sending a response containing the UNSUPP_VERSION
result code, the PCP message MUST be 12 octets long.</t>
<t>If future PCP versions greater than 1 are specified, version
negotiation is expected to proceed as follows: <list style="numbers">
<t>If a client or server supports more than one version it SHOULD
support a contiguous range of versions -- i.e., a lowest version
and a highest version and all versions in between.</t>
<t>Client sends first request using highest (i.e., presumably
'best') version number it supports.</t>
<t>If server supports that version it responds normally.</t>
<t>If server does not support that version it replies giving a
result containing the error code UNSUPP_VERSION, and the closest
version number it does support (if the server supports a range of
versions higher than the client's requested version, the server
returns the lowest of that supported range; if the server supports
a range of versions lower than the client's requested version, the
server returns the highest of that supported range).</t>
<t>If the client receives an UNSUPP_VERSION result containing a
version it does support, it records this fact and proceeds to use
this message version for subsequent communication with this PCP
server (until a possible future UNSUPP_VERSION response if the
server is later updated, at which point the version negotiation
process repeats).</t>
<t>If the client receives an UNSUPP_VERSION result containing a
version it does not support then the client MAY log an error
message to inform the user that it is too old to work with this
server, and the client SHOULD set a timer to retry its request in
30 minutes or the returned Lifetime value, whichever is
smaller.</t>
</list></t>
</section>
<section title="General PCP Option">
<t>The following option can appear in certain PCP responses, without
regard to the OpCode.</t>
<section anchor="unprocessed" title="UNPROCESSED Option">
<t>If the PCP server cannot process a mandatory-to-process option,
for whatever reason, it includes the UNPROCESSED Option in the
response, shown in <xref target="fig_unprocessed"></xref>. This
helps with debugging interactions between the PCP client and PCP
server. This option MUST NOT appear more than once in a PCP
response. The unprocessed options are listed once, and the option
data is zero-filled to the necessary 32 bit boundary. If a certain
Option appeared more than once in the PCP request, that Option value
can appear once or as many times as it occurred in the request. The
order of the Options in the PCP request has no relationship with the
order of the Option values in this UNPROCESSED Option. This Option
MUST NOT appear in a response unless the associated request
contained at least one mandatory-to-process Option.</t>
<figure anchor="fig_unprocessed" title="UNPROCESSED option">
<preamble>The UNPROCESSED option is formatted as follows, showing
an example of two option codes that were unprocessed:</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code-1 | option-code-2 | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Padding: 0, 1, 2, or 3 octets. If the number of option-codes is
not a multiple of 4, padding is used to make it 32-bit aligned. The
padding MUST be on on sending, and MUST be ignored by the
receiver.</t>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>name: UNPROCESSED</t>
<t>number: 1</t>
<t>purpose: indicates which PCP options in the request are
not supported by the PCP server</t>
<t>is valid for OpCodes: all</t>
<t>length: 1 or more</t>
<t>may appear in: responses, and only if the result code is
non-zero.</t>
<t>maximum occurrences: 1</t>
</list></t>
</list></t>
</section>
</section>
</section>
<section anchor="opcode_introduction"
title="Introduction to MAP and PEER OpCodes">
<t>There are three uses for the MAP and PEER OpCodes defined in this
document: a host operating a server (and wanting an incoming
connection), a host operating a client (and wanting to optimize the
application keepalive traffic), and a host operating a client and server
on the same port. These are discussed in the following sections.</t>
<t>When operating a server (<xref target="operating_a_server"></xref>
and <xref target="pcp_symmetric"></xref>) the PCP client knows if it
wants an IPv4 listener, IPv6 listener, or both on the Internet. The PCP
client also knows if it has an IPv4 address 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>It is REQUIRED that the PCP-controlled device assign the
same external IP address to PCP-created explicit dynamic mappings
and to implicit dynamic mappings. It is RECOMMENDED that
static mappings (e.g., those created by a command-line
interface on the PCP server or PCP-controlled device) also be
assigned to the same IP address. Once all internal addresses
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 address 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>
<!--
<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 host 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
host follows the procedures described in this section.</t>
<t>As normal, the application needs to begin listening on a port.
Then, the application constructs a PCP message with the appropriate
MAP OpCode depending on if it is listening on an IPv4 or IPv6 address
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(...);
bind(s, ...);
listen(s, ...);
getsockname(s, &internal_sockaddr, ...);
external_sockaddr = 0;
while (1)
{
/* Note: the "time_to_send_pcp_request" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* The PCP packet sent is identical in all cases, apart from the
* Suggested External Address and Port which may change over time
*/
if (time_to_send_pcp_request)
pcp_send_map_request(internal_sockaddr.sin_port,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
if (pcp_response_received)
update_rendezvous_server("Client Ident", external_sockaddr);
if (received_incoming_connection_or_packet)
process_it(s);
if (other_work_to_do)
do_it();
/* ... */
block_until_we_need_to_do_something_else();
}]]></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
application 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 application 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_sockaddr, ...);
external_sockaddr = 0;
while (1)
{
/* Note: the "time_to_send_pcp_request" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* The PCP packet sent is identical in all cases, apart from the
* Suggested External Address and Port which may change over time
*/
if (time_to_send_pcp_request)
pcp_send_peer_request(internal_sockaddr.sin_port,
&external_sockaddr, /* will be zero the first time */
remote_peer, requested_lifetime, &assigned_lifetime);
if (data_to_send)
send_it(s);
if (other_work_to_do)
do_it();
/* ... */
block_until_we_need_to_do_something_else();
}]]></artwork>
</figure>
</section>
<section anchor="pcp_symmetric"
title="For Operating a Symmetric Client/Server">
<t>A host operating a client and server on the same port (e.g., <xref
target="RFC4961">Symmetric RTP</xref> or <xref target="RFC3581">SIP
Symmetric Response Routing (rport)</xref>) first establishes a local
listener, (usually) sends the local and public IP addresses and ports
to a rendezvous service (which is out of scope of this document), and
initiates an outbound connection from that same source address and
same port. To accomplish this, the application uses the procedure
described in this section.</t>
<t>An application that is using the same port for outgoing connections
as well as incoming connections MUST first signal its operation of a
server using the PCP MAP OpCode, as described in <xref
target="map_opcodes"></xref>, and receive a positive PCP response
before it sends any packets from that port. <list style="empty">
<t>Discussion: Although reversing those steps is tempting
(to eliminate the PCP round trip before a packet can be
sent from that port) and will work if the NAT has
endpoint-independent mapping (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 an application to first
signal its operation of a server using the PCP MAP OpCode.
See also <xref target="non-eim"></xref>.</t>
</list></t>
<?rfc needLines="47" ?>
<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(...);
bind(s, ...);
listen(s, ...);
getsockname(s, &internal_sockaddr, ...);
external_sockaddr = 0;
while (1)
{
/* Note: the "time_to_send_pcp_request" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* The PCP packet sent is identical in all cases, apart from the
* Suggested External Address and Port which may change over time
*/
if (time_to_send_pcp_request)
pcp_send_map_request(internal_sockaddr.sin_port,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
if (pcp_response_received)
update_rendezvous_server("Client Ident", external_sockaddr);
if (received_incoming_connection_or_packet)
process_it(s);
if (need_to_make_outgoing_connection)
make_outgoing_connection(s, ...);
if (data_to_send)
send_it(s);
if (other_work_to_do)
do_it();
/* ... */
block_until_we_need_to_do_something_else();
}]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<section anchor="map_opcodes" title="MAP OpCodes">
<t>This section defines two OpCodes which control forwarding from a NAT
(or firewall) to an internal host. They are: <list hangIndent="11"
style="hanging">
<t hangText=" MAP4=1:">create a mapping between an internal address
and external IPv4 address (e.g., NAT44, NAT64, or firewall)</t>
<t hangText=" MAP6=2:">create a mapping between an internal target
address and external IPv6 address (e.g., NAT46, or firewall)</t>
</list></t>
<t>The internal address is the source IP address of the PCP request
message itself, unless the THIRD_PARTY option is used.</t>
<t>Note that all mappings created by PCP MAP requests are, by
definition, Endpoint Independent Mappings (even on a NAT that usually
creates Endpoint Dependent Mappings for outgoing connections) since the
purpose of a MAP mapping is to receive inbound traffic from any remote
endpoint, not from only one specific remote endpoint.</t>
<t>Note also that all NAT mappings (created by PCP or otherwise) are by
necessity bidirectional and symmetrical. For any packet going in one
direction (in or out) that is translated by the NAT, a reply going in
the opposite direction needs to have the corresponding opposite
translation done so that the reply arrives at the right endpoint. This
means that if a client creates a MAP mapping, and then later sends an
outgoing packet using the mapping's internal source port, the NAT should
translate that packet's Internal Address and Port to the mapping's
External Address and Port, so that replies addressed to the External
Address and Port are correctly translated to the mapping's Internal
Address and Port.</t>
<t>The operation of the MAP OpCodes is described in this section.</t>
<section title="OpCode Packet Formats">
<t>The two MAP OpCodes (MAP4, MAP6) share a similar packet layout for
both requests and responses. Because of this similarity, they are
shown together. For both of the MAP OpCodes, if the assigned external
IP address and assigned external port match the request's Internal IP
address and port, the functionality is purely a firewall; otherwise it
pertains to a network address translator which might also perform
firewall-like functions.</t>
<figure anchor="pin_request" title="MAP OpCode Request Packet Format">
<preamble>The following diagram shows the OpCode-specific
information format in a request for the MAP4 and MAP6
OpCodes.</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Suggested External IP Address (32 or 128, depending on OpCode):
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Requested lifetime (in common header):">Requested
lifetime of this mapping, in seconds. The value 0 indicates
"delete".</t>
<t hangText="Protocol:">indicates upper-layer protocol associated
with this OpCode. Values are taken from the <xref
target="proto_numbers">IANA protocol registry</xref>. For example,
this field contains 6 (TCP) if the opcode is intended to create a
TCP mapping. The value 0 has a special meaning for 'all
protocols', and is used only for delete requests. This means that
HOPOPT (which is assigned by IANA as protocol 0) cannot have a
mapping deleted by PCP.</t>
<t hangText="Reserved:">24 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Internal Port:">Internal port for the mapping. The
value 0 indicates "all ports", and is only legal in a request if
lifetime=0.</t>
<t hangText="Suggested External Port:">suggested external port for
the mapping. This is useful for refreshing a mapping, especially
after the PCP server loses state. If the PCP client does not know
the external port, or does not have a preference, it uses 0.</t>
<t hangText="Suggested External IP Address:">Suggested external IP
address. This is useful for refreshing a mapping, especially after
the PCP server loses state. If the PCP server can fulfill the
request, it will do so. If the PCP client does not know the
external address, or does not have a preference, it MUST use
0.</t>
</list></t>
<figure anchor="pin_response"
title="MAP OpCode Response Packet Format">
<preamble>The following diagram shows the OpCode-specific
information format in a response packet for the MAP4 and MAP6
OpCodes:</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Assigned External IP Address (32 or 128, depending on OpCode) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Lifetime (in common header):">On a success response,
this indicates the lifetime for this mapping, in seconds. On an
error response, this indicates how long clients should assume
they'll get the same error response from the that PCP server if
they repeat the same request.</t>
<t hangText="Protocol:">Copied from the request</t>
<t hangText="Reserved:">24 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Assigned External IP Address:">On success responses,
this is the assigned external IPv4 or IPv6 address for the
mapping; IPv4 or IPv6 address is indicated by the OpCode. On error
responses, this MUST be 0.</t>
<t hangText="Internal Port:">Internal port for the mapping, copied
from request.</t>
<t hangText="Assigned External Port:">On success responses, this
is the assigned external port for the mapping. On error responses,
the Assigned External Port MUST be 0.</t>
</list></t>
</section>
<section anchor="map_result_codes" title="OpCode-Specific Result Codes">
<t>In addition to the general PCP result codes (<xref
target="result_codes"></xref>), the following additional result codes
may be returned as a result of the four MAP OpCodes received by the
PCP server. These errors are considered 'long lifetime' or 'short
lifetime', which provides guidance to PCP server developers for the
value of the Lifetime field for these errors. It is RECOMMENDED that
short lifetime errors use 30 second lifetime and long lifetime errors
use 30 minute lifetime.<list style="hanging">
<t hangText="20">NETWORK_FAILURE, PCP server or the device it
controls are experiencing a network failure of some sort (e.g.,
has not obtained an IP address). This is a short lifetime
error.</t>
<t hangText="21">NO_RESOURCES, e.g., NAT device cannot create more
mappings at this time. This is a system-wide error, and different
from USER_EX_QUOTA. This is a short lifetime error.</t>
<t hangText="22">UNSUPP_PROTOCOL, unsupported Protocol. This is a
long lifetime error.</t>
<t hangText="23">NOT_AUTHORIZED, e.g., PCP server supports
mapping, but the feature is disabled for this PCP client, or the
PCP client requested a mapping that cannot be fulfilled by the PCP
server's security policy. This is a long lifetime error.</t>
<t hangText="24">USER_EX_QUOTA, mapping would exceed user's port
quota. This is a short lifetime error.</t>
<t hangText="25">CANNOT_PROVIDE_EXTERNAL_PORT, indicates the port
is already in use (e.g. already allocated to a previous PCP
client) or otherwise temporarily unavailable. This error is only
returned if the request included the Option PREFER_FAILURE. This
is a short lifetime error.</t>
<t hangText="26">EXCESSIVE_REMOTE_PEERS, indicates the PCP server
was not able to create the filters in this request. This result
code MUST only be returned if the MAP request contained the
REMOTE_FILTER Option. This is a long lifetime error.</t>
</list></t>
<t>Additional result codes may be returned if the THIRD_PARTY option
is used, see <xref target="third_party"></xref>.</t>
</section>
<section anchor="pin-opcode_client_operation"
title="OpCode-Specific Client: Generating a Request">
<t>This section describes the operation of a PCP client when sending
requests with OpCodes MAP4 and MAP6.</t>
<t>The request MAY contain values in the suggested-external-ip-address
and suggested-external-port fields. This allows the PCP client to
attempt to rebuild the PCP server's state, so that the PCP client
could avoid having to change information maintained at the rendezvous
server. Of course, due to other activity on the network (e.g., by
other users or network renumbering), the PCP server may not be able to
fulfill the request.</t>
<t>An existing mapping can have its lifetime extended by the PCP
client. To do this, the PCP client sends a new MAP request indicating
the internal port. The PCP MAP request SHOULD also include the
currently allocated external IP address and port as the suggested
external IP address and port, so that if the NAT gateway has lost
state it can recreate the lost mapping with the same parameters.</t>
<t>The PCP client SHOULD renew the mapping before its expiry time,
otherwise it will be removed by the PCP server (see <xref
target="lifetime"></xref>). In order to prevent excessive PCP chatter,
it is RECOMMENDED to send a single renewal request packet when a
mapping is halfway to expiration time, then, if no SUCCESS result is
received, another single renewal request 3/4 of the way to expiration
time, and then another at 7/8 of the way to expiration time, and so
on, subject to the constraint that renewal requests MUST NOT be sent
less than four seconds apart (a PCP client MUST NOT send
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. Processing SHOULD
be performed in the order of the following paragraphs.</t>
<t>If the server is overloaded by requests (from a particular client
or from all clients), it MAY simply discard requests, as the requests
will be retried by PCP clients, or MAY generate the SERVER_OVERLOADED
error response, or both.</t>
<t>If the request contains internal-port=0 and the lifetime is
non-zero, the server MUST generate a MALFORMED_REQUEST error.</t>
<t>If the requested lifetime is not zero, it indicates a request to
create a mapping or extend the lifetime of an existing mapping.</t>
<t>Processing of the lifetime is described in <xref
target="lifetime"></xref>.</t>
<t>If the PCP-controlled device is stateless (that is, it does not
establish any per-flow state, and simply rewrites the address and/or
port in a purely algorithmic fashion), the PCP server simply returns
an answer indicating the external IP address and port yielded by this
stateless algorithmic translation. This allows the PCP client to learn
its external IP address and port as seen by remote peers. Examples of
stateless translators include stateless NAT64 and 1:1 NAT44, both of
which modify addresses but not port numbers.</t>
<t>If an Option with value less than 128 exists (i.e. mandatory to
process) but that option does not make sense (e.g., the PREFER_FAILURE
option is included in a request with lifetime=0), the request is
invalid and generates a MALFORMED_OPTION error.</t>
<!--
<t>If the REMOTE_PEER option is not included in the request and it is
impossible for the PCP-controlled device to establish a mapping
because a conflicting dynamic mapping already exists, the PCP server
responds with the error AMBIGUOUS (this is due to interactions with
dynamic mappings, see <xref target="dynamic-interaction"></xref>).</t>
-->
<t>If the PCP server can allocate the suggested external port, and the
request did not contain the PREFER_FAILURE Option, it SHOULD do so.
This is beneficial for re-establishing state lost when the PCP server
loses its state (e.g., due to a reboot). If the PCP server cannot
allocate the suggested external port but can allocate some other port
and the request did not contain the PREFER_FAILURE Option, the PCP
server MUST do so and return the allocated port in the response. Cases
where a NAT gateway cannot allocate the suggested external port
include: <list style="symbols">
<t>Where the suggested external port is already allocated to
another existing explicit, implicit, or static mapping, or already
forwarding traffic to some other internal address:port, or;</t>
<t>Where the suggested external port is already used by the NAT
gateway for one of its own services (e.g., port 80 for the NAT
gateway's own configuration pages), or;</t>
<t>When the suggested external port is otherwise prohibited by the
PCP server's policy.</t>
</list></t>
<t>By default, a PCP-controlled device MUST NOT create mappings for a
protocol not indicated in the request. For example, if the request was
for a TCP mapping, a UDP mapping MUST NOT be created.</t>
<t>If the THIRD_PARTY option is not present in the request, the source
IP address of the PCP packet is used when creating the mapping. If the
THIRD_PARTY option is present, the PCP server validates that the
client is authorized to make mappings on behalf of the indicated
internal IP address. This validation depends on the PCP deployment
scenario; see <xref target="subscriber_identification"></xref> for the
validation procedure. If the internal IP address in the PCP request is
not authorized to make mappings on behalf of the indicated internal IP
address, an error response MUST be generated with result code
NOT_AUTHORIZED.</t>
<t>Mappings typically consume state on the PCP-controlled device, and
it is RECOMMENDED that a per-subscriber or per-host limit be enforced
by the PCP server to prevent exhausting the mapping state. If this
limit is exceeded, the result code USER_EX_QUOTA is returned.</t>
<t>If all of the proceeding operations were successful (did not
generate an error response), then the requested mappings are created
or refreshed as described in the request and a SUCCESS response is
built. This SUCCESS response contains the same OpCode as the request,
but with the "R" bit set.</t>
</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>After performing common PCP response processing, the
response is further matched with an outstanding 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>On an error response, clients SHOULD NOT repeat the same request to
the same PCP server within the lifetime returned in the response.</t>
</section>
<section anchor="lifetime" title="Mapping Lifetime and Deletion">
<t>The PCP client requests a certain lifetime, and the PCP server
responds with the assigned lifetime. The PCP server MAY grant a
lifetime smaller or larger than the requested lifetime. The PCP server
SHOULD be configurable for permitted minimum and maximum lifetime, and
the RECOMMENDED values are 120 seconds for the minimum value and 24
hours for the maximum. It is RECOMMENDED that the server restrict
lifetimes to less than 24 hours, because they will consume ports even
if the internal host is no longer interested in receiving the traffic
or no longer connected to the network.</t>
<t>Once a PCP server has responded positively to a mapping
request for a certain lifetime, the port forwarding is active
for the duration of the lifetime unless the lifetime is
reduced by the PCP client (to a shorter lifetime or to zero)
or until the PCP server loses its state (e.g.,
crashes). Mappings created by PCP PEER and MAP requests are
not special or different to mappings created other ways. In
particular, it is implementation-dependent if outgoing traffic
extends the lifetime of such mappings. PCP clients MUST NOT
depend on this behavior to keep mappings active, and MUST
explicitly renew their mappings as required by the Lifetime
field in PCP response messages.</t>
<t>If the requested lifetime is 0 then: <list style="symbols">
<t>If the internal port and protocol both are non-zero, it
indicates a request to delete the indicated mapping
immediately.</t>
<t>If the internal port is non-zero and the protocol is zero, it
indicates a request to delete all mappings for this Internal
Address for the given internal port for all transport
protocols.</t>
<t>If the internal port and protocol both are zero, it indicates a
request to delete all mappings for this Internal Address for all
transport protocols. This is useful when a host reboots or joins a
new network, to clear out prior stale state from the NAT gateway
before beginning to install new mappings.</t>
</list> The suggested external address and port fields are ignored
in requests where the requested lifetime is 0.</t>
<t>A PCP MAP request can delete an implicit dynamic mapping
(e.g., a mapping created by a TCP SYN) or an explicit dynamic
mapping (e.g., a mapping created by PCP MAP). If the PCP
client attempts to delete a single static mapping (i.e., a
mapping created outside of PCP itself), the error
NOT_AUTHORIZED is returned. If the PCP client attempts to
delete an implicit dynamic mapping (e.g., created by a TCP
SYN), the PCP server deletes the mapping and responds with the
SUCCESS result code. If the PCP client attempts to delete a
mapping that does not exist, the SUCCESS result code is
returned (this is necessary for PCP to be idempotent). If the
PCP MAP request was for port=0 (indicating 'all ports'), the
PCP server deletes all of the explicit dynamic mappings it can
(but not any implicit mappings), and returns a SUCCESS
response. If the deletion request was properly formatted and
successfully processed, a SUCCESS response is generated with
lifetime of 0 and the server copies the protocol and internal
port number from the request into the response. An explicit
dynamic mapping MUST NOT have its lifetime reduced by
transport protocol messages (e.g., TCP RST, TCP FIN).</t>
<t>An application that forgets its PCP-assigned mappings (e.g., the
application or OS crashes) will request new PCP mappings. This may
consume port mappings, if the application binds to a different
Internal Port every time it runs. The application will also likely
initiate new implicit dynamic mappings (e.g., TCP connections) without
using PCP, which will also consume port mappings. If there is a port
mapping quota for the internal host, frequent restarts such as this
may exhaust the quota. PCP provides some protections against such port
consumption: When a PCP client first acquires a new IP address (e.g.,
reboots or joins a new network), it SHOULD remove mappings that may
already be instantiated for that new Internal Address. To do this, the
PCP client sends a MAP request with protocol, internal port, and
lifetime set to 0. Some port mapping APIs (e.g., the
"DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on
Mac OS X, iOS, Windows, Linux) 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>To reduce unwanted traffic and data corruption, UDP and TCP ports
should not be immediately re-used for an interval (TIME_WAIT interval
as discussed in <xref target="RFC0793"></xref>). However, the PCP
server MUST allow the same subscriber and same internal address to
re-acquire the same port during that interval.</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>
<t>The following list summarizes the sentinel values when deleting a
mapping using lifetime=0:<list style="hanging">
<t
hangText="* all ports, all protocols, all Internal Addresses for which the client is authorized:">internal
address=0, via the THIRD_PARTY option</t>
<t hangText="* all ports, all protocols:">internal port=0,
protocol=0</t>
<t hangText="* all ports, specific protocol:">internal port=0,
protocol={protocol value} (e.g., protocol=6 for TCP)</t>
<t hangText="* one port, specific protocol:">internal port={port
number}, protocol={protocol value} (e.g., port=12345, protocol=6
for TCP)</t>
</list></t>
</section>
<section anchor="renumbering"
title="Subscriber Renumbering and Address Change Events">
<t>The customer premises router might obtain a new IP address. 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. Typically, the PCP
client will no longer receive traffic sent to that old IP address.
Assuming the PCP client wants to continue receiving traffic, it needs
to install new mappings for its new IP address. The suggested external
port field will not be fulfilled by the PCP server, in all likelihood,
because it is still being forwarded to the old IP address. Thus, a
mapping is likely to be assigned a new external port number and/or
public IP address. Note that this scenario is not expected to happen
routinely on a regular basis for most hosts, since most hosts renew
their DHCP leases before they expire (or re-request the same address
after reboot) and most DHCP servers honor such requests and grant the
host the same address it was previously using before the reboot.</t>
<t>A host might gain or lose interfaces while existing mappings are
active (e.g., Ethernet cable plugged in or removed, joining/leaving a
WiFi network). Because of this, if the PCP client is sending a PCP
request to maintain state in the PCP server, it SHOULD ensure those
PCP requests continue to use the same interface (e.g., when refreshing
mappings). If the PCP client is sending a PCP request to create new
state in the PCP server, it MAY use a different source interface or
different source address.</t>
</section>
<section title="PCP Failure Scenarios">
<t>If an event occurs that causes the PCP server to lose explicit dynamic mapping 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 more common in a
residential NAT device which does not write information to its
non-volatile memory. Of course, due to outright failure of service
provider equipment (e.g., software malfunction), state may still be
lost.</t>
<t>The Epoch allows a client to deduce when a PCP server may have lost
its state. When the Epoch value is smaller than expected, the PCP
client can attempt to recreate the mappings following the procedures
described in this section.</t>
<section anchor="reboot" title="Recreating Mappings">
<t>The PCP server SHOULD store mappings in persistent storage so
when it is powered off or rebooted, it remembers the port mapping
state of the network. Due to the physical architecture of some PCP
servers, this is not always achievable (e.g., some non-volatile
memory can withstand only a certain number of writes, so writing PCP
mappings to such memory is generally avoided).</t>
<t>However, maintaining this state is not essential for correct
operation. When the PCP server loses state and begins processing new
PCP messages, its Epoch is reset to zero (per the procedure of <xref
target="epoch"></xref>).</t>
<t>A mapping renewal packet is formatted identically to an original
mapping request; from the point of view of the client it is a
renewal of an existing mapping, but from the point of view of the
PCP server it appears as a new mapping request. In the normal
process of routinely renewing its mappings before they expire, a PCP
client will automatically recreate all its lost mappings.</t>
<t>In addition, as the result of receiving a packet where the Epoch
field indicates that a reboot or similar loss of state has occurred,
the client can renew its port mappings sooner, without waiting for
the normal routine renewal time.</t>
<t>The discussion in this section focuses on recreating inbound port
mappings after loss of PCP server state, because that is the more
serious problem. Losing port mappings for outgoing connections
destroys those currently active connections, but does not prevent
clients from establishing new outgoing connections. In contrast,
losing inbound port mappings not only destroys all existing inbound
connections, but also prevents the reception of any new inbound
connections until the port mapping is recreated. Accordingly, we
consider recovery of inbound port mappings the more important
priority. However, clients that want outgoing connections to survive
a NAT gateway reboot can also achieve that using PCP. After
initiating an outbound TCP connection (which will cause the NAT
gateway to establish an implicit port mapping) the client should
send the NAT gateway a PEER request for the source port of its TCP
connection, which will cause the NAT gateway to send a response
giving the external port it allocated for that mapping. The client
can then store this information, and use it later to recreate the
mapping if it determines that the NAT gateway has lost its mapping
state.</t>
</section>
<section title="Maintaining Mappings">
<t>A PCP client can refresh a mapping by sending a new PCP request
containing information from the earlier PCP response. The PCP server
will respond indicating the new lifetime. It is possible, due to
failure of the PCP server, that the public IP address and/or public
port, or the PCP server itself, has changed (due to a new route to a
different PCP server). To detect such events more quickly, the PCP
client may find it beneficial to use shorter lifetimes (so that it
communicates with the PCP server more often). If the PCP client has
several mappings, the Epoch value only needs to be retrieved for one
of them to verify the PCP server has not lost port forwarding
state.</t>
<t>If the client wishes to check the PCP server's Epoch, it sends a
PCP request for any one of the client's mappings. This will return
the current Epoch value. In that request the PCP client could extend
the mapping lifetime (by asking for more time) or maintain the
current lifetime (by asking for the same number of seconds that it
knows are remaining of the lifetime).</t>
<t>If an internal IP address is no longer valid (e.g., because the
internal host has moved to a new network), and the PCP client wishes
to still receive incoming traffic, it MUST create a new mapping on
that new network. A new mapping will also require an update to the
application-specific rendezvous server (see <xref
target="operating_a_server"></xref> and <xref
target="renumbering"></xref>).</t>
</section>
</section>
<section anchor="non-eim"
title="Implementing MAP with non-EIM NATs">
<t>For implicit dynamic mappings, some existing NAT devices
have endpoint-independent mapping (EIM) behavior while other NAT
devices have non-endpoint-independent mapping (non-EIM) behavior.
NATs which have EIM behavior do not suffer from the problem described
in this section. EIM behavior is strongly encouraged by
both <xref target="RFC4787"></xref>
and <xref target="RFC5382"></xref>.</t>
<t>In such non-EIM NAT devices, the same external port may be used by
connections from different internal hosts. This complicates the
interaction with the MAP4 and MAP6 OpCodes. With such NAT devices,
there are two ways envisioned to implement the MAP4 and MAP6 OpCodes:
<list style="numbers">
<t>have implicit dynamic mappings (e.g., TCP SYN) use a different set
of public ports than explicit dynamic mappings (e.g., those created
with MAP4 or MAP6), thus avoiding the interaction problem between
them.</t>
<t>on arrival of an incoming packet from the Internet, first attempt
to process implicit dynamic mappings (as done today by existing port
overload code), and if none of those can be processed then the
incoming packet is for the explicit dynamic mapping. This effectively
'prioritizes' implicit dynamic mappings above explicit dynamic
mappings.</t>
</list></t>
</section>
</section>
<section anchor="peer_opcodes" title="PEER OpCodes">
<t>This section defines two OpCodes for controlling dynamic connections.
They are:<list hangIndent="12" style="hanging">
<t hangText=" PEER4=3:">Set (or query) the lifetime for flow to a
remote peer's IPv4 address.</t>
<t hangText=" PEER6=4:">Set (or query) the lifetime for flow to a
remote peer's IPv6 address.</t>
</list> The operation of these OpCodes is described in this
section.</t>
<section title="OpCode Packet Formats">
<t>The PEER OpCodes provide a single function: the ability for the PCP
client to query and (possibly) extend the lifetime of an existing
mapping.</t>
<t>The two PEER OpCodes (PEER4 and PEER6) share a similar packet
layout for both requests and responses. Because of this similarity,
they are shown together.</t>
<figure anchor="peer_request"
title="PEER OpCode Request Packet Format">
<preamble>The following diagram shows the request packet format for
PEER4 and PEER6. This packet format is aligned with the response
packet format:</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP Address (32 bits if PEER4, 128 bits if PEER6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Reserved (128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Requested Lifetime (in common header):">Requested
lifetime of this mapping, in seconds. Note that, depending on the
implementation of the PCP-controlled device, it may not be
possible to reduce the lifetime of a mapping (or delete it, with
requested lifetime=0) using PEER.</t>
<t hangText="Protocol:">indicates upper-level protocol associated
with this OpCode. Values are taken from the <xref
target="proto_numbers">IANA protocol registry</xref>. For example,
this field contains 6 (TCP) if the OpCode is describing a TCP
peer.</t>
<t hangText="Reserved:">24 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="Internal Port:">Internal port of the 5-tuple.</t>
<t hangText="Suggested External Port:">suggested external port for
the mapping. This is useful for refreshing a mapping, especially
after the PCP server loses state. If the PCP server can fulfill
the request, it will do so. If the PCP client does not know the
external port, or does not have a preference, it uses 0.</t>
<t hangText="Remote Peer Port:">Remote peer's port of the
5-tuple.</t>
<t hangText="Reserved:">16 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="Remote Peer IP Address:">This is the Remote peer's IP
address from the perspective of the PCP client so that the PCP
client does not need to concern itself with NAT64 or NAT46 (which
both cause the client's idea of the remote peer's IP address to
differ from the remote peer's actual IP address). This field
allows the PCP client and PCP server to disambiguate multiple
connections from the same port on the internal host to different
servers. Note this field has no bearing whatsoever on any
filtering associated with the mapping.</t>
<t hangText="Reserved:">128 reserved bits, MUST be 0 on
transmission and MUST be ignored on reception.</t>
</list></t>
<figure anchor="peer_response"
title="PEER OpCode Response Packet Format">
<preamble>The following diagram shows the response packet format for
PEER4 and PEER6:</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | External_AF | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP Address (32 bits if PEER4, 128 bits if PEER6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: External IP Address (32 bits if External_AF indicates IPv4 :
: 128 bits if External_AF indicates IPv6) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Lifetime (in common header):">On a success response,
this indicates the lifetime for this mapping, in seconds. On an
error response, this indicates how long clients should assume
they'll get the same error response from the PCP server if they
repeat the same request.</t>
<t hangText="Protocol:">Copied from the request.</t>
<t hangText="External_AF:">For success responses, this contains
the address family of the external IP address associated with this
peer connection, to properly decode the External IP Address. This
field is necessary because the Remote Peer's IP Address is from
the PCP client's perspective, whereas the External_AF and External
IP Address are from the PCP-controlled device's perspective. As an
example, if the PCP-controlled device is a NAT64, the PCP client
only knows the remote peer's IPv6 address, whereas the NAT64 knows
the remote peer's IPv4 address. Values are from IANA's address
family numbers (IPv4 is 1, IPv6 is 2). For error responses, the
value MUST be 1.</t>
<t hangText="Reserved:">16 reserved bits, MUST be 0 on
transmission, MUST be ignored on reception.</t>
<t hangText="Internal Port:">copied from request.</t>
<t hangText="External Port:">For success responses, this is the
external port number, assigned by the NAT (or firewall) to this
mapping. If firewall or 1:1 NAT, this will match the internal
port. For error responses, this MUST be 0.</t>
<t hangText="Remote Peer port:">Copied from request.</t>
<t hangText="Reserved:">16 reserved bits, MUST be 0 on
transmission, MUST be ignored on reception.</t>
<t hangText="Remote Peer IP Address:">Copied from the request.</t>
<t hangText="External IP Address:">For success responses, this
contains the external IP address, assigned by the NAT (or
firewall) to this mapping. This field allows the PCP client and
its remote peer to determine if there is another NAT between the
PCP-controlled NAT and remote peer. If the PCP-controlled device
is a firewall, this will match the internal IP address. This field
is 128 bits long if External_AF indicates IPv6, or 32 bits long if
External_AF indicates IPv4.</t>
</list></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 MAY be sent before or after establishing
bi-directional communication with the remote peer. If sent before,
PEER4 or PEER6 OpCodes will create a mapping in the PCP-controlled
device that functions exactly as if an implicit dynamic connection
were made (e.g., TCP SYN). If sent after, the PEER4 or PEER6 OpCodes
query (and control) the implicit dynamic mapping.</t>
<t>The PEER4 and PEER6 OpCodes contain a description of the remote
peer address, from the perspective of the PCP client. This is
important when the PCP-controlled device is performing address family
translation (NAT46 or NAT64), because the destination address from the
perspective of the PCP client is different from the destination
address on the other side of the address family translation device.
For this reason, the PEER4 and PEER6 responses contain an External_AF
field.</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 OpCode PEER4 or PEER6. Processing SHOULD be performed
in the order of the following paragraphs.</t>
<t>On receiving the PEER4 or PEER6 OpCode, the PCP server examines the
mapping table. If the described mapping does not exist yet, it is
created, just as it would be for an outgoing UDP packet or TCP SYN.
This avoids a race condition between the PEER request or the initial
outgoing packet arriving at the NAT gateway first.</t>
<t>The PEER4 or PEER6 OpCode MAY reduce the lifetime of an existing
mapping; this is implementation-dependent.</t>
<t>If the PCP-controlled device can extend the lifetime of a mapping,
the PCP server uses the smaller of its configured maximum lifetime
value and the requested lifetime from the PEER request, and sets the
lifetime to that value.</t>
<t>If all of the proceeding operations were successful (did not
generate an error response), then a SUCCESS response is generated,
with the Lifetime field containing the lifetime of the mapping.</t>
<t>After a successful PEER response is sent, it is
implementation-specific if the PCP-controlled device destroys
the mapping when the lifetime expires, or if the
PCP-controlled device's implementation allows traffic to keep
the mapping alive. Thus, if the PCP client wants the mapping
to persist beyond the lifetime, it MUST refresh the mapping
(by sending another PEER message) prior to the expiration of
the lifetime. If the mapping is terminated by the TCP client
or server (e.g., TCP FIN or TCP RST), the mapping will be
destroyed normally; the mapping will not persist for the time
indicated by Lifetime. This means the Lifetime in a PEER
response indicates how long the mapping will persist in the
absence of a transport termination message (e.g., TCP
RST).</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 OpCode PEER4 or PEER6.</t>
<t>After performing common PCP response processing, the response is
further 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 a successful response, the application can use 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 maintain state on its server (e.g.,
"busy" / "away") more frequently than once an hour.</t>
<t>If the PCP client wishes to keep this mapping alive beyond the
indicated lifetime, it SHOULD issue a new PCP request prior to the
expiration. That is, inside->outside traffic is not sufficient to
ensure the mapping will continue to exist. It is RECOMMENDED to send a
single renewal request packet when a mapping is halfway to expiration
time, then, if no SUCCESS response is received, another single renewal
request 3/4 of the way to expiration time, and then another at 7/8 of
the way to expiration time, and so on, subject to the constraint that
renewal requests MUST NOT be sent less than four seconds apart (a PCP
client MUST NOT ever-closer-together requests in the last few seconds
before a mapping expires).</t>
</section>
</section>
<section anchor="map_peer_options"
title="Options for MAP and PEER OpCodes">
<t>This section describes Options for the MAP4, MAP6, PEER OpCodes.
These Options MUST NOT appear with other OpCodes, unless permitted by
those OpCodes.</t>
<section anchor="third_party"
title="THIRD_PARTY Option for MAP and PEER OpCodes">
<t>This Option is used when a PCP client wants to control a mapping to
an internal host other than itself. This is used with both MAP and
PEER OpCodes.</t>
<t>A THIRD_PARTY Option MUST NOT contain the same address as the
source address of the packet. A PCP server receiving a THIRD_PARTY
Option specifying the same address as the source address of the packet
MUST return a MALFORMED_REQUEST result code. This is because many PCP
servers may not implement the THIRD_PARTY Option at all, and a client
using the THIRD_PARTY Option to specify the same address as the source
address of the packet will cause mapping requests to fail where they
would otherwise have succeeded.</t>
<t>Where possible, it may beneficial if a client using the THIRD_PARTY
option to create and maintain mappings on behalf of some other device
can take steps to verify that the other device is still present and
active on the network. Otherwise the client using the THIRD_PARTY
option to maintain mappings on behalf of some other device risks
maintaining those mappings forever, long after the device that
required them has gone. This would defeat the purpose of PCP mappings
having a finite lifetime so that they can be automatically deleted
after they are no longer needed.</t>
<figure alt="fig_third_party" title="THIRD_PARTY option packet format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Internal IP Address (32 bits of 128 bits, depending :
: on Option length) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are described below:<list style="hanging">
<t hangText="Internal IP Address:">IP address of this mapping. If
the length of this Option is 4, this is a 32-bit IPv4 address. If
the length of this Option is 16, this is a 128-bit IPv6 address.
This can contain the special value "0" (all zeros), which
indicates "all Internal Addresses for which this client is
authorized" which is used to delete all pre-existing mappings with
the MAP Opcode.</t>
</list></t>
<t>This Option:<list style="empty">
<t>name: THIRD_PARTY</t>
<t>number: 4</t>
<t>purpose: Indicates the MAP or PEER request is for a host other
than the host sending the PCP option.</t>
<t>is valid for OpCodes: MAP4, MAP6, PEER4, PEER6</t>
<t>length: 4 if Internal IP Address is IPv4, 16 if Internal IP
Address is IPv6.</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, indicating the internal IP
address specified is not permitted (e.g., client is not authorized
to make mappings for this Internal Address, or is otherwise
prohibited.). This error can be returned for both MAP and PEER
requests. If this is a MAP request, this is a long-term error.</t>
</list></t>
<t>A PCP server MAY be configured to permit or to restrict the use of
the THIRD_PARTY option. If this option is permitted, any host can
create, modify, or destroy mappings for another host on the
subscriber's network. If third party mappings are restricted, only
authorized clients can perform these operations. If a PCP server is
configured to restrict third party mappings, and receives a PCP MAP
request with a THIRD_PARTY option, it MUST generate a
UNAUTH_TARGET_ADDRESS response. Determining which PCP clients are
authorized to use the THIRD_PARTY option depends on the deployment
scenario. For Dual-Stack Lite deployments, the PCP server only
supports this option if the source IPv6 address is the B4's source IP
address. For home deployments (where the PCP server is embedded in the
NAT device), this option MUST NOT be processed. For scenarios where
the subscriber has only one IP address (e.g., typical residential ISP
service) this Option serves no purpose (and will only generate error
messages from the server). If a subscriber has more than one IP
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. A cryptographic authentication and authorization model is
outside the scope of this specification.</t>
<t>It is RECOMMENDED that PCP servers embedded into customer premise
equipment be configured to refuse third party mappings by default.
With this default, if a user wants to create a third party mapping,
the user needs to interact out-of-band with their customer premise
router (e.g., using its HTTP administrative interface).</t>
<t>It is RECOMMENDED that PCP servers embedded into service provider
NAT and firewall devices be configured to permit the THIRD_PARTY
option, when sent by the customer premise router. With this
configuration, if a user wants to create an explicit dynamic mapping
or query an implicit dynamic mapping for another host within their
network, the user needs to interact out-of-band with their customer
premise router (e.g., using its HTTP administrative interface). To
accomplish this, the PCP server in the ISP's network processes
requests with the THIRD_PARTY option if they arrived from the IP
address of the customer premise router. In deployments with only one
IP address (e.g., which is common in residential networks), the PCP
messages will -- by necessity -- arrive from the IP address of the
customer premise router router. In networks where users have multiple
IPv4 or multiple IPv6 addresses, the PCP server MUST only allow the
THIRD_PARTY option if the PCP message was sent by the IP address of
the subscriber's customer premise router. In Dual-Stack Lite, this
would be the B4 element's IPv6 address. If the packet arrived from a
different address, the PCP server MUST generate an
UNAUTH_TARGET_ADDRESS error.</t>
<t>If authorized to do so, a PCP client can delete all the PCP-created
explicit dynamic mappings (i.e., those created by PCP MAP requests)
for all hosts belonging to the same subscriber. This is done by
sending a PCP MAP request including the THIRD_PARTY option with its
Internal Address field set to 0.</t>
</section>
<section title="PREFER_FAILURE Option for MAP OpCodes">
<t>This option is only used with the MAP4 and MAP6 OpCodes.</t>
<t>This option indicates that if the PCP server is unable to MAP the
suggested port, then instead of returning an available port that it
*can* allocate, the PCP server should instead allocate no port and
return result code CANNOT_PROVIDE_EXTERNAL_PORT.</t>
<t>This option is intended solely for use by <xref
target="I-D.bpw-pcp-upnp-igd-interworking">UPnP IGD
interworking</xref>, where the semantics of UPnP IGD version 1 do not
provide any way to indicate to an UPnP IGD client that any port is
available other than the one it wanted. A PCP server MAY support this
option, if its designers wish to support downstream devices that
perform UPnP 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 UPnP IGD
interworking are not required to support this option. PCP clients
other than UPnP 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. It is anticipated that this
option will be deprecated in the future as more clients adopt PCP
natively and the need for UPnP 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 anchor="filter" title="FILTER Option for MAP OpCodes">
<t>This Option indicates filtering incoming packets is
desired. The remote peer port and remote peer IP Address
indicate the permitted remote peer's source IP address and
port for packets from the Internet. The remote peer prefix
length indicates the length of the remote peer's IP address
that is significant; this allows a single Option to permit an
entire subnet. After processing this MAP request containing
the FILTER option and generating a successful response, the
PCP-controlled device will drop packets received on its
public-facing interface that don't match the filter
fields. After dropping the packet, if its security policy
allows, the PCP-controlled device MAY also generate an ICMP
error in response to the dropped packet.</t>
<figure anchor="fig_filter" title="FILTER option layout">
<preamble>The FILTER packet layout is described below:</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | prefix-length | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP address (32 bits if MAP4, :
: 128 bits if MAP6) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Reserved:">8 reserved bits, MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="prefix-length:">indicates how many bits of the IPv4
or IPv6 address are relevant for this filter. The value 0
indicates "no filter", and will remove all previous filters. See
below for detail.</t>
<t hangText="Remote Peer Port:">the port number of the remote
peer. The value 0 indicates "all ports"</t>
<t hangText="Remote Peer IP address:">The IP address of the remote
peer.</t>
</list></t>
<t>This Option:<list style="empty">
<t>name: FILTER</t>
<t>number: 2</t>
<t>is valid for OpCodes: MAP4, MAP6</t>
<t>is included in responses: MUST, if it appeared in the
request</t>
<t>length: 2 if used with MAP4, 5 if used with MAP6</t>
<t>may appear in: requests, and MUST appear in
successfully-processed responses</t>
<t>maximum occurrences: as many as fit within maximum PCP message
size</t>
</list></t>
<t>Because of interactions with dynamic ports this Option MUST only be
used by a client that is operating a server (that is, using the MAP
OpCode), as this ensures that no other application will be assigned
the same ephemeral port for its outgoing connection. It is RECOMMENDED
that the PCP client avoid other use, because it will cause some UNSAF
NAT traversal mechanisms <xref target="RFC3424"></xref> to fail where
they would have otherwise succeeded, breaking other applications
running on this same host.</t>
<t>The prefix-length indicates how many bits of the IPv6 address or
IPv4 address are used for the filter. For MAP4, a prefix-length of 32
indicates the entire IPv4 address is used. For MAP6, a prefix-length
of 128 indicates the entire IPv6 address is used. For MAP4 the minimum
prefix-length value is 0 and the maximum value is 32. For MAP6 the
minimum prefix-length value is 0 and the maximum value is 128. Values
outside those range cause an MALFORMED_OPTION result code.</t>
<t>If multiple occurrences of the FILTER option exist in the same MAP
request, they are processed in the same order received, and they MUST
all be successfully processed or return an error (e.g.,
MALFORMED_OPTION if one of the options was malformed), and they MAY
overlap the filtering requested. As with other PCP errors, returning
an error causes no state to be changed in the PCP server or in the
PCP-controlled device. If an existing mapping exists (with or without
a filter) and the server receives a MAP request with FILTER, the
filters indicated in the new request are added to any existing
filters. If a MAP request has a lifetime of 0 and contains the FILTER
option, the error MALFORMED_OPTION is returned.</t>
<t>To remove all existing filters, the prefix-length 0 is used. There
is no mechanism to remove a specific filter.</t>
<t>To change an existing filter, the PCP client sends a MAP request
containing two FILTER options, the first option containing a
prefix-length of 0 (to delete all existing filters) and the second
containing the new remote peer's IP address and port. Other FILTER
options in that PCP request, if any, add more allowed remote
hosts.</t>
<t>The PCP server or the PCP-controlled device is expected to have a
limit on the number of remote peers it can support. This limit might
be as small as one. If a MAP request would exceed this limit, the
entire MAP request is rejected with the result code
EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is
unchanged.</t>
</section>
<!--
<section title="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 title="REMOTE_PEER">
<t>Due to a pre-existing dynamic mapping, a PCP server may not be
able to instantiate a filter on a specific port. It is thus
recommended that applications bind to the source port (to prevent
other applications from using that same source port) prior to using
this PCP Option.</t>
<t>In those situations, the Option REMOTE_PEER is necessary to
disambiguate the mappings. This option does not change filtering
behavior of the NAT or firewall.</t>
<figure>
<artwork align="center"><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP address (32 bits if MAP44 or MAP64, :
: 1 28 bits if MAP46 or MAP66) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>value: 129</t>
<t>is valid for OpCodes: MAP44, MAP64, MAP46, or MAP66</t>
<t>is included in responses: MUST</t>
<t>length: 8 or 20</t>
<t>maximum occurrences: 1</t>
</list></t>
</list></t>
</section>
-->
</section>
<!--
<section title="NAT-PMP Transition">
<t>Port Control Protocol (PCP) is a successor to NAT Port
Mapping Protocol (NAT-PMP), and shares similar semantics,
concepts, and packet formats. Because of this NAT-PMP and PCP
can both use the same port, and use the NAT-PMP and PCP's
version negotiation capabilities to determine which version to
use. This section describes how an orderly transition may be
achieved.</t>
<section title="NAT-PMP Clients Updated to Add PCP Support">
<t>A client supporting both NAT-PMP and PCP SHOULD optimistically
assume that the gateway supports PCP, since we expect that this will
rapidly become the case, and we want to optimize for better
performance in this case. A dual-mode client SHOULD send all its
requests first using PCP packet format. If the gateway responds with a
packet four or more bytes long, containing the following (NAT-PMP
format) data in the first four bytes, then the dual-mode client SHOULD
conclude that this NAT gateway supports only NAT-PMP, and SHOULD retry
its request in the older NAT-PMP format.</t>
<figure align="left" anchor="PMPGate"
title="NAT-PMP Gateway Response to PCP Request">
<preamble>NAT-PMP gateways respond to PCP requests with the
following packet. The first byte (supported version) is zero. The
second byte (opcode) echoes back the request opcode, with the top
bit set. The third byte (high byte of the NAT-PMP error code) is
zero. The fourth byte is 1 (NAT-PMP and PCP error code "Unsupported
Version").</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Version = 0 |R| OP = any | Zero | Result = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="NAT-PMP Gateways Updated to Add PCP Support">
<t>A gateway supporting both NAT-PMP and PCP is able to handle and
respond to requests using both packet formats. If the first byte of
the packet is zero, a dual-mode gateway SHOULD parse the request as a
NAT-PMP-format message and reply using a NAT-PMP-format response.
Otherwise it should parse the request as a PCP-format message and
respond accordingly.</t>
<t>A PCP-only gateway receiving a NAT-PMP request (identified by the
first byte being zero) MUST reply with the packet shown below, so that
the NAT-PMP may log an error message informing the user that they need
to update to a PCP-capable client.</t>
<figure align="left" anchor="PCPGate"
title="PCP Gateway Response to NAT-PMP Request">
<preamble>PCP gateways respond to NAT-PMP requests (identified by
the first byte being zero) with the following packet. The first byte
(supported version) is 1. The second byte (opcode) echoes back the
request opcode, with the top bit set. The third byte (high byte of
the NAT-PMP error code) is zero. The fourth byte is 1 (NAT-PMP and
PCP error code "Unsupported Version").</preamble>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Version = 1 |R| OP = any | Zero | Result = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
</section>
-->
<section title="Deployment Considerations">
<section title="Ingress Filtering">
<t>To prevent spoofing of PCP requests, <xref target="RFC2827">ingress
filtering</xref> MUST be performed by devices between the PCP clients
and PCP server. For example, with a PCP server integrated into a
customer premise router, the Ethernet switch needs to perform ingress
filtering. As another example, with a PCP server deployed by a service
provider, the service provider's aggregation router (the first device
connecting to subscribers) needs to do ingress filtering.</t>
</section>
<section anchor="quota" title="Per-Subscriber Explicit Dynamic Mapping 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
quota for explicit dynamic mappings. It is implementation-specific
if the PCP server has a separate or combined quota for both implicit
dynamic mappings (e.g., created by TCP SYNs) and explicit dynamic
mappings (created using PCP).</t>
</section>
</section>
<!--
<section anchor="scenarios" title="Deployment Scenarios">
<section title="Dual-Stack Lite">
<t>The interesting components in a Dual-Stack Lite deployment are the
B4 element (which is the customer premises router) and the
Address Family Transition Router (AFTR) element. The AFTR element
terminates the IPv6-over-IPv4 tunnel and also implements a
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>
<t>Various PCP deployment scenarios can be considered to control the
PCP server embedded in the AFTR element:<list style="numbers">
<t>If 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. Details of this interworking function are left for future work.</t>
<t>Hosts behind the B4 element will either include a PCP client, UPnP IGD client, NAT-PMP client, or combination of these three. <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 its nearest PCP server (e.g., built
into its B4 element).</t>
<t>if a NAT-PMP client, the NAT-PMP client will communicate with its default gateway (its B4 element), which will proxy NAT-PMP to the Dual-Stack Lite AFTR element. Details of this proxy function are left for future work.</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. When proxying
for other hosts, the B4 element will use the THIRD_PARTY
Option with the MAP and PEER OpCodes.</t>
</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). For example, in such situations, the IPv6 host can use
the MAP4 OpCode to operate a server that listens on the IPv4
Internet.</t>
<t>If the IANA-assigned IP address is used for the discovery of the
PCP server, that IPv4 address can be placed into the IPv6 destination
address following that particular network's well-known prefix or
network-specific prefix, per <xref target="RFC6052"></xref>.</t>
</section>
<section title="NAT44 and NAT444">
<t>Residential subscribers in NAT44 (and NAT444) deployments are
usually given one IPv4 address, but may also be given several IPv4
addresses. These addresses are not routable on the IPv4 Internet, but
are routable between the subscriber's home and the ISP's CGN. To
accommodate multiple hosts within a home, especially when provided
insufficient IPv4 addresses for the number of devices in the home,
subscribers operate a NAPT device. When this occurs in conjunction
with an upstream NAT44, this is nicknamed "NAT444".</t>
<list style="empty">
<t>[Ed. Note: Does PCP need a mechanism to detect a
non-PCP-supporting NAT between a PCP client and a PCP server? Or
can that problem be detected by relying on the failure of PCP
server Discovery? This is tracked as PCP Issue #25 <xref
target="PCP-Issues"></xref>.]</t>
</list></t>
</section>
<section title="IPv6 Simple Firewall">
<t>Many IPv6 deployments will include a <xref target="RFC6092">simple
firewall</xref>, which permits outgoing packets to initiate
bi-directional communication but blocks unsolicited incoming packets,
which is similar to PCP's security model that allows a host to create
a mapping to itself. In many situations, especially residential
networks that lack an IT staff, the security provided by an IPv6
simple firewall and the security provided by PCP are compatible. In
such situations, the IPv6 simple firewall and the IPv6 host can use
the MAP6 OpCode to allow unsolicited incoming packets, so the host can
operate a server.</t>
</section>
</section>
-->
<!--
<section anchor="upnp-interworking"
title="Interworking with UPnP IGD 1.0 and 2.0">
<t><list style="empty">
<t>[Ed. Note: This UPnP IGD Interworking section will likely be
moved to a separate document which will fully describe how a proxy
needs to translate UPnP IGD messages into PCP messages. This is
tracked as PCP Issue #28 <xref target="PCP-Issues"></xref>.]</t>
</list></t>
<t>The following diagram shows how UPnP IGD can be interworked with PCP,
using an interworking function (IWF).</t>
<figure align="center" anchor="igd-interworking-function"
title="Network Diagram, Interworking UPnP IGD and PCP">
<artwork><![CDATA[
xxx
]]></artwork>
</figure>
<section title="UPnP IGD 1.0 with AddPortMapping Action">
<t>In <xref target="IGD">UPnP IGD 1.0</xref> it is only possible to
request a specific port using the AddPortMapping action. Requiring a
specific port is incompatible with both (1) a Carrier-Grade NAT and
with (2) widely-deployed applications. Regarding (1), another
subscriber is likely to already be using the same port, so it will be
unavailable to this application to operate a server. Regarding (2), if
the same popular application exists on two devices behind the same
NAPT, they cannot both get the same port. PCP cannot correct this
behavior of UPnP IGD:1, but PCP does work with this behavior.</t>
<t>Due to this incompatibility with address sharing and popular
applications, future hosts and applications will either support UPnP
IGD 2.0's AddAnyPortMapping method (see <xref
target="upnp-2-interworking"></xref>) or, more likely, will support
PCP natively.</t>
<t>When a requested port assignment fails, most UPnP IGD control
points will retry the port assignment requesting the next higher port
or requesting a random port. These UPnP IGD requests are translated to
PCP requests and sent to the PCP server. The requests include the
PREFER_FAILURE option, which causes the PCP server to return an error
if it cannot allocate the requested port. The interworking function
translates the PCP error response to a UPnP IGD error response. This
repeats until the UPnP IGD client gives up or until the PCP server is
able to return the requested port.</t>
<figure align="left" anchor="message-flow-upnp-1"
title="Message Flow: Interworking from UPnP IGD 1.0 AddPortMapping action to PCP">
<preamble>Message flow would be similar to this:</preamble>
<artwork align="center"><![CDATA[
UPnP Control Point in-home CPE PCP server
xxx
]]></artwork>
</figure>
</section>
<section anchor="upnp-2-interworking"
title="UPnP IGD 2.0 with AddAnyPortMapping Action">
<t>If the UPnP IGD control point and the UPnP IGD interworking
function both implement <xref target="IGD-2">UPnP IGD 2.0</xref> and
the UPnP IGD control point uses IGD 2's new AddAnyPortMapping action,
only one round-trip is necessary. This is because AddAnyPortMapping
has semantics similar to PCP's semantics, allowing the PCP server to
assign any port.</t>
<figure align="left" anchor="message-flow-upnp-2"
title="Message Flow: Interworking from UPnP IGD 2.0 AddAnyPortMapping action to PCP">
<preamble>Message flow would be similar to this:</preamble>
<artwork align="center"><![CDATA[
UPnP Control Point in-home CPE PCP server
xxx
]]></artwork>
</figure>
</section>
<section title="Lifetime Maintenance">
<t>UPnP IGD 1.0 and 2.0 provide a lifetime (PortMappingLeaseDuration),
but it is seldom used by UPnP IGD control points, and does not allow
the UPnP IGD to override the requested duration. Thus, the UPnP
IGD/PCP interworking function is responsible for extending the
lifetime of mappings that are still interesting to the UPnP IGD
control point.</t>
<t><list style="empty">
<t>Note: It can be an implementation advantage, where possible,
for the UPnP IGD/PCP interworking function to request a port
mapping lifetime only while that client is active and connected.
For example, creating a PCP mapping that is equal to the client's
remaining DHCP lifetime is one useful approach.</t>
</list></t>
</section>
</section>
-->
<section anchor="security" title="Security Considerations">
<t>This document defines Port Control Protocol and two types of OpCodes,
PEER and MAP. The PEER OpCode allows querying and extending (if
permitted) the lifetime of an existing implicit dynamic mapping, so a
host can reduce its keepalive messages. The MAP OpCode allows creating a
mapping so a host can receive incoming unsolicited connections from the
Internet in order to run a server.</t>
<t>The PEER OpCode does not introduce any new security
considerations, unless the THIRD_PARTY Option is included.
Discussion of the THIRD_PARTY Option is below.</t>
<t>With the exception of wireless providers (who are interested in
protecting their radio access network), Internet service providers do
not typically filter traffic from the Internet towards their
subscribers. However, when an ISP introduces stateful address sharing
with a NAPT device, such filtering will occur as a side effect of the
NAPT device. Filtering will also occur with an IPv6 CPE <xref
target="RFC6092"></xref>. The MAP OpCode allows a PCP client to create a
mapping so that a host can receive inbound traffic and operate a server.
Security considerations for the MAP OpCode are described in the
following sections.</t>
<section title="Denial of Service">
<t>Because of 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 (or for another host), 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
relies on the same ingress filtering as implicit dynamic mappings and
does not create a new requirement for ingress filtering.</t>
</section>
<section anchor="subscriber_identification"
title="Validating THIRD_PARTY Internal Address">
<t>The THIRD_PARTY Option contains a Internal Address field,
which allows a PCP client to create, extend, or delete an
implicit or explicit dynamic mapping for another host.</t>
<t>In scenarios where the subscriber has one IP address (e.g.,
as commonly occurs with IPv4 residential deployments) or the
subscriber has multiple IP addresses and a CP router enforces
a PCP policy (by operating its own PCP server or performing
filtering <xref target="RFC6092"></xref>), the PCP server in
both the CP router and the ISP's equipment will both reject
any message containing THIRD_PARTY. Thus, PCP cannot be used
by a host to 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>In other scenarios, where the subscriber has multiple IP
addresses and the subscriber CP router is not filtering, but
the ISP is providing filtering, the ISP should only accept PCP
messages containing the THIRD_PARTY Option from the IP address
of the customer's router, 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 title="Interference by Other Applications on Same Host">
<t>An application running on a host can send PCP messages which create
or delete mappings for ports related to other applications on that
same host. This is by design. To reduce interference with other
applications, it is strongly RECOMMENDED that applications
implementing PCP themselves refrain from performing the delete-all MAP
function (lifetime=0, port=0). Instead, it is RECOMMENDED that the MAP
delete-all function be performed by the underlying operating
system.</t>
</section>
<section anchor="theft" title="Theft of mapping">
<t>In the time between when a PCP server loses state and the
PCP client notices the lower-than-expected Epoch value, it is
possible that the PCP client's mapping will be acquired by
another host (via an explicit dynamic mapping or implicit
dynamic mapping). This means incoming traffic will be sent to
a different host ("theft"). A mechanism to immediately inform
the PCP client of state loss would reduce this interval, but
would not eliminate this threat. The PCP client can reduce
this interval by using a relatively short lifetime; however,
this increases the amount of PCP chatter. This threat is
eliminated by using persistent storage of explicit dynamic
mappings in the PCP server (so it does not lose explicit
dynamic mapping state). This threat can be mitigated by
authenticating the data connection between the hosts (e.g.,
using TLS).</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>PCP will use port 5351 (currently assigned by IANA to NAT-PMP). We
request that IANA re-assign that same port number to PCP, and
relinquish UDP port 44323.</t>
</section>
<section anchor="iana_opcodes" title="OpCodes">
<t>IANA shall create a new protocol registry for PCP OpCodes,
initially populated with the values in <xref
target="map_opcodes"></xref> and <xref target="peer_opcodes"></xref>.
The values 0 and 127 are reserved.</t>
<t>Additional OpCodes in the range 4-95 can be created via <xref
target="RFC5226">Standards Action</xref>, and the range 96-126 is for
<xref target="RFC5226">Private Use</xref>.</t>
</section>
<section anchor="iana_result_codes" title="Result Codes">
<t>IANA shall create a new registry for PCP result codes, numbered
0-255, initially populated with the result codes from <xref
target="result_codes"></xref>, <xref
target="map_result_codes"></xref>, <xref target="filter"></xref>, and
<xref target="third_party"></xref>. The values 0 and 255 are
reserved.</t>
<t>Additional Result Codes can be defined via <xref
target="RFC5226">Specification Required</xref>.</t>
</section>
<section anchor="iana_ie" title="Options">
<t>IANA shall create a new registry for PCP Options, numbered 0-255
with an associated mnemonic. The values 0-127 are
mandatory-to-process, and 128-255 are optional-to-process. The initial
registry contains the options described in <xref
target="map_peer_options"></xref> and <xref
target="third_party"></xref>. The option values 0, 127, and 255 are
reserved.</t>
<t>Additional PCP option codes in the ranges 5-63 and 128-191 can be
created via <xref target="RFC5226">Standards Action</xref>, and the
ranges 64-126 and 192-254 are for <xref target="RFC5226">Private
Use</xref>.</t>
</section>
</section>
<section title="Acknowledgments">
<t>Thanks to Alain Durand, Christian Jacquenet, Jacni Qin, Simon
Perreault, Paul Selkirk, and James Yu for their comments and review.
Thanks to Simon Perreault for highlighting the interaction of dynamic
connections with PCP-created mappings.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.0768"?>
<?rfc include="reference.RFC.2827"?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate'?>
<?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.I-D.ietf-softwire-dual-stack-lite'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate-stateful'?>
<?rfc include='reference.RFC.4941'?>
<?rfc include='reference.RFC.3587'?>
<?rfc include='reference.RFC.4787'?>
<?rfc include='reference.RFC.5382'?>
<?rfc include='reference.RFC.1918'?>
<?rfc include='reference.RFC.4961'?>
<?rfc include='reference.RFC.3581'?>
<?rfc include='reference.RFC.3022'?>
<!--
<?rfc include='reference.RFC.5461'?>
-->
<?rfc include='reference.RFC.3424'?>
<?rfc include='reference.I-D.miles-behave-l2nat'?>
<?rfc include='reference.RFC.6092'?>
<?rfc include='reference.I-D.bpw-pcp-upnp-igd-interworking'?>
<?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
<?rfc include='reference.I-D.cheshire-nat-pmp'?>
<?rfc include='reference.I-D.arkko-dual-stack-extra-lite'?>
<reference anchor="IGD"
target="http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf">
<front>
<title>WANIPConnection:1</title>
<author fullname="UPnP Gateway Committee"
surname="UPnP Gateway Committee">
<organization>UPnP Forum</organization>
</author>
<date month="November" year="2001" />
</front>
</reference>
<!--
<reference anchor="IGD-2"
target="http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf">
<front>
<title>Internet Gateway Device (IGD) V 2.0</title>
<author fullname="UPnP Gateway Committee"
surname="UPnP Gateway Committee">
<organization>UPnP Forum</organization>
</author>
<date month="September" year="2010" />
</front>
</reference>
-->
<!--
<reference anchor="PCP-Issues"
target="http://trac.tools.ietf.org/wg/pcp/trac/report/1">
<front>
<title>PCP Active Tickets</title>
<author fullname="PCP Working Group" surname="PCP Working Group">
<organization>IETF</organization>
</author>
<date month="January" year="2011" />
</front>
</reference>
-->
<!--
<reference anchor="I-D.bpw-pcp-proxy">
<front>
<title>Port Control Protocol (PCP) Proxy Function</title>
<author fullname="Mohammed Boucadair" initials="M"
surname="Boucadair">
<organization></organization>
</author>
<author fullname="Reinaldo Penno" initials="R" surname="Penno">
<organization></organization>
</author>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization></organization>
</author>
<author fullname="Francis Dupont" initials="F" surname="Dupont">
<organization></organization>
</author>
<date day="27" month="February" year="2011" />
<abstract>
<t>This document specifies the behavior of a PCP Proxy element,
for instance embedded in Customer Premise routers.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-bpw-pcp-proxy-00" />
<format target="http://www.ietf.org/internet-drafts/draft-bpw-pcp-proxy-00.txt"
type="TXT" />
</reference>
-->
<!--
<reference anchor="I-D.wing-pcp-nested-nat">
<front>
<title>Using PCP With One Nested NAT</title>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization></organization>
</author>
<date month="January" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-wing-pcp-nested-nat-00" />
<format target="http://www.ietf.org/internet-drafts/draft-wing-pcp-nested-nat-00.txt"
type="TXT" />
</reference>
-->
</references>
<section title="NAT-PMP Transition">
<t>The Port Control Protocol (PCP) is a successor to the NAT Port
Mapping Protocol (NAT-PMP), and shares similar semantics, concepts, and
packet formats. Because of this NAT-PMP and PCP both use the same port,
and use the NAT-PMP and PCP's version negotiation capabilities to
determine which version to use. This section describes how an orderly
transition may be achieved.</t>
<t>A client supporting both NAT-PMP and PCP SHOULD send its request
using the PCP packet format. This will be received by a NAT-PMP server
or a PCP server. If received by a NAT-PMP server, the response will be
as indicated by <xref target="I-D.cheshire-nat-pmp"></xref>, which will
cause the client to downgrade to NAT-PMP and re-send its request in
NAT-PMP format. If received by a PCP server, the response will be as
described by this document and processing continues as expected.</t>
<t>A PCP server supporting both NAT-PMP and PCP can respond to requests
in either format. The first byte of the packet indicates if it is
NAT-PMP (first byte zero) or PCP (first byte non-zero).</t>
<t>A PCP-only gateway receiving a NAT-PMP request (identified by the
first byte being zero) will interpret the request as a version mismatch.
Normal PCP processing will emit a PCP response that is compatible with
NAT-PMP, without any special handling by the PCP server.</t>
</section>
<section title="Change History">
<t>[Note to RFC Editor: Please remove this section prior to
publication.]</t>
<section title="Changes from draft-ietf-pcp-base-07 to -08">
<t><list style="symbols">
<t>moved all MAP4-, MAP6-, and PEER-specific options into a single
section.</t>
<t>discussed NAPT port-overloading and its impact on MAP
(new section <xref target="non-eim"></xref>), which allowed
removing the IMPLICIT_MAPPING_EXISTS error.</t>
<t>eliminated NONEXIST_PEER error (which was returned if a PEER
request was received without an implicit dynamic mapping
already being created), and adjusted PEER so that it creates an
implicit dynamic mapping.</t>
<t>Removed Deployment Scenarios section (which detailed NAT64,
NAT44, Dual-Stack Lite, etc.).</t>
<t>Added Client's IP Address to PCP common header. This allows server
to refuse a PCP request if there is a mismatch with the source IP
address, such as when a non-PCP-aware NAT was on the path. This
should reduce failure situations where PCP is deployed in conjunction
with a non-PCP-aware NAT. This addition was consensus at IETF80.</t>
<t>Changed UNSPECIFIED_ERROR to PROCESSING_ERROR. Clarified that
MALFORMED_REQUEST is for malformed requests (and not related to failed
attempts to process the request).</t>
<t>Removed MISORDERED_OPTIONS. Consensus of IETF80.</t>
<t>SERVER_OVERLOADED is now a common PCP error (instead of specific to MAP).</t>
<t>Tweaked PCP retransmit/retry algorithm again, to allow more aggressive
PCP discovery if an implementation wants to do that.</t>
<t>Version negotation text tweaked to soften NAT-PMP reference, and
more clearly explain exactly what UNSUPP_VERSION should return.</t>
<t>PCP now uses NAT-PMP's UDP port, 5351. There are no normative
changes to NAT-PMP or PCP to allow them both to use the same port
number.</t>
<t>New Appendix A to discuss NAT-PMP / PCP interworking.</t>
<t>improved pseudocode to be non-blocking.</t>
<t>clarified that PCP cannot delete a static mapping (i.e., a mapping
created by CLI or other non-PCP means).</t>
<t>moved theft of mapping discussion from Epoch section to Security
Considerations, (<xref target="theft"></xref>).</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-06 to -07">
<t><list style="symbols">
<t>tightened up THIRD_PARTY security discussion. Removed "highest
numbered address", and left it as simply "the CPE's IP
address".</t>
<t>removed UNABLE_TO_DELETE_ALL error.</t>
<t>renumbered Opcodes</t>
<t>renumbered some error codes</t>
<t>assigned value to IMPLICIT_MAPPING_EXISTS.</t>
<t>UNPROCESSED can include arbitrary number of option codes.</t>
<t>Moved lifetime fields into common request/response headers</t>
<t>We've noticed we're having to repeatedly explain to people that
the "requested port" is merely a hint, and the NAT gateway is free
to ignore it. Changed name to "suggested port" to better convey
this intention.</t>
<t>Added NAT-PMP transition section</t>
<t>Separated Internal Address, External Address, Remote Peer
Address definition</t>
<t>Unified Mapping, Port Mapping, Port Forwarding definition</t>
<t>adjusted so DHCP configuration is non-normative.</t>
<t>mentioned PCP refreshes need to be sent over the same
interface.</t>
<t>renamed the REMOTE_PEER_FILTER option to FILTER.</t>
<t>Clarified FILTER option to allow sending an ICMP error if
policy allows.</t>
<t>for MAP, clarified that if the PCP client changed its IP
address and still wants to receive traffic, it needs to send a new
MAP request.</t>
<t>clarified that PEER requests have to be sent from same
interface as the connection itself.</t>
<t>for MAP opcode, text now requires mapping be deleted when
lifetime expires (per consensus on 8-Mar interim meeting)</t>
<t>PEER OpCode: better description of remote peer's IP address,
specifically that it does not control or establish any filtering,
and explaining why it is 'from the PCP client's perspective'.</t>
<t>Removed latent text allowing DMZ for 'all protocols'
(protocol=0). Which wouldn't have been legal, anyway, as protocol
0 is assigned by IANA to HOPOPT (thanks to James Yu for catching
that one).</t>
<t>clarified that PCP server only listens on its internal
interface.</t>
<t>abandoned 'target' term and reverted to simplier 'internal'
term.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-05 to -06">
<t><list style="symbols">
<t>Dual-Stack Lite: consensus was encapsulation mode. Included a
suggestion that the B4 will need to proxy PCP-to-PCP and
UPnP-to-PCP.</t>
<t>defined THIRD_PARTY option to work with the PEER OpCode, too.
This meant moving it to its own section, and having both MAP and
PEER OpCodes reference that common section.</t>
<t>used "target" instead of "internal", in the hopes that
clarifies internal address used by PCP itself (for sending its
packets) versus the address for MAPpings.</t>
<t>Options are now required to be ordered in requests, and
ordering has to be validated by the server. Intent is to ease
server processing of mandatory-to-implement options.</t>
<t>Swapped Option values for the mandatory- and
optional-to-process Options, so we can have a simple
lowest..highest ordering.</t>
<t>added MISORDERED_OPTIONS error.</t>
<t>re-ordered some error messages to cause MALFORMED_REQUEST
(which is PCP's most general error response) to be error 1,
instead of buried in the middle of the error numbers.</t>
<t>clarified that, after successfully using a PCP server, that PCP
server is declared to be non-responsive after 5 failed
retransmissions.</t>
<t>tightened up text (which was inaccurate) about how long general
PCP processing is to delay when receiving an error and if it
should honor OpCode-specific error lifetime. Useful for MAP errors
which have an error lifetime. (This all feels awkward to have only
some errors with a lifetime.)</t>
<t>Added better discussion of multiple interfaces, including
highlighting WiFi+Ethernet. Added discussion of using IPv6 Privacy
Addresses and RFC1918 as source addresses for PCP requests. This
should finish the section on multi-interface issues.</t>
<t>added some text about why server might send SERVER_OVERLOADED,
or might simply discard packets.</t>
<t>Dis-allow internal-port=0, which means we dis-allow using PCP
as a DMZ-like function. Instead, ports have to be mapped
individually.</t>
<t>Text describing server's processing of PEER is tightened
up.</t>
<t>Server's processing of PEER now says it is
implementation-specific if a PCP server continues to allow the
mapping to exist after a PEER message. Client's processing of PEER
says that if client wants mapping to continue to exist, client has
to continue to send recurring PEER messages.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-04 to -05">
<t><list style="symbols">
<t>tweaked PCP common header packet layout.</t>
<t>Re-added port=0 (all ports).</t>
<t>minimum size is 12 octets (missed that change in -04).</t>
<t>removed Lifetime from PCP common header.</t>
<t>for MAP error responses, the lifetime indicates how long the
server wants the client to avoid retrying the request.</t>
<t>More clearly indicated which fields are filled by the server on
success responses and error responses.</t>
<t>Removed UPnP interworking section from this document. It will
appear in <xref
target="I-D.bpw-pcp-upnp-igd-interworking"></xref>.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-03 to -04">
<t><list style="symbols">
<t>"Pinhole" and "PIN" changed to "mapping" and "MAP".</t>
<t>Reduced from four MAP OpCodes to two. This was done by
implicitly using the address family of the PCP message itself.</t>
<t>New option THIRD_PARTY, to more carefully split out the case
where a mapping is created to a different host within the
home.</t>
<t>Integrated a lot of editorial changes from Stuart and
Francis.</t>
<t>Removed nested NAT text into another document, including the
IANA-registered IP addresses for the PCP server.</t>
<t>Removed suggestion (MAY) that PCP server reserve UDP when it
maps TCP. Nobody seems to need that.</t>
<t>Clearly added NAT and NAPT, such as in residential NATs, as
within scope for PCP.</t>
<t>HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE</t>
<t>Added 'Lifetime' field to the common PCP header, which replaces
the functions of the 'temporary' and 'permanent' error types of
the previous version.</t>
<t>Allow arbitrary Options to be included in PCP response, so that
PCP server can indicate un-supported PCP Options. Satisfies PCP
Issue #19</t>
<t>Reduced scope to only deal with mapping protocols that have
port numbers.</t>
<t>Reduced scope to not support DMZ-style forwarding.</t>
<t>Clarified version negotiation.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-02 to -03">
<t><list style="symbols">
<t>Adjusted abstract and introduction to make it clear PCP is
intended to forward ports and intended to reduce application
keepalives.</t>
<t>First bit in PCP common header is set. This allows DTLS and
non-DTLS to be multiplexed on same port, should a future update to
this specification add DTLS support.</t>
<t>Moved subscriber identity from common PCP section to MAP*
section.</t>
<t>made clearer that PCP client can reduce mapping lifetime if it
wishes.</t>
<t>Added discussion of host running a server, client, or symmetric
client+server.</t>
<t>Introduced PEER4 and PEER6 OpCodes.</t>
<t>Removed REMOTE_PEER Option, as its function has been replaced
by the new PEER OpCodes.</t>
<t>IANA assigned port 44323 to PCP.</t>
<t>Removed AMBIGUOUS error code, which is no longer needed.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-01 to -02">
<t><list style="symbols">
<t>more error codes</t>
<t>PCP client source port number should be random</t>
<t>PCP message minimum 8 octets, maximum 1024 octets.</t>
<t>tweaked a lot of text in section 7.4, "Opcode-Specific Server
Operation".</t>
<t>opening a mapping also allows ICMP messages associated with
that mapping.</t>
<t>PREFER_FAILURE value changed to the mandatory-to-process
range.</t>
<t>added text recommending applications that are crashing obtain
short lifetimes, to avoid consuming subscriber's port quota.</t>
</list></t>
</section>
<section title="Changes from draft-ietf-pcp-base-00 to -01">
<t><list style="symbols">
<t>Significant document reorganization, primarily to split base
PCP operation from OpCode operation.</t>
<t>packet format changed to move 'protocol' outside of PCP common
header and into the MAP* opcodes</t>
<t>Renamed Informational Elements (IE) to Options.</t>
<t>Added REMOTE_PEER (for disambiguation with dynamic ports),
REMOTE_PEER_FILTER (for simple packet filtering), and
PREFER_FAILURE (to optimize UPnP IGD interworking) options.</t>
<t>Is NAT or router behind B4 in scope?</t>
<t>PCP option MAY be included in a request, in which case it MUST
appear in a response. It MUST NOT appear in a response if it was
not in the request.</t>
<t>Result code most significant bit now indicates
permanent/temporary error</t>
<t>PCP Options are split into mandatory-to-process ("P" bit), and
into Specification Required and Private Use.</t>
<t>Epoch discussion simplified.</t>
</list></t>
</section>
</section>
<!--
<section anchor="discovery_analysis"
title="Analysis of Techniques to Discover PCP Server">
<t><list style="empty">
<t>[Ed. Note: This Appendix will be removed in a later version of
this document. It is included here for reference and discussion
purposes. This is tracked as PCP Issue #8 <xref
target="PCP-Issues"></xref>.]</t>
</list></t>
<t><list style="empty">
<t>Discussion Note: A deployment model is a non-PCP aware NAT in a
home, and a PCP-aware CGN operated by the ISP. For example, the home
users purchased a NAT last year at a computer shop (to extend their
home's WiFi network). This could work by having the host use UPnP
IGD with the in-home NAT, and the host use PCP with the LSN. But
this deployment model is impossible with several of the mechanisms
below. Is this deployment model important, or can we wait for PCP to
be enabled on CPE?</t>
</list></t>
<t>Several mechanisms for discovering the PCP server can be envisaged as
listed below:</t>
<t><list style="numbers">
<t>A special-purpose IPv4 or IPv6 address, assigned by IANA, which
is routed normally until it hits a PCP server, which responds. <list
style="empty">
<t>Analysis: This solution can be deployed in the context of
DS-Lite architecture. Concretely, a well-known IPv4 address can
be used to reach a PCP server embedded in the device that embeds
the AFTR capabilities. Since all IPv4 messages issued by a
DS-Lite CP router will be encapsulated in IPv6, no state
synchronisation issues will be experienced because PCP messages
will be handled by the appropriate PCP server.</t>
<t>In some deployment scenarios (e.g., deployment of several
stateful NAT64/NAT46 in the same domain), the use of this
address is not recommended since PCP messages, issued by a given
host, may be handled by a PCP server embedded in a NAT node
which is not involved to handle IP packets issued from that
host. The use of this special-purpose IP address may induce
session failures and therefore the customer may experience
troubles when accessing its services.</t>
<t>Consequently, the use of a special-purpose IPv4 address is
suitable for DS-Lite NAT44. As for NAT46/NAT64, this is left to
the Service Providers according to their deployment
configuration.</t>
<t>The special-use address MUST NOT be advertised in the global
routing table. Packets with that destination address SHOULD be
filtered so they are not transmitted on the Internet.</t>
</list></t>
<t>Assume the default router is a PCP server, and send PCP packets
to the IP address of the default router. <list style="empty">
<t>Analysis: This solution is not suitable for DS-Lite NAT44 nor
for all variants of NAT64/NAT46. <list style="empty">
<t>In the context of DS-Lite: There is no default IPv4
router configured in the CP router. All outgoing IPv4
traffic is encapsulated in IPv6 and then forwarded to a
pre-configured DS-Lite AFTR device. Furthermore, if IPv6 is
used to reach the PCP server, the first router may not be
the one which embeds the AFTR.</t>
<t>For NAT64/NAT46 scenarios: The NAT function is not
embedded in the first router, therefore this solution
candidate does not allow to discover a valid PCP server.</t>
</list></t>
<t>Therefore, this alternative is not recommended.</t>
</list></t>
<t>Service Location Protocol (<xref
target="RFC2608">SLP</xref>).<list style="empty">
<t>Analysis: This solution is not suitable in scenarios where
multicast is not enabled. SLP is a chatty protocol. Also, as
with UPnP IGD's use of SSDP, SLP will discover NAT gateways
which exist on the local network, but are not actually on the
path that packets will take from the Internal Host to the
Internet, leading to the situation where Internal Hosts create
apparently-successful mappings, which are in fact completely
worthless for the purpose of establishing useful communication
with Remote Hosts on the Internet. This alternative is not
recommended.</t>
</list></t>
<t>NAPTR. The host would issue a DNS query for a NAPTR record,
formed from some bits of the host's IPv4 or IPv6 address. For
example, a host with the IPv6 address 2001:db8:1:2:3:4:567:89ab
would first send an NAPTR query for
3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements,
representing a /64 network prefix), which returns the PCP server's
IPv6 address. A similar scheme can be used with IPv4 using, for
example, the first 24 bits of the IPv4 address.<list style="empty">
<t>Analysis: This solution candidate requires more configuration
effort by the Service Provider so as to redirect a given client
to the appropriate PCP server. Any change of the engineering
policies (e.g., introduce new LSN device, load-based
dimensioning, load-balancing, etc.) would require to update the
zone configuration. This would be a hurdle for the flexibility
of the operational networks. Adherence to DNS is not encouraged
and means which allows for more flexibility are to be
promoted.</t>
<t>Therefore, this mechanism is not recommended.</t>
</list></t>
<t>New DHCPv6/DHCP option and/or a RA option to convey an FQDN of a
PCP server.<list style="empty">
<t>Analysis: Since DS-Lite and NAT64/NAT46 are likely to be
deployed in provider-provisioned environments, DHCP (both DHCPv6
and IPv4 DHCP) is convenient to provision the address/FQDN of
the PCP server.</t>
</list></t>
</list></t>
</section>
-->
<!--
<section title="Contributors' Addresses">
<t>The following individuals contributed substantial text to this
document and are listed in alphabetical order:</t>
<figure>
<artwork align="left"><![CDATA[
Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, California 95014
USA
Phone: +1 408 974 3207
Email: cheshire@apple.com
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Reinaldo Penno
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, California 94089
USA
Email: rpenno@juniper.net
Francis Dupont
Internet Systems Consortium
Email: fdupont@isc.org
]]></artwork>
</figure>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:46 |