idnits 2.17.1 draft-penno-behave-rfc4787-5382-5508-bis-04.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 07, 2013) is 4119 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FC5382' is mentioned on line 370, but not defined == Missing Reference: 'TCP-Security' is mentioned on line 516, but not defined == Unused Reference: 'I-D.ietf-pcp-base' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'I-D.naito-nat-resource-optimizing-extension' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Downref: Normative reference to an Informational RFC: RFC 2663 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Port Control Protocol R. Penno 3 Internet-Draft Cisco 4 Intended status: BCP S. Perreault 5 Expires: July 11, 2013 Viagenie 6 S. Kamiset 7 Consultant 8 M. Boucadair 9 France Telecom 10 K. Naito 11 NTT 12 January 07, 2013 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-penno-behave-rfc4787-5382-5508-bis-04 17 Abstract 19 This document clarifies and updates several requirements of RFC4787, 20 RFC5382 and RFC5508 based on operational and development experience. 21 The focus of this document is NAPT44. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 11, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. TCP Session Tracking . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. TCP Transitory Connection Idle-Timeout . . . . . . . . . . 4 68 3.1.1. Port resources limited case . . . . . . . . . . . . . 5 69 3.1.2. Proposal: Apply RFC6191 and PAWS to NAT . . . . . . . 6 70 3.2. TCP RST . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4. Port Overlapping behavior . . . . . . . . . . . . . . . . . . 9 72 5. Address Pooling Paired (APP) . . . . . . . . . . . . . . . . . 10 73 6. EIF Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. EIF Protocol Independence . . . . . . . . . . . . . . . . . . 10 75 8. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Outbound Mapping Refresh and Error Packets . . . . . . . . 11 77 9. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 11 78 10. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11. Port Randomization . . . . . . . . . . . . . . . . . . . . . . 11 80 12. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 12 81 13. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 12 82 14. Hairpinning Support for ICMP Packets . . . . . . . . . . . . . 12 83 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 16. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 18.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 18.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Terminology 93 The reader should be familiar with all terms defined in RFC2663 94 [RFC2663],RFC4787 [RFC4787],RFC5382 [RFC5382],RFC5508 [RFC5508] 96 2. Introduction 98 [RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT 99 interoperability and conformance. But with widespread deployment and 100 evolution of NAT more development and operational experience was 101 acquired some areas of the original documents need further 102 clarification or updates. This documents provides such 103 clarifications and updates. 105 2.1. Scope 107 This document focuses solely on NAPT44 and its goal is to clarify, 108 fill gaps or update requirements of [RFC4787], [RFC5382] and 109 [RFC5508]. It is out of the scope of this document the creation of 110 completely new requirements not associated with the documents cited 111 above. New requirements would be better served elsewhere and if they 112 are CGN specific in [I-D.ietf-behave-lsn-requirements] 114 3. TCP Session Tracking 116 [RFC5382] specifies TCP timers associated with various connection 117 states but does not specify the TCP state machine a NAPT44 should use 118 as a basis to apply such timers. The TCP state machine below, 119 adapted from [RFC6146], provides guidance on how TCP session tracking 120 could be implemented - it is non-normative. 122 +-----------------------------+ 123 | | 124 V | 125 +------+ CV4 | 126 |CLOSED|-----SYN------+ | 127 +------+ | | 128 ^ | | 129 |TCP_TRANS T.O. | | 130 | V | 131 +-------+ +-------+ | 132 | TRANS | |V4 INIT| | 133 +-------+ +-------+ | 134 | ^ | | 135 data pkt | | | 136 | V4 or V4 RST | | 137 | TCP_EST T.O. | | 138 V | SV4 SYN | 139 +--------------+ | | 140 | ESTABLISHED |<---------+ | 141 +--------------+ | 142 | | | 143 CV4 FIN SV4 FIN | 144 | | | 145 V V | 146 +---------+ +----------+ | 147 |CV4 FIN | | SV4 FIN | | 148 | RCV | | RCV | | 149 +---------+ +----------+ | 150 | | | 151 SV4 FIN CV4 FIN TCP_TRANS 152 | | T.O. 153 V V | 154 +----------------------+ | 155 | CV4 FIN + SV4 FIN RCV|--------------------+ 156 +----------------------+ 157 (postamble) 159 3.1. TCP Transitory Connection Idle-Timeout 161 [RFC5382]:REQ-5 The transitory connection idle-timeout is defined as 162 the minimum time a TCP connection in the partially open or closing 163 phases must remain idle before the NAT considers the associated 164 session a candidate for removal. But the document does not clearly 165 states if these can be configured separately. This document 166 clarifies that a NAT device SHOULD provide different knobs for 167 configuring the open and closing idle timeouts. This document 168 further acknowledges that most TCP flows are very short (less than 10 169 seconds) [FLOWRATE][TCPWILD] and therefore a partially open timeout 170 of 4 minutes might be excessive if security is a concern. Therefore 171 it MAY be configured to be less than 4 minutes in such cases. There 172 also may be a case that timeout of 4 minutes might be excessive. The 173 case and the solution are written below. 175 3.1.1. Port resources limited case 177 After IPv4 addresses run out, IPv4 address resources will be further 178 restricted site-by-site. If global IPv4 address are shared between 179 several clients, assignable port resources at each client will be 180 limited. 182 NAT is a tool that is widely used to deal with this IPv4 address 183 shortage problem. However, the demand for resources to provide 184 Internet access to users and devices will continue to increase. IPv6 185 is a fundamental solution to this problem, but the deployment of IPv6 186 will take time. 188 In some cases, e.g. browsing a dynamic web page for a map service, a 189 lot of sessions are used by the browser, and a number of ports are 190 eaten up in a short time. What is worse is that when a NAT is 191 between a PC and a server, TIME_WAIT state of each TCP connection is 192 kept for certain period, typically for four minutes, which consumes 193 port resources. Therefore, new connections cannot be established. 195 This problem is caused or worsened by the following behavior. 197 TIME_WAIT state assigned for a TCP connection remains active for 198 2MSL after the last ACK to the last FIN is transferred. 200 To reuse resources effectively, reducing TIME_WAIT without making any 201 bad effect is important. To reduce TIME_WAIT, [RFC6191] is proposed 202 for clients and remote hosts. To prevent bad effects, there is a 203 PAWS mechanism, which prevent the old duplicate problem. We propose 204 mechanisms adopting to NAT, to change the TIME_WAIT behavior that 205 make it possible to save addresses and ports resources. 207 3.1.1.1. RFC6191 Reducing the TIME-WAIT State Using TCP Timestamps 209 [RFC6191] defines a mechanism for reducing the TIME_WAIT state using 210 TCP timestamps and sequence numbers. When a connection request is 211 received with a four-tuple that is in the TIME-WAIT state, the 212 connection request may be accepted if the sequence number or the 213 timestamp of the incoming SYN segment is greater than the last 214 sequence number seen on the previous incarnation of the connection 216 3.1.1.2. TCP TIME_WAIT 218 The TCP TIME_WAIT state is described in [RFC0793]. The TCP TIME_WAIT 219 state needs to be kept for 2MSL before a connection is CLOSED, for 220 the reasons below. 222 1: In the event that packets from a session are delayed in the in- 223 between network, and delivered to the end relatively later, we 224 should prevent the packets from being transferred and interpreted 225 as a packet that belongs to a new session. 227 2: If the remote TCP has not received the acknowledgment of its 228 connection termination request, it will re-send the FIN packet 229 several times. 231 These points are important for the TCP to work without problems. 233 3.1.1.3. Protect Against Wrapped Sequence numbers (PAWS) 235 The TCP sequence number wraps frequently especially in a high 236 bandwidth session. PAWS is used to prevent old duplicate packets 237 that occurred in a previous session from being transferred to the new 238 session whose valid TCP sequence numbers happen to overlap with the 239 old duplicate packets. This is implemented by introducing TCP 240 timestamp option, and checking the timestamp option value of each 241 packet. PAWS is described in [RFC1323]. 243 3.1.2. Proposal: Apply RFC6191 and PAWS to NAT 245 This section proposes to apply [RFC6191] mechanism at NAT. This 246 mechanism MAY be adopted for both clients' and remote hosts' TCP 247 active close. 249 client NAT remote host 250 | | | 251 | FIN | FIN | 252 |------------------------>|------------------------>| 253 | | | 254 | ACK | ACK | 255 |<------------------------|<------------------------| 256 | FIN | FIN | 257 |<------------------------|<------------------------| 258 | | | 259 | ACK(TSval=A) | ACK | 260 |------------------------>|------------------------>| 261 | | - | 262 | | | | 263 | | | | 264 | | | | 265 | | | TIME_WAIT | 266 | | | ->assassinated at x | 267 | | | | 268 | | | | 269 | | | | 270 | SYN(TSval>A) | x SYN | 271 |------------------------>|------------------------>| 272 | | - | 273 | | | | 274 | | | SYN_SENT | 275 | | | | 276 | | | | 277 (postamble) 279 Also, PAWS works to discard old duplicate packets at NAT. A packet 280 can be discarded as an old duplicate if it is received with a 281 timestamp or sequence number value less than a value recently 282 received on the connection. 284 To make these mechanisms work, we should concern the case that there 285 are several clients with nonsuccessive timestamp or sequence number 286 values are connected to a NAT device (i.e. not monotonically 287 increasing among clients). Two mechanisms to solve this mechanism 288 and applying [RFC6191] and PAWS to NAT are described below. These 289 mechanisms are optional. 291 3.1.2.1. Rewrite timestamp and sequence number values at NAT 293 Rewrite timestamp and sequence number values of outgoings packets at 294 NAT to be monotonically increasing. This can be done by adopting 295 following mechanisms at NAT. 297 A: Store the newest rewritten value of timestamp and sequence number 298 as the "max value at the time". 300 B: NAT rewrite timestamp and sequence number values of incoming 301 packets to be monotonically increasing. 303 When packets come back as replies from remote hosts, NAT rewrite 304 again the timestamp and sequence number values to be the original 305 values. This can be done by adopting following mechanisms at NAT. 307 C: Store the values of original timestamp and sequence number of 308 packets, and rewritten values of those. 310 3.1.2.2. Split an assignable number of port space to each client 312 Adopt following mechanisms at NAT. 314 A: Choose clients that can be assigned ports. 316 B: Split assignable port numbers between clients. 318 Packets from other clients which are not chosen by these mechanisms 319 are rejected at NAT, unless there is unassigned port left. 321 3.1.2.3. Resend the last ACK to the resended FIN 323 We should concern another case to make RFC6191 work at NAT. In case 324 the remote TCP could not receive the acknowledgment of its connection 325 termination request, NAT, on behalf of clients. resends the last ACK 326 packet when it receives an FIN packet of the previous connection, and 327 when the state of the previous connection is deleted from the NAT. 328 This mechanism MAY be used when clients starts closing process, and 329 the remote host could not receive the last ACK. 331 3.1.2.4. Remote host behavior of several implementations 333 To solve the port shortage problem on the client side, the behavior 334 of remote host should be compliant to [RFC6191] or the mechanism 335 written in 4.2.2.13 of [RFC1122], since NAT may reuse the same 5 336 tuple for a new connection.We have investigated behaviors of OSes 337 (e.g., Linux, FreeBSD, Windows, MacOS), and found that they 338 implemented the server side behavior of the above two. 340 3.2. TCP RST 342 [RFC5382] leaves the handling of TCP RST packets unspecified. This 343 document does not try standardize such behavior but clarifies based 344 on operational experience that a NAT that receives a TCP RST for an 345 active mapping and performs session tracking MAY immediately delete 346 the sessions and remove any state associated with it. If the NAT 347 device that performs TCP session tracking receives a TCP RST for the 348 first session that created a mapping, it MAY remove the session and 349 the mapping immediately. 351 4. Port Overlapping behavior 353 There may be another solution to the address resource restricted 354 environment written in 3.1.1. Also NAT are required to be maped 355 endpoint-independent in [RFC4787] and [RFC5382] REQ-1, the mechanism 356 below MAY be one optional implement to NAT. 358 If destination addresses and ports are different for outgoing 359 connections started by local clients, NAT MAY assign the same 360 external port as the source ports for the connections. The port 361 overlapping mechanism manages mappings between external packets and 362 internal packets by looking at and storing the 5-tuple (protocol, 363 source address, source port, destination address, destination port) 364 of them. This enables concurrent use of a single NAT external port 365 for multiple transport sessions, which enables NAT to work correctly 366 in IP address resource limited network. 368 Discussions: 370 [RFC4787]and[FC5382] requires "endpoint-independent mapping" at NAT, 371 and port overlapping NAT cannot meet the requirement. This mechanism 372 can degrade the transparency of NAT in that its mapping mechanism is 373 endpoint-dependent and makes NAT traversal harder. However, if a NAT 374 adopts endpoint-independent mapping together with endpoint-dependent 375 filtering, then the actual behavior of the NAT will be the same as 376 port overlapping NAT. It should also be noted that a lot of existing 377 NAT devices(e.g., SEIL, FITELnet Series) adopted this port 378 overlapping mechanism. 380 A: Reference URL for SEIL -> www.seil.jp 382 B: Reference URL for FITELnet -> www.furukawa.co.jp/fitelnet 384 The netfilter, which is a popular packet filtering mechanism for 385 Linux, also adopts port overlapping behavior. 387 5. Address Pooling Paired (APP) 389 [RFC4787]: REQ-2 [RFC5382]:ND Address Pooling Paired behavior for NAT 390 is recommended in previous documents but behavior when a public IPv4 391 run out of ports is left undefined. This document clarifies that if 392 APP is enabled new sessions from a subscriber that already has a 393 mapping associated with a public IP that ran out of ports SHOULD be 394 dropped. The administrator MAY provide a knob that allows a NAT 395 device to starting using ports from another public IP when the one 396 that anchored the APP mapping ran out of ports. This is trade-off 397 between subscriber service continuity and APP strict enforcement. 398 (NE: It is sometimes referred as 'soft-APP') 400 6. EIF Security 402 [RFC4787]:REQ-8 and [RFC5382]:REQ-3 End-point independent filtering 403 could potentially result in security attacks from the public realm. 404 In order to handle this, when possible there MUST be strict filtering 405 checks in the inbound direction. A knob SHOULD be provided to limit 406 the number of inbound sessions and a knob SHOULD be provided to 407 enable or disable EIF on a per application basis. This is specially 408 important in the case of Mobile networks where such attacks can 409 consume radio resources and count against the user quota. 411 7. EIF Protocol Independence 413 [RFC4787]:REQ-8 and[RFC5382]: REQ-3 Current RFCs do not specify 414 whether EIF mappings are protocol independent. In other words, if a 415 outbound TCP SYN creates a mapping it is left undefined whether 416 inbound UDP packets create sessions and are forwarded. EIF mappings 417 SHOULD be protocol independent in order allow inbound packets for 418 protocols that multiplex TCP and UDP over the same IP: port through 419 the NAT and maintain compatibility with stateful NAT64 RFC6146 420 [RFC6146]. But the administrator MAY provide a configuration knob to 421 make it protocol dependent. 423 8. EIF Mapping Refresh 425 [RFC4787]: REQ-6 [RFC5382]: ND The NAT mapping Refresh direction MAY 426 have a "NAT Inbound refresh behavior" of "True" but it does not 427 clarifies how this applies to EIF mappings. The issue in question is 428 whether inbound packets that match an EIF mapping but do not create a 429 new session due to a security policy should refresh the mapping 430 timer. This document clarifies that even when a NAT device has a 431 inbound refresh behavior of TRUE, that such packets SHOULD NOT 432 refresh the mapping. Otherwise a simple attack of a packet every 2 433 minutes can keep the mapping indefinitely. 435 8.1. Outbound Mapping Refresh and Error Packets 437 In the case of NAT outbound refresh behavior there might be certain 438 types of packets that should not refresh the mapping. For example, 439 if the mapping is kept alive by ICMP Error or TCP RST outbound 440 packets sent as response to inbound packets, these SHOULD NOT refresh 441 the mapping. 443 9. EIM Protocol Independence 445 [RFC4787] [RFC5382]: REQ-1 Current RFCs do not specify whether EIM 446 are protocol independent. In other words, if a outbound TCP SYN 447 creates a mapping it is left undefined whether outbound UDP can reuse 448 such mapping and create session. On the other hand, Stateful NAT64 449 [RFC6146] clearly specifies three binding information bases (TCP, 450 UDP, ICMP). This document clarifies that EIM mappings SHOULD be 451 protocol dependent . A knob MAY be provided in order allow protocols 452 that multiplex TCP and UDP over the same source IP and port to use a 453 single mapping. 455 10. Port Parity 457 A NAT devices MAY disable port parity preservation for dynamic 458 mappings. Nevertheless, A NAT SHOULD support means to explicitly 459 request to preserve port parity (e.g., [I-D.boucadair-pcp-rtp-rtcp]). 461 11. Port Randomization 463 A NAT SHOULD follow the recommendations specified in Section 4 of 464 [RFC6056] especially: "A NAPT that does not implement port 465 preservation [RFC4787] [RFC5382] SHOULD obfuscate selection of the 466 ephemeral port of a packet when it is changed during translation of 467 that packet. A NAPT that does implement port preservation SHOULD 468 obfuscate the ephemeral port of a packet only if the port must be 469 changed as a result of the port being already in use for some other 470 session. A NAPT that performs parity preservation and that must 471 change the ephemeral port during translation of a packet SHOULD 472 obfuscate the ephemeral ports. The algorithms described in this 473 document could be easily adapted such that the parity is preserved 474 (i.e., force the lowest order bit of the resulting port number to 0 475 or 1 according to whether even or odd parity is desired)." 477 12. IP Identification (IP ID) 479 A NAT SHOULD handle the Identification field of translated IPv4 480 packets as specified in Section 9 of [I-D.ietf-intarea-ipv4-id- 481 update]. 483 13. ICMP Query Mappings Timeout 485 Section 3.1 of [RFC5508] says that ICMP Query Mappings are to be 486 maintained by NAT device. However, RFC doesn't discuss about the 487 Query Mapping timeout values. Section 3.2 of that RFC only discusses 488 about ICMP Query Session Timeouts. ICMP Query Mappings MAY be 489 deleted once the last the session using the mapping is deleted. 491 14. Hairpinning Support for ICMP Packets 493 [RFC5508]:REQ-7 This requirement specifies that NAT devices enforcing 494 Basic NAT MUST support traversal of hairpinned ICMP Query sessions. 495 This implicitly means that address mappings from external address to 496 internal address (similar to Endpoint Independent Filters) MUST be 497 maintained to allow inbound ICMP Query sessions. If an ICMP Query is 498 received on an external address, NAT device can then translate to an 499 internal IP. [RFC5508]:REQ-7 This requirement specifies that all NAT 500 devices (i.e., Basic NAT as well as NAPT devices) MUST support the 501 traversal of hairpinned ICMP Error messages. This too requires NAT 502 devices to maintain address mappings from external IP address to 503 internal IP address in addition to the ICMP Query Mappings described 504 in section 3.1 of that RFC. 506 15. IANA Considerations 508 TBD 510 16. Security Considerations 512 In the case of EIF mappings due to high risk of resource crunch, a 513 NAT device MAY provide a knob to limit the number of inbound sessions 514 spawned from a EIF mapping. 516 [TCP-Security] contains a detailed discussion of the security 517 implications of TCP Timestamps and of different timestamp generation 518 algorithms. 520 17. Acknowledgements 522 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan and 523 Senthil Sivamular for review and discussions 525 18. References 527 18.1. Normative References 529 [I-D.ietf-pcp-base] 530 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 531 Selkirk, "Port Control Protocol (PCP)", 532 draft-ietf-pcp-base-29 (work in progress), November 2012. 534 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 535 RFC 793, September 1981. 537 [RFC1122] Braden, R., "Requirements for Internet Hosts - 538 Communication Layers", STD 3, RFC 1122, October 1989. 540 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 541 for High Performance", RFC 1323, May 1992. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 547 Translator (NAT) Terminology and Considerations", 548 RFC 2663, August 1999. 550 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 551 in Session Description Protocol (SDP)", RFC 3605, 552 October 2003. 554 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 555 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 556 RFC 4787, January 2007. 558 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 559 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 560 RFC 5382, October 2008. 562 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 563 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 564 April 2009. 566 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 567 Protocol Port Randomization", BCP 156, RFC 6056, 568 January 2011. 570 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 571 NAT64: Network Address and Protocol Translation from IPv6 572 Clients to IPv4 Servers", RFC 6146, April 2011. 574 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 575 Timestamps", BCP 159, RFC 6191, April 2011. 577 18.2. Informative References 579 [FLOWRATE] 580 Zhang, Y., Breslau, L., Paxson, V., and S. Shenker, "On 581 the Characteristics and Origins of Internet Flow Rates". 583 [I-D.boucadair-pcp-rtp-rtcp] 584 Boucadair, M. and S. Sivakumar, "Reserving N and N+1 Ports 585 with PCP", draft-boucadair-pcp-rtp-rtcp-05 (work in 586 progress), October 2012. 588 [I-D.ietf-behave-lsn-requirements] 589 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 590 and H. Ashida, "Common requirements for Carrier Grade NATs 591 (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in 592 progress), December 2012. 594 [I-D.naito-nat-resource-optimizing-extension] 595 Kengo, K. and A. Matsumoto, "NAT TIME_WAIT reduction", 596 draft-naito-nat-resource-optimizing-extension-02 (work in 597 progress), July 2012. 599 [TCPWILD] Qian, F., Subhabrata, S., Spatscheck, O., Morley Mao, Z., 600 and W. Willinger, "TCP Revisited: A Fresh Look at TCP in 601 the Wild". 603 Authors' Addresses 605 Reinaldo Penno 606 Cisco Systems, Inc. 607 170 West Tasman Drive 608 San Jose, California 95134 609 USA 611 Email: repenno@cisco.com 613 Simon Perreault 614 Viagenie 615 2875 boul. Laurier, suite D2-630 616 Quebec, QC G1V 2M2 617 Canada 619 Email: simon.perreault@viagenie.ca 621 Sarat Kamiset 622 Consultant 623 California 625 Phone: 626 Fax: 628 Mohamed Boucadair 629 France Telecom 630 Rennes, 35000 631 France 633 Email: mohamed.boucadair@orange.com 635 Kengo Naito 636 NTT 637 Tokyo 638 Japan 640 Email: kengo@lab.ntt.co.jp