One document matched: draft-bpw-pcp-upnp-igd-interworking-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?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="std" docName="draft-bpw-pcp-upnp-igd-interworking-01"
ipr="trust200902">
<front>
<title abbrev="UPnP IGD-PCP Interworking Function">Universal Plug and Play
(UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP)
Interworking Function</title>
<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>
<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="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="Francis Dupont" initials="F." surname="Dupont">
<organization>ISC</organization>
<address>
<email>Francis.Dupont@fdupont.fr</email>
</address>
</author>
<date day="23" month="December" year="2010" />
<keyword>PCP working group, UPnP, pinhole, PCP, mapping, NAT control,
interworking</keyword>
<abstract>
<t>This document specifies the behavior of the UPnP IGD (Internet
Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP Interworking
Function (IGD-PCP IWF) is required to be embedded in CP routers to allow
for transparent NAT control in environments where UPnP is used in the
LAN side and PCP in the external side of the CP router.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>PCP <xref target="I-D.ietf-pcp-base"></xref> discusses the
implementation of NAT control features that rely upon Carrier Grade NAT
devices such as DS-Lite AFTR <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref> or NAT64 <xref
target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>. Nevertheless, in
environments where UPnP is used in the local network, an interworking
function between UPnP IGD and PCP is required to be embedded in the CP
router (an example is illustrated in <xref
target="iwf_example"></xref>).</t>
<t>Two configurations are considered:<list style="symbols">
<t>No NAT function is embedded in the CP router. This is required
for instance in DS-Lite or NAT64 deployments;</t>
<t>The CP router embeds a NAT function.</t>
</list></t>
<t><figure anchor="iwf_example" title="Flow Example">
<preamble></preamble>
<artwork><![CDATA[ UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddPortMapping | |
|--------------------->| |
| | (2) PCP PINxy Request |
| |-------------------------->|
| | |]]></artwork>
<postamble></postamble>
</figure></t>
<t>The UPnP IGD-PCP Interworking Function (IGD-PCP IWF) maintains a
local mapping table which stores all active mappings instructed by
internal UPnP Control Points. This design choice restricts the amount of
PCP messages to be exchanged with the PCP Server.</t>
<t>Triggers for deactivating the UPnP IGD-PCP Interworking Function from
the CP router and relying on a PCP-only mode are out of scope of this
document.</t>
<t>In the remaining, PINxy refers to one of the PIN44, PIN46, PING64 and
PIN66 PCP OpCodes defined in <xref
target="I-D.ietf-pcp-base"></xref>.</t>
</section>
<section title="Acronyms">
<t>This document make use of the following abbreviations:</t>
<texttable align="center" style="none" suppress-title="false">
<ttcol align="right">CP router</ttcol>
<ttcol align="left">Customer Premise router</ttcol>
<c>DS-Lite</c>
<c>Dual-Stack Lite</c>
<c>IGD</c>
<c>Internet Gateway Device</c>
<c>IWF</c>
<c>Interworking Function</c>
<c>NAT</c>
<c>Network Address Translation</c>
<c>PCP</c>
<c>Port Control Protocol</c>
<c>UPnP</c>
<c>Universal Plug and Play</c>
</texttable>
<t></t>
</section>
<section title="Architecture Model">
<t>As a reminder, <xref target="igd_model"></xref> illustrates the
architecture model adopted by UPnP IGD <xref target="IGD2"></xref>. In
<xref target="igd_model"></xref>, the following UPnP terminology is
used:<list style="symbols">
<t>Client refers to a host located in the local network.</t>
<t>IGD Control Point is a UPnP control point using UPnP to control
an IGD (Internet Gateway Device).</t>
<t>Host represents a remote peer reachable in the Internet.</t>
</list></t>
<t><figure anchor="igd_model" title="UPnP IGD Model">
<preamble></preamble>
<artwork><![CDATA[+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +-----+ +------+
+---| | | |
| IGD |-------| Host |
+---| | | |
+-------------+ | +-----+ +------+
| Client |-----+
+-------------+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>This model is not valid when PCP is used to control for instance a
Carrier Grade NAT (a.k.a., Provider NAT) while internal hosts continue
to use UPnP. In such scenarios, <xref target="igdpcp"></xref> shows the
updated model.</t>
<t><figure anchor="igdpcp" title="UPnP IGD-PCP Interworking Model">
<preamble></preamble>
<artwork><![CDATA[+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +-----+ +--------+ +------+
+---| IGD-| |Provider| | |
| PCP |-------| NAT |--<Internet>---| Peer |
+---| IWF | | | | |
+-------------+ | +-----+ +--------+ +------+
| Local Host |-----+
+-------------+
LAN Side External Side
<======UPnP IGD===============><======PCP=====>
]]></artwork>
<postamble></postamble>
</figure></t>
<t>In the updated model depicted in <xref target="igdpcp"></xref>, one
or two levels of NAT can be encountered in the data path. Indeed, in
addition to the Carrier Grade NAT, the CP router may embed a NAT
function (<xref target="multinat"></xref>).</t>
<t><figure anchor="multinat" title="Cascaded NAT scenario">
<preamble></preamble>
<artwork><![CDATA[+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +-----+ +----+ +------+
+---| IGD-| | | |Remote|
| PCP |-------|NAT2|--<Internet>---| Host |
+---| IWF | | | | |
+-------------+ | +-----+ +----+ +------+
| Local Host |-----+ NAT1
+-------------+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>To ensure a successful interworking between UPnP IGD and PCP, an
interworking function is embedded in the CP router. In the model defined
in <xref target="igdpcp"></xref>, all UPnP IGD server-oriented
functions, a PCP Client <xref target="I-D.ietf-pcp-base"></xref> and a
UPnP IGD-PCP Interworking Function are embedded in the CP router (i.e.,
IGD). In the rest of the document, IGD-PCP Interworking Function refers
to PCP Client and UPnP IGD-PCP Interworking Function.</t>
<t>UPnP IGD-PCP Interworking Function is responsible for generating a
well-formed PCP (resp., UPnP IGD) message from a received UPnP IGD
(resp., PCP) message.</t>
</section>
<section title="UPnP IGD-PCP Interworking Function: Overview">
<t>Three tables are provided to specify the mapping between UPnP IGD and
PCP:<list style="numbers">
<t><xref target="variables"></xref> provides the mapping between
WANIPConnection parameters and PCP parameters;</t>
<t><xref target="methods"></xref> focuses on the correspondence
between supported methods;</t>
<t><xref target="errors"></xref> lists the IGD error messages and
their corresponding PCP ones.</t>
</list></t>
<t>Note that some enhancements have been integrated in WANIPConnection
as documented in <xref target="IGD2"></xref>.</t>
<section title="UPnP IGD-PCP: Variables">
<t></t>
<texttable align="center" anchor="variables" style="all"
suppress-title="false" title="UPnP IGD-PCP: Variables">
<ttcol align="center">WANIPConnection</ttcol>
<ttcol align="center" width="">PCP</ttcol>
<ttcol align="center">Comments</ttcol>
<c>PortMappingEnabled</c>
<c>Not applicable</c>
<c>When set to 1, this parameter MUST NOT be reproduced as an
argument in PCP messages. If set to 0, this is the default PCP mode
(no explicit indication in PCP messages). PCP does not support
deactivating the dynamic NAT mapping since the initial goal of PCP
is to ease the traversal of Carrier Grade NAT. Supporting such
per-subscriber function may overload the Carrier Grade NAT.</c>
<c>PortMappingLeaseDuration</c>
<c>Requested Mapping Lifetime</c>
<c>PCP recommends 7200s as default value. When
PortMappingLeaseDuration is set to 0, a maximum lifetime value MAY
be included in the corresponding PCP message. PCP allows for a
maximum value of 65536 seconds while UPnP IGD allows 604800 seconds
(i.e., one week) as a maximum bound. 3600s being the recommended
lease value in UPnP IGD:2 <xref target="IGD2"></xref>.</c>
<c>ExternalPort</c>
<c>External Port Number</c>
<c>PCP does not support explicit wildcard values. If ExternalPort is
a wildcard value, a random value of External Port Number MUST be
enclosed in the corresponding PCP message.</c>
<c>InternalPort</c>
<c>Internal Port Number</c>
<c></c>
<c>PortMappingProtocol</c>
<c>Transport Protocol</c>
<c>IGD only supports TCP and UDP.</c>
<c>InternalClient</c>
<c>Internal IP Address</c>
<c>InternalClient can be an IP address or a FQDN. Only an IP address
scheme is supported in PCP. If a FQDN is used by the IGD Control
Point, it must be resolved to an IP address by the Interworking
Function when relying the message to the PCP Server.</c>
<c>ExternaIPAddress</c>
<c>External IP Address</c>
<c></c>
<c>PortMappingDescription</c>
<c>Not applicable</c>
<c>Not supported in base PCP. When present in UPnP IGD messages,
this parameter SHOULD NOT be propagated in the corresponding PCP
messages. If the local PCP Client support a PCP Option to convey the
description, this option MAY be used.</c>
<c>RemoteHost</c>
<c>REMOTE_PEER</c>
<c>PCP RECOMMENDS to configure the CP router's firewall instead of
overloading the Carrier Grade NAT. The REMOTE_PEER PCP Option can be
used.</c>
<c>PossibleConnectionTypes</c>
<c>Not applicable</c>
<c>Out of scope of PCP</c>
<c>ConnectionStatus</c>
<c>Not applicable</c>
<c>Out of scope of PCP</c>
<c>PortMappingNumberOfEntries</c>
<c>Not applicable</c>
<c>Managed locally by the UPnP IGD-PCP Interworking Function</c>
<c>SystemUpdateID</c>
<c>Not applicable</c>
<c>Managed locally by the UPnP IGD-PCP Interworking Function</c>
</texttable>
<t></t>
</section>
<section title="IGD-PCP: Methods">
<t>Both IGD:1 and IGD:2 methods are listed in <xref
target="methods"></xref>.</t>
<texttable anchor="methods" style="all" title="IGD-PCP: Methods">
<ttcol align="center">WANIPConnection</ttcol>
<ttcol align="center">PCP</ttcol>
<ttcol align="center">Comments</ttcol>
<c>GetGenericPortMappingEntry</c>
<c>Not applicable</c>
<c>This request is not relayed to the PCP Server. IGD-PCP
Interworking Function maintains an updated list of active mappings
instantiated in the PCP Server by internal hosts. See <xref
target="list"></xref> for more information. </c>
<c>GetSpecificPortMappingEntry</c>
<c>Not applicable</c>
<c>Under normal conditions, the IGD-PCP Interworking Function
maintains an updated list of active mapping as instantiated in the
PCP Server. The IGD-PCP Interworking Function locally handles this
request and provides back the port mapping entry based on the
ExternalPort, the PortMappingProtocol, and the RemoteHost. See <xref
target="list"></xref> for more information</c>
<c>AddPortMapping</c>
<c>PINxy</c>
<c>We recommend the use of AddAnyPortMapping() instead of
AddPortMapping(). Refer to <xref target="addportmapping"></xref>
</c>
<c>DeletePortMapping</c>
<c>PINxy with a requested lifetime set to 0</c>
<c>Refer to <xref target="delete"></xref> </c>
<c>GetExternalIPAddress</c>
<c>PCP does not support yet a method for retrieving the external IP
address. Issuing PINxy may be used as a means to retrieve the
external IP address</c>
<c></c>
<c>DeletePortMappingRange()</c>
<c>PINxy with a lifetime positioned to 0</c>
<c>Individual requests are issued by the IGD-PCP Interworking
Function. Refer to <xref target="delete"></xref> for more
details</c>
<c>GetListOfPortMappings()</c>
<c>Not applicable</c>
<c>The IGD-PCP Interworking Function maintains an updated list of
active mapping as instantiated in the PCP Server. The IGD-PCP
Interworking Function handles locally this request. See <xref
target="list"></xref> for more information</c>
<c>AddAnyPortMapping()</c>
<c>PINxy</c>
<c>No issue is encountered to proxy this request to the PCP Server.
Refer to <xref target="addanyportmapping"></xref> for more
details</c>
</texttable>
<t></t>
</section>
<section title="UPnP IGD-PCP: Errors">
<t><xref target="errors"></xref> lists UPnP IGD errors codes and the
corresponding PCP ones. Error codes specific to IGD:2 are tagged
accordingly.</t>
<texttable align="center" anchor="errors" style="all"
title="UPnP IGD-PCP: Errors">
<ttcol align="center">IGD Error Code</ttcol>
<ttcol align="center">PCP Error Code</ttcol>
<c>401 (InvalidAction)</c>
<c>129 (UNSUPP_OPCODE)</c>
<c>402 (InvalidArgs)</c>
<c>TBD (MALFORMED_REQUEST)</c>
<c>501(ActionFailed)</c>
<c>154 (UNABLE_TO_DELETE_ALL) (??)</c>
<c>606 (ActionNotAuthorized) (only for IGD:2)</c>
<c>151 (NOT_AUTHORIZED)</c>
<c>713 (SpecifiedArrayIndexInvalid)</c>
<c>Not applicable because Get* requests are not relayed to the PCP
Server</c>
<c>714 (NoSuchEntryInArray)</c>
<c>PCP returns always a positive response even if the mapping to be
deleted does not exist. This error code is not applicable for Get*
requests which are not relayed to the PCP Server</c>
<c>715 (WildCardNotPermitedInSrcIP)</c>
<c>TBD (MALFORMED_REQUEST)</c>
<c>716 (WildCardNotPermitedInSrcExtPort)</c>
<c>Not applicable</c>
<c>718 (ConflictInMappingEntry)</c>
<c>Not applicable</c>
<c>724 (SamePortValuesRequired)</c>
<c>Not applicable</c>
<c>725 (OnlyPermanentLeaseSupported)</c>
<c>Not applicable</c>
<c>726 (RemoteHostOnlySupportsWildcard)</c>
<c>130 (UNSUPP_OPTION)</c>
<c>727 (ExternalPortOnlySupportsWildcard)</c>
<c>Not applicable</c>
<c>728 (NoPortMapsAvailable) (only for IGD:2)</c>
<c>4 (NO_RESOURCES) or 152 (USER_EX_QUOTA)</c>
<c>729 (ConflictWithOtherMechanisms) (only for IGD:2)</c>
<c>TBD (MECHANISM_CONFLICT)</c>
<c>730 (PortMappingNotFound) (only for IGD:2)</c>
<c>Not applicable</c>
<c>732 (WildCardNotPermittedInPort) (only for IGD:2)</c>
<c>TBD (MALFORMED_REQUEST)</c>
<c>733 (InconsistentParameter) (only for IGD:2)</c>
<c>Not applicable</c>
</texttable>
<t></t>
</section>
</section>
<section title="Specification of the IGD-PCP Interworking Function">
<t>This section covers the scenarios with or without NAT in the CP
router.</t>
<section title="PCP Server Discovery">
<t>The IGD-PCP Interworking Function implements one of the discovery
methods identified in <xref target="I-D.ietf-pcp-base"></xref> (e.g.,
DHCP <xref target="I-D.bpw-pcp-dhcp"></xref>). The IGD-PCP
Interworking Function behaves as a PCP Client when communicating with
the provisioned PCP Server.</t>
<t>In order to not impact the delivery of local services requiring the
control of the local IGD during any failure event to reach the PCP
Server (e.g., no IP address/prefix is assigned to the CP router),
IGD-PCP Interworking Function MUST NOT be invoked. Indeed, UPnP
machinery is used to control that device and therefore lead to
successful operations of internal services.</t>
<t>Once the PCP Sever is reachable, the IGD-PCP Interworking Function
MUST synchronize its states as specified in <xref
target="sync"></xref>.</t>
</section>
<section title="Control of the Firewall">
<t>In order to configure security policies to be applied to inbound
and outbound traffic, UPnP IGD can be used to control a local firewall
engine.</t>
<t>No IGD-PCP Interworking Function is therefore required for that
purpose.</t>
</section>
<section title="NAT Control in LAN Side">
<t>Internal UPnP Control Points are not aware of the presence of the
IGD-PCP Interworking Function in the CP router (IGD). Especially, UPnP
Control Points MUST NOT be aware of the deactivation of the NAT in the
CP router.</t>
<t>No modification is required in the UPnP Control Point.</t>
</section>
<section title="Port Mapping Tables">
<t>IGD-PCP Interworking Function MUST store locally all the mappings
instantiated by internal UPnP Control Points in the PCP Server. Port
Forwarding mappings SHOULD be stored in a permanent storage. If not,
upon reset or reboot, the IGD-PCP Interworking Function MUST
synchronise its states as specified in <xref
target="sync"></xref>.</t>
<t>Upon receipt of a PCP PINxy Response from the PCP Server, the
IGD-PCP Interworking Function MUST retrieve the enclosed mapping(s)
and MUST store it in the local mapping table. The local mapping table
is an image of the mapping table as maintained by the PCP Server for a
given subscriber.</t>
</section>
<section anchor="spec_no_nat"
title="Interworking Function Without NAT in the CP Router"
toc="default">
<t>When no NAT is embedded in the CP router, the content of received
WANIPConnection and PCP messages is not altered by the IGD-PCP
Interworking Function (i.e., the content of WANIPConnection messages
are copied to the PCP messages (and vice versa) according to <xref
target="variables"></xref>).</t>
</section>
<section anchor="spec_nat" title="NAT Embedded in the CP Router"
toc="default">
<t>Unlike the scenario with one level of NAT (<xref
target="spec_no_nat"></xref>), the IGD-PCP Interworking Function MUST
update their content of received mapping messages with the IP address
and/or port number belonging to the external interface of the CP
router (i.e., after the NAT1 operation in <xref
target="multinat"></xref>) and not as initially positioned by the UPnP
Control Point.</t>
<t>All WANIPConnection messages issued by the UPnP Control Point
(resp., PCP Server) are intercepted by the IGD-PCP Interworking
Function. Then, the corresponding messages (see <xref
target="variables"></xref>, <xref target="methods"></xref> and <xref
target="errors"></xref>) are generated by the IGD-PCP Interworking
Function and sent to the provisioned PCP Server (resp., corresponding
UPnP Control Point). The content of PCP messages received by the PCP
Server reflects the mapping information as enforced in the first NAT.
In particular, the internal IP address and/or port number of the
requests are replaced with the IP address and port number as assigned
by the NAT of the CP router. For the reverse path, PCP response
messages are intercepted by the IGD-PCP Interworking Function. The
content of the corresponding WANIPConnection messages are updated:
<list style="symbols">
<t>The internal IP address and/or port number as initially
positioned by the UPnP Control Point and stored in the CP router
NAT are used to update the corresponding fields in received PCP
responses.</t>
<t>The external IP and port number are not altered by the IGD-PCP
Interworking Function.</t>
<t>The NAT mapping entry in the first NAT is updated with the
result of PCP request.</t>
</list></t>
<t>The lifetime of the mappings instantiated in all involved NATs
SHOULD be the one assigned by the terminating PCP Server. In any case,
the lifetime MUST be lower or equal to the one assigned by the
terminating PCP Server.</t>
</section>
<section title="Creating a Mapping">
<t>Two methods can be used to create a mapping: AddPortMapping() or
AddAnyPortMapping().</t>
<t>AddAnyPortMapping() is the RECOMMENDED method.</t>
<section anchor="addanyportmapping" title="AddAnyPortMapping()">
<t>When an UPnP Control Point issues a AddAnyPortMapping(), this
request is received by the UPnP Server. The request is then relayed
to the IGD-PCP Interworking Function which generates a PCP PINxy
Request (see <xref target="variables"></xref> for mapping between
WANIPConnection and PCP parameters). Upon receipt of PCP PINxy
Response from the PCP Server, an XML mapping is returned to the
requesting UPnP Control Point (the content of the messages follows
the recommendations listed in <xref target="spec_nat"></xref> or
<xref target="spec_no_nat"></xref> according to the deployed
scenario). A flow example is depicted in <xref
target="igd2"></xref>.</t>
<t>If a PCP Error is received from the PCP Server, a corresponding
WANIPConnection error code <xref target="errors"></xref> is
generated by the IGD-PCP Interworking Function and sent to the
requesting UPnP Control Point.</t>
<t><figure anchor="igd2"
title="Flow example when AddAnyPortMapping() is used">
<preamble></preamble>
<artwork><![CDATA[ UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
|(1) AddAnyPortMapping | |
|--------------------->| |
| | (2) PCP PINxy Request |
| |(requested external port=0) |
| |---------------------------->|
| | |
| | (3) PCP PINxy Response |
| |(assigned external port=6598)|
| |<----------------------------|
|(4) AddAnyPortMapping | |
| ReservedPort=6598 | |
|<---------------------| |
]]></artwork>
<postamble></postamble>
</figure></t>
<t></t>
</section>
<section anchor="addportmapping" title="AddPortMapping()">
<t>A dedicated option called HONOR_EXTERNAL_PORT is defined in <xref
target="I-D.ietf-pcp-base"></xref> to toggle the behavior in a PCP
Request message. This options is inserted by the IGD-PCP IWF when
issuing its requests to the PCP Server only if a specific external
port is requested by the UPnP Control Point. When a wildcard is used
(i.e., 0), HONOR_EXTERNAL_PORT Option is not required to be inserted
in the PCP request to the PCP Server (see <xref
target="wildcard"></xref>). In the remaining, we assume that a
specific external port is requested by the UPnP Control Point.</t>
<t><figure anchor="wildcard"
title="Example of AddPortMapping() with wildcard external port">
<preamble></preamble>
<artwork><![CDATA[ UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddPortMapping | |
| ExternalPort=0 | |
|--------------------->| |
| | (2) PCP PINxy Request |
| |(requested external port=0) |
| |---------------------------->|
| | |
| | (3) PCP PINxy Response |
| |(assigned external port=1365)|
| |<----------------------------|
| (4) AddPortMapping | |
| ExternalPort=1356 | |
|<---------------------| |
]]></artwork>
<postamble></postamble>
</figure></t>
<t>Upon receipt of AddPortMapping() from an UPnP Control Point, the
IGD-PCP Interworking Function first checks if the requested external
port number is not used by another Internal UPnP Control Point. In
case a mapping bound to the requested external port number is found
in the local mapping table, the IGD-PCP IWF MUST send back a
ConflictInMappingEntry error to the requesting UPnP Control Point
(see <xref target="local_check"></xref>).</t>
<t><figure anchor="local_check" title="IWF Local Behaviour">
<preamble></preamble>
<artwork><![CDATA[ UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddPortMapping | |
| ExternalPort=2356 | |
|--------------------->| |
| | |
| (2) Error: | |
|ConflictInMappingEntry| |
|<---------------------| |
| | |
| (3) AddPortMapping | |
| ExternalPort=4586 | |
|--------------------->| |
| | |
| (4) Error: | |
|ConflictInMappingEntry| |
|<---------------------| |
| | |
]]></artwork>
<postamble></postamble>
</figure></t>
<t>This exchange (<xref target="local_check"></xref>) is re-iterated
until an external port number that is not in use is requested by the
UPnP Control Point. Then, the IGD-PCP IWF generates a PCP PINxy
Request with all requested mapping information as indicated by the
UPnP Control Point if no NAT is embedded in the CP router or updated
as specified in <xref target="spec_nat"></xref>. In addition, the
IGD-PCP IWF inserts a HONOR_EXTERNAL_PORT Option to the generated
PCP request.</t>
<t>If the requested external port is in use, a PCP Error message
MUST be sent by the PCP Server to the IGD-PCP IWF indicating
CANNOT_HONOR_EXTERNAL_PORT as the error cause. The IGD-PCP IWF
relays a negative message to the UPnP Control Point indicating
ConflictInMappingEntry as error code. The UPnP Control Point
re-issues a new request with a new requested external port number.
This process is repeated until a positive answer is received or
maximum retry is reached.</t>
<t>If the PCP Server is able to honor the requested external port, a
positive response is sent to the requesting IGD-PCP IWF. Upon
receipt of the response from the PCP Server, the returned mapping
MUST be stored by the IGD-PCP Interworking Function in its local
mapping table and a positive answer MUST be sent to the requesting
UPnP Control Point. This answer terminates this exchange.</t>
<t><xref target="positive"></xref> shows an example of the flow
exchange that occurs when the PCP Server satisfies the request from
the IGD-PCP IWF. <xref target="negative"></xref> shows the messages
exchange when the requested external port is in use.</t>
<t><figure anchor="positive" title="Flow Example (Positive Answer)">
<preamble></preamble>
<artwork><![CDATA[ UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddPortMapping | |
| ExternalPort=8080 | |
|--------------------->| |
| | (2) PCP PINxy Request |
| |requested external port=8080 |
| | HONOR_EXTERNAL_PORT |
| |---------------------------->|
| | |
| | (3) PCP PINxy Response |
| | assigned external port=8080 |
| |<----------------------------|
| (4) AddPortMapping | |
| ExternalPort=8080 | |
|<---------------------| |
]]></artwork>
<postamble></postamble>
</figure></t>
<t><figure anchor="negative" title="Flow Example (Negative Answer)">
<preamble></preamble>
<artwork><![CDATA[ UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddPortMapping | |
| ExternalPort=8080 | |
|--------------------->| |
| | (2) PCP PINxy Request |
| |requested external port=8080 |
| | HONOR_EXTERNAL_PORT |
| |---------------------------->|
| | (3) PCP PINxy Response |
| | CANNOT_HONOR_EXTERNAL_PORT |
| |<----------------------------|
| (4) Error: | |
|ConflictInMappingEntry| |
|<---------------------| |
| (5) AddPortMapping | |
| ExternalPort=5485 | |
|--------------------->| |
| | (6) PCP PINxy Request |
| |requested external port=5485 |
| | HONOR_EXTERNAL_PORT |
| |---------------------------->|
| | (7) PCP PINxy Response |
| | CANNOT_HONOR_EXTERNAL_PORT |
| |<----------------------------|
| (8) Error: | |
|ConflictInMappingEntry| |
|<---------------------| |
....
| (a) AddPortMapping | |
| ExternalPort=6591 | |
|--------------------->| |
| | (b) PCP PINxy Request |
| |requested external port=6591 |
| | HONOR_EXTERNAL_PORT |
| |---------------------------->|
| | (c) PCP PINxy Response |
| | CANNOT_HONOR_EXTERNAL_PORT |
| |<----------------------------|
| (d) Error: | |
|ConflictInMappingEntry| |
|<---------------------| |
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
</section>
<section anchor="list" title="Listing One or a Set of Mappings">
<t>In order to list active mappings, an UPnP Control Point may issue
GetGenericPortMappingEntry(), GetSpecificPortMappingEntry() or
GetListOfPortMappings().</t>
<t>These methods MUST NOT be proxied to the PCP Server since a local
mapping is maintained by the IGD-PCP Interworking Function.</t>
</section>
<section anchor="delete"
title="Delete One or a Set of Mappings: DeletePortMapping() or DeletePortMappingRange()">
<t>An UPnP Control Point proceeds to the deletion of one or a list of
mappings by issuing DeletePortMapping() or DeletePortMappingRange().
When one of these messages is received by the IGD-PCP Interworking
Function, it first checks if the requested mapping to be removed is
present in the local mapping table. If no mapping matching the request
is found in the local table, an error is sent back to the UPnP Control
Point (see <xref target="local_delete"></xref>).</t>
<figure anchor="local_delete" title="Local Delete (IGD-PCP IWF)">
<preamble></preamble>
<artwork><![CDATA[ UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
|(1) DeletePortMapping | |
|--------------------->| |
| | |
| (2) Error: | |
| NoSuchEntryInArray | |
|<---------------------| |
| | |
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>if a mapping matches in the local table, PCP PINxy delete
request(s) is generated taking into account the input arguments: <list
style="symbols">
<t>as included in DeletePortMapping() if no NAT is enabled in the
CP router; In case DeletePortMappingRange() is used, the IGD-PCP
IWF generates individual requests to cover all the range;<list
style="empty">
<t>[[Note: Add a figure to illustrate the behaviour to handle
DeletePortMappingRange()]]</t>
</list></t>
<t>or the corresponding local IP address and port number as
assigned by the local NAT if a NAT is enabled in the CP
router.</t>
</list></t>
<t>Once received by the PCP Server, it proceeds to removing the
corresponding entry(ies). A PCP PINxy delete response is sent back if
the removal of the corresponding entry(ies) was successful; if not, a
PCP Error is sent back to the IGD-PCP Interworking Function including
the corresponding error cause (e.g., Not Authorised).</t>
<t>When a positive answer is received from the PCP Server, the IGD-PCP
Interworking Function updates its local mapping table (i.e., remove
the corresponding entry(ies)) and notifies the UPnP Control Point
about the result of the removal operation.</t>
</section>
<section anchor="sync" title="Mapping Synchronisation">
<t>[[Note: This section needs further discussion among authors]]</t>
<t>Under normal conditions, since a valid copy of the mapping table is
stored locally in the CP router, the IGD-PCP Interworking Function
SHOULD NOT issue any subsequent PCP request to handle a request
received from an UPnP Control Point to list active mappings.
Nevertheless, in case of loss of synchronisation (e.g., reboot, system
crashes, power outage, etc.), the IGD-PCP Interworking Function SHOULD
generate a get method to retrieve all active mappings in the PCP
Server and update its local mapping table without waiting for an
explicit request from a UPnP Control Point. Doing so, the IGD-PCP
Interworking Function maintains an updated mapping table.</t>
<t>In case of massive reboot of CP routers (e.g., avalanche restart
phenomenon), PCP request bursts SHOULD be avoided. For this aim, we
recommend the use of a given timer denoted as PCP_SERVICE_WAIT. This
timer can be pre-configured in the CP router or to be provisioned
using a dedicated means such as DHCP. Upon reboot of the CP router,
PCP messages SHOULD NOT be sent immediately. A random value is
selected between 0 and PCP_SERVICE_WAIT. This value is referred to as
RAND(PCP_SERVICE_WAIT). Upon the expiration of RAND(PCP_SERVICE_WAIT),
the CP router SHOULD proceed to its synchronisation operations (i.e.,
retrieve all active mappings which have been instructed by internal
UPnP Control Point(s)).</t>
<t>[[Note: per-subscriber quota may be exhausted due to unlimited
lifetime and stale mappings in IGD due to reboots, etc.]]</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document defines a procedure to instruct PCP mappings for third
party devices belonging to the same subscriber. Identification means to
avoid a malicious user to instruct mappings on behalf of a third party
must be enabled. Such means are already discussed in Section 7.4.4 of
<xref target="I-D.ietf-pcp-base"></xref>.</t>
<t>Security considerations elaborated in <xref
target="I-D.ietf-pcp-base"></xref> and <xref target="Sec_DCP"></xref>
should be taken into account.</t>
</section>
<section title="Acknowledgments">
<t>Authors would like to thank F. Fontaine and C. Jacquenet for their
review and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-softwire-dual-stack-lite'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate-stateful'?>
<?rfc include='reference.I-D.bpw-pcp-dhcp'?>
<reference anchor="Sec_DCP" target="">
<front>
<title>Device Protection:1</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization>UPnP Forum</organization>
</author>
<date day="17" month="November" year="2009" />
</front>
</reference>
<reference anchor="IGD2">
<front>
<title>WANIPConnection:2 Service
(http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf)</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date day="15" month="September" year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:42 |