One document matched: draft-ietf-pcp-proxy-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-pcp-proxy-07" ipr="trust200902">
<front>
<title abbrev="PCP Proxy">Port Control Protocol (PCP) Proxy
Function</title>
<author fullname="Simon Perreault" initials="S." role="editor"
surname="Perreault">
<organization>Viagenie</organization>
<address>
<postal>
<street>246 Aberdeen</street>
<city>Quebec</city>
<region>QC</region>
<code>G1R 2E1</code>
<country>Canada</country>
</postal>
<phone>+1 418 656 9254</phone>
<email>simon.perreault@viagenie.ca</email>
<uri>http://viagenie.ca</uri>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<code></code>
<country>USA</country>
</postal>
<email>repenno@cisco.com</email>
</address>
</author>
<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="Stuart Cheshire" initials="S." surname="Cheshire">
<organization abbrev="Apple">Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 408 974 3207</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<date />
<abstract>
<t>This document specifies a new PCP functional element denoted as a PCP
Proxy. The PCP Proxy relays PCP requests received from PCP clients to
upstream PCP server(s). A typical deployment usage of this function is
to help establish successful PCP communications for PCP clients that can
not be configured with the address of a PCP server located more than one
hop away.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><?rfc subcompact="no" ?>This document defines a new PCP <xref
target="RFC6887"></xref> functional element: the PCP Proxy. As shown in
<xref target="Reference_Architecture"></xref>, the PCP proxy is
logically equivalent to a PCP client back-to-back with a PCP server. The
"glue" between the two is what is specified in this document. Other than
that "glue", the server and the client behave exactly like their regular
counterparts.</t>
<t><figure align="center" anchor="Reference_Architecture"
title="Reference Architecture">
<artwork><![CDATA[
.................
+------+ : +------+------+ : +------+
|Client|-------:-|Server|Client|-:----|Server|
+------+ : +------+------+ : +------+
: Proxy :
.................
]]></artwork>
</figure></t>
<section title="Use Case: the NAT Cascade">
<t>In today's world, with public routable IPv4 addresses becoming less
readily available, it is increasingly common for customers to receive
a private address from their Internet Service Provider (ISP), and the
ISP uses a NAT gateway of its own to translate those packets before
sending them out onto the public Internet. This means that there is
likely to be more than one NAT on the path between client machines and
the public Internet: <list style="symbols">
<t>If a residential customer receives a translated address from
their ISP, and then installs their own residential NAT gateway to
share that address between multiple client devices in their home,
then there are at least two NAT gateways on the path between
client devices and the public Internet.</t>
<t>If a mobile phone customer receives a translated address from
their mobile phone carrier, and uses "Personal Hotspot" or
"Internet Sharing" software on their mobile phone to make Wireless
LAN (WLAN) Internet access available to other client devices, then
there are at least two NAT gateways on the path between those
client devices and the public Internet.</t>
<t>If a hotel guest connects a portable WLAN gateway to their
hotel room Ethernet port to share their room's Internet connection
between their phone and their laptop computer, then packets from
the client devices may traverse the hotel guest's portable NAT,
the hotel network's NAT, and the ISP's NAT before reaching the
public Internet.</t>
</list></t>
<t>While it is possible, in theory, that client devices could somehow
discover all the NATs on the path, and communicate with each one
separately using Port Control Protocol <xref target="RFC6887"></xref>,
in practice it's not clear how client devices would reliably learn
this information. Since the NAT gateways are installed and operated by
different individuals and organizations, no single entity has
knowledge of all the NATs on the path. Also, even if a client device
could somehow know all the NATs on the path, requiring a client device
to communicate separately with all of them imposes unreasonable
complexity on PCP clients, many of which are expected to be simple
low-cost devices.</t>
<t>In addition, this goes against the spirit of NAT gateways. The main
purpose of a NAT gateway is to make multiple downstream client devices
making outgoing TCP connections to appear, from the point of view of
everything upstream of the NAT gateway, to be a single client device
making outgoing TCP connections. In the same spirit, it makes sense
for a PCP-capable NAT gateway to make multiple downstream client
devices requesting port mappings to appear, from the point of view of
everything upstream of the NAT gateway, to be a single client device
requesting port mappings.</t>
</section>
<section title="Use Case: the PCP Relay">
<t>Another envisioned use case of the PCP Proxy is to help establish
successful PCP communications for PCP clients that can not be
configured with the address of a PCP server located more than one hop
away. A PCP Proxy can be for instance embedded in a CPE (Customer
Premises Equipment) while the PCP server is located in a network
operated by an ISP. This is illustrated in <xref
target="pcp_relay"></xref>.</t>
<figure align="center" anchor="pcp_relay" title="PCP Relay Use Case">
<artwork><![CDATA[
|
+------+ |
|Client|--+
+------+ | +-----+ +------+
+--|Proxy|--------<ISP network>----------|Server|
+------+ | +-----+ +------+
|Client|--+ CPE
+------+ |
|
LAN
]]></artwork>
</figure>
<t>This works because the proxy's server side is listening on the
address used as a default gateway by the clients. The clients use that
address as a fallback when discovering the PCP server's address. The
proxy picks up the requests and forwards them upstream to the ISP's
PCP server, with whose address it has been provisioned through regular
PCP client provisioning means.</t>
<t>This particular use case assumes that provisioning the server's
address on the CPE is feasible while doing it on the clients in the
LAN is not, which is what makes the PCP proxy valuable.</t>
<t>Note that <xref target="I-D.ietf-pcp-anycast"></xref> documents an
alternate solution to the PCP proxy. Nevertheless, as discussed in
<xref target="I-D.boucadair-pcp-deployment-cases"></xref>, the anycast
solution may be problematic when multiple PCP servers are to be
contacted.</t>
</section>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>Where this document uses the terms "upstream" and "downstream", the
term "upstream" refers to the direction outbound packets travel towards
the public Internet, and the term "downstream" refers to the direction
inbound packets travel from the public Internet towards client systems.
Typically when a home user views a web site, their computer sends an
outbound TCP SYN packet upstream towards the public Internet, and an
inbound downstream TCP SYN ACK reply comes back from the public
Internet.</t>
</section>
<section title="Operation of the PCP Proxy">
<t>Upon receipt of a PCP mapping-creation request from a downstream PCP
client, a PCP proxy first examines its local mapping table to see if it
already has a valid active mapping matching the Internal Address and
Internal Port (and in the case of PEER requests, remote peer) given in
the request.</t>
<t>If the PCP proxy does not already have a valid active mapping for
this mapping-creation request, then it allocates an available port on
its external interface. We assume for the sake of this description that
the address of its external interface is itself a private address,
subject to translation by an upstream NAT. The PCP proxy then constructs
an appropriate corresponding PCP request of its own (described below),
and sends it to its upstream NAT, and the newly-created local mapping is
considered temporary until a confirming reply is received from the
upstream PCP server.</t>
<t>If the PCP proxy does already have a valid active mapping for this
mapping-creation request, and the lifetime remaining on the local
mapping is at least 3/4 of the lifetime requested by the PCP client,
then the PCP proxy SHOULD send an immediate reply giving the outermost
External Address and Port (previously learned using PCP recursively, as
described below), and the actual lifetime remaining for this mapping. If
the lifetime remaining on the local mapping is less than 3/4 of the
lifetime requested by the PCP client, then the PCP proxy MUST generate
an upstream request as described below.</t>
<t>For mapping-deletion requests (Lifetime = 0), the local mapping, if
any, is deleted, and then (regardless of whether a local mapping
existed) a corresponding upstream request is generated.</t>
<t>The PCP proxy knows the destination IP address for its upstream PCP
request using the same means that are available for provisioning a PCP
client. In particular, the PCP proxy MUST follow the procedure defined
in Section 8.1 of <xref target="RFC6887"></xref> to discover its PCP
server. This does not preclude other means from being used in
addition.</t>
<t>In the upstream PCP request: <list style="symbols">
<t>The PCP Client's IP Address and Internal Port are the PCP proxy's
own external address and port just allocated for this mapping.</t>
<t>The Suggested External Address and Port in the upstream PCP
request SHOULD be copied from the original PCP request.</t>
<t>The Requested Lifetime is as requested by the client if it falls
within the acceptable range for this PCP server; otherwise it SHOULD
be capped to appropriate minimum and maximum values configured for
this PCP server.</t>
<t>The Mapping Nonce is copied from the original PCP request.</t>
<t>For PEER requests, the Remote Peer IP Address and Port are copied
from the original PCP request.</t>
</list></t>
<t>Upon receipt of a PCP reply giving the outermost (i.e., publicly
routable) External Address, Port and Lifetime, the PCP proxy records
this information in its own mapping table and relays the information to
the requesting downstream PCP client in a PCP reply. The PCP proxy
therefore records, among other things, the following information in its
mapping table: <list style="symbols">
<t>Client's Internal Address and Port.</t>
<t>External Address and Port allocated by this PCP proxy.</t>
<t>Outermost External Address and Port allocated by the upstream PCP
server.</t>
<t>Mapping lifetime (also dictated by the upstream PCP server).</t>
<t>Mapping nonce.</t>
</list></t>
<t>In the downstream PCP reply: <list style="symbols">
<t>The Lifetime is as granted by the upstream PCP server, or less,
if the granted lifetime exceeds the maximum lifetime this PCP server
is configured to grant. If the downstream Lifetime is more than the
Lifetime granted by the upstream PCP server (which is NOT
RECOMMENDED) then this PCP proxy MUST take responsibility for
renewing the upstream mapping itself.</t>
<t>The Epoch Time is this PCP proxy's Epoch Time, not the Epoch Time
of the upstream PCP server. Each PCP server has its own independent
Epoch Time. However, if the Epoch Time received from the upstream
PCP server indicates a loss of state in that PCP server, the PCP
proxy can either recreate the lost mappings itself, or it can reset
its own Epoch Time to cause its downstream clients to perform such
state repairs themselves. A PCP proxy MUST NOT simply copy the
upstream PCP server's Epoch Time into its downstream PCP replies,
since if it suffers its own state loss it needs the ability to
communicate that state loss to clients. Thus each PCP server has its
own independent Epoch Time. However, as a convenience, a downstream
PCP proxy may simply choose to reset its own Epoch Time whenever it
detects that its upstream PCP server has lost state. Thus, in this
case, the PCP proxy's Epoch Time always resets whenever its upstream
PCP server loses state; it may also reset at other times too.</t>
<t>The Mapping Nonce is copied from the reply received from the
upstream PCP server.</t>
<t>The Assigned External Port and Assigned External IP Address are
copied from the reply received from the upstream PCP server (i.e.,
they are the outermost External IP Address and Port, not the
locally-assigned external address and port.)</t>
<t>For PEER requests, the Remote Peer IP Address and Port are copied
from the reply received from the upstream PCP server.</t>
</list></t>
<section title="Optimized Hairpin Routing">
<t>A PCP proxy SHOULD implement Optimized Hairpin Routing. What this
means is the following: <list style="symbols">
<t>If a PCP proxy observes an outgoing packet arriving on its
internal interface that is addressed to an External Address and
Port appearing in the NAT gateway's own mapping table, then the
NAT gateway SHOULD (after creating a new outbound mapping if one
does not already exist) rewrite the packet appropriately and
deliver it to the internal client currently allocated that
External Address and Port.</t>
<t>If a PCP proxy observes an outgoing packet arriving on its
internal interface which is addressed to an Outermost External
Address and Port appearing in the NAT gateway's own mapping table,
then the NAT gateway SHOULD do likewise: create a new outbound
mapping if one does not already exist, and then rewrite the packet
appropriately and deliver it to the internal client currently
allocated that Outermost External Address and Port. This is not
necessary for successful communication, but for efficiency.
Without this Optimized Hairpin Routing, the packet will be
delivered all the way to the outermost NAT gateway, which will
then perform standard hairpin translation and send it back. Using
knowledge of the Outermost External Address and Port, this
rewriting can be anticipated and performed locally, which will
typically offer higher throughput and lower latency than sending
it all the way to the outermost NAT gateway and back.</t>
</list></t>
</section>
<section title="Termination of Recursion">
<t>Any recursive algorithm needs a mechanism to terminate the
recursion at the appropriate point. This termination of recursion can
be achieved in a variety of ways. The following (non exhaustive)
examples are provided for illustration purposes: <list style="symbols">
<t>An ISP's PCP-controlled gateway (that may embed a NAT, firewall
or any function that can be controlled with PCP) could be
configured to know that it is the outermost PCP-controlled
gateway, and consequently does not need to relay PCP requests
upstream. Typically, it may be the case that many Carrier Grade
NATs and/or firewalls of the kind used by ISPs may simply not
implement Recursive PCP, thereby naturally terminating the
recursion at that point.</t>
<t>A PCP-controlled gateway could determine automatically that if
its external address is not one of the known private addresses
<xref target="RFC1918"></xref><xref target="RFC6598"></xref>, then
its external address is a public routable IP address, and
consequently it does not need to relay PCP requests upstream.</t>
<t>Recursion may be terminated if there is no explicit list of PCP
servers configured to the PCP Proxy (e.g., <xref
target="RFC7291"></xref>) or if its default router is not
responsive to PCP requests.</t>
<t>Recursion may also be terminated if the upstream PCP-controlled
device does not embed a PCP Proxy.</t>
</list></t>
</section>
<section anchor="third_party"
title="Source Address for PCP Requests Sent Upstream">
<t>As with a regular PCP server, the PCP-controlled device can be a
NAT, a firewall, or even some sort of hybrid. In particular, a PCP
proxy that simply relays all requests upstream can be thought of as
the degenerate case of a PCP server controlling a wide-open firewall
back-to-back with a regular PCP client.</t>
<t>One important property of the PCP-controlled device will affect the
PCP proxy's behaviour: when the proxy's server part instructs the
device to create a mapping, that mapping's external address may or may
not be one that belongs to the proxy node. <list style="symbols">
<t>When the mapping's external address belongs to the proxy node,
as would presumably be the case for a NAT, then the proxy's client
side sends out an upstream PCP request using the mapping's
external IP address as source.</t>
<t>When the mapping's external address does not belong to the
proxy node, as would presumably be the case for a firewall, then
the proxy's client side needs to install upstream mappings on
behalf of its downstream clients. To do this, it MUST insert a
THIRD_PARTY Option in its upstream PCP request carrying the
mapping's external address.</t>
</list></t>
<t>Note that hybrid PCP-controlled devices may create NAT-like
mappings in some circumstances and firewall-like mappings in others. A
proxy controlling such a device would adjust its behavior dynamically
depending on the kind of mapping created.</t>
</section>
<section title="Unknown OpCodes and Options">
<section anchor="nonat"
title="No NAT is Co-located with the PCP Proxy">
<t>When no NAT is co-located with the PCP Proxy, the port numbers
included in received PCP messages (from the PCP server or PCP
client(s)) are not altered by the PCP Proxy. The PCP Proxy relays to
the PCP server unknown Options and OpCodes because there is no
reachability failure risk.</t>
</section>
<section anchor="embedded_NAT"
title="PCP Proxy Co-located with a NAT Function">
<t>By default, the proxy MUST relay unknown OpCodes and
mandatory-to-process unknown Options. Rejecting unknown Options and
OpCodes has the drawback of preventing a PCP client to make use of
new capabilities offered by the PCP server but not supported by the
PCP Proxy even if no IP address and/or port is included in the
Option/OpCode.</t>
<t>Because PCP messages with an unknown OpCode or
mandatory-to-process unknown Options can carry a hidden internal
address or internal port that will not be translated, a PCP Proxy
MUST be configurable to disable relaying unknown OpCodes and
mandatory-to-process unknown Options. If the PCP Proxy is configured
to disable relaying unknown OpCodes and mandatory-to-process unknown
Options, the PCP Proxy MUST behave as follows:</t>
<t><list style="symbols">
<t>a PCP Proxy co-located with a NAT MUST reject by an
UNSUPP_OPCODE error response a received request with an unknown
OpCode.</t>
<t>a PCP Proxy co-located with a NAT MUST reject by an
UNSUPP_OPTION error response a received request with a
mandatory-to-process unknown Option.</t>
</list></t>
</section>
</section>
<section title="Mapping Repair">
<t>ANNOUNCE requests received from PCP clients are handled locally; as
such these requests MUST NOT be relayed to the provisioned PCP
server.</t>
<t>Upon receipt of an unsolicited ANNOUNCE response from a PCP server,
the PCP Proxy proceeds to renew the mappings and checks whether there
are changes compared to a local cache if it is maintained by the PCP
Proxy. If no change is detected, no unsolicited ANNOUNCE is generated
towards PCP clients. If a change is detected, the PCP Proxy MUST
generate unsolicited ANNOUNCE message(s) to appropriate PCP clients.
If the PCP Proxy does not maintain a local cache for the mappings,
unsolicited multicast ANNOUNCE messages are sent to PCP clients.</t>
<t>Upon change of its external IP address, the PCP Proxy SHOULD renew
the mappings it maintained. If the PCP server assigns a different
external port, the PCP Proxy SHOULD follow the mapping repair
procedure defined in <xref target="RFC6887"></xref>. This can be
achieved only if a full state table is maintained by the PCP
Proxy.</t>
</section>
<section title="Multiple PCP Servers">
<t>A PCP Proxy MAY handle multiple PCP servers at the same time. Each
PCP server is associated with its own epoch value. PCP clients are not
aware of the presence of multiple PCP servers.</t>
<t>According to <xref target="RFC7488"></xref>, if several PCP Names
are configured to the PCP Proxy, it will contact in parallel all these
PCP servers.</t>
<t>In some contexts (e.g., PCP-controlled CGNs), the PCP Proxy MAY
load balance the PCP clients among available PCP servers. The PCP
Proxy MUST ensure requests of a given PCP client are relayed to the
same PCP server.</t>
<t>The PCP Proxy MAY rely on some fields (e.g., Zone ID <xref
target="I-D.penno-pcp-zones"></xref>) in the PCP request to redirect
the request to a given PCP server.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The PCP Proxy MUST follow the security considerations elaborated in
<xref target="RFC6887"></xref> for both the client and server side.</t>
<t><xref target="third_party"></xref> specifies the cases where a
THIRD_PARTY option is inserted by the PCP Proxy. In those cases, means
to prevent a malicious user from creating mappings on behalf of a third
party must be enabled as discussed in Section 13.1 of <xref
target="RFC6887"></xref>. In particular, THIRD_PARTY options MUST NOT be
enabled unless the network on which the PCP messages are to be sent is
fully trusted. For example if access control lists (ACLs) are installed
on the PCP Proxy, PCP server, and the network between them, so those
ACLs allow only communications from a trusted PCP Proxy to the PCP
server.</t>
<t>A received request carrying an unknown OpCode or Option SHOULD be
dropped (or in the case of an unknown Option which is not
mandatory-to-process the Option SHOULD be removed) if it is not
compatible with security controls provisioned to the PCP Proxy.</t>
<t>The device embedding the PCP Proxy MAY block PCP requests directly
sent to the PCP server. This can be enforced using access control
lists.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and
comments.</t>
<t>Special thanks to F. Dupont who contributed to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6887"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1918"?>
<?rfc include="reference.RFC.6598"?>
<?rfc include='reference.RFC.7488'?>
<?rfc include='reference.RFC.7291'?>
<?rfc include='reference.I-D.penno-pcp-zones'?>
<?rfc include='reference.I-D.ietf-pcp-anycast'?>
<?rfc include='reference.I-D.boucadair-pcp-deployment-cases'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:19:47 |