idnits 2.17.1 draft-ietf-behave-lsn-requirements-07.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 (June 13, 2012) is 4332 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-24 -- 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-00 == 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: December 15, 2012 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 June 13, 2012 13 Common requirements for Carrier Grade NATs (CGNs) 14 draft-ietf-behave-lsn-requirements-07 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 December 15, 2012. 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. Bulk Port Allocation . . . . . . . . . . . . . . . . . . . . . 11 60 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 67 Appendix A. Change Log (to be removed by RFC Editor prior to 68 publication) . . . . . . . . . . . . . . . . . . . . 15 69 A.1. Changed in -07 . . . . . . . . . . . . . . . . . . . . . 15 70 A.2. Changed in -06 . . . . . . . . . . . . . . . . . . . . . 16 71 A.3. Changed in -05 . . . . . . . . . . . . . . . . . . . . . 17 72 A.4. Changed in -04 . . . . . . . . . . . . . . . . . . . . . 17 73 A.5. Changed in -03 . . . . . . . . . . . . . . . . . . . . . 17 74 A.6. Changed in -02 . . . . . . . . . . . . . . . . . . . . . 18 75 A.7. Changed in -01 . . . . . . . . . . . . . . . . . . . . . 19 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 With the shortage of IPv4 addresses, it is expected that more 81 Internet Service Providers (ISPs) may want to provide a service where 82 a public IPv4 address would be shared by many subscribers. Each 83 subscriber is assigned a private address, and a Network Address 84 Translator (NAT) [RFC2663] situated in the ISP's network translates 85 between private and public addresses. When a second IPv4 NAT is 86 located at the customer edge, this results in two layers of NAT. 88 This service can conceivably be offered alongside others, such as 89 IPv6 services or regular IPv4 service assigning public addresses to 90 subscribers. Some ISPs started offering such a service long before 91 there was a shortage of IPv4 addresses, showing that there are 92 driving forces other than the shortage of IPv4 addresses. One 93 approach to CGN deployment is described in [RFC6264]. 95 This document describes behavior that is required of those multi- 96 subscriber NATs for interoperability. It is not an IETF endorsement 97 of CGN or a real specification for CGN, but rather just a minimal set 98 of requirements that will increase the likelihood of applications 99 working across CGNs. 101 Because subscribers do not receive unique IPv4 addresses, Carrier 102 Grade NATs introduce substantial limitations in communications 103 between subscribers and with the rest of the Internet. In 104 particular, it is considerably more involved to establish proxy 105 functionality at the border between internal and external realms. 106 Some applications may require substantial enhancements, while some 107 others may not function at all in such an environment. Please see 108 "Issues with IP Address Sharing" [RFC6269] for details. 110 Note that the CGN mechanism described in this document only applies 111 to IPv4. Any IPv6 address translation is out of scope. 113 This document builds upon previous works describing requirements for 114 generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their 115 updates if any, still apply in this context. What follows are 116 additional requirements, to be satisfied on top of previous ones. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 Readers are expected to be familiar with "NAT Behavioral Requirements 125 for Unicast UDP" [RFC4787] and the terms defined there. The 126 following additional term is used in this document: 128 Carrier-Grade NAT (CGN): A NAT-based [RFC2663] functional element 129 operated by an administrative entity (e.g., operator) to share the 130 same IPv4 address among several subscribers. A CGN is managed by 131 the administrative entity, not the subscribers. 133 Note that the term "carrier-grade" has nothing to do with the 134 quality of the NAT; that is left to discretion of implementers. 135 Rather, it is to be understood as a topological qualifier: the 136 NAT is placed in an ISP's network and translates the traffic of 137 potentially many subscribers. Subscribers have limited or no 138 control over the CGN, whereas they typically have full control 139 over a NAT placed on their premises. 141 Note also that the CGN described in this document is IPv4-only. 142 IPv6 address translation is not considered. 144 Figure 1 summarizes a common network topology in which a CGN 145 operates. 147 . 148 : 149 | Internet 150 ............... | ................... 151 | ISP network 152 External pool: | 153 192.0.2.1/26 | 154 ++------++ External realm 155 ........... | CGN |............... 156 ++------++ Internal realm 157 10.0.0.1 | | 158 | | 159 | | ISP network 160 ............. | .. | ................ 161 | | Customer premises 162 10.0.0.100 | | 10.0.0.101 163 ++------++ ++------++ 164 | CPE1 | | CPE2 | etc. 165 ++------++ ++------++ 167 (IP addresses are only for example purposes) 169 Figure 1: CGN network topology 171 Another possible topology is one for hotspots, where there is no 172 customer premise or customer-premises equipment (CPE), but where a 173 CGN serves a bunch of customers who don't trust each other and hence 174 fairness is an issue. One important difference with the previous 175 topology is the absence of a second layer of NAT. This, however, has 176 no impact on CGN requirements since they are driven by fairness and 177 robustness in the service provided to customers, which applies in 178 both cases. 180 3. Requirements for CGNs 182 What follows is a list of requirements for CGNs. They are in 183 addition to those found in other documents such as [RFC4787], 184 [RFC5382], and [RFC5508]. 186 REQ-1: If a CGN forwards packets containing a given transport 187 protocol, then it MUST fulfill that transport protocol's 188 behavioral requirements. Current applicable documents are as 189 follows: 191 A. "NAT Behavioral Requirements for Unicast UDP" [RFC4787] 193 B. "NAT Behavioral Requirements for TCP" [RFC5382] 195 C. "NAT Behavioral Requirements for ICMP" [RFC5508] 197 D. "NAT Behavioral Requirements for DCCP" [RFC5597] 199 If NAT behavioral requirements documents are created for 200 additional protocols, then these new documents MUST update 201 this list by adding themselves to it. 203 Justification: It is crucial for CGNs to maximize the set of 204 applications that can function properly across them. The IETF has 205 documented the best current practices for UDP, TCP, ICMP, and 206 DCCP. 208 REQ-2: A CGN MUST have a default "IP address pooling" behavior of 209 "Paired" (as defined in [RFC4787] section 4.1). A CGN MAY 210 provide a mechanism for administrators to change this 211 behavior on an application protocol basis. 213 * When multiple overlapping internal IP address ranges share 214 the same external IP address pool (e.g., DS-Lite 215 [RFC6333]), the "IP address pooling" behavior applies to 216 mappings between external IP addresses and internal 217 subscribers rather than between external and internal IP 218 addresses. 220 Justification: This stronger form of REQ-2 from [RFC4787] is 221 justified by the stronger need for not breaking applications that 222 depend on the external address remaining constant. 224 Note that this requirement applies regardless of the transport 225 protocol. In other words, a CGN must use the same external IP 226 address mapping for all sessions associated with the same internal 227 IP address, be they TCP, UDP, ICMP, something else, or a mix of 228 different protocols. 230 The justification for allowing other behaviors is to allow the 231 administrator to save external addresses and ports for application 232 protocols that are known to work fine with other behaviors in 233 practice. However, the default behavior MUST be "Paired". 235 REQ-3: The CGN function SHOULD NOT have any limitations on the size 236 nor the contiguity of the external address pool. In 237 particular, the CGN function MUST be configurable with 238 contiguous or non-contiguous external IPv4 address ranges. 240 Justification: Given the increasing rarity of IPv4 addresses, it is 241 becoming harder for an operator to provide large contiguous 242 address pools to CGNs. Additionally, operational flexibility may 243 require non-contiguous address pools for reasons such as 244 differentiated services, routing management, etc. 246 The reason for having SHOULD instead of MUST is to account for 247 limitations imposed by available resources as well as constraints 248 imposed for security reasons. 250 REQ-4: A CGN MUST support limiting the number of external ports (or, 251 equivalently, "identifiers" for ICMP) that are assigned per 252 subscriber. 254 A. Limits MUST be configurable by the CGN administrator. 256 B. Limits MAY be configurable independently per transport 257 protocol. 259 C. Additionally, it is RECOMMENDED that the CGN include 260 administrator-adjustable thresholds to prevent a single 261 subscriber from consuming excessive CPU resources from 262 the CGN (e.g., rate limit the subscriber's creation of 263 new mappings). 265 Justification: A CGN can be considered a network resource that is 266 shared by competing subscribers. Limiting the number of external 267 ports assigned to each subscriber mitigates the DoS attack that a 268 subscriber could launch against other subscribers through the CGN 269 in order to get a larger share of the resource. It ensures 270 fairness among subscribers. Limiting the rate of allocation 271 mitigates a similar attack where the CPU is the resource being 272 targeted instead of port numbers, however this requirement is not 273 a MUST because it is very hard to explicitly call out all CPU- 274 consuming events. 276 REQ-5: A CGN SHOULD support limiting the amount of state memory 277 allocated per mapping and per subscriber. This may include 278 limiting the number of sessions, the number of filters, etc., 279 depending on the NAT implementation. 281 A. Limits SHOULD be configurable by the CGN administrator. 283 B. Additionally, it SHOULD be possible to limit the rate at 284 which memory-consuming state elements are allocated. 286 Justification: A NAT needs to keep track of TCP sessions associated 287 to each mapping. This state consumes resources for which, in the 288 case of a CGN, subscribers may compete. It is necessary to ensure 289 that each subscriber has access to a fair share of the CGN's 290 resources. Limiting TCP sessions per subscriber and per time unit 291 is an effective mitigation against inter-subscriber DoS attacks. 292 Limiting the rate of allocation is intended to prevent against CPU 293 resource exhaustion. It is at the SHOULD level to account for the 294 fact that means other than rate limiting may be used to attain the 295 same goal. 297 REQ-6: It MUST be possible to administratively turn off translation 298 for specific destination addresses and/or ports. 300 Justification: It is common for a CGN administrator to provide 301 access for subscribers to servers installed in the ISP's network, 302 in the external realm. When such a server is able to reach the 303 internal realm via normal routing (which is entirely controlled by 304 the ISP), translation is unneeded. In that case, the CGN may 305 forward packets without modification, thus acting like a plain 306 router. This may represent an important efficiency gain. 308 Figure 2 illustrates this use-case. 310 X1:x1 X1':x1' X2:x2 311 +---+from X1:x1 +---+from X1:x1 +---+ 312 | C | to X2:x2 | | to X2:x2 | S | 313 | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e | 314 | i | | G | | r | 315 | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v | 316 | n |from X2:x2 | |from X2:x2 | e | 317 | t | to X1:x1 | | to X1:x1 | r | 318 +---+ +---+ +---+ 320 Figure 2: CGN pass-through 322 REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent 323 Filtering" behavior (as defined in [RFC4787] section 5). If 324 it is known that "Address-Independent Filtering" does not 325 cause the application-layer protocol to break (how to 326 determine this is out of scope for this document), then it 327 MAY be used instead. 329 Justification: This is a stronger form of REQ-8 from [RFC4787]. 330 This is based on the observation that some games and peer-to-peer 331 applications require EIF for the NAT traversal to work. In the 332 context of a CGN it is important to minimize application breakage. 334 REQ-8: Once an external port is deallocated, it SHOULD NOT be 335 reallocated to a new mapping until at least 120 seconds have 336 passed, with the exceptions being: 338 A. If the CGN tracks TCP sessions (e.g., with a state 339 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 340 be reused immediately. 342 B. If external ports are statically assigned to internal 343 addresses (e.g., address X with port range 1000-1999 is 344 assigned to subscriber A, 2000-2999 to subscriber B, 345 etc.), and the assignment remains constant across state 346 loss, then ports MAY be reused immediately. 348 C. If the allocated external ports used address-dependent or 349 address-and-port-dependent filtering before state loss, 350 they MAY be reused immediately. 352 The length of time and the maximum number of ports in this 353 state MUST be configurable by the CGN administrator. 355 Justification: This is necessary in order to prevent collisions 356 between old and new mappings and sessions. It ensures that all 357 established sessions are broken instead of redirected to a 358 different peer. 360 The exceptions are for cases where reusing a port immediately does 361 not create a possibility that packets would be redirected to the 362 wrong peer. One can imagine other exceptions where mapping 363 collisions are avoided, thus justifying the SHOULD level for this 364 requirement. 366 The 120 seconds value corresponds to the Maximum Segment Lifetime 367 (MSL) from [RFC0793]. 369 Note that this requirement also applies to the case when a CGN 370 loses state (due to a crash, reboot, failover to a cold standby, 371 etc.). In that case, ports that were in use at the time of state 372 loss SHOULD NOT be reallocated until at least 120 seconds have 373 passed. 375 REQ-9: A CGN MUST include a Port Control Protocol server 376 [I-D.ietf-pcp-base]. 378 Justification: Allowing subscribers to manipulate the NAT state 379 table with PCP greatly increases the likelihood that applications 380 will function properly. 382 A study of PCP-less CGN impacts can be found in 383 [I-D.donley-nat444-impacts]. Another study considering the 384 effects of PCP on a peer-to-peer file sharing protocol can be 385 found in [I-D.boucadair-pcp-bittorrent]. 387 REQ-10: CGN implementrers SHOULD make their equipment manageable. 388 Standards-based management using standards such as 389 "Definitions of Managed Objects for NAT" [RFC4008] is 390 RECOMMENDED. 392 Justification: It is anticipated that CGNs will be primarily 393 deployed in ISP networks where the need for management is 394 critical. This requirement is at the SHOULD level to acocunt for 395 the fact that some CGN operators may not need management 396 functionality. 398 Note also that there are efforts within the IETF toward creating a 399 MIB tailored for CGNs (e.g., [I-D.ietf-behave-nat-mib]). 401 REQ-11: When a CGN is unable to create a mapping due to resource 402 constraints or administrative restrictions (i.e., quotas): 404 A. it MUST drop the original packet; 406 B. it SHOULD send an ICMP Destination Unreachable message 407 with code 1 (Host Unreachable) to the sender; 409 C. it SHOULD send a notification (e.g., SNMP trap) towards 410 a management system (if configured to do so); 412 D. and it MUST NOT delete existing mappings in order to 413 "make room" for the new one. (This only applies to 414 normal CGN behavior, not to manual operator 415 intervention.) 417 Justification: This is a slightly different form of REQ-8 from 418 [RFC5508]. Code 1 is preferred to code 13 because it is listed as 419 a "soft error" in [RFC1122], which is important because we don't 420 want TCP stacks to abort the connection attempt in this case. See 421 [RFC5461] for details on TCP's reaction to soft errors. 423 Sending ICMP errors and SNMP traps may be rate-limited for 424 security reasons, which is why requirements B and C are SHOULDs, 425 not a MUSTs. 427 Applications generally handle connection establishment failure 428 better than established connection failure. This is why dropping 429 the packet initiating the new connection is preferred over 430 deleting existing mappings. See also the rationale in [RFC5508] 431 section 6. 433 4. Logging 435 It may be necessary for CGN administrators to be able to identify a 436 subscriber based on external IPv4 address, port, and timestamp in 437 order to deal with abuse. When multiple subscribers share a single 438 external address, the source address and port that are visible at the 439 destination host have been translated from the ones originated by the 440 subscriber. 442 In order to be able to do this, the CGN would need to log the 443 following information for each mapping created: 445 o subscriber identifier (e.g., internal source address or tunnel 446 endpoint identifier) 448 o external source address 450 o external source port 452 o timestamp 454 By "subscriber identifier" we mean information that uniquely 455 identifies a subscriber. For example, in a traditional NAT scenario, 456 the internal source address would be sufficient. In the case of DS- 457 Lite, many subscribers share the same internal address and the 458 subscriber identifier is the tunnel endpoint identifier (i.e., the 459 B4's IPv6 address). 461 A disadvantage of logging mappings is that CGNs under heavy usage may 462 produce large amounts of logs, which may require large storage 463 volume. 465 REQ-12: A CGN SHOULD NOT log destination addresses or ports. 467 Justification: Destination logging at the CGN creates privacy 468 issues. Furthermore, readers should be aware of logging 469 recommendations for Internet-facing servers [RFC6302]. With 470 compliant servers, the destination address and port do not need to 471 be logged by the CGN. This can help reduce the amount of logging. 473 This requirement is at the SHOULD level to account for the fact 474 that there may be other reasons for logging destination addresses 475 or ports. 477 5. Bulk Port Allocation 479 So far we have assumed that a CGN allocates one external port for 480 every outgoing connection. In this section, the impacts of 481 allocating multiple external ports at a time are discussed. 483 There is a range of things a CGN can do: 485 Traditional: For every outgoing connection, allocate one external 486 port. 488 Scattered port set: For an outgoing connection, create a set of 489 several non-consecutive external ports. Subsequent outgoing 490 connections will use ports from the set. When the set is 491 exhausted, a new connection causes a new set to be created. A set 492 is smaller or equal to the user's maximum port limit. 494 Consecutive port set: Same as the scattered port set, but the ports 495 allocated to a set are consecutive. 497 Note that this list is not exhaustive. There is a continuum of 498 behavior that a CGN may choose to implement. For example, a CGN 499 could use scattered port sets of consecutive port sets. 501 The impacts of bulk port allocation are as follows. 503 Port Utilization: The mechanisms at the top of the list are very 504 efficient in their port utilization. In that sense, they have 505 good scaling properties (nothing is wasted). The mechanisms at 506 the bottom of the list will waste ports. The number of wasted 507 ports is proportional to size of the "bin". 509 Logging: Traditional allocation creates a lot of log entries as 510 compared to allocation by port sets which creates much fewer 511 entries. Scattered and consecutive port sets generate the same 512 number of log entries. In the case of consecutive port sets, 513 entries can be expressed very compactly by indicating a range 514 (e.g., "12000-12009"). Some scattered port set allocation schemes 515 can also generate small log entries containing the parameters and 516 algorithm used for the port set generation (see, e.g., [RFC6431]). 518 With large set sizes, the logging frequency for scattered and 519 consecutive port sets can approach that of DHCP servers. 521 Security: Traditional and scattered port sets provide very good 522 security in that ports numbers are not easily guessed. Easily 523 guessed port numbers put subscribers at risk of the attacks 524 described in [RFC6056]. Consecutive port sets provides poor 525 security to subscribers, especially if the set size is small. 527 6. Deployment Considerations 529 Several issues are encountered when CGNs are used [RFC6269]. There 530 is current work in the IETF toward alleviating some of these issues. 531 For example, see [I-D.ietf-intarea-nat-reveal-analysis]. 533 7. IANA Considerations 535 There are no IANA considerations. 537 8. Security Considerations 539 If a malicious subscriber can spoof another subscriber's CPE, it may 540 cause a DoS to that subscriber by creating mappings up to the allowed 541 limit. An ISP can prevent this with ingress filtering, as described 542 in [RFC2827]. 544 This document recommends Endpoint-Independent Filtering (EIF) as the 545 default filtering behavior for CGNs. EIF has security considerations 546 which are discussed in [RFC4787]. 548 NATs sometimes perform fragment reassembly. CGNs would do so at 549 presumably high data rates. Therefore, the reader should be familiar 550 with the potential security issues described in [RFC4963]. 552 9. Acknowledgements 554 Thanks for the input and review by Arifumi Matsumoto, Benson 555 Schliesser, Dai Kuwabara, Dan Wing, Dave Thaler, David Harrington, 556 Francis Dupont, Jean-Francois Tremblay, Joe Touch, Lars Eggert, 557 Kousuke Shishikura, Mohamed Boucadair, Nejc Skoberne, Reinaldo Penno, 558 Senthil Sivakumar, Takanori Mizuguchi, Takeshi Tomochika, Tina Tsou, 559 Tomohiro Fujisaki, Tomohiro Nishitani, Tomoya Yoshida, Wesley Eddy, 560 and Yasuhiro Shirasaki. Dan Wing also contributed much of section 5. 562 10. References 564 10.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, March 1997. 569 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 570 C. Wang, "Definitions of Managed Objects for Network 571 Address Translators (NAT)", RFC 4008, March 2005. 573 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 574 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 575 RFC 4787, January 2007. 577 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 578 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 579 RFC 5382, October 2008. 581 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 582 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 583 April 2009. 585 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 586 Behavioral Requirements for the Datagram Congestion 587 Control Protocol", BCP 150, RFC 5597, September 2009. 589 [I-D.ietf-pcp-base] 590 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 591 Selkirk, "Port Control Protocol (PCP)", 592 draft-ietf-pcp-base-24 (work in progress), March 2012. 594 10.2. Informative Reference 596 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 597 RFC 793, September 1981. 599 [RFC1122] Braden, R., "Requirements for Internet Hosts - 600 Communication Layers", STD 3, RFC 1122, October 1989. 602 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 603 Translator (NAT) Terminology and Considerations", 604 RFC 2663, August 1999. 606 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 607 Defeating Denial of Service Attacks which employ IP Source 608 Address Spoofing", BCP 38, RFC 2827, May 2000. 610 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 611 Errors at High Data Rates", RFC 4963, July 2007. 613 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 614 February 2009. 616 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 617 Protocol Port Randomization", BCP 156, RFC 6056, 618 January 2011. 620 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 621 NAT64: Network Address and Protocol Translation from IPv6 622 Clients to IPv4 Servers", RFC 6146, April 2011. 624 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 625 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 626 June 2011. 628 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 629 Roberts, "Issues with IP Address Sharing", RFC 6269, 630 June 2011. 632 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 633 "Logging Recommendations for Internet-Facing Servers", 634 BCP 162, RFC 6302, June 2011. 636 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 637 Stack Lite Broadband Deployments Following IPv4 638 Exhaustion", RFC 6333, August 2011. 640 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 641 T. Tsou, "Huawei Port Range Configuration Options for PPP 642 IP Control Protocol (IPCP)", RFC 6431, November 2011. 644 [I-D.ietf-behave-nat-mib] 645 Perreault, S., Tsou, T., and S. Sivakumar, "Additional 646 Definitions of Managed Objects for Network Address 647 Translators (NAT)", draft-ietf-behave-nat-mib-00 (work in 648 progress), April 2012. 650 [I-D.ietf-intarea-nat-reveal-analysis] 651 Boucadair, M., Touch, J., Levis, P., and R. Penno, 652 "Analysis of Solution Candidates to Reveal a Host 653 Identifier (HOST_ID) in Shared Address Deployments", 654 draft-ietf-intarea-nat-reveal-analysis-02 (work in 655 progress), April 2012. 657 [I-D.donley-nat444-impacts] 658 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 659 Colorado, "Assessing the Impact of Carrier-Grade NAT on 660 Network Applications", draft-donley-nat444-impacts-04 661 (work in progress), May 2012. 663 [I-D.boucadair-pcp-bittorrent] 664 Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, 665 "Behavior of BitTorrent service in PCP-enabled networks 666 with Address Sharing", draft-boucadair-pcp-bittorrent-00 667 (work in progress), May 2012. 669 Appendix A. Change Log (to be removed by RFC Editor prior to 670 publication) 672 A.1. Changed in -07 674 o Fixed sub-requirement numbering in REQ-1. 676 o Reference update. 678 o Changed REQ-2 back to MUST (from SHOULD). 680 o Added reference to RFC6264 (incremental CGN). 682 o Be more clear that this is not an endorsement of CGN. 684 o Make it clear that this draft is only about IPv4. 686 o Added justification for a bunch of SHOULDs and turned the 687 remaining ones into MUSTs. 689 A.2. Changed in -06 691 o Expanded some acronyms. 693 o Added example IP addresses to ASCII art. 695 o Reword transport protocol section. 697 o Stronger words of caution about CGNs. 699 o Refer to RFC for DCCP NAT behaviour. 701 o Note in headers and abstract that this updates RFC 4787. 703 o Remove sentence "This is not to be considered a solution to the 704 shortage of IPv4 addresses." 706 o Remove text having marketing scent. 708 o Change some "MUST ... unless" requirements to "SHOULD ... unless". 710 o Merge REQ-8 and REQ-9. 712 o PCP is now a MUST. 714 o NAT-MIB is now an example rather than specificially required. 716 o When a quota is hit, send ICMP DU code 1 instead of code 3. 718 o Remove mention of "lawful intercept". 720 o Remove discussion on destination logging from section on bulk port 721 allocation. 723 o Remove discussion on address sharing ratio. 725 A.3. Changed in -05 727 o Removed DSCP requirement since it applies to non-CG NATs as well. 729 o Removed instances of "NAT444". 731 o Filtering has no effect on the requirement for a hold down pool. 732 Removed REQ-8-B. 734 o Statically assigned port ranges do not need to go in the hold down 735 pool. Added a new REQ-8-B. 737 o Fixed various nits. More precise text in some places. 739 A.4. Changed in -04 741 o Fixed nits, spelling, updated references. 743 o CGNs SHOULD NOT log destinations. 745 o Allow address-dependent filtering when it does not cause the 746 application protocol to break. 748 o Refer to RFC4787 security considerations on EIF. 750 o Clarify REQ-12 point D (it does not apply to operator 751 intervention). 753 o Changed "CGNs SHOULD limit ..." to "SHOULD support limiting" to 754 make it clear that the operator is in control. 756 o Added reference to RFC 4963. 758 o Added requirement for non-contiguous external address pools. 760 A.5. Changed in -03 762 o Added exceptions for which it is not necessary to wait 120 seconds 763 before reusing a port. 765 o Renamed "random port set" to "scattered port set", which is more 766 accurate. 768 o Log "subscriber identifier" instead of internal address+port to 769 allow for overlapping internal address ranges (DS-Lite). 771 o Adjusted logging text and added reference to I-D.boucadair-pppext- 772 portrange-option. 774 o Adjusted destination logging text for bulk port allocation 775 schemes. 777 o Removed requirement for I-D.ietf-intarea-ipv4-id-update. 779 o Made PCP support a SHOULD-level requirement. 781 o Lowered the level of requirement for not dropping existing 782 mappings in order to "make room" to SHOULD level, and added 783 rationale. 785 A.6. Changed in -02 787 o CGNs MUST support at least TCP, UDP, and ICMP. 789 o Add requirement from I-D.ietf-intarea-ipv4-id-update. 791 o Add informative reference to [RFC6269]. 793 o Add requirement (SHOULD level) for a port forwarding protocol. 795 o Allow any pooling behavior on a per-application protocol basis. 797 o Adjust wording for external port allocation rate limiting. 799 o Add requirement for RFC4008 support (SHOULD level). 801 o Adjust wording for swapping address pools when rebooting. 803 o Add DSCP requirement (stolen from draft-jennings-behave-nat6). 805 o Add informative reference to 806 draft-boucadair-intarea-nat-reveal-analysis. 808 o Add requirement for hold-down pool. 810 o Change definition of CGN. 812 o Avoid usage of "device" loaded word throughout the document. 814 o Add requirement about resource exhaustion. 816 o Change title. 818 o Describe additional CGN topology where there is no NAT444. 820 o Better justification for "Paired" pool behavior. 822 o Make it clear that rate limiting allocation is for preserving CPU 823 resources 825 o Generalize the requirement for limiting the number of TCP sessions 826 per mapping so that it applies to all memory-consuming state 827 elements. 829 o Change CPE to subscriber where it applies throughout the text. 831 o Better terminology for bulk port allocation mechanisms. 833 o Explain how external address pairing works with DS-Lite. 835 A.7. Changed in -01 837 o Terminology: LSN is now CGN. 839 o Imported all requirements from RFCs 4787, 5382, and 5508. This 840 allowed us to eliminate some duplication. 842 o Added references to 843 draft-ietf-intarea-server-logging-recommendations and 844 draft-ford-shared-addressing-issues. 846 o Incorporated a requirement from 847 draft-xu-behave-stateful-nat-standby-06. 849 Authors' Addresses 851 Simon Perreault (editor) 852 Viagenie 853 246 Aberdeen 854 Quebec, QC G1R 2E1 855 Canada 857 Phone: +1 418 656 9254 858 Email: simon.perreault@viagenie.ca 859 URI: http://www.viagenie.ca 860 Ikuhei Yamagata 861 NTT Communications Corporation 862 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 863 Tokyo 108-8118 864 Japan 866 Phone: +81 50 3812 4704 867 Email: ikuhei@nttv6.jp 869 Shin Miyakawa 870 NTT Communications Corporation 871 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 872 Tokyo 108-8118 873 Japan 875 Phone: +81 50 3812 4695 876 Email: miyakawa@nttv6.jp 878 Akira Nakagawa 879 Japan Internet Exchange Co., Ltd. (JPIX) 880 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 881 Tokyo 100-0004 882 Japan 884 Phone: +81 90 9242 2717 885 Email: a-nakagawa@jpix.ad.jp 887 Hiroyuki Ashida 888 IS Consulting G.K. 889 12-17 Odenma-cho Nihonbashi Chuo-ku 890 Tokyo 103-0011 891 Japan 893 Email: assie@hir.jp