One document matched: draft-reddy-pcp-server-discovery-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-reddy-pcp-server-discovery-00"
ipr="trust200902">
<front>
<title abbrev="PCP Serv Discovery in IPv6 Multihoming">PCP Server
Discovery in IPv6 Multihoming</title>
<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="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="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="Fred Baker" initials="F.J." surname="Baker">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date />
<workgroup>PCP Working Group</workgroup>
<abstract>
<t>A multihomed network may have a PCP server on each router connecting
to each upstream network, providing firewall or prefix translation
functions to hosts in the network. In these networks, a PCP client needs
to discover all of those PCP servers and then send PCP requests to them
individually.</t>
<t>This document proposes a multicast mechanism to discover PCP
servers.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Using <xref target="I-D.ietf-pcp-base">Port Control Protocol
(PCP)</xref> a host can create mappings with its NAT or firewall. PCP
expects only one PCP server. In a multihomed network, there may be
multiple PCP servers and the PCP client is unaware of all designated PCP
Servers in the network. For example, there may be a PCP server
integrated into every firewall device connecting to each network. Hence
there is a need for PCP client to discover all such PCP Servers with
specific functionalities so that the PCP client can make appropriate PCP
requests to each one of them.</t>
<t>This document proposes a means by which a PCP client can discover all
such PCP servers within the network. Each PCP server in the network
joins a certain multicast. Using the new DISCOVER OpCode, defined in
this document, each PCP client sends a DISCOVER request to that
multicast group address. Each PCP server responds with a DISCOVER
response. The PCP client then sends regular unicast PCP request messages
(e.g., MAP or PEER OpCodes) to each of those discovered PCP servers.</t>
</section>
<section anchor="notation" title="Notational Conventions">
<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"></xref>.</t>
</section>
<section anchor="multicast_pcp" title="DISCOVER OpCode">
<t>DISCOVER : Discover PCP servers listening on specific multicast
groups.</t>
<t>PCP Servers SHOULD provide a configuration option to allow
administrators to disable DISCOVER support if they wish. PCP DISCOVER
requests are only designed to discover appropriate PCP servers on the
network. The request does not offer functionality defined by other
Opcodes described in <xref target="I-D.ietf-pcp-base"></xref>.</t>
<t>The following diagram shows the usage of DISCOVER OpCode, where PCP
Server1 and PCP Server2 join the same multicast group (for e.g.
ALL-IPv6-FIREWALLS)</t>
<t><figure anchor="Figure1" title="PCP Server Discover">
<artwork align="left"><![CDATA[
+------+ +-------------+ +-------------+
| PCP | | PCP Server1 | | PCP Server2 |
|Client| | | | |
+------+ +-------------+ +-------------+
| | |
| PCP DISCOVER Request to ALL-IPv6-FIREWALLS |
| | |
|--------------------------->|--------------------->|
| PCP DISCOVER Response | |
|<---------------------------| |
| PCP DISCOVER Response | |
|<--------------------------------------------------|
| | |
| | |
| PCP MAP/PEER Request | |
|--------------------------->| |
| PCP MAP/PEER Request | |
|-------------------------------------------------->|
| | |
| PCP MAP/PEER Response | |
|<--------------------------------------------------|
| PCP MAP/PEER Response | |
|<---------------------------| |
| | | ]]></artwork>
</figure></t>
<section anchor="pcp_serv_join"
title="PCP Server joining a multicast group">
<t>Each PCP server in the network joins a certain multicast group
based on other functionalities embedded with it. Consider a scenario
in which a firewall also implements a <xref
target="I-D.ietf-pcp-base">Port Control Protocol (PCP)</xref> Server,
in which case it joins a multicast group ALL-IPv6-FIREWALLS.</t>
<t>A PCP server can join more than one mutlicast groups if it offers
multiple functionalities within the same device.</t>
</section>
<section anchor="pcp_clnt_disc" title="Generating a DISCOVER Request">
<t>To discover the PCP servers listening on each of the assigned
multicast addresses of interest to the PCP client, the PCP client
sends a DISCOVER request to each of those multicast addresses.</t>
<t>A Discover Nonce is included in the request by the PCP client. The
Discover Nonce is randomly chosen by the PCP client, and is used as
part of validation of PCP responses.</t>
<t>To accommodate packet loss, the request SHOULD be transmitted
several times with a random jitter between them to each of the
multicast address. It is RECOMMENDED to transmit the DISCOVER Request
a total of three times with the first retransmission after 5 seconds
plus a random value between 0-2.5 seconds, and again at 10 seconds
plus a random value between 0-5 seconds.</t>
<t>Periodic PCP DISCOVER requests should be made to determine the
updated list of PCP servers in the network. A PCP client can send
DISCOVER messages periodically every 600 seconds to each of the
multicast addresses.</t>
</section>
<section anchor="pcp_serv_process" title="Processing a DISCOVER Request">
<t>When a PCP server listening on one of the multicast groups as
described in <xref target="pcp_serv_join"></xref> receives a PCP
DISCOVER Opcode, after successful parsing and processing, it generates
a SUCCESS response with zero Assigned Lifetime. If a PCP DISCOVER
Request is received on an unassigned multicast group, it should be
ignored.</t>
<t>Each PCP Server sends a separate DISCOVER response with unicast
source address signaling to the PCP client that the source IPv6
address of DISCOVER response is the PCP Server address. The Discover
Nonce field from the request is copied into the PCP DISCOVER
response.</t>
</section>
<section title="Processing a DISCOVER Response">
<t>A DISCOVER request sent to the multicast group will result in zero,
one, or more responses from each of the addresses multicasted in <xref
target="pcp_serv_join"></xref>. If the network contains multiple
servers then multiple DISCOVER responses will normally be received.
After regular PCP response processing, a PCP client should check using
the Discover Nonce from the response to match with a previously sent
DISCOVER request and hence also determine the capability of the PCP
server.</t>
<t>If a DISCOVER request results in one or more DISCOVER response then
the client can update its PCP server list with the source addresses of
all DISCOVER responses. This list is essentially a list of all PCP
Servers in the network. Future specifications that use PCP DISCOVER to
discover PCP servers will also define how PCP clients will use the
discovered PCP server list.</t>
<t>A PCP server may join or leave a network unexpectedly (e.g., device
failure, link failure, or link recovery). To accommodate these
situations, the PCP client should also periodically send PCP DISCOVER
requests to each of the multicast groups to ensure that the client has
an updated list of PCP Servers.</t>
</section>
<section title="Discover Option Packet Format">
<t>The DISCOVER Opcode has a similar layout for both request and
response.</t>
<t>The following diagram shows the format of the Opcode-specific
information in a request for the DISCOVER Opcode:</t>
<t>The Requested Lifetime value MUST be set to zero in the PCP common
header.</t>
<t><figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Discover Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discover Nonce: Random value chosen by the PCP client.]]></artwork>
</figure></t>
<t>The following diagram shows the format of Opcode-specific
information in a response packet for the DISCOVER Opcode:</t>
<t><figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Discover Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discover Nonce: Copied from the request.]]></artwork>
</figure></t>
</section>
</section>
<section anchor="consider" title="Operational Considerations">
<t>This document defines a set of multicast addresses in several scopes.
Operationally, the choice of which scope is appropriate is made by the
administration. A reasonable default value in system configurations
might be Organization-Local (e.g., all firewalls operated by the
organization). However, a large organization might well choose
Site-Local or Admin-Local, and consider that "site" or "administrative"
domain to include the set of Firewalls advertising a default route into
a specific part of its network.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The principal security threat in this algorithm is a security threat
inherent to IP multicast routing and any application that runs on it. A
rogue system can join a multicast group and respond to discovery
requests pretending to be PCP servers. Discovery of such rogue systems
as PCP servers, in itself, is not a security threat if there is a means
for the PCP client to authenticate and authorize the discovered PCP
servers.</t>
<t>In addition, the security considerations in <xref
target="I-D.ietf-pcp-base"></xref> also apply to this use.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This note requests of the IANA the assignment of a new PCP Opcode</t>
<t><figure>
<artwork><![CDATA[ value Opcode
----- ---------
TBD DISCOVER]]></artwork>
</figure></t>
<t>This note also requests of the IANA the assignment of a set of
multicast addresses as described in Section 2.7 of the <xref
target="RFC4291">IP Version 6 Addressing Architecture</xref> from the
registry <xref target="v6mult"></xref>. This set of addresses is
referred to as "ALL-IPv6-FIREWALLS". One address should be assigned for
each of the following scopes: Link-Local, Admin-Local, Site-Local, and
Organization-Local.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4291"?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc ?>
<?rfc ?>
</references>
<references title="Informative References">
<reference anchor="v6mult"
target="http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml">
<front>
<title>IPv6 Multicast Address Space Registry</title>
<author fullname="IANA" surname="IANA">
<organization>IANA</organization>
</author>
<date month="December" year="2011" />
</front>
</reference>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:23:48 |