One document matched: draft-ietf-pcp-server-selection-01.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="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pcp-server-selection-01"
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="22" month="May" year="2013" />
<workgroup>PCP Working Group</workgroup>
<keyword>PCP Server discovery, Port Mapping, Shared Address</keyword>
<abstract>
<t>This document specifies the behavior to be followed by the PCP client
to contact its PCP server(s) when one or several PCP server names are
configured. Multiple names may be configured to a PCP client in some
deployment contexts such as multi-homing.</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>This document specifies the behavior to be followed by the PCP client
<xref target="RFC6887"></xref> to contact its PCP server(s) <xref
target="RFC6887"> </xref> when receiving one or several PCP server names
(e.g., using DHCP <xref target="I-D.ietf-pcp-dhcp"></xref>). This
document is not specific to DHCP; any other mechanism can be used to
configure PCP server names.</t>
<t>Multiple names may be configured to a PCP client in some deployment
contexts such as multi-homing (see <xref target="multihoming"></xref>).
It is out of scope of this document to enumerate all deployment
scenarios which require multiple names to be configured.</t>
<t>This document assumes appropriate name resolution means (e.g.,
Section 6.1.1 of <xref target="RFC1123"></xref>) are available on the
host client.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>PCP server denotes a functional element which 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"></xref>.</t>
<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>Name is a string that can be passed to getaddrinfo (Section 6.1
of <xref target="RFC3493"></xref>), such as a DNS name, address
literals, etc. A name may be a fully qualified domain name (e.g.,
"myservice.example.com."), IPv4 address in dotted-decimal form
(e.g., 192.0.2.33) or textual representation of an IPv6 address
(e.g., 2001:db8::1). </t>
</list><?rfc subcompact="no" ?></t>
</section>
<section title="Name Resolution">
<t>Each configured name is passed to the name resolution library (e.g.,
Section 6.1.1 of <xref target="RFC1123"></xref> or <xref
target="RFC6055"></xref>) to retrieve the corresponding IP address(es)
(IPv4 or IPv6). Then, the PCP client follows the procedure specified in
<xref target="selection"></xref> to contact its PCP server(s).</t>
<t>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.</t>
</section>
<section anchor="selection" title="IP Address Selection">
<t>This section specifies the behavior to be followed by the PCP client
to contact its PCP server(s) when receiving one or several PCP server
names:</t>
<t><?rfc subcompact="yes" ?></t>
<t><list style="numbers">
<t>If only one PCP server name is configured: if a list of IP
addresses is returned as a result of resolving the PCP server name,
the PCP client follows the procedure specified in <xref
target="series"></xref>.</t>
<t>If several PCP server names are configured: each name is treated
as a separate PCP server. Moreover, each name may be resolved into
one IP address or a list of IP addresses. The PCP client contacts in
parallel the first IP address of each name and follows the procedure
specified in <xref target="series"></xref> for the list of IP
addresses returned for each name. <xref target="examples"></xref>
provides some examples to illustrate this procedure.</t>
</list></t>
<t><?rfc subcompact="no" ?></t>
<t><!--Various use cases may be envisaged:
(1) Multiple PCP-controlled devices (e.g, IPv6 FW, NAT64 and NPTv6): these functions may be embedded in distinct devices:
"Procedure 2" is to be followed. But still the question is how the PCP client
is aware about the capabilities of each PCP-controlled device and how to bound an IP address to a PCP function?
(2) Co-located model (e.g., FW and NATxy functions): one single IP address is needed; "Procedure 1" is to be followed.
(3) When several IP addresses pointing to the same function are retrieved: "Procedure 1" is to be followed.
* case: chain of PCP servers: FW+NAT/NPT, two addresses may be used: capabilities of the PCP-controlled device
* Capabilities OPTION (see extension): to distinguish between these devices; how to associate capabilities/IP address
*** Do we need to indicate the capabilities in the DHCP option? See http://tools.ietf.org/html/draft-boucadair-pcp-extensions-02#section-4
-->This procedure does not require any knowledge of the capabilities of the
PCP-controlled device(s). Instead, the PCP client assumes each
configured name refer to a separate PCP server.</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 is deployment-specific. Only the
PCP client can decide whether all the mappings are needed or only a
subset of them.</t>
<section anchor="series" title="Serial Queries">
<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 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 tries with the next IP address in its list of
PCP server addresses. If it has exhausted its list, the procedure is
repeated every fifteen minutes until the PCP request is successfully
answered. If, when sending PCP requests the PCP client receives an
ICMP error (e.g., port unreachable, network unreachable) it SHOULD
immediately try the next IP address in the list. Once the PCP client
has successfully received a response from a PCP server address on that
interface, it sends subsequent PCP requests to that same server
address until that PCP server becomes non-responsive, which causes the
PCP client to attempt to re-iterate the procedure starting with the
first PCP server address on its list.</t>
</section>
</section>
<section anchor="examples" title="Examples">
<t>The following sub-sections provide three examples to illustrate the
procedure.</t>
<t>For all these examples, let's suppose pcpserver-x, pcpserver-y and
pcpserver-z are configured as PCP server names.</t>
<section title="Example 1">
<t>Let's also suppose:</t>
<t><figure>
<artwork><![CDATA[* IPx1 and IPx2 are returned for pcpserver-x; IPx1 is not reachable.
* IPy1 and IPy2 are returned for pcpserver-y; IPy1 is reachable
* IPz1 and IPz2 are returned for pcpserver-z; IPz1 is reachable]]></artwork>
</figure></t>
<t>The procedure to contact the PCP servers is as follows:</t>
<t><figure>
<artwork><![CDATA[* Send PCP requests to all servers: IPx1, IPy1 and IPz1
* Responses are received from IPy1 and IPz1 but not from IPx1
- The request is re-sent to IPx1
- If no response is received after four attempts, the request
is sent to IPx2
]]></artwork>
</figure></t>
</section>
<section title="Example 2">
<t>Now, if the following conditions are made:</t>
<t><figure>
<artwork><![CDATA[* IPx1 and IPx2 are returned for pcpserver-x; IPx1 is not reachable.
* IPy1 and IPy2 are returned for pcpserver-y; IPy1 is reachable
* IPz1 and IPz2 are returned for pcpserver-z; IPz1 is not reachable]]></artwork>
</figure></t>
<t>The procedure to contact the PCP servers lead to the following:</t>
<t><figure>
<artwork><![CDATA[* Send PCP requests to all servers: IPx1, IPy1 and IPz1
* A response is received from IPy1 but not from IPx1 and IPz1
- the requests are re-sent to IPx1 and IPz1
- If no response is received after four attempts, the request
is then sent to IPx2 and IPz2
]]></artwork>
</figure></t>
</section>
<section title="Example 3">
<t>Let's suppose now that:</t>
<t><figure>
<artwork><![CDATA[* IPx1 and IPx2 are returned for pcpserver-x; IPx1 is not reachable.
* IPy1 and IPy2 are returned for pcpserver-y; IPy1 is not reachable
* IPz1 and IPz2 are returned for pcpserver-z; IPz1 is not reachable]]></artwork>
</figure></t>
<t>The procedure to contact the PCP servers is as follows:</t>
<t><figure>
<artwork><![CDATA[* Send PCP requests to all servers: IPx1, IPy1 and IPz1
* No answer is received for all requests
- the requests are re-sent to IPx1, IPy1 and IPz1
- If no response is received after four attempts, the request
is then sent to IPx2, IPy2 and IPz2]]></artwork>
</figure></t>
<t></t>
</section>
</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 names are provisioned
to the PCP client. It is the responsibility of 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 D. Thaler for the review and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include='reference.RFC.6887'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3493'?>
<?rfc include='reference.RFC.1123'?>
<?rfc include='reference.RFC.6055'
?>
<?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"></xref>, if a PCP client discovers multiple PCP
server names, 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 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/NTP servers. Consider a
scenario in which firewalls within an IPv6 multi-homing environment
also implement a PCP server. PCP client learns of the available PCP
servers using DHCP <xref target="I-D.ietf-pcp-dhcp"></xref> or any
other PCP server discovery technique defined in future specifications.
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 |
+-------+---+ +----+------+
| |
| |
| |
-----+-+-----+------
|
+-+-----+
| Hosts |
+-------+]]></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 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. PCP client learns of the available PCP servers
using DHCP <xref target="I-D.ietf-pcp-dhcp"></xref> or any other PCP
server discovery technique defined in future specifications. The PCP
client will send PCP requests in parallel to each of the PCP
servers.</t>
<t><figure anchor="Figure3" title="IPv4 Multihoming">
<artwork align="left"><![CDATA[
====================
| Internet |
=====================
| |
| |
+----+--------+ +-+------------+
| ISP1 | | ISP2 |
| | | |
+----+--------+ +-+------------+ ISP Network
| |
| |
..............................................................
| |
| Port1 | Port2 Subscriber Network
| |
+----+-----------------+
| NAT & PCP servers |
| GW Router |
+----+-----------------+
|
|
|
-----+-+-----+------
|
+-+-----+
| Hosts | (private address space)
+-------+]]></artwork>
</figure></t>
</section>
<section title="Multiple interfaces and Servers">
<t>In case for multi-homing when an end host such as a mobile terminal
has multiple interfaces concurrently active (e.g., IEEE 802.11 and
3G), a PCP client would discover different PCP servers over different
interfaces. Although multiple interfaces are available, an application
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>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:29:51 |