Internet DRAFT - draft-penno-pcp-ext-addr
draft-penno-pcp-ext-addr
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]
