Recursive PCP
draft-cheshire-recursive-pcp-00

PCP working group                                            S. Cheshire
Internet-Draft                                                     Apple
Intended status: Standards Track                             Feb 9, 2013
Expires: August 13, 2013

                             Recursive PCP
                    draft-cheshire-recursive-pcp-00

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 13, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Cheshire                 Expires August 13, 2013                [Page 1]
Internet-Draft                Recursive PCP                     Feb 2013

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   When NAT Port Mapping Protcol [NAT-PMP] 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.

   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:

   o  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.

   o  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.

   o  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.

   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 Port Control Protocol [PCP] (NAT-PMP's IETF
   Standards Track successor), in practice it's not clear how client
   devices would reliably learn this information.  Since the NAT

Cheshire                 Expires August 13, 2013                [Page 2]
Internet-Draft                Recursive PCP                     Feb 2013

   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.

   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.

   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.

2.  Operation of Recursive PCP

   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).

   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.

   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 PCP Anycast
   [Anycast].

Cheshire                 Expires August 13, 2013                [Page 3]
Internet-Draft                Recursive PCP                     Feb 2013

   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:

   o  Client's Internal Address and Port.

   o  External Address and Port allocated by this Recursive PCP server.

   o  Outermost External Address and Port allocated by the upstream PCP
      server.

   o  Mapping lifetime (also dictated by the upstream PCP server).

2.1.  Optimized Hairpin Routing

   A Recursive PCP server SHOULD implement Optimized Hairpin Routing.
   What this means is the following:

   o  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.

   o  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.

Cheshire                 Expires August 13, 2013                [Page 4]
Internet-Draft                Recursive PCP                     Feb 2013

2.2.  Recursive Application

   The protocol specified is described as "recursive" because of the
   following properties:

   o  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.

   o  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.

2.3.  Termination of Recursion

   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:

   o  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.

   o  A NAT gateway could determine automatically that if its external
      address is not one of the known private addresses
      [RFC1918][RFC6598] then its external address is a public routable
      IP address, and consequently it does not need to relay PCP
      requests upstream.

   o  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.

Cheshire                 Expires August 13, 2013                [Page 5]
Internet-Draft                Recursive PCP                     Feb 2013

3.  IANA Considerations

   No IANA actions are required by this document.

4.  Security Considerations

   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.

5.  References

5.1.  Normative References

   [PCP]      Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-29 (work in progress), November 2012.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
              Space", BCP 153, RFC 6598, April 2012.

5.2.  Informative References

   [Anycast]  Cheshire, S., "PCP Anycast Address",
              draft-cheshire-pcp-anycast-00 (work in progress),
              February 2013.

   [NAT-PMP]  Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
              draft-cheshire-nat-pmp-07 (work in progress),
              January 2013.

Cheshire                 Expires August 13, 2013                [Page 6]
Internet-Draft                Recursive PCP                     Feb 2013

Author's Address

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014
   USA

   Phone: +1 408 974 3207
   Email: cheshire@apple.com

Cheshire                 Expires August 13, 2013                [Page 7]