<?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>
