Port Control Protocol
charter-ietf-pcp-01

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