Middleboxes such as NATs and firewalls have seen significant deployment in residential and enterprise networks for years. Applications have adapted to such environments. A first family of solutions involves some form of static configuration on the middlebox to perform port opening and/or port forwarding. Another family of solutions works indirectly, using external services to help the establishment of connections and work around the NAT. STUN (RFC 5389) and TURN (RFC 5766) are examples of such solutions. A third family of solutions include protocols that work directly with the middlebox to dynamically open up ports. Universal Plug and Play Internet Gateway Device (UPnP-IGD) and NAT Port Mapping Protocol (NAT-PMP) are examples of such solutions.
IPv4 address exhaustion is now forcing ISPs to deploy carrier-grade NAT devices in their network. Those devices could operate either in addition to or instead of an existing NAT device. An example of the former case is a double NAT configuration and an example of the latter case is the application of Dual Stack Lite (DS-Lite) in a network. These deployments will break a fundamental assumption made by protocols, such UPnP or NAT-PMP, that the NAT is located on the same link as the host running the client application. As a result, such applications may break in the presence of a carrier grade NAT.
The PCP working group is chartered to standardize a client/server Port Control Protocol (PCP) to enable an explicit dialog with a middlebox such as a NAT or a firewall to open up and/or forward TCP or UDP port, regardless of the location of that middlebox. A PCP client can be used by applications to directly dialog with the middlebox running a PCP server. It can also be used by a home gateways on behalf of applications. This eases the deployment of PCP in situations where applications have already changed to support the APIs necessary for communicating with UPnP-IGD or NAT-PMP. Those applications only work today when the home gateway gets a public address, but may no longer work in situations where the gateway is behind another NAT. Home gateways could use PCP to translate and relay those UPnP and NAP-PMP messages to the PCP server, thus allowing such applications to continue working as they do today.
The functionality that enables the control of IPv4 middleboxes such as NAT devices or firewalls can also be useful in IPv6 context, to control IPv6 functionality in firewalls. As such, PCP will be defined for both IPv4 and IPv6.
The discovery PCP servers, using classic methods such as DHCP options, is in scope for the PCP working group. The working group will also ensure that the protocol has the necessary security mechanisms. The IETF will make no changes to either NAT-PMP or UPnP-IGP protocols, and they will be used only as is.
Deliverables: - PCP protocol description and terminology document - PCP service discovery document - PCP relay of UPnP document - PCP relay of NAT-PMP document
First WG draft on PCP protocol description
First WG draft on PCP service discovery
First WG draft on UPnP relay
First WG draft on NAT-PMP relay
Send PCP protocol description to IESG for publication as Proposed Standard
Send PCP service discovery to IESG for publication as Proposed Standard
Send UPnP relay to IESG for publication as Proposed Standard
Send NAT-PMP relay to IESG for publication as Proposed Standard
Send PCP Description option to IESG as a proposed Standard
Send Learn NAT64 PREFIX64s using PCP to IESG as proposed Standard
Send Port Control Protocol (PCP) Proxy Function to IESG as proposed Standard