One document matched: draft-wing-softwire-port-control-protocol-02.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-wing-softwire-port-control-protocol-02"
ipr="trust200902">
<front>
<title abbrev="Pinhole Control Protocol (PCP)">Pinhole 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>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>California</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>rpenno@juniper.net</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<date />
<workgroup>Softwire working group</workgroup>
<abstract>
<t>Pinhole Control Protocol is an address-family independent mechanism
to control how incoming packets are forwarded by upstream devices such
as IPv4 NAT devices, NAT64 devices, and IPv6 firewalls.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<section title="Protocol Overview">
<t>Pinhole Control Protocol (PCP) provides a mechanism to control how
incoming packets are forwarded by upstream devices such as NATs. PCP
is primarily designed to be implemented in the context of large scale
NAT deployments. Especially, it offers the ability to configure a port
forwarding capability in Service Provider NATs. Therefore, similar
service features as per current CP (Customer Premises) router model
can be offered to Customers who are serviced behind a Provider
NAT.</t>
<t>PCP allows applications to learn their external IP address and also
to instantiate mappings in the PCP-controlled devices. These mappings
are required for successful inbound communications destined to
machines located behind a large scale NAT <xref
target="I-D.ford-shared-addressing-issues"></xref>. Owing to PCP, the
overall performance of the Provider NAT would not be altered since PCP
is a means to avoid enabling numerous ALGs (Application Level
Gateways) in the CGN. Because applications may learn their external
reachability information, ALGs are de-activated for the configured
mappings. This behaviour would enhance the performance of
PCP-controlled devices.</t>
<t>The main design principles of PCP are as follows:</t>
<t><list style="symbols">
<t>address-family dependent; it can be used over IPv4 and IPv6,
and for any transport protocol;</t>
<t>lightweight on both the Client and Server;</t>
<t>request/response protocol running over UDP;</t>
<t>no permanent sessions are required to be maintained between the
Client and the Server;</t>
<t>client can be implemented within customer premise equipment
(e.g., a router), or by an application running on a host;</t>
<t>allows opening ports on behalf of other devices belonging to
the same (home) network such as a webcam or a webserver.</t>
</list></t>
</section>
<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
AFTR</xref></t>
<t><xref target="I-D.ietf-behave-v6v4-xlate-stateful">Stateful
NAT64</xref></t>
<t><xref target="I-D.ietf-behave-v6v4-xlate">Stateless
NAT64</xref></t>
<t><xref target="I-D.nishitani-cgn">Large-Scale NAT44</xref></t>
<t><xref target="I-D.miles-behave-l2nat">Layer-2 aware
NAT</xref></t>
<t><xref target="I-D.ietf-v6ops-cpe-simple-security">IPv6 firewall
control</xref></t>
</list></t>
</section>
<section title=" Companion Documents">
<t>This document specifies the base PCP protocol. Other documents are
edited to elaborate on additional aspects such as:<list
style="symbols">
<t>Interworking with UPnP-IGD <xref
target="I-D.bpw-softwire-upnp-pcp-interworking"></xref>.</t>
<t>DHCP options to provision PCP Servers <xref
target="I-D.bpw-softwire-pcp-dhcp"></xref>.</t>
<t>PCP flow examples <xref
target="I-D.bpw-softwire-pcp-flow-examples"></xref>.</t>
</list></t>
</section>
</section>
<section title="Scope">
<section title="Supported Transport Protocols">
<t>PCP is 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>
</section>
<section anchor="mono_homed" title="Single-homed CP Routers">
<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 restriction exists because otherwise there would need
to be one PCP servers 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>
<section title="Port Forwarding">
<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>
</section>
<section title="PCP Client">
<t>The network element that sends PCP requests to the PCP Server. This
network element could be an application running on a host, embedded in
the host's OS or libraries, or running on a network device (such as a
customer premise router).</t>
</section>
<section title="PCP Server ">
<t>A network element which receives and processes PCP requests from a
PCP Client. This element might be the same as the device embedding the
controlled NAT (as shown in <xref
target="diagram_pcp_server_embedded"></xref>) or might be a different
element in the network which interacts with the NAT (e.g., using
out-of-band XML, as shown in <xref
target="diagram_pcp_server_separate"></xref>).</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>
<figure anchor="diagram_pcp_server_separate"
title="NAT with Separate PCP Server">
<artwork align="center"><![CDATA[ +-----------------+
+--+ NAT or firewall +---<Internet>
/ +-----------------+
+------------+ / ^
| PCP Client +-<network> | Interaction (e.g., using XML)
+------------+ \ v
\ +------------+
+--+ PCP Server |
+------------+
]]></artwork>
</figure>
</section>
<section anchor="sec_interworking" title="PCP Interworking Function">
<t>A PCP Interworking Function denotes a functional element which is
responsible for interworking PCP with another control protocol. This
interworking function functions as a PCP client towards the PCP
server, and functions as a server towards the user's network. For
example, if interworking with UPnP IGD, the interworking function
would appear as a UPnP IGD server <xref
target="I-D.bpw-softwire-upnp-pcp-interworking"></xref>. Interworking
other control protocols, or interworking with a customer premise
router's HTTP configuration, would also be a PCP Interworking
Function.</t>
</section>
</section>
<section anchor="discovery" title="PCP Server Discovery">
<t>After considering several discovery mechanisms (<xref
target="discovery_analysis"></xref>) we propose two mechanisms for the
PCP client to discover its PCP server:<list style="symbols">
<t>a new DHCP option <xref
target="I-D.bpw-softwire-pcp-dhcp"></xref></t>
<t>a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA.
This is necessary in some expected environments, including<list
style="symbols">
<t>where the customer premise NAT is unable to forward a new
DHCP option to internal hosts,</t>
<t>or where the OS running on internal hosts does not provide an
API to request the new DHCP option.</t>
</list></t>
</list></t>
</section>
<section anchor="format" title="PCP Message Format">
<t>PCP messages start with one PCP header, one OpCode, and zero or more
Informational Elements.</t>
<section title="PCP Header">
<t>All PCP messages MUST begin with the following header.</t>
<figure align="center" anchor="pcp_generic_header"
title="PCP Generic Header">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| RESERVED |S| OpCode | OpCode-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>The description of the fields is as follows:<list style="symbols">
<t>Ver: This 2 bit field indicates the PCP version. The version
defined in this document is version 0, and it MUST be set to 0.
Other values, when received, generate an error.</t>
<t>Reserved bits: These 6 bits are reserved for future use. They
MUST be zero when sending, and their value MUST be ignored when
receiving.</t>
<t>S bit, indicates request (0) or response (1).</t>
<t>OpCode: Operation code, a 7 bit field. <xref
target="iana_opcodes"></xref> lists the OpCodes as defined in this
document.</t>
<t>Length: 16 bits. Indicates the length of the OpCode Payload, in
bytes. After this offset start the Informational Elements, if any.
They contain their own length fields.</t>
<t>Transaction-ID: 32 bits. This transaction ID is randomly
generated by the PCP Client for each new PCP Request;
retransmitted requests use the same value. The value of this field
MUST be echoed by the PCP Server in the response. Transaction-ID
allows several messages to be in flight between the PCP Client and
PCP Server.</t>
</list></t>
</section>
<section anchor="pcp_opcodes" title="OpCodes">
<t>This section defines PCP OpCodes. A request or response MUST
contain one OpCode. New OpCodes can be defined following the policy
described in <xref target="iana_opcodes"></xref>.</t>
<section anchor="opcode_pcp" title="Pinhole Requests and Reponses">
<t>The following OpCodes are defined and indicate if an IPv4 address
(or IPv6 address) is provided in the request and its associated
response: <list style="hanging">
<t hangText="PIN44: ">Pinhole IPv4 address and port to IPv4
address and port, which has an IPv4 address in the request and
an IPv6 address in the response.</t>
<t hangText="PIN64: ">Pinhole IPv6 address and port to IPv4
address and port, which has an IPv6 address in the request an
IPv4 address in the response.</t>
<t hangText="PIN46: ">Pinhole IPv4 address and port to IPv6
address and port, which has an IPv4 address in the request and
an IPv6 address in the response.</t>
<t hangText="PIN66: ">Pinhole IPv6 address and port to IPv6
address and port, which has an IPv6 address in the request and
an IPv4 address in the response.</t>
</list>These OpCodes all share the same OpCode format, shown
below. The difference is only the length of the IP address
fields.</t>
<texttable anchor="table_pin"
title="IP addresses in various PINxy messages">
<ttcol align="center">PIN message</ttcol>
<ttcol align="center">Request Internal IP address</ttcol>
<ttcol align="center">Response External IP address</ttcol>
<c>PIN44</c>
<c>IPv4</c>
<c>IPv4</c>
<c>PIN64</c>
<c>IPv6</c>
<c>IPv4</c>
<c>PIN46</c>
<c>IPv4</c>
<c>IPv6</c>
<c>PIN66</c>
<c>IPv6</c>
<c>IPv6</c>
<postamble></postamble>
</texttable>
<figure align="center" anchor="PIN-REQUEST" title="PIN-REQUEST">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal IP address (32 or 128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proto |W|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Pinhole Lifetime (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal Port | Requested External Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal Port : Requested External Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The description of the fields is as follows:<list style="symbols">
<t>Internal IP address</t>
<t>Proto indicates the protocol, with values taken from IANA's
protocol registry.</t>
<t>The "W" bit indicates 'wildcard', which means 'any protocol',
and the protocol value is meaningless when W is set. When the W
bit is set, the internal and external port numbers MUST NOT be
included in the request. The wildcard is intended to function
similar to the "DMZ" function for IPv4 hosts or a firewall
pinhole for IPv6 firewalls.</t>
<t>The "M" bit indicates that mapping all of the Requested
External Ports are mandatory; if any cannot be mapped, the
transaction fails.</t>
<t>Requested Pinhole Lifetime is the desired lifetime of this
pinhole.</t>
<t>Internal port indicates the internal host's port</t>
<t>Requested external port indicates the requested external
port. This is often the same as the internal port, or a popular
port (e.g., TCP/80).</t>
</list></t>
<t>Pairs of internal port and external port MAY be repeated,
indicating the PCP client wishes to allocate several ports in one
PCP request. This is an optimization to reduce chattiness of the
protocol when several ports are needed by an application.</t>
<t>Non-Error responses use the same OpCode and Transaction-ID as the
associated request, set the S bit, and use the following format:</t>
<figure align="center" anchor="PIN-RESPONSE" title="PIN-RESPONSE">
<preamble></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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal IP address (32 or 128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: External IP address (32 or 128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proto |W| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Pinhole Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal Port | Assigned External Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal Port | Assigned External Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The description of the fields is as follows:<list style="symbols">
<t>Internal IP address of the host. This is simply echoed from
the request.</t>
<t>External IP address of the pinhole. If the PCP controlled
element is a NAT, this value will differ from the internal IP
address of the host.</t>
<t>Proto indicates the protocol, which is echoed from the
request.</t>
<t>The "W" bit indicates 'wildcard', which means 'any protocol',
and the protocol value is meaning less when this bit is set.
When the W bit is set, it means all traffic (no matter the
protocol) is sent from the external IP address to the internal
IP address. When the W bit is set, the internal port and
external port MUST NOT be returned in the response.</t>
<t>Assigned pinhole Lifetime is the lifetime of this pinhole,
and may be greater or less than the requested pinhole
lifetime.</t>
<t>Internal port indicates the internal host's port, and is
echoed from the request.</t>
<t>External port indicates the assigned external port. This MAY
be different from the requested external port, especially on a
busy NAT.</t>
</list></t>
</section>
<section anchor="opcode_error" title="Error Response">
<t>This OpCode MUST only be present in a PCP response (that is, the
S bit in the PCP header MUST be set). If a PCP client or PCP server
receives a request with this OpCode, it MUST be silently dropped.
The PCP Server generates this response if a PCP request cannot
successfully be processed.</t>
<figure align="center" anchor="ERROR-RESPONSE"
title="Error response">
<preamble></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 0 0 0 0 0|S| OpCode | OpCode-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error SubCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
]]></artwork>
</figure>
<t>The following error codes are defined in this document. For
certain errors, additional information is in the error subcode.</t>
<figure anchor="pcp_error_code_table">
<artwork><![CDATA[
code error subcode meaning
---- ---------- -----------
1 highest supported version unsupported PCP version
(do we need this error code?)
2 0 user not authorized
3 0 (reserved)
4 0 out of resources
5 OpCode received unsupported OpCode
6 transport protocol received unsupported transport protocol
7 subscriber's port limit subscriber port limit exceeded
8 0 parsing error
9 0 internal/external mismatch
10 0 other error
11 0 unsupported use of wildcard
13 0 cannot assign mandatory ports
]]></artwork>
</figure>
<t><list style="empty">
<t>Notes: error-code 7 indicates that 'available number of
ports' can never be relied upon because its value depends on the
port utilization of the NAT across all users and the number of
sessions consumed by other applications running on the same
computer or other computers belonging to the same subscriber. As
these are constantly changing, the value returned should only be
considered a hint to the PCP client in determining the number of
ports available to PCP. Also, the value returned does not
necessarily have any relation with the number of ports available
to the subscriber for dynamic forwarding, as it is expected some
PCP servers and some NATs will permit only a subset of a
subscriber's ports to be forwarded using PCP.</t>
</list></t>
</section>
</section>
<section anchor="pcp_information_elements" title="Information Elements">
<t>Information Elements (IE) MAY appear in requests and are associated
with the request being sent. If a PCP request contains several IEs,
they MAY be encoded in any order in the request and MUST be encoded in
the same order in the response. If a PCP client or PCP server receives
an IE it does not understand, or is malformed, it simply ignores the
IE (as if that IE was not present); note this can cause a response to
contain fewer IEs than the request if the PCP server does not
understand an IE.</t>
<figure align="center" anchor="IE-layout"
title="Informational Element header">
<preamble></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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information-Element-Code | IE-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (data) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>When a new IE is defined, it MUST cause the PCP server to generate
an indication the IE was processed by the PCP server (e.g., by
including an IE in the response). For example, if the PCP server
supported a newly-defined IE which provides descriptive text for a
port mapping ("webcam on 4th floor"), the mapping would be created and
the PCP server would respond with an IE indicating it included that
descriptive text in the mapping. New IEs MUST be registered with IANA
following the procedure described in <xref
target="iana_ie"></xref>.</t>
<t>One Information Element, for DSCP, is defined in <xref
target="sec_dscp_ie"></xref>.</t>
</section>
</section>
<section 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 port number (<xref
target="iana_port"></xref>).</t>
<t>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 header, PCP OpCode, and
optional Information Elements. Each of these elements contain a length
and their own encoding.</t>
<t>The PCP Client MAY request an external port matching the internal
port.</t>
<t>Once a PCP client has discovered its PCP Server (<xref
target="discovery"></xref>), and has prepared a PCP Request message
for its PCP server, it tries communicating with the first PCP server
on its list. 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 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 with the same Transaction-ID, and
waits again. This procedure is repeated three times, doubling the
value of RETRY_TIMER each time. If no response is received, 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, it is parsed. A valid request
has the "S" bit cleared, contains a valid PCP 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 (<xref target="opcode_error"></xref>) is generated
and immediately sent back to the PCP client. This error response
SHOULD include those IEs from the request that are understood by the
server.</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 the pinhole described
by the internal IP address (and internal ports, if W is cleared)
should be deleted; the requested external port is ignored by the
server. If such a pinhole exists, it is deleted and a positive
response MUST be generated, echoing the information in the request. If
the "W" bit is set, it indicates all pinholes for the indicated
internal IP address are to be deleted. If the internal IP address is
all zeros, it indicates that all pinholes for all hosts belonging to
the subscriber are to be deleted for all protocols (if "W" is set) or
the indicated protocol (if "W" is cleared). For all cases with
lifetime is 0, if such a pinhole does not exist, it could be because
the pinhole was already deleted and the response was lost, so the same
positive response (as described above) MUST be generated.</t>
<t>If the requested lifetime is not 0, but a pinhole already exists
for the indicated internal IP address (and port(s)), the PCP server
replies with a successful response, as if this was a newly-created
pinhole. This can occur because the PCP client is either asking for a
renewal of their lifetime, because the original response was lost, or
because the PCP client has forgotten about its mapping (e.g.,
application crashed) and it is requesting a mapping for the same
internal IP address and internal port.</t>
<t>If any of the requested external port number(s) is not available,
and the "M" bit is set, the PCP-controlled device MUST NOT create any
pinholes and MUST return an error code=13.</t>
<t>If any of the requested external port number is not available, the
PCP-controlled device MUST return an available external port number
or, if no ports are available or the user has exhausted their port
limit, return an error response. If several ports were requested, but
not all could be mapped, the PCP server MUST NOT map any of them, and
MUST return an error code=7.</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 3600 seconds (i.e.,
one hour).</t>
<t>By default, a PCP-controlled device MUST NOT create mappings for a
protocol not indicated in the request; that is, 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 the companion port so the same PCP Client can map 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 and Transaction-ID as the
request, sets the "S" bit, and uses the PIN-RESPONSE. If multiple
ports were in the request, they are all included in the response, in
the same order, with their associated assigned external port numbers.
If there were Informational Elements in the request, which the server
understood and processed (as described by the documents that define
those IEs), the necessary IE responses are included. If there were IEs
in the request, which the server did not understand, they are simply
ignored as if they were not present.</t>
</section>
<section title="Processing a Response">
<t>The PCP client receives the response and checks that the
Transaction-ID matches one of its outstanding transactions. 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 transaction
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 CP 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. This same problem can occur if an IP address is re-assigned
today, without PCP. The solution is the same as today: don't re-assign
IP addresses. PCP provides a solution, as well: the PCP client can
request the mappings be re-assigned to its new IP address, using the
procedure described in Section 7.1.7.</t>
</section>
</section>
<section title="PCP Server Operation">
<t>This section details operation specific to a PCP server.</t>
<section title="Pinhole Lifetime">
<t>Once a PCP server has responded positively to a pinhole request for
a certain lifetime, the PCP-controlled device (e.g., NAT, firewall)
MUST keep that pinhole open for the duration of the lifetime that was
indicated in the PCP response. This is very much akin to how DHCP
works today, in that an IP address assigned via DHCP can be used for
the duration of the DHCP lease, but this is different from how other
protocols (e.g., NAT-PMP) function where the NAT device is permitted
to reboot and lose its pinholes. This is by design, because the
service provider-operated PCP server and PCP-controlled device are
expected to have persistent storage so that pinholes are not forgotten
upon failure of the PCP server or failure of the PCP-controlled device
(e.g., NAT or firewall).</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 (e.g.,
due to crash or power failure of the PCP client). Other mechanisms,
such as a web portal or even a publicly-routed IP address, are
probably more appropriate for such long-duration mappings.</t>
<t>The PCP server SHOULD be configurable for permeated minimum and
maximum lifetime, and the RECOMMENDED values are 60 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 MUST NOT assign that same external port to
another client for 30 seconds, and SHOULD NOT assign it for 120
seconds.</t>
</section>
<section anchor="sec_subscriber_identification"
title="Subscriber Identification">
<t>A PCP Client can instruct mappings in a PCP-controlled device on
behalf of a third party device (e.g., webcam). In order to prevent a
PCP Client to ask for mappings on behalf of a device belonging to
another subscriber, the following rules are to be followed depending
on the PCP-controlled device:<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>
</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., CGN 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>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>
<t>Etc.</t>
</list></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.</t>
</section>
<section title="Policy Configuration">
<t>A PCP Server MAY be configured with various policies such as:<list
style="symbols">
<t>Supported transport protocols;</t>
<t>Ports to be excluded from the allocation process;</t>
<t>Behaviour when a well-known port is requested: [[Note: A
specific configuration: what to do when a PCP Client asks for a
WKP but this port associated with the assigned external IP address
(for dynamic mapping and not for configured mappings) is used but
this port is available in other addresses. This flexibility in the
decision-making process of the PCP Server mitigates some of the
limitations of sharing IP addresses.]]</t>
<t>Maximum number of ports be assigned to that subscriber;</t>
<t>Enable/disable port preservation; that means the PCP Server
always assign the requested port number when that port is in not
in use for the corresponding external IP address and transport
protocol;</t>
<t>Enable/disable port randomization;</t>
<t>Enable/disable port range allocation policy;</t>
<t>Enable/disable port parity preservation;</t>
<t>Enable/disable port contiguity;</t>
<t>Enable/disable DSCP re-marking;</t>
<t>Enable/disable DSCP filtering;</t>
<t>Enable/disable restricting remote IP address;</t>
<t>Logging of PCP-mapped ports.</t>
</list></t>
<t>PCP Server MUST be aware of the configured IPv4 address pool(s),
ports in use, etc. It is outside this document to specify how this
information is known to the PCP Server. This is
implementation-specific.</t>
</section>
</section>
<section anchor="failure" title="Failure Scenarios">
<t>In the following sub-sections we discuss PCP failure scenarios.</t>
<section title="Host Reboot/PCP Client Failure">
<t>From a PCP Client perspective, several failure scenarios can be
experienced by the host embedding that PCP Client (e.g., manual
reboot, crashes, power outage, etc.).</t>
<t>[[To be completed. PCP client can request removal of its mappings
(if any) and establish new mappings.]]</t>
<t>If the PCP Client has instructed a PCP Server to create mappings on
behalf of a third party (e.g., webcam device), any connectivity change
occurred in that third party device requires updating its associated
mappings. Concretely, if a new IP address is assigned to that device:
this change can be notified to the PCP Client by other means (e.g.,
the PCP Client is embedded in the same DHCP server which assigns IP
addresses to internal hosts, administration GUI, etc.). In such case,
the PCP Client MUST update the mapping with the new assigned internal
IP address.</t>
</section>
<section title="Provider NAT or PCP Server Reboot">
<t>The NAT operated by the Service Provider and the PCP Server are
both expected to maintain PCP-initiated port mapping information in
permanent storage, so a reboot will cause no loss of port mapping
information. Furthermore, If the NAT provides high availability
(stateful switchover), it is RECOMMENDED that PCP-initiated port
mappings be synchronized with the backup NAT device(s).</t>
</section>
<section title="PCP Proxy/PCP Interworking Function">
<t>A failure/reboot of a device embedding a PCP Proxy or a PCP
Interworking Function may lead to a change of the IP address of the
external interface of that device and/or the loss of the mappings. The
PCP Proxy or PCP Interworking Function behaves as follows according to
its ability to recover locally installed mappings:<list
style="symbols">
<t>Persistent storage of the mappings: <list style="symbols">
<t>Change of the IP address of the external interface of the
PCP Proxy/PCP Interworking Function: the PCP Proxy/PCP
Interworking Function MUST update all its associated mappings
in the PCP Server (see <xref target="refresh"></xref>);</t>
<t>The same IP address is assigned to the external interface
of the PCP Proxy/PCP Interworking Function: No action is to be
undertaken by the PCP Proxy/PCP Interworking Function.</t>
</list></t>
<t>Non-persistent storage of the mappings:<list style="symbols">
<t>The PCP Proxy MUST delete all pinholes the subscriber.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="scenarios" title="Deployment Scenarios">
<section title="Dual Stack-Lite">
<t></t>
<section title="Overview">
<t>Various PCP deployment scenarios can be considered to control an
AFTR. <list style="numbers">
<t>UPnP IGD and NAT-PMP are used in the LAN: an interworking
function is required to be embedded in the CP router to ensure
interworking between the protocol used in the LAN and PCP. UPnP
IGD-PCP Interworking Function is defined in <xref
target="I-D.bpw-softwire-upnp-pcp-interworking"></xref>.</t>
<t>Hosts behind the CP router embed a PCP Client, and
communicate directly with the PCP server. No interworking
function is required to be embedded in the CP router. In the
LAN, the IP address to reach an external PCP Server or a local
PCP Proxy is advertised to PCP Clients owing to one of the
recommended methods in <xref target="discovery"></xref>.</t>
<t>The CP router embeds a PCP Client invoked for HTTP-based
configuration. Indeed, PCP packets triggered by HTTP-based
configuration would be crafted as described in <xref
target="sec_interworking"></xref>. The source IPv4 address would
be the internal host used in the port forwarding configuration
and the destination IPv4 address is provisioned owing to the one
of the recommended methods in <xref target="discovery"></xref>.
The UDP destination port number MUST be set to the IANA
allocated destination port for PCP.</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>
</section>
<section anchor="dslite_encap" title="Encapsulation Mode">
<t>In this mode, CP router (B4) does no processing at all of the PCP
messages, and forwards them as any other UDP traffic. With DS-Lite,
this means that PCP messages issued by internal PCP Clients are
encapsulated in IPv6 packets and sent to the AFTR as for any other
IPv4 packets. The AFTR de-encapsulates the IPv4 packets and
processes the PCP requests (because the destination IPv4 address
points to the PCP Server embedded in the AFTR).</t>
<t>Like for any other IPv4 packet received by the AFTR in the
softwire tunnel, the source IPv6 address of the received
IPv4-in-IPv6 PCP packet is stored by the PCP Server.</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 CP router. 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. This IPv6 address is maintained by the PCP Server in its
PCP mapping table.</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="I-D.ietf-behave-address-format"></xref>.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Any software on the host can open a transport port on an upstream NAT
or upstream firewall, permitting incoming connections. At first glance,
this seems risky, as malicious software running on a host could allow
that host's web server to be accessible from the Internet, for example.
However, that same malicious software, if it were restricted to only
open incoming connections for itself could do so, and could then relay
incoming traffic to the host's own webserver. Thus, security is no worse
by allowing an application to open other arbitrary ports.</t>
<t>A PCP Client may open pinholes on behalf of devices belonging to the
same administrative entity (e.g., residential customer, enterprise,
etc.). Nevertheless, a host belonging to subscriber A cannot open a
pinhole for a host belonging to subscriber B (<xref
target="sec_create"></xref>).</t>
<t>The following sub-sections analyses how PCP mitigates some security
issues that may be raised when using a tool to control a firewall or a
NAT.</t>
<section title="Forbidden Mapping Requests">
<t>The PCP Server MUST NOT accept PCP requests from an Internet-
facing interface, but only from subscribers belonging to the Service
Provider. Requests destined to one of the PCP-controlled device's
external IP addresses MUST NOT be accepted by the PCP Server.</t>
</section>
<section title="PCP Response Integrity">
<t>Upon receiving a PCP response packet, the PCP Client MUST check the
source IP address, and silently discard the packet if the address is
not the address of the PCP Server to which these request was sent.</t>
<t>Upon receiving a PCP Map Create Response, the PCP Client MUST check
if the included Internal IP address and Internal port numbers matches
the ones includes in the PCP Map Create Request. If not, the response
is considered as invalid one (e.g., blind responses sent by a fake PCP
Server) and it is ignored consequently. In such case, the PCP Client
has to issue its initial request.</t>
</section>
<section title="Unwanted Deleting/Modification of Mappings">
<t>Removing or modifying an existing mapping in a PCP-controlled
device would disturb and affect the successful delivery of wanted
traffic to a legitimate subscriber.</t>
</section>
<section anchor="sec_create"
title="Protection Against Creating Unwanted Mappings">
<t></t>
<section title="DS-Lite">
<t>In DS-Lite, the subscriber is identified by IPv6 address of their
DS-Lite tunnel or an IPv6 prefix. To prevent a subscriber from
masquerading as another subscriber and using PCP to attract traffic
to the victim, IPv6 source address validation is RECOMMENDED, as
already suggested in Section 11 of <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>.</t>
</section>
<section title="NAT64">
<t>In NAT64, subscribers are identified by their IPv6 prefix, whose
length is determined by the network operator (e.g., /56 or /48). The
PCP server MUST be configured with the prefix-length, and uses that
prefix-length to ensure the PCP request is for a host belonging to
the same subscriber.</t>
</section>
</section>
<section title="Protection Against DoS Attacks">
<t>PCP Server may be subject to DoS attacks. Therefore, PCP Servers
SHOULD be protected against DoS attacks.</t>
<t>A PCP Server may receive an excessive number of PCP messages from a
PCP Client, in an effort to interfere with normal operation of the PCP
Server. In such a situation, the PCP Server MAY ignore messages from
such misbehaving PCP clients.</t>
</section>
<section title="Stale Mappings">
<t>Due to a change of IP address, a host may receive an unwanted
traffic because the previous owner of that address has instructed some
mappings in the PCP and didn't deleted them in a proper manner. As a
reminder, on today's Internet without an ISP-operated NAT, subscribers
occasionally have their IPv4 addresses changed due to renumbering or
because a service provider changes subscriber address (typically done
to interfere with the subscriber operating a server). In those
instances, traffic from the Internet is also sent to the previous
address. In the presence of PCP and a NAT, it is possible that
subscribers behind a NAT would also have their IPv4 addresses changed,
and also receive traffic from the Internet because the NAT is unaware
that the subscriber's IPv4 address has changed.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to perform the following actions:</t>
<section title="PCP IP address">
<t>Assign an IPv4 and an IPv6 address for PCP discovery. This is
denoted as PCP-IPV4 and PCP-IPV6 in this document. [[RFC-Editor:
please update occurrences with the IANA-assigned value.]]</t>
</section>
<section anchor="iana_port" title="PCP Port Number">
<t>IANA shall assign a UDP port number for PCP communication,
preferably from the well-known port range (0-1023). This is denoted as
PCP-PORT in this document.</t>
</section>
<section anchor="iana_opcodes" title="PCP OpCodes">
<t>Create a new protocol registry for PCP OpCodes populated with the
following values:</t>
<figure>
<artwork><![CDATA[value mnemonic
----- --------
0 PIN44
1 PIN64
2 PIN46
3 PIN66
128 ERROR (only valid in responses)
]]></artwork>
</figure>
<t></t>
<t>New OpCodes can be created via <xref target="RFC2434">Standards
Action</xref>.</t>
</section>
<section anchor="iana_error_codes" title="PCP Error Codes">
<t>IANA shall create a new registry for PCP error codes, numbered
0-255, initially populated with the error codes in <xref
target="pcp_error_code_table"></xref>.</t>
<t>New Error Codes can be created via <xref
target="RFC2434">Specification Required</xref>.</t>
</section>
<section anchor="iana_ie" title="PCP Information Elements">
<t>IANA shall create a new registry for PCP Information Elements,
numbered 0-65535 with associated mnemonic.</t>
<t>New information elements in the range 0-32768 can be created via
<xref target="RFC2434">Standards Action</xref>, new information
elements in the range 32769-64511 can be created with <xref
target="RFC2434">Expert Review</xref>, and the range 64512-65535 is
for <xref target="RFC2434"> Private Use</xref>.</t>
</section>
</section>
<section title="Acknowledgments">
<t>Thanks to Francis Dupont, Alain Durand, and C. Jacquenet for their
comments and review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2434"?>
<?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'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2608'?>
<?rfc include='reference.RFC.2475'?>
<?rfc include='reference.I-D.miles-behave-l2nat'?>
<?rfc include='reference.I-D.ietf-v6ops-cpe-simple-security'?>
<?rfc include='reference.I-D.bpw-softwire-pcp-dhcp'?>
<?rfc include='reference.I-D.ietf-behave-address-format'?>
<?rfc include='reference.I-D.bpw-softwire-upnp-pcp-interworking'?>
<?rfc include='reference.I-D.ford-shared-addressing-issues'?>
<?rfc include='reference.I-D.bpw-softwire-pcp-flow-examples'?>
<?rfc include='reference.I-D.nishitani-cgn'?>
</references>
<section anchor="discovery_analysis"
title="Analysis of Techniques to Discover PCP Server">
<t><list style="empty">
<t>[[Note: This Appendix will be removed in a later version of this
document. It is included here for reference and discussion
purposes.]]</t>
</list>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 CGN device, load-based
dimensioning, load-balancing, etc.) would require to update the
zone configuration. This would be a hurdle for the flexibility
of the operational networks. Adherence to DNS is not encouraged
and means which allows for more flexibility are to be
promoted.</t>
<t>Therefore, this mechanism is not recommended.</t>
</list></t>
<t>New DHCPv6/DHCP option and/or a RA option to convey an FQDN of a
PCP Server.<list style="empty">
<t>Analysis: Since DS-Lite and NAT64/NAT46 are likely to be
deployed in provider-provisioned environments, DHCP (both DHCPv6
and IPv4 DHCP) is convenient to provision the address/FQDN of
the PCP Server.</t>
</list></t>
</list></t>
</section>
<section anchor="sec_dscp_ie" title="DSCP Informational Element">
<t><list style="empty">
<t>[[Note: This Appendix may be moved into the main body of the PCP
specification, or may be moved into a separate document. It is
currently here to show how an Informational Element can extend the
functionality of PCP.]]</t>
</list>PCP controls NAT and firewall devices which are typically at a
network boundary where it is useful to map between different DSCP
values. This section describes an extension to the PCP base protocol to
allow the PCP client to request special handling of Differentiated
Services (<xref target="RFC2475">DSCP</xref>).</t>
<t>Two scenarios are supported: all packets in a certain direction are
remarked to a specific DSCP value (no matter their original DSCP value),
and where certain DSCP values are remarked to other certain DSCP values.
In eiher situation, packets are forwarded (that is, packets not matching
the indicated DSCP values are not dropped).</t>
<t>If the PCP server supports the DSCP Informational Element, and it
successfully installs the configuration into the controlled NAT or
firewall device, it MUST include the same DSCP Informational Element in
the PCP response. In other cases it does not include hte DSCP IE in the
response, but still performs the pinhole control operation specified by
the PCP message.</t>
<t>The DSCP IE has the following syntax. The value of the DSCP_IE_CODE
is to be assigned.</t>
<figure align="center" anchor="fig-dscp-wildcard"
title="Informational Element header">
<preamble></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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP_IE_CODE | IE-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:DIR |inside DSCP| out DSCP | RESERVED (must be 0) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where DIR is encoded so its left bit indicate wildcard (1=wildcard)
and its right bit indicates the direction of the mapping (0=inside to
outside, 1=outside to inside). Thus, 00 indicates a mapping of 'inside
DSCP' to 'outside DSCP' for packets from the inside to the outside, and
11 indicates a mapping of any DSCP value to 'insside DSCP' for packets
from the outside to the inside.</t>
<t>To establish multiple DSCP mappings the fields DIR, inside DSCP, out
DSCP, and RESERVED MAY be repeated. If both wildcards and specific
mappings are provided, the behavior is not defined. [[do we want to
define behavior?]]</t>
<section title="Generation and Processing the DSCP IE">
<t>A PCP client MAY include the DSCP IE in any PINHOLE-REQUEST
message. Multiple DSCP IEs MAY be included.</t>
<t>When the PCP server processes the DSCP IE, the PCP server instructs
the PCP-controlled device to install the indicated DSCP mappings. If
all of the mappings are installed successfully, the DSCP IE is echoed
back to the PCP client exactly as it appeared in the request. If all
of mappings could not be installed successfully, the DSCP IE that is
echoed contains only those DSCP mappings that were successfully
installed (which might also mean none were successfully
installed).</t>
<t>Upon receipt of the PCP response, the PCP client knows all the
requested DSCP mappings were successfully installed if the IE-length
is the same as it sent. If the IE-length was shorter, it indicates
some of the mappings were not successfully installed.</t>
</section>
<section title="DSCP Policy">
<t>A Service Provider MAY allow its customers to configure their DSCP
marking policies in an upstream device. Distinct DSCP marking policies
can be implemented in th internal and external side of the controlled
device. A PCP Client MAY issue a PCP Map Create Request indicating its
internal DS code point and the external DSCP value.</t>
<t>PCP allows also to instruct forwarding policies only for packets
marked with a given DSCP value.</t>
<t>Note that a Service Provider may not support such feature and adopt
a transparent scheme to QoS policy enforcement, that is, not
controllable by subscribers. Generic QoS enforcement policies can be
enforced for all customers: such as leave DSCP field values
unchanged.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:32:33 |