* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Pcp Status Pages

Port Control Protocol (Concluded WG)
Int Area: Suresh Krishnan, Terry Manderson | 2010-Aug-31 — 2017-Nov-12 

2017-10-06 charter

Port Control Protocol (pcp)


 Current Status: Active

     Dave Thaler <dthaler@microsoft.com>
     Reinaldo Penno <repenno@cisco.com>

 Internet Area Directors:
     Suresh Krishnan <suresh@kaloom.com>
     Terry Manderson <terry.manderson@icann.org>

 Internet Area Advisor:
     Suresh Krishnan <suresh@kaloom.com>

 Mailing Lists:
     General Discussion: pcp@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/pcp
     Archive:            https://mailarchive.ietf.org/arch/browse/pcp/

Description of Working Group:

    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.

    - PCP protocol description and terminology document
    - PCP service discovery document
    - PCP relay of UPnP document
    - PCP relay of NAT-PMP document

Goals and Milestones:
  Done     - First WG draft on PCP protocol description
  Done     - First WG draft on PCP service discovery
  Done     - First WG draft on UPnP relay
  Done     - First WG draft on NAT-PMP relay
  Done     - Send PCP protocol description to IESG for publication as Proposed Standard
  May 2011 - Send PCP service discovery to IESG for publication as Proposed Standard
  Oct 2011 - Send UPnP relay to IESG for publication as Proposed Standard
  Oct 2011 - Send NAT-PMP relay to IESG for publication as Proposed Standard
  Oct 2013 - Send PCP Description option to IESG as a proposed Standard
  Oct 2013 - Send Learn NAT64 PREFIX64s using PCP to IESG as proposed Standard
  Dec 2013 - Send Port Control Protocol (PCP) Proxy Function to IESG as proposed Standard

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/pcp/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -