idnits 2.17.1 draft-wing-behave-dynamic-tcp-port-reuse-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 379. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 14, 2008) is 5797 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-15 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Informational May 14, 2008 5 Expires: November 15, 2008 7 Dynamic TCP Port Reuse for Large Network Address and Port Translators 8 draft-wing-behave-dynamic-tcp-port-reuse-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 15, 2008. 35 Abstract 37 A strawman proposal is made to reduce public-facing TCP port use with 38 large Network Address and Port Translators (NAPTs). This proposal 39 attempts to preserve emergent NAT traversal techniques. It is 40 anticipated that large NAPTs will be used for NAT64. 42 This document describes a strawman proposal for discussion on the 43 BEHAVE mailing list, . 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 49 3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3.1. Algorithm for client/server applications (ALGO-1) . . . . 3 51 3.2. Algorithm for Peer-to-Peer Applications (ALGO-2) . . . . . 4 52 3.3. Algorithm for Client/Server and Peer-to-Peer (ALGO-3) . . 6 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . . . 10 61 1. Introduction 63 With large NAPTs, it is desirable to re-use public TCP ports in order 64 to conserve IPv4 address space [Iljitsch]. This paper describes 65 three mechanisms to accomplish this goal for TCP. 67 UDP is not considered in this paper, as the primary goal of port re- 68 use is for TCP applications. 70 2. Notational Conventions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Algorithms 78 This document proposes three algorithms with increasing level of 79 complexity. ALGO-1 works for TCP client/server applications (e.g., 80 HTTP, SMTP, IMAP), ALGO-2 works for TCP peer-to-peer applications 81 that use emergent NAT traversal techniques such as UNSAF [RFC3424] 82 mechanisms to learn their public TCP port. The most advanced 83 algorithm, ALGO-3, reuses public TCP ports for client/server 84 applications while also allowing UNSAF applications to function. All 85 three algorithms are presented in this paper to discuss the 86 incremental improvements. 88 With all algorithms proposed below, a new TCP connection from an 89 internal host cannot re-use the same public TCP source port and 90 address to the same remote destination port and address (i.e., you 91 cannot use the same 5-tuple for a new connection). 93 3.1. Algorithm for client/server applications (ALGO-1) 95 Upon seeing a new TCP SYN from the internal interface, the NAPT shall 96 choose a public TCP ephemeral port that is not already used (this is 97 today's REQ-1 in [I-D.ietf-behave-tcp]). 99 ALGO-1: If all of the public TCP ports are used, the NAPT shall 100 choose a TCP port that is already used. It may select any port that 101 has completed its TCP handshake. Once selected, that port cannot be 102 chosen for additional TCP port re-use until it, too, has completed 103 its TCP handshake. 105 Thus, the following situation could occur if the TCP handshake 106 between H1 and H2 had completed, and then H1 needed another TCP 107 connection with host H3: 109 +----+(16.1.1.1,5000) (163.1.1.1, 2000) 110 +--+(10.1.1.1, 30000) | +------------------------------------H2 111 | |-------------------+ | 112 |H1| |NAPT| 113 | |(10.1.1.1, 40000) | | 114 | +-------------------+ |(16.1.1.1,5000) (23.1.1.1,8000) 115 +--+ | +------------------------------------H3 116 +----+ 118 Figure 1: Same Source TCP Port on NAPT 120 ALGO-1 should work very well for client/server applications and 121 provides the desired port overloading. 123 A drawback of ALGO-1 is that it violates REQ-1 of 124 [I-D.ietf-behave-tcp]. This is because between the time the host 125 performs UNSAF and learns its IP address and TCP port, the NAPT might 126 re-use that public TCP port for another host (or application running 127 on the same host) to re-use that same public TCP port. If the NAPT 128 re-uses the TCP port with an UNSAF application (which expects an 129 incoming TCP connection), an incoming TCP connection cannot be sent 130 to the correct internal host -- thus breaking UNSAF. However, this 131 can be improved upon with ALGO-2, below. 133 3.2. Algorithm for Peer-to-Peer Applications (ALGO-2) 135 Peer-to-peer TCP applications require a host, behind a NAPT, to 136 listen for and respond to incoming TCP connections. In order to do 137 so, many of these applications utilize UPnP or NAT-PMP to cause their 138 IPv4 NAPT to forward incoming TCP connections to the host. After 139 learning the public IPv4 and TCP port via UPnP or NAT-PMP, that 140 information is communicated to other hosts participating in the peer- 141 to-peer network. Because UPnP and NAT-PMP both utilize broadcast or 142 multicast packets, and do not support nested NAPTs, they are not 143 suitable for use by an ISP's NAPT. 145 For these reasons, it is anticipated that peer-to-peer TCP 146 applications will migrate to using an UNSAF [RFC3424] technique 147 (e.g., STUN [I-D.ietf-behave-rfc3489bis]). A host using an UNSAF 148 technique learns its public IP address and TCP port and then tries to 149 cause the NAPT to re-use that learned public IP address and TCP port 150 for a subsequent connection to a different host (REQ-1 of 151 [I-D.ietf-behave-tcp]). In order to cause the NAT to re-use the same 152 public port for a new TCP connection, the host re-uses the same local 153 TCP port for the connection to the different host. The NAPT can take 154 advantage of this characteristic of UNSAF applications to determine 155 if the port can be re-used. 157 ALGO-2 requires TCP UNSAF applications signal they are using UNSAF 158 (often they do this as a matter of their normal operation), and a 159 change to the NAPT: 161 o TCP UNSAF applications need signal the NAPT that they are TCP 162 UNSAF applications. Such TCP UNSAF implementations would need to 163 make two connections from its same source TCP port to two 164 different hosts, and make that connection within a finite length 165 of time -- such as 30 seconds. 167 (The first host is the host running the UNSAF protocol (e.g., 168 the STUN server); the second host is any other host on the 169 Internet (e.g., a remote host on the Internet, or NAPT's own 170 public IP address, or even just a sink-hole IP address). 172 o 30 seconds after the TCP connection is established, one of two 173 things would have occurred: 175 * The host has re-used its internal TCP port for a connection to 176 a different remote host. This indicates the host is using an 177 UNSAF mechanism, and the NAT needs to conform to REQ-1 of 178 [I-D.ietf-behave-tcp] for this connection, or; 180 * The host has not re-used its internal TCP port for a connection 181 to a different remote host. This indicates the NAPT can re-use 182 the public TCP port for another connection. 184 This means short-lived connections (such as HTTP/1.0 connections) 185 would receive less direct benefit from this p2p-friendly port-reuse 186 scheme (but see , below). Longer lived client/server connections 187 (e.g., IMAP, HTTP/1.1 with keepalive) would not trigger the p2p- 188 friendliness described in this section and would reuse public TCP 189 ports after the ~30 second wait to decide if the internal host was 190 using UNSAF. 192 Thus, with ALGO-2 if the TCP handshake between H1 and H2 had 193 completed and (within 30 seconds) H1 uses the same source port 194 (30000) when making a connection within 30 seconds to H3, the NAPT 195 will allocate the same external TCP port (5000): 197 +-----+(16.1.1.1,5000) (163.1.1.1, 2000) 198 +--+(10.1.1.1, 30000) | +------------------------------------H2 199 | |-------------------+ | 200 |H1| |NAPT| 201 | |(10.1.1.1, 30000) | | 202 | +-------------------+ |(16.1.1.1,5000) (23.1.1.1,8000) 203 +--+ | +------------------------------------H3 204 +----+ 206 Figure 2: Same Source TCP Port on Host 208 When another host, H4, connects, the TCP SYN is forwarded to H1: 210 +----+(16.1.1.1,5000) (163.1.1.1, 2000) 211 +--+(10.1.1.1, 30000) | +------------------------------------H2 212 | |-------------------+ | 213 |H1| |NAPT| 214 | |(10.1.1.1, 30000) | | 215 | +<------------------+ |(16.1.1.1,5000) (25.1.1.1,9000) 216 +--+ | +<-----------------------------------H4 217 +----+ 219 Figure 3: Incoming TCP connection 221 Cleanup: The NAPT can re-use the public TCP port once the TCP 222 session has been torn down (TCP RST, FIN, or other similar shutdown 223 indicator) and TIME_WAIT seconds have elapsed. 225 A drawback to ALGO-2 is that a specific port cannot be re-used until 226 ~30 seconds have elapsed. By that time, some applications will have 227 finished their TCP connection (e.g., short-lived HTTP connections). 228 However, this can be improved upon with ALGO-3. 230 3.3. Algorithm for Client/Server and Peer-to-Peer (ALGO-3) 232 The final algorithm provides peer-to-peer friendliness while also 233 providing better TCP port re-use -- when viewed at a system level. 234 That is, with multiple TCP connections from multiple applications on 235 multiple hosts, there is a good re-use of TCP ports. This is because 236 multiple longer-lived TCP connections are allowed to persist on a 237 specific port, and new connections are allowed to also re-use that 238 same port. Once a connection has lived for its 30 seconds on a port, 239 a new connection is allowed to re-use that same port. 241 The following algorithm further modifies ALGO-1's port selection to 242 re-use TCP ports that are not needed by an UNSAF application. 244 ALGO-3: If a host has not re-used its internal TCP source port for a 245 TCP connection within 30 seconds, the NAPT should prefer to re-use 246 that public TCP port for the next TCP connection. 248 Discussion: After 30 seconds the NAPT knows the connections are 249 client/server TCP connections because the internal host has not 250 re-used the source TCP port. If the host does re-use its source 251 TCP port, the NAPT MUST forward all incoming TCP connection 252 requests to that host. 254 In this way, once a connection has been alive for 30 seconds and the 255 host has demonstrated it doesn't need to an accept incoming 256 connection (that is, the host has not exhibited characteristics of an 257 UNSAF application), that public TCP port can be re-used by another 258 (new) TCP connection. 260 The following figure shows H5 has established two TCP connections 261 with two different servers (H6, H7), which the NAPT happened to place 262 on the same public TCP port, 5000. This happened because the first 263 connection had already persisted for 30 seconds and the NAPT decided 264 it could re-use that port for another TCP connection. Then, after 265 the second TCP connection had persisted for 30 seconds, H8 266 established a connection to yet another host and the NAPT decided to 267 re-use port 5000 again. However, H8 is using UNSAF -- which the NAPT 268 noticed because H8 connected to another host within 30 seconds using 269 its same source TCP port (40000) [that connection is not shown in the 270 diagram]. Thus, because of this, the NAPT will not re-use this 271 public TCP port for another connection but instead forwards all 272 incoming TCP connections (TCP SYNs) to port 40000 on H8. 274 +-----+ 275 +--+(10.1.1.1, 30000) | |(16.1.1.1,5000) (163.1.1.1,80) 276 | +------------------>+-----+---------------------------------> H6 277 |H5| | | 278 | |(10.1.1.1, 32222) | |(16.1.1.1,5000) (164.2.2.2,80) 279 +--+------------------>+-----+---------------------------------> H7 280 | | 281 +--+(10.1.1.2, 40000) | |(16.1.1.1,5000) (163.1.1.1,2000) 282 | |-------------------+-----+---------------------------------> H9 283 |H8| |NAPT | 284 | |(10.1.1.2, 40000) | |(16.1.1.1,5000) (23.1.1.1,8000) 285 | +<------------------+-----+<--------------------------------- H10 286 +--+ +-----+ 288 Figure 4: Client/Server and Peer-to-Peer 290 Cleanup: If a port was used by an UNSAF application, the NAPT can 291 re-use that public TCP port once the UNSAF application has stopped 292 (TCP RST, FIN, or other similar shutdown indication), and TIME_WAIT 293 for the UNSAF application has elapsed. 295 4. Security Considerations 297 sTBD. 299 5. IANA Considerations 301 There are no IANA considerations for this document. 303 6. References 305 6.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 6.2. Informative References 312 [I-D.ietf-behave-rfc3489bis] 313 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 314 "Session Traversal Utilities for (NAT) (STUN)", 315 draft-ietf-behave-rfc3489bis-15 (work in progress), 316 February 2008. 318 [I-D.ietf-behave-tcp] 319 Guha, S., "NAT Behavioral Requirements for TCP", 320 draft-ietf-behave-tcp-07 (work in progress), April 2007. 322 [Iljitsch] 323 van Beijnum, I., "Scalability of endpoint independent 324 mapping", May 2008, . 327 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 328 Self-Address Fixing (UNSAF) Across Network Address 329 Translation", RFC 3424, November 2002. 331 Author's Address 333 Dan Wing 334 Cisco Systems, Inc. 335 170 West Tasman Drive 336 San Jose, CA 95134 337 USA 339 Email: dwing@cisco.com 341 Full Copyright Statement 343 Copyright (C) The IETF Trust (2008). 345 This document is subject to the rights, licenses and restrictions 346 contained in BCP 78, and except as set forth therein, the authors 347 retain all their rights. 349 This document and the information contained herein are provided on an 350 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 351 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 352 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 353 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 354 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 355 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 357 Intellectual Property 359 The IETF takes no position regarding the validity or scope of any 360 Intellectual Property Rights or other rights that might be claimed to 361 pertain to the implementation or use of the technology described in 362 this document or the extent to which any license under such rights 363 might or might not be available; nor does it represent that it has 364 made any independent effort to identify any such rights. Information 365 on the procedures with respect to rights in RFC documents can be 366 found in BCP 78 and BCP 79. 368 Copies of IPR disclosures made to the IETF Secretariat and any 369 assurances of licenses to be made available, or the result of an 370 attempt made to obtain a general license or permission for the use of 371 such proprietary rights by implementers or users of this 372 specification can be obtained from the IETF on-line IPR repository at 373 http://www.ietf.org/ipr. 375 The IETF invites any interested party to bring to its attention any 376 copyrights, patents or patent applications, or other proprietary 377 rights that may cover technology that may be required to implement 378 this standard. Please address the information to the IETF at 379 ietf-ipr@ietf.org. 381 Acknowledgment 383 This document was produced using xml2rfc v1.33 (of 384 http://xml.resource.org/) from a source in RFC-2629 XML format.