idnits 2.17.1 draft-ietf-behave-lsn-requirements-10.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 private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4787, updated by this document, for RFC5378 checks: 2005-01-13) -- 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 (December 6, 2012) is 4131 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) ** Obsolete normative reference: RFC 4008 (Obsoleted by RFC 7658) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-11) exists of draft-ietf-behave-nat-mib-01 == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-02 == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Perreault, Ed. 3 Internet-Draft Viagenie 4 Updates: 4787 (if approved) I. Yamagata 5 Intended status: BCP S. Miyakawa 6 Expires: June 9, 2013 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 December 6, 2012 13 Common requirements for Carrier Grade NATs (CGNs) 14 draft-ietf-behave-lsn-requirements-10 16 Abstract 18 This document defines common requirements for Carrier-Grade NAT 19 (CGN). It updates RFC 4787. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 9, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Requirements for CGNs . . . . . . . . . . . . . . . . . . . . 5 58 4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 5. Port Allocation Scheme . . . . . . . . . . . . . . . . . . . . 11 60 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 69 1. Introduction 71 With the shortage of IPv4 addresses, it is expected that more 72 Internet Service Providers (ISPs) may want to provide a service where 73 a public IPv4 address would be shared by many subscribers. Each 74 subscriber is assigned a private address, and a Network Address 75 Translator (NAT) [RFC2663] situated in the ISP's network translates 76 between private and public addresses. When a second IPv4 NAT is 77 located at the customer edge, this results in two layers of NAT. 79 This service can conceivably be offered alongside others, such as 80 IPv6 services or regular IPv4 service assigning public addresses to 81 subscribers. Some ISPs started offering such a service long before 82 there was a shortage of IPv4 addresses, showing that there are 83 driving forces other than the shortage of IPv4 addresses. One 84 approach to CGN deployment is described in [RFC6264]. 86 This document describes behavior that is required of those multi- 87 subscriber NATs for interoperability. It is not an IETF endorsement 88 of CGN or a real specification for CGN, but rather just a minimal set 89 of requirements that will increase the likelihood of applications 90 working across CGNs. 92 Because subscribers do not receive unique IPv4 addresses, Carrier 93 Grade NATs introduce substantial limitations in communications 94 between subscribers and with the rest of the Internet. In 95 particular, it is considerably more involved to establish proxy 96 functionality at the border between internal and external realms. 97 Some applications may require substantial enhancements, while some 98 others may not function at all in such an environment. Please see 99 "Issues with IP Address Sharing" [RFC6269] for details. 101 This document builds upon previous works describing requirements for 102 generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their 103 updates if any, still apply in this context. What follows are 104 additional requirements, to be satisfied on top of previous ones. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 Readers are expected to be familiar with "NAT Behavioral Requirements 113 for Unicast UDP" [RFC4787] and the terms defined there. The 114 following additional term is used in this document: 116 Carrier-Grade NAT (CGN): A NAT-based [RFC2663] logical function used 117 to share the same IPv4 address among several subscribers. A CGN 118 is not managed by the subscribers. 120 Note that the term "carrier-grade" has nothing to do with the 121 quality of the NAT; that is left to discretion of implementers. 122 Rather, it is to be understood as a topological qualifier: the 123 NAT is placed in an ISP's network and translates the traffic of 124 potentially many subscribers. Subscribers have limited or no 125 control over the CGN, whereas they typically have full control 126 over a NAT placed on their premises. 128 Note also that the CGN described in this document is IPv4-only. 129 IPv6 address translation is not considered. 131 However, the scenario in which the IPv4-only CGN logical 132 function is used may include IPv6 elements. For example, DS- 133 Lite [RFC6333] uses an IPv4-only CGN logical function in a 134 scenario making use of IPv6 encapsulation. Therefore, this 135 document would also apply to the CGN part of DS-Lite. 137 Figure 1 summarizes a common network topology in which a CGN 138 operates. 140 . 141 : 142 | Internet 143 ............... | ................... 144 | ISP network 145 External pool: | 146 192.0.2.1/26 | 147 ++------++ External realm 148 ........... | CGN |............... 149 ++------++ Internal realm 150 10.0.0.1 | | 151 | | 152 | | ISP network 153 ............. | .. | ................ 154 | | Customer premises 155 10.0.0.100 | | 10.0.0.101 156 ++------++ ++------++ 157 | CPE1 | | CPE2 | etc. 158 ++------++ ++------++ 160 (IP addresses are only for example purposes) 162 Figure 1: CGN network topology 164 Another possible topology is one for hotspots, where there is no 165 customer premise or customer-premises equipment (CPE), but where a 166 CGN serves a bunch of customers who don't trust each other and hence 167 fairness is an issue. One important difference with the previous 168 topology is the absence of a second layer of NAT. This, however, has 169 no impact on CGN requirements since they are driven by fairness and 170 robustness in the service provided to customers, which applies in 171 both cases. 173 3. Requirements for CGNs 175 What follows is a list of requirements for CGNs. They are in 176 addition to those found in other documents such as [RFC4787], 177 [RFC5382], and [RFC5508]. 179 REQ-1: If a CGN forwards packets containing a given transport 180 protocol, then it MUST fulfill that transport protocol's 181 behavioral requirements. Current applicable documents are as 182 follows: 184 A. "NAT Behavioral Requirements for Unicast UDP" [RFC4787] 186 B. "NAT Behavioral Requirements for TCP" [RFC5382] 188 C. "NAT Behavioral Requirements for ICMP" [RFC5508] 190 D. "NAT Behavioral Requirements for DCCP" [RFC5597] 192 Any future NAT behavioral requirements documents for IPv4 193 transport protocols will impose additional requirements for 194 CGNs on top of those stated here. 196 Justification: It is crucial for CGNs to maximize the set of 197 applications that can function properly across them. The IETF has 198 documented the best current practices for UDP, TCP, ICMP, and 199 DCCP. 201 REQ-2: A CGN MUST have a default "IP address pooling" behavior of 202 "Paired" (as defined in [RFC4787] section 4.1). A CGN MAY 203 provide a mechanism for administrators to change this 204 behavior on an application protocol basis. 206 * When multiple overlapping internal IP address ranges share 207 the same external IP address pool (e.g., DS-Lite 208 [RFC6333]), the "IP address pooling" behavior applies to 209 mappings between external IP addresses and internal 210 subscribers rather than between external and internal IP 211 addresses. 213 Justification: This stronger form of REQ-2 from [RFC4787] is 214 justified by the stronger need for not breaking applications that 215 depend on the external address remaining constant. 217 Note that this requirement applies regardless of the transport 218 protocol. In other words, a CGN must use the same external IP 219 address mapping for all sessions associated with the same internal 220 IP address, be they TCP, UDP, ICMP, something else, or a mix of 221 different protocols. 223 The justification for allowing other behaviors is to allow the 224 administrator to save external addresses and ports for application 225 protocols that are known to work fine with other behaviors in 226 practice. However, the default behavior MUST be "Paired". 228 REQ-3: The CGN function SHOULD NOT have any limitations on the size 229 nor the contiguity of the external address pool. In 230 particular, the CGN function MUST be configurable with 231 contiguous or non-contiguous external IPv4 address ranges. 233 Justification: Given the increasing rarity of IPv4 addresses, it is 234 becoming harder for an operator to provide large contiguous 235 address pools to CGNs. Additionally, operational flexibility may 236 require non-contiguous address pools for reasons such as 237 differentiated services, routing management, etc. 239 The reason for having SHOULD instead of MUST is to account for 240 limitations imposed by available resources as well as constraints 241 imposed for security reasons. 243 REQ-4: A CGN MUST support limiting the number of external ports (or, 244 equivalently, "identifiers" for ICMP) that are assigned per 245 subscriber. 247 A. Per-subscriber limits MUST be configurable by the CGN 248 administrator. 250 B. Per-subscriber limits MAY be configurable independently 251 per transport protocol. 253 C. Additionally, it is RECOMMENDED that the CGN include 254 administrator-adjustable thresholds to prevent a single 255 subscriber from consuming excessive CPU resources from 256 the CGN (e.g., rate limit the subscriber's creation of 257 new mappings). 259 Justification: A CGN can be considered a network resource that is 260 shared by competing subscribers. Limiting the number of external 261 ports assigned to each subscriber mitigates the DoS attack that a 262 subscriber could launch against other subscribers through the CGN 263 in order to get a larger share of the resource. It ensures 264 fairness among subscribers. Limiting the rate of allocation 265 mitigates a similar attack where the CPU is the resource being 266 targeted instead of port numbers, however this requirement is not 267 a MUST because it is very hard to explicitly call out all CPU- 268 consuming events. 270 REQ-5: A CGN SHOULD support limiting the amount of state memory 271 allocated per mapping and per subscriber. This may include 272 limiting the number of sessions, the number of filters, etc., 273 depending on the NAT implementation. 275 A. Limits SHOULD be configurable by the CGN administrator. 277 B. Additionally, it SHOULD be possible to limit the rate at 278 which memory-consuming state elements are allocated. 280 Justification: A NAT needs to keep track of TCP sessions associated 281 to each mapping. This state consumes resources for which, in the 282 case of a CGN, subscribers may compete. It is necessary to ensure 283 that each subscriber has access to a fair share of the CGN's 284 resources. Limiting the rate of allocation is intended to prevent 285 CPU resource exhaustion. Item "B" is at the SHOULD level to 286 account for the fact that means other than rate limiting may be 287 used to attain the same goal. 289 REQ-6: It MUST be possible to administratively turn off translation 290 for specific destination addresses and/or ports. 292 Justification: It is common for a CGN administrator to provide 293 access for subscribers to servers installed in the ISP's network 294 in the external realm. When such a server is able to reach the 295 internal realm via normal routing (which is entirely controlled by 296 the ISP), translation is unneeded. In that case, the CGN may 297 forward packets without modification, thus acting like a plain 298 router. This may represent an important efficiency gain. 300 Figure 2 illustrates this use-case. 302 X1:x1 X1':x1' X2:x2 303 +---+from X1:x1 +---+from X1:x1 +---+ 304 | C | to X2:x2 | | to X2:x2 | S | 305 | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e | 306 | i | | G | | r | 307 | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v | 308 | n |from X2:x2 | |from X2:x2 | e | 309 | t | to X1:x1 | | to X1:x1 | r | 310 +---+ +---+ +---+ 312 Figure 2: CGN pass-through 314 REQ-7: It is RECOMMENDED that a CGN use an "Endpoint-Independent 315 Filtering" behavior (as defined in [RFC4787] section 5). If 316 it is known that "Address-Dependent Filtering" does not cause 317 the application-layer protocol to break (how to determine 318 this is out of scope for this document), then it MAY be used 319 instead. 321 Justification: This is a stronger form of REQ-8 from [RFC4787]. 322 This is based on the observation that some games and peer-to-peer 323 applications require EIF for the NAT traversal to work. In the 324 context of a CGN it is important to minimize application breakage. 326 REQ-8: Once an external port is deallocated, it SHOULD NOT be 327 reallocated to a new mapping until at least 120 seconds have 328 passed, with the exceptions being: 330 A. If the CGN tracks TCP sessions (e.g., with a state 331 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 332 be reused immediately. 334 B. If external ports are statically assigned to internal 335 addresses (e.g., address X with port range 1000-1999 is 336 assigned to subscriber A, 2000-2999 to subscriber B, 337 etc.), and the assignment remains constant across state 338 loss, then ports MAY be reused immediately. 340 C. If the allocated external ports used address-dependent or 341 address-and-port-dependent filtering before state loss, 342 they MAY be reused immediately. 344 The length of time and the maximum number of ports in this 345 state MUST be configurable by the CGN administrator. 347 Justification: This is necessary in order to prevent collisions 348 between old and new mappings and sessions. It ensures that all 349 established sessions are broken instead of redirected to a 350 different peer. 352 The exceptions are for cases where reusing a port immediately does 353 not create a possibility that packets would be redirected to the 354 wrong peer. One can imagine other exceptions where mapping 355 collisions are avoided, thus justifying the SHOULD level for this 356 requirement. 358 The 120 seconds value corresponds to the Maximum Segment Lifetime 359 (MSL) from [RFC0793]. 361 Note that this requirement also applies to the case when a CGN 362 loses state (due to a crash, reboot, failover to a cold standby, 363 etc.). In that case, ports that were in use at the time of state 364 loss SHOULD NOT be reallocated until at least 120 seconds have 365 passed. 367 REQ-9: A CGN MUST implement a protocol giving subscribers explicit 368 control over NAT mappings. That protocol SHOULD be the Port 369 Control Protocol [I-D.ietf-pcp-base]. 371 Justification: Allowing subscribers to manipulate the NAT state 372 table with PCP greatly increases the likelihood that applications 373 will function properly. 375 A study of PCP-less CGN impacts can be found in 376 [I-D.donley-nat444-impacts]. Another study considering the 377 effects of PCP on a peer-to-peer file sharing protocol can be 378 found in [I-D.boucadair-pcp-bittorrent]. 380 REQ-10: CGN implementers SHOULD make their equipment manageable. 381 Standards-based management using standards such as 382 "Definitions of Managed Objects for NAT" [RFC4008] is 383 RECOMMENDED. 385 Justification: It is anticipated that CGNs will be primarily 386 deployed in ISP networks where the need for management is 387 critical. This requirement is at the SHOULD level to account for 388 the fact that some CGN operators may not need management 389 functionality. 391 Note also that there are efforts within the IETF toward creating a 392 MIB tailored for CGNs (e.g., [I-D.ietf-behave-nat-mib]). 394 REQ-11: When a CGN is unable to create a dynamic mapping due to 395 resource constraints or administrative restrictions (i.e., 396 quotas): 398 A. it MUST drop the original packet; 400 B. it SHOULD send an ICMP Destination Unreachable message 401 with code 1 (Host Unreachable) to the sender; 403 C. it SHOULD send a notification (e.g., SNMP trap) towards 404 a management system (if configured to do so); 406 D. and it MUST NOT delete existing mappings in order to 407 "make room" for the new one. (This only applies to 408 normal CGN behavior, not to manual operator 409 intervention.) 411 Justification: This is a slightly different form of REQ-8 from 412 [RFC5508]. Code 1 is preferred to code 13 because it is listed as 413 a "soft error" in [RFC1122], which is important because we don't 414 want TCP stacks to abort the connection attempt in this case. See 415 [RFC5461] for details on TCP's reaction to soft errors. 417 Sending ICMP errors and SNMP traps may be rate-limited for 418 security reasons, which is why requirements B and C are SHOULDs, 419 not a MUSTs. 421 Applications generally handle connection establishment failure 422 better than established connection failure. This is why dropping 423 the packet initiating the new connection is preferred over 424 deleting existing mappings. See also the rationale in [RFC5508] 425 section 6. 427 4. Logging 429 It may be necessary for CGN administrators to be able to identify a 430 subscriber based on external IPv4 address, port, and timestamp in 431 order to deal with abuse. When multiple subscribers share a single 432 external address, the source address and port that are visible at the 433 destination host have been translated from the ones originated by the 434 subscriber. 436 In order to be able to do this, the CGN would need to log the 437 following information for each mapping created (this list is for 438 informational purposes only and does not constitute a requirement): 440 o transport protocol 442 o subscriber identifier (e.g., internal source address or tunnel 443 endpoint identifier) 445 o external source address 447 o external source port 449 o timestamp 451 By "subscriber identifier" we mean information that uniquely 452 identifies a subscriber. For example, in a traditional NAT scenario, 453 the internal source address would be sufficient. In the case of DS- 454 Lite, many subscribers share the same internal address and the 455 subscriber identifier is the tunnel endpoint identifier (i.e., the 456 B4's IPv6 address). 458 A disadvantage of logging mappings is that CGNs under heavy usage may 459 produce large amounts of logs, which may require large storage 460 volume. 462 REQ-12: A CGN SHOULD NOT log destination addresses or ports unless 463 required to do so for administrative reasons. 465 Justification: Destination logging at the CGN creates privacy 466 issues. Furthermore, readers should be aware of logging 467 recommendations for Internet-facing servers [RFC6302]. With 468 compliant servers, the destination address and port do not need to 469 be logged by the CGN. This can help reduce the amount of logging. 471 This requirement is at the SHOULD level to account for the fact 472 that there may be other reasons for logging destination addresses 473 or ports. One such reason might be that the remote server is not 474 following [RFC6302]. 476 5. Port Allocation Scheme 478 A CGN's port allocation scheme is subject to three competing 479 requirements: 481 REQ-13: A CGN's port allocation scheme SHOULD maximize port 482 utilization. 484 Justification: External ports is one of the resources being shared 485 by a CGN. Efficient management of that resource directly impacts 486 the quality of a subscriber's Internet connection. 488 Some schemes are very efficient in their port utilization. In 489 that sense, they have good scaling properties (nothing is wasted). 490 Others will systematically waste ports. 492 REQ-14: A CGN's port allocation scheme SHOULD minimize log volume. 494 Justification: Huge log volumes can be problematic to CGN operators. 496 Some schemes create one log entry per mapping. Others allow 497 multiple mappings to generate a single log entry, which sometimes 498 can be expressed very compactly. With some schemes the logging 499 frequency can approach that of DHCP servers. 501 REQ-15: A CGN's port allocation scheme SHOULD make it hard for 502 attackers to guess port numbers. 504 Justification: Easily guessed port numbers put subscribers at risk 505 of the attacks described in [RFC6056]. 507 Some schemes provide very good security in that ports numbers are 508 not easily guessed. Others provide poor security to subscribers 510 A CGN implementation's choice of port allocation scheme optimizes to 511 satisfy one requirement at the expense of another. Therefore, these 512 are soft requirements (SHOULD as opposed to MUST). 514 6. Deployment Considerations 516 Several issues are encountered when CGNs are used [RFC6269]. There 517 is current work in the IETF toward alleviating some of these issues. 518 For example, see [I-D.ietf-intarea-nat-reveal-analysis]. 520 7. IANA Considerations 522 There are no IANA considerations. 524 8. Security Considerations 526 If a malicious subscriber can spoof another subscriber's CPE, it may 527 cause a DoS to that subscriber by creating mappings up to the allowed 528 limit. An ISP can prevent this with ingress filtering, as described 529 in [RFC2827]. 531 This document recommends Endpoint-Independent Filtering (EIF) as the 532 default filtering behavior for CGNs. EIF has security considerations 533 which are discussed in [RFC4787]. 535 NATs sometimes perform fragment reassembly. CGNs would do so at 536 presumably high data rates. Therefore, the reader should be familiar 537 with the potential security issues described in [RFC4963]. 539 9. Acknowledgements 541 Thanks for the input and review by Alexey Melnikov, Arifumi 542 Matsumoto, Barry Leiba, Benson Schliesser, Dai Kuwabara, Dan Wing, 543 Dave Thaler, David Harrington, Francis Dupont, Jean-Francois 544 Tremblay, Joe Touch, Lars Eggert, Kousuke Shishikura, Mohamed 545 Boucadair, Martin Stiemerling, Meng Wei, Nejc Skoberne, Pete Resnick, 546 Reinaldo Penno, Ron Bonica, Sam Hartman, Sean Turner, Senthil 547 Sivakumar, Stephen Farrell, Stewart Bryant, Takanori Mizuguchi, 548 Takeshi Tomochika, Tina Tsou, Tomohiro Fujisaki, Tomohiro Nishitani, 549 Tomoya Yoshida, Wes George, Wesley Eddy, and Yasuhiro Shirasaki. 551 10. References 553 10.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 559 C. Wang, "Definitions of Managed Objects for Network 560 Address Translators (NAT)", RFC 4008, March 2005. 562 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 563 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 564 RFC 4787, January 2007. 566 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 567 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 568 RFC 5382, October 2008. 570 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 571 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 572 April 2009. 574 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 575 Behavioral Requirements for the Datagram Congestion 576 Control Protocol", BCP 150, RFC 5597, September 2009. 578 [I-D.ietf-pcp-base] 579 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 580 Selkirk, "Port Control Protocol (PCP)", 581 draft-ietf-pcp-base-26 (work in progress), June 2012. 583 10.2. Informative Reference 585 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 586 RFC 793, September 1981. 588 [RFC1122] Braden, R., "Requirements for Internet Hosts - 589 Communication Layers", STD 3, RFC 1122, October 1989. 591 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 592 Translator (NAT) Terminology and Considerations", 593 RFC 2663, August 1999. 595 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 596 Defeating Denial of Service Attacks which employ IP Source 597 Address Spoofing", BCP 38, RFC 2827, May 2000. 599 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 600 Errors at High Data Rates", RFC 4963, July 2007. 602 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 603 February 2009. 605 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 606 Protocol Port Randomization", BCP 156, RFC 6056, 607 January 2011. 609 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 610 NAT64: Network Address and Protocol Translation from IPv6 611 Clients to IPv4 Servers", RFC 6146, April 2011. 613 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 614 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 615 June 2011. 617 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 618 Roberts, "Issues with IP Address Sharing", RFC 6269, 619 June 2011. 621 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 622 "Logging Recommendations for Internet-Facing Servers", 623 BCP 162, RFC 6302, June 2011. 625 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 626 Stack Lite Broadband Deployments Following IPv4 627 Exhaustion", RFC 6333, August 2011. 629 [I-D.ietf-behave-nat-mib] 630 Perreault, S., Tsou, T., and S. Sivakumar, "Additional 631 Managed Objects for Network Address Translators (NAT)", 632 draft-ietf-behave-nat-mib-01 (work in progress), 633 June 2012. 635 [I-D.ietf-intarea-nat-reveal-analysis] 636 Boucadair, M., Touch, J., Levis, P., and R. Penno, 637 "Analysis of Solution Candidates to Reveal a Host 638 Identifier (HOST_ID) in Shared Address Deployments", 639 draft-ietf-intarea-nat-reveal-analysis-02 (work in 640 progress), April 2012. 642 [I-D.donley-nat444-impacts] 643 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 644 Colorado, "Assessing the Impact of Carrier-Grade NAT on 645 Network Applications", draft-donley-nat444-impacts-04 646 (work in progress), May 2012. 648 [I-D.boucadair-pcp-bittorrent] 649 Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, 650 "Behavior of BitTorrent service in PCP-enabled networks 651 with Address Sharing", draft-boucadair-pcp-bittorrent-00 652 (work in progress), May 2012. 654 Authors' Addresses 656 Simon Perreault (editor) 657 Viagenie 658 246 Aberdeen 659 Quebec, QC G1R 2E1 660 Canada 662 Phone: +1 418 656 9254 663 Email: simon.perreault@viagenie.ca 664 URI: http://www.viagenie.ca 665 Ikuhei Yamagata 666 NTT Communications Corporation 667 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 668 Tokyo 108-8118 669 Japan 671 Phone: +81 50 3812 4704 672 Email: ikuhei@nttv6.jp 674 Shin Miyakawa 675 NTT Communications Corporation 676 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 677 Tokyo 108-8118 678 Japan 680 Phone: +81 50 3812 4695 681 Email: miyakawa@nttv6.jp 683 Akira Nakagawa 684 Japan Internet Exchange Co., Ltd. (JPIX) 685 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 686 Tokyo 100-0004 687 Japan 689 Phone: +81 90 9242 2717 690 Email: a-nakagawa@jpix.ad.jp 692 Hiroyuki Ashida 693 IS Consulting G.K. 694 12-17 Odenma-cho Nihonbashi Chuo-ku 695 Tokyo 103-0011 696 Japan 698 Email: assie@hir.jp