One document matched: draft-cheshire-recursive-pcp-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?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-cheshire-recursive-pcp-00" ipr="trust200902">
  <front>
    <title abbrev="Recursive PCP">Recursive PCP</title>

    <author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
      <organization abbrev="Apple">Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino</city>
          <region>California</region>
          <code>95014</code>
          <country>USA</country>
        </postal>
        <phone>+1 408 974 3207</phone>
        <email>cheshire@apple.com</email>
      </address>
    </author>

    <date day='9' month='Feb' year='2013'/>

    <workgroup>PCP working group</workgroup>

    <abstract>
      <t>The Port Control Protocol (PCP) allows clients to request
      explicit dynamic inbound and outbound port mappings in their their
      closest on-path NAT, Firewall, or other middlebox. However, in
      today's world, there may be more than one NAT on the path between
      a client and the public Internet.
      This document describes how the closest on-path middlebox
      generates a corresponding upstream PCP request to the next closest
      on-path middlebox, to request an appropriate explicit dynamic port
      mapping in that middlebox too. Applied recursively, this generates
      the necessary chain of port mappings in any number of middleboxes
      on the path between the client and the public Internet.</t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
      <t>When <xref target="NAT-PMP">NAT Port Mapping Protcol</xref> was first
      created in 2004, a common network configuration was that a residential
      customer received a single public routable IPv4 address from their ISP,
      and had a single NAT gateway serving multiple computers in their home.
      Consequently, creating appropriate mappings in that single NAT gateway
      was sufficient to provide full Internet connectivity.</t>

      <t>In today's world, with public routable IPv4 addresses becoming
      less readily available, it is increasingly common for customers to
      receive a private address from their ISP, and the ISP uses a NAT
      gateway of its own to translate those packets before sending them
      out onto the public Internet. This means that there is likely
      to be more than on NAT on the path between client machines and
      the public Internet:
        <list style='symbols'>
          <t>If a residential customer receives a translated address
          from their ISP, and then installs their own residential NAT
          gateway to share that address between multiple client devices
          in their home, then there are at least two NAT gateways on the
          path between client devices and the public Internet.</t>

          <t>If a mobile phone customer receives a translated address
          from their mobile phone carrier, and uses "Personal Hotspot"
          or "Internet Sharing" software on their mobile phone to make
          Wi-Fi Internet access available to other client devices, then
          there are at least two NAT gateways on the path between those
          client devices and the public Internet.</t>

          <t>If a hotel guest connects a portable Wi-Fi gateway, such as
          an Apple AirPort Express, to their hotel room Ethernet port to
          share their room's Internet connection between their phone, their
          iPad, and their laptop computer, then packets from the client devices
          may traverse the hotel guest's portable NAT, the hotel network's
          NAT, and the ISP's NAT before reaching the public Internet.</t>
        </list>
      </t>


      <t>While it is possible, in theory, that client devices could somehow
      discover all the NATs on the path, and communicate with each one
      separately using <xref target="PCP">Port Control Protocol</xref>
      (NAT-PMP's IETF Standards Track successor), in practice it's not
      clear how client devices would reliably learn this information.
      Since the NAT gateways are installed and operated by different
      individuals and organizations, no single entity has knowledge of
      all the NATs on the path. Also, even if a client device could
      somehow know all the NATs on the path, requiring a client device
      to communicate separately with all of them imposes unreasonable
      complexity on PCP clients, many of which are expected to be simple
      low-cost devices.</t>

      <t>In addition, this goes against the spirit of NAT gateways.
      The main purpose of a NAT gateway is to make multiple local
      client devices making outgoing TCP connections to appear,
      from the point of view of everything upstream of the NAT gateway,
      to be a single client device making outgoing TCP connections.
      In the same spirit, it makes sense for a PCP-capable NAT gateway
      to make multiple local client devices requesting port mappings to
      appear, from the point of view of everything upstream of the NAT
      gateway, to be a single client device requesting port mappings.</t>

      <t>This document specifies how a PCP-capable NAT gateway
      uses Recursive PCP to create the appearance of being a single
      device, from the point of view of the upstream network.</t>

    </section>

    <section anchor="operation" title="Operation of Recursive PCP">

      <t>Upon receipt of a PCP request from a local PCP client, a
      Recursive PCP server first examines its local mapping table to see
      if it already has a valid active mapping matching the Internal
      Address and Internal Port (and in the case of PEER requests,
      remote peer) given in the request. If so, it sends a reply giving
      the outermost External Address and Port (previously learned using
      Recursive PCP, as described below).</t>

      <t>If the Recursive PCP server does not already have a valid
      active mapping for this request, then it allocates an available
      port on its external interface. We assume for the sake of this
      description that the address of its external interface is itself
      a private address, subject to translation by an upstream NAT.</t>

      <t>The Recursive PCP server then constructs an appropriate
      corresponding PCP request of its own, and sends it to its upstream
      NAT. In the upstream PCP request, the Internal Address and
      Internal Port are the Recursive PCP server's own external address
      and port just allocated for this mapping. The Suggested External
      Address and Port in the upstream PCP request may be copied from
      the original PCP request. How the Recursive PCP server knows the
      destination IP address for its upstream PCP request is outside the
      scope of this document, but this may be achieved in a zero-configuration
      manner using <xref target="Anycast">PCP Anycast</xref>.</t>

      <t>Upon receipt of a PCP reply giving the outermost (i.e. publicly
      routable) External Address, Port and Lifetime, the Recursive PCP
      server records this information in its own mapping table and
      relays the information to the requesting downstream PCP client in a PCP reply.
      The Recursive PCP server therefore records, among other things,
      the following information in its mapping table:
        <list style='symbols'>
          <t>Client's Internal Address and Port.</t>
          <t>External Address and Port allocated by this Recursive PCP server.</t>
          <t>Outermost External Address and Port allocated by the upstream PCP server.</t>
          <t>Mapping lifetime (also dictated by the upstream PCP server).</t>
        </list>
      </t>

      <section anchor="hairpin" title="Optimized Hairpin Routing">
        <t>A Recursive PCP server SHOULD implement Optimized Hairpin
        Routing. What this means is the following:
          <list style='symbols'>
            <t>If a Recursive PCP server observes an outgoing packet
            arriving on its internal interface that is addressed to
            an External Address and Port appearing in the NAT gateway's
            own mapping table, then the NAT gateway SHOULD (after creating a
            new outbound mapping if one does not already exist) rewrite the
            packet appropriately and deliver it to the internal client
            currently allocated that External Address and Port.</t>
            <t>If a Recursive PCP server observes an outgoing packet
            arriving on its internal interface which is addressed to an
            Outermost External Address and Port appearing in the NAT
            gateway's own mapping table, then the NAT gateway SHOULD do
            likewise: create a new outbound mapping if one does not
            already exist, and then rewrite the packet appropriately and
            deliver it to the internal client currently allocated that
            Outermost External Address and Port. This is not necessary
            for successful communication, but for efficiency. Without
            this Optimized Hairpin Routing, the packet will be delivered
            all the way to the outermost NAT gateway, which will then
            perform standard hairpin translation and send it back. 
            Using knowledge of the Outermost External Address and Port,
            this rewriting can be anticipated and performed locally, which
            will typically offer higher throughput and lower latency than
            sending it all the way to the outermost NAT gateway and back.</t>
          </list>
        </t>
      </section>

      <section anchor="recursion" title="Recursive Application">
        <t>The protocol specified is described as "recursive" because
        of the following properties:
          <list style='symbols'>
            <t>Although the description above refers to an incoming
            PCP request being received from a local PCP client, that
            local PCP client could itself be a Recursive PCP server
            relaying a request on behalf of one of its own local downstream PCP clients
            (which could itself be another Recursive PCP server, and so on).
            The fact that the Recursive PCP server receiving the request
            does not need to be aware of this or take any special action,
            is an important simplifying property of the protocol.
            The purpose of a NAT gateway is to make many local client
            devices appear to be a single client device, and the purpose
            of a Recursive PCP server is to make many local client
            devices making PCP requests appear to be a single client
            device making PCP requests.</t>
            <t>Although the description above suggests that the upstream
            PCP server may be the final outermost NAT gateway, in fact that
            upstream PCP server could itself be another Recursive PCP
            server making requests to its own upstream PCP server,
            and relaying back the corresponding replies.</t>
          </list>
        </t>
      </section>

      <section anchor="termination" title="Termination of Recursion">
        <t>Any recursive algorithm needs a mechanism to terminate the
        recursion at the appropriate point. This termination of recursion
        can be achieved in a variety of ways:
          <list style='symbols'>
            <t>An ISP's NAT gateway could be configured to know
            that it is the outermost NAT gateway, and consequently
            does not need to relay PCP requests upstream. In fact,
            it may be the case that many large-scale NATs of the kind
            used by ISPs may simply not implement Recursive PCP,
            thereby naturally terminating the recursion at that point.</t>
            <t>A NAT gateway could determine automatically that if its
            external address is not one of the known private addresses
            <xref target="RFC1918"/><xref target="RFC6598"/> then
            its external address is a public routable IP address, and
            consequently it does not need to relay PCP requests upstream.</t>
            <t>A NAT gateway could attempt sending PCP requests upstream,
            and upon failing to receive any positive reply (e.g. receiving
            ICMP host unreachable, ICMP port unreachable, or a timeout)
            conclude that it does not need to relay PCP requests upstream.</t>
          </list>
        </t>
      </section>

    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>No IANA actions are required by this document.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>No new security concerns are raised by use of Recursive PCP.
      Since the purpose of a NAT gateway is to enable multiple client devices
      to appear as a single client device to the upstream network,
      a NAT gateway implementing Recursive PCP maintains this property,
      appearing to the upstream network to be a single client device
      using PCP to request port mappings for itself.
      Whether those port mappings are for multiple processes running on
      multiple CPUs connected via an internal bus in a single computer,
      or multiple processes running on multiple CPUs connected via an IP
      network, is transparent to the external network.</t>
    </section>

  </middle>

  <back>
    <?rfc needLines="8" ?>
    <references title="Normative References">
      <?rfc include="reference.RFC.1918"?>
      <?rfc include="reference.RFC.6598"?>
      <reference anchor="PCP">
        <front>
          <title>Port Control Protocol (PCP)</title>
          <author initials='D' surname='Wing' fullname='Dan Wing'><organization /></author>
          <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'><organization /></author>
          <author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'><organization /></author>
          <author initials='R' surname='Penno' fullname='Reinaldo Penno'><organization /></author>
          <author initials='P' surname='Selkirk' fullname='Paul Selkirk'><organization /></author>
          <date month='November' day='7' year='2012' />
          <abstract><t>The Port Control Protocol allows an IPv6 or IPv4
          host to control how incoming IPv6 or IPv4 packets are
          translated and forwarded by a network address translator (NAT)
          or simple firewall, and also allows a host to optimize its
          outgoing NAT keepalive messages.</t></abstract>
        </front>
        <seriesInfo name='Internet-Draft' value='draft-ietf-pcp-base-29' />
        <format target="http://tools.ietf.org/id/draft-ietf-pcp-base-29.txt" type="TXT" />
      </reference>

    </references>

    <references title="Informative References">

      <reference anchor="Anycast">
        <front>
          <title>PCP Anycast Address</title>
          <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'><organization /></author>
          <date month="February" day="7" year="2013" />
        </front>
        <seriesInfo name="Internet-Draft" value="draft-cheshire-pcp-anycast-00" />
        <format target="http://tools.ietf.org/id/draft-cheshire-pcp-anycast-00.txt" type="TXT" />
      </reference>

      <reference anchor="NAT-PMP">
        <front>
          <title>NAT Port Mapping Protocol (NAT-PMP)</title>
          <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'><organization /></author>
          <date month="January" day="26" year="2013" />
        </front>
        <seriesInfo name="Internet-Draft" value="draft-cheshire-nat-pmp-07" />
        <format target="http://tools.ietf.org/id/draft-cheshire-nat-pmp-07.txt" type="TXT" />
      </reference>

    </references>

  </back>
</rfc>