idnits 2.17.1 draft-ietf-behave-lsn-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4561 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-16 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-06 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 Intended status: BCP I. Yamagata 5 Expires: April 26, 2012 S. Miyakawa 6 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 October 24, 2011 13 Common requirements for Carrier Grade NAT (CGN) 14 draft-ietf-behave-lsn-requirements-04 16 Abstract 18 This document defines common requirements for Carrier-Grade NAT 19 (CGN). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 26, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Requirements for CGNs . . . . . . . . . . . . . . . . . . . . 4 64 4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Destination Logging . . . . . . . . . . . . . . . . . . . 10 66 5. Bulk Port Allocation . . . . . . . . . . . . . . . . . . . . . 10 67 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Change Log (to be removed by RFC Editor prior to 75 publication) . . . . . . . . . . . . . . . . . . . . 15 76 A.1. Changed in -04 . . . . . . . . . . . . . . . . . . . . . . 15 77 A.2. Changed in -03 . . . . . . . . . . . . . . . . . . . . . . 15 78 A.3. Changed in -02 . . . . . . . . . . . . . . . . . . . . . . 16 79 A.4. Changed in -01 . . . . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 With the shortage of IPv4 addresses, it is expected that more ISPs 85 may want to provide a service where a public IPv4 address would be 86 shared by many subscribers. Each subscriber is assigned a private 87 address, and a NAT situated in the ISP's network translates between 88 private and public addresses. This is known as NAT444 89 [I-D.shirasaki-nat444-isp-shared-addr] when the CPE includes a NAT 90 function. 92 This is not to be considered a solution to the shortage of IPv4 93 addresses. It is a service that can conceivably be offered alongside 94 others, such as IPv6 services or regular, un-NATed IPv4 service. 95 Some ISPs started offering such a service long before there was a 96 shortage of IPv4 addresses, showing that there are driving forces 97 other than the shortage of IPv4 addresses. 99 This document describes behavioral requirements that are to be 100 expected of those ISP-controlled NAT. Meeting this set of 101 requirements will greatly increase the likelihood that subscribers' 102 applications will function properly. 104 Readers should be aware of potential issues that may arise when 105 sharing a public address between many subscribers. See [RFC6269] for 106 details. 108 This document builds upon previous works describing requirements for 109 generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their 110 updates if any, still apply in this context. What follows are 111 additional requirements, to be satisfied on top of previous ones. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Readers are expected to be familiar with [RFC4787] and the terms 120 defined there. The following additional term is used in this 121 document: 123 Carrier-Grade NAT (CGN): A NAT-based [RFC2663] functional element 124 operated by an administrative entity (e.g. operator) to share the 125 same address among several subscribers. A CGN is managed by the 126 administrative entity, not the subscribers. 128 Note that the term "carrier-grade" has nothing to do with the 129 quality of the NAT; that is left to discretion of implementers. 130 Rather, it is to be understood as a topological qualifier: the 131 NAT is placed in an ISP's network and translates the traffic of 132 potentially many subscribers. Subscribers have limited or no 133 control over the CGN, whereas they typically have full control 134 over a NAT placed on their premises. 136 Figure 1 summarizes a common network topology in which a CGN 137 operates. 139 . 140 : 141 | Internet 142 ............... | ................... 143 | ISP network 144 | 145 | 146 ++------++ External realm 147 ........... | CGN |............... 148 ++------++ Internal realm 149 | | 150 | | 151 | | ISP network 152 ............. | .. | ................ 153 | | Customer premises 154 ++------++ ++------++ 155 | CPE1 | | CPE2 | etc. 156 ++------++ ++------++ 158 Figure 1: CGN network topology 160 Another possible topology is one for hotspots, where there is no 161 customer premise or CPE, but where a CGN serves a bunch of customers 162 who don't trust each other and hence fairness is an issue. One 163 important difference with the previous topology is the absence of 164 NAT444. This, however, has no impact on CGN requirements since they 165 are driven by fairness and robustness in the service provided to 166 customers, which applies in both cases. 168 3. Requirements for CGNs 170 What follows is a list of requirements for CGNs. They are in 171 addition to those found in other documents such as [RFC4787], 172 [RFC5382], and [RFC5508]. 174 REQ-1: A CGN MUST support at least the following transport 175 protocols: TCP (MUST support [RFC5382]), UDP (MUST support 176 [RFC4787]), and ICMP (MUST support [RFC5508]). Support for 177 additional transport protocols is OPTIONAL. 179 Justification: These protocols are the ones that NATs traditionally 180 support. The IETF has documented the best current practices for 181 them. 183 REQ-2: A CGN MUST have a default "IP address pooling" behavior of 184 "Paired". The CGN administrator MAY change this behavior on 185 an application protocol basis. 187 * When multiple overlapping internal address ranges share 188 the same external address pool (e.g. DS-Lite [RFC6333]), 189 external addresses are paired with subscribers rather than 190 internal addresses. 192 Justification: This stronger form of REQ-2 from [RFC4787] is 193 justified by the stronger need for not breaking applications that 194 depend on the external address remaining constant. 196 Note that this requirement applies regardless of the transport 197 protocol. In other words, a CGN must use the same external IP 198 address mapping for all sessions associated with the same internal 199 IP address, be they TCP, UDP, ICMP, something else, or a mix of 200 different protocols. 202 The justification for allowing other behaviors is to allow the 203 administrator to save external addresses and ports for application 204 protocols that are known to work fine with other behaviors in 205 practice. However, the default behavior MUST be "Paired". 207 REQ-3: The CGN function SHOULD NOT have any pre-requisite on the 208 size neither the contiguity of the external address pool. 210 * In particular, the CGN function SHOULD be able to be 211 configured with contiguous and non-contiguous external 212 IPv4 addresses. 214 Justification: Given the increasing rarity of IPv4 addresses, it is 215 becoming harder for an operator to provide large contiguous 216 address pools to CGNs. Additionally, operational flexibility may 217 require non-contiguous addresss pools for ressons such as 218 differentiated services, routing management, etc. 220 REQ-4: A CGN SHOULD support limiting the number of external ports 221 (or, equivalently, "identifiers" for ICMP) that are assigned 222 per subscriber. 224 A. Limits SHOULD be configurable by the CGN administrator. 226 B. Limits MAY be configured and applied independently per 227 transport protocol. 229 C. Additionally, it is RECOMMENDED that the CGN include 230 administrator-adjustable thresholds to prevent a single 231 subscriber from consuming excessive CPU resources from 232 the CGN (e.g. rate limit the subscriber's creation of new 233 mappings). 235 Justification: A CGN can be considered a network resource that is 236 shared by competing subscribers. Limiting the number of external 237 ports assigned to each subscriber mitigates the DoS attack that a 238 subscriber could launch against other subscribers through the CGN 239 in order to get a larger share of the resource. It ensures 240 fairness among subscribers. Limiting the rate of allocation 241 mitigates a similar attack where the CPU is the resource being 242 targeted instead of port numbers. 244 REQ-5: A CGN SHOULD support limiting the amount of state memory 245 allocated per mapping and per subscriber. This may include 246 limiting the number of TCP sessions, the number of filters, 247 etc., depending on the NAT implementation. 249 A. Limits SHOULD be configurable by the CGN administrator. 251 B. Additionally, it SHOULD be possible to limit the rate at 252 which memory-consuming state elements are allocated. 254 Justification: A NAT needs to keep track of TCP sessions associated 255 to each mapping. This state consumes resources for which, in the 256 case of a CGN, subscribers may compete. It is necessary to ensure 257 that each subscriber has access to a fair share of the CGN's 258 resources. Limiting TCP sessions per subscriber and per time unit 259 is an effective mitigation against inter-subscriber DoS attacks. 260 Limiting the rate of allocation is intended to prevent against CPU 261 resource exhaustion. 263 REQ-6: It SHOULD be possible to administratively turn off 264 translation for specific destination addresses and/or ports. 266 Justification: It is common for a CGN administrator to provide 267 access for subscribers to servers installed in the ISP's network, 268 in the external realm. When such a server is able to reach the 269 internal realm via normal routing (which is entirely controlled by 270 the ISP), translation is unneeded. In that case, the CGN may 271 forward packets without modification, thus acting like a plain 272 router. This may represent an important efficiency gain. 274 Figure 2 illustrates this use-case. 276 X1:x1 X1':x1' X2:x2 277 +---+from X1:x1 +---+from X1:x1 +---+ 278 | | to X2:x2 | | to X2:x2 | S | 279 | C |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e | 280 | P | | G | | r | 281 | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v | 282 | |from X2:x2 | |from X2:x2 | e | 283 | | to X1:x1 | | to X1:x1 | r | 284 +---+ +---+ +---+ 286 Figure 2: CGN pass-through 288 REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent 289 Filtering" behavior UNLESS it is known that "Address- 290 Independent Filtering" does not cause the application-layer 291 protocol to break. 293 Justification: This is a stronger form of REQ-8 from [RFC4787]. 294 This is based on the observation that some games and peer-to-peer 295 applications require EIF for the NAT traversal to work. In the 296 context of a CGN it is important to minimize application breakage. 298 REQ-8: When a CGN loses state (due to a crash, reboot, failover to a 299 cold standby, etc.), it MUST NOT reuse the same external 300 address+port pairs for new dynamic mappings for at least 120 301 seconds, except for the following cases: 303 A. If the CGN tracks TCP sessions (e.g. with a state 304 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 305 be reused immediately. 307 B. If the allocated external ports used address-dependent or 308 address-and-port-dependent filtering before state loss, 309 they MAY be reused immediately. 311 Justification: This is necessary in order to prevent collisions 312 between old and new mappings and sessions. It ensures that all 313 established sessions are broken instead of redirected to a 314 different peer. 316 The exceptions are for cases where reusing a port immediately does 317 not create a possibility that packets would be redirected to the 318 wrong peer. 320 The 120 seconds value corresponds to the Maximum Segment Lifetime 321 (MSL) from [RFC0793]. 323 One way that this requirement could be satisfied would be have two 324 distinct address pools: one dormant and one active. When 325 rebooting, the CGN would swap the dormant pool with the active 326 pool. Another way would be simply to wait 120 seconds before 327 resuming NAT activity. 329 REQ-9: Once an external port is deallocated, it SHOULD NOT be 330 reallocated to a new mapping until at least 120 seconds have 331 passed. The length of time and the maximum number of ports 332 in this state SHOULD be configurable by the CGN 333 administrator. The following exceptions apply: 335 A. If the CGN tracks TCP sessions (e.g. with a state 336 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 337 be reused immediately. 339 B. If the allocated external ports used address-dependent or 340 address-and-port-dependent filtering before state loss, 341 they MAY be reused immediately. 343 Justification: This is to prevent users from receiving unwanted 344 traffic. It also helps prevent against clock skew when mappings 345 are logged. 347 The exceptions are for cases where reusing a port immediately does 348 not create a possibility that packets would be redirected to the 349 wrong peer. 351 The 120 seconds value corresponds to the Maximum Segment Lifetime 352 (MSL) from [RFC0793]. 354 REQ-10: A CGN SHOULD include a Port Control Protocol server 355 [I-D.ietf-pcp-base]. 357 Justification: Allowing subscribers to manipulate the NAT state 358 table with PCP greatly increases the likelihood that applications 359 will function properly. 361 REQ-11: A CGN SHOULD support [RFC4008]. 363 Justification: It is anticipated that CGNs will be primarily 364 deployed in ISP networks where the need for management is 365 critical. 367 Note also that there are efforts within the IETF toward creating a 368 MIB specifically for CGNs [I-D.jpdionne-behave-cgn-mib]. 370 REQ-12: When packets pass from one side to the other, the DSCP 371 values MUST be preserved. If the CGN also includes diffserv 372 classifier and marker functionality it MAY change the DSCP 373 values. 375 Justification: See [RFC2983], in particular section 6. 377 REQ-13: When a CGN is unable to create a mapping due to resource 378 constraints or administrative restrictions (i.e. quotas)... 380 A. it MUST drop the original packet; 382 B. it SHOULD send an ICMP Destination Unreachable message 383 with code 3 (Port Unreachable) to the session initiator; 385 C. it SHOULD send a notification (e.g. SNMP trap) towards 386 a management system (if configured to do so); 388 D. and it SHOULD NOT delete existing mappings in order to 389 "make room" for the new one. (This only applies to 390 normal CGN behavior, not to manual operator 391 intervention.) 393 Justification: This is a slightly different form of REQ-8 from 394 [RFC5508]. Code 3 is preferred to code 13 because it is listed as 395 a "soft error" in [RFC5461], which is important because we don't 396 want TCP stacks to abort the connection attempt in this case. 397 Sending an ICMP error may be rate-limited for security reasons, 398 which is why requirement B is a SHOULD, not a MUST. 400 Applications generally handle connection establishment failure 401 better than established connection failure. This is why dropping 402 the packet initiating the new connection is to preferred to 403 deleting existing mappings. See also the rationale in [RFC5508] 404 section 6. 406 4. Logging 408 It may be necessary for CGN administrators to be able to identify a 409 subscriber based on external IPv4 address, port, and timestamp in 410 order to deal with abuse and lawful intercept requests. When 411 multiple subscribers share a single external address, the source 412 address and port that are visible at the destination host have been 413 translated from the ones originated by the subscriber. 415 In order to be able to do this, the CGN would need to log the 416 following information for each mapping created: 418 o subscriber identifier (e.g. internal source address or tunnel 419 endpoint identifier) 421 o external source address 423 o external source port 425 o timestamp 427 By "subscriber identifier" we mean information that uniquely 428 identifies a subscriber. For example, in a traditional NAT scenario, 429 the internal source address would be sufficient. In the case of DS- 430 Lite, many subscribers share the same internal address and the 431 subscriber identifier is the tunnel endpoint identifier (i.e. the 432 B4's IPv6 address). 434 A disadvantage of logging mappings is that CGNs under heavy usage may 435 produce large amounts of logs, which may require large storage 436 volume. 438 4.1. Destination Logging 440 Readers should be aware of logging recommendations for Internet- 441 facing servers [RFC6302]. With compliant servers, the destination 442 address and port do not need to be logged by the CGN. This can help 443 reduce the amount of logging. Furthermore, given that destination 444 logging at the CGN creates privacy issues, CGNs SHOULD NOT log 445 destinations. 447 5. Bulk Port Allocation 449 So far we have assumed that a CGN allocates one external port for 450 every outgoing connection. In this section, the impacts of 451 allocating multiple external ports at a time are discussed. 453 There is a range of things a CGN can do: 455 Traditional: For every outgoing connection, allocate one external 456 port. 458 Scattered port set: For an outgoing connection, create a set of 459 several non-consecutive external ports. Subsequent outgoing 460 connections will use ports from the set. When the set is 461 exhausted, a new connection causes a new set to be created. A set 462 is smaller or equal to the user's maximum port limit. 464 Consecutive port set: Same as the scattered port set, but the ports 465 allocated to a set are consecutive. 467 Note that this list is not exhaustive. There is a continuum of 468 behavior that a CGN may choose to implement. For example, a CGN 469 could use scattered port sets of consecutive port sets. 471 The impacts of bulk port allocation are as follows. 473 Port Utilization: The mechanisms at the top of the list are very 474 efficient in their port utilization. In that sense, they have 475 good scaling properties (nothing is wasted). The mechanisms at 476 the bottom of the list will waste ports. The number of wasted 477 ports is proportional to size of the "bin". 479 Logging: Traditional allocation creates a lot of log entries as 480 compared to allocation by port sets create much fewer entries. 481 Scattered and consecutive port sets generate the same number of 482 log entries. In the case of consecutive port sets, entries can be 483 expressed very compactly by indicating a range (e.g. "12000- 484 12009"). Some scattered port set allocation schemes can also 485 generate small log entries containing the parameters and algorithm 486 used for the port set generation (see e.g. 487 [I-D.boucadair-pppext-portrange-option]). 489 With large set sizes, the logging frequency for scattered and 490 consecutive port sets can approach that of DHCP servers. 492 Logging destination addresses and ports can only be done on a per- 493 session basis. This means that destination logging for a CGN 494 implementing bulk port allocation would create one log entry per 495 session containing the destination address and port. Other 496 information could still be logged in one entry per port set. 498 Security: Traditional and scattered port sets provide very good 499 security in that ports numbers are not easily guessed. Easily 500 guessed port numbers put subscribers at risk of the attacks 501 described in [RFC6056]. Consecutive port sets provides poor 502 security to subscribers, especially if the set size is small. 504 6. Deployment Considerations 506 Several issues are encountered when CGNs are used [RFC6269]. There 507 is current work in the IETF toward alleviating some of these issues. 508 For example, see [I-D.boucadair-intarea-nat-reveal-analysis]. 510 The address sharing ratio is the ratio between the number of external 511 addresses and the number of internal addresses that a CGN is 512 configured to handle. See [RFC6269] section 26.2 for guidance on 513 picking an appropriate ratio. 515 7. IANA Considerations 517 There are no IANA considerations. 519 8. Security Considerations 521 If a malicious subscriber can spoof another subscriber's CPE, it may 522 cause a DoS to that subscriber by creating mappings up to the allowed 523 limit. Therefore, the CGN administrator SHOULD ensure that spoofing 524 is impossible. This can be accomplished with ingress filtering, as 525 described in [RFC2827]. 527 Endpoint-Independent Filtering has security considerations which are 528 discussed in [RFC4787]. 530 NATs sometimes perform fragment reassembly. CGNs would do so at 531 presumably high data rates. Therefore, the reader should be familiar 532 with the potential security issues described in [RFC4963]. 534 9. Acknowledgements 536 Thanks for the input and review by Arifumi Matsumoto, Benson 537 Schliesser, Dai Kuwabara, Dan Wing, Dave Thaler, Francis Dupont, Joe 538 Touch, Lars Eggert, Kousuke Shishikura, Mohamed Boucadair, Nejc 539 Skoberne, Reinaldo Penno, Senthil Sivakumar, Takanori Mizuguchi, 540 Takeshi Tomochika, Tomohiro Fujisaki, Tomohiro Nishitani, Tomoya 541 Yoshida, and Yasuhiro Shirasaki. Dan Wing also contributed much of 542 section 5. 544 10. References 546 10.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 552 C. Wang, "Definitions of Managed Objects for Network 553 Address Translators (NAT)", RFC 4008, March 2005. 555 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 556 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 557 RFC 4787, January 2007. 559 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 560 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 561 RFC 5382, October 2008. 563 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 564 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 565 April 2009. 567 [I-D.ietf-pcp-base] 568 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 569 Selkirk, "Port Control Protocol (PCP)", 570 draft-ietf-pcp-base-16 (work in progress), October 2011. 572 10.2. Informative Reference 574 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 575 RFC 793, September 1981. 577 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 578 Translator (NAT) Terminology and Considerations", 579 RFC 2663, August 1999. 581 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 582 Defeating Denial of Service Attacks which employ IP Source 583 Address Spoofing", BCP 38, RFC 2827, May 2000. 585 [RFC2983] Black, D., "Differentiated Services and Tunnels", 586 RFC 2983, October 2000. 588 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 589 Errors at High Data Rates", RFC 4963, July 2007. 591 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 592 February 2009. 594 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 595 Protocol Port Randomization", BCP 156, RFC 6056, 596 January 2011. 598 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 599 NAT64: Network Address and Protocol Translation from IPv6 600 Clients to IPv4 Servers", RFC 6146, April 2011. 602 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 603 Roberts, "Issues with IP Address Sharing", RFC 6269, 604 June 2011. 606 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 607 "Logging Recommendations for Internet-Facing Servers", 608 BCP 162, RFC 6302, June 2011. 610 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 611 Stack Lite Broadband Deployments Following IPv4 612 Exhaustion", RFC 6333, August 2011. 614 [I-D.boucadair-intarea-nat-reveal-analysis] 615 Boucadair, M., Touch, J., Levis, P., and R. Penno, 616 "Analysis of Solution Candidates to Reveal a Host 617 Identifier in Shared Address Deployments", 618 draft-boucadair-intarea-nat-reveal-analysis-04 (work in 619 progress), September 2011. 621 [I-D.boucadair-pppext-portrange-option] 622 Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 623 T. Tsou, "Huawei Port Range Configuration Options for PPP 624 IPCP", draft-boucadair-pppext-portrange-option-09 (work in 625 progress), September 2011. 627 [I-D.jpdionne-behave-cgn-mib] 628 Dionne, J. and M. Blanchet, "CGN Management Information 629 Base (MIB)", draft-jpdionne-behave-cgn-mib-00 (work in 630 progress), July 2011. 632 [I-D.shirasaki-nat444-isp-shared-addr] 633 Yamaguchi, J., Shirasaki, Y., Miyakawa, S., Nakagawa, A., 634 and H. Ashida, "NAT444 addressing models", 635 draft-shirasaki-nat444-isp-shared-addr-06 (work in 636 progress), July 2011. 638 Appendix A. Change Log (to be removed by RFC Editor prior to 639 publication) 641 A.1. Changed in -04 643 o Fixed nits, spelling, updated references. 645 o CGNs SHOULD NOT log destinations. 647 o Allow address-dependent filtering when it does not cause the 648 application protocol to break. 650 o Refer to RFC4787 security considerations on EIF. 652 o Clarify REQ-12 point D (it does not apply to operator 653 intervention). 655 o Changed "CGNs SHOULD limit ..." to "SHOULD support limiting" to 656 make it clear that the operator is in control. 658 o Added reference to RFC 4963. 660 o Added requirement for non-contiguous external address pools. 662 A.2. Changed in -03 664 o Added exceptions for which it is not necessary to wait 120 seconds 665 before reusing a port. 667 o Renamed "random port set" to "scattered port set", which is more 668 accurate. 670 o Log "subscriber identifier" instead of internal address+port to 671 allow for overlapping internal address ranges (DS-Lite). 673 o Adjusted logging text and added reference to I-D.boucadair-pppext- 674 portrange-option. 676 o Adjusted destination logging text for bulk port allocation 677 schemes. 679 o Removed requirement for I-D.ietf-intarea-ipv4-id-update. 681 o Made PCP support a SHOULD-level requirement. 683 o Lowered the level of requirement for not dropping existing 684 mappings in order to "make room" to SHOULD level, and added 685 rationale. 687 A.3. Changed in -02 689 o CGNs MUST support at least TCP, UDP, and ICMP. 691 o Add requirement from I-D.ietf-intarea-ipv4-id-update. 693 o Add informative reference to [RFC6269]. 695 o Add requirement (SHOULD level) for a port forwarding protocol. 697 o Allow any pooling behavior on a per-application protocol basis. 699 o Adjust wording for external port allocation rate limiting. 701 o Add requirement for RFC4008 support (SHOULD level). 703 o Adjust wording for swapping address pools when rebooting. 705 o Add DSCP requirement (stolen from draft-jennings-behave-nat6). 707 o Add informative reference to 708 draft-boucadair-intarea-nat-reveal-analysis. 710 o Add requirement for hold-down pool. 712 o Change definition of CGN. 714 o Avoid usage of "device" loaded word throughout the document. 716 o Add requirement about resource exhaustion. 718 o Change title. 720 o Describe additional CGN topology where there is no NAT444. 722 o Better justification for "Paired" pool behavior. 724 o Make it clear that rate limiting allocation is for preserving CPU 725 resources 727 o Generalize the requirement for limiting the number of TCP sessions 728 per mapping so that it applies to all memory-consuming state 729 elements. 731 o Change CPE to subscriber where it applies throughout the text. 733 o Better terminology for bulk port allocation mechanisms. 735 o Explain how external address pairing works with DS-Lite. 737 A.4. Changed in -01 739 o Terminology: LSN is now CGN. 741 o Imported all requirements from RFCs 4787, 5382, and 5508. This 742 allowed us to eliminate some duplication. 744 o Added references to 745 draft-ietf-intarea-server-logging-recommendations and 746 draft-ford-shared-addressing-issues. 748 o Incorporated a requirement from 749 draft-xu-behave-stateful-nat-standby-06. 751 Authors' Addresses 753 Simon Perreault (editor) 754 Viagenie 755 2875 boul. Laurier, suite D2-630 756 Quebec, QC G1V 2M2 757 Canada 759 Phone: +1 418 656 9254 760 Email: simon.perreault@viagenie.ca 761 URI: http://www.viagenie.ca 763 Ikuhei Yamagata 764 NTT Communications Corporation 765 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 766 Tokyo 108-8118 767 Japan 769 Phone: +81 50 3812 4704 770 Email: ikuhei@nttv6.jp 771 Shin Miyakawa 772 NTT Communications Corporation 773 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 774 Tokyo 108-8118 775 Japan 777 Phone: +81 50 3812 4695 778 Email: miyakawa@nttv6.jp 780 Akira Nakagawa 781 Japan Internet Exchange Co., Ltd. (JPIX) 782 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 783 Tokyo 100-0004 784 Japan 786 Phone: +81 90 9242 2717 787 Email: a-nakagawa@jpix.ad.jp 789 Hiroyuki Ashida 790 IS Consulting G.K. 791 12-17 Odenma-cho Nihonbashi Chuo-ku 792 Tokyo 103-0011 793 Japan 795 Email: assie@hir.jp