Internet DRAFT - draft-cheshire-pcp-expire
draft-cheshire-pcp-expire
PCP Working Group S. Cheshire
Internet-Draft Apple
Intended status: Standards Track August 23, 2012
Expires: February 24, 2013
PCP Address Expiration
draft-cheshire-pcp-expire-00
Abstract
Port Control Protocol (PCP) Address Expiration allows an address
allocation agent (e.g. a DHCP Server) to signal to a NAT or firewall
that an address that was previously in use is no longer in use, and
all state pertaining to it may be discarded.
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 February 24, 2013.
Copyright Notice
Copyright (c) 2012 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 February 24, 2013 [Page 1]
Internet-Draft PCP Expire August 2012
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
NATs and firewalls create implicit mapping state as a result of
seeing outbound traffic from the host. In addition, Port Control
Protocol [PCP] allows a host to explicitly request mappings. All
NATs and firewalls have some finite limit on the amount of mapping
state they can accomodate, so releasing mapping state when it is no
longer required makes those resources available for other clients.
When a host leaves the network and its DHCP address lease expires,
any mapping state associated with that address is no longer required.
In addition, allowing old mapping state to remain after the address
is assigned to a new host could potentially expose that new host to
unwanted traffic. Therefore, when a DHCP address lease expires or is
released, the DHCP server should signal to the NAT or firewall that
all mapping state associated with that address should be released.
In the case of a typical residential home gateway, the DHCP server is
colocated with the NAT or firewall in the same hardware device, and
the signal from the DHCP server software component to the NAT or
firewall software component can be a simple internal software
operation.
In the case of an Internet Service Provider, the DHCP server and
Large Scale NAT may often be implemented in different devices. In
this case it would be useful to have a network protocol to enable the
DHCP server to signal Address Expiration to the Large Scale NAT.
This could be done via some proprietary mechanism, or via some SNMP
message, but the most natural way to implement this state management
message would be via a PCP Opcode.
Cheshire Expires February 24, 2013 [Page 2]
Internet-Draft PCP Expire August 2012
3. PCP Address Expiration
When a DHCP address lease expires or is released, and the DHCP server
wishes to inform the NAT and/or firewall device(s) of this, it sends
the PCP request [PCP] shown below:
Data format for PCP Opcode 3 "EXPIRE"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Expired Internal IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PCP Address Expiration Request and Response Format
When the "Expired Internal IP Address" field is an IPv6 address, the
IPv6 address is placed in the field as-is.
When the "Expired Internal IP Address" field is an IPv4 address, an
IPv4-mapped IPv6 address [RFC4291] is used (::ffff:0:0/96). This has
the first 80 bits set to zero and the next 16 set to one, while its
last 32 bits are filled with the IPv4 address. This is unambiguously
distinguishable from a native IPv6 address, because an IPv4-mapped
IPv6 address [RFC4291] would not be valid for a mapping.
The PCP Address Expiration Request MUST be sent in such a way that
its authenticity can be verified by the receiving NAT or firewall.
For example, the request could be signed and timestamped to prove
that it was generated by an entity authorized to do so (e.g. the DHCP
server). Alternatively, the request could be sent over a secure
channel, such as TLS, or DTLS, where the identity of the sender is
securely verified. In some environments, if the PCP Address
Expiration Request is sent over a private network within a service
provider's data centre, with adequate ingress filtering, then merely
checking the source IP address of the packet against a whitelist may
be adequate. If the request fails such authentication checks, a
NOT_AUTHORIZED error MUST be returned.
The NAT or firewall replies with a PCP Response containing the same
Expired Internal IP Address, and an appropriate response code. If
the request was properly authenticated and all existing mapping state
(if any) for the specified address was successfully deleted, then a
SUCCESS response code (zero) is returned. Otherwise an an
appropriate non-zero response code is returned.
Cheshire Expires February 24, 2013 [Page 3]
Internet-Draft PCP Expire August 2012
4. Security Considerations
NATs and firewalls MUST verify that PCP Address Expiration Requests
are properly authorized.
5. IANA Considerations
IANA is requested to record that PCP Opcode 3 is allocated for "PCP
Expire".
6. 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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
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 February 24, 2013 [Page 4]
