idnits 2.17.1 draft-ietf-behave-lsn-requirements-05.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 (November 30, 2011) is 4530 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) Summary: 2 errors (**), 0 flaws (~~), 2 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: June 2, 2012 S. Miyakawa 6 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 November 30, 2011 13 Common requirements for Carrier Grade NATs (CGNs) 14 draft-ietf-behave-lsn-requirements-05 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 June 2, 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 5. Bulk Port Allocation . . . . . . . . . . . . . . . . . . . . . 10 66 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 73 Appendix A. Change Log (to be removed by RFC Editor prior to 74 publication) . . . . . . . . . . . . . . . . . . . . 14 75 A.1. Changed in -05 . . . . . . . . . . . . . . . . . . . . . 14 76 A.2. Changed in -04 . . . . . . . . . . . . . . . . . . . . . 15 77 A.3. Changed in -03 . . . . . . . . . . . . . . . . . . . . . 15 78 A.4. Changed in -02 . . . . . . . . . . . . . . . . . . . . . 16 79 A.5. 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. When a second IPv4 NAT is located at 89 the customer edge, this results in two layers of NAT. 91 This is not to be considered a solution to the shortage of IPv4 92 addresses. It is a service that can conceivably be offered alongside 93 others, such as IPv6 services or regular, un-NATed IPv4 service. 94 Some ISPs started offering such a service long before there was a 95 shortage of IPv4 addresses, showing that there are driving forces 96 other than the shortage of IPv4 addresses. 98 This document describes behavioral requirements that are to be 99 expected of those multi-subscriber NATs. Meeting this set of 100 requirements will greatly increase the likelihood that subscribers' 101 applications will function properly. 103 Readers should be aware of potential issues that may arise when 104 sharing a public address between many subscribers. See [RFC6269] for 105 details. 107 This document builds upon previous works describing requirements for 108 generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their 109 updates if any, still apply in this context. What follows are 110 additional requirements, to be satisfied on top of previous ones. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 Readers are expected to be familiar with [RFC4787] and the terms 119 defined there. The following additional term is used in this 120 document: 122 Carrier-Grade NAT (CGN): A NAT-based [RFC2663] functional element 123 operated by an administrative entity (e.g., operator) to share the 124 same address among several subscribers. A CGN is managed by the 125 administrative entity, not the subscribers. 127 Note that the term "carrier-grade" has nothing to do with the 128 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 customer-premises equipment (CPE), but where a 162 CGN serves a bunch of customers who don't trust each other and hence 163 fairness is an issue. One important difference with the previous 164 topology is the absence of a second layer of NAT. This, however, has 165 no impact on CGN requirements since they are driven by fairness and 166 robustness in the service provided to customers, which applies in 167 both cases. 169 3. Requirements for CGNs 171 What follows is a list of requirements for CGNs. They are in 172 addition to those found in other documents such as [RFC4787], 173 [RFC5382], and [RFC5508]. 175 REQ-1: A CGN MUST support at least the following transport 176 protocols: TCP (MUST support [RFC5382]), UDP (MUST support 177 [RFC4787]), and ICMP (MUST support [RFC5508]). Support for 178 additional transport protocols is OPTIONAL. 180 Justification: These protocols are the ones that NATs traditionally 181 support. The IETF has documented the best current practices for 182 them. 184 REQ-2: A CGN MUST have a default "IP address pooling" behavior of 185 "Paired" (as defined in [RFC4787] section 4.1). A CGN MAY 186 provide a mechanism for administrators to change this 187 behavior on an application protocol basis. 189 * When multiple overlapping internal IP address ranges share 190 the same external IP address pool (e.g., DS-Lite 191 [RFC6333]), the "IP address pooling" behavior applies to 192 mappings between external IP addresses and internal 193 subscribers rather than between external and internal IP 194 addresses. 196 Justification: This stronger form of REQ-2 from [RFC4787] is 197 justified by the stronger need for not breaking applications that 198 depend on the external address remaining constant. 200 Note that this requirement applies regardless of the transport 201 protocol. In other words, a CGN must use the same external IP 202 address mapping for all sessions associated with the same internal 203 IP address, be they TCP, UDP, ICMP, something else, or a mix of 204 different protocols. 206 The justification for allowing other behaviors is to allow the 207 administrator to save external addresses and ports for application 208 protocols that are known to work fine with other behaviors in 209 practice. However, the default behavior MUST be "Paired". 211 REQ-3: The CGN function SHOULD NOT have any limitations on the size 212 nor the contiguity of the external address pool. In 213 particular, the CGN function SHOULD be configurable with 214 contiguous or non-contiguous external IPv4 address ranges. 216 Justification: Given the increasing rarity of IPv4 addresses, it is 217 becoming harder for an operator to provide large contiguous 218 address pools to CGNs. Additionally, operational flexibility may 219 require non-contiguous address pools for reasons such as 220 differentiated services, routing management, etc. 222 REQ-4: A CGN SHOULD support limiting the number of external ports 223 (or, equivalently, "identifiers" for ICMP) that are assigned 224 per subscriber. 226 A. Limits SHOULD be configurable by the CGN administrator. 228 B. Limits MAY be configurable independently per transport 229 protocol. 231 C. Additionally, it is RECOMMENDED that the CGN include 232 administrator-adjustable thresholds to prevent a single 233 subscriber from consuming excessive CPU resources from 234 the CGN (e.g., rate limit the subscriber's creation of 235 new mappings). 237 Justification: A CGN can be considered a network resource that is 238 shared by competing subscribers. Limiting the number of external 239 ports assigned to each subscriber mitigates the DoS attack that a 240 subscriber could launch against other subscribers through the CGN 241 in order to get a larger share of the resource. It ensures 242 fairness among subscribers. Limiting the rate of allocation 243 mitigates a similar attack where the CPU is the resource being 244 targeted instead of port numbers. 246 REQ-5: A CGN SHOULD support limiting the amount of state memory 247 allocated per mapping and per subscriber. This may include 248 limiting the number of sessions, the number of filters, etc., 249 depending on the NAT implementation. 251 A. Limits SHOULD be configurable by the CGN administrator. 253 B. Additionally, it SHOULD be possible to limit the rate at 254 which memory-consuming state elements are allocated. 256 Justification: A NAT needs to keep track of TCP sessions associated 257 to each mapping. This state consumes resources for which, in the 258 case of a CGN, subscribers may compete. It is necessary to ensure 259 that each subscriber has access to a fair share of the CGN's 260 resources. Limiting TCP sessions per subscriber and per time unit 261 is an effective mitigation against inter-subscriber DoS attacks. 262 Limiting the rate of allocation is intended to prevent against CPU 263 resource exhaustion. 265 REQ-6: It SHOULD be possible to administratively turn off 266 translation for specific destination addresses and/or ports. 268 Justification: It is common for a CGN administrator to provide 269 access for subscribers to servers installed in the ISP's network, 270 in the external realm. When such a server is able to reach the 271 internal realm via normal routing (which is entirely controlled by 272 the ISP), translation is unneeded. In that case, the CGN may 273 forward packets without modification, thus acting like a plain 274 router. This may represent an important efficiency gain. 276 Figure 2 illustrates this use-case. 278 X1:x1 X1':x1' X2:x2 279 +---+from X1:x1 +---+from X1:x1 +---+ 280 | C | to X2:x2 | | to X2:x2 | S | 281 | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e | 282 | i | | G | | r | 283 | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v | 284 | n |from X2:x2 | |from X2:x2 | e | 285 | t | to X1:x1 | | to X1:x1 | r | 286 +---+ +---+ +---+ 288 Figure 2: CGN pass-through 290 REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent 291 Filtering" behavior (as defined in [RFC4787] section 5). If 292 it is known that "Address-Independent Filtering" does not 293 cause the application-layer protocol to break (how to 294 determine this is out of scope for this document), then it 295 MAY be used instead. 297 Justification: This is a stronger form of REQ-8 from [RFC4787]. 298 This is based on the observation that some games and peer-to-peer 299 applications require EIF for the NAT traversal to work. In the 300 context of a CGN it is important to minimize application breakage. 302 REQ-8: When a CGN loses state (due to a crash, reboot, failover to a 303 cold standby, etc.), it MUST NOT reuse the same external 304 address+port pairs for new dynamic mappings for at least 120 305 seconds, except for any of the following cases: 307 A. If the CGN tracks TCP sessions (e.g., with a state 308 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 309 be reused immediately. 311 B. If external ports are statically assigned to internal 312 addresses (e.g., address X with port range 1000-1999 is 313 assigned to subscriber A, 2000-2999 to subscriber B, 314 etc.), and the assignment remains constant across state 315 loss, then ports MAY be reused immediately. 317 Justification: This is necessary in order to prevent collisions 318 between old and new mappings and sessions. It ensures that all 319 established sessions are broken instead of redirected to a 320 different peer. 322 The exceptions are for cases where reusing a port immediately does 323 not create a possibility that packets would be redirected to the 324 wrong peer. 326 The 120 seconds value corresponds to the Maximum Segment Lifetime 327 (MSL) from [RFC0793]. 329 One way that this requirement could be satisfied would be have two 330 distinct address pools: one dormant and one active. When 331 rebooting, the CGN would swap the dormant pool with the active 332 pool. Another way would be simply to wait 120 seconds before 333 resuming NAT activity. 335 REQ-9: Once an external port is deallocated, it SHOULD NOT be 336 reallocated to a new mapping until at least 120 seconds have 337 passed. The length of time and the maximum number of ports 338 in this state SHOULD be configurable by the CGN 339 administrator. The following exceptions apply: 341 A. If the CGN tracks TCP sessions (e.g., with a state 342 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 343 be reused immediately. 345 B. If the allocated external ports used address-dependent or 346 address-and-port-dependent filtering before state loss, 347 they MAY be reused immediately. 349 Justification: This is to prevent users from receiving unwanted 350 traffic. It also helps prevent against clock skew when mappings 351 are logged. 353 The exceptions are for cases where reusing a port immediately does 354 not create a possibility that packets would be redirected to the 355 wrong peer. 357 The 120 seconds value corresponds to the Maximum Segment Lifetime 358 (MSL) from [RFC0793]. 360 REQ-10: A CGN SHOULD include a Port Control Protocol server 361 [I-D.ietf-pcp-base]. 363 Justification: Allowing subscribers to manipulate the NAT state 364 table with PCP greatly increases the likelihood that applications 365 will function properly. 367 REQ-11: A CGN SHOULD support [RFC4008]. 369 Justification: It is anticipated that CGNs will be primarily 370 deployed in ISP networks where the need for management is 371 critical. 373 Note also that there are efforts within the IETF toward creating a 374 MIB tailored for CGNs (e.g., [I-D.perreault-opsawg-natmib-bis]). 376 REQ-12: When a CGN is unable to create a mapping due to resource 377 constraints or administrative restrictions (i.e., quotas): 379 A. it MUST drop the original packet; 381 B. it SHOULD send an ICMP Destination Unreachable message 382 with code 3 (Port Unreachable) to the session initiator; 384 C. it SHOULD send a notification (e.g., SNMP trap) towards 385 a management system (if configured to do so); 387 D. and it SHOULD NOT delete existing mappings in order to 388 "make room" for the new one. (This only applies to 389 normal CGN behavior, not to manual operator 390 intervention.) 392 Justification: This is a slightly different form of REQ-8 from 393 [RFC5508]. Code 3 is preferred to code 13 because it is listed as 394 a "soft error" in [RFC5461], which is important because we don't 395 want TCP stacks to abort the connection attempt in this case. 396 Sending an ICMP error may be rate-limited for security reasons, 397 which is why requirement B is a SHOULD, not a MUST. 399 Applications generally handle connection establishment failure 400 better than established connection failure. This is why dropping 401 the packet initiating the new connection is preferred over 402 deleting existing mappings. See also the rationale in [RFC5508] 403 section 6. 405 4. Logging 407 It may be necessary for CGN administrators to be able to identify a 408 subscriber based on external IPv4 address, port, and timestamp in 409 order to deal with abuse and lawful intercept requests. When 410 multiple subscribers share a single external address, the source 411 address and port that are visible at the destination host have been 412 translated from the ones originated by the subscriber. 414 In order to be able to do this, the CGN would need to log the 415 following information for each mapping created: 417 o subscriber identifier (e.g., internal source address or tunnel 418 endpoint identifier) 420 o external source address 422 o external source port 424 o timestamp 426 By "subscriber identifier" we mean information that uniquely 427 identifies a subscriber. For example, in a traditional NAT scenario, 428 the internal source address would be sufficient. In the case of DS- 429 Lite, many subscribers share the same internal address and the 430 subscriber identifier is the tunnel endpoint identifier (i.e., the 431 B4's IPv6 address). 433 A disadvantage of logging mappings is that CGNs under heavy usage may 434 produce large amounts of logs, which may require large storage 435 volume. 437 REQ-13: A CGN SHOULD NOT log destination addresses or ports. 439 Justification: Destination logging at the CGN creates privacy 440 issues. Furthermore, readers should be aware of logging 441 recommendations for Internet-facing servers [RFC6302]. With 442 compliant servers, the destination address and port do not need to 443 be logged by the CGN. This can help reduce the amount of logging. 445 5. Bulk Port Allocation 447 So far we have assumed that a CGN allocates one external port for 448 every outgoing connection. In this section, the impacts of 449 allocating multiple external ports at a time are discussed. 451 There is a range of things a CGN can do: 453 Traditional: For every outgoing connection, allocate one external 454 port. 456 Scattered port set: For an outgoing connection, create a set of 457 several non-consecutive external ports. Subsequent outgoing 458 connections will use ports from the set. When the set is 459 exhausted, a new connection causes a new set to be created. A set 460 is smaller or equal to the user's maximum port limit. 462 Consecutive port set: Same as the scattered port set, but the ports 463 allocated to a set are consecutive. 465 Note that this list is not exhaustive. There is a continuum of 466 behavior that a CGN may choose to implement. For example, a CGN 467 could use scattered port sets of consecutive port sets. 469 The impacts of bulk port allocation are as follows. 471 Port Utilization: The mechanisms at the top of the list are very 472 efficient in their port utilization. In that sense, they have 473 good scaling properties (nothing is wasted). The mechanisms at 474 the bottom of the list will waste ports. The number of wasted 475 ports is proportional to size of the "bin". 477 Logging: Traditional allocation creates a lot of log entries as 478 compared to allocation by port sets which creates much fewer 479 entries. Scattered and consecutive port sets generate the same 480 number of log entries. In the case of consecutive port sets, 481 entries can be expressed very compactly by indicating a range 482 (e.g., "12000-12009"). Some scattered port set allocation schemes 483 can also generate small log entries containing the parameters and 484 algorithm used for the port set generation (see, e.g., 485 [I-D.boucadair-pppext-portrange-option]). 487 With large set sizes, the logging frequency for scattered and 488 consecutive port sets can approach that of DHCP servers. 490 Logging destination addresses and ports can only be done on a per- 491 session basis. This means that destination logging for a CGN 492 implementing bulk port allocation would create one log entry per 493 session containing the destination address and port. Other 494 information could still be logged in one entry per port set. 496 Security: Traditional and scattered port sets provide very good 497 security in that ports numbers are not easily guessed. Easily 498 guessed port numbers put subscribers at risk of the attacks 499 described in [RFC6056]. Consecutive port sets provides poor 500 security to subscribers, especially if the set size is small. 502 6. Deployment Considerations 504 Several issues are encountered when CGNs are used [RFC6269]. There 505 is current work in the IETF toward alleviating some of these issues. 506 For example, see [I-D.boucadair-intarea-nat-reveal-analysis]. 508 The address sharing ratio is the ratio between the number of external 509 addresses and the number of internal addresses that a CGN is 510 configured to handle. See [RFC6269] section 26.2 for guidance on 511 picking an appropriate ratio. 513 7. IANA Considerations 515 There are no IANA considerations. 517 8. Security Considerations 519 If a malicious subscriber can spoof another subscriber's CPE, it may 520 cause a DoS to that subscriber by creating mappings up to the allowed 521 limit. Preventing this can be accomplished with ingress filtering, 522 as described in [RFC2827]. 524 Endpoint-Independent Filtering has security considerations which are 525 discussed in [RFC4787]. 527 NATs sometimes perform fragment reassembly. CGNs would do so at 528 presumably high data rates. Therefore, the reader should be familiar 529 with the potential security issues described in [RFC4963]. 531 9. Acknowledgements 533 Thanks for the input and review by Arifumi Matsumoto, Benson 534 Schliesser, Dai Kuwabara, Dan Wing, Dave Thaler, Francis Dupont, Joe 535 Touch, Lars Eggert, Kousuke Shishikura, Mohamed Boucadair, Nejc 536 Skoberne, Reinaldo Penno, Senthil Sivakumar, Takanori Mizuguchi, 537 Takeshi Tomochika, Tina Tsou, Tomohiro Fujisaki, Tomohiro Nishitani, 538 Tomoya Yoshida, and Yasuhiro Shirasaki. Dan Wing also contributed 539 much of section 5. 541 10. References 542 10.1. Normative References 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 548 C. Wang, "Definitions of Managed Objects for Network 549 Address Translators (NAT)", RFC 4008, March 2005. 551 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 552 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 553 RFC 4787, January 2007. 555 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 556 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 557 RFC 5382, October 2008. 559 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 560 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 561 April 2009. 563 [I-D.ietf-pcp-base] 564 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 565 Selkirk, "Port Control Protocol (PCP)", 566 draft-ietf-pcp-base-16 (work in progress), October 2011. 568 10.2. Informative Reference 570 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 571 RFC 793, September 1981. 573 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 574 Translator (NAT) Terminology and Considerations", 575 RFC 2663, August 1999. 577 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 578 Defeating Denial of Service Attacks which employ IP Source 579 Address Spoofing", BCP 38, RFC 2827, May 2000. 581 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 582 Errors at High Data Rates", RFC 4963, July 2007. 584 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 585 February 2009. 587 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 588 Protocol Port Randomization", BCP 156, RFC 6056, 589 January 2011. 591 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 592 NAT64: Network Address and Protocol Translation from IPv6 593 Clients to IPv4 Servers", RFC 6146, April 2011. 595 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 596 Roberts, "Issues with IP Address Sharing", RFC 6269, 597 June 2011. 599 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 600 "Logging Recommendations for Internet-Facing Servers", 601 BCP 162, RFC 6302, June 2011. 603 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 604 Stack Lite Broadband Deployments Following IPv4 605 Exhaustion", RFC 6333, August 2011. 607 [I-D.boucadair-intarea-nat-reveal-analysis] 608 Boucadair, M., Touch, J., Levis, P., and R. Penno, 609 "Analysis of Solution Candidates to Reveal a Host 610 Identifier in Shared Address Deployments", 611 draft-boucadair-intarea-nat-reveal-analysis-04 (work in 612 progress), September 2011. 614 [I-D.boucadair-pppext-portrange-option] 615 Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 616 T. Tsou, "Huawei Port Range Configuration Options for PPP 617 IPCP", draft-boucadair-pppext-portrange-option-09 (work in 618 progress), September 2011. 620 [I-D.perreault-opsawg-natmib-bis] 621 Perreault, S. and T. ZOU), "Definitions of Managed Objects 622 for Network Address Translators (NAT)", 623 draft-perreault-opsawg-natmib-bis-00 (work in progress), 624 September 2011. 626 Appendix A. Change Log (to be removed by RFC Editor prior to 627 publication) 629 A.1. Changed in -05 631 o Removed DSCP requirement since it applies to non-CG NATs as well. 633 o Removed instances of "NAT444". 635 o Filtering has no effect on the requirement for a hold down pool. 636 Removed REQ-8-B. 638 o Statically assigned port ranges do not need to go in the hold down 639 pool. Added a new REQ-8-B. 641 o Fixed various nits. More precise text in some places. 643 A.2. Changed in -04 645 o Fixed nits, spelling, updated references. 647 o CGNs SHOULD NOT log destinations. 649 o Allow address-dependent filtering when it does not cause the 650 application protocol to break. 652 o Refer to RFC4787 security considerations on EIF. 654 o Clarify REQ-12 point D (it does not apply to operator 655 intervention). 657 o Changed "CGNs SHOULD limit ..." to "SHOULD support limiting" to 658 make it clear that the operator is in control. 660 o Added reference to RFC 4963. 662 o Added requirement for non-contiguous external address pools. 664 A.3. Changed in -03 666 o Added exceptions for which it is not necessary to wait 120 seconds 667 before reusing a port. 669 o Renamed "random port set" to "scattered port set", which is more 670 accurate. 672 o Log "subscriber identifier" instead of internal address+port to 673 allow for overlapping internal address ranges (DS-Lite). 675 o Adjusted logging text and added reference to I-D.boucadair-pppext- 676 portrange-option. 678 o Adjusted destination logging text for bulk port allocation 679 schemes. 681 o Removed requirement for I-D.ietf-intarea-ipv4-id-update. 683 o Made PCP support a SHOULD-level requirement. 685 o Lowered the level of requirement for not dropping existing 686 mappings in order to "make room" to SHOULD level, and added 687 rationale. 689 A.4. Changed in -02 691 o CGNs MUST support at least TCP, UDP, and ICMP. 693 o Add requirement from I-D.ietf-intarea-ipv4-id-update. 695 o Add informative reference to [RFC6269]. 697 o Add requirement (SHOULD level) for a port forwarding protocol. 699 o Allow any pooling behavior on a per-application protocol basis. 701 o Adjust wording for external port allocation rate limiting. 703 o Add requirement for RFC4008 support (SHOULD level). 705 o Adjust wording for swapping address pools when rebooting. 707 o Add DSCP requirement (stolen from draft-jennings-behave-nat6). 709 o Add informative reference to 710 draft-boucadair-intarea-nat-reveal-analysis. 712 o Add requirement for hold-down pool. 714 o Change definition of CGN. 716 o Avoid usage of "device" loaded word throughout the document. 718 o Add requirement about resource exhaustion. 720 o Change title. 722 o Describe additional CGN topology where there is no NAT444. 724 o Better justification for "Paired" pool behavior. 726 o Make it clear that rate limiting allocation is for preserving CPU 727 resources 729 o Generalize the requirement for limiting the number of TCP sessions 730 per mapping so that it applies to all memory-consuming state 731 elements. 733 o Change CPE to subscriber where it applies throughout the text. 735 o Better terminology for bulk port allocation mechanisms. 737 o Explain how external address pairing works with DS-Lite. 739 A.5. Changed in -01 741 o Terminology: LSN is now CGN. 743 o Imported all requirements from RFCs 4787, 5382, and 5508. This 744 allowed us to eliminate some duplication. 746 o Added references to 747 draft-ietf-intarea-server-logging-recommendations and 748 draft-ford-shared-addressing-issues. 750 o Incorporated a requirement from 751 draft-xu-behave-stateful-nat-standby-06. 753 Authors' Addresses 755 Simon Perreault (editor) 756 Viagenie 757 2875 boul. Laurier, suite D2-630 758 Quebec, QC G1V 2M2 759 Canada 761 Phone: +1 418 656 9254 762 Email: simon.perreault@viagenie.ca 763 URI: http://www.viagenie.ca 765 Ikuhei Yamagata 766 NTT Communications Corporation 767 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 768 Tokyo 108-8118 769 Japan 771 Phone: +81 50 3812 4704 772 Email: ikuhei@nttv6.jp 773 Shin Miyakawa 774 NTT Communications Corporation 775 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 776 Tokyo 108-8118 777 Japan 779 Phone: +81 50 3812 4695 780 Email: miyakawa@nttv6.jp 782 Akira Nakagawa 783 Japan Internet Exchange Co., Ltd. (JPIX) 784 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 785 Tokyo 100-0004 786 Japan 788 Phone: +81 90 9242 2717 789 Email: a-nakagawa@jpix.ad.jp 791 Hiroyuki Ashida 792 IS Consulting G.K. 793 12-17 Odenma-cho Nihonbashi Chuo-ku 794 Tokyo 103-0011 795 Japan 797 Email: assie@hir.jp