idnits 2.17.1 draft-ietf-behave-lsn-requirements-09.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 (August 9, 2012) is 4272 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: February 10, 2013 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 August 9, 2012 13 Common requirements for Carrier Grade NATs (CGNs) 14 draft-ietf-behave-lsn-requirements-09 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 February 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 5. Port Allocation Scheme . . . . . . . . . . . . . . . . . . . . 12 60 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 66 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 have 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], in which case the PCP 370 server MUST obey the following constraints on its behavior: 372 A. It MUST NOT permit the lifetime of a mapping to be 373 reduced beyond its current life or be set to zero 374 (deleted). 376 B. It MUST NOT permit a NAT mapping to be created with a 377 lifetime less than the lifetime used for implicit 378 mappings. 380 C. It MUST NOT support the THIRD_PARTY option except for 381 requests received from "trusted" sources where it is 382 impractical for those sources to be spoofed. 384 D. The MAP opcode MAY be permitted if the recommendation of 385 endpoint independent filtering behavior described in 386 REQ-7 is adopted; the map opcode MUST NOT be permitted in 387 other circumstances. These constraints MAY be relaxed if 388 a security mechanism consistent with PCP's Advanced 389 Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) is 390 used; this is expected to be rare for CGN deployments. 392 E. Mappings created by PCP MUST follow the same deallocation 393 behavior (REQ-8) as implicitly mapped traffic. 395 Justification: Allowing subscribers to manipulate the NAT state 396 table with PCP greatly increases the likelihood that applications 397 will function properly. 399 A study of PCP-less CGN impacts can be found in 400 [I-D.donley-nat444-impacts]. Another study considering the 401 effects of PCP on a peer-to-peer file sharing protocol can be 402 found in [I-D.boucadair-pcp-bittorrent]. 404 Items "A" to "D" are justified as follows: Most of the concern has 405 to do with one customer device interacting negatively with the 406 security of another; this is of particular concern when the 407 devices belong to different customers, but devices belonging to 408 the same customer are in scope for the PCP security analysis as 409 well. Reducing a mapping lifetime or deleting a mapping create 410 DoS opportunities and can create an opportunity for one device to 411 intercept another device's traffic. If a device spoofs creation 412 of a mapping with less than the default lifetime, then that can 413 create DoS or packet capture opportunities. The behavior of REQ-8 414 is critical to avoiding packet capture attacks. 416 REQ-10: CGN implementers SHOULD make their equipment manageable. 417 Standards-based management using standards such as 418 "Definitions of Managed Objects for NAT" [RFC4008] is 419 RECOMMENDED. 421 Justification: It is anticipated that CGNs will be primarily 422 deployed in ISP networks where the need for management is 423 critical. This requirement is at the SHOULD level to account for 424 the fact that some CGN operators may not need management 425 functionality. 427 Note also that there are efforts within the IETF toward creating a 428 MIB tailored for CGNs (e.g., [I-D.ietf-behave-nat-mib]). 430 REQ-11: When a CGN is unable to create a dynamic mapping due to 431 resource constraints or administrative restrictions (i.e., 432 quotas): 434 A. it MUST drop the original packet; 436 B. it SHOULD send an ICMP Destination Unreachable message 437 with code 1 (Host Unreachable) to the sender; 439 C. it SHOULD send a notification (e.g., SNMP trap) towards 440 a management system (if configured to do so); 442 D. and it MUST NOT delete existing mappings in order to 443 "make room" for the new one. (This only applies to 444 normal CGN behavior, not to manual operator 445 intervention.) 447 Justification: This is a slightly different form of REQ-8 from 448 [RFC5508]. Code 1 is preferred to code 13 because it is listed as 449 a "soft error" in [RFC1122], which is important because we don't 450 want TCP stacks to abort the connection attempt in this case. See 451 [RFC5461] for details on TCP's reaction to soft errors. 453 Sending ICMP errors and SNMP traps may be rate-limited for 454 security reasons, which is why requirements B and C are SHOULDs, 455 not a MUSTs. 457 Applications generally handle connection establishment failure 458 better than established connection failure. This is why dropping 459 the packet initiating the new connection is preferred over 460 deleting existing mappings. See also the rationale in [RFC5508] 461 section 6. 463 4. Logging 465 It may be necessary for CGN administrators to be able to identify a 466 subscriber based on external IPv4 address, port, and timestamp in 467 order to deal with abuse. When multiple subscribers share a single 468 external address, the source address and port that are visible at the 469 destination host have been translated from the ones originated by the 470 subscriber. 472 In order to be able to do this, the CGN would need to log the 473 following information for each mapping created (this list is for 474 informational purposes only and does not constitute a requirement): 476 o transport protocol 478 o subscriber identifier (e.g., internal source address or tunnel 479 endpoint identifier) 481 o external source address 483 o external source port 485 o timestamp 487 By "subscriber identifier" we mean information that uniquely 488 identifies a subscriber. For example, in a traditional NAT scenario, 489 the internal source address would be sufficient. In the case of DS- 490 Lite, many subscribers share the same internal address and the 491 subscriber identifier is the tunnel endpoint identifier (i.e., the 492 B4's IPv6 address). 494 A disadvantage of logging mappings is that CGNs under heavy usage may 495 produce large amounts of logs, which may require large storage 496 volume. 498 REQ-12: A CGN SHOULD NOT log destination addresses or ports unless 499 required to do so for administrative reasons. 501 Justification: Destination logging at the CGN creates privacy 502 issues. Furthermore, readers should be aware of logging 503 recommendations for Internet-facing servers [RFC6302]. With 504 compliant servers, the destination address and port do not need to 505 be logged by the CGN. This can help reduce the amount of logging. 507 This requirement is at the SHOULD level to account for the fact 508 that there may be other reasons for logging destination addresses 509 or ports. One such reason might be that the remote server is not 510 following [RFC6302]. 512 5. Port Allocation Scheme 514 A CGN's port allocation scheme is subject to three competing 515 requirements: 517 REQ-13: A CGN's port allocation scheme SHOULD maximize port 518 utilization. 520 Justification: External ports is one of the resources being shared 521 by a CGN. Efficient management of that resource directly impacts 522 the quality of a subscriber's Internet connection. 524 Some schemes are very efficient in their port utilization. In 525 that sense, they have good scaling properties (nothing is wasted). 526 Others will systematically waste ports. 528 REQ-14: A CGN's port allocation scheme SHOULD minimize log volume. 530 Justification: Huge log volumes can be problematic to CGN operators. 532 Some schemes create one log entry per mapping. Others allow 533 multiple mappings to generate a single log entry, which sometimes 534 can be expressed very compactly. With some schemes the logging 535 frequency can approach that of DHCP servers. 537 REQ-15: A CGN's port allocation scheme SHOULD make it hard for 538 attackers to guess port numbers. 540 Justification: Easily guessed port numbers put subscribers at risk 541 of the attacks described in [RFC6056]. 543 Some schemes provide very good security in that ports numbers are 544 not easily guessed. Others provide poor security to subscribers 546 A CGN implementation's choice of port allocation scheme optimizes to 547 satisfy one requirement at the expense of another. Therefore, these 548 are soft requirements (SHOULD as opposed to MUST). 550 6. Deployment Considerations 552 Several issues are encountered when CGNs are used [RFC6269]. There 553 is current work in the IETF toward alleviating some of these issues. 554 For example, see [I-D.ietf-intarea-nat-reveal-analysis]. 556 7. IANA Considerations 558 There are no IANA considerations. 560 8. Security Considerations 562 If a malicious subscriber can spoof another subscriber's CPE, it may 563 cause a DoS to that subscriber by creating mappings up to the allowed 564 limit. An ISP can prevent this with ingress filtering, as described 565 in [RFC2827]. 567 This document recommends Endpoint-Independent Filtering (EIF) as the 568 default filtering behavior for CGNs. EIF has security considerations 569 which are discussed in [RFC4787]. 571 NATs sometimes perform fragment reassembly. CGNs would do so at 572 presumably high data rates. Therefore, the reader should be familiar 573 with the potential security issues described in [RFC4963]. 575 9. Acknowledgements 577 Thanks for the input and review by Alexey Melnikov, Arifumi 578 Matsumoto, Barry Leiba, Benson Schliesser, Dai Kuwabara, Dan Wing, 579 Dave Thaler, David Harrington, Francis Dupont, Jean-Francois 580 Tremblay, Joe Touch, Lars Eggert, Kousuke Shishikura, Mohamed 581 Boucadair, Martin Stiemerling, Meng Wei, Nejc Skoberne, Pete Resnick, 582 Reinaldo Penno, Ron Bonica, Sam Hartman, Sean Turner, Senthil 583 Sivakumar, Stephen Farrell, Stewart Bryant, Takanori Mizuguchi, 584 Takeshi Tomochika, Tina Tsou, Tomohiro Fujisaki, Tomohiro Nishitani, 585 Tomoya Yoshida, Wes George, Wesley Eddy, and Yasuhiro Shirasaki. 587 10. References 589 10.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 595 C. Wang, "Definitions of Managed Objects for Network 596 Address Translators (NAT)", RFC 4008, March 2005. 598 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 599 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 600 RFC 4787, January 2007. 602 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 603 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 604 RFC 5382, October 2008. 606 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 607 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 608 April 2009. 610 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 611 Behavioral Requirements for the Datagram Congestion 612 Control Protocol", BCP 150, RFC 5597, September 2009. 614 [I-D.ietf-pcp-base] 615 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 616 Selkirk, "Port Control Protocol (PCP)", 617 draft-ietf-pcp-base-26 (work in progress), June 2012. 619 10.2. Informative Reference 621 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 622 RFC 793, September 1981. 624 [RFC1122] Braden, R., "Requirements for Internet Hosts - 625 Communication Layers", STD 3, RFC 1122, October 1989. 627 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 628 Translator (NAT) Terminology and Considerations", 629 RFC 2663, August 1999. 631 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 632 Defeating Denial of Service Attacks which employ IP Source 633 Address Spoofing", BCP 38, RFC 2827, May 2000. 635 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 636 Errors at High Data Rates", RFC 4963, July 2007. 638 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 639 February 2009. 641 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 642 Protocol Port Randomization", BCP 156, RFC 6056, 643 January 2011. 645 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 646 NAT64: Network Address and Protocol Translation from IPv6 647 Clients to IPv4 Servers", RFC 6146, April 2011. 649 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 650 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 651 June 2011. 653 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 654 Roberts, "Issues with IP Address Sharing", RFC 6269, 655 June 2011. 657 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 658 "Logging Recommendations for Internet-Facing Servers", 659 BCP 162, RFC 6302, June 2011. 661 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 662 Stack Lite Broadband Deployments Following IPv4 663 Exhaustion", RFC 6333, August 2011. 665 [I-D.ietf-behave-nat-mib] 666 Perreault, S., Tsou, T., and S. Sivakumar, "Additional 667 Managed Objects for Network Address Translators (NAT)", 668 draft-ietf-behave-nat-mib-01 (work in progress), 669 June 2012. 671 [I-D.ietf-intarea-nat-reveal-analysis] 672 Boucadair, M., Touch, J., Levis, P., and R. Penno, 673 "Analysis of Solution Candidates to Reveal a Host 674 Identifier (HOST_ID) in Shared Address Deployments", 675 draft-ietf-intarea-nat-reveal-analysis-02 (work in 676 progress), April 2012. 678 [I-D.donley-nat444-impacts] 679 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 680 Colorado, "Assessing the Impact of Carrier-Grade NAT on 681 Network Applications", draft-donley-nat444-impacts-04 682 (work in progress), May 2012. 684 [I-D.boucadair-pcp-bittorrent] 685 Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, 686 "Behavior of BitTorrent service in PCP-enabled networks 687 with Address Sharing", draft-boucadair-pcp-bittorrent-00 688 (work in progress), May 2012. 690 Authors' Addresses 692 Simon Perreault (editor) 693 Viagenie 694 246 Aberdeen 695 Quebec, QC G1R 2E1 696 Canada 698 Phone: +1 418 656 9254 699 Email: simon.perreault@viagenie.ca 700 URI: http://www.viagenie.ca 702 Ikuhei Yamagata 703 NTT Communications Corporation 704 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 705 Tokyo 108-8118 706 Japan 708 Phone: +81 50 3812 4704 709 Email: ikuhei@nttv6.jp 711 Shin Miyakawa 712 NTT Communications Corporation 713 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 714 Tokyo 108-8118 715 Japan 717 Phone: +81 50 3812 4695 718 Email: miyakawa@nttv6.jp 719 Akira Nakagawa 720 Japan Internet Exchange Co., Ltd. (JPIX) 721 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 722 Tokyo 100-0004 723 Japan 725 Phone: +81 90 9242 2717 726 Email: a-nakagawa@jpix.ad.jp 728 Hiroyuki Ashida 729 IS Consulting G.K. 730 12-17 Odenma-cho Nihonbashi Chuo-ku 731 Tokyo 103-0011 732 Japan 734 Email: assie@hir.jp