idnits 2.17.1 draft-ietf-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 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 (June 03, 2013) is 3970 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 193, but not defined == Missing Reference: 'I-D.pcp-port-set' is mentioned on line 434, but not defined == Missing Reference: 'TCP-Security' is mentioned on line 490, but not defined == Unused Reference: 'RFC1323' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pcp-port-set' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'I-D.naito-nat-resource-optimizing-extension' is defined on line 561, 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-01 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE R. Penno 3 Internet-Draft Cisco 4 Intended status: Best Current Practice S. Perreault 5 Expires: December 05, 2013 Viagenie 6 S. Kamiset 7 Insieme Networks 8 M. Boucadair 9 France Telecom 10 K. Naito 11 NTT 12 June 03, 2013 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-ietf-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 December 05, 2013. 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) . . . . . . . . . . . . . . . . 9 72 6. EIF Security . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. EIF Protocol Independence . . . . . . . . . . . . . . . . . . 9 74 8. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Outbound Mapping Refresh and Error Packets . . . . . . . 10 76 9. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 10 77 10. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11. Port Randomization . . . . . . . . . . . . . . . . . . . . . 10 79 12. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 10 80 13. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 11 81 14. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 11 82 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 16. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 18.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 18.2. Informative References . . . . . . . . . . . . . . . . . 13 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] [I-D.ietf-behave-lsn- 112 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 +----------------------+ 158 (postamble) 160 3.1. TCP Transitory Connection Idle-Timeout 162 [RFC5382]:REQ-5 The transitory connection idle-timeout is defined as 163 the minimum time a TCP connection in the partially open or closing 164 phases must remain idle before the NAT considers the associated 165 session a candidate for removal. But the document does not clearly 166 states if these can be configured separately. This document 167 clarifies that a NAT device SHOULD provide different knobs for 168 configuring the open and closing idle timeouts. This document 169 further acknowledges that most TCP flows are very short (less than 10 170 seconds) [FLOWRATE][TCPWILD] and therefore a partially open timeout 171 of 4 minutes might be excessive if security is a concern. Therefore 172 it MAY be configured to be less than 4 minutes in such cases. There 173 also may be cases that a timeout of 4 minutes might be excessive. 174 The case and the solution are written below. 176 3.2. TIME_WAIT State 178 The TCP TIME_WAIT state is described in [RFC0793]. The TCP TIME_WAIT 179 state needs to be kept for 2MSL before a connection is CLOSED, for 180 the reasons below. 182 1: In the event that packets from a session are delayed in the in- 183 between network, and delivered to the end relatively later, we 184 should prevent the packets from being transferred and interpreted 185 as a packet that belongs to a new session. 187 2: If the remote TCP has not received the acknowledgment of its 188 connection termination request, it will re-send the FIN packet 189 several times. 191 These points are important for the TCP to work without problems. 193 [RFC5283] leaves the handling of TCP connections in TIME_WAIT state 194 unspecified and mentions that TIME_WAIT state is not part of the 195 transitory connection idle-timeout. If the NAT device honors the 196 TIME_WAIT state, each TCP connection and its assocaited resources is 197 kept for a certain period, typically for four minutes, which consumes 198 port resources. 200 [RFC6191] explains that in certain situation it is necessary to 201 reduce the TIME_WAIT state and defines such a mechanism using TCP 202 timestamps and sequence numbers. When a connection request is 203 received with a four-tuple that is in the TIME-WAIT state, the 204 connection request may be accepted if the sequence number or the 205 timestamp of the incoming SYN segment is greater than the last 206 sequence number seen on the previous incarnation of the connection. 208 [N.E] This document specifies that a NAT device should keep TCP 209 connections in TIME_WAIT state unless it implements the proposal 210 below? 212 3.2.1. Proposal: Apply RFC6191 and PAWS to NAT 214 This section proposes to apply [RFC6191] mechanism at NAT. This 215 mechanism MAY be adopted for both clients' and remote hosts' TCP 216 active close. 218 client NAT remote host 219 | | | 220 | FIN | FIN | 221 |------------------------>|------------------------>| 222 | | | 223 | ACK | ACK | 224 |<------------------------|<------------------------| 225 | FIN | FIN | 226 |<------------------------|<------------------------| 227 | | | 228 | ACK(TSval=A) | ACK | 229 |------------------------>|------------------------>| 230 | | - | 231 | | | | 232 | | | | 233 | | | | 234 | | | TIME_WAIT | 235 | | | ->assassinated at x | 236 | | | | 237 | | | | 238 | | | | 239 | SYN(TSval>A) | x SYN | 240 |------------------------>|------------------------>| 241 | | - | 242 | | | | 243 | | | SYN_SENT | 244 | | | | 245 | | | | 247 (postamble) 249 Also, PAWS works to discard old duplicate packets at NAT. A packet 250 can be discarded as an old duplicate if it is received with a 251 timestamp or sequence number value less than a value recently 252 received on the connection. 254 To make these mechanisms work, we should concern the case that there 255 are several clients with nonsuccessive timestamp or sequence number 256 values are connected to a NAT device (i.e. not monotonically 257 increasing among clients). Two mechanisms to solve this mechanism 258 and applying [RFC6191] and PAWS to NAT are described below. These 259 mechanisms are optional. 261 3.2.1.1. Rewrite timestamp and sequence number values at NAT 263 Rewrite timestamp and sequence number values of outgoings packets at 264 NAT to be monotonically increasing. This can be done by adopting 265 following mechanisms at NAT. 267 A: Store the newest rewritten value of timestamp and sequence number 268 as the "max value at the time". 270 B: NAT rewrite timestamp and sequence number values of incoming 271 packets to be monotonically increasing. 273 When packets come back as replies from remote hosts, NAT rewrite 274 again the timestamp and sequence number values to be the original 275 values. This can be done by adopting following mechanisms at NAT. 277 C: Store the values of original timestamp and sequence number of 278 packets, and rewritten values of those. 280 3.2.1.2. Split an assignable number of port space to each client 282 Adopt following mechanisms at NAT. 284 A: Choose clients that can be assigned ports. 286 B: Split assignable port numbers between clients. 288 Packets from other clients which are not chosen by these mechanisms 289 are rejected at NAT, unless there is unassigned port left. 291 3.2.1.3. Resend the last ACK to the resended FIN 293 We should concern another case to make RFC6191 work at NAT. In case 294 the remote TCP could not receive the acknowledgment of its connection 295 termination request, the NAT device, on behalf of clients, resends 296 the last ACK packet when it receives an FIN packet of the previous 297 connection, and when the state of the previous connection is deleted 298 from the NAT. This mechanism MAY be used when clients starts closing 299 process, and the remote host could not receive the last ACK. 301 3.2.1.4. Remote host behavior of several implementations 303 To solve the port shortage problem on the client side, the behavior 304 of remote host should be compliant to [RFC6191] or the mechanism 305 written in 4.2.2.13 of [RFC1122], since NAT may reuse the same 5 306 tuple for a new connection. We have investigated behaviors of OSes 307 (e.g., Linux, FreeBSD, Windows, MacOS), and found that they 308 implemented the server side behavior of the above two. 310 3.3. TCP RST 312 [RFC5382] leaves the handling of TCP RST packets unspecified. This 313 document does not try standardize such behavior but clarifies based 314 on operational experience that a NAT that receives a TCP RST for an 315 active mapping and performs session tracking MAY immediately delete 316 the sessions and remove any state associated with it. If the NAT 317 device that performs TCP session tracking receives a TCP RST for the 318 first session that created a mapping, it MAY remove the session and 319 the mapping immediately. 321 4. Port Overlapping behavior 323 [RFC4787] [RFC5382]: REQ-1 Current RFCs specifiy a specific port 324 overlapping behavior, i.e., that the external IP:port can be reused 325 for connections originating from the same internal source IP:port 326 irrespective of the detination. This is known as endpoint- 327 independent mapping. This document clarifies that this port 328 overlapping behavior can be extended to connections originating from 329 different interal source IP:ports as long as their destinations are 330 different. This known as EDM (Endpoint Dependent Mapping). The 331 mechanism below MAY be one optional implement to NAT. 333 If destination addresses and ports are different for outgoing 334 connections started by local clients, NAT MAY assign the same 335 external port as the source ports for the connections. The port 336 overlapping mechanism manages mappings between external packets and 337 internal packets by looking at and storing their 5-tuple (protocol, 338 source address, source port, destination address, destination port) . 339 This enables concurrent use of a single NAT external port for 340 multiple transport sessions, which enables NAT to work correctly in 341 IP address resource limited network. 343 Discussions: 345 [RFC4787] and [RFC5382] requires "endpoint-independent mapping" at 346 NAT, and port overlapping NAT cannot meet the requirement. This 347 mechanism can degrade the transparency of NAT in that its mapping 348 mechanism is endpoint-dependent and makes NAT traversal harder. 349 However, if a NAT adopts endpoint-independent mapping together with 350 endpoint-dependent filtering, then the actual behavior of the NAT 351 will be the same as port overlapping NAT. It should also be noted 352 that a lot of existing NAT devices(e.g., SEIL, FITELnet Series) 353 adopted this port overlapping mechanism. 355 A: Reference URL for SEIL -> www.seil.jp 357 B: Reference URL for FITELnet -> www.furukawa.co.jp/fitelnet 358 The netfilter, which is a popular packet filtering mechanism for 359 Linux, also adopts port overlapping behavior. 361 5. Address Pooling Paired (APP) 363 [RFC4787]: REQ-2 [RFC5382]:ND Address Pooling Paired behavior for NAT 364 is recommended in previous documents but behavior when a public IPv4 365 run out of ports is left undefined. This document clarifies that if 366 APP is enabled new sessions from a subscriber that already has a 367 mapping associated with a public IP that ran out of ports SHOULD be 368 dropped. The administrator MAY provide a knob that allows a NAT 369 device to starting using ports from another public IP when the one 370 that anchored the APP mapping ran out of ports. This is trade-off 371 between subscriber service continuity and APP strict enforcement. 372 (NE: It is sometimes referred as 'soft-APP') 374 6. EIF Security 376 [RFC4787]:REQ-8 and [RFC5382]:REQ-3 End-point independent filtering 377 could potentially result in security attacks from the public realm. 378 In order to handle this, when possible there MUST be strict filtering 379 checks in the inbound direction. A knob SHOULD be provided to limit 380 the number of inbound sessions and a knob SHOULD be provided to 381 enable or disable EIF on a per application basis. This is specially 382 important in the case of Mobile networks where such attacks can 383 consume radio resources and count against the user quota. 385 7. EIF Protocol Independence 387 [RFC4787]:REQ-8 and[RFC5382]: REQ-3 Current RFCs do not specify 388 whether EIF mappings are protocol independent. In other words, if an 389 outbound TCP SYN creates a mapping, it is left undefined whether 390 inbound UDP packets destined to that mapping should be forwarded. 391 This document specifies that EIF mappings SHOULD be protocol 392 independent in order allow inbound packets for protocols that 393 multiplex TCP and UDP over the same IP: port through the NAT and also 394 maintain compatibility with stateful NAT64 RFC6146 [RFC6146]. But 395 the administrator MAY provide a configuration knob to make it 396 protocol dependent. 398 8. EIF Mapping Refresh 400 [RFC4787]: REQ-6 [RFC5382]: ND The NAT mapping Refresh direction MAY 401 have a "NAT Inbound refresh behavior" of "True" but it does not 402 clarifies how this applies to EIF mappings. The issue in question is 403 whether inbound packets that match an EIF mapping but do not create a 404 new session due to a security policy should refresh the mapping 405 timer. This document clarifies that even when a NAT device has a 406 inbound refresh behavior of TRUE, such packets SHOULD NOT refresh the 407 mapping. Otherwise a simple attack of a packet every 2 minutes can 408 keep the mapping indefinitely. 410 8.1. Outbound Mapping Refresh and Error Packets 412 In the case of NAT outbound refresh behavior there are certain types 413 of packets that should not refresh the mapping even if their 414 direction is outbound. For example, if the mapping is kept alive by 415 ICMP Errors or TCP RST outbound packets sent as response to inbound 416 packets, these SHOULD NOT refresh the mapping. 418 9. EIM Protocol Independence 420 [RFC4787] [RFC5382]: REQ-1 Current RFCs do not specify whether EIM 421 are protocol independent. In other words, if a outbound TCP SYN 422 creates a mapping it is left undefined whether outbound UDP can reuse 423 such mapping and create session. On the other hand, Stateful NAT64 424 [RFC6146] clearly specifies three binding information bases (TCP, 425 UDP, ICMP). This document clarifies that EIM mappings SHOULD be 426 protocol dependent . A knob MAY be provided in order allow protocols 427 that multiplex TCP and UDP over the same source IP and port to use a 428 single mapping. 430 10. Port Parity 432 A NAT devices MAY disable port parity preservation for dynamic 433 mappings. Nevertheless, A NAT SHOULD support means to explicitly 434 request to preserve port parity (e.g., [I-D.pcp-port-set]). 436 11. Port Randomization 438 A NAT SHOULD follow the recommendations specified in Section 4 of 439 [RFC6056] especially: "A NAPT that does not implement port 440 preservation [RFC4787] [RFC5382] SHOULD obfuscate selection of the 441 ephemeral port of a packet when it is changed during translation of 442 that packet. A NAPT that does implement port preservation SHOULD 443 obfuscate the ephemeral port of a packet only if the port must be 444 changed as a result of the port being already in use for some other 445 session. A NAPT that performs parity preservation and that must 446 change the ephemeral port during translation of a packet SHOULD 447 obfuscate the ephemeral ports. The algorithms described in this 448 document could be easily adapted such that the parity is preserved 449 (i.e., force the lowest order bit of the resulting port number to 0 450 or 1 according to whether even or odd parity is desired)." 452 12. IP Identification (IP ID) 453 A NAT SHOULD handle the Identification field of translated IPv4 454 packets as specified in Section 9 of [I-D.ietf-intarea-ipv4-id- 455 update]. 457 13. ICMP Query Mappings Timeout 459 Section 3.1 of [RFC5508] says that ICMP Query Mappings are to be 460 maintained by NAT device. However, RFC doesn't discuss about the 461 Query Mapping timeout values. Section 3.2 of that RFC only discusses 462 about ICMP Query Session Timeouts. ICMP Query Mappings MAY be 463 deleted once the last the session using the mapping is deleted. 465 14. Hairpinning Support for ICMP Packets 467 [RFC5508]:REQ-7 This requirement specifies that NAT devices enforcing 468 Basic NAT MUST support traversal of hairpinned ICMP Query sessions. 469 This implicitly means that address mappings from external address to 470 internal address (similar to Endpoint Independent Filters) MUST be 471 maintained to allow inbound ICMP Query sessions. If an ICMP Query is 472 received on an external address, NAT device can then translate to an 473 internal IP. [RFC5508]:REQ-7 This requirement specifies that all NAT 474 devices (i.e., Basic NAT as well as NAPT devices) MUST support the 475 traversal of hairpinned ICMP Error messages. This too requires NAT 476 devices to maintain address mappings from external IP address to 477 internal IP address in addition to the ICMP Query Mappings described 478 in section 3.1 of that RFC. 480 15. IANA Considerations 482 TBD 484 16. Security Considerations 486 In the case of EIF mappings due to high risk of resource crunch, a 487 NAT device MAY provide a knob to limit the number of inbound sessions 488 spawned from a EIF mapping. 490 [TCP-Security] contains a detailed discussion of the security 491 implications of TCP Timestamps and of different timestamp generation 492 algorithms. 494 17. Acknowledgements 496 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan and 497 Senthil Sivamular for review and discussions 499 18. References 500 18.1. Normative References 502 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 503 793, September 1981. 505 [RFC1122] Braden, R., "Requirements for Internet Hosts - 506 Communication Layers", STD 3, RFC 1122, October 1989. 508 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 509 for High Performance", RFC 1323, May 1992. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 515 Translator (NAT) Terminology and Considerations", RFC 516 2663, August 1999. 518 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 519 in Session Description Protocol (SDP)", RFC 3605, October 520 2003. 522 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 523 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 524 RFC 4787, January 2007. 526 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 527 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 528 RFC 5382, October 2008. 530 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 531 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 532 April 2009. 534 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 535 Protocol Port Randomization", BCP 156, RFC 6056, January 536 2011. 538 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 539 NAT64: Network Address and Protocol Translation from IPv6 540 Clients to IPv4 Servers", RFC 6146, April 2011. 542 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 543 Timestamps", BCP 159, RFC 6191, April 2011. 545 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 546 and H. Ashida, "Common Requirements for Carrier-Grade NATs 547 (CGNs)", BCP 127, RFC 6888, April 2013. 549 18.2. Informative References 551 [FLOWRATE] 552 Zhang, Y., Breslau, L., Paxson, V., and S. Shenker, "On 553 the Characteristics and Origins of Internet Flow Rates", . 555 [I-D.ietf-pcp-port-set] 556 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 557 and S. Perreault, "Port Control Protocol (PCP) Extension 558 for Port Set Allocation", draft-ietf-pcp-port-set-01 (work 559 in progress), May 2013. 561 [I-D.naito-nat-resource-optimizing-extension] 562 Kengo, K. and A. Matsumoto, "NAT TIME_WAIT reduction", 563 draft-naito-nat-resource-optimizing-extension-02 (work in 564 progress), July 2012. 566 [TCPWILD] Qian, F., Subhabrata, S., Spatscheck, O., Morley Mao, Z., 567 and W. Willinger, "TCP Revisited: A Fresh Look at TCP in 568 the Wild", . 570 Authors' Addresses 572 Reinaldo Penno 573 Cisco Systems, Inc. 574 170 West Tasman Drive 575 San Jose, California 95134 576 USA 578 Email: repenno@cisco.com 580 Simon Perreault 581 Viagenie 582 2875 boul. Laurier, suite D2-630 583 Quebec, QC G1V 2M2 584 Canada 586 Email: simon.perreault@viagenie.ca 588 Sarat Kamiset 589 Insieme Networks 590 California 591 Mohamed Boucadair 592 France Telecom 593 Rennes 35000 594 France 596 Email: mohamed.boucadair@orange.com 598 Kengo Naito 599 NTT 600 Tokyo 601 Japan 603 Email: kengo@lab.ntt.co.jp