One document matched: draft-patil-pcp-multihoming-00.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-patil-pcp-multihoming-00" ipr="trust200902">
<front>
<title abbrev="PCP in Multihoming">Using PCP to control NAT and Firewalls
in Multihoming</title>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marthalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<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>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<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>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>
<date />
<workgroup>PCP Working Group</workgroup>
<abstract>
<t>This note describes how Port Control Protocol (PCP) can be used to
control NATs and Firewalls in multihoming deployments.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>A host can use the Port Control Protocol (PCP) to flexibly manage the
IP address and port mapping information on Network Address Translators
(NATs) or firewalls, to facilitate communications with remote hosts. In
a multihomed network, there may be multiple PCP servers providing
Firewall or prefix translation functions to hosts in the network.</t>
<t>This document covers PCP related considerations in IPv4 and IPv6
multihomed networks.</t>
</section>
<section title="Problem Statement">
<t>The main problem of a PCP multihoming situation can be succintly
described as 'one client, multiple servers'. <xref
target="I-D.ietf-pcp-base">PCP-base</xref> does not address how a PCP
Client should behave in a situation when it discovers multiple PCP
Servers and therefore many questions are open to standardization. For
example, if multiple PCP Servers are discovered through the same
interface, should the client send PCP requests be sent to all of them?
Are there significant differences between a multihoming and
high-availability scenarios? If yes, how can a PCP Client determine one
versus the other. These are just a few questions related to the
problem.</t>
<t>In this document we make the following simplifying assumption:</t>
<t><list style="symbols">
<t>Whenever a PCP Client discovers multiple PCP Servers, it will
send requests to all of them in parallel as described in <xref
target="I-D.boucadair-pcp-server-selection"></xref>.</t>
<t>There is no requirement that multiple PCP Servers have the same
capabilities.</t>
<t>PCP Requests to different servers are independent, meaning that
the result of a PCP request to one server does not influence
another.</t>
<t>If PCP Servers provides 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>In all scenarios below PCP client has a single interface unless
explicitly noted otherwise.</t>
</section>
<section anchor="ipv6_multi" title="IPv6 Multihoming">
<t>In an IPv6 multihomed 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 multihoming environment also implement a PCP
Server. PCP client learns of the available PCP servers by 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 as
described in <xref
target="I-D.boucadair-pcp-server-selection"></xref>.</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 anchor="ipv4_multi" title="IPv4 Multihoming">
<t>In an IPv4 multihomed network, the gateway router is connected to
different service provider networks. The host is connected to the
gateway router and is given a private IPv4 address oblivious to the fact
that there are multiple service providers. The Gateway router will be
configured with multiple PCP proxy servers, each corresponding to an
upstream PCP server. Each PCP Server is announced independently since it
is within a different ISP. PCP client can learn these multiple PCP proxy
addresses using DHCP or any other PCP server discovery technique. The
PCP client, by sending PCP requests in parallel to both the PCP proxies,
will learn the external IP addresses and ports allocated by each of the
upstream PCP servers. The Gateway router which implements a PCP Proxy
<xref target="I-D.bpw-pcp-proxy"></xref> , creates local NAT state,
modifies the PCP request and forwards it to the PCP server. The incoming
PCP response will be updated by the PCP Proxy and forwarded to the PCP
client.</t>
<figure anchor="Figure3"
title="IPv4 Multihomed environment with Gateway Router performing NAPT">
<artwork align="left"><![CDATA[
====================
| Internet |
=====================
| |
| |
+----+--------+ +-+------------+
| ISP1 | | ISP2 |
| PCP ServerA | | PCP ServerB |
+----+--------+ +-+------------+ ISP Network
| |
| |
..............................................................
| |
| Port1 | Port2 Subscriber Network
| |
+----+-----------------+
| NAPT & PCP Proxy |
| GW Router |
+----+-----------------+
|
|
|
-----+-+-----+------
|
+-+-----+
| Hosts | (private address space)
+-------+]]></artwork>
</figure>
<t></t>
</section>
<section title="Other Multihoming use cases">
<section title="IPv6 Network-Managed Firewall ">
<t>A network-managed Firewall uses the same techniques as the
premises-based firewall, but the firewall service is delivered using a
security appliance positioned in the ISP. The requesting router in
customer premises may obtain the PCP server addresses from the ISP
delegating router, and then pass that configuration information on to
the PCP clients through a DHCP server in the requesting router in the
customer premises. The PCP client can also learn PCP servers using
other PCP server discovery techniques. Each PCP Server is announced
independently since it is within a different ISP.</t>
<figure anchor="Figure2" title="Network-Managed Firewall">
<artwork align="left"><![CDATA[ ====================
| Internet |
=====================
| |
| |
+----+------+ +-+---------+
| | | |
| ISP1 with | | ISP2 with |
| FW1 | | FW2 |
+----+------+ +-+---------+ ISP Network
| |
............................................................
| |
| Port1 | Port2 Subscriber Network
| |
+----+-----------------+
| Gateway |
| Router |
+----+-----------------+
|
|
|
-----+-+-----+------
|
+-+-----+
| Hosts |
+-------+]]></artwork>
</figure>
<t></t>
<t>When the PCP client sends a PCP request to the PCP server deployed
in the ISP and the source address of the PCP request is not the one
that is delegated by the upstream ISP, then that PCP request will be
dropped at the ISP by its ingress filter rule. Ingress filtering is
becoming more popular among ISPs to mitigate the damage of
denial-of-service (DoS) attacks as explained in section 2.1.2 of <xref
target="RFC5220"></xref>. In IPv6 multihoming the PCP client will
eventually learn that the PCP server responds to only PCP requests
with specific source address after few attempts and hence can discard
sending PCP requests with wrong source address to the PCP server
provided by the ISP.</t>
</section>
<section anchor="PBR" title="IPv4 Policy based Routing">
<t>Policy based Routing (PBR) with multi-homing is typically used in
enterprises to route packets from the same source IP address to
different ISP based on configuration policies and match conditions
based on source IP address, destination IP address, destination port,
DSCP value(s), L4 and L7 protocols (e.g., SIP, RTP, RTSP) etc. For
e.g. a site with Dual WAN connections Gold-ISP, Bronze-ISP and uses
Gold-ISP for certain traffic only (e.g. Media). In such a environment
NAT has different NAT pools and would rely on pre-configured PBR
policy to determine which NAT address pool to use when an IP packet
comes from an internal host. PCP allows a host to interact with a
PCP-controlled NAT device and request an external IP and port.
Therefore a PCP Server that controls the NAT device with PBR and
receives a PCP request from a PCP client needs to know from which NAT
pool to allocate an external IP address and port.</t>
<t>The PCP PEER request would contain the destination IP address,
destination port and transport protocol of the remote peer that the
PCP client will be trying to communicate with. The PCP MAP request
with FILTER option would also contain the destination IP address,
transport port but the destination port could be all ports. The NAT
device based on the information present in the PCP request can
possibly select the NAT pool, create mapping and return the external
IP address and port in PCP response.</t>
<t>There is also a possibility that PBR is determined based on other
information like L7 protocol, DSCP value(s) that is not conveyed by
default in the PCP PEER or MAP with FILTER option. Further In case of
PCP MAP request with just the 3-tuple information (internal port,
protocol and source IP address), the NAT device does not know which
NAT pool to use. Hence if the information conveyed in PCP request is
not sufficient to execute the policy then the PCP server will return a
new error code (PROVIDE_MORE_DATA) in the PCP response to the PCP
client asking it to provide additional information in subsequent PCP
requests. The PCP client can then convey more information like
DESCRIPTION, DSCP_POLICY using the PCP extensions defined in <xref
target="I-D.boucadair-pcp-extensions"></xref>.</t>
</section>
</section>
<section title="Multiple interfaces and Servers">
<t>One interesting case for PCP multi-homing is when a end host such as
a mobile terminal has multiple interfaces concurrently active, for
example, Wi-Fi and 3G. In this case 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, bandwidth requirements, and therefore would need to send PCP
requests to just one PCP Server.</t>
<t>This scenario requires further discussion. TBD</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Security considerations in <xref target="I-D.ietf-pcp-base"></xref>
apply to this use.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>The following PCP result code is to be allocated :
PROVIDE_MORE_DATA</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc include='reference.I-D.ietf-pcp-dhcp'?>
<?rfc include='reference.I-D.bpw-pcp-proxy'?>
<?rfc include='reference.I-D.boucadair-pcp-extensions'?>
<?rfc include='reference.I-D.boucadair-pcp-server-selection'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5220"?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:28 |