One document matched: draft-cheshire-pcp-recovery-01.txt
Differences from draft-cheshire-pcp-recovery-00.txt
PCP working group S. Cheshire
Internet-Draft Apple
Intended status: Standards Track June 6, 2011
Expires: December 8, 2011
PCP Rapid Recovery
draft-cheshire-pcp-recovery-01
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 December 8, 2011.
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 December 8, 2011 [Page 1]
Internet-Draft PCP Rapid Recovery June 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-enabled NAT gateway [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 doesn't know whether it may have had prior mapping state
that it lost) it MUST inform PCP clients of this fact by multicasting
the UDP packet shown below to 224.0.0.1:5350 on all multicast-capable
interfaces on which it accepts PCP requests. To accommodate packet
loss, the PCP-enabled NAT MAY transmit such packets up to ten times
(with an appropriate Epoch 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.
Cheshire Expires December 8, 2011 [Page 2]
Internet-Draft PCP Rapid Recovery June 2011
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 on UDP
224.0.0.1:5350 on all multicast-capable interfaces on which it has
sent PCP requests, to receive these PCP Restart Announcements. (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 indicates that the NAT
gateway has begun a new epoch since the last time the PCP client
received a PCP response message from that PCP server address, 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 NAT gateway of what mappings the client had previously been
given, so that in many cases the prior state can be recreated. For
NAT gateways 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,
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.
Cheshire Expires December 8, 2011 [Page 3]
Internet-Draft PCP Rapid Recovery June 2011
4. PCP Mapping Update
If a PCP-enabled NAT gateway 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
NAT gateway MAY chose to remedy this situation by automatically
repairing its mappings and notifying its clients.
For PCP MAP mappings, for each one the NAT gateway 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-enabled NAT MAY transmit such
packets up to ten times (with an appropriate Epoch 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-
enabled NAT gateway 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 December 8, 2011 [Page 4]
Internet-Draft PCP Rapid Recovery June 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 December 8, 2011 [Page 5]
| PAFTECH AB 2003-2026 | 2026-04-24 01:30:48 |