PCP Working Group R. Penno, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track June 16, 2013 Expires: December 18, 2013 PCP Stability of External Address Recommendations draft-penno-pcp-ext-addr-01 Abstract This document recommends PCP Server and client behavior in light of Address Pooling Paired. Requirements Language 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 RFC 2119 [RFC2119]. 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 18, 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 Penno Expires December 18, 2013 [Page 1] Internet-DraPCP Stability of External Address Considerations June 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Proposed Behavior . . . . . . . . . . . . . . . . . . . . . . 2 3. Use-Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. PCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 5. PCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 6. PCP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 4 7. Implementation Considerations . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 10.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document recommends PCP Server behavior in light of Address Pooling Paired (APP). Address Pooling Paired is defined in [RFC4787] REQ-2. 2. Proposed Behavior In some recent discussions within the working group it was suggested that the text below from [RFC6887] may need changes: The MAP and PEER requests include a Suggested External IP Address field. Some PCP-controlled devices, especially CGN but also multi- homed NPTv6 networks, have a pool of public-facing IP addresses. PCP allows the client to indicate if it wants a mapping assigned on a specific address of that pool or any address of that pool. Some applications will break if mappings are created on different IP addresses (e.g., active mode FTP), so applications should carefully consider the implications of using this capability. Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address, and if the suggested external IP address is the IPv4 or IPv6 all- zeros address, PCP SHOULD assign its mappings to the same external address, as this can also help applications using a mix of both static mappings and PCP-created mappings. If, on the other hand, the suggested external IP address contains a non-zero IP address Penno Expires December 18, 2013 [Page 2] Internet-DraPCP Stability of External Address Considerations June 2013 the PCP server SHOULD create a mapping to that external address, even if there are other mappings from that same internal address to a different external address. Once an internal address has no implicit dynamic mappings and no explicit dynamic mappings in the PCP-controlled device, a subsequent implicit or explicit mapping for that internal address MAY be assigned to a different External address. Generally, this reassignment would occur when a CGN device is load balancing newly seen internal addresses to its public pool of external addresses. Specifically, it says: Once an internal address has no implicit dynamic mappings and no explicit dynamic mappings in the PCP-controlled device, a subsequent implicit or explicit mapping for that internal address MAY be assigned to a different External address. That implies the corollary: While an internal address has *some* mappings in the PCP-controlled device, new implicit or explicit mappings for that internal address SHOULD be assigned the *same* external address. Unfortunately, while it implies this, it does not actually state it. To clarify this the working group proposes submitting the following erratum: Change: ... Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address, and if the suggested external IP address is the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to the same external address, as this can also help applications using a mix of both static mappings and PCP-created mappings. To: ... Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address. If the suggested external IP address is the IPv4 or IPv6 all-zeros address, and the internal address currently has *any* active mappings (implicit, explicit, or static) with an external address of the indicated address family, then that external address SHOULD be used for the new mapping, so that PCP behavior follows NAT requirements of REQ-2 of [RFC4787] and REQ-2 of [RFC6888].If the existing mappings for that external address family do not all share a single Penno Expires December 18, 2013 [Page 3] Internet-DraPCP Stability of External Address Considerations June 2013 external address, then the choice of which external address is assigned for the new mapping is implementation dependent. 3. Use-Case The internal host creates real mappings for its services, and creates SRV records giving the external ports. The question is whether those SRV records can share a single target hostname, which points to a single target address (which is what Mac OS X currently does). Requiring the code to potentially generate multiple different target hostnames pointing to different target addresses would add significant complexity (which is why we haven't done that). With NAT-PMP [RFC6886] this was not an issue because there was only a single external address. 4. PCP Server Behavior If the PCP Server can not maintain APP behavior for a new mapping then it should fail the request and send a CANNOT_PROVIDE_EXTERNAL error back to the client. [N.E.] This is a departure from RFC6887 which says CANNOT_PROVIDE_EXTERNAL error can only be sent back to client when PREFER_FAILURE was used in the request. But since APP is mandatory, one could argue there is an implicit PREFER_FAILURE. Should we come up with a more descriptive error code? Or maybe we use NO_RESOURCES? 5. PCP Client Behavior If a PCP client that has active mappings receives an error code of CANNOT_PROVIDE_EXTERNAL (NO_RESOURCES?) for a new request it might mean that this new request would break APP behavior. The client should not interpret this as that the NAT having no more free external IP address and ports overall. [N.E.] should there be an option for the client to say it does not care about APP? The server of course does not need to honor such request, but for certain applications such as SSH, Telnet, HTTP, DNS, maintaining APP might not be needed. 6. PCP Proxy Behavior If a PCP Proxy [I-D.ietf-pcp-proxy] has an associated NAT and can not maintain APP behavior for a new mapping, it should fail the request locally instead of forwarding it to the next upstream PCP Server. If the upstream Proxy can not main APP for the new mapping, it should fail the request, which will cause the downstream Proxy to also fail Penno Expires December 18, 2013 [Page 4] Internet-DraPCP Stability of External Address Considerations June 2013 the request. [N.E.] In the case of a CPE with a single public external address that acts as a PCP Proxy this might cause an application writer to interpret this error code as the local PCP Proxy running out of ports, which is not the case. 7. Implementation Considerations PCP cannot require much more from NATs than what is already in RFC 4787s and 6888. RFC 4787 requires of all NATs: REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". RFC 6888 makes this requirement stronger for CGNs in particular: REQ-2: A CGN MUST have a default "IP address pooling" behavior of "Paired" If an application depends on this NAT behaviour, then it should use the PREFER_FAILURE option because a host behind a NAT cannot rely on its external address being always the same for a variety of reasons. More discussion can be found in [I-D.ietf-behave-requirements-update] section 5. 8. Security Considerations TBD. 9. Acknowledgements Stuart Cheshire for starting the discussion leading to this document. Simon Perrault for implementation considerations. 10. References 10.1. Normative References [I-D.ietf-behave-requirements-update] Penno, R., Perreault, S., Boucadair, M., and K. Naito, "Network Address Translation (NAT) Behavioral Requirements Updates", draft-ietf-behave-requirements-update-00 (work in progress), June 2013. [I-D.ietf-pcp-proxy] Boucadair, M., Penno, R., and D. Wing, "Port Control Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02 (work in progress), February 2013. Penno Expires December 18, 2013 [Page 5] Internet-DraPCP Stability of External Address Considerations June 2013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, April 2013. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013. 10.2. Informative References [I-D.cheshire-recursive-pcp] Cheshire, S., "Recursive PCP", draft-cheshire-recursive- pcp-02 (work in progress), March 2013. Author's Address Reinaldo Penno (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose 95134 USA Email: repenno@cisco.com Penno Expires December 18, 2013 [Page 6]