[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]