One document matched: draft-ietf-pcp-server-selection-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-ietf-pcp-server-selection-05"
ipr="trust200902" updates="6887">
<front>
<title abbrev="PCP Server Selection">PCP Server Selection</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>
<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="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<date day="19" month="August" year="2014" />
<workgroup>PCP Working Group</workgroup>
<keyword>PCP Server discovery, Port Mapping, Shared Address, Multiple PCP
Servers</keyword>
<abstract>
<t>The document specifies the behavior to be followed by a PCP client to
contact its PCP server(s) when one or several PCP server IP addresses
are configured.</t>
<t>This document updates RFC6887.</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 anchor="intro" title="Introduction">
<t>A host may have multiple network interfaces (e.g., 3G, IEEE 802.11,
etc.); each configured with different PCP servers. Each PCP server
learned must be associated with the interface on which it was learned.
Generic multi-interface considerations are documented in Section 8.4 of
<xref target="RFC6887"></xref>. Multiple PCP server IP addresses may be
configured on a PCP client in some deployment contexts such as
multi-homing (see <xref target="multihoming"></xref>). A PCP server may
also have multiple IP addresses associated with it. It is out of scope
of this document to enumerate all deployment scenarios that require
multiple PCP server IP addresses to be configured. Refer to <xref
target="I-D.boucadair-pcp-deployment-cases"></xref> for a discussion on
PCP deployment scenarios.</t>
<t>If a PCP client discovers multiple PCP server IP addresses, it needs
an indication to determine whether PCP entries are to be installed in
all or a subset of discovered IP addresses. This document makes the
following assumptions:</t>
<t><list style="symbols">
<t>There is no requirement that multiple PCP servers configured on
the same interface have the same capabilities.</t>
<t>PCP requests to different PCP servers are independent, the result
of a PCP request to one PCP server does not influence another.</t>
<t>The configuration mechanism must distinguish IP addresses that
belong to the same PCP server.</t>
</list></t>
<t>This document specifies the behavior to be followed by a PCP client
<xref target="RFC6887"></xref> to contact its PCP server(s) <xref
target="RFC6887"></xref> when it is configured with one or several PCP
server IP addresses (e.g., using DHCP <xref
target="RFC7291"></xref>).</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>PCP client: denotes a PCP software instance responsible for
issuing PCP requests to a PCP server. Refer to <xref
target="RFC6887"></xref>.</t>
<t>PCP server: denotes a software instance that receives and
processes PCP requests from a PCP client. A PCP server can be
co-located with or be separated from the function it controls (e.g.,
Network Address Translation (NAT) or firewall). Refer to <xref
target="RFC6887"></xref>.</t>
</list><?rfc subcompact="no" ?></t>
</section>
<section anchor="selection"
title="IP Address Selection: PCP Server with Multiple IP Addresses">
<t>This section describes the behavior of the PCP client to contact its
PCP server when the PCP client has multiple IP addresses for a single
PCP server.</t>
<t><list style="numbers">
<t>A PCP client should construct a set of candidate source addresses
(Section 4 of <xref target="RFC6724"></xref>), based on application
input and PCP <xref target="RFC6887"></xref> constraints. For
example, when sending a PEER or a MAP with FILTER request for an
existing TCP connection, the only candidate source address is the
source address used for the existing TCP connection. But, when
sending a MAP request for a wildcard bound server, the candidate
source addresses may be all IP addresses of the server or just the
IP address on which the server intends to explicitly listen.</t>
<t>The PCP client then sorts the PCP server IP addresses as per
Section 6 of <xref target="RFC6724"></xref> using the candidate
source addresses selected in the previous step as input to the
destination address selection algorithm.</t>
<t>The PCP client initializes its Maximum Retransmission Count (MRC)
to 4.</t>
<t>The PCP client sends its PCP messages following the
retransmission procedure specified in Section 8.1.1 of <xref
target="RFC6887"></xref>. If no response is received after MRC
attempts, the PCP client re-tries the procedure with the next IP
address in the sorted list. The PCP client SHOULD ignore any
response received from an IP address after exhausting MRC attempts
for that particular IP address. If, when sending PCP requests, the
PCP client receives a hard ICMP error <xref target="RFC1122"></xref>
it SHOULD immediately try the next IP address from the list of PCP
server IP addresses.</t>
<t>If the PCP client has exhausted all IP addresses configured for a
given PCP server, the procedure SHOULD be repeated every fifteen
(15) minutes until the PCP request is successfully answered.</t>
<t>Once the PCP client has successfully received a response from a
PCP server's IP address, all subsequent PCP requests to that PCP
server are sent on the same IP address until that IP address becomes
unresponsive. In case the IP address becomes unresponsive, the PCP
client to clears the cache of sorted destination address list and
follows the steps described above to contact the PCP server
again.</t>
</list></t>
<t>For efficiency, the PCP client SHOULD use the same Mapping Nonce for
requests sent to all IP addresses belonging to a single PCP server.</t>
</section>
<section anchor="sel" title="IP Address Selection: Multiple PCP Servers">
<t>This section describes the behavior of the PCP client to contact
multiple PCP servers; with each PCP server reachable on a list of IP
addresses. There is no requirement that these multiple PCP servers have
the same capabilities.</t>
<t>If several PCP servers are configured, each with multiple IP
addresses, the PCP client contacts all PCP servers using the procedure
described in <xref target="selection"></xref>.</t>
<t>As specified in Section 11.2 of <xref target="RFC6887"></xref>, the
PCP client must use different Mapping Nonces for each PCP server it
communicates with.</t>
<t>If the PCP client is configured, using some means, with the
capabilities of each PCP server, a PCP client may choose to contact all
PCP servers simultaneously or iterate with a delay.</t>
<t>This procedure may result in a PCP client instantiating multiple
mappings maintained by distinct PCP servers. The decision to use all
these mappings or delete some of them depends on the purpose of the PCP
request. For example, if the PCP servers are configuring firewall (not
NAT) functionality then the client would by default (i.e., unless it
knows that they all replicate state among them) need to use all the PCP
servers.</t>
</section>
<section title="Example: Multiple PCP Servers on a Single Interface">
<t><xref target="ex"></xref> depicts an example that is used to
illustrate the server selection procedure specified in <xref
target="selection"></xref> and <xref target="sel"></xref>. In this
example PCP servers (A and B) are co-located with edge routers (rtr1,
rtr2) with each PCP server controlling its own device.<figure
align="center" anchor="ex">
<artwork><![CDATA[ ISP Network
| |
.........................................................
| | Subscriber Network
+-------+--------+ +----+-----------+
| PCP-Server-A | | PCP-Server-B |
| (rtr1) | | (rtr2) |
+-------+--------+ +----+-----------+
192.0.2.1 | | 198.51.100.1
2001:db8:1111::1 | | 2001:db8:2222::1
| |
| |
-------+--------------+-----------
|
| 203.0.113.0
| 2001:db8:3333::1
+---+---+
| Host |
+-------+
Edge Routers (rtr1, rtr2)]]></artwork>
</figure></t>
<t>The example describes behavior when a single IP address for one PCP
server is not responsive. The PCP client is configured with two PCP
servers for the same interface, PCP-Server-A and PCP-Server-B each
having two IP addresses, an IPv4 address and an IPv6 address. The PCP
client wants an IPv4 mapping so it orders the addresses as follows:</t>
<t><list style="symbols">
<t>PCP-Server-A: <list style="symbols">
<t>192.0.2.1</t>
<t>2001:db8:1111::1</t>
</list></t>
<t>PCP-Server-B: <list style="symbols">
<t>198.51.100.1</t>
<t>2001:db8:2222::1</t>
</list></t>
</list></t>
<t>Suppose that:</t>
<t><list style="symbols">
<t>The path to reach 192.0.2.1 is broken</t>
<t>The path to reach 2001:db8:1111::1 is working</t>
<t>The path to reach 198.51.100.1 is working</t>
<t>The path to reach 2001:db8:2222::1 is working</t>
</list></t>
<t>It sends two PCP requests at the same time, the first to 192.0.2.1
(corresponding to PCP-Server-A) and the second to 198.51.100.1
(corresponding to PCP-Server-B). The path to 198.51.100.1 is working so
a PCP response is received. Because the path to 192.0.2.1 is broken, no
PCP response is received. The PCP client retries 4 times to elicit a
response from 192.0.2.1 and finally gives up on that address and sends a
PCP message to 2001::db8:1111:1. That path is working, and a response is
received. Thereafter, the PCP client should continue using that
responsive IP address for PCP-Server-A (2001:db8:1111::1). In this
particular case, it will have to use THIRD_PARTY option for IPv4
mappings.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>PCP related security considerations are discussed in <xref
target="RFC6887"></xref>.</t>
<t>This document does not specify how PCP server addresses are
provisioned on the PCP client. It is the responsibility of PCP server
provisioning document(s) to elaborate on security considerations to
discover legitimate PCP servers.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not request any action from IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Dave Thaler, Simon Perreault, and Hassnaa Moustafa for
their reviews and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.RFC.6724'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.1122'?>
<?rfc include='reference.RFC.4116'?>
<?rfc include='reference.I-D.boucadair-pcp-deployment-cases'?>
<?rfc include='reference.RFC.7291'?>
</references>
<section anchor="multihoming" title="Multi-homing">
<t>The main problem of a PCP multi-homing situation can be succinctly
described as 'one PCP client, multiple PCP servers'. As described in
<xref target="selection"></xref>, if a PCP client discovers multiple PCP
servers, it should send requests to all of them with assumptions
described in <xref target="intro"></xref>. </t>
<t>The following sub-sections describe multi-homing examples to
illustrate the PCP client behavior. </t>
<section title="IPv6 Multi-homing">
<t>In this example of an IPv6 multi-homed network, two or more routers
co-located with firewalls are present on a single link shared with the
host(s). Each router is in turn connected to a different service
provider network and the host in this environment would be offered
multiple prefixes and advertised multiple DNS servers. Consider a
scenario in which firewalls within an IPv6 multi-homing environment
also implement a PCP server. The PCP client learns the available PCP
servers using DHCP <xref target="RFC7291"></xref> or any other
provisioning mechanism. In reference to <xref
target="Figure1"></xref>, a typical model is to embed DHCP servers in
rtr1 and rtr2. A host located behind rtr1 and rtr2 can contact these
two DHCP servers and retrieve from each server the IP address(es) of
the corresponding PCP server.</t>
<t>The PCP client will send PCP requests in parallel to each of the
PCP servers.</t>
<t><?rfc needLines="20"?><figure anchor="Figure1"
title="IPv6 Multihoming">
<artwork align="left"><![CDATA[ ==================
| Internet |
==================
| |
| |
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+ ISP Network
| |
.........................................................
| |
| | Subscriber Network
+-------+---+ +----+------+
| rtr1 with | | rtr2 with |
| FW1 | | FW2 |
+-------+---+ +----+------+
| |
| |
-------+----------+------
|
+---+---+
| Host |
+-------+
]]><?rfc needLines="20"?></artwork>
</figure></t>
</section>
<section title="IPv4 Multi-homing">
<t>In this example an IPv4 multi-homed network described in 'NAT- or
RFC2260-based multi-homing' (Section 3.3 of <xref
target="RFC4116"></xref>), the gateway router is connected to
different service provider networks. This method uses
Provider-Aggregatable (PA) addresses assigned by each transit provider
to which the site is connected. The site uses NAT to translate the
various provider addresses into a single set of private-use addresses
within the site. In such a case, two PCP servers might have to be
present to configure NAT to each of the transit providers. The PCP
client learns the available PCP servers using DHCP <xref
target="RFC7291"></xref> or any other provisioning mechanism. In
reference to <xref target="Figure3"></xref>, a typical model is to
embed the DHCP server and the PCP servers in rtr1. A host located
behind rtr1 can contact the DHCP server to obtain IP addresses of the
PCP servers. The PCP client will send PCP requests in parallel to each
of the PCP servers.</t>
<t><?rfc needLines="20"?><figure anchor="Figure3"
title="IPv4 Multihoming">
<artwork><![CDATA[
=====================
| Internet |
=====================
| |
| |
+----+--------+ +-+------------+
| ISP1 | | ISP2 |
| | | |
+----+--------+ +-+------------+ ISP Network
| |
| |
..............................................................
| |
| Port1 | Port2 Subscriber Network
| |
+----+-------------------+
|rtr1: NAT & PCP servers |
| GW Router |
+----+-------------------+
|
|
|
-----+--------------
|
+-+-----+
| Host | (private address space)
+-------+]]></artwork>
</figure></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:32:36 |