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]