One document matched: draft-penno-pcp-nested-nat-00.txt
Port Control Protocol R. Penno
Internet-Draft Juniper Networks
Intended status: Standards Track D. Wing
Expires: April 19, 2012 Cisco
P. Selkirk
Internet Systems Consortium
October 17, 2011
PCP Support for Nested NAT Environments
draft-penno-pcp-nested-nat-00
Abstract
Nested NATs or multi-layer NATs are already widely deployed. They
are characterized by two or more NAT devices in the path of packets
from the subscriber to the Internet. Moreover, NAT devices current
deployed are PCP unaware and It is assumed that NAT aware PCP devices
will take a long time to be rolled out. Therefore in order to lower
the adoption barrier of PCP and make it work for current deployed
networks, this draft proposes a few mechanisms for PCP enabled
clients to work through nested NATs with varying level of PCP
protocol support.
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 April 19, 2012.
Copyright Notice
Penno, et al. Expires April 19, 2012 [Page 1]
Internet-Draft penno-nested-nat October 2011
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. PCP Nested NAT Methods . . . . . . . . . . . . . . . . . . . . 4
2.1. NAT and UPnP unaware Intermediate NATs . . . . . . . . . . 5
2.2. PCP Server intermediate NAT . . . . . . . . . . . . . . . 7
2.3. UPnP enabled intermediate NAT . . . . . . . . . . . . . . 8
2.4. PCP Proxy Intermediate NAT . . . . . . . . . . . . . . . . 8
2.4.1. PCP Proxy Discovery . . . . . . . . . . . . . . . . . 9
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Penno, et al. Expires April 19, 2012 [Page 2]
Internet-Draft penno-nested-nat October 2011
1. Introduction
Nested NATs are widely deployed and come in different topology
flavors. It could be a home subscriber which has an ISP provided NAT
CPE chained with another personal NAT router. It could be an ISP
provided CPE chained with a CGN.
1.1. Terminology
This document uses PCP terminology defined in [I-D.ietf-pcp-base]].
1.2. Problem Statement
The current NAT deployed devices will take years to be replaced or
upgraded to become PCP aware. Moreover, nested NATs are common and
come in a variety of flavors (examples below). Therefore, as
applications become PCP enabled, it is important that they can work
through nested NAT networks as is, without requiring infrastructure
changes. From the point of view of a PCP enabled application running
on an end host, the core problem is common across different nested
NAT topologies: how to install PCP mappings in a nested NAT scenario
where the different NATs in the path have varying level of PCP
protocol support.
Penno, et al. Expires April 19, 2012 [Page 3]
Internet-Draft penno-nested-nat October 2011
,-----------.
PCP Server ,' `--.
+-------+ +------+ +----------+ / :
|PCP |____|Home |______|ISP CPE |________; Public |
|Client | |Router| |NAT Router| : Internet |
+-------+ +------+ +----------+ \ |
\ ;
`------. ,-'
`-----'
,-----------.
PCP Server ,' `--.
+-------+ +------+ +-------+ / :
|PCP |____|Home |______| CGN |___________; Public |
|Client | |Router| | | : Internet |
+-------+ +------+ +-------+ \ |
\ ;
`------. ,-'
`-----'
,-----------.
PCP Server ,' `--.
+-------+ +------+ +----------+ +-------+ / :
|PCP |____|Home |__|ISP CPE |_| CGN |__; Public |
|Client | |Router| |NAT Router| | | : Internet |
+-------+ +------+ +----------+ +-------+ \ |
\ ;
`------. ,-'
`-----'
,-----------.
PCP Server PCP Server ,' `--.
+-------+ +------+ +----------+ +-------+ / :
|PCP |____|Home |__|ISP CPE |_| CGN |__; Public |
|Client | |Router| |NAT Router| | | : Internet |
+-------+ +------+ +----------+ +-------+ \ |
\ ;
`------. ,-'
`-----'
1.3. Scope
This proposal considers the discovery of the PCP Server out of scope.
Nonetheless, it s a critical piece of PCP deployment in service
provider networks. This proposal is aimed at solving the nested NAT
problem without PCP protocol extensions .
2. PCP Nested NAT Methods
There are a few methods to make PCP work through nested NATs. They
Penno, et al. Expires April 19, 2012 [Page 4]
Internet-Draft penno-nested-nat October 2011
differ mainly based on the level of support that can be expected from
intermediate NATs, which can be:
o PCP and UPnP unaware or disabled
o PCP Server
o UPnP Server
o PCP Proxy
The next sections discuss each scenario on the basis of protocol
support on intermediate NATs.
2.1. NAT and UPnP unaware Intermediate NATs
This method will most likely be used by PCP clients in nested NAT
environments while PCP Proxy support in not ubiquitous. It assumes
no UPnP or PCP Proxy support on intermediate NATs. This proposal
leverages the current behavior of the PCP Protocol
[I-D.ietf-pcp-base] which allows a PCP Client and Server to detect
intervening nested NATs. The PCP Server uses the information on the
outer IP and PCP headers to detect and install a proper NAT mapping
and return the source IP:port from the IP header on the PCP response.
It does not assume any change to current deployed NATs.
1. The PCP Client sends the MAP request as it normally would without
any changes.
2. As the message goes through one (or more) PCP-unaware NAT, the
source IP:port of the IP header will change accordingly
3. The PCP Server compares the PCP Client IP:port in the PCP header
with the source IP:port of the IP header
4. If these are different, the server knows that the PCP message
went through a PCP-unaware NAT. Therefore it installs a mapping
directed to the source IP address found on the IP header and
internal port of the PCP header.
Penno, et al. Expires April 19, 2012 [Page 5]
Internet-Draft penno-nested-nat October 2011
s/dport: source/destination port
s/dIP : source/destination IP
PCP-C : PCP client
iport : Internal port
PCP-U : PCP Unaware NAT
E-port : External port
E-IP : External IP
PCP Client PCP-U NAT PCP Server
| | |
| Map request | |
| Outer sIP:192.68.0.2 | |
| Outer sPort:19268 | Map request |
| PCP-C Addr:192.168.0.1 | Outer sIP:10.0.0.2 |
| PCP-C port:19268 | Outer sPort:10002 |
| iPort:40000 | PCP-C Addr:192.168.0.2 |
| -------------------> | PCP-C port:19268 |
| | iPort:40000 |
| | ----------------------> |
| | |
| | PCP client IP != Outer IP
| | Allocate public IP and port
| | Mapping:
| | (10.0.0.2, 40000) <- (20.0.0.1, 20001)
| | |
| | Map response |
| | Outer dIP:10.0.0.2 |
| | Outer dport:10002 |
| | Assigned E-port:20001 |
| Map response | Assigned E-IP:20.0.0.1 |
| Outer dIP:192.168.0.2 | PCP-C Addr:10.0.0.2 |
| Outer dport:19268 | PCP-C port:10002 |
| Assigned E-port:20001 | <---------------------- |
| Assigned E-IP:20.0.0.1 | |
| PCP-C Addr:10.0.0.2 | |
| PCP-C port:10002 | |
|<---------------------- |
- Subscriber installs a port forwarding or DMZ entry on its home CPE
(PCP U-NAT) through manual configuration. The entry would be (*,
40000) -> (10.0.0.1, 40000). Alternatively the application could use
UPnP for the same purpose.
Penno, et al. Expires April 19, 2012 [Page 6]
Internet-Draft penno-nested-nat October 2011
2.2. PCP Server intermediate NAT
If the intermediate NAT implements a PCP Server (but not a Proxy), a
two-step iterative process is needed in order to install PCP PEER
mappings for the PCP control message itself followed by another PCP
mapping for the data path. if client relies on nested NAT detection
the first step is not needed. It is assumed that before the PCP MAP
request to the CGN the client would install the following map on the
NAT Home Gateway: (192.168.0.2, 40000) <- (10.0.0.2, 40000). The
internal port that the server listens on does not necessarily needs
to be 40000, it could be different than the internal port used
between the CGN and HGW.
PCP Client PCP Server (HGW) PCP Server (CGN)
| PEER request | |
| Outer sIP:192.168.0.2 | |
| Outer sPort:19216 | |
| PCP-C Addr:192.168.0.2 | |
| PCP-C port:19216 | |
| iPort:19216 | |
| Remote Port:44323 | |
| Remote IP: 10.0.0.1 | |
| -------------------> | |
| | |
| PEER response | |
| Outer sIP:192.168.0.1 | |
| Outer sPort: 19216 | |
| Assigned E-port: 10002 | |
| Assigned E-IP: 10.0.0.2| |
| PCP-C Addr:192.168.0.2 | |
| PCP-C port:19216 | |
| iPort:19216 | |
| Remote Port:44323 | |
| Remote IP: 10.0.0.1 | |
| <--------------------- | |
| (192.68.0.2,19216) -> (10.0.0.2,10002) |
| Dest: 10.0.0.1, 44323 |
| | |
| Map request | |
| Outer sIP:192.168.0.2 | |
| Outer sPort:19216 | |
| PCP-C Addr:10.0.0.2 | |
| PCP-C port:10002 | |
| iPort:40000 | |
| --------------------> | |
| | Map request |
| | Outer sIP:10.0.0.2 |
Penno, et al. Expires April 19, 2012 [Page 7]
Internet-Draft penno-nested-nat October 2011
| | Outer sPort:10002 |
| | PCP-C Addr:10.0.0.2 |
| | PCP-C port: 10002 |
| | iPort:40000 |
| | ----------------------> |
| | |
| | (10.0.0.2, 40000) <- (20.0.0.1, 20001)
| | |
| | Map response |
| | Outer dIP:10.0.0.2 |
| | Outer dport: 10002 |
| | Assigned E-port: 20001 |
| Map response | Assigned E-IP: 20.0.0.1 |
| Outer dIP:192.168.0.2 | PCP-C Addr: 10.0.0.2 |
| Outer dport:19216 | PCP-C port: 10002 |
| Assigned E-port: 20001 | <---------------------- |
| Assigned E-IP: 20.0.0.1| |
| PCP-C Addr: 10.0.0.2 | |
| PCP-C port: 10002 | |
|<---------------------- |
2.3. UPnP enabled intermediate NAT
This scenario is very similar to the PCP Server intermediate NAT, but
the HGW implements a UPnP Server instead of PCP Server. The
mechanics are the same with the difference that first PEER message to
setup the PCP Control messages mapping is substituted by its UPnP
equivalent.
2.4. PCP Proxy Intermediate NAT
This method assumed that the intermediate NATs implement a PCP Proxy
function. There are two non-exclusive types of proxy functions:
interception (ALG) and server based. In the interception case the
PCP Proxy intercepts PCP messages destined to a PCP Server
downstream, modifies IP, UDP and PCP headers, allocates a mapping and
send them to the downstream PCP Server. Ideally if the interception
PCP Proxy also implements a PCP server it would let the PCP Client
know of its existence in a PCP response and henceforth the PCP Client
would start directing messages to it.
In the server based proxy the PCP Client directs the PCP messages to
the proxy which acts as a PCP Server and Client. More information
about this method can be found in [I-D.bpw-pcp-proxy].
Penno, et al. Expires April 19, 2012 [Page 8]
Internet-Draft penno-nested-nat October 2011
2.4.1. PCP Proxy Discovery
TBD
3. IANA Considerations
TBD
4. Security Considerations
TBD
5. Acknowledgements
TBD
6. References
6.1. Normative References
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Penno, et al. Expires April 19, 2012 [Page 9]
Internet-Draft penno-nested-nat October 2011
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
6.2. Informative References
[I-D.bpw-pcp-proxy]
Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port
Control Protocol (PCP) Proxy Function",
draft-bpw-pcp-proxy-02 (work in progress), September 2011.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-14 (work in progress), October 2011.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
Authors' Addresses
Reinaldo Penno
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, California 94089
USA
Email: rpenno@juniper.net
Penno, et al. Expires April 19, 2012 [Page 10]
Internet-Draft penno-nested-nat October 2011
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Paul Selkirk
Internet Systems Consortium
950 Charter Street
Redwood City, California 94063
Phone:
Fax:
Email: pselkirk@isc.org
URI:
Penno, et al. Expires April 19, 2012 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 05:57:18 |