One document matched: draft-boucadair-pcp-failure-05.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="std" docName="draft-boucadair-pcp-failure-05" ipr="trust200902">
<front>
<title abbrev="PCP Failure Scenarios">Port Control Protocol (PCP) Failure
Scenarios</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.com</email>
</address>
</author>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<code></code>
<country>USA</country>
</postal>
<email>repenno@cisco.com</email>
</address>
</author>
<date day="15" month="February" year="2013" />
<workgroup>PCP Working Group</workgroup>
<keyword>reliability, failure, state synchronization, state recovery,
stale mapping</keyword>
<abstract>
<t>This document identifies and analyzes several PCP failure scenarios.
Identifying these failure scenarios are useful to assess the efficiency
of the protocol and also to decide whether new extensions are needed to
the base PCP.</t>
<t>A procedure to retrieve the explicit dynamic mapping(s) from the PCP
Server is proposed. This procedure relies upon the use of a new PCP
OpCode and Option: GET/NEXT.</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>This document discusses several failure scenarios that may occur when
deploying PCP <xref target="I-D.ietf-pcp-base"></xref>.</t>
</section>
<section title="PCP Client Failure Scenarios">
<t></t>
<section title="Change of the IP Address of The PCP Server">
<t>When a new IP address is used to reach its PCP Server, the PCP
Client MUST re-create all of its explicit dynamic mappings using the
newly discovered IP address.</t>
<t>The PCP Client must undertake the same process as per refreshing an
existing explicit dynamic mapping (see <xref
target="I-D.ietf-pcp-base"></xref>); the only difference is the PCP
requests are sent to a distinct IP address. No specific behavior is
required from the PCP Server for handling these requests.</t>
</section>
<section title="Application Crash">
<t>When a fatal error is encountered by an application relying on PCP
to open explicit dynamic mappings on an upstream device, and upon the
restart of that application, the PCP Client should issue appropriate
requests to refresh the explicit dynamic mappings of that application
(e.g., clear old mappings and install new ones using the new port
number used by the application).</t>
<t>If the same port number is used but a distinct Mapping Nonce is
generated, the request will be rejected with a NOT_AUTHORIZED error
with the Lifetime of the error indicating duration of that existing
mapping (see Section 2.7 of <xref
target="I-D.boucadair-pcp-flow-examples"></xref>). A solution to
recover the Mapping Nonce used when instantiating the mapping may be
envisaged; this solution may not be viable if PCP authentication is
not in use. Mapping Nonce recovery in the simple PCP threat model
(especially when Mapping Check validation is enabled) induced the same
security threated as those discussed in <xref
target="I-D.ietf-pcp-base"></xref>. </t>
<t>If a distinct port number is used by the application to bound its
service (i.e., a new internal port number is to be signaled in PCP),
the PCP Server may honor the refresh requests if the per-subscriber
quota is not exceeded. A distinct external port number would be
assigned by the PCP Server due to the presence of "stale" explicit
dynamic mapping(s) associated with the "old" port number.</t>
<t>To avoid this inconvenience induced by stale explicit dynamic
mappings, the PCP Client MAY clear the "old" mappings before issuing
the refresh requests; but this would require the PCP Client to store
the information about the "old" port number. This can be easy to solve
if the PCP Client is embedded in the application. In some scenarios,
this is not so easy because the PCP Client may handle PCP requests on
behalf of several applications and no means to identify the requesting
application may be supported. Means to identify the application are
implementation-specific and are out of scope of this document.</t>
<t><xref target="I-D.ietf-pcp-base"></xref> does not allow anymore a
PCP Client to issue a request to delete all the explicit dynamic
mappings associated with an internal IP address. If a PCP Client is
allowed to clear all mappings bound to the same IP address, this would
have negative impact on other applications and PCP Client(s) which may
use the same internal IP address to instruct their explicit dynamic
mappings in the PCP Server.</t>
</section>
<section title="PCP Client Crash">
<t>The PCP Client may encounter a fatal error leading to its restart.
In such case, the internal IP address and port numbers used by
requesting applications are not impacted. Therefore, the explicit
dynamic mappings as maintained by the PCP Server are accurate and
there is no need to refresh them.</t>
<t>On the PCP Client side, a new UDP port should be assigned to issue
PCP requests. As a consequence, if outstanding requests have been sent
to the PCP Server, the responses are likely to be lost.</t>
<t>If the PCP Client stores its explicit dynamic mappings in a
persistent memory, there is no need to retrieve the list of active
mappings from the PCP Server. If several PCP Clients are co-located on
the same host, related PCP mapping tables should be uniquely
distinguished (e.g., a PCP Client does not delete explicit dynamic
mappings instructed by another PCP Client.)</t>
<t>If the PCP Client does not store the explicit dynamic mappings and
new Mapping Nonces are assigned, the PCP Server will reject to refresh
these mappings. This issue can be solved if the PCP Client uses GET
OpCode (<xref target="get"></xref>) to recover the mapping nonces used
when instantiating the mappings if PCP authentication is used or
Mapping Nonce validation check is disabled.</t>
<t>If the PCP Client (or the application) is crashing, it should be
allocating short PCP lifetimes until it is debugged and running
properly. If it is never debugged and never running properly, it
should continue to request short PCP lifetimes.</t>
</section>
<section anchor="change_internal_ip_address"
title="Change of the Internal IP Address">
<t>When a new IP address is assigned to a host embedding a PCP Client,
the PCP Client MUST install on the PCP Server all the explicit dynamic
mappings it manages, using the new assigned IP address as the internal
IP address. The hinted external port number won't be assigned by the
PCP Server since a "stale" mapping is already instantiated by the PCP
Server (but it is associated with a distinct internal IP address).</t>
<t>For a host configured with several addresses, the PCP Client MUST
maintain a record about the target IP address it used when issuing its
PCP requests. If no record is maintained and upon a change of the IP
address or de-activation of an interface, the PCP-instructed explicit
dynamic mappings are broken and inbound communications will fail to be
delivered.</t>
<t>Depending on the configured policies, the PCP Server may honor all
or part of the requests received from the PCP Client. Upon receipt of
the response from the PCP Server, the PCP Client MUST update its local
PCP state with the new assigned port numbers and external IP
address.</t>
<t>Because of the possible negative impact if the quota is exceed due
to the presence of stale mappings (see the example in Section 2.14 of
<xref target="I-D.boucadair-pcp-flow-examples"></xref>), a procedure
to clear stale mappings may have some benefits (but also some side
effect as discussed above). Note PCP does not support such
functionality anymore.</t>
<t>A PCP Client may be used to manage explicit dynamic mappings on
behalf of a third party (i.e., the PCP Client and the third party are
not co-located on the same host). If a new internal IP address is
assigned to that third party (e.g., webcam), the PCP Client SHOULD be
instructed to delete the old mapping(s) and create new one(s) using
the new assigned internal IP address. When the PCP Client is
co-located with the DHCP server (e.g., PCP Proxy <xref
target="I-D.ietf-pcp-proxy"></xref>, IWF in the CP router <xref
target="I-D.ietf-pcp-upnp-igd-interworking"></xref>), the state can be
updated using the state of the local DHCP server. Otherwise, it is
safe to recommend the use of static internal IP addresses if PCP is
used to configure third-party explicit dynamic mappings.</t>
</section>
<section title="Change of the CPE WAN IP Address">
<t>The change of the IP address of the WAN interface of the CPE would
have an impact on the accuracy of the explicit dynamic mappings
instantiated in the PCP Server:</t>
<t><list style="symbols">
<t>For the DS-Lite case <xref target="RFC6333"></xref>: if a new
IPv6 address is used by the B4 element when encapsulating IPv4
packets in IPv6 ones, the explicit dynamic mappings SHOULD be
refreshed: If the PCP Client is embedded in the B4, the refresh
operation is triggered by the change of the B4 IPv6 address. This
would be more complicated when the PCP Client is located in a
device behind the B4. If a PCP Proxy is embedded in the CPE, the
proxy can use ANNOUNCE OpCode towards internal IPv4 hosts behind
the DS-Lite CPE.</t>
<t>For the NAT64 case <xref target="RFC6146"></xref>, any change
of the assigned IPv6 prefix delegated to the CPE will be detected
by the PCP Client (because this leads to the allocation of a new
IPv6 address). The PCP Client has to undertake the operation
described in <xref
target="change_internal_ip_address"></xref>.</t>
<t>For the NAT444 case, similar problems are encountered because
the PCP Client has no reasonable way to detect the CPE's WAN
address changed.</t>
</list></t>
</section>
<section title="UPnP IGD/PCP IWF">
<t>In the event an UPnP IGD/PCP IWF <xref
target="I-D.ietf-pcp-upnp-igd-interworking"></xref> fails to renew a
mapping, there is no mechanism to inform the UPnP Control Point about
this failure.</t>
<t>On the reboot of the IWF, if no mapping table is maintained in a
permanent storage, "stale" mappings will be maintained by the PCP
Server and per-user quota will be consumed. This is even exacerbated
if new mapping nonces are assigned by the IWF. This issue can be
soften by synchronizing the mapping table owing to the invocation of
the GET OpCode defined in <xref target="get"></xref>. This procedure
is supported only if Mapping Nonce validation checks are disabled.</t>
</section>
</section>
<section title="Restart or Failure of the PCP Server">
<t>This section covers failure scenarios encountered by the PCP
Server.</t>
<section title="Basic Rule">
<t>In any situation the PCP Server loses all or part of its PCP state,
the Epoch value MUST be reset when replying to received requests.
Doing so would allow PCP Client to audit its explicit dynamic mapping
table.</t>
<t>If the state is not lost, the PCP Server MUST NOT reset the Epoch
value returned to requesting PCP Clients.</t>
</section>
<section title="Clear PCP Mappings">
<t>When a command line or a configuration change is enforced to clear
all or a subset of PCP explicit dynamic mappings maintained by the PCP
Server, the PCP Server MUST reset its Epoch to zero value.</t>
<t>In order to avoid all PCP Clients to update their explicit dynamic
mappings, the PCP Server SHOULD reset the Epoch to zero value only for
impacted users.</t>
</section>
<section title="State Redundancy is Enabled">
<t>When state redundancy is enabled, the state is not lost during
failure events. Failures are therefore transparent to requesting PCP
Clients. When a backup device takes over, Epoch MUST NOT be reset to
zero.</t>
</section>
<section title="Cold-Standby without State Redundancy">
<t>In this section we assume that a redundancy mechanisms is
configured between a primary PCP-controlled device and a backup one
but without activating any state synchronization for the
PCP-instructed explicit dynamic mappings between the backup and the
primary devices.</t>
<t>If the primary PCP-controlled device fails and the backup one takes
over, the PCP Server MUST reset the Epoch to zero value. Doing so
would allow PCP Clients to detect the loss of states in the PCP Server
and proceed to state synchronization.</t>
</section>
<section title="Anycast Redundancy Mode">
<t>When an anycast-based mode is deployed (i.e., the same IP address
is used to reach several PCP Servers) for redundancy reasons, the
change of the PCP Server which handles the requests of a given PCP
Client won't be detected by that PCP Client.</t>
<t>Tweaking the Epoch (Section 8.5 of <xref
target="I-D.ietf-pcp-base"></xref>) may help to detect the loss of
state and therefore to re-create missing explicit dynamic
mappings.</t>
</section>
<section title="Mapping Repair Procedure">
<t></t>
<section title="PCP Client Behaviour">
<t><xref target="I-D.ietf-pcp-base"></xref> defines a procedure for
the PCP Server to notify PCP Clients about changes related to the
mappings it maintains. Indeed, the PCP Server can send unsolicited
ANNOUNCE OpCode or unsolicited MAP/PEER responses. When unsolicited
ANNOUNCE is received, the PCP Client proceeds to re-installing its
mappings. Unsolicited PCP MAP/PEER responses received from a PCP
Server are handled as any normal MAP/PEER response.</t>
</section>
<section title="PCP Proxy Behaviour">
<t>Upon receipt of an unsolicited ANNOUNCE response from a PCP
Server, the PCP Proxy proceeds to renewing the mappings and checks
whether there are changes compared to a local cache if it is
maintained by the PCP Proxy. If no change is detected, no
unsolicited ANNOUNCE is generated towards PCP Clients. If a change
is detected, the PCP Proxy MUST generate unsolicited ANNOUNCE
message(s) to appropriate PCP Clients. If the PCP Proxy does not
maintain a local cache for the mappings, unsolicited ANNOUNCE
messages are relayed to PCP Clients.</t>
<t>Unsolicited PCP MAP/PEER responses received from a PCP Server are
handled as any normal MAP/PEER response. To handle unsolicited PCP
MAP/PEER responses, the PCP Proxy is required to maintain a local
cache of instantiated mappings in the PCP Server. When this service
is supported the state SHOULD be recovered in case of failures using
the procedure defined in <xref target="get"></xref>.</t>
<t>Upon change of its external IP address, the PCP Proxy SHOULD
renew the mappings it maintained. This can be achieved only if a
full state table is maintained by the PCP Proxy.</t>
</section>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBC.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>The following OpCode is requested:<list style="symbols">
<t>GET</t>
</list></t>
<t>The following Option code is requested:<list style="symbols">
<t>NEXT</t>
</list></t>
<t>The following error codes are requested:<list style="symbols">
<t>NONEXIST_MAP</t>
<t>AMBIGUOUS</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Francis Dupont contributed text to this document. Many thanks to
him.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc include='reference.I-D.ietf-pcp-proxy'?>
<?rfc include='reference.I-D.ietf-pcp-upnp-igd-interworking'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.I-D.boucadair-pcp-flow-examples'?>
<?rfc include='reference.RFC.6146'?>
</references>
<section title="PCP State Synchronization: Overview">
<t>The following sketches the state synchronization logic:</t>
<t><list style="symbols">
<t>One element (i.e., PCP Client/host/application, PCP Server, PCP
Proxy, PCP IWF) of the chain is REQUIRED to use stable storage</t>
<t>If the PCP Client (resp., the PCP Server) crashes and restarts it
just have to synchronize with the PCP Server (resp., the PCP
Client);</t>
<t>If both crash then one has to use stable storage and we fall back
in the previous case as soon as we know which one (the Epoch value
gives this information);</t>
<t>PCP Server -> PCP Client not-disruptive synchronization
requires a GET/NEXT mechanism to retrieve the state from the PCP
Server; without this mechanism the only way to put the PCP Server in
a known state is for the PCP Client to send a delete all request, a
clearly disruptive operation.</t>
<t>PCP Client -> PCP Server synchronization is done by a
re-create or refresh of the state. The PCP Client MAY retrieve the
PCP Server state in order to prevent stale explicit dynamic
mappings.</t>
</list></t>
</section>
<section anchor="get" title="GET/NEXT Operation">
<t>This section defines a new PCP OpCode called GET and its associated
Option NEXT.</t>
<t>These PCP Opcode and Option are used by the PCP Client to retrieve an
explicit mapping or to walk through the explicit dynamic mapping table
maintained by the PCP Server for this subscriber and retrieves a list of
explicit dynamic mapping entries it instantiated.</t>
<t>GET can also be used by a NoC to retrieve the list of mappings for a
given subscriber.</t>
<section title="OpCode Format">
<t>The GET OpCode payload contains a Filter used for explicit dynamic
mapping matching: only the explicit dynamic mappings of the subscriber
which match the Filter in a request are considered so could be
returned in response.<list style="empty">
<t>Implementation Note: Some existing implementations use 98
(0x62) codepoint for GET OpCode, 131 for AMBIGUOUS error code, and
131 (0x83) for NEXT Option.</t>
</list></t>
<t>The layout of GET OpCode is shown in <xref
target="GET"></xref>.</t>
<t><figure anchor="GET" title="GET: OpCode format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Filter internal IP address (always 128 bits) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Filter external IP address (always 128 bits) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filter internal port | Filter external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>For all fields, the value 0 in a request means wildcard filter/any
value matches. Of course this has to be sound: no defined port with
protocol set to any.</t>
<t>These fields are described below: <list style="hanging">
<t hangText="Protocol:">Same than for MAP <xref
target="I-D.ietf-pcp-base"></xref>.</t>
<t hangText="Reserved:">MUST be sent as 0 and MUST be ignored when
received.</t>
<t hangText="Filter internal IP address:">Conveys the internal IP
address (including an unspecified IPv4IPv6 address). The encoding
of this field follows Section 5 of <xref
target="I-D.ietf-pcp-base"></xref>.</t>
<t hangText="Filter external IP address:">Conveys the external IP
address (including an unspecified IPv4IPv6 address). The encoding
of this field follows Section 5 of <xref
target="I-D.ietf-pcp-base"></xref>.</t>
<t hangText="Filter internal port:">The internal port (including
0).</t>
<t hangText="Filter external port:">The external port (including
0).</t>
</list></t>
<t>Responses include a bit-to-bit copy of the OpCode found in the
request.</t>
</section>
<section title="OpCode-Specific Result Code">
<t>This OpCode defines two new specific Result Code <list
style="hanging">
<t hangText="TBD:">NONEXIST_MAP, e.g., no explicit dynamic mapping
matching the Filter was found.</t>
<t hangText="TBD:">AMBIGUOUS. This code is returned when the PCP
Server is not able to decide which mapping to return. Existing
implementations use 131 as codepoint.</t>
</list></t>
</section>
<section anchor="order" title="Ordering and Equality">
<t>The PCP server is required to implement an order between matching
explicit dynamic mappings. The only property of this order is to be
stable: it doesn't change (*) between two GET requests with the same
Filter.</t>
<t>(*) "change" means two mappings are not gratuitously swapped:
expiration, renewal or creation are authorized to change the order but
they are at least expected by the PCP client. <list style="empty">
<t>[Ed. Note: We have two proposals for the order: lexicographical
order and lifetime order. Both work, this should be left to the
implementor.]</t>
</list></t>
<?rfc subcompact="yes"?>
<t>Equality is defined by: <list style="symbols">
<t>same protocol and;</t>
<t>same internal address and;</t>
<t>same external address and;</t>
<t>same internal port and;</t>
<t>same external port.</t>
</list></t>
<?rfc subcompact="no"?>
</section>
<section title="NEXT Option">
<t>Formal definition: <list style="hanging">
<t hangText="Name:">NEXT</t>
<t hangText="Number:">at most one in requests, any in
responses.</t>
<t hangText="Purpose:">carries a Locator in requests, matching
explicit dynamic mappings greater than the Locator in
responses.</t>
<t hangText="Is valid for OpCodes:">GET OpCode.</t>
<t hangText="Length:">variable, the minimum is 11.</t>
<t hangText="May appear in:">both requests and responses.</t>
<t hangText="Maximum occurrences:">one for requests, bounded by
maximum message size for PCP responses <xref
target="I-D.ietf-pcp-base"></xref>.</t>
</list></t>
<t>The layout of the NEXT Option is shown in <xref
target="NEXT"></xref>.</t>
<t><figure anchor="NEXT" title="NEXT: Option format">
<artwork><![CDATA[Version=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved | MORE/END |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Mapping internal IP address (always 128 bits) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Mapping external IP address (always 128 bits) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping remaining lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping internal port | Mapping external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Options :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version=2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mapping Nonce (96 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved | MORE/END |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Mapping internal IP address (always 128 bits) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Mapping external IP address (always 128 bits) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping remaining lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping internal port | Mapping external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Options :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>In requests the NEXT Option carries a Locator: a position in the
list of explicit dynamic mappings which match the Filter. The
following two useful forms of Locators are considered: <list
style="symbols">
<t>the "Undefined" form where the Protocol, Addresses, Ports
fields are set to zero.</t>
<t>the "Defined" form where none of the Protocol, Addresses and
Ports is set to zero.</t>
</list></t>
<t>The new fields in a Locator (a.k.a., the NEXT Option in a GET
request) are described below: <list style="hanging">
<t hangText="MORE/END:">The value 0 denotes "MORE" and means the
response MAY include multiple NEXT Options; a value other than 0
(1 is RECOMMENDED) denotes "END" and means the response SHALL
include at most one NEXT Option.</t>
<t hangText="Mapping remaining lifetime:">MUST be sent as 0 and
MUST be ignored when received.</t>
<t hangText="Mapping Options:">The Option Codes of the PCP Client
wants to get in the response (e.g., THIRD_PARTY). The format is
the same than for the UNPROCESSED Option (see rev 17 of<xref
target="I-D.ietf-pcp-base"></xref>).</t>
</list></t>
<t>In responses the NEXT Options carry the returned explicit dynamic
mappings, one per NEXT Option. The fields are described below: <list
style="hanging">
<t hangText="Protocol:">The protocol of the returned mapping.</t>
<t hangText="MORE/END:">The value 0 when there are explicit
dynamic mapping matching the Filter and greater than this returned
mapping; a value other than 0 (1 is RECOMMENDED) when the return
mapping is the greatest explicit dynamic mapping matching the
Filter.</t>
<t hangText="Mapping internal IP address:">the internal address of
the returned mapping. The encoding of this field follows Section 5
of <xref target="I-D.ietf-pcp-base"></xref>.</t>
<t hangText="Mapping external IP address:">the external address of
the returned mapping. The encoding of this field follows Section 5
of <xref target="I-D.ietf-pcp-base"></xref>.</t>
<t hangText="Mapping remaining lifetime:">The remaining lifetime
in seconds of the returned mapping.</t>
<t hangText="Mapping internal port:">the internal port of the
returned mapping.</t>
<t hangText="Mapping external port:">the external port of the
returned mapping.</t>
<t hangText="Mapping Options:">An embedded list of option values.
Each corresponding Option Code MUST be present in the request NEXT
Option, each option MUST be related to the returned mapping or not
related to any mapping.</t>
</list></t>
</section>
<section title="GET/NEXT PCP Client Theory of Operation">
<t>GET requests without a NEXT Option have low usage but with a full
wildcard Filter they ask the PCP Server to know if it has at least one
explicit dynamic mapping for this subscriber.</t>
<t>GET requests with an END NEXT Option are "pure" GET: they asks for
the status and/or the remaining lifetime or options of a specific
explicit dynamic mapping. It is recommended to use an Undefined
Locator and to use the Filter to identify the mapping.</t>
<t>GET requests with a MORE NEXT Option are for the whole explicit
dynamic mapping table retrieval from the PCP Server. The initial
request contains an Undefined Locator, other requests a Defined
Locator filled by a copy of the last returned mapping with the
Lifetime and Option fields reseted to the original values. An END NEXT
Option marks the end of the retrieval.</t>
</section>
<section title="GET/NEXT PCP Server Theory of Operation">
<t>The PCP Server behavior is described below: <list style="symbols">
<t>on the reception of a valid GET request the ordered list of
explicit dynamic mapping of the subscriber matching the given
Filter is (conceptually) built.</t>
<t>if the list is empty a NONEXIST_MAP error response is returned.
It includes no NEXT Option.</t>
<t>the list is scanned to find the Locator using the Equality
defined in <xref target="order"></xref>. If it is found the
mappings less than the Locator are removed from the list, so the
result is a list which begins by the mapping equals to the Locator
followed by greater mappings.</t>
<t>if the NEXT Option in the request is an END one, the first
mapping of the list is returned in an only NEXT option, marked END
if the list contains only this mapping, marked MORE otherwise.</t>
<t>if the NEXT option in the request is a MORE one, as many as can
fit mappings are returned in order in the response, marked as MORE
but if the whole list can be returned the last is marked END.</t>
</list>"Returned" means to include required options when they are
defined for a mapping: if the mapping M has 3 REMOTE_PEER_FILTERs and
the REMOTE_PEER_FILTER code was in the request NEXT, the NEXT carrying
M will get the 3 REMOTE_PEER_FILTER options embedded.</t>
</section>
<section title="Flow Examples">
<t>As an illustration example, let's consider the following explicit
dynamic mapping table is maintained by the PCP Server:</t>
<texttable align="center" anchor="mapping_table" style="full"
title="Excerpt of a mapping table">
<ttcol align="center">Pro</ttcol>
<ttcol align="center">Internal IP Address</ttcol>
<ttcol align="center">Internal Port</ttcol>
<ttcol align="center">External IP Address</ttcol>
<ttcol align="center">External Port</ttcol>
<ttcol align="center">Remaining Lifetime</ttcol>
<c>UDP</c>
<c>198.51.100.1</c>
<c>25655</c>
<c>192.0.2.1</c>
<c>15659</c>
<c>1659</c>
<c>TCP</c>
<c>198.51.100.2</c>
<c>12354</c>
<c>192.0.2.1</c>
<c>32654</c>
<c>3600</c>
<c>TCP</c>
<c>198.51.100.2</c>
<c>8596</c>
<c>192.0.2.1</c>
<c>25659</c>
<c>6000</c>
<c>UDP</c>
<c>198.51.100.1</c>
<c>19856</c>
<c>192.0.2.1</c>
<c>42654</c>
<c>7200</c>
<c>TCP</c>
<c>198.51.100.1</c>
<c>15775</c>
<c>192.0.2.1</c>
<c>32652</c>
<c>9000</c>
</texttable>
<t></t>
<t>As shown in <xref target="mapping_table"></xref>, the PCP Server
sorts the explicit dynamic mapping table using the internal IP address
and the remaining lifetime.</t>
<t><xref target="single_mapping_failed"></xref> illustrates the
exchange that occurs when a PCP Client tries to retrieve the
information related to a non-existing explicit dynamic mapping.</t>
<t><figure align="center" anchor="single_mapping_failed"
title="Example of a failed GET operation">
<artwork><![CDATA[
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| (1) PCP GET Request |
| protocol= TCP |
| internal-ip-address= 198.51.100.1 |
| internal-port= 59864 |
| Undefined Locator |
|---------------------------------->|
| |
| (2) PCP GET Response |
| error= NONEXIST_MAP |
|<----------------------------------|
| |
]]></artwork>
</figure></t>
<t><xref target="single_mapping_success"></xref> shows an example of a
PCP Client which retrieves successfully an existing mapping from the
PCP Server.</t>
<t><figure align="center" anchor="single_mapping_success"
title="Example of a successful GET operation">
<artwork><![CDATA[
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| (1) PCP GET Request |
| protocol= TCP |
| internal-ip-address= 198.51.100.1 |
| internal-port= 25655 |
| Undefined Locator |
|---------------------------------->|
| |
| (2) PCP GET Response |
| END |
| protocol= TCP |
| internal-ip-address= 198.51.100.1 |
| internal-port= 25655 |
| external-ip-address= 192.0.2.1 |
| external-port= 15659 |
| remaining-lifetime= 1659 |
|<----------------------------------|
| |
| (3) PCP MAP4 Request |
| protocol= TCP |
| internal-ip-address= 198.51.100.1 |
| internal-port= 25655 |
| external-ip-address= 192.0.2.1 |
| external-port= 15659 |
| requested-lifetime= 0 |
|---------------------------------->|
| |
]]></artwork>
</figure></t>
<t>In reference to <xref target="example"></xref>, the PCP Server
returns the explicit dynamic mappings having the internal address
equal to 192.0.2.1 ordered by increasing remaining lifetime.</t>
<t><figure align="center" anchor="example"
title="Flow example of GET/NEXT">
<artwork><![CDATA[
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| (1) PCP GET Request |
| internal-ip-address= 198.51.100.2 |
| Undefined Locator |
|---------------------------------->|
| |
| (2) PCP GET Response |
| MORE |
| protocol= TCP |
| internal-ip-address= 198.51.100.2 |
| internal-port= 12354 |
| external-ip-address= 192.0.2.1 |
| external-port= 32654 |
| remaining-lifetime= 3600 |
| END |
| protocol= TCP |
| internal-ip-address= 198.51.100.2 |
| internal-port= 8596 |
| external-ip-address= 192.0.2.1 |
| external-port= 25659 |
| remaining-lifetime= 6000 |
|<----------------------------------|
| |
]]></artwork>
</figure></t>
<t>In reference to <xref target="example_2"></xref>, the PCP Server
returns the explicit dynamic mappings having the internal address
equal to 192.0.2.2 ordered by increasing remaining lifetime. In this
example, the same internal port is used for TCP and UDP.</t>
<t><figure align="center" anchor="example_2"
title="Flow example of GET/NEXT: same internal port number">
<artwork><![CDATA[
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| (1) PCP GET Request |
| internal-ip-address= 198.51.100.1 |
| internal-port= 25655 |
| Undefined Locator |
|---------------------------------->|
| |
| (2) PCP GET Response |
| MORE |
| protocol= UDP |
| internal-ip-address= 198.51.100.1 |
| internal-port= 25655 |
| external-ip-address= 192.0.2.1 |
| external-port= 15659 |
| remaining-lifetime= 1659 |
| END |
| protocol= TCP |
| internal-ip-address= 198.51.100.1 |
| internal-port= 25655 |
| external-ip-address= 192.0.2.1 |
| external-port= 32652 |
| remaining-lifetime= 9000 |
|<----------------------------------|
| |
]]></artwork>
</figure></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:46:56 |