idnits 2.17.1 draft-ietf-tsvwg-behave-requirements-update-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 : ---------------------------------------------------------------------------- == 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 (November 19, 2013) is 3811 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: 'RFC5283' is mentioned on line 191, but not defined == Missing Reference: 'I-D.pcp-port-set' is mentioned on line 426, but not defined == Missing Reference: 'TCP-Security' is mentioned on line 483, but not defined == Unused Reference: 'RFC1323' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pcp-port-set' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'I-D.naito-nat-resource-optimizing-extension' is defined on line 555, 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 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-03 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG R. Penno 3 Internet-Draft Cisco 4 Intended status: Best Current Practice S. Perreault 5 Expires: May 23, 2014 Viagenie 6 S. Kamiset 7 Insieme Networks 8 M. Boucadair 9 France Telecom 10 K. Naito 11 NTT 12 November 19, 2013 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-ietf-tsvwg-behave-requirements-update-00 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 May 23, 2014. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. TCP Session Tracking . . . . . . . . . . . . . . . . . . . . 3 66 3.1. TCP Transitory Connection Idle-Timeout . . . . . . . . . 4 67 3.2. TIME_WAIT State . . . . . . . . . . . . . . . . . . . . . 4 68 3.2.1. Proposal: Apply RFC6191 and PAWS to NAT . . . . . . 5 69 3.3. TCP RST . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Port Overlapping behavior . . . . . . . . . . . . . . . . . . 8 71 5. Address Pooling Paired (APP) . . . . . . . . . . . . . . . . 8 72 6. EIF Security . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. EIF Protocol Independence . . . . . . . . . . . . . . . . . . 9 74 8. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Outbound Mapping Refresh and Error Packets . . . . . . . 9 76 9. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 9 77 10. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11. Port Randomization . . . . . . . . . . . . . . . . . . . . . 10 79 12. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 10 80 13. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 10 81 14. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 10 82 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 16. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 18.1. Normative References . . . . . . . . . . . . . . . . . . 11 87 18.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Terminology 92 The reader should be familiar with all terms defined in RFC2663 93 [RFC2663],RFC4787 [RFC4787],RFC5382 [RFC5382],RFC5508 [RFC5508] 95 2. Introduction 97 [RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT 98 interoperability and conformance. But with widespread deployment and 99 evolution of NAT more development and operational experience was 100 acquired some areas of the original documents need further 101 clarification or updates. This documents provides such 102 clarifications and updates. 104 2.1. Scope 106 This document focuses solely on NAPT44 and its goal is to clarify, 107 fill gaps or update requirements of [RFC4787], [RFC5382] and 108 [RFC5508]. It is out of the scope of this document the creation of 109 completely new requirements not associated with the documents cited 110 above. New requirements would be better served elsewhere and if they 111 are CGN specific in an update to [RFC6888]. 113 3. TCP Session Tracking 115 [RFC5382] specifies TCP timers associated with various connection 116 states but does not specify the TCP state machine a NAPT44 should use 117 as a basis to apply such timers. The TCP state machine below, 118 adapted from [RFC6146], provides guidance on how TCP session tracking 119 could be implemented - it is non-normative. 121 +-----------------------------+ 122 | | 123 V | 124 +------+ CV4 | 125 |CLOSED|-----SYN------+ | 126 +------+ | | 127 ^ | | 128 |TCP_TRANS T.O. | | 129 | V | 130 +-------+ +-------+ | 131 | TRANS | |V4 INIT| | 132 +-------+ +-------+ | 133 | ^ | | 134 data pkt | | | 135 | V4 or V4 RST | | 136 | TCP_EST T.O. | | 137 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 +----------------------+ 158 3.1. TCP Transitory Connection Idle-Timeout 160 [RFC5382]:REQ-5 The transitory connection idle-timeout is defined as 161 the minimum time a TCP connection in the partially open or closing 162 phases must remain idle before the NAT considers the associated 163 session a candidate for removal. But the document does not clearly 164 states if these can be configured separately. This document 165 clarifies that a NAT device SHOULD provide different knobs for 166 configuring the open and closing idle timeouts. This document 167 further acknowledges that most TCP flows are very short (less than 10 168 seconds) [FLOWRATE][TCPWILD] and therefore a partially open timeout 169 of 4 minutes might be excessive if security is a concern. Therefore 170 it MAY be configured to be less than 4 minutes in such cases. There 171 also may be cases that a timeout of 4 minutes might be excessive. 172 The case and the solution are written below. 174 3.2. TIME_WAIT State 176 The TCP TIME_WAIT state is described in [RFC0793]. The TCP TIME_WAIT 177 state needs to be kept for 2MSL before a connection is CLOSED, for 178 the reasons below. 180 1: In the event that packets from a session are delayed in the in- 181 between network, and delivered to the end relatively later, we 182 should prevent the packets from being transferred and interpreted 183 as a packet that belongs to a new session. 185 2: If the remote TCP has not received the acknowledgment of its 186 connection termination request, it will re-send the FIN packet 187 several times. 189 These points are important for the TCP to work without problems. 191 [RFC5283] leaves the handling of TCP connections in TIME_WAIT state 192 unspecified and mentions that TIME_WAIT state is not part of the 193 transitory connection idle-timeout. If the NAT device honors the 194 TIME_WAIT state, each TCP connection and its associated resources is 195 kept for a certain period, typically for four minutes, which consumes 196 port resources. 198 [RFC6191] explains that in certain situation it is necessary to 199 reduce the TIME_WAIT state and defines such a mechanism using TCP 200 timestamps and sequence numbers. When a connection request is 201 received with a four-tuple that is in the TIME-WAIT state, the 202 connection request may be accepted if the sequence number or the 203 timestamp of the incoming SYN segment is greater than the last 204 sequence number seen on the previous incarnation of the connection. 206 [N.E] This document specifies that a NAT device should keep TCP 207 connections in TIME_WAIT state unless it implements the proposal 208 below? 210 3.2.1. Proposal: Apply RFC6191 and PAWS to NAT 212 This section proposes to apply [RFC6191] mechanism at NAT. This 213 mechanism MAY be adopted for both clients' and remote hosts' TCP 214 active close. 216 client NAT remote host 217 | | | 218 | FIN | FIN | 219 |------------------------>|------------------------>| 220 | | | 221 | ACK | ACK | 222 |<------------------------|<------------------------| 223 | FIN | FIN | 224 |<------------------------|<------------------------| 225 | | | 226 | ACK(TSval=A) | ACK | 227 |------------------------>|------------------------>| 228 | | - | 229 | | | | 230 | | | | 231 | | | | 232 | | | TIME_WAIT | 233 | | | ->assassinated at x | 234 | | | | 235 | | | | 236 | | | | 237 | SYN(TSval>A) | x SYN | 238 |------------------------>|------------------------>| 239 | | - | 240 | | | | 241 | | | SYN_SENT | 242 | | | | 243 | | | | 245 (postamble) 247 Also, PAWS works to discard old duplicate packets at NAT. A packet 248 can be discarded as an old duplicate if it is received with a 249 timestamp or sequence number value less than a value recently 250 received on the connection. 252 To make these mechanisms work, we should concern the case that there 253 are several clients with nonsuccessive timestamp or sequence number 254 values are connected to a NAT device (i.e. not monotonically 255 increasing among clients). Two mechanisms to solve this mechanism 256 and applying [RFC6191] and PAWS to NAT are described below. These 257 mechanisms are optional. 259 3.2.1.1. Rewrite timestamp and sequence number values at NAT 261 Rewrite timestamp and sequence number values of outgoings packets at 262 NAT to be monotonically increasing. This can be done by adopting 263 following mechanisms at NAT. 265 A: Store the newest rewritten value of timestamp and sequence number 266 as the "max value at the time". 268 B: NAT rewrite timestamp and sequence number values of incoming 269 packets to be monotonically increasing. 271 When packets come back as replies from remote hosts, NAT rewrite 272 again the timestamp and sequence number values to be the original 273 values. This can be done by adopting following mechanisms at NAT. 275 C: Store the values of original timestamp and sequence number of 276 packets, and rewritten values of those. 278 3.2.1.2. Split an assignable number of port space to each client 280 Adopt following mechanisms at NAT. 282 A: Choose clients that can be assigned ports. 284 B: Split assignable port numbers between clients. 286 Packets from other clients which are not chosen by these mechanisms 287 are rejected at NAT, unless there is unassigned port left. 289 3.2.1.3. Resend the last ACK to the retransmisstted FIN 291 We need to solve another scenario to make RFC6191 work with NAT. In 292 the case the remote TCP could not receive the acknowledgment of its 293 connection termination request, the NAT device, on behalf of clients, 294 resends the last ACK packet when it receives a FIN packet of the 295 previous connection, and when the state of the previous connection 296 has been deleted from the NAT. This mechanism MAY be used when 297 clients starts closing process, and the remote host could not receive 298 the last ACK. 300 3.2.1.4. Remote host behavior of several implementations 302 To solve the port shortage problem on the client side, the behavior 303 of remote host should be compliant to [RFC6191] or the mechanism 304 written in 4.2.2.13 of [RFC1122], since NAT may reuse the same 5 305 tuple for a new connection. We have investigated behaviors of OSes 306 (e.g., Linux, FreeBSD, Windows, MacOS), and found that they 307 implemented the server side behavior of the above two. 309 3.3. TCP RST 311 [RFC5382] leaves the handling of TCP RST packets unspecified. This 312 document does not try standardize such behavior but clarifies based 313 on operational experience that a NAT that receives a TCP RST for an 314 active mapping and performs session tracking MAY immediately delete 315 the sessions and remove any state associated with it. If the NAT 316 device that performs TCP session tracking receives a TCP RST for the 317 first session that created a mapping, it MAY remove the session and 318 the mapping immediately. 320 4. Port Overlapping behavior 322 [RFC4787] [RFC5382]: REQ-1 Current RFCs specifiy a specific port 323 overlapping behavior, i.e., that the external IP:port can be reused 324 for connections originating from the same internal source IP:port 325 irrespective of the destination. This is known as endpoint- 326 independent mapping. This document clarifies that this port 327 overlapping behavior can be extended to connections originating from 328 different internal source IP:ports as long as their destinations are 329 different. This known as EDM (Endpoint Dependent Mapping). The 330 mechanism below MAY be one optional implement to NAT. 332 If destination addresses and ports are different for outgoing 333 connections started by local clients, NAT MAY assign the same 334 external port as the source ports for the connections. The port 335 overlapping mechanism manages mappings between external packets and 336 internal packets by looking at and storing their 5-tuple (protocol, 337 source address, source port, destination address, destination port) . 338 This enables concurrent use of a single NAT external port for 339 multiple transport sessions, which enables NAT to work correctly in 340 IP address resource limited network. 342 Discussions: 344 [RFC4787] and [RFC5382] requires "endpoint-independent mapping" at 345 NAT, and port overlapping NAT cannot meet the requirement. This 346 mechanism can degrade the transparency of NAT in that its mapping 347 mechanism is endpoint-dependent and makes NAT traversal harder. 348 However, if a NAT adopts endpoint-independent mapping together with 349 endpoint-dependent filtering, then the actual behavior of the NAT 350 will be the same as port overlapping NAT. 352 5. Address Pooling Paired (APP) 354 [RFC4787]: REQ-2 [RFC5382]:ND Address Pooling Paired behavior for NAT 355 is recommended in previous documents but behavior when a public IPv4 356 run out of ports is left undefined. This document clarifies that if 357 APP is enabled new sessions from a subscriber that already has a 358 mapping associated with a public IP that ran out of ports SHOULD be 359 dropped. The administrator MAY provide a knob that allows a NAT 360 device to starting using ports from another public IP when the one 361 that anchored the APP mapping ran out of ports. This is trade-off 362 between subscriber service continuity and APP strict enforcement. 363 (NE: It is sometimes referred as 'soft-APP') 365 6. EIF Security 367 [RFC4787]:REQ-8 and [RFC5382]:REQ-3 End-point independent filtering 368 could potentially result in security attacks from the public realm. 369 In order to handle this, when possible there MUST be strict filtering 370 checks in the inbound direction. A knob SHOULD be provided to limit 371 the number of inbound sessions and a knob SHOULD be provided to 372 enable or disable EIF on a per application basis. This is specially 373 important in the case of Mobile networks where such attacks can 374 consume radio resources and count against the user quota. 376 7. EIF Protocol Independence 378 [RFC4787]:REQ-8 and[RFC5382]: REQ-3 Current RFCs do not specify 379 whether EIF mappings are protocol independent. In other words, if an 380 outbound TCP SYN creates a mapping, it is left undefined whether 381 inbound UDP packets destined to that mapping should be forwarded. 382 This document specifies that EIF mappings SHOULD be protocol 383 independent in order allow inbound packets for protocols that 384 multiplex TCP and UDP over the same IP: port through the NAT and also 385 maintain compatibility with stateful NAT64 RFC6146 [RFC6146]. But 386 the administrator MAY provide a configuration knob to make it 387 protocol dependent. 389 8. EIF Mapping Refresh 391 [RFC4787]: REQ-6 [RFC5382]: ND The NAT mapping Refresh direction MAY 392 have a "NAT Inbound refresh behavior" of "True" but it does not 393 clarifies how this applies to EIF mappings. The issue in question is 394 whether inbound packets that match an EIF mapping but do not create a 395 new session due to a security policy should refresh the mapping 396 timer. This document clarifies that even when a NAT device has a 397 inbound refresh behavior of TRUE, such packets SHOULD NOT refresh the 398 mapping. Otherwise a simple attack of a packet every 2 minutes can 399 keep the mapping indefinitely. 401 8.1. Outbound Mapping Refresh and Error Packets 403 In the case of NAT outbound refresh behavior there are certain types 404 of packets that should not refresh the mapping even if their 405 direction is outbound. For example, if the mapping is kept alive by 406 ICMP Errors or TCP RST outbound packets sent as response to inbound 407 packets, these SHOULD NOT refresh the mapping. 409 9. EIM Protocol Independence 411 [RFC4787] [RFC5382]: REQ-1 Current RFCs do not specify whether EIM 412 are protocol independent. In other words, if a outbound TCP SYN 413 creates a mapping it is left undefined whether outbound UDP can reuse 414 such mapping and create session. On the other hand, Stateful NAT64 416 [RFC6146] clearly specifies three binding information bases (TCP, 417 UDP, ICMP). This document clarifies that EIM mappings SHOULD be 418 protocol dependent . A knob MAY be provided in order allow protocols 419 that multiplex TCP and UDP over the same source IP and port to use a 420 single mapping. 422 10. Port Parity 424 A NAT devices MAY disable port parity preservation for dynamic 425 mappings. Nevertheless, A NAT SHOULD support means to explicitly 426 request to preserve port parity (e.g., [I-D.pcp-port-set]). 428 11. Port Randomization 430 A NAT SHOULD follow the recommendations specified in Section 4 of 431 [RFC6056] especially: "A NAPT that does not implement port 432 preservation [RFC4787] [RFC5382] SHOULD obfuscate selection of the 433 ephemeral port of a packet when it is changed during translation of 434 that packet. A NAPT that does implement port preservation SHOULD 435 obfuscate the ephemeral port of a packet only if the port must be 436 changed as a result of the port being already in use for some other 437 session. A NAPT that performs parity preservation and that must 438 change the ephemeral port during translation of a packet SHOULD 439 obfuscate the ephemeral ports. The algorithms described in this 440 document could be easily adapted such that the parity is preserved 441 (i.e., force the lowest order bit of the resulting port number to 0 442 or 1 according to whether even or odd parity is desired)." 444 12. IP Identification (IP ID) 446 A NAT SHOULD handle the Identification field of translated IPv4 447 packets as specified in Section 9 of [I-D.ietf-intarea-ipv4-id- 448 update]. 450 13. ICMP Query Mappings Timeout 452 Section 3.1 of [RFC5508] says that ICMP Query Mappings are to be 453 maintained by NAT device. However, RFC doesn't discuss about the 454 Query Mapping timeout values. Section 3.2 of that RFC only discusses 455 about ICMP Query Session Timeouts. ICMP Query Mappings MAY be 456 deleted once the last the session using the mapping is deleted. 458 14. Hairpinning Support for ICMP Packets 460 [RFC5508]:REQ-7 This requirement specifies that NAT devices enforcing 461 Basic NAT MUST support traversal of hairpinned ICMP Query sessions. 462 This implicitly means that address mappings from external address to 463 internal address (similar to Endpoint Independent Filters) MUST be 464 maintained to allow inbound ICMP Query sessions. If an ICMP Query is 465 received on an external address, NAT device can then translate to an 466 internal IP. [RFC5508]:REQ-7 This requirement specifies that all NAT 467 devices (i.e., Basic NAT as well as NAPT devices) MUST support the 468 traversal of hairpinned ICMP Error messages. This too requires NAT 469 devices to maintain address mappings from external IP address to 470 internal IP address in addition to the ICMP Query Mappings described 471 in section 3.1 of that RFC. 473 15. IANA Considerations 475 TBD 477 16. Security Considerations 479 In the case of EIF mappings due to high risk of resource crunch, a 480 NAT device MAY provide a knob to limit the number of inbound sessions 481 spawned from a EIF mapping. 483 [TCP-Security] contains a detailed discussion of the security 484 implications of TCP Timestamps and of different timestamp generation 485 algorithms. 487 17. Acknowledgements 489 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan and 490 Senthil Sivamular for review and discussions 492 18. References 494 18.1. Normative References 496 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 497 793, September 1981. 499 [RFC1122] Braden, R., "Requirements for Internet Hosts - 500 Communication Layers", STD 3, RFC 1122, October 1989. 502 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 503 for High Performance", RFC 1323, May 1992. 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 509 Translator (NAT) Terminology and Considerations", RFC 510 2663, August 1999. 512 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 513 in Session Description Protocol (SDP)", RFC 3605, October 514 2003. 516 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 517 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 518 RFC 4787, January 2007. 520 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 521 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 522 RFC 5382, October 2008. 524 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 525 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 526 April 2009. 528 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 529 Protocol Port Randomization", BCP 156, RFC 6056, January 530 2011. 532 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 533 NAT64: Network Address and Protocol Translation from IPv6 534 Clients to IPv4 Servers", RFC 6146, April 2011. 536 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 537 Timestamps", BCP 159, RFC 6191, April 2011. 539 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 540 and H. Ashida, "Common Requirements for Carrier-Grade NATs 541 (CGNs)", BCP 127, RFC 6888, April 2013. 543 18.2. Informative References 545 [FLOWRATE] 546 Zhang, Y., Breslau, L., Paxson, V., and S. Shenker, "On 547 the Characteristics and Origins of Internet Flow Rates", . 549 [I-D.ietf-pcp-port-set] 550 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 551 T., and S. Perreault, "Port Control Protocol (PCP) 552 Extension for Port Set Allocation", draft-ietf-pcp-port- 553 set-03 (work in progress), October 2013. 555 [I-D.naito-nat-resource-optimizing-extension] 556 Kengo, K. and A. Matsumoto, "NAT TIME_WAIT reduction", 557 draft-naito-nat-resource-optimizing-extension-02 (work in 558 progress), July 2012. 560 [TCPWILD] Qian, F., Subhabrata, S., Spatscheck, O., Morley Mao, Z., 561 and W. Willinger, "TCP Revisited: A Fresh Look at TCP in 562 the Wild", . 564 Authors' Addresses 566 Reinaldo Penno 567 Cisco Systems, Inc. 568 170 West Tasman Drive 569 San Jose, California 95134 570 USA 572 Email: repenno@cisco.com 574 Simon Perreault 575 Viagenie 576 2875 boul. Laurier, suite D2-630 577 Quebec, QC G1V 2M2 578 Canada 580 Email: simon.perreault@viagenie.ca 582 Sarat Kamiset 583 Insieme Networks 584 California 586 Mohamed Boucadair 587 France Telecom 588 Rennes 35000 589 France 591 Email: mohamed.boucadair@orange.com 593 Kengo Naito 594 NTT 595 Tokyo 596 Japan 598 Email: kengo@lab.ntt.co.jp