Port Control Protocol (PCP)
Deployment ModelsFrance TelecomRennes35000Francemohamed.boucadair@orange.comPCP Working GroupThis document lists a set of Port Control Protocol (PCP) deployment
models.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 RFC 2119.This document lists a set of PCP
deployment models.This document makes use of the following terms:PCP client denotes a functional element responsible for issuing
PCP requests to a PCP server. Refer to .PCP server denotes a functional element that receives and
processes PCP requests from a PCP client. A PCP server can be
co-located with or be separated from the function (e.g., NAT,
Firewall) it controls. Refer to .PCP proxy refers to a functional elements that is responsible for
relaying PCP requests received from PCP client to upstream PCP
servers.This model assumes PCP is enabled in the LAN side to control
functions located in the CPE. The PCP server is reachable with the IP
address of the private-faced interface of the CPE. Typical functions
that can be controlled by PCP in this model are NAT and firewall.PCP client can be configured with their PCP server using DHCP for
instance . If no PCP server is
configured, PCP clients assume their default gateway is the PCP
server.This model applies for both residential or corporate markets. This model assumes a customer site is connected to the same ISP's
network. One or multiple PCP servers are deployed in the ISP's domain;
each of them manage distinct set of functions. In the example shown in
the following figure:NAT64 device are used to interwork
with IPv4-only devices.NPTv6 function is used for
engineering motivation internal to the ISP.The use of NAT64 and NPTv6 functions is for illustration purposes;
other functions can be enabled in the ISP's network side.PCP clients located behind the CPE, must discover both the external
IPv4 address and port numbers assigned by the NAT64 and the external
IPv6 address assigned by the NPTv6. These external addresses are used
for example in referrals to indicate to remote peers both the IPv4
address and IPv6 address to reach an internal server deployed in an
IPv6-only domain.The use of a PCP anycast address () is not recommended for this
deployment case because two state entries must be created in both NAT64
and NPTv6. Explicit means such as must be used instead to provision IP
addresses of available PCP servers. may be used to provision the
IP addresses of these PCP servers, or the CPE must embed a PCP proxy
function that must follow to contact all PCP
servers.In order to hide PCP servers deployed within an administrative
domain, an administrative entity may decide to deploy one or more PCP
proxies in front of PCP
clients. A PCP proxy is responsible for relaying PCP requests to the
appropriate PCP server(s):In order to prevent single failure scenarios, multiple PCP
proxies can be hosted within an administrative domain. A PCP proxy can be configured with one or multiple PCP
servers.A PCP proxy can be configured with the logic indicating how it
should proceed to contact upstream PCP servers. The PCP proxy will
then follow the procedure defined in to contact those
PCP servers.Internal PCP clients may be configured with the IP address(es)
of the appropriate PCP proxy (e.g., ).If all PCP proxies interact with the same PCP server(s),
the same IP address can be provisioned to PCP clients.If PCP proxies do not interact with the same set of PCP
server(s), appropriate IP address(es) are to be returned to
each requesting PCP client.The PCP proxy should not use the PCP anycast address () if available PCP servers do not
manage the same PCP-controlled device. Deterministic means should be
used instead.PCP client should not use the PCP anycast address to reach a PCP
proxy if deployed PCP proxies do not interact with the same PCP
servers. Explicit provisioning means should be preferred.If the PCP proxy is reachable using the PCP anycast address,
available PCP servers must not be reachable using the same PCP anycast
address.Another deployment model to hide the identity of back-end PCP
servers is to rely on HTTP to invoke the PCP service. This model can
be used by operators to accommodate cases where a PCP client
implementation is not available at the customer side (e.g., unmanaged
CPE model).The deployment model relies on the following:An HTTP administration based interface (e.g. GUI) is provided
to the user to manage its flow-based forwarding rules.The HTTP user interface can be part of a CPE management
interface or be provided as part of the customer care portal.The HTTP server embeds also a PCP client.HTTP requests are translated into appropriate PCP requests in
order to install the requested state. The PCP client uses THIRD_PARTY option.The PCP client should be configured with the PCP server that
controls the on-path PCP-controlled device for that user.One or multiple PCP servers can be deployed. The logic of
contacting these PCP servers may be explicitly configured to the
PCP client. If not, the procedure defined in is used to contact
those PCP servers.The use of a well-known address () to reach internal PCP
servers might not be convenient if all PCP servers do not manage
the same set of mapping entries (e.g., NAT64, NPTv6, IPv6
firewall, etc.).This model assumes the PCP server is not co-located with the
PCP-controlled device. Moreover:In order to prevent single failure scenarios, multiple PCP
servers can be hosted within an administrative domain.A PCP server can control one or many PCP-controlled devices.Multiple PCP servers can be enabled; each of them manages a set
of PCP-controlled devices.Internal PCP clients are configured with the IP address(es) of
the appropriate PCP server.If all PCP servers interact with the same PCP-controlled
devices, the same PCP server's IP address can be provisioned to
PCP clients.If PCP servers do not interact with the same set of
PCP-controlled devices, PCP server IP address(es) are to be
returned to each requesting PCP client.Note, PCP is not used between the PCP server and the
PCP-controlled device. Other protocols (e.g., H.248) can be used for
that purpose.This model assumes cascaded PCP-controlled devices are deployed. A
typical example is provided below.This model requires a PCP proxy function be deployed in intermediate
PCP-controlled devices:The PCP client is not aware of the presence of more than one
level of PCP servers.Each intermediate PCP proxy must contact the appropriate next hop
PCP server(s).The use of PCP anaycast address may not be appropriate when the
PCP server is co-located with the PCP-controlled device.This model assumes no PCP-controlled function is located in the CPE
(e.g., DS-Lite case). The upstream PCP server is located in the ISP's
network. The PCP server can be deduced from other provisioning
parameters (e.g., use the IP address of the AFTR as PCP server);
otherwise the IP address (s) must be discovered by other means.The use of an anycast-based model may not be convenient in some
cases (e.g., multiple PCP-controlled devices are deployed; each of
them manage a subset of services and state).This model is specified in . The
interworking function must be provisioned with the IP address(es) of
remote PCP server(s).A typical example of this model is shown in the following figure:Internal PCP clients can interact with one single PCP server.A typical example of this model is shown in the following figure:The PCP client must interact with all PCP servers; otherwise
complications arise to communicate with remote peers. The procedure
defined in is used
to contact those servers.The use of anycast-based model () might induce failures when
communicating with external peers (e.g., incoming packets will be
dropped by one of the firewalls).PCP-related security considerations are discussed in .This document does not require any action from IANA.