idnits 2.17.1 draft-tsou-pcp-address-modify-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 16, 2010) is 4939 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou, Ed. 3 Internet-Draft T. Taylor 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 19, 2011 S. Ding 6 China Telecom 7 October 16, 2010 9 Ensuring Address Reuse In the Pinhole Control Protocol (PCP) 10 draft-tsou-pcp-address-modify-00 12 Abstract 14 This document proposes that a field be added to the PIN-REQUEST 15 message in the Pinhole Control Protocol to ask that the new mapping 16 being requested reuse the same external address already assigned to 17 the requesting device. The actual form of this new field is 18 discussed within the document. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 19, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Possible Solutions and Proposal . . . . . . . . . . . . . . . . 3 57 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. PIN-REQUEST . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. PIN-RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 64 6.2. informative References . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 The Pinhole Control Protocol (PCP) [ID.port_control_protocol] allows 70 applications to learn their external IP address and also to 71 instantiate mappings in the PCP-controlled devices. Currently the 72 application can request a mapping from a given internal port to a 73 given external port, but it has no control over the external address 74 that is assigned to it. 76 A number of applications, for example, RTP/RTCP [RFC3550] or FTP 77 [RFC0959], require the allocation of multiple ports. However, if 78 these ports are assigned with different IP addresses, the 79 applications will fail. 81 The recommendations for NAT behaviour for UDP [RFC4787] include a 82 recommendation for the Paired address mapping behaviour when IP 83 address pooling is being used. However, this is only a 84 recommendation, and could therefore fail at times. The 85 recommendations for NAT behaviour for TCP [RFC5382] do not even 86 address the topic. The conclusion is that a method is needed for the 87 application to request that it be given the same external address for 88 a new mapping request as for one that has already been mapped to it. 90 1.1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Possible Solutions and Proposal 98 The most straightforward solution to the problem just proposed is to 99 provide a field in the PINHOLE-REQ message for the application to 100 specify the external address that it wishes to use. If the client 101 receives an error response to its request, it is obviously free to 102 repeat the request with fewer constraints. 104 This has a drawback: the lack of any constraint on what address the 105 application specifies, so that could request an entirely new external 106 address for the current assignment. Granting the unrestricted 107 ability to request specific external addresses could result in 108 fragmentation of the address-port space that the NAT has to work 109 with, and will certainly increase the burden on the PCP server. 111 To resolve this problem, the server and/or the client should follow 112 the rules below: 114 o Server Behavior 116 When receiving a request message specifying an external address, the 117 PCP server should check whether that address is now used by the user; 118 if not, the PCP server should deny the request. 120 o Client Behavior 122 client should not specify the address in the initial request message 123 and should let the server to choose one. In the subsequent request 124 messages, the client can request the external IP address contained in 125 the initial response message. 127 3. Message Format 129 3.1. PIN-REQUEST 131 External IP address is added in the PIN-REQUEST message, so that a 132 client can specify the external IP address in a request message. 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 : Internal IP address (32 or 128 bits) : 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 : External IP address (32 or 128 bits) : 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Proto |W|R| Reserved | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Requested Pinhole Lifetime (seconds) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 : Internal Port | Requested External Port : 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 : Internal Port : Requested External Port : 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 PIN-REQUEST 152 o External IP address: requested external IP address; when set to 0, 153 the PCP server would be free to choose one out of the external IP 154 addresses being used by the user. If there no active mappings for 155 the user, then the PCP server can use any one of free external IP 156 addresses. 158 3.2. PIN-RESPONSE 160 This memo does not change the PIN-RESPONSE message format. 162 A new error code should be added in the response message, in case the 163 PCP server can not allocate resource for the specified external IP 164 address. 166 code error subcode meaning 167 ---- ------------- ----------------- 168 14(TBD) 0 unable to allocate resource 169 for the specified external 170 IP address 172 4. IANA Considerations 174 IANA should add an error code for the new PCP error. 176 5. Security Considerations 178 This memo does not in itself introduce any security issues. The 179 client is unable to control whether new state is created on the 180 server, and is thus not enabled by this feature to mount a DoS attack 181 through resource consumption. 183 6. References 185 6.1. Normative References 187 [ID.port_control_protocol] 188 Wing, D., Penno, R., and M. Boucadair, "Pinhole Control 189 Protocol (PCP) (Work in progress)", July 2010. 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, March 1997. 194 6.2. informative References 196 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 197 STD 9, RFC 959, October 1985. 199 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 200 Jacobson, "RTP: A Transport Protocol for Real-Time 201 Applications", STD 64, RFC 3550, July 2003. 203 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 204 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 205 RFC 4787, January 2007. 207 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 208 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 209 RFC 5382, October 2008. 211 Authors' Addresses 213 Tina Tsou (editor) 214 Huawei Technologies 215 Bantian, Longgang District 216 Shenzhen 518129 217 P.R. China 219 Phone: 220 Email: tena@huawei.com 222 Tom Taylor 223 Huawei Technologies 224 1852 Lorraine Ave. 225 Ottawa K1H 6Z8 226 Canada 228 Phone: 229 Email: tom111.taylor@bell.net 231 Shengyong Ding 232 China Telecom 233 109, Zhongshan Ave. West, Tianhe District 234 Guangzhou 510630 235 P.R. China 237 Phone: 238 Email: dingsy@gsta.com