Internet Engineering Task Force T. Tsou, Ed.
Internet-Draft T. Taylor
Intended status: Standards Track Huawei Technologies
Expires: April 19, 2011 S. Ding
China Telecom
October 16, 2010
Ensuring Address Reuse In the Pinhole Control Protocol (PCP)
draft-tsou-pcp-address-modify-00
Abstract
This document proposes that a field be added to the PIN-REQUEST
message in the Pinhole Control Protocol to ask that the new mapping
being requested reuse the same external address already assigned to
the requesting device. The actual form of this new field is
discussed within the document.
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, 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
Tsou, et al. Expires April 19, 2011 [Page 1]
Internet-Draft Requesting External Address In PCP October 2010
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
2. Possible Solutions and Proposal . . . . . . . . . . . . . . . . 3
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. PIN-REQUEST . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. PIN-RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Tsou, et al. Expires April 19, 2011 [Page 2]
Internet-Draft Requesting External Address In PCP October 2010
1. Introduction
The Pinhole Control Protocol (PCP) [ID.port_control_protocol] allows
applications to learn their external IP address and also to
instantiate mappings in the PCP-controlled devices. Currently the
application can request a mapping from a given internal port to a
given external port, but it has no control over the external address
that is assigned to it.
A number of applications, for example, RTP/RTCP [RFC3550] or FTP
[RFC0959], require the allocation of multiple ports. However, if
these ports are assigned with different IP addresses, the
applications will fail.
The recommendations for NAT behaviour for UDP [RFC4787] include a
recommendation for the Paired address mapping behaviour when IP
address pooling is being used. However, this is only a
recommendation, and could therefore fail at times. The
recommendations for NAT behaviour for TCP [RFC5382] do not even
address the topic. The conclusion is that a method is needed for the
application to request that it be given the same external address for
a new mapping request as for one that has already been mapped to it.
1.1. Terminology
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 [RFC2119].
2. Possible Solutions and Proposal
The most straightforward solution to the problem just proposed is to
provide a field in the PINHOLE-REQ message for the application to
specify the external address that it wishes to use. If the client
receives an error response to its request, it is obviously free to
repeat the request with fewer constraints.
This has a drawback: the lack of any constraint on what address the
application specifies, so that could request an entirely new external
address for the current assignment. Granting the unrestricted
ability to request specific external addresses could result in
fragmentation of the address-port space that the NAT has to work
with, and will certainly increase the burden on the PCP server.
To resolve this problem, the server and/or the client should follow
the rules below:
Tsou, et al. Expires April 19, 2011 [Page 3]
Internet-Draft Requesting External Address In PCP October 2010
o Server Behavior
When receiving a request message specifying an external address, the
PCP server should check whether that address is now used by the user;
if not, the PCP server should deny the request.
o Client Behavior
client should not specify the address in the initial request message
and should let the server to choose one. In the subsequent request
messages, the client can request the external IP address contained in
the initial response message.
3. Message Format
3.1. PIN-REQUEST
External IP address is added in the PIN-REQUEST message, so that a
client can specify the external IP address in a request message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal IP address (32 or 128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: External IP address (32 or 128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proto |W|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Pinhole Lifetime (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal Port | Requested External Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Internal Port : Requested External Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIN-REQUEST
o External IP address: requested external IP address; when set to 0,
the PCP server would be free to choose one out of the external IP
addresses being used by the user. If there no active mappings for
the user, then the PCP server can use any one of free external IP
addresses.
Tsou, et al. Expires April 19, 2011 [Page 4]
Internet-Draft Requesting External Address In PCP October 2010
3.2. PIN-RESPONSE
This memo does not change the PIN-RESPONSE message format.
A new error code should be added in the response message, in case the
PCP server can not allocate resource for the specified external IP
address.
code error subcode meaning
---- ------------- -----------------
14(TBD) 0 unable to allocate resource
for the specified external
IP address
4. IANA Considerations
IANA should add an error code for the new PCP error.
5. Security Considerations
This memo does not in itself introduce any security issues. The
client is unable to control whether new state is created on the
server, and is thus not enabled by this feature to mount a DoS attack
through resource consumption.
6. References
6.1. Normative References
[ID.port_control_protocol]
Wing, D., Penno, R., and M. Boucadair, "Pinhole Control
Protocol (PCP) (Work in progress)", July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. informative References
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Tsou, et al. Expires April 19, 2011 [Page 5]
Internet-Draft Requesting External Address In PCP October 2010
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
Authors' Addresses
Tina Tsou (editor)
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: tena@huawei.com
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.
Ottawa K1H 6Z8
Canada
Phone:
Email: tom111.taylor@bell.net
Shengyong Ding
China Telecom
109, Zhongshan Ave. West, Tianhe District
Guangzhou 510630
P.R. China
Phone:
Email: dingsy@gsta.com
Tsou, et al. Expires April 19, 2011 [Page 6]