One document matched: draft-wing-pcp-design-considerations-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-wing-pcp-design-considerations-00"
ipr="trust200902">
<front>
<title abbrev="PCP Design Considerations">PCP Design
Considerations</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<!--
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>California</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>rpenno@juniper.net</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
-->
<date />
<workgroup>PCP Working Group</workgroup>
<abstract>
<t>This document summarizes changes from NAT-PMP to support the needs of
a large-scale NAT and support IPv6.</t>
<t>This document is for discussion purposes. It is not intended to
be published as an RFC.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t><xref target="I-D.cheshire-nat-pmp">NAT-PMP</xref> is a lightweight,
UDP-based request/response protocol that forms a good basis to obtain
mappings from a NAT. This document describes how NAT-PMP can be extended
to support a large-scale NAT (such as deployed by an ISP, <xref
target="I-D.nishitani-cgn"></xref>), support NAT64, and provide
sufficient support to interwork between <xref target="UPnP-IGD">UPnP
IGD</xref> and PCP.</t>
<t>This document is for discussion purposes. It is not intended to
be published as an RFC.</t>
</section>
<section title="Design Considerations">
<section title="Add IPv6 Support">
<t>Needs to support NAT44, NAPT44, stateless and stateful NAT64,
NAT46, and IPv6 firewall.</t>
</section>
<section title="Open Pinhole for Another Host">
<t>Provide ability for another device, within same home, to open ports
on behalf of another. This functionality also intended to be used by
the operator of the NAT itself (e.g., the ISP) which is accessed by
their technical support staff or is accessed by the end user.</t>
<t>Use 0 as internal IP address to indicate 'this IP SRC address'.</t>
</section>
<section title="Interworking with UPnP IGD">
<t>In UPnP IGD, a 'control point' can request a specific port or can
request a wildcard port, and there is no concept of a mapping
lifetime. This model does not work well with NATs, especially large
scale NATs.</t>
<figure align="center" anchor="igd-interworking-function"
title="UPnP IGD to PCP Interworking Function">
<artwork><![CDATA[
+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +-----+ +--------+
+---| IGD-| |Provider|
| PCP |-------| NAT |--<Internet>
+---| IWF | | |
+-------------+ | +-----+ +--------+
| Local Host |-----+
+-------------+
LAN Side External Side
<======UPnP IGD==========><======PCP=====>
]]></artwork>
</figure>
<section title="Creating a mapping">
<t>The Madatory bit, from draft-wing-softwire-port-control-protocol
is not necessary, and will not be used in PCP. We had a lengthy
discussion on this during our design meetings. The primary benefit
of this bit is to ease interworking between UPnP IGD and PCP. As
most people are aware, UPnP IGD mandates that UPnP IGD gateways
implement the ability for a UPnP 'control point' (the computer
inside the home) to obtain a mapping for a specific port. UPnP IGD
includes optional support for the control point to request 'any'
port, which allows the UPnP IGD gateway to choose the port number.
However, this ability to request 'any' port seems to not be commonly
used by UPnP IGD control points, is not available in the Windows
UPnP API, and appears to also not be commonly implemented in UPnP
IGD gateways (NATs). Thus, most UPnP IGD applications request a
specific port. On a NAT with a lot of activity, such as a large
scale NAT, any specific port number is probably already in use by
another subscriber, so the UPnP IGD model does not work well.</t>
<t>In our experience, UPnP IGD applications or the underlying
library will attempt to try port+1, port+2, and so on. However, we
can't recommend this behavior
[draft-ietf-tsvwg-port-randomization].</t>
<t>Thus, to interwork from UPnP IGD to PCP, our recommendation is
that every UPnP request be forwarded to the PCP server. This works
if the UPnP control point is incrementing the source port number,
and also works if the UPnP control point is randomly choosing the
source port number, and also works if it chooses 'any'. The UPnP
IGD/PCP interworking function would request very short leases (e.g.,
5 seconds) in order to avoid the chatter of a DELETE message
(lifetime=0). Once a port can be allocated, its lifetime is
extended. When interworking with UPnP IGD, the in-home CPE limits
itself to sending one PCP message a second, which ensures there are
only 5 outstanding PCP reserverations at a time; this avoids
consuming all of that subscriber's NAT mappings while trying to find
an available port via the UPnP IGD->PCP interworking
function).</t>
<t><list style="empty">
<t>Note: for this to work successfully, the PCP server (large
NAT) make an attempt to honor the requested-external-port field
in the PCP request.</t>
</list></t>
<figure align="center" anchor="message-flow"
title="Message Flow for UPnP to PCP Interworking">
<preamble>Message flow would be similar to this:</preamble>
<artwork><![CDATA[
UPnP CP in-home CPE PCP server
| | |
|-UPnP:give me port 80->| |
| |-PCP:request port 80------>|
| | with lease=5 seconds |
| |<-PCP:here is port 51389---|
|<-UPnP: unavailable----| |
| | |
|-UPnP:give me port 81->| |
| |-PCP:request port 81------>|
| | with lease=5 seconds |
| |<-PCP:here is port 23831---|
|<-UPnP: unavailable----| |
| | |
... ... ... ...
| | |
|-UPnP:give me port 85->| |
| |-PCP:request port 85------>|
| | with lease=5 seconds |
| |<-PCP:here is port 85------|
| | |
| |-PCP:extend lease,port=85->|
| |<-PCP:ok-------------------|
| | |
|<-UPnP: ok, port 85----| |
| | |
]]></artwork>
</figure>
<t></t>
</section>
<section title="Lifetime Maintenance">
<t>UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP
interworking function is responsible for extending the lifetime of
mappings that are still interesting to the UPnP IGD device. We
recommend the UPnP IGD/PCP function request a port mapping lifetime
equal to the client's remaining DHCP lifetime. Th UPnP IGD/PCP
interworking function is responsible for renewing the PCP lifetime
as necessary. As long as client renews its DHCP lease, the PCP
lifetime should also be extended. For clients not using DHCP, ping,
ARP, or WiFi association can be used to discern liveliness of the
UPnP IGD control point. It is not recommended to attempt to connect
to the TCP or UDP port opened on the control point to determine if
the host still wants to receive packets; the server could be
temporarily down when tested, causing a false negative.</t>
</section>
</section>
<section title="Protocol support">
<t>Only TCP and UDP will be supported. Additional protocols can be
defined later, using the protocol field.</t>
</section>
<section title="Delete all mappings for a host">
<t>PCP will allow deleting all mappings for a host. (This is already
present in NAT-PMP.)</t>
</section>
<section title="Delete all mappings for all hosts in a home">
<t>PCP will allow deleting all mappings for all hosts behind an
in-home CPE, such as DS-Lite's "B4" element. This is to allow flushing
PCP mappings when a subscriber is assigned an IP address belonging to
a previous subscriber.</t>
</section>
<section title="No Reservation of Ports in other protocol">
<t>When a port reservation is made, NAT-PMP currently reserves the
same port in the other transport protocol for the same host. That is,
if a mapping is made for TCP/12345, the port UDP/12345 will be
reserved for a future mapping. This functionality will be removed from
PCP.</t>
<t>If a protocol requires the same mapping for UDP and TCP, it will
need to issue separate requests (with short lifetimes) until it is
assigned the same ports.</t>
</section>
<section title="Consolidate IP request and port request messages">
<t>NAT-PMP currently uses a separate message to obtain the public IP
address and to obtain the port. In PCP, this will be consolidated into
one message so that every port response includes the external address
and lifetime. Once a host has an active PCP-created mapping on one
port, it will get the same external address for all subsequent port
requests.</t>
</section>
<section title="NAT Changing Public Mapping">
<t>Currently, NAT-PMP has a feature where the NAT can alert hosts on
the local LAN if the NAT's public address changed or the NAT rebooted.
This functionality will not be available in the initial functionality
of PCP, but can be provided in a future document.</t>
</section>
<section title="Epoch">
<t>As in NAT-PMP, all NATs will implement epoch. NATs which retain
their state will simply increase the epoch. This reduces
implementation burden to deal with NATs-that-retain-state and
NATs-which-lose-state, and also allows ISPs to renumber the public
side of the NAT (and force epoch back to zero).</t>
</section>
<section title="PCP Server Discovery">
<t>Currently we are considering a new DHCP option which indicates the
PCP server's address, with a fallback to using the default gateway's
address as the PCP server if the DHCP option isn't available.</t>
<t>This requires the default gateway to support PCP -- either by
processing PCP packets (or tunneling them), or by handling the new
DHCP option.</t>
<t>DHCP option is vulnerable to accidental or malicious breakage if
the incorrect PCP server is sent in the DHCP option.</t>
</section>
<section title="Port number">
<t>Re-use the same port as NAT-PMP (5351).</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>Re-use the IANA-assigned port number for NAT-PMP, 5351, changing its
reference to read:</t>
<figure>
<artwork><![CDATA[
pcp 5351/tcp Port Control Protocol (was NAT Port Mapping Protocol)
pcp 5351/udp Port Control Protocol (was NAT Port Mapping Protocol)
# RFCnnnn (this RFC)
]]></artwork>
</figure>
</section>
<!--
<section title="Acknowledgments">
<t>Thanks to Francis Dupont, Alain Durand, and Christian Jacquenet for
their comments and review.</t>
</section>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.I-D.cheshire-nat-pmp'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.nishitani-cgn'?>
<reference anchor="UPnP-IGD"
target="http://www.upnp.org/standardizeddcps/igd.asp">
<front>
<title>Universal Plug and Play Internet Gateway Device</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date year="2000" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:36:44 |