IETF 82 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Port Control Protocol (pcp) (WG)

Minutes  | Audio Archives  |  Jabber Logs  |  Mailing List Archives

Additional information is available at tools.ietf.org/wg/pcp

Chair(s):

Internet Area Director(s):

Internet Area Advisor:

Meeting Slides

Internet-Drafts:

No Request For Comments

Charter (as of 2011-12-09)

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

Goals and Milestones:

Oct 2010  First WG draft on PCP protocol description
Dec 2010  First WG draft on PCP service discovery
Feb 2011  First WG draft on UPnP relay
Feb 2011  First WG draft on NAT-PMP relay
May 2011  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

Internet SocietyAMSHome - Tools Team - Datatracker - Web Site Usage Statistics - IASA - IAB - RFC Editor - IANA - IRTF - IETF Trust - ISOC - Store - Contact Us
Secretariat services provided by Association Management Solutions, LLC (AMS).
Please send problem reports to: ietf-action@ietf.org.