One document matched: draft-ietf-pcp-server-selection-02.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-02"
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/>
<city>Rennes</city>
<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/>
<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/>
<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="06" month="January" year="2014"/>
<workgroup>PCP Working Group</workgroup>
<keyword>PCP Server discovery, Port Mapping, Shared Address</keyword>
<abstract>
<t>Multiple IP addresses may be configured on a PCP client in some
deployment contexts such as multi-homing. This document specifies the
behavior to be followed by the 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 title="Introduction">
<t>Multiple IP addresses may be configured on a PCP client in some
deployment contexts such as multi-homing (see <xref
target="multihoming"/>). A PCP server may also have multiple IP
addresses associated with it. This document specifies the behavior to be
followed by the PCP client <xref target="RFC6887"/> to contact its PCP
server(s) <xref target="RFC6887"> </xref> when it receives one or
several PCP server IP addresses (e.g., using DHCP <xref
target="I-D.ietf-pcp-dhcp"/>).</t>
<t>This document is not specific to DHCP; any other mechanism can be
used to configure PCP server IP addresses.</t>
<t>It is out of scope of this document to enumerate all deployment
scenarios that require multiple IP addresses to be configured.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:</t>
<t><list style="symbols">
<t>PCP server denotes a functional element that receives and
processes PCP requests from a PCP client. A PCP server can be
co-located with or be separated from the function (e.g., Network
Address Translation (NAT), firewall) it controls. Refer to <xref
target="RFC6887"/>.</t>
<t>PCP client denotes a PCP software instance responsible for
issuing PCP requests to a PCP server. Refer to <xref
target="RFC6887"/>.</t>
</list></t>
</section>
<section anchor="selection" title="IP Address Selection">
<t>These steps specify the behavior to be followed by the PCP client to
contact a PCP server when the PCP client has multiple IP addresses for a
single PCP server. Additional considerations to be taken into account
when the PCP client is multi-interfaced are specified in <xref
target="MIF"/>:</t>
<t><list style="numbers">
<t>If the PCP client can use both address families when
communicating to a particular PCP server, the PCP client SHOULD
select the source address of the PCP request to be of the same IP
address family as its requested PCP mapping (i.e., the address
family of the Requested External IP Address).</t>
<t>Whenever communicating with a PCP server, the rules of Section 6
of <xref target="RFC6724"/> SHOULD be followed by using the source
address 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 message to the PCP server's IP
address following the retransmission procedure specified in Section
8.1.1 of <xref target="RFC6887"/>. If no response is received after
MRC attempts, the PCP client re-tries the procedure excluding the
destination addresses which did not respond. 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"/> 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 is repeated every fifteen 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, it sends subsequent PCP requests to the
same server's IP address until that IP address becomes
non-responsive, which causes the PCP client to follow the steps
above to contact its PCP server.</t>
</list></t>
<t>For efficiency, the PCP client should use the same Mapping Nonce for
requests sent to all PCP server' IP addresses.</t>
<t>If several PCP servers are configured, each with multiple IP
addresses, the PCP client contacts all PCP servers in parallel following
the steps described above. 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 is
implementation-specific and only the PCP client can decide whether all
mappings are needed or only a subset of them.</t>
</section>
<section anchor="MIF" title="Multiple Interfaces">
<t>When an end host has multiple interfaces concurrently active (e.g.,
IEEE 802.11 and 3G), a PCP client would discover different PCP servers
over different interfaces. A host may have multiple network interfaces
(e.g, 3G, IEEE 802.11, etc.); each configured differently. Each PCP
server learned MUST be associated with the interface via which it was
learned. Particularly, the PCP client relies on the source IP address of
an outgoing PCP request to select which PCP server(s) to use.</t>
<t>Although multiple interfaces may be available, a PCP client might
choose to use just one based on, for example, cost and bandwidth
requirements, and therefore would need to send PCP requests to just one
PCP server.</t>
<t>Generic multi-interfaces considerations are documented in Section 8.4
of <xref target="RFC6887"/></t>
</section>
<section title="Example: Multiple PCP servers on a Single Interface">
<t><xref target="ex"/> depicts an example that is used to illustrate the
server selection procedure specified in <xref target="selection"/>.</t>
<t><figure align="center" anchor="ex">
<artwork><![CDATA[
ISP Network
| |
.........................................................
| | Subscriber Network
+-------+------+ +----+---------+
| PCP-Server-A | | PCP-Server-B |
| | | |
+-------+------+ +----+---------+
192.0.2.1 | | 198.51.100.1
2001:db8:2222::1 | | 2001:db8:3333::1
| |
| |
-------+--------------+-----------
|
| 203.0.113.0
| 2001:db8:1111::1
+---+---+
| Host |
+-------+
]]></artwork>
</figure>The example shows the experienced behavior when a single IP
address for one PCP server is not responsive. The PCP client is
configured with two PCP servers, 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>The PCP client 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"/>.</t>
<t>This document does not specify how PCP server addresses are
provisioned to the PCP client. It is the responsibility of any PCP
server provisioning document(s) to elaborate on the security
considerations to discover a legitimate PCP server.</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 for the review 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.3493'?>
<?rfc include='reference.RFC.1122'?>
<?rfc include='reference.RFC.1123'?>
<?rfc include='reference.RFC.4116'?>
<?rfc include='reference.I-D.ietf-pcp-dhcp'?>
</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"/>, if a PCP client discovers multiple PCP
servers, it should send requests to all of them in parallel with the
following assumptions:<list style="symbols">
<t>There is no requirement that multiple PCP servers have the same
capabilities.</t>
<t>PCP requests to different servers are independent, the result of
a PCP request to one server does not influence another.</t>
<t>If PCP servers provide NAT, it is out of scope how the client
manages ports across PCP servers. For example, whether PCP client
requires all external ports to be the same or whether there are
ports available at all.</t>
</list>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="I-D.ietf-pcp-dhcp"/> or any other
provisioning mechanism. In reference to <xref target="Figure1"/>, a
typical model is to embed DHCP servers in rtr1 and rtr2. A host
located behind rtr1 and rtr2 can contact these two DHCP server and
retrieves from each server the IP address of the corresponding PCP
server.</t>
<t>The PCP client will send PCP requests in parallel to each of the
PCP servers.</t>
<t><figure anchor="Figure1" title="IPv6 Multihoming">
<artwork align="left"><![CDATA[ ==================
| Internet |
==================
| |
| |
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+ ISP Network
| |
.........................................................
| |
| | Subscriber Network
+-------+---+ +----+------+
| rtr1 with | | rtr2 with |
| FW1 | | FW2 |
+-------+---+ +----+------+
| |
| |
-------+----------+------
|
+---+---+
| Host |
+-------+
]]></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"/>),
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 have to be present to control NAT to each of the
transit providers. The PCP client learns the available PCP servers
using DHCP <xref target="I-D.ietf-pcp-dhcp"/> or any other
provisioning mechanism. In reference to <xref target="Figure3"/>, 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><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:34:24 |