One document matched: draft-wing-pcp-design-considerations-00.txt
PCP Working Group D. Wing
Internet-Draft Cisco
Intended status: Informational September 17, 2010
Expires: March 21, 2011
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
Wing Expires March 21, 2011 [Page 1]
Internet-Draft PCP Design Considerations September 2010
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
2. Design Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Add IPv6 Support . . . . . . . . . . . . . . . . . . . . . 3
2.2. Open Pinhole for Another Host . . . . . . . . . . . . . . . 3
2.3. Interworking with UPnP IGD . . . . . . . . . . . . . . . . 3
2.3.1. Creating a mapping . . . . . . . . . . . . . . . . . . 4
2.3.2. Lifetime Maintenance . . . . . . . . . . . . . . . . . 5
2.4. Protocol support . . . . . . . . . . . . . . . . . . . . . 6
2.5. Delete all mappings for a host . . . . . . . . . . . . . . 6
2.6. Delete all mappings for all hosts in a home . . . . . . . . 6
2.7. No Reservation of Ports in other protocol . . . . . . . . . 6
2.8. Consolidate IP request and port request messages . . . . . 6
2.9. NAT Changing Public Mapping . . . . . . . . . . . . . . . . 6
2.10. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.11. PCP Server Discovery . . . . . . . . . . . . . . . . . . . 7
2.12. Port number . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Wing Expires March 21, 2011 [Page 2]
Internet-Draft PCP Design Considerations September 2010
1. Introduction
NAT-PMP [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]),
support NAT64, and provide sufficient support to interwork between
UPnP IGD [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.
Wing Expires March 21, 2011 [Page 3]
Internet-Draft PCP Design Considerations September 2010
+-------------+
| 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
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
Wing Expires March 21, 2011 [Page 4]
Internet-Draft PCP Design Considerations September 2010
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
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
Wing Expires March 21, 2011 [Page 5]
Internet-Draft PCP Design Considerations September 2010
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.
Wing Expires March 21, 2011 [Page 6]
Internet-Draft PCP Design Considerations September 2010
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
Wing Expires March 21, 2011 [Page 7]
Internet-Draft PCP Design Considerations September 2010
5.1. Normative References
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008.
5.2. Informative References
[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.
[UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway
Device", 2000,
<http://www.upnp.org/standardizeddcps/igd.asp>.
Author's Address
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Wing Expires March 21, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 04:42:33 |