| TOC |
|
This document summarizes changes from NAT-PMP to support the needs of a large-scale NAT and support IPv6.
This document is for discussion purposes. It is not intended to be published as an RFC.
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 March 21, 2011.
Copyright (c) 2010 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.
1.
Introduction
2.
Design Considerations
2.1.
Add IPv6 Support
2.2.
Open Pinhole for Another Host
2.3.
Interworking with UPnP IGD
2.3.1.
Creating a mapping
2.3.2.
Lifetime Maintenance
2.4.
Protocol support
2.5.
Delete all mappings for a host
2.6.
Delete all mappings for all hosts in a home
2.7.
No Reservation of Ports in other protocol
2.8.
Consolidate IP request and port request messages
2.9.
NAT Changing Public Mapping
2.10.
Epoch
2.11.
PCP Server Discovery
2.12.
Port number
3.
Security Considerations
4.
IANA Considerations
5.
References
5.1.
Normative References
5.2.
Informative References
§
Author's Address
| TOC |
NAT-PMP (Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” April 2008.) [I‑D.cheshire‑nat‑pmp] is a lightweight, UDP-based request/response protocol that forms a good basis to obtain mappings from a NAT. This document describes how NAT-PMP can be extended to support a large-scale NAT (such as deployed by an ISP, [I‑D.nishitani‑cgn] (Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, “Common requirements for IP address sharing schemes,” July 2010.)), support NAT64, and provide sufficient support to interwork between UPnP IGD (UPnP Forum, “Universal Plug and Play Internet Gateway Device,” 2000.) [UPnP‑IGD] and PCP.
This document is for discussion purposes. It is not intended to be published as an RFC.
| TOC |
| TOC |
Needs to support NAT44, NAPT44, stateless and stateful NAT64, NAT46, and IPv6 firewall.
| TOC |
Provide ability for another device, within same home, to open ports on behalf of another. This functionality also intended to be used by the operator of the NAT itself (e.g., the ISP) which is accessed by their technical support staff or is accessed by the end user.
Use 0 as internal IP address to indicate 'this IP SRC address'.
| TOC |
In UPnP IGD, a 'control point' can request a specific port or can request a wildcard port, and there is no concept of a mapping lifetime. This model does not work well with NATs, especially large scale NATs.
+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +-----+ +--------+
+---| IGD-| |Provider|
| PCP |-------| NAT |--<Internet>
+---| IWF | | |
+-------------+ | +-----+ +--------+
| Local Host |-----+
+-------------+
LAN Side External Side
<======UPnP IGD==========><======PCP=====>
| Figure 1: UPnP IGD to PCP Interworking Function |
| TOC |
The Madatory bit, from draft-wing-softwire-port-control-protocol is not necessary, and will not be used in PCP. We had a lengthy discussion on this during our design meetings. The primary benefit of this bit is to ease interworking between UPnP IGD and PCP. As most people are aware, UPnP IGD mandates that UPnP IGD gateways implement the ability for a UPnP 'control point' (the computer inside the home) to obtain a mapping for a specific port. UPnP IGD includes optional support for the control point to request 'any' port, which allows the UPnP IGD gateway to choose the port number. However, this ability to request 'any' port seems to not be commonly used by UPnP IGD control points, is not available in the Windows UPnP API, and appears to also not be commonly implemented in UPnP IGD gateways (NATs). Thus, most UPnP IGD applications request a specific port. On a NAT with a lot of activity, such as a large scale NAT, any specific port number is probably already in use by another subscriber, so the UPnP IGD model does not work well.
In our experience, UPnP IGD applications or the underlying library will attempt to try port+1, port+2, and so on. However, we can't recommend this behavior [draft-ietf-tsvwg-port-randomization].
Thus, to interwork from UPnP IGD to PCP, our recommendation is that every UPnP request be forwarded to the PCP server. This works if the UPnP control point is incrementing the source port number, and also works if the UPnP control point is randomly choosing the source port number, and also works if it chooses 'any'. The UPnP IGD/PCP interworking function would request very short leases (e.g., 5 seconds) in order to avoid the chatter of a DELETE message (lifetime=0). Once a port can be allocated, its lifetime is extended. When interworking with UPnP IGD, the in-home CPE limits itself to sending one PCP message a second, which ensures there are only 5 outstanding PCP reserverations at a time; this avoids consuming all of that subscriber's NAT mappings while trying to find an available port via the UPnP IGD->PCP interworking function).
Note: for this to work successfully, the PCP server (large NAT) make an attempt to honor the requested-external-port field in the PCP request.
Message flow would be similar to this:
UPnP CP in-home CPE PCP server | | | |-UPnP:give me port 80->| | | |-PCP:request port 80------>| | | with lease=5 seconds | | |<-PCP:here is port 51389---| |<-UPnP: unavailable----| | | | | |-UPnP:give me port 81->| | | |-PCP:request port 81------>| | | with lease=5 seconds | | |<-PCP:here is port 23831---| |<-UPnP: unavailable----| | | | | ... ... ... ... | | | |-UPnP:give me port 85->| | | |-PCP:request port 85------>| | | with lease=5 seconds | | |<-PCP:here is port 85------| | | | | |-PCP:extend lease,port=85->| | |<-PCP:ok-------------------| | | | |<-UPnP: ok, port 85----| | | | |
| Figure 2: Message Flow for UPnP to PCP Interworking |
| TOC |
UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP interworking function is responsible for extending the lifetime of mappings that are still interesting to the UPnP IGD device. We recommend the UPnP IGD/PCP function request a port mapping lifetime equal to the client's remaining DHCP lifetime. Th UPnP IGD/PCP interworking function is responsible for renewing the PCP lifetime as necessary. As long as client renews its DHCP lease, the PCP lifetime should also be extended. For clients not using DHCP, ping, ARP, or WiFi association can be used to discern liveliness of the UPnP IGD control point. It is not recommended to attempt to connect to the TCP or UDP port opened on the control point to determine if the host still wants to receive packets; the server could be temporarily down when tested, causing a false negative.
| TOC |
Only TCP and UDP will be supported. Additional protocols can be defined later, using the protocol field.
| TOC |
PCP will allow deleting all mappings for a host. (This is already present in NAT-PMP.)
| TOC |
PCP will allow deleting all mappings for all hosts behind an in-home CPE, such as DS-Lite's "B4" element. This is to allow flushing PCP mappings when a subscriber is assigned an IP address belonging to a previous subscriber.
| TOC |
When a port reservation is made, NAT-PMP currently reserves the same port in the other transport protocol for the same host. That is, if a mapping is made for TCP/12345, the port UDP/12345 will be reserved for a future mapping. This functionality will be removed from PCP.
If a protocol requires the same mapping for UDP and TCP, it will need to issue separate requests (with short lifetimes) until it is assigned the same ports.
| TOC |
NAT-PMP currently uses a separate message to obtain the public IP address and to obtain the port. In PCP, this will be consolidated into one message so that every port response includes the external address and lifetime. Once a host has an active PCP-created mapping on one port, it will get the same external address for all subsequent port requests.
| TOC |
Currently, NAT-PMP has a feature where the NAT can alert hosts on the local LAN if the NAT's public address changed or the NAT rebooted. This functionality will not be available in the initial functionality of PCP, but can be provided in a future document.
| TOC |
As in NAT-PMP, all NATs will implement epoch. NATs which retain their state will simply increase the epoch. This reduces implementation burden to deal with NATs-that-retain-state and NATs-which-lose-state, and also allows ISPs to renumber the public side of the NAT (and force epoch back to zero).
| TOC |
Currently we are considering a new DHCP option which indicates the PCP server's address, with a fallback to using the default gateway's address as the PCP server if the DHCP option isn't available.
This requires the default gateway to support PCP -- either by processing PCP packets (or tunneling them), or by handling the new DHCP option.
DHCP option is vulnerable to accidental or malicious breakage if the incorrect PCP server is sent in the DHCP option.
| TOC |
Re-use the same port as NAT-PMP (5351).
| TOC |
TBD.
| TOC |
Re-use the IANA-assigned port number for NAT-PMP, 5351, changing its reference to read:
pcp 5351/tcp Port Control Protocol (was NAT Port Mapping Protocol) pcp 5351/udp Port Control Protocol (was NAT Port Mapping Protocol) # RFCnnnn (this RFC)
| TOC |
| TOC |
| [I-D.cheshire-nat-pmp] | Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” draft-cheshire-nat-pmp-03 (work in progress), April 2008 (TXT). |
| TOC |
| [I-D.nishitani-cgn] | Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, “Common requirements for IP address sharing schemes,” draft-nishitani-cgn-05 (work in progress), July 2010 (TXT). |
| [UPnP-IGD] | UPnP Forum, “Universal Plug and Play Internet Gateway Device,” 2000. |
| TOC |
| Dan Wing | |
| Cisco Systems, Inc. | |
| 170 West Tasman Drive | |
| San Jose, California 95134 | |
| USA | |
| Email: | dwing@cisco.com |