PCP Unsupported Family Error
draft-cheshire-pcp-unsupp-family-02

PCP working group                                            S. Cheshire
Internet-Draft                                                     Apple
Updates: 6887 (if approved)                                June 11, 2013
Intended status: Standards Track
Expires: December 13, 2013

                      PCP Unsupported Family Error
                  draft-cheshire-pcp-unsupp-family-02

Abstract

   The Port Control Protocol allows clients to request mappings in NAT
   gateways and firewalls.  The PCP UNSUPP_FAMILY error code enables PCP
   servers to inform clients when the requested external address family
   is not supported.

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

Cheshire                Expires December 13, 2013               [Page 1]
Internet-Draft              PCP UNSUPP_FAMILY                  June 2013

1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

2.  Introduction

   The Port Control Protocol [RFC6887] allows clients to request
   mappings in NAT gateways and firewalls.  A client can request a
   mapping to an external IPv6 address or to an external IPv4 address.
   The client signifies which family of external address it desires by
   the type of address it puts into the Suggested External Address
   field.

   If the client wants an external IPv6 address, then it populates the
   Suggested External Address field with a native IPv6 address.  In the
   overwhelmingly common case where the client doesn't know the external
   address when it makes its initial request, this will be the all-zeros
   IPv6 address (::).

   If the client wants an external IPv4 address, then it populates the
   Suggested External Address field with an IPv4-mapped IPv6 address
   (the first 80 bits set to zero, the next 16 set to one).  In the
   overwhelmingly common case where the client doesn't know the NAT's
   external address when it makes its initial request, this will be the
   all-zeros IPv4 address (::ffff:0:0).

   Note that while the specific address placed in the Suggested External
   Address field is merely a suggestion that the PCP server is free to
   ignore, the address family is not.  If the suggested address cannot
   be provided, another address of the same family SHOULD be provided if
   possible, but if the suggested address *family* cannot be provided by
   this PCP server, it MUST return a PCP error reply containing the
   UNSUPP_FAMILY error code.

   Many gateway devices, particularly early ones, may not be able to
   provide both external address families.  For example, an IPv4-only
   NAT cannot provide an external IPv6 address.

   Even with gateway devices that can support both external address
   families, the ability to provide the an external address of the
   requested family may depend on the family of the client's internal
   address.  For example, a gateway that supports native IPv6, and
   traditional NAT44, but not NAT64, can provide mappings from an
   internal IPv6 address to an external IPv6 address (typically the same

Cheshire                Expires December 13, 2013               [Page 2]
Internet-Draft              PCP UNSUPP_FAMILY                  June 2013

   address when no address translation is being performed), and can
   provide mappings from an internal IPv4 address to an external IPv4
   address, but not mappings from an internal IPv6 address to an
   external IPv4 address.  When such a gateway receives a request to map
   an internal IPv6 address to an external IPv4 address it MUST return
   the UNSUPP_FAMILY error code.

   Note that it is possible and valid for a given internal address and
   port to have two mappings simultaneously, one to an external IPv4
   address and one to an external IPv6 address.  The handling of
   outbound packets is determined by the outbound destination address;
   for example, an outbound IPv6 packet addressed to an IPv6 address in
   the NAT64 gateway's IPv6 address pool is translated to the
   corresponding IPv4 packet before forwarding; an outbound IPv6 packet
   addressed to some other routable IPv6 address is forwarded
   unmodified.

   A client that can handle both IPv6 and IPv4 external addresses MAY
   send two requests, and then determine its behaviour based on the
   responses it receives.  For example, if the client requests and
   receives an IPv6 external address, it may create a DNS AAAA record
   giving that IPv6 address.  If the client requests and receives an
   IPv4 external address, it may create a DNS address record giving that
   IPv4 address.  If the client requests and receives both families of
   external address, it may create both DNS records.  Or, if one
   external address is sufficient for the client, then it MAY first
   request its preferred address family, and only if that fails with an
   UNSUPP_FAMILY error, request the other family.

3.  Implications for RFC 6887

   Various sections of the PCP specification [RFC6887] describe clients
   and servers identifying a mapping by examining the three-tuple of
   { internal port, protocol, internal address } in a request or reply.
   For example:

      If the internal port, protocol, and internal address match an
      existing static mapping (which will have no nonce), then a PCP
      reply is sent giving the external address and port of that static
      mapping, using the nonce from the PCP request.  The server does
      not record the nonce.

      It is possible that a mapping might already exist for a requested
      internal address, protocol, and port.  If so, the PCP server takes
      the following actions...

Cheshire                Expires December 13, 2013               [Page 3]
Internet-Draft              PCP UNSUPP_FAMILY                  June 2013

      If no mapping exists for the internal address, protocol, and port,
      and the PCP server is able to create a mapping using the suggested
      external address and port, it SHOULD do so.

      After performing common PCP response processing, the response is
      further matched with a previously sent MAP request by comparing
      the internal IP address (the destination IP address of the PCP
      response, or other IP address specified via the THIRD_PARTY
      option), the protocol, the internal port, and the mapping nonce.
      Other fields are not compared, because the PCP server sets those
      fields.

   Everywhere that RFC 6887 refers to using the "internal port,
   protocol, and internal address" to identify a particular mapping, it
   should be read to mean the four-tuple of
   { int port, protocol, internal address, external address family }.

   PCP clients and servers that only support one external address family
   can continue to use the previous three-tuple
   { internal port, protocol, internal address } to identify a mapping,
   since they only support one external address family, and unilaterally
   reject requests and responses containing the unsupported family.  For
   PCP servers this means rejecting requests containing the unsupported
   address family via the UNSUPP_FAMILY error code.  For PCP clients
   this should be a non-issue because a PCP client should never receive
   a reply containing an external address family it didn't request, but
   should a client receive such a reply from a misbehaving PCP server
   offering an external address family the client did not request, the
   client MUST silently ignore the erroneous reply.

   An implication of this is that when renewing a mapping, a PCP client
   MUST include a suggested external address of the correct family, so
   that the gateway device can identify which mapping is being renewed.
   Ideally a PCP client SHOULD record the previously-granted external
   address and use that as the suggested external address in its renewal
   request, to facilitate recovery in the event of gateway state loss,
   but at the very least a PCP client MUST provide an all-zeroes
   suggested external address of the correct family (just as it must
   have indicated the desired address family in its initial request that
   created the mapping).

Cheshire                Expires December 13, 2013               [Page 4]
Internet-Draft              PCP UNSUPP_FAMILY                  June 2013

4.  IANA Considerations

   IANA should allocate the following PCP Result Code:

   14 UNSUPP_FAMILY: Unsupported external address family, e.g., IPv6 in
      a NAT that handles only IPv4.  This is a long lifetime error.

5.  Security Considerations

   This new error code leaks no sensitive information and creates no new
   security vulnerabilities.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              April 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 December 13, 2013               [Page 5]