One document matched: draft-ietf-pcp-base-01.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-01" 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>Port 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 small-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 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.</t>
<!--
> 1. define new IE, EVEN_PLUS_ONE, which has no payload.
>
> 2. PCP request is sent, with that IE.
>
> 3. PCP server attempts to allocate an even port number, and
> PCP server reserves the adjacent port number (sticks it
> on the TIME_WAIT queue for 5 seconds, and it is only allocatable
> to the same IP address as got the even port number).
>
> Maybe we have PCP server return an IE EVEN_PLUS_ONE if it
> was able to allocate the adjacent port. That seems helpful
> for the next steps.
>
> 4. VoIP endpoint can send its SIP/SDP message now. Total
> delay: one round trip to PCP server.
>
> 5. A second PCP request is sent, without the IE, requesting
> port+1.
>
> Med: I still we can avoid some extra exchanges with the server (for
> instance in your bullet 5, you will need to do it for all the media you
> are negotiating including audio, video, etc.).
If the endpoint needs to do audio and video, it will send two PCP
requests, at the same time, in step 2. This will result in two
PCP responses in step 4.
As soon as the audio+video session is established, there will be
at least 50 packets per second of video and ~20-50 packets per
second of video.
Here are the scenarios:
1. internal host is IPv4 only
2. internal host is IPv6 only
3. internal host is dual stack
For (1), that host can only do PIN44 (to get a public IPv4 address)
or PIN46 (to get a public IPv6 address).
For (2), that host can only do PIN66 (to get a public IPv6 address;
mostly this is for IPv6 firewall. Yes, this needs more fleshing
out. Yes, there is an "Ed. Note" to that effect in the document.
Yes, I am aware of that) or PIN64 (to get a public IPv4 address).
For (3), that host can use any of the four opcodes (PIN44, PIN46,
PIN64, PIN66). If it is being reasonable, it won't do PIN46
or PIN64, because it could just keep the IP address family the
same instead because it is dual stack. But we cannot detect
a dual-stack node and there isn't a reason to block it. So,
yes, I suppose a dual-stack host could attempt all four of
the OpCodes. But it would more reasonably do PIN44 to get
a public IPv4 presence and PIN66 to get a public IPv6 presence.
Besides, on a network with a dual-stack host, that network
is unlikely (not not prohibited) to operate a NAT64, and
also unlikely (but not prohibited) to operate a NAT46. This
seems to warrant some text around
In some scenarios communications may fail if intermediary (non
PCP-controlled) firewalls are not appropriately configured to accept
incoming traffic. Detecting the presence of firewall(s) in the path
and configuring it is out of scope of this document
Add discussion around if, to optimize keepalives, a host
should do PCP first or should do its TCP (or UDP) first.
If PCP is done first, the mapping will be endpoint independent.
If doing TCP (or UDP) first, the mapping could be endpoint
independent or could be endpoint dependent. This is all
tweakable with the PCP option ENDPOINT_DEPENDANT.
Add defintion, for firewall, of ENDPOINT_DEPENDANT. This allows
indicating an IPvM address (which, by necessity, matches the
length of the outside address of the PINxy), and optionally
allows indicating the remote protocol and remote port. Remote
protocol 0 means 'any protocol'. Remote port 0 means 'any
port'. Packets from the public Internet which don't match the
filter SHOULD get an ICMP error.
-->
</section>
<section title="Scope">
<section title="Deployment Scenarios">
<t>PCP can be used in various deployment scenarios, including:<list
style="symbols">
<t><xref
target="I-D.ietf-softwire-dual-stack-lite">DS-Lite</xref>,
including a NAT and including a router behind the B4 element, and;
<list style="empty"><t>[Ed. Note: Do we want 'NAT behind the B4
element' in our scope? This affects PCP server discovery, among other
things. Howeve, users deploy these NATs. Do we want PCP to work
with this, detect this, or quietly fail??]</t></list></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 use a 16-bit port number (e.g., TCP, UDP,
SCTP, DCCP). Transport protocols that do not use a port number (e.g.,
IPsec ESP) 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>
</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. This is important because after a PCP pinhole is created and
an inbound packet (e.g., TCP SYN) arrives at the host the outbound
response (e.g., TCP SYNACK) has to go through the same path so the
proper address rewriting takes place on that outbound response packet.
This restriction exists because otherwise there would need to be one
PCP server for each egress, because the host could not reliably
determine which egress path packets would take.</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 or NAPT, the internal address and
external address are different. In the context of a firewall,
the internal address and external address are different. In both
contexts, if an internal host is listening to connections on a
specific port (that is, operating as a server), the external IP
address and port number need to be port forwarded to the
internal IP address and port number. In the context of a NAPT,
it is possible that both the IP address and port are modfiied.
For example with a NAPT, a webcam might be listening on port 80
on its internal address 192.168.1.1, while its
publicly-accessible external address is 192.0.2.1 and port is
12345. The NAT does 'port forwarding' of one to the other.</t>
<t>In the context of a firewall, the internal address, external
IP address, 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. An interworking function, from UPnP IGD to PCP, or
from PCP to PCP (for nested NATs) is another example of a PCP
client.</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>See also Port Forwarding. A mapping exists only in the
context of a Network Address Translator. A NAT 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 functional element
responsible for interworking another protocol with PCP. For example
interworking between <xref target="IGD">UPnP IGD</xref> with
PCP.</t>
</list></t>
</section>
<section anchor="relationship"
title="Relationship of PCP Server and its NAT">
<t>The PCP server receives PCP requests. The PCP server might be
integrated within the NAT or firewall device (as shown in <xref
target="diagram_pcp_server_embedded"></xref>) which is expected to be a
common deployment.</t>
<figure anchor="diagram_pcp_server_embedded"
title="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> | any suitable control protocol
+------------+ \ v
\ +------------+
+--+ PCP Server |
+------------+
]]></artwork>
</figure>
</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. 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 specific OpCodes defined in
this document is described in <xref target="pin_opcodes"></xref>, and
behavior of new OpCodes are described in their own documents following a
similar format as in <xref target="pin_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 |reserve|R| OpCode | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields are described below:<list style="hanging">
<t hangText="Ver:">Version is 0</t>
<t hangText="reserve:">4 reserved bits, MUST be sent as 0 and MUST
be ignored when received.</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="opcodes"></xref>. More can be defined per rules described
in <xref target="iana"></xref>.</t>
<t hangText="Reserved:">16 reserved bits, 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|R| Opcode | Reserved | 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="R:">Indicates Request (0) or Response (1). All
Responses MUST use 1.</t>
<t hangText="OpCode+128:">The OpCode value from the request.</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="Options">
<t>A PCP OpCode can be extended with an Option. Options can be used in
requests and responses. It is anticipated that Options will include
information which are associated with the normal function of an
OpCode.For example, an Option could indicate DSCP markings to apply to
incoming or outgoing traffic associated with a PCP pinhole, or an Open
could include descriptive text (e.g., "for my webcam").</t>
<t>Options use the following Type-Length-Value format:</t>
<figure align="left" anchor="options-layout" title="Options 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The description of the fields is as follows:<list style="hanging">
<t hangText="Option Code:">Option code, 8 bits. The first bit of
the option code is the "P" bit, described below. Option codes MUST
be registered with IANA following the procedure described in <xref
target="iana"></xref>.</t>
<t hangText="Reserved:">MUST be set to 0 on transmission and MUST
be ignored on reception.</t>
<t hangText="Option-Length:">Indicates in units of 4 octets the
length of the enclosed data. Options with length of 0 are
allowed.</t>
<t hangText="data:">Option data. The option data MUST end on a 32
bit boundary, padded with 0's when necessary.</t>
</list></t>
<t>A given Option MAY be included in a request. An Option
MUST NOT appear in a PCP response unless solicited in the associated
request. If a given Option was included in a request, and understood
and processed by the PCP server, it MUST be included in the response.
The handling of an Option by the PCP Client and Server
MUST be specified in a appropriate document and must include whether
the PCP Option can appear (one or more times) in a request, and
indicate the contents of the Option in the response.</t>
<t>If the "P" bit in the OpCode is set,
<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, it MUST generate
a failure response without including this Option in the
response.</t>
<t>If the PCP server does implement this Option, but
cannot perform the function indicated by this Option, it MUST
generate a failure response and include this Option (and its
arguments) in the response.</t></list></t>
<t>If the "P" bit is clear, the PCP server MAY process or ignore this
Option.</t>
<t>If several Options are to be included in a PCP request or response,
the Options MAY be encoded in any order by the PCP Client. The
response MUST encode them in the same order, but may omit some PCP
Options in the response (e.g., to indicate the PCP server does not
understand that Option, or that Option is not included in responses).
A single Option MAY appear more than once, if permitted by the
defintion of the Option itself. If the Option's definition allows the
Option to appear only once, the PCP server MUST respond to such a PCP
request with an error message [[which error?]]</t>
<t>To enhance interoperability, newly defined Options should avoid
interdependencies with each other.</t>
<t>New Options MUST include the information below:</t>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>number: </t>
<t>is valid for OpCodes: <list of OpCodes></t>
<t>is included in responses: [MUST | MUST NOT]</t>
<t>has length: <rules for length></t>
<t>appear more than once: ["yes" | "no"]</t>
</list></t>
</list></t>
</section>
<section anchor="result_codes" title="Result Codes">
<t>The following response codes may be returned as a result of any
OpCode received by the PCP server. Result codes are 8 bits long and
the most significant bit indicates if the error is transient or
permanent. A transient error is one that might resolve itself, such
that an identical PCP request submitted later would be successful
(e.g., a resource is consumed and might become available later). A
permanent error is one that cannot reasonably be successful if an
identical PCP request is submitted (e.g., unsupported opcode). Future
result codes should follow this same format.</t>
<figure anchor="figure_result_codes" title="PCP Result Codes">
<artwork align="center"><![CDATA[
0 - Success
128 - Unsupported version
129 - Unsupported OpCode
]]></artwork>
</figure>
<t>Other result codes, specific to the OpCodes defined in this
document, are listed in <xref
target="opcode-specific-error-codes"></xref>.</t>
</section>
</section>
<section title="General Operation">
<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 title="General PCP Client Operation">
<t>This section details operation specific to a PCP client, for any
OpCode. Procedures specific to the PIN OpCodes are described in <xref
target="pin_opcodes"></xref>.</t>
<section anchor="sec_generating_request"
title="Generating and Sending a Request">
<t>Prior to sending its first PCP message, the PCP client determines
which servers to use. The PCP client tries the following to get a
list of PCP servers:<list style="numbers">
<t>if a PCP server is is configured (e.g., in a configuration
file), the address(es) of the PCP server(s) are used as the list of PCP server(s), else;</t>
<t>if DHCP indicates the PCP server(s), the address(es) of the
indicated PCP server(s) are used as the list of PCP server(s), else;</t>
<t>if the PCP working group decides an IANA-allocated
address for the PCP server is suitable, it is added to the list of PCP servers, else;</t>
<t>the address of the default router, it is added to the list of PCP servers.</t>
</list><list style="empty">
<t>[Ed. Note: more discussion around these methods is necessary
to reach consensus on the best approach(es) for PCP. Also see
<xref target="discovery_analysis"></xref> for further
analysis.]</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 optional Information Elements. It initializes a
retransmission timer to 4 seconds. The PCP client sends a PCP
message to each server in sequence, waiting for a response until its
timer expires. Once a PCP client has successfully communicated with
a PCP server, it continues communicating with that PCP server until
that PCP server becomes non-responsive, which causes the PCP client
to attempt to re-iterate the procedure starting with the first PCP
server on its list. If a hard ICMP error is received (e.g., port
unreachable, network unreachable) the PCP client SHOULD immediately
abort trying to contact that PCP server. If no response is received
from any of those servers, it doubles its retransmission timer and
tries each server again. This is repeated 4 times. If, after
repeating the procedure 4 times, no PCP server has responded the PCP
client SHOULD abort the procedure.</t>
</section>
<section title="Processing a Response">
<t>The PCP client receives the response and verifies the
source IP address and port belong to the PCP server of an
outstanding request. It validates the version number and
OpCode matches an outstanding request. The response is
further matched by comparing fields in the response
OpCode-specific data to fields in the request
OpCode-specific data. This matching is described by the
OpCode itself,
see <xref target="opcode_client_operation"></xref>. After a
successful match with an outstanding request, the PCP client
checks the Epoch field to determine if it needs to restore
its state to the PCP server
(see <xref target="epoch"></xref>).</t>
<t>If it is an error response (>0), the request failed. If the
error response is less than 128, retrying the same request sometime
in the future might be successful. If the error response is greater
or equal to 128, retrying the same request is unlikely to be
successful.</t>
<t>If it is the success response (0), the PCP client knows the
request was successful.</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. <list
style="empty">
<t>[Ed. Note: text regarding multi-homing needs work.]</t>
</list></t>
</section>
</section>
<section title="General PCP Server Operation">
<t>This section details operation specific to a PCP server.</t>
<t>Upon receiving a PCP request message, the PCP Server parses and
validates it. A valid request contains a valid PCP common header, one
valid PCP Opcode, and optional 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.</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 PCP
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
result code NOT_AUTHORIZED.</t>
</section>
</section>
<section anchor="pin_opcodes" title="Pinhole Operation">
<t>This document defines four OpCodes for forwarding ports and
controlling dynamic connections. These four OpCodes share a similar
packet layout for requests and responses. They are:</t>
<figure anchor="opcodes" title="OpCodes">
<preamble></preamble>
<artwork align="center"><![CDATA[
PIN44 = 0 = IPv4 address to IPv4 address (e.g., NAT44 or firewall)
PIN46 = 1 = IPv4 address to IPv6 address (e.g., NAT46 or firewall)
PIN64 = 2 = IPv6 address to IPv4 address (e.g., NAT64 or firewall)
PIN66 = 3 = IPv6 address to IPv6 address (e.g., NAT66 or firewall)
]]></artwork>
</figure>
<t>These operation of these OpCodes is described in this section.</t>
<section title="OpCode Packet Format">
<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 request's internal-ip-address and internal-port matches the
response's external-ip-address and external-port, the IP addresses and
ports are not changed and thus the functionality is purely a firewall;
otherwise it pertains to a network address translator which might also
perform firewall functions.</t>
<t>The following diagram shows the request packet format for PIN44,
PIN46, PIN64, and PIN66. This packet format is aligned with the
response packet format:</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: 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="Protocol:">indicates protocol associated with this
opcode. Values are taken from the <xref
target="proto_numbers">IANA protocol registry</xref>. For example,
this field contains 6 (TCP) if the opcode is intended to create a
TCP mapping. If a particular OpCode does not need the field, it
MUST sent as 0 and MUST be ignored when received.</t>
<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 MUST use 0.</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 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 MUST use 0.</t>
</list></t>
<t>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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: 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="Protocol:">Copied from the request.</t>
<t hangText="Reserved:">MUST be 0 on transmission, MUST be ignored
on reception.</t>
<t hangText="Pinhole Internal IP address:">Copied from the
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 anchor="opcode-specific-error-codes"
title="OpCode-Specific Error Codes">
<t>In addition to the response codes described in <xref
target="figure_result_codes"></xref>, the following additional
response codes may be returned as a result of the four PIN OpCodes
received by the PCP server.</t>
<figure anchor="figure_pin_result_codes"
title="Result Codes specific to PIN OpCodes">
<artwork align="center"><![CDATA[
130 - NOT_AUTHORIZED
(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)
[Ed. Note: probably need an OpCode indicating that the
REMOTE_PEER option is necessary to disambiguate a
connection. Do we require the PCP server to figure
out there is an ambiguity (multiple connections using
the same port)? Probably.]
]]></artwork>
</figure>
<t>Other OpCodes are in result codes are defined following the
procedure in <xref target="iana_result_codes"></xref>.</t>
</section>
<section anchor="opcode_client_operation"
title="OpCode-Specific Client Operation, Processing a Response">
<t>[Ed. Note: describe how PCP client sends a PIN* request, and
might get an Invalid Opcode response, and what it does.]</t>
<t>This section describes the operation of a client when sending the
OpCodes PIN44, PIN64, PIN46, or PIN66.</t>
<t>A response is matched with a request by comparing the protocol,
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 pinhole created
by the OpCode.</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.</t>
<t>If an unsucessful response code greater than or equal to 128, the
PCP client SHOULD NOT re-issue the same request. If a response code
less than or equal to 127, the PCP client MAY, if it wishes, resend
the same message after a delay of at least 5 seconds.</t>
</section>
<section anchor="opcode_server_operation"
title="OpCode-Specific Server Operation">
<t>This section describes the operation of a client when processing the
OpCodes PIN44, PIN64, PIN46, or PIN66.</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,
a positive 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><list style="empty">
<t>[Ed. Note: Issue #15: Should ICMP messages, associated with
this pinhole, be allowed by default. Consensus appears to be 'yes',
because that is what dynamic mappings on NATs do. And if we don't
do this, we will have PCP clients forget (or avoid) requesting
an ICMP pinhole, further degrading ICMP operation on the Internet.]</t>
</list></t>
<t><list style="empty">
<t>[Ed. Note: The following text needs discussion. Keep it or discard
it?] 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>
</list></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 title="Maintaining Same 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>.
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 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 (or until
the PCP server crashes). This has interactions with
dynamically-created mappings, see Sections <xref
target="dynamic-interaction"></xref>.</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>The PIN OpCodes require subscriber identification because they
allocate resources to a subscriber. 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,
a PCP client cannot 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 (e.g., /64), and that
length must be configurable by the network operator.</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 LSN with a routed network (NAT44), each subscriber has a
known set of IPv4 address (usually one IPv4 address) and all PCP
requests MUST be sent from only one of the subscriber's IP
addresses and MUST only open pinholes towards the subscriber's
own own IP address.</t>
<t>If IPv6 firewall: 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 (e.g., /64), and that length must be
configurable by the network operator.</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>
</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 title="Disambiguating Remote Peer">
<t>When operating a UDP or TCP server, one application is listening
on a port and no other application will be assigned that port by the
operating system. However, ephemeral connections (that is, outgoing
connections) to different servers can share the same ephemeral port,
even between applications. If a PCP request with a PIN OpCode is
sent after such a dynamic connection is established (potentially by
another application), the PCP server cannot reliable distinguish if
the PIN request is referring to the current connection or to a new
connection. To eliminate this ambiguity, the remote peer's IP
address and port can be specified in the REMOTE_PEER Option. </t>
<t>This Option does not create or modify filtering on the NAT (for
that, use REMOTE_PEER_FILTER) and have no effect on the NAT or
firewall's normal filtering which will be any combination of
Endpoint-Independent Filtering, Address-Dependent Filtering, or
Address and Port-Dependent Filtering (these terms are originally
defined and explained in <xref target="RFC4787"></xref>).</t>
</section>
</section>
<section anchor="pin_options" title="PCP Options for PIN OpCodes">
<t></t>
<!--
<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: PIN44, PIN64,
PIN46, PIN66.</t>
</section>
-->
<section anchor="remote_peer_filter" title="REMOTE_PEER_FILTER">
<t>This Option indicates packet filtering is desired. The remote
peer port and remote peer IP Address indicate the permitted remote
peer's source IP address and port for packets from the Internet.
That is, packets with a source IP address, transport, or port that
do not match those fields of the PCP request are dropped by the PCP
server-controlled NAT/firewall device. As a consequence of dropping
the packet, an ICMP port unreachable error SHOULD be generated, as
long as it does not violate the security policy of the
NAT/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 PIN44 or PIN64, :
: 1 28 bits if PIN46 or PIN66) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t></t>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>value: 128</t>
<t>is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66</t>
<t>is included in responses: MUST</t>
<t>has length: 64 or 160</t>
<t>may appear more than once: no</t>
</list></t>
</list>Because of interactions with dynamic ports (<xref
target="dynamic-interaction"></xref>), this Option MUST only be used
by a client that is operating a server, as this ensures that no
other application will be assigned the same ephemeral port for its
outgoing connection. Other use by a PCP client is NOT RECOMMENDED
and will cause some UNSAF NAT traversal mechanisms <xref
target="RFC3424"></xref> to fail where they would have otherwise
succeeded, breaking other applications running on this same
host.</t>
<t><list style="empty">
<t>[Ed. Note: How do we want to remove a filter? Do we want to allow
removing a filter at all -- is there a use-case for that or can the
application just create a new mapping? If we have a use-case, perhaps
use 0.0.0.0 as the remote IP address to remove all filters?</t>
</list></t>
</section>
<section title="REMOTE_PEER">
<t>Due to a pre-existing dynamic mapping, a PCP server may not be
able to instantiate a filter on a specific port. It is thus
recommended that applications bind to the source port (to prevent
other applications from using that same source port) prior to using
this PCP Option.</t>
<t>In those situations, the Option REMOTE_PEER is necessary to disambiguate
the mappings. This option does not change filtering behavior of the
NAT or firewall.</t>
<figure>
<artwork align="center"><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Remote Peer IP address (32 bits if PIN44 or PIN64, :
: 1 28 bits if PIN46 or PIN66) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>value: 129</t>
<t>is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66</t>
<t>is included in responses: MUST</t>
<t>has length: 64 or 160</t>
<t>may appear more than once: no</t>
</list></t>
</list></t>
</section>
<section title="HONOR_EXTERNAL_PORT">
<t>This option indicates the PCP client needs to have the indicated
requested-eternal-port allocated. If the PCP server cannot provide
that port for the exclusive use of the PCP client, the PCP server MUST
return an error [which code should we use?].</t>
<t>This option is intended for use
by <xref target="upnp-interworking">UPnP IGD
interworking</xref>.</t>
<t><list style="empty">
<t>This Option:<list style="empty">
<t>value: 6</t>
<t>is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66</t>
<t>is included in responses: MUST</t>
<t>has length: 0</t>
<t>may appear more than once: no</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="dynamic-interaction"
title="Interaction with Dynamic Connections">
<t>Dynamic connections are created by hosts sending a TCP or UDP
packet across their NAT. PCP can be used with such dynamic
connections. There are two interesting cases: PCP before a dynamic
connection, and PCP after a dynamic connection.</t>
<t>If two applications on the same host communicate with different
destinations, it is possible for them to be allocated the same
ephemeral source port -- without either of the applications using the
REUSEADDR socket option. Thus, one application's use of PCP (to adjust
the NAT or firewalls behavior) can affect an unrelated application on
the same host. This is why the four PIN OpCodes include the remote
peer fields. The remote peer fields allow the PCP server to to
disambiguate which mapping applies to the PIN OpCode message. </t>
<t>Because PCP is not intended to adjust NAT
behavior for dynamically-created connections, it is possible (and
reasonable) for that second dynamic connection to be mapped to a
different public port. Even if that occurs, the other application can
issue its own PCP request (to determine the mapping lifetime)
following the same procedure described in this section.</t>
</section>
<section anchor="keepalives"
title="Using PCP to Eliminate Application Keepalive Messages">
<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 avoid such application
keepalive traffic by using PCP.</t>
<t>To use PCP for this function, the applications first
connects to its server, as normal. Afterwards, it issues a PCP
PIN request (PIN44, PIN64, PIN46, or PIN66, as appropriate)
specifying the same 5-tuple as that connection in the PCP PIN
request (internal IP address and port, transport protocol, and
remote peer IP address and port), with
requested-external-address and requested-external-port both
set to 0, and includes the REMOTE_PEER Option indicating the
remote peer's IP address is from the perspective of the PCP
client. The PCP response will indicate the lifetime for that
session.</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>
<figure anchor="keepalive-pseudocode"
title="Pseudo-code for using PCP to with a dynamic socket">
<preamble>The following pseudo-code shows how PCP can be reliably
used with a dynamic socket, for the purposes of reducing application
keepalive messages:</preamble>
<artwork align="center"><![CDATA[
int s = socket(...);
connect(s, &remote_peer, ...);
getsockname(s, &internal_address, ...);
pcp_send_request(internal_address, 0, remote_peer, lifetime);
/* external address is set to zero */
]]></artwork>
</figure>
</section>
<section title="PCP Mapping State Maintenance">
<t>If an event occurs that causes the PCP server to lose state (such
as a crash or power outage), the 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 PCP response sent by the PCP Server includes an Epoch
field. This field increments by 1 every second, and indicates to the
PCP client if PCP state needs to be restored. If the PCP Server
resets or loses the state of its port mapping table, due to reboot,
power failure, or any other reason, it MUST reset its Epoch time to
0. Similarly, if the public IP address of the NAT (controlled by the
PCP server) changes, the Epoch MUST be reset to 0.</t>
<t>Whenever a client receives a PCP response, the client computes
its own conservative estimate of the expected Epoch value by taking
the Epoc 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>.<list style="empty">
<t>[Ed. Note: comment from Dave Thaler: "So spoofed packets with
Epoch=0 that look like they come from the server could result in
a big amplification attack on the PCP server. How is this
mitigated?"]</t>
</list></t>
</section>
<section anchor="reboot" title="Recreating Pinholes">
<t>The PCP server SHOULD store mappings in persistent storage so
when it is powered off or rebooted, it remembers the port mapping
state of the network. Due to the physical architecture of some PCP
servers, this is not always achievable (e.g., some non-volatile
memory can withstand only a certain number of writes, so writing PCP
mappings to such memory is generally avoided).</t>
<t>However, maintaining this state is not essential for correct
operation. When the PCP server loses state and begins processing new
PCP messages, its Epoch is reset to zero (per the procedure of <xref
target="epoch"></xref>).</t>
<t>A mapping renewal packet is formatted identically to an original
mapping request; from the point of view of the client it is a
renewal of an existing mapping, but from the point of view of the
PCP server it appears as a new mapping request.</t>
<t>This self-healing property of the protocol is very important.</t>
<t>When a client renews its port mappings as the result of receiving
a packet where the Epoch field 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 PCP request. After
that request is acknowledged by the PCP server, 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 focuses on recreating inbound port
mappings after loss of PCP server state, because that is the more
serious problem. Losing port mappings for outgoing connections
destroys those currently active connections, but does not prevent
clients from establishing new outgoing connections. In contrast,
losing inbound port mappings not only destroys all existing inbound
connections, but also prevents the reception of any new inbound
connections until the port mapping is recreated. Accordingly, we
consider recovery of inbound port mappings the more important
priority. However, clients that want outgoing connections to survive
a NAT gateway reboot can also achieve that using PCP. After
initiating an outbound TCP connection (which will cause the NAT
gateway to establish an implicit port mapping) the client should
send the NAT gateway a port mapping request for the source port of
its TCP connection, which will cause the NAT gateway to send a
response giving the external port it allocated for that mapping. The
client can then store this information, and use it later to recreate
the mapping if it determines that the NAT gateway has lost its
mapping state.</t>
</section>
<section title="Maintaining 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>
<t>If the client wishes to check the PCP server's Epoch, it sends a
PCP request for any one of the client's pinholes. This will return
the current Epoch value. In that request the PCP client could extend
the mapping lifetime (by asking for more time) or maintain the
current lifetime (by asking for the same number of seconds that it
knows are remaining of the lifetime).</t>
</section>
</section>
<section anchor="nested_nat" title="Nested NATs">
<t><list style="empty">
<t>[Ed. Note: Nested NATs will be discussed in a later version of
this document or, more likely, in a separate document. The
mechanism to support nested NATs is to have each NAT implement a
PCP server (to service devices and NATs behind it) and a PCP
client (to communicate with NATs above it). This allows a PCP
client to be unaware of the PCP communications going on between
upstream NATs.]</t>
</list></t>
</section>
<section anchor="delete" title="Pinhole Deletion">
<t>A PCP Client can delete a pinhole immediately by sending the
appropriate PIN OpCode with a lifetime of 0. The PCP server responds
by returning a PIN Response with a lifetime of 0.</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="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>
<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 and is the
local network's default router.</t>
<section title="Overview">
<t>Various PCP deployment scenarios can be considered to control the
PCP server embedded in the AFTR element:<list style="numbers">
<t>UPnP IGD and NAT-PMP 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 with either include a PCP client
or UPnP IGD client.<list style="letters">
<t>if a UPnP IGD client, the B4 element will need to include
an interworking function from UPnP IGD to PCP.</t>
<t>if a PCP client, the PCP client will communicate directly
with the PCP server.</t>
</list></t>
<t>The B4 element 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>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 large scale
NAT (LSN). To accomodate 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".<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?]</t>
</list></t>
</section>
<section title="IPv6 Firewall">
<t>See <xref target="remote_peer_filter"></xref>.<list style="empty">
<t>[Ed. Note: this IPv6 firewall section needs more text.]</t>
</list></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.]</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[
+-------------+
| 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. Requiring a
specific port is incompatible with both (1) a large-scale 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 large-scale address sharing and
popular applications, future hosts and applications will either
support UPnP IGD 2.0's AddAnyPort Mapping (see <xref
target="upnp-2-interworking"></xref>) or will support PCP.</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
HONOR_EXTERNAL_PORT 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
| | |
|-UPnP:AddPortMapping(80)--->| |
| |-PCP:request port 80------>|
| | HONOR_EXTERNAL_PORT |
| | |
| |<-PCP:error----------------|
|<-UPnP: unavailable---------| |
| | |
|-UPnP:AddPortMapping(3213)->| |
| |-PCP:request port 3213---->|
| | HONOR_EXTERNAL_PORT |
| | |
| |<-PCP:error----------------|
|<-UPnP: unavailable---------| |
| | |
... ... ... ...
| | |
|-UPnP:AddPortMapping(8921)->| |
| |-PCP:request port 8921---->|
| | HONOR_EXTERNAL_PORT |
| | |
| |<-PCP:ok, port 8921--------|
|<-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 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
| | |
|-UPnP:AddAnyPortMapping()->| |
| |-PCP:external port 0----->|
| |<-PCP:external port=12345-|
|<-UPnP:port=12345----------| |
| | |
]]></artwork>
</figure>
</section>
<section title="Lifetime Maintenance">
<t>Neither UPnP IGD 1.0 nor 2.0 provide a lifetime. 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. The UPnP IGD/PCP
interworking function is responsible for renewing the PCP lifetime
as necessary. 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, as
the server could be temporarily down when tested, causing a false
negative.</t>
</list></t>
</section>
</section>
<section anchor="security" title="Security Considerations"></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 both <xref
target="figure_result_codes"></xref> and <xref
target="figure_pin_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="Options">
<t>IANA shall create a new registry for PCP Options, numbered 0-255
with an associated mnemonic. The values 0-127 are optional-to-process,
and 128-255 are mandatory-to-process. The initial registry contains
the options described in <xref target="pin_options"></xref>.</t>
<t>New information elements in the range 0-64 and 128-192 can be
created via <xref target="RFC5226">Standards Action</xref>, and the
range 64-127 and 192-255 is for <xref target="RFC5226"> Private
Use</xref>.</t>
</section>
</section>
<section title="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, Christian Jacquenet, and Simon Perreault for
their comments and review. Thanks to Simon Perreault for highlighting
the interaction of dynamic connections with PCP-created pinholes.</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.3424'?>
<?rfc include='reference.RFC.4787'?>
<?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 title="Changes">
<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 PIN* opcodes</t>
<t>Renamed Informational Elements (IE) to Options.</t>
<t>Added REMOTE_PEER, REMOTE_PEER_FILTER, and HONOR_EXTERNAL_PORT 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 wasn't in the request.</t>
<t>Response code most significant bit now indicates
permanent/temporary error</t>
<t>PCP Options are split into mandatory-to-process ("P" bit),
and into Specification Required and Private Use.</t>
<t>Epoch discussion simplified.</t>
</list></t>
</section>
</section>
<section anchor="discovery_analysis"
title="Analysis of Techniques to Discover PCP Server">
<t><list style="empty">
<t>[Ed. Note: This Appendix will be removed in a later version of
this document. It is included here for reference and discussion
purposes.]</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 large scale NAT (LSN) operated by the ISP. 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. 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:24:43 |