One document matched: draft-ietf-pcp-server-selection-03.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-03"
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="28" month="April" year="2014"/>
<workgroup>PCP Working Group</workgroup>
<keyword>PCP Server discovery, Port Mapping, Shared Address</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 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"/>. Multiple PCP server 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. 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"/> 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"/> to contact its PCP server(s) <xref
target="RFC6887"/> when it is configured with one or several PCP server
IP addresses (e.g., using DHCP <xref target="I-D.ietf-pcp-dhcp"/>).</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"/>.</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"/>.</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"/>), based on application input
and PCP <xref target="RFC6887"/> 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"/> 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"/>. 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"/> 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 PCP server IP addresses.</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"/>.</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"/> depicts an example that is used to illustrate the
server selection procedure specified in <xref target="selection"/> and
<xref target="sel"/>. 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:2222::1 | | 2001:db8:3333::1
| |
| |
-------+--------------+-----------
|
| 203.0.113.0
| 2001:db8:1111::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"/>.</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 and Simon Perreault for their 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.boucadair-pcp-deployment-cases'?>
<?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 with assumptions
described in Section-1. 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 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"/>),
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="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><?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:34 |