idnits 2.17.1 draft-ietf-behave-lsn-requirements-06.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 (May 3, 2012) is 4369 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 Summary: 1 error (**), 0 flaws (~~), 4 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: November 4, 2012 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 May 3, 2012 13 Common requirements for Carrier Grade NATs (CGNs) 14 draft-ietf-behave-lsn-requirements-06 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 November 4, 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 . . . . . . . . . . . . . . . . . . . . 4 58 4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 5. Bulk Port Allocation . . . . . . . . . . . . . . . . . . . . . 10 60 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 67 Appendix A. Change Log (to be removed by RFC Editor prior to 68 publication) . . . . . . . . . . . . . . . . . . . . 14 69 A.1. Changed in -06 . . . . . . . . . . . . . . . . . . . . . 14 70 A.2. Changed in -05 . . . . . . . . . . . . . . . . . . . . . 15 71 A.3. Changed in -04 . . . . . . . . . . . . . . . . . . . . . 15 72 A.4. Changed in -03 . . . . . . . . . . . . . . . . . . . . . 16 73 A.5. Changed in -02 . . . . . . . . . . . . . . . . . . . . . 16 74 A.6. Changed in -01 . . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 With the shortage of IPv4 addresses, it is expected that more 80 Internet Service Providers (ISPs) may want to provide a service where 81 a public IPv4 address would be shared by many subscribers. Each 82 subscriber is assigned a private address, and a Network Address 83 Translator (NAT) [RFC2663] situated in the ISP's network translates 84 between private and public addresses. When a second IPv4 NAT is 85 located at the customer edge, this results in two layers of NAT. 87 This service can conceivably be offered alongside others, such as 88 IPv6 services or regular IPv4 service assigning public addresses to 89 subscribers. Some ISPs started offering such a service long before 90 there was a shortage of IPv4 addresses, showing that there are 91 driving forces other than the shortage of IPv4 addresses. 93 This document describes behavior that is required of those multi- 94 subscriber NATs for interoperability. 96 Because subscribers do not receive unique IP addresses, Carrier Grade 97 NATs introduce substantial limitations in communications between 98 subscribers and with the rest of the Internet. In particular, it is 99 considerably more involved to establish proxy functionality at the 100 border between internal and external realms. Some applications may 101 require substantial enhancements, while some others may not function 102 at all in such an environment. Please see "Issues with IP Address 103 Sharing" [RFC6269] for details. 105 This document builds upon previous works describing requirements for 106 generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their 107 updates if any, still apply in this context. What follows are 108 additional requirements, to be satisfied on top of previous ones. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 Readers are expected to be familiar with "NAT Behavioral Requirements 117 for Unicast UDP" [RFC4787] and the terms defined there. The 118 following additional term is used in this document: 120 Carrier-Grade NAT (CGN): A NAT-based [RFC2663] functional element 121 operated by an administrative entity (e.g., operator) to share the 122 same address among several subscribers. A CGN is managed by the 123 administrative entity, not the subscribers. 125 Note that the term "carrier-grade" has nothing to do with the 126 quality of the NAT; that is left to discretion of implementers. 127 Rather, it is to be understood as a topological qualifier: the 128 NAT is placed in an ISP's network and translates the traffic of 129 potentially many subscribers. Subscribers have limited or no 130 control over the CGN, whereas they typically have full control 131 over a NAT placed on their premises. 133 Figure 1 summarizes a common network topology in which a CGN 134 operates. 136 . 137 : 138 | Internet 139 ............... | ................... 140 | ISP network 141 External pool: | 142 192.0.2.1/26 | 143 ++------++ External realm 144 ........... | CGN |............... 145 ++------++ Internal realm 146 10.0.0.1 | | 147 | | 148 | | ISP network 149 ............. | .. | ................ 150 | | Customer premises 151 10.0.0.100 | | 10.0.0.101 152 ++------++ ++------++ 153 | CPE1 | | CPE2 | etc. 154 ++------++ ++------++ 156 (IP addresses are only for example purposes) 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: If a CGN forwards packets containing a given transport 176 protocol, then it MUST fulfill that transport protocol's 177 behavioral requirements. Current applicable documents are as 178 follows: 180 REQ-1: "NAT Behavioral Requirements for Unicast UDP" 181 [RFC4787] 183 REQ-2: "NAT Behavioral Requirements for TCP" [RFC5382] 185 REQ-3: "NAT Behavioral Requirements for ICMP" [RFC5508] 187 REQ-4: "NAT Behavioral Requirements for DCCP" [RFC5597] 189 If NAT behavioral requirements documents are created for 190 additional protocols, then these new documents MUST update 191 this list by adding themselves to it. 193 Justification: It is crucial for CGNs to maximize the set of 194 applications that can function properly across them. The IETF has 195 documented the best current practices for UDP, TCP, ICMP, and 196 DCCP. 198 REQ-2: A CGN SHOULD have a default "IP address pooling" behavior of 199 "Paired" (as defined in [RFC4787] section 4.1). A CGN MAY 200 provide a mechanism for administrators to change this 201 behavior on an application protocol basis. 203 * When multiple overlapping internal IP address ranges share 204 the same external IP address pool (e.g., DS-Lite 205 [RFC6333]), the "IP address pooling" behavior applies to 206 mappings between external IP addresses and internal 207 subscribers rather than between external and internal IP 208 addresses. 210 Justification: This stronger form of REQ-2 from [RFC4787] is 211 justified by the stronger need for not breaking applications that 212 depend on the external address remaining constant. 214 Note that this requirement applies regardless of the transport 215 protocol. In other words, a CGN must use the same external IP 216 address mapping for all sessions associated with the same internal 217 IP address, be they TCP, UDP, ICMP, something else, or a mix of 218 different protocols. 220 The justification for allowing other behaviors is to allow the 221 administrator to save external addresses and ports for application 222 protocols that are known to work fine with other behaviors in 223 practice. However, the default behavior MUST be "Paired". 225 REQ-3: The CGN function SHOULD NOT have any limitations on the size 226 nor the contiguity of the external address pool. In 227 particular, the CGN function SHOULD be configurable with 228 contiguous or non-contiguous external IPv4 address ranges. 230 Justification: Given the increasing rarity of IPv4 addresses, it is 231 becoming harder for an operator to provide large contiguous 232 address pools to CGNs. Additionally, operational flexibility may 233 require non-contiguous address pools for reasons such as 234 differentiated services, routing management, etc. 236 REQ-4: A CGN SHOULD support limiting the number of external ports 237 (or, equivalently, "identifiers" for ICMP) that are assigned 238 per subscriber. 240 A. Limits SHOULD be configurable by the CGN administrator. 242 B. Limits MAY be configurable independently per transport 243 protocol. 245 C. Additionally, it is RECOMMENDED that the CGN include 246 administrator-adjustable thresholds to prevent a single 247 subscriber from consuming excessive CPU resources from 248 the CGN (e.g., rate limit the subscriber's creation of 249 new mappings). 251 Justification: A CGN can be considered a network resource that is 252 shared by competing subscribers. Limiting the number of external 253 ports assigned to each subscriber mitigates the DoS attack that a 254 subscriber could launch against other subscribers through the CGN 255 in order to get a larger share of the resource. It ensures 256 fairness among subscribers. Limiting the rate of allocation 257 mitigates a similar attack where the CPU is the resource being 258 targeted instead of port numbers. 260 REQ-5: A CGN SHOULD support limiting the amount of state memory 261 allocated per mapping and per subscriber. This may include 262 limiting the number of sessions, the number of filters, etc., 263 depending on the NAT implementation. 265 A. Limits SHOULD be configurable by the CGN administrator. 267 B. Additionally, it SHOULD be possible to limit the rate at 268 which memory-consuming state elements are allocated. 270 Justification: A NAT needs to keep track of TCP sessions associated 271 to each mapping. This state consumes resources for which, in the 272 case of a CGN, subscribers may compete. It is necessary to ensure 273 that each subscriber has access to a fair share of the CGN's 274 resources. Limiting TCP sessions per subscriber and per time unit 275 is an effective mitigation against inter-subscriber DoS attacks. 276 Limiting the rate of allocation is intended to prevent against CPU 277 resource exhaustion. 279 REQ-6: It SHOULD be possible to administratively turn off 280 translation for specific destination addresses and/or ports. 282 Justification: It is common for a CGN administrator to provide 283 access for subscribers to servers installed in the ISP's network, 284 in the external realm. When such a server is able to reach the 285 internal realm via normal routing (which is entirely controlled by 286 the ISP), translation is unneeded. In that case, the CGN may 287 forward packets without modification, thus acting like a plain 288 router. This may represent an important efficiency gain. 290 Figure 2 illustrates this use-case. 292 X1:x1 X1':x1' X2:x2 293 +---+from X1:x1 +---+from X1:x1 +---+ 294 | C | to X2:x2 | | to X2:x2 | S | 295 | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e | 296 | i | | G | | r | 297 | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v | 298 | n |from X2:x2 | |from X2:x2 | e | 299 | t | to X1:x1 | | to X1:x1 | r | 300 +---+ +---+ +---+ 302 Figure 2: CGN pass-through 304 REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent 305 Filtering" behavior (as defined in [RFC4787] section 5). If 306 it is known that "Address-Independent Filtering" does not 307 cause the application-layer protocol to break (how to 308 determine this is out of scope for this document), then it 309 MAY be used instead. 311 Justification: This is a stronger form of REQ-8 from [RFC4787]. 312 This is based on the observation that some games and peer-to-peer 313 applications require EIF for the NAT traversal to work. In the 314 context of a CGN it is important to minimize application breakage. 316 REQ-8: Once an external port is deallocated, it SHOULD NOT be 317 reallocated to a new mapping until at least 120 seconds have 318 passed, with the exceptions being: 320 A. If the CGN tracks TCP sessions (e.g., with a state 321 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 322 be reused immediately. 324 B. If external ports are statically assigned to internal 325 addresses (e.g., address X with port range 1000-1999 is 326 assigned to subscriber A, 2000-2999 to subscriber B, 327 etc.), and the assignment remains constant across state 328 loss, then ports MAY be reused immediately. 330 C. If the allocated external ports used address-dependent or 331 address-and-port-dependent filtering before state loss, 332 they MAY be reused immediately. 334 The length of time and the maximum number of ports in this 335 state SHOULD be configurable by the CGN administrator. 337 Justification: This is necessary in order to prevent collisions 338 between old and new mappings and sessions. It ensures that all 339 established sessions are broken instead of redirected to a 340 different peer. 342 The exceptions are for cases where reusing a port immediately does 343 not create a possibility that packets would be redirected to the 344 wrong peer. 346 The 120 seconds value corresponds to the Maximum Segment Lifetime 347 (MSL) from [RFC0793]. 349 Note that this requirement also applies to the case when a CGN 350 loses state (due to a crash, reboot, failover to a cold standby, 351 etc.). In that case, ports that were in use at the time of state 352 loss SHOULD NOT be reallocated until at least 120 seconds have 353 passed. 355 REQ-9: A CGN MUST include a Port Control Protocol server 356 [I-D.ietf-pcp-base]. 358 Justification: Allowing subscribers to manipulate the NAT state 359 table with PCP greatly increases the likelihood that applications 360 will function properly. 362 REQ-10: CGN implementrers SHOULD make their equipment manageable. 363 Standards-based management using standards such as 364 "Definitions of Managed Objects for NAT" [RFC4008] is 365 RECOMMENDED. 367 Justification: It is anticipated that CGNs will be primarily 368 deployed in ISP networks where the need for management is 369 critical. 371 Note also that there are efforts within the IETF toward creating a 372 MIB tailored for CGNs (e.g., [I-D.ietf-behave-nat-mib]). 374 REQ-11: When a CGN is unable to create a mapping due to resource 375 constraints or administrative restrictions (i.e., quotas): 377 A. it MUST drop the original packet; 379 B. it SHOULD send an ICMP Destination Unreachable message 380 with code 1 (Host Unreachable) to the sender; 382 C. it SHOULD send a notification (e.g., SNMP trap) towards 383 a management system (if configured to do so); 385 D. and it SHOULD NOT delete existing mappings in order to 386 "make room" for the new one. (This only applies to 387 normal CGN behavior, not to manual operator 388 intervention.) 390 Justification: This is a slightly different form of REQ-8 from 391 [RFC5508]. Code 1 is preferred to code 13 because it is listed as 392 a "soft error" in [RFC1122], which is important because we don't 393 want TCP stacks to abort the connection attempt in this case. See 394 [RFC5461] for details on TCP's reaction to soft errors. 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. When multiple subscribers share a single 410 external address, the source address and port that are visible at the 411 destination host have been translated from the ones originated by the 412 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-12: 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., [RFC6431]). 486 With large set sizes, the logging frequency for scattered and 487 consecutive port sets can approach that of DHCP servers. 489 Security: Traditional and scattered port sets provide very good 490 security in that ports numbers are not easily guessed. Easily 491 guessed port numbers put subscribers at risk of the attacks 492 described in [RFC6056]. Consecutive port sets provides poor 493 security to subscribers, especially if the set size is small. 495 6. Deployment Considerations 497 Several issues are encountered when CGNs are used [RFC6269]. There 498 is current work in the IETF toward alleviating some of these issues. 499 For example, see [I-D.boucadair-intarea-nat-reveal-analysis]. 501 7. IANA Considerations 503 There are no IANA considerations. 505 8. Security Considerations 507 If a malicious subscriber can spoof another subscriber's CPE, it may 508 cause a DoS to that subscriber by creating mappings up to the allowed 509 limit. An ISP can prevent this with ingress filtering, as described 510 in [RFC2827]. 512 This document recommends Endpoint-Independent Filtering (EIF) as the 513 default filtering behavior for CGNs. EIF has security considerations 514 which are discussed in [RFC4787]. 516 NATs sometimes perform fragment reassembly. CGNs would do so at 517 presumably high data rates. Therefore, the reader should be familiar 518 with the potential security issues described in [RFC4963]. 520 9. Acknowledgements 522 Thanks for the input and review by Arifumi Matsumoto, Benson 523 Schliesser, Dai Kuwabara, Dan Wing, Dave Thaler, David Harrington, 524 Francis Dupont, Joe Touch, Lars Eggert, Kousuke Shishikura, Mohamed 525 Boucadair, Nejc Skoberne, Reinaldo Penno, Senthil Sivakumar, Takanori 526 Mizuguchi, Takeshi Tomochika, Tina Tsou, Tomohiro Fujisaki, Tomohiro 527 Nishitani, Tomoya Yoshida, and Yasuhiro Shirasaki. Dan Wing also 528 contributed much of section 5. 530 10. References 532 10.1. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 538 C. Wang, "Definitions of Managed Objects for Network 539 Address Translators (NAT)", RFC 4008, March 2005. 541 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 542 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 543 RFC 4787, January 2007. 545 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 546 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 547 RFC 5382, October 2008. 549 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 550 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 551 April 2009. 553 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 554 Behavioral Requirements for the Datagram Congestion 555 Control Protocol", BCP 150, RFC 5597, September 2009. 557 [I-D.ietf-pcp-base] 558 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 559 Selkirk, "Port Control Protocol (PCP)", 560 draft-ietf-pcp-base-24 (work in progress), March 2012. 562 10.2. Informative Reference 564 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 565 RFC 793, September 1981. 567 [RFC1122] Braden, R., "Requirements for Internet Hosts - 568 Communication Layers", STD 3, RFC 1122, October 1989. 570 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 571 Translator (NAT) Terminology and Considerations", 572 RFC 2663, August 1999. 574 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 575 Defeating Denial of Service Attacks which employ IP Source 576 Address Spoofing", BCP 38, RFC 2827, May 2000. 578 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 579 Errors at High Data Rates", RFC 4963, July 2007. 581 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 582 February 2009. 584 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 585 Protocol Port Randomization", BCP 156, RFC 6056, 586 January 2011. 588 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 589 NAT64: Network Address and Protocol Translation from IPv6 590 Clients to IPv4 Servers", RFC 6146, April 2011. 592 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 593 Roberts, "Issues with IP Address Sharing", RFC 6269, 594 June 2011. 596 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 597 "Logging Recommendations for Internet-Facing Servers", 598 BCP 162, RFC 6302, June 2011. 600 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 601 Stack Lite Broadband Deployments Following IPv4 602 Exhaustion", RFC 6333, August 2011. 604 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 605 T. Tsou, "Huawei Port Range Configuration Options for PPP 606 IP Control Protocol (IPCP)", RFC 6431, November 2011. 608 [I-D.boucadair-intarea-nat-reveal-analysis] 609 Boucadair, M., Touch, J., Levis, P., and R. Penno, 610 "Analysis of Solution Candidates to Reveal a Host 611 Identifier in Shared Address Deployments", 612 draft-boucadair-intarea-nat-reveal-analysis-04 (work in 613 progress), September 2011. 615 [I-D.ietf-behave-nat-mib] 616 Perreault, S., Tsou, T., and S. Sivakumar, "Additional 617 Definitions of Managed Objects for Network Address 618 Translators (NAT)", draft-ietf-behave-nat-mib-00 (work in 619 progress), April 2012. 621 Appendix A. Change Log (to be removed by RFC Editor prior to 622 publication) 624 A.1. Changed in -06 626 o Expanded some acronyms. 628 o Added example IP addresses to ASCII art. 630 o Reword transport protocol section. 632 o Stronger words of caution about CGNs. 634 o Refer to RFC for DCCP NAT behaviour. 636 o Note in headers and abstract that this updates RFC 4787. 638 o Remove sentence "This is not to be considered a solution to the 639 shortage of IPv4 addresses." 641 o Remove text having marketing scent. 643 o Change some "MUST ... unless" requirements to "SHOULD ... unless". 645 o Merge REQ-8 and REQ-9. 647 o PCP is now a MUST. 649 o NAT-MIB is now an example rather than specificially required. 651 o When a quota is hit, send ICMP DU code 1 instead of code 3. 653 o Remove mention of "lawful intercept". 655 o Remove discussion on destination logging from section on bulk port 656 allocation. 658 o Remove discussion on address sharing ratio. 660 A.2. Changed in -05 662 o Removed DSCP requirement since it applies to non-CG NATs as well. 664 o Removed instances of "NAT444". 666 o Filtering has no effect on the requirement for a hold down pool. 667 Removed REQ-8-B. 669 o Statically assigned port ranges do not need to go in the hold down 670 pool. Added a new REQ-8-B. 672 o Fixed various nits. More precise text in some places. 674 A.3. Changed in -04 676 o Fixed nits, spelling, updated references. 678 o CGNs SHOULD NOT log destinations. 680 o Allow address-dependent filtering when it does not cause the 681 application protocol to break. 683 o Refer to RFC4787 security considerations on EIF. 685 o Clarify REQ-12 point D (it does not apply to operator 686 intervention). 688 o Changed "CGNs SHOULD limit ..." to "SHOULD support limiting" to 689 make it clear that the operator is in control. 691 o Added reference to RFC 4963. 693 o Added requirement for non-contiguous external address pools. 695 A.4. Changed in -03 697 o Added exceptions for which it is not necessary to wait 120 seconds 698 before reusing a port. 700 o Renamed "random port set" to "scattered port set", which is more 701 accurate. 703 o Log "subscriber identifier" instead of internal address+port to 704 allow for overlapping internal address ranges (DS-Lite). 706 o Adjusted logging text and added reference to I-D.boucadair-pppext- 707 portrange-option. 709 o Adjusted destination logging text for bulk port allocation 710 schemes. 712 o Removed requirement for I-D.ietf-intarea-ipv4-id-update. 714 o Made PCP support a SHOULD-level requirement. 716 o Lowered the level of requirement for not dropping existing 717 mappings in order to "make room" to SHOULD level, and added 718 rationale. 720 A.5. Changed in -02 722 o CGNs MUST support at least TCP, UDP, and ICMP. 724 o Add requirement from I-D.ietf-intarea-ipv4-id-update. 726 o Add informative reference to [RFC6269]. 728 o Add requirement (SHOULD level) for a port forwarding protocol. 730 o Allow any pooling behavior on a per-application protocol basis. 732 o Adjust wording for external port allocation rate limiting. 734 o Add requirement for RFC4008 support (SHOULD level). 736 o Adjust wording for swapping address pools when rebooting. 738 o Add DSCP requirement (stolen from draft-jennings-behave-nat6). 740 o Add informative reference to 741 draft-boucadair-intarea-nat-reveal-analysis. 743 o Add requirement for hold-down pool. 745 o Change definition of CGN. 747 o Avoid usage of "device" loaded word throughout the document. 749 o Add requirement about resource exhaustion. 751 o Change title. 753 o Describe additional CGN topology where there is no NAT444. 755 o Better justification for "Paired" pool behavior. 757 o Make it clear that rate limiting allocation is for preserving CPU 758 resources 760 o Generalize the requirement for limiting the number of TCP sessions 761 per mapping so that it applies to all memory-consuming state 762 elements. 764 o Change CPE to subscriber where it applies throughout the text. 766 o Better terminology for bulk port allocation mechanisms. 768 o Explain how external address pairing works with DS-Lite. 770 A.6. Changed in -01 772 o Terminology: LSN is now CGN. 774 o Imported all requirements from RFCs 4787, 5382, and 5508. This 775 allowed us to eliminate some duplication. 777 o Added references to 778 draft-ietf-intarea-server-logging-recommendations and 779 draft-ford-shared-addressing-issues. 781 o Incorporated a requirement from 782 draft-xu-behave-stateful-nat-standby-06. 784 Authors' Addresses 786 Simon Perreault (editor) 787 Viagenie 788 2875 boul. Laurier, suite D2-630 789 Quebec, QC G1V 2M2 790 Canada 792 Phone: +1 418 656 9254 793 Email: simon.perreault@viagenie.ca 794 URI: http://www.viagenie.ca 796 Ikuhei Yamagata 797 NTT Communications Corporation 798 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 799 Tokyo 108-8118 800 Japan 802 Phone: +81 50 3812 4704 803 Email: ikuhei@nttv6.jp 805 Shin Miyakawa 806 NTT Communications Corporation 807 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 808 Tokyo 108-8118 809 Japan 811 Phone: +81 50 3812 4695 812 Email: miyakawa@nttv6.jp 813 Akira Nakagawa 814 Japan Internet Exchange Co., Ltd. (JPIX) 815 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 816 Tokyo 100-0004 817 Japan 819 Phone: +81 90 9242 2717 820 Email: a-nakagawa@jpix.ad.jp 822 Hiroyuki Ashida 823 IS Consulting G.K. 824 12-17 Odenma-cho Nihonbashi Chuo-ku 825 Tokyo 103-0011 826 Japan 828 Email: assie@hir.jp