PCP Design Considerations
draft-wing-pcp-design-considerations-00

Abstract

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.

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 March 21, 2011.

Copyright Notice

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.

Table of Contents

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

1.  Introduction

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.

2.  Design Considerations

2.1.  Add IPv6 Support

Needs to support NAT44, NAPT44, stateless and stateful NAT64, NAT46, and IPv6 firewall.

2.2.  Open Pinhole for Another Host

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'.

2.3.  Interworking with UPnP IGD

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=====>

2.3.1.  Creating a mapping

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----|                           |
   |                       |                           |

2.3.2.  Lifetime Maintenance

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.

2.4.  Protocol support

Only TCP and UDP will be supported. Additional protocols can be defined later, using the protocol field.

2.5.  Delete all mappings for a host

PCP will allow deleting all mappings for a host. (This is already present in NAT-PMP.)

2.6.  Delete all mappings for all hosts in a home

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.

2.7.  No Reservation of Ports in other protocol

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.

2.8.  Consolidate IP request and port request messages

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.

2.9.  NAT Changing Public Mapping

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.

2.10.  Epoch

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).

2.11.  PCP Server Discovery

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.

2.12.  Port number

Re-use the same port as NAT-PMP (5351).

3.  Security Considerations

TBD.

4.  IANA Considerations

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)

5.  References

5.1. Normative References

5.2. Informative References

Author's Address