One document matched: draft-ietf-pcp-base-00.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-00" ipr="trust200902">
<front>
<title abbrev="Port Control Protocol (PCP)">Port Control Protocol
(PCP)</title>
<author fullname="Dan Wing" initials="D." 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>
<date />
<workgroup>PCP working group</workgroup>
<abstract>
<t>Port Control Protocol is an address-family independent mechanism to
control how incoming packets are forwarded by upstream devices such as
network address translators (NATs) and simple IPv6 firewalls.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Pinhole Control Protocol (PCP) provides a mechanism to control how
incoming packets are forwarded by upstream devices such as NATs and
firewalls. PCP is primarily designed to be implemented in the context of
both large scale NAT and low-scale NAT (e.g., residential NATs). PCP
allows hosts to operate servers permanently (e.g., a webcam) or
temporarily (e.g., while playing a game) when behind one or more NAT
devices, including when behind a large-scale NAT operated by their
Internet service provider.</t>
<t>PCP allows applications to create pinholes from an external IP
address to an internal IP address and port. If the PCP-controlled device
is a NAT, a mapping is created; if the PCP-controlled device is a
firewall, a pinhole is created in the firewall. These pinholes are
required for successful inbound communications destined to machines
located behind a NAT.</t>
<t>After creating a pinhole 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 rendzevous 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.</t>
<!--
> 1. define new IE, EVEN_PLUS_ONE, which has no payload.
>
> 2. PCP request is sent, with that IE.
>
> 3. PCP server attempts to allocate an even port number, and
> PCP server reserves the adjacent port number (sticks it
> on the TIME_WAIT queue for 5 seconds, and it is only allocatable
> to the same IP address as got the even port number).
>
> Maybe we have PCP server return an IE EVEN_PLUS_ONE if it
> was able to allocate the adjacent port. That seems helpful
> for the next steps.
>
> 4. VoIP endpoint can send its SIP/SDP message now. Total
> delay: one round trip to PCP server.
>
> 5. A second PCP request is sent, without the IE, requesting
> port+1.
>
> Med: I still we can avoid some extra exchanges with the server (for
> instance in your bullet 5, you will need to do it for all the media you
> are negotiating including audio, video, etc.).
If the endpoint needs to do audio and video, it will send two PCP
requests, at the same time, in step 2. This will result in two
PCP responses in step 4.
As soon as the audio+video session is established, there will be
at least 50 packets per second of video and ~20-50 packets per
second of video.
Here are the scenarios:
1. internal host is IPv4 only
2. internal host is IPv6 only
3. internal host is dual stack
For (1), that host can only do PIN44 (to get a public IPv4 address)
or PIN46 (to get a public IPv6 address).
For (2), that host can only do PIN66 (to get a public IPv6 address;
mostly this is for IPv6 firewall. Yes, this needs more fleshing
out. Yes, there is an "Ed. Note" to that effect in the document.
Yes, I am aware of that) or PIN64 (to get a public IPv4 address).
For (3), that host can use any of the four opcodes (PIN44, PIN46,
PIN64, PIN66). If it is being reasonable, it won't do PIN46
or PIN64, because it could just keep the IP address family the
same instead because it is dual stack. But we cannot detect
a dual-stack node and there isn't a reason to block it. So,
yes, I suppose a dual-stack host could attempt all four of
the OpCodes. But it would more reasonably do PIN44 to get
a public IPv4 presence and PIN66 to get a public IPv6 presence.
Besides, on a network with a dual-stack host, that network
is unlikely (not not prohibited) to operate a NAT64, and
also unlikely (but not prohibited) to operate a NAT46. This
seems to warrant some text around
In some scenarios communications may fail if intermediary (non
PCP-controlled) firewalls are not appropriately configured to accept
incoming traffic. Detecting the presence of firewall(s) in the path
and configuring it is out of scope of this document
-->
</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">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">Large-Scale
NAT44</xref>, including nested NATs ("NAT444"), and;</t>
<t><xref target="I-D.miles-behave-l2nat">Layer-2 aware NAT</xref>
and <xref target="I-D.arkko-dual-stack-extra-lite">Dual-Stack
Extra Lite</xref>, and;</t>
<t><xref target="I-D.ietf-v6ops-cpe-simple-security">IPv6 firewall
control</xref>.</t>
</list></t>
</section>
<section title="Supported Transport Protocols">
<t>The PCP OpCodes defined in this document are designed to support
transport protocols that uses a port number (e.g., TCP, UDP, SCTP,
DCCP). Transport protocols that do not use a port number (e.g., IPsec
ESP) can be wildcarded (allowing any traffic with that protocol to
pass), provided of course the upstream device being controlled by PCP
supports that functionality, or new PCP OpCodes can be defined to
support those protocols.</t>
<t>In this document, only TCP and UDP are defined.</t>
</section>
<section anchor="mono_homed"
title="Single-homed Customer Premise Network">
<t>The PCP machinery assumes a single-homed subscriber model. That is,
for a given IP version, only one default route exists to reach the
Internet, much as there is only one default route for a dynamic
connection (e.g., TCP SYN) towards the Internet. 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.</t>
</section>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t><list style="hanging">
<t hangText="Port Forwarding:"><list style="empty">
<t>Port forwarding allows a host to receive traffic sent to a
specific IP address and port.</t>
<t>In the context of a NAT with internal and external IP
addresses, if an internal host is listening to connections on a
specific port (that is, operating as a server), the external IP
address and port number need to be port forwarded (also called
"mapped") to the internal IP address and port number. The
internal and external IP addresses are different, and a key
point is that the internal and external transport destination
port numbers could be different. For example, a webcam might be
listening on port 80 on its internal address 192.168.1.1, while
its publicly-accessible external address is 192.0.2.1 and port
is 12345. The NAT does 'port forwarding' of one to the
other.</t>
<t>In the context of a firewall, the internal and external IP
addresses (and ports) are not changed.</t>
</list></t>
<t hangText="PCP Client:"><list style="empty">
<t>A PCP software instance responsible for issuing PCP requests
to a PCP Server. One or several PCP Clients can be embedded in
the same host. Several PCP Clients can be located in the same
local network of a given subscriber. A PCP Client can issue PCP
request on behalf of a third party device of the same
subscriber.</t>
</list></t>
<t hangText="PCP Server:"><list style="empty">
<t>A network element which receives and processes PCP requests
from a PCP Client. See also <xref
target="relationship"></xref>.</t>
</list></t>
<t hangText="Mapping:"><list style="empty">
<t>In the context of Network Address Translation a mapping
creates a relationship between an internal IP transport address
and an external IP transport address. More specifically, it
creates a translation rule where packets destined to the
external IP and port are translated to the internal IP and
port.</t>
</list></t>
<t hangText="Mapping Types:"><list style="empty">
<t>There are three different ways to create mappings: dynamic
(e.g., outgoing TCP SYN), PCP, and static configured (e.g., CLI
or web page) . These mappings are one and the same but their
attributes such as lifetime or filtering might be different.</t>
</list></t>
<t hangText="Interworking Function:">A PCP Interworking Function
denotes a functional element which is responsible for another
protocol with PCP, for example interworking with <xref
target="IGD">UPnP IGD</xref> described in <xref
target="upnp-interworking"></xref>.</t>
</list></t>
</section>
<section anchor="discovery" title="PCP Server Discovery">
<t>There are several possible methods to discover a PCP Service:<list
style="symbols">
<t>sending the PCP message to the default router. This requires the
default router to support PCP.</t>
<t>a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA.
This follows the same routing path as other Internet-bound traffic.
<list style="empty">
<t>[Ed. Note: For an IPv4 address, would the AFTR
element's IPv4 address,
192.0.0.1 <xref target="I-D.ietf-softwire-dual-stack-lite"></xref>,
be suitable as this address for DS-Lite deployments?
Would that same address be suitable for all PCP
deployment scenarios?]</t>
</list></t>
<t>New DHCP option. This requires the local network's DHCP server
support the new option.</t>
</list></t>
<t><list style="empty">
<t>[Ed. Note: more discussion around these methods is necessary to
reach consensus on the best approach(es)s for PCP.]</t>
</list></t>
</section>
<section title="Common Request and Response Header Format">
<t>All PCP messages contain a request (or response) header, opcode-
specific information, and (optional) informational elements. These are
described in the following sections.</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve| OpCode | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Informational Elements :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Ver:">Version is 1</t>
<t hangText="reserve:">4 reserved bits, MUST be sent as 0, MUST be
ignored when received.</t>
<t hangText="OpCode:">defined in <xref
target="opcodes"></xref>.</t>
<t hangText="Protocol:">indicates protocol associated with this
opcode. For example, this field contains 6 (TCP) if the opcode is
intended to create a TCP mapping. Values are taken from the <xref
target="proto_numbers">IANA protocol registry</xref>. If a
particular OpCode does not need the field, it MUST sent as 0 and
MUST be ignored when received.</t>
<t hangText="Reserved:">The reserved fields MUST be sent as 0 and
MUST be ignored when received.</t>
</list></t>
</section>
<section title="Response Header">
<figure align="center" anchor="common_response"
title="Common Response Packet Format">
<preamble>All responses have the following format:</preamble>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve| Opcode+128 | Protocol | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) OpCode-specific response data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Informational Elements :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Ver:">Version is 1</t>
<t hangText="reserve:">4 reserved bits, MUST be sent as 0, MUST be
ignored when received.</t>
<t hangText="OpCode+128:">The OpCode value from the request plus
128.</t>
<t hangText="Protocol:">Protocol field, echoed exactly from the
request</t>
<t hangText="Result Code:">The result code for this response. See
<xref target="result_codes"></xref> for values.</t>
<t hangText="Epoch:">The server's Epoch value. The same value is
used for all PCP clients. See <xref target="epoch"></xref> for
discussion.</t>
</list></t>
</section>
<section anchor="pcp_information_elements" title="Information Elements">
<t>The Informational Elements (IE) allow extending PCP, without
defining a new PCP version and without consuming additional opcodes.
IEs can be used in requests and responses. It is anticipated that IEs
will include information which are associated with the normal function
of an OpCode, such as one of the PIN OpCodes defined in this document.
For example, an IE could indicate DSCP markings to apply to incoming
or outgoing traffic associated with a PCP pinhole, or an IE could
include descriptive text (e.g., "for my webcam").</t>
<t>IEs use the following Type-Length-Value format:</t>
<figure align="center" anchor="IE-layout"
title="Informational Element header">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IE Code | Reserved | IE-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The description of the fields is as follows:<list style="hanging">
<t hangText="IE Code:">IE codes MUST be registered with IANA
following the procedure described in <xref
target="iana_ie"></xref>.</t>
<t hangText="Reserved:">MUST be set to 0 on transmission and MUST
be ignored on reception.</t>
<t hangText="IE-Length:">Indicates in units of 4 octets the length
of the enclosed data. IEs MUST be padded when necessary to 32 bits
boundaries. IEs with length of 0 are allowed.</t>
</list></t>
<t>A given IE MAY be included in the request and/or the response. The
handling of an IE at the PCP Client and the PCP Server sides MUST be
specified in dedicated document(s). <list style="empty">
<t>[Ed. Note: Do we want to allow an unsolicited IE to appear in a
response?]</t>
</list></t>
<t>If several IEs are to be included in a PCP request or response, IEs
MAY be encoded in any order by the PCP Client or the PCP Server.</t>
<t><list style="empty">
<t>[Ed. Note: There are two proposals to handle unsupported IEs on
the server: (1) return a notification in the response with the
Code(s) of unsupported IEs, (2) every IE that appears in a request
will cause an IE to appear in the response if the server
understood the request' IE(s). Consensus is needed.]</t>
</list></t>
<t><list style="empty">
<t>[Ed. Note: There is a proposal to define a Mandatory bit, so
that the PCP server will not process a PCP request at all if it
encounters an unsupported IE with the Mandatory bit set. This
diverges from IE being "informational", but may have some value.
Consensus is needed.]</t>
</list></t>
<t>New IEs are defined in companion documents and MUST follow the
format shown in Figure 1. To avoid errors and increased complexity, it
is RECOMMENDED to define one single IE which carry all the required
information for a given usage instead of defining several IEs to be
included simultaneously in the same PCP message. Interdependence
between IEs SHOULD be avoided at maximum.</t>
</section>
<section anchor="result_codes" title="Result Codes">
<t>The following response codes are defined:</t>
<figure anchor="figure_result_codes" title="PCP Result Codes">
<artwork align="center"><![CDATA[
0 - Success
1 - Unsupported Version
2 - Not Authorized/Refused
(e.g., PCP server supports mapping, but feature is disabled)
3 - Network Failure
(e.g., NAT device has not obtained a DHCP lease)
4 - Out of resources
(e.g., NAT device cannot create more mappings at this time)
5 - Unsupported opcode
]]></artwork>
</figure>
<t>Additional result codes are defined following the procedure in
<xref target="iana_result_codes"></xref>.</t>
</section>
</section>
<section title="OpCodes">
<t>This document defines four OpCodes which share a similar packet
layout for requests and responses. For these OpCodes, the request and
response packet formats take the same space and layout. New OpCodes MAY
choose to follow the same format. The OpCodes defined in this document
are:</t>
<figure anchor="opcodes" title="OpCodes">
<preamble></preamble>
<artwork align="center"><![CDATA[
PIN44 = 0 = IPv4 address to IPv4 address (NAT44 or IPv4 firewall)
PIN46 = 1 = IPv4 address to IPv6 address (NAT46)
PIN64 = 2 = IPv6 address to IPv4 address (NAT64)
PIN66 = 3 = IPv6 address to IPv6 address (NAT66 or IPv6 firewall)
]]></artwork>
</figure>
<section title="PIN OpCodes">
<t>The four PIN OpCodes (PIN44, PIN46, PIN64, PIN66) share a similar
packet layout for both requests and responses. Because of this
similarity, they are shown together. For all of the PIN OpCodes, if
the internal-ip-address and internal-port matches (requested)
external-ip-address and (requested) external-port, the (request or)
response pertains to a firewall; otherwise it pertains to a NAT.</t>
<t>The following diagram shows the request packet format for PIN44,
PIN46, PIN64, and PIN66:</t>
<figure align="center" anchor="pin_request"
title="PIN OpCode Request Packet Format">
<preamble></preamble>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Reserved (always 160 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pinhole Internal IP address (32 or 128, depending on OpCode) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Requested external IP address (32 or 128, depending on OpCode):
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | requested external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Reserved:">MUST be 0 on transmission and MUST be
ignored on reception.</t>
<t hangText="Pinhole Internal IP Address:">Internal IP address of
the pinhole. This can be IPv4 or IPv6, depending on the
OpCode.</t>
<t hangText="Requested External IP Address:">Requested external IP
address. This is useful for refreshing a mapping, especially after
the PCP server loses state. If the PCP server can fulfill the
request, it will do so. If the PCP client doesn't know the
external address, or doesn't have a preference, it MAY place any
value into this field including 0. If the Pinhole Internal IP
Address equals the Requested External IP Address, it indicates the
PCP client wants firewall (versus NAT) behavior.</t>
<t hangText="Requested lifetime:">Requested lifetime of this
pinhole, in seconds.</t>
<t hangText="internal port:">Internal port for the pinhole.</t>
<t hangText="requested external port:">requested external
port.</t>
<t hangText="internal port:">Internal port for the pinhole, copied
from request.</t>
<t hangText="Assigned external port:">requested external port for
the mapping. This is useful for refreshing a mapping, especially
after the PCP server loses state. If the PCP server can fulfill
the request, it will do so. If the PCP client doesn't know the
external port, or doesn't have a preference, it SHOULD use 0.</t>
</list></t>
<t><list style="empty">
<t>[Ed. Note: for firewall, we need to add fields indicating the
remote peer address (address family will match the address family
of the requsted IP address). Addition permission for multiple
remote peers is possible (by sending multiple PCP requests, one
for each remote peer's IP address). Deleting a single permission
would require a new OpCode. Should perhaps firewall use different
OpCodes than NAT??]</t>
</list>The following diagram shows the response packet format for
PIN44, PIN46, PIN64, and PIN66:</t>
<figure align="center" anchor="pin_response"
title="PIN OpCode Response Packet Format">
<preamble></preamble>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP Request Address Family | PCP Request Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Request IP Address (always 128 bits) |
| (first 32 bits are XOR'd) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pinhole Internal IP address (32 or 128, depending on OpCode) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Assigned external IP address (32 or 128, depending on OpCode) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | assigned external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="PCP Request Address Family:">The IP address family of
the PCP request, as received in the IP header by the PCP server.
Will usually be 1 (IPv4) or 2 (IPv6). This is used by the PCP
client to determine if there is a NAT between the PCP client and
PCP server (see <xref target="nested_nat"></xref>).</t>
<t hangText="PCP Request Port:">The port of the PCP request, as
received in the UDP header by the PCP server. This is used by the
PCP client to determine if there is a NAT between the PCP client
and PCP server (see <xref target="nested_nat"></xref>).</t>
<t hangText="PCP Request IP Address:">The IPv4 or IPv6 address of
the PCP request, as received in the IP header by the PCP server.
This is used by the PCP client to determine if there is a NAT
between the PCP client and PCP server (see <xref
target="nested_nat"></xref>). As some NATs rewrite IPv4 packets
containing the NAT's public IPv4 address in the UDP payload, the
first 32 bits of the address are XOR'd with 0xFFFFFFFF if it
contains an IPv4 address; IPv6 addresses are not XOR'd.</t>
<t hangText="Pinhole Internal IP address">Copied from request.
IPv4 or IPv6 address is indicated by the OpCode.</t>
<t hangText="Assigned external IP address">Assigned external IPv4
or IPv6 address for the pinhole. IPv4 or IPv6 address is indicated
by the OpCode</t>
<t hangText="Assigned Lifetime">Lifetime for this mapping, in
seconds</t>
<t hangText="internal port">Internal port for the pinhole, copied
from request.</t>
<t hangText="Assigned external port">requested external port for
the mapping. IPv4 or IPv6 address is indicated by the OpCode</t>
</list></t>
</section>
</section>
<section title="PCP Mapping State Maintenance">
<t>If an event occurs that causes the PCP server and NAT to lose state
(such as a crash or power outage), the pinholes created by PCP are lost.
Such loss of state is rare in a service provider environment (due to
redundant power, disk drives for storage, etc.). But such loss of state
is more common in a residential NAT device which does not write
information to its non-volatile memory.</t>
<t>The Epoch indicates if the PCP server has lost its state. If this
occurs, the PCP client can attempt to recreate the pinholes following
the procedures described in this section.</t>
<section anchor="epoch" title="Epoch">
<t>Every packet sent by the PCP Server includes a "Seconds since start
of epoch" field (SSSOE). The PCP Server MUST set its Epoch time to
zero when it is ready to accept new connections. If the PCP Server
resets or loses the state of its port mapping table, due to reboot,
power failure, or any other reason, it MUST reset its epoch time and
begin counting SSSOE from 0 again. Whenever a client receives any
packet from the PCP Server, either gratuitously or in response to a
client request, the client computes its own conservative estimate of
the expected SSSOE value by taking the SSSOE 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 SSSOE in the newly
received packet is less than the client's conservative estimate by
more than one second, then the client concludes that the NAT gateway
has undergone a reboot or other loss of port mapping state, and the
client MUST immediately renew all its active port mapping leases as
described in <xref target="reboot"></xref>.</t>
</section>
<section anchor="reboot" title="Recreating Pinholes">
<t>The NAT gateway MAY store mappings in persistent storage so when it
is powered off or rebooted, it remembers the port mapping state of the
network.</t>
<t>However, maintaining this state is not essential for correct
operation. When the NAT gateway powers on or clears its port mapping
state as the result of a configuration change, it MUST reset the epoch
time.</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
freshly-rebooted NAT gateway it appears as a new mapping request.</t>
<t>This self-healing property of the protocol is very important.</t>
<t>The remarkable reliability of the Internet as a whole derives in
large part from the fact that important state is held in the
endpoints, not in the network itself <xref
target="Saltzer84"></xref>]. Power-cycling an Ethernet switch results
only in a brief interruption in the flow of packets; established TCP
connections through that switch are not broken, merely delayed for a
few seconds. Indeed, an old Ethernet switch can even be replaced with
a new one, and as long as the cables are transferred over reasonably
quickly, after the upgrade all the TCP connections that were
previously going though the old switch will be unbroken and now going
through the new one. The same is true of IP routers, wireless base
stations, etc. The one exception is NAT gateways. Because the port
mapping state is required for the NAT gateway to know where to forward
inbound packets, loss of that state breaks connectivity through the
NAT gateway. By allowing clients to detect when this loss of NAT
gateway state has occurred, and recreate it on demand, we turn hard
state in the network into soft state, and allow it to be recovered
automatically when needed.</t>
<t>Without this automatic recreation of soft state in the NAT gateway,
reliable long-term networking would not be achieved. As mentioned
above, the reliability of the Internet does not come from trying to
build a perfect network in which errors never happen, but from
accepting that in any sufficiently large system there will always be
some component somewhere that's failing, and designing mechanisms that
can handle those failures and recover. To illustrate this point with
an example, consider the following scenario: Imagine a network
security camera that has a web interface and accepts incoming
connections from web browser clients. Imagine this network security
camera uses NAT-PMP or a similar protocol to set up an inbound port
mapping in the NAT gateway so that it can receive incoming connections
from clients the other side of the NAT gateway. Now, this camera may
well operate for weeks, months, or even years. During that time it's
possible that the NAT gateway could experience a power failure or be
rebooted. The user could upgrade the NAT gateway's firmware, or even
replace the entire NAT gateway device with a newer model. The general
point is that if the camera operates for a long enough period of time,
some kind of disruption to the NAT gateway becomes inevitable. The
question is not whether the NAT gateway will lose its port mappings,
but when, and how often. If the network camera and devices like it on
the network can detect when the NAT gateway has lost its port
mappings, and recreate them automatically, then these disruptions are
self-correcting and largely invisible to the end user. If, on the
other hand, the disruptions are not self-correcting, and after a NAT
gateway reboot the user has to manually reset or reboot all the other
devices on the network too, then these disruptions are *very* visible
to the end user. This aspect of the design is what makes the
difference between a protocol that keeps on working indefinitely over
a time scale of months or years, and a protocol that works in brief
testing, but in the real world is continually failing and requiring
manual intervention to get it going again.</t>
<t>When a client renews its port mappings as the result of receiving a
packet where the "Seconds since start of epoch" field (SSSoE)
indicates that a reboot or similar loss of state has occurred, the
client MUST first delay by a random amount of time selected with
uniform random distribution in the range 0 to 5 seconds, and then send
its first port mapping request. After that request is acknowledged by
the gateway, the client may then send its second request, and so on,
as rapidly as the gateway allows. The requests SHOULD be issued
serially, one at a time; the client SHOULD NOT issue multiple requests
simultaneously in parallel.</t>
<t><list style="empty">
<t>[Ed. Note: the paragraph above is copied from NAT-PMP, and
seems to be advice specific to receiving asynchronous notification
that the Epoch was reset. Asynchronous notification needs the
delay described (in fact, it probably needs greater delay than 0-5
seconds if on a larger network) and also needs to discourage
sending multiple PCP requests serially. However, PCP does not have
asynchronous notification (yet), and has different
needs/requirements for pacing. In short: the above paragraph needs
some discussion.]</t>
</list></t>
<t>The discussion in this section focusses on recreating inbound port
mappings after loss of NAT gateway 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 NAT-PMP. After
initiating an outbound TCP connection (which will cause the NAT
gateway to establish an implicit port mapping) the client should send
the NAT gateway a port mapping request for the source port of its TCP
connection, which will cause the NAT gateway to send a response giving
the external port it allocated for that mapping. The client can then
store this information, and use later to recreate the mapping if it
determines that the NAT gateway has lost its mapping state.</t>
</section>
<section title="Maintaining Pinholes">
<t>A PCP client can refresh a pinhole 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 pinholes, the Epoch value only needs to be retrieved for one
of them to verify the PCP server has not lost port forwarding
state.</t>
</section>
<section anchor="nested_nat" title="Nested NATs">
<t>A PCP Client can detect the presence of a NAT on the path between
the PCP client and PCP server by sending a PCP request to the PCP
server and comparing fields in the PCP response. If the request's IP
address family, IP address, and source port match the information in
the PCP response's payload (PCP Request Address Family, PCP Request
Port, and PCP Request XOR'd IP Address), there is no NAT on the path.
If they differ, there is a NAT on the path.</t>
<t><list style="empty">
<t>Note: this provides a function similar to <xref
target="RFC5389">STUN</xref>. Being integrated within PCP itself
provides the advantage of checking the path to the PCP server,
which may be a different path than to the STUN server.</t>
</list></t>
<t>After determining a NAT is on the path, the PCP application can
take appropriate action based on this information. This action would
require using another mechanism to open pinholes in the intervening
NATs (e.g., UPnP IGD, NAT-PMP) or returning an error to the user.</t>
</section>
</section>
<section anchor="sec_processing"
title="Processing Pinhole Requests and Responses">
<t>PCP messages MUST be sent over UDP, and the PCP Server MUST listen
for PCP requests on the PCP port number (<xref
target="iana_port"></xref>). Every PCP request generates a response, so
PCP does not need to run over a reliable transport protocol.</t>
<section anchor="sec_generating_request"
title="Generating and Sending a Request">
<t>To create a pinhole, the PCP client generates a PCP request for the
appropriate address family of the internal host and the desired public
mapping. The PCP request contains a PCP common header, PCP OpCode and
payload, and optional Information Elements.</t>
<t>The PCP client determines its PCP server using the procedure
described in <xref target="discovery"></xref>. It initializes its
retransmission timer, RETRY_TIMER, to the round trip time between the
PCP client and PCP server. If this value is unknown, 250ms is
RECOMMENDED. The PCP Client sends its PCP message to the PCP server
and waits RETRY_TIMER for a response. If no response is received, it
doubles the value of RETRY_TIMER, sends another (identical) PCP
message and waits RETRY_TIMER*2. This procedure is repeated three
times, doubling the value of RETRY_TIMER each time. If no response is
received after 4 attempts, the PCP client tries with the next IP
address in its list of PCP servers. If it has exhausted its list, it
SHOULD abort the procedure. If, when sending PCP requests the PCP
Client receives an ICMP error (e.g., port unreachable, network
unreachable) it SHOULD immediately abort the procedure. Once a PCP
client has successfully communicated with a PCP server, it continues
communicating with that PCP server until that PCP server becomes
non-responsive, which causes the PCP client to attempt to re-iterate
the procedure starting with the first PCP server on its list.</t>
</section>
<section title="Processing a Request and Generating the Response">
<t>Upon receiving a PCP request message, the PCP Server parses and
validates it. A valid request contains a valid PCP common header, one
valid PCP Opcode, and optional Informational Elements (which the
server might or might not comprehend). If an error is encountered
during processing, an error response is generated and sent back to the
PCP client.</t>
<t>After successful parsing of the message, the PCP server validates
that the internal IP address in the PCP request belongs to that
subscriber. This validation depends on the deployment scenario; see
<xref target="sec_subscriber_identification"></xref>. If the internal
IP address in the PCP request does not belong to the subscriber, an
error response MUST be generated with error-code=2.</t>
<t>If the requested lifetime is 0, it indicates a Delete request. This
means the pinhole described by the internal IP address should be
deleted, and requested external port field is ignored by the server
(that is, it isn't validated). If the deletion request was successful,
apositive response generated containing external port of 0 and
lifetime of 0. If the deletion request was unsusccessful a non-zero
result code is returned and the lifetime is undefined. If the client
attempts to delete a port mapping which was manually assigned by some
kind of configuration tool, the PCP server MUST respond with a 'Not
Authorized' error (result code 2).<list style="empty">
<t>[Ed. Note: Should we similarly return an error if attempting to
delete mappings that were created dynamically (e.g., TCP
SYN)?]</t>
</list></t>
<t>When a mapping is destroyed as a result of its lifetime expiring or
for any other reason, if the NAT gateway's internal state indicates
that there are still active TCP connections traversing that now-
defunct mapping, then the NAT gateway SHOULD send appropriately-
constructed TCP RST (reset) packets both to the local client and to
the remote peer on the Internet to terminate that TCP connection.</t>
<t>A client can request the explicit deletion of all its UDP or TCP
mappings by sending the same deletion request to the NAT gateway with
external port, internal port, and lifetime set to 0. A client MAY
choose to do this when it first acquires a new IP address in order to
protect itself from port mappings that were performed by a previous
owner of the IP address. After receiving such a deletion request, the
PCP server and NAT MUST delete all the port mappings. The PCP server
responds to such a deletion request with a response as described
above, with the internal port set to zero. If the PCP server is unable
to delete a port mapping, for example, because the mapping was
manually configured by a configuration tooll, the gateway MUST still
delete as many port mappings as possible, but respond with a non-zero
result code. The exact result code to return depends on the cause of
the failure. If the gateway is able to successfully delete all port
mappings as requested, it MUST respond with a result code of 0.</t>
<t>The PCP-controlled device MAY reduce the lifetime that was
requested by the PCP Client. The PCP-controlled device SHOULD NOT
offer a lease lifetime greater than that requested by the PCP Client.
The RECOMMENDED lifetime assigned by the server is 7200 seconds (i.e.,
two hours).</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. Nevertheless, a
configurable feature MAY be supported by the PCP-controlled device,
which MAY reserve (but not forward) the companion port so the same PCP
Client can request it in the future.</t>
<t>If all of the proceeding operations were successful (did not
generate an error response), then the requested pinholes are created
as described in the request and a positive response is built. This
positive response contains the same OpCode as the request plus
128.</t>
</section>
<section title="Processing a Response">
<t>The PCP client receives the response and checks that the response
matches one of its outstanding requests. If it is an error response,
the PCP client knows that none of the requested pinholes were created,
and can attempt to resolve the problem based on the error code and
error subcode.</t>
<t>If it is an positive response, the PCP client knows the request was
entirely successful and 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 mechanism.</t>
</section>
</section>
<section title="PCP Client Operation">
<t>This section details operation specific to a PCP client.</t>
<section anchor="refresh" title="Pinhole Lifetime Extension">
<t>An existing mapping can have its lifetime extended by the PCP
client. To do this, the PCP client sends a new PCP map request to the
server indicating the internal IP address and port(s).</t>
<t>The PCP Client SHOULD renew the mapping before its expiry time,
otherwise it will be removed by the PCP Server (see <xref
target="sec_server_delete"></xref>). In order to prevent excessive PCP
chatter, it is RECOMMENDED to renew only 60 seconds before expiration
time (to account for retransmissions that might be necessary due to
packet loss, clock synchronization between PCP client and PCP server,
and so on).</t>
</section>
<section anchor="delete" title="Pinhole Deletion">
<t>A PCP Client MAY delete a pinhole prior to its natural expiration
by sending a PCP Map Request with a lifetime of 0. The PCP server
responds by returning a PCP Map Response with a lifetime of 0.</t>
<t>To delete all pinholes for all ports, the "W" (wildcard) bit is
set, and no internal port/external port is included in the PCP
request.</t>
<t>To delete all pinholes for all hosts associated with this
subscriber, an all-zero internal IP address is used.</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
dual-stack or be configured with several IP addresses. These IP
addresses may have distinct reachability scopes (e.g., if IPv6 they
might have global reachability scope as for GUA (Global Unicast
Address) or limited scope such as ULA (Unique Local Address, <xref
target="RFC4193"></xref>)).</t>
<t>IPv6 addresses with global reachability scope SHOULD be used as
internal IP address when instructing a PCP mapping in a PCP-controlled
device. IPv6 addresses with limited scope (e.g., ULA), SHOULD NOT be
indicated as internal IP address in a PCP message.</t>
<t>As mentioned in <xref target="mono_homed"></xref>, only mono-homed
CP routers are in scope. Therefore, there is no viable scenario where
a host located behind a CP router is assigned with two GUA addresses
belonging to the same global IPv6 prefix.</t>
</section>
<section title="Renumbering">
<t>The customer premise router might obtain a new IPv6 prefix, either
due to a reboot, power outage, DHCPv6 lease expiry, or other action.
If this occurs, the ports reserved using PCP might be delivered to
another customer who now has that (old) address. This same problem can
occur if an IP address is re-assigned today, without PCP. The solution
is the same as today: ISPs should not re-assign IP addresses.</t>
</section>
</section>
<section title="PCP Server Operation">
<t>This section details operation specific to a PCP server.</t>
<section anchor="relationship"
title="Relationship of PCP Server and its NAT">
<t>The PCP server receives PCP requests. The PCP server might be
integrated within the NAT 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="device with Embedded PCP Server">
<artwork align="center"><![CDATA[ +-----------------+
+------------+ | NAT or firewall |
| PCP Client |-<network>-+ +---<Internet>
+------------+ | with embedded |
| PCP server |
+-----------------+]]></artwork>
</figure>
<t>However, it is useful to also model a separation of the PCP server
from the NAT, as shown below (<xref
target="diagram_pcp_server_separate"></xref>). The PCP server would
communicate with the NAT using a protocol beyond the scope of this
document, such as a proprietary protocol or any suitable standard
protocol for NAT control).</t>
<figure anchor="diagram_pcp_server_separate"
title="NAT with Separate PCP Server">
<artwork align="center"><![CDATA[ +-----------------+
+--+ NAT or firewall +---<Internet>
/ +-----------------+
+------------+ / ^
| PCP Client +-<network> | suitable NAT control protocol
+------------+ \ v
\ +------------+
+--+ PCP Server |
+------------+
]]></artwork>
</figure>
</section>
<section title="Pinhole Lifetime">
<t>Once a PCP server has responded positively to a pinhole request for
a certain lifetime, the port forwarding is active for the duration of
the lifetime unless deleted by the PCP client. Also see XXX.</t>
<t>It is NOT RECOMMENDED that the server allow long lifetimes
(exceeding 24 hours), because they will consume ports even if the
internal host is no longer interested in receiving the traffic or no
longer connected to the network.</t>
<t>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.</t>
</section>
<section anchor="sec_server_delete" title="Pinhole deletion">
<t>A pinhole MUST be deleted by the PCP Server upon the expiry of its
lifetime, or upon request from the PCP client.</t>
<t>In order to prevent another subscriber from receiving unwanted
traffic, the PCP server SHOULD NOT assign that same external port to
another host for 120 seconds (MSL, <xref
target="RFC0793"></xref>).</t>
<t><list style="empty">
<t>[Ed. Note: it should (MUST?) allow the same host to re-acquire
the same port, though.]</t>
</list></t>
</section>
<section anchor="sec_subscriber_identification"
title="Subscriber Identification">
<t>Subscribers identification is required for several reasons such as
the following:<list style="symbols">
<t>Allow access to the network resources;</t>
<t>Configure service profiles such as a bandwidth and/or port
usage quotas for fairness service usage among all subscribers;</t>
<t>Blacklist a subscriber because of abuse or non-payment of
service fee, etc.</t>
<t>Legal requirements such as legal intercept or legal
storage.</t>
</list>A PCP Client can create mappings in a PCP-controlled device
on behalf of a third party device (e.g., a computer can create PCP
mappings on behalf of a webcam). However, it is not desirable for a
PCP client to open pinholes for a different subscriber. The mechanism
to identify "same subscriber" depends on the sort of NAT on this
network:<list style="symbols">
<t>If the PCP-controlled device is a NAT64: the internal IP
address indicated in the PCP message and the source IPv6 address
of received PCP request MUST belong to the same IPv6 prefix. The
length of the IPv6 prefix is the same as the length assigned to
each subscriber on that particular network.</t>
<t>If the PCP-controlled device is a DS-Lite AFTR: DS-Lite
(Section 11 of <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>) already
requires the tunnel transport source address be validated, and
that same address is used by PCP to assign the tunnel-ID to the
requested mapping (see <xref target="dslite_encap"></xref> and
<xref target="dslite_plain"></xref>). Thus, PCP acquires the same
security properties as DS-Lite. If address validation is
implemented correctly, the PCP Client can not instruct mappings on
behalf of devices of another subscriber.</t>
<t>If CGN with a routed network, each subscriber has one IPv4
address and all PCP requests MUST be sent from only that IP
address and MUST only open pinholes towards its own IP
address.</t>
</list></t>
<t>PCP-controlled devices can be a DS-Lite AFTR or an IPv4-IPv6
interconnection node such as NAT46 or NAT64. These nodes are deployed
by Service Providers to deliver global connectivity service to their
customers. Appropriate functions to restrict the use of these
resources (e.g., LSN facility) to only subscribed users should be
supported by these devices. Access control can be implicit or
explicit: <list style="symbols">
<t>It is said to be explicit if an authorisation procedure is
required for a user to be granted access to such resources. For
such variant of PCP-controlled device, a subscriber can be
identified by an IPv6 address, an IPv4 address, a MAC address, or
any other information.</t>
<t>For other scenarios, such as plain IPv4-in-IPv6 encapsulation
for a DS-Lite architecture, the access to the service is based on
the source IPv6 prefix. No per-user polices is pre-configured in
the PCP-controlled device.</t>
</list></t>
<t></t>
</section>
<section title="External IP Address">
<t>If there are active mappings for a particular PCP Client -- created
via dynamic assignment or created by PCP -- subsequent mapping
requests from that same PCP Client MUST use the same external IP
address. This is necessary because some protocols require using the
same IP address for several ports, and follows REQ-1 of <xref
target="I-D.ietf-behave-lsn-requirements"></xref>. Additionally, all
PCP-mapped requests MUST also use the same external IP address. Once a
client has no active dynamic mappings and no PCP pinholes, a
subsequent dynamic mapping or PCP request MAY be assigned to a
different external IP address.</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 premise router) and the AFTR element
(which is the device that both terminates the IPv6-over-IPv4 tunnel
and also implements the large-scale 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.</t>
<section title="Overview">
<t>Various PCP deployment scenarios can be considered to control the
PCP server embedded in the AFTR element:<list style="numbers">
<t>UPnP IGD and NAT-PMP are used in the LAN: an interworking
function is required to be embedded in the B4 element to ensure
interworking between the protocol used in the LAN and PCP. UPnP
IGD-PCP Interworking Function is described in <xref
target="upnp-interworking"></xref>.</t>
<t>Hosts behind the B4 element include a PCP Client, and
communicate directly with the PCP server. No interworking
function is required to be embedded in the B4 element.</t>
<t>The B4 element include a PCP Client which is invoked by an
HTTP-based configuration (as is common today). The
internal-IP-address in the PCP payload would be the internal
host used in the port forwarding configuration.</t>
</list></t>
<t>Two modes are identified to forward PCP packets to a PCP Server
controlling the provisioned AFTR as described in the following
sub-sections.</t>
<t><list style="empty">
<t>[Ed. Note: We need to decide on Encapsulation Mode or Plain
IPv6 Mode.]</t>
</list></t>
</section>
<section anchor="dslite_encap" title="Encapsulation Mode">
<t>In this mode, B4 element does no processing at all of the PCP
messages, and forwards them as any other UDP traffic. With DS-Lite,
this means that IPv4 PCP messages issued by internal PCP Clients are
encapsulated into the IPv6 tunnel sent to the AFTR as for any other
IPv4 packets. The AFTR decapsulates the IPv4 packets and processes
the PCP requests (because the destination IPv4 address points to the
PCP Server embedded in the AFTR).</t>
</section>
<section anchor="dslite_plain" title="Plain IPv6 Mode">
<t>Another alternative for deployment of PCP in a DS-Lite context is
to rely on a PCP Proxy in the B4 element. Protocol exchanges between
the PCP Proxy and the PCP Server are conveyed using plain IPv6 (no
tunnelling is used). Nevertheless, the IPv6 address used as source
address by the PCP Proxy MUST be the same as the one used by the B4
element.</t>
</section>
</section>
<section title="NAT64">
<t>Hosts behind a NAT64 device can make use of PCP in order to perform
port reservation (to get a publicly routable IPv4 port).</t>
<t>If the IANA-assigned IP address is used for the discovery of the
PCP Server, that IPv4 address can be placed into the IPv6 destination
address following that particular network's well-known prefix or
network-specific prefix, per <xref
target="RFC6052"></xref>.</t>
</section>
<section title="NAT44 and NAT444">
<t>Subscribers are given only one IPv4 address. To accomodate multiple
hosts within the home, subscribers operate a NAPT device. When this
occurs in conjunction with an upstream NAT44, this is nicknamed
"NAT444".</t>
<t>In either environment (with or without a NAPT in the home), the
service provider and PCP server see only one IPv4 address from each
subscriber.</t>
<t>PCP includes a function to detect a NAT between the PCP client and
PCP server, described in <xref target="nested_nat"></xref>.</t>
</section>
<section title="IPv6 Firewall">
<t>[Ed. Note: PCP packet format needs changes to support IPv6
firewall, or we need additional OpCodes for IPv6 firewall.]</t>
</section>
</section>
<section title="Adjacent Port Procedure">
<t>RTP and RTCP have historically run on adjacent ports, and some
existing equipment still expects them to be on adjacent ports. To
accomodate that, a procedure can be used rather than adding complexity
to the protocol or to the server implementation.</t>
<t><list style="empty">
<t>[Ed. Note: Are there any other referencable 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. This request can have a short lifetime (e.g., 5 seconds) to avoid
the need to delete the pinhole. It receives the PCP response indicating
it now has external port N. The PCP client then attempts to obtain a
port on either side of this external port. It sends two PCP requests,
using the same internal port number in both requests, for external port
N-1 and for external port N+1. The adjacent external ports N-1 and N+1
are either (a) not available, (b) only one is available, or (c) both are
available. If (a), an unrelated port will be assigned and the procedure
can be repeated. If (b) the procedure was successful. Case (c) is also
successful, because the PCP client cannot distinguish it from case (b),
because the PCP server maps an specific internal IP address and internal
port to a single external IP address and port.</t>
<t><list style="empty">
<t>[Ed. Note: Add message flow diagram showing adjacent port
procedure]</t>
</list></t>
</section>
<section anchor="upnp-interworking" title="Interworking with UPnP IGD">
<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[
+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +---------+ +--------+
+---| IGD-PCP | | PCP |
| IWF +-------+ Server |--<Internet>
+---| | | |
+-------------+ | +---------+ +--------+
| Local Host |-----+
+-------------+ | |
| |
LAN Side | WAN side |
<======UPnP IGD=============>|<========PCP=====>|
]]></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. Requesting a
specific port is incompatible with both (1) a large-scale NAT and with
(2) successful applications. Regarding (1), other subscribers are
likely to also be running the same application, all demanding (or
desiring) the same port number. Regarding (2), a popular application
will exist on multiple devices within the home. Thus, PCP is not
designed to optimize for this behavior of requesting a particular port
as it cannot work well in address sharing environments; but PCP will
work with this behavior using the suggested procedure below.</t>
<t>Due to this incompatibility with large-scale address sharing and
popular applications, future hosts and applications will either
support UPnP IGD 2.0 (which has improved behavior, see <xref
target="upnp-2-interworking"></xref>) or will support PCP.</t>
<t>To interwork from UPnP IGD to PCP, our recommendation is that every
UPnP request be forwarded to the PCP server -- this works no matter if
the UPnP IGD control point is randomizing or incrementing each port
number when its requests fail. 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. In either case, the
described procedure will work. The UPnP IGD/PCP interworking function
would request very short leases (e.g., 5 seconds) in order to avoid
the chatter of a Delete message (lifetime=0). Once a port can be
allocated, its lifetime is extended. When interworking with UPnP IGD,
the in-home CPE limits itself to sending one PCP message a second,
which ensures there are only 5 outstanding PCP reservations at a time;
this avoids consuming all of that subscriber's NAT mappings while
trying to find an available port via the UPnP IGD->PCP interworking
function).</t>
<t><list style="empty">
<t>Note: for this to work successfully, the PCP server (large NAT)
needs to honor the requested-external-port field in the PCP
request. Which is the purpose of that field, of course.</t>
</list></t>
<figure align="center" anchor="message-flow"
title="Message Flow: Interworking from UPnP IGD 1.0 AddPortMapping action to PCP">
<preamble>Message flow would be similar to this:</preamble>
<artwork><![CDATA[
UPnP CP in-home CPE PCP server
| | |
|-UPnP:give me port 80--->| |
| |-PCP:request port 80------>|
| | with lifetime=5 seconds |
| |<-PCP:here is port 51389---|
|<-UPnP: unavailable------| |
| | |
| (allow port 51389 to naturally expire, |
| or actively Delete it) |
| | |
|-UPnP:give me port 3213->| |
| |-PCP:request port 3213---->|
| | with lifetime=5 seconds |
| |<-PCP:here is port 23831---|
|<-UPnP: unavailable------| |
| | |
| (allow port 23831 to naturally expire, |
| or actively Delete it) |
| | |
... ... ... ...
| | |
|-UPnP:give me port 8921->| |
| |-PCP:request port 8921---->|
| | with lifetime=5 seconds |
| |<-PCP:here is port 8921----|
| | |
| |-PCP:life=1 hour,port=8921>|
| |<-PCP:ok-------------------|
| | |
|<-UPnP: ok, port 8921----| |
| | |
]]></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 the IGD 2's new AddAnyPortMapping
message, 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>
</section>
<section title="Lifetime Maintenance">
<t>UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP
interworking function is responsible for extending the lifetime of
mappings that are still interesting to the UPnP IGD device.</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. The UPnP IGD/PCP
interworking function is responsible for renewing the PCP lifetime
as necessary. As long as client renews its DHCP lease, the PCP
lifetime should also be extended. For clients not using DHCP,
other mechanisms to check on the client host's liveliness can also
be useful (e.g., ping, ARP, or WiFi association) can be used to
discern liveliness of the UPnP IGD control point. However, it is
NOT RECOMMENDED to attempt to connect to the TCP or UDP port
opened on the control point to determine if the host still wants
to receive packets; the server could be temporarily down when
tested, causing a false negative.</t>
</list></t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>[Ed. Note: to be completed.]</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to perform the following actions:</t>
<section title="PCP Server IP address">
<t>IANA shall assign an IPv4 and an IPv6 address for PCP
discovery.</t>
<t>[Ed. Note: perhaps we can use the AFTR element's IPv4 address? But
still need an IPv6 address assigned for PIN64 and PIN66.]</t>
</section>
<section anchor="iana_port" title="Port Number">
<t>Need a UDP port allocated.</t>
</section>
<section anchor="iana_opcodes" title="OpCodes">
<t>IANA shall create a new protocol registry for PCP OpCodes,
initially populared with the values in <xref
target="opcodes"></xref>.</t>
<t>New OpCodes can be created via <xref target="RFC5226">Standards
Action</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 error codes from <xref
target="figure_result_codes"></xref>.</t>
<t>New Result Codes can be created via <xref
target="RFC5226">Specification Required</xref>.</t>
</section>
<section anchor="iana_ie" title="Information Elements">
<t>IANA shall create a new registry for PCP Information Elements,
numbered 0-255 with associated mnemonic.</t>
<t>New information elements in the range 0-127 can be created via
<xref target="RFC5226">Standards Action</xref>, new information
elements in the range 128-192 can be created with <xref
target="RFC5226">Expert Review</xref>, and the range 193-255 is for
<xref target="RFC5226"> Private Use</xref>.</t>
</section>
</section>
<section title="Authors">
<figure>
<preamble>The following individuals contributed substantial text to
this document and are listed in alphabetical order:</preamble>
<artwork><![CDATA[ Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange-ftgroup.com
Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, California 95014 USA
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Francis Dupont
ISC
Email: Francis.Dupont@fdupont.fr
Reinaldo Penno
Juniper Networks
Email: rpenno@juniper.net
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Acknowledgments">
<t>Thanks to Alain Durand and Christian Jacquenet for their comments and
review.s</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.6052"?>
<?rfc include='reference.I-D.ietf-softwire-dual-stack-lite'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate-stateful'?>
<?rfc include='reference.RFC.4193'?>
<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.2608'?>
<?rfc include='reference.RFC.5389'?>
<?rfc include='reference.RFC.0793'?>
<?rfc include='reference.I-D.miles-behave-l2nat'?>
<?rfc include='reference.I-D.ietf-v6ops-cpe-simple-security'?>
<?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
<?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/igd2">
<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="Saltzer84"
target="http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf">
<front>
<title>End-to-end arguments in system design</title>
<author initials="J.H." surname="Saltzer">
<organization></organization>
</author>
<author initials="D.P." surname="Reed">
<organization></organization>
</author>
<author initials="D.D." surname="Clark">
<organization></organization>
</author>
<date year="1984" />
</front>
</reference>
</references>
<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.]]</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. 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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:30:32 |