PCP working group S. Cheshire Internet-Draft Apple Intended status: Standards Track October 27, 2011 Expires: April 29, 2012 PCP Rapid Recovery draft-cheshire-pcp-recovery-02 Abstract Port Control Protocol (PCP) Rapid Recovery allows PCP clients to repair failed mappings within seconds, rather than the minutes or hours it might take if they relied solely on waiting for the next routine renewal of the mapping. Mapping failures may occur when a NAT gateway is rebooted and loses its mapping state, or when a NAT gateway has its external IP address changed so that its current mapping state becomes invalid. 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 April 29, 2012. Copyright Notice Copyright (c) 2011 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 Cheshire Expires April 29, 2012 [Page 1] Internet-Draft PCP Rapid Recovery October 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Terminology 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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 2. Introduction Port Control Protocol [PCP] allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its outgoing NAT keepalive messages. PCP Rapid Recovery allows PCP clients to repair failed mappings within seconds, rather than the minutes or hours it might take if they relied solely on waiting for the next routine renewal of the mapping. Mapping failures may occur when a NAT gateway is rebooted and loses its mapping state, or when a NAT gateway has its external IP address changed so that its current mapping state becomes invalid. 3. PCP Restart Announcement When a PCP server device [PCP] that implements PCP Rapid Recovery reboots, restarts its NAT engine, or otherwise enters a state where it may have lost some or all of its previous mapping state (or enters a state where it doesn't even know whether it may have had prior state that it lost) it MUST inform PCP clients of this fact by multicasting the UDP packet shown below on all multicast-capable interfaces on which it accepts PCP requests. A PCP server device which accepts PCP requests over IPv4 sends the Restart Announcement to the IPv4 multicast address 224.0.0.1:5350. A PCP server device which accepts PCP requests over IPv6 sends the Restart Announcement to the IPv6 multicast address [FF02::1]:5350. A PCP server device which accepts PCP requests over both IPv4 and IPv6 sends a pair of Restart Announcements, one to each multicast address. To accommodate packet loss, the PCP server device MAY transmit such packets (or packet pairs) up to ten times (with an appropriate Epoch time value in each to reflect the passage of time between transmissions) provided that the interval between the first two notifications is at least 250ms, and the interval between subsequent notification at Cheshire Expires April 29, 2012 [Page 2] Internet-Draft PCP Rapid Recovery October 2011 least doubles. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version = 1 |1| OpCode = 0 | Reserved = 0 | Result = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PCP Restart Announcement Packet A PCP client that implements PCP Rapid Recovery MUST listen to receive these PCP Restart Announcements on all multicast-capable interfaces on which it sends PCP requests. A PCP client device which sends PCP requests using IPv4 MUST listen for packets sent to the IPv4 multicast address 224.0.0.1:5350. A PCP client device which sends PCP requests using IPv6 MUST listen for packets sent to the IPv6 multicast address [FF02::1]:5350. A PCP client device which sends PCP requests using both IPv4 and IPv6 MUST listen for both types of Restart Announcement. (The SO_REUSEPORT socket option or equivalent should be used for the multicast UDP port, if required by the host OS to permit multiple independent listeners on the same multicast UDP port.) Upon receiving a PCP Restart Announcement a PCP client MUST (as it does with all received PCP response packets) inspect the Announcement's source IP address, and if the Epoch value is outside the expected range for that server [PCP], then for all PCP mappings it made at that address the client should issue new PCP requests to to recreate any lost mapping state. The use of the Suggested External IP Address and Suggested External Port fields in the client's renewal request allows the client to remind the restarted PCP server device of what mappings the client had previously been given, so that in many cases the prior state can be recreated. For PCP server devices that reboot relatively quickly it is usually possible to reconstruct lost mapping state fast enough that existing TCP connections and UDP communications do not time out and continue without failure. The PCP Rapid Recovery capability enables users to, for example, connect to remote machines using ssh, and then reboot the NAT gateway (or even replace it with completely new hardware) without losing their established ssh connections. Use of PCP Rapid Recovery is a performance optimization. Without it, Cheshire Expires April 29, 2012 [Page 3] Internet-Draft PCP Rapid Recovery October 2011 PCP clients will still recreate their correct state when they next renew their mappings, but this routine self-healing process may take hours rather than seconds, and will probably not happen fast enough to prevent active TCP connections from timing out. 4. PCP Mapping Update If a PCP server device has not forgotten its mapping state, but for some other reason has determined that some or all of its mappings have become unusable (e.g. when a home gateway is assigned a different external IPv4 address by the upstream DHCP server) then the PCP server device MAY chose to remedy this situation by automatically repairing its mappings and notifying its clients. For PCP MAP mappings, for each one the PCP server device should update the External IP Address and External Port to appropriate available values, and then send unicast PCP MAP responses to inform the PCP client of the new External IP Address and External Port. Such MAP responses are identical to the MAP responses normally returned in response to client MAP requests, except they may be viewed as a long-delayed response to an earlier MAP request, containing newly updated External IP Address and External Port values. To accommodate packet loss, the PCP server device MAY transmit such packets up to ten times (with an appropriate Epoch time value in each to reflect the passage of time between transmissions) provided that the interval between the first two notifications is at least 250ms, and the interval between subsequent notification at least doubles. Upon receipt of such long-delayed MAP responses, a PCP client MUST to use the information in them to update its DNS records, or other address and port information recorded with some kind of application- specific rendezvous server. Existing TCP connections will be lost, but promptly updating the DNS or rendezvous server with the new data will allow new connections to be made. For PCP PEER mappings there is no general way to recover them (the remote host doesn't know the new External IP Address and External Port) so existing connections will be lost. Accordingly, a PCP server device is not required to take any specific action for PEER mappings. It MAY delete all PEER mappings immediately (and let application-layer timeouts detect the failure) or it MAY choose to retain them for some time in case another change in the external environment (e.g. a lost DHCP-assigned external address is re- assigned after a few seconds) results in the mappings becoming usable again. Cheshire Expires April 29, 2012 [Page 4] Internet-Draft PCP Rapid Recovery October 2011 5. Security Considerations Forged PCP Restart Announcements could be used to cause high load on a PCP server. Forged MAP responses could be used to mislead a PCP client about what External IP Address and External Port is has been allocated. 6. IANA Considerations IANA is requested to record that UDP port 5350 is now formally reallocated from "NAT-PMP Restart Announcement" to "PCP Restart Announcement". 7. Normative References [PCP] Wing, D., "Port Control Protocol (PCP)", draft-ietf-pcp-base-07 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 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 April 29, 2012 [Page 5]