idnits 2.17.1 draft-ietf-behave-lsn-requirements-02.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 11, 2011) is 4671 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 (-07) exists of draft-ietf-intarea-ipv4-id-update-02 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-13 == Outdated reference: A later version (-04) exists of draft-boucadair-intarea-nat-reveal-analysis-03 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-05 Summary: 2 errors (**), 0 flaws (~~), 6 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: January 12, 2012 S. Miyakawa 6 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 iTSCOM 11 July 11, 2011 13 Common requirements for Carrier Grade NAT (CGN) 14 draft-ietf-behave-lsn-requirements-02 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 January 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Bulk Port Allocation . . . . . . . . . . . . . . . . . . . . . 9 66 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 12 73 Appendix A. Change Log (to be removed by RFC Editor prior to 74 publication) . . . . . . . . . . . . . . . . . . . . 13 75 A.1. Changed in -02 . . . . . . . . . . . . . . . . . . . . . 13 76 A.2. Changed in -01 . . . . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 With the shortage of IPv4 addresses, it is expected that more ISPs 82 may want to provide a service where a public IPv4 address would be 83 shared by many subscribers. Each subscriber is assigned a private 84 address, and a NAT situated in the ISP's network translates between 85 private and public addresses. This is known as NAT444 86 [I-D.shirasaki-nat444-isp-shared-addr] when the CPE includes a NAT 87 function. 89 This is not to be considered a solution to the shortage of IPv4 90 addresses. It is a service that can conceivably be offered alongside 91 others, such as IPv6 services or regular, un-NATed IPv4 service. 92 Some ISPs started offering such a service long before there was a 93 shortage of IPv4 addresses, showing that there are driving forces 94 other than the shortage of IPv4 addresses. 96 This document describes behavioral requirements that are to be 97 expected of those ISP-controlled NAT. Meeting this set of 98 requirements will greatly increase the likelihood that subscribers' 99 applications will function properly. 101 Readers should be aware of potential issues that may arise when 102 sharing a public address between many subscribers. See 103 [I-D.ford-shared-addressing-issues] for details. 105 This document builds upon previous works describing requirements for 106 generic NATs [RFC4787][RFC5382][RFC5508]. These documents still 107 apply in this context. What follows are additional requirements, to 108 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 [RFC4787] and the terms 117 defined there. The following additional term is used in this 118 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 | 142 | 143 ++------++ External realm 144 ........... | CGN |............... 145 ++------++ Internal realm 146 | | 147 | | 148 | | ISP network 149 ............. | .. | ................ 150 | | Customer premises 151 ++------++ ++------++ 152 | CPE1 | | CPE2 | etc. 153 ++------++ ++------++ 155 Figure 1: CGN network topology 157 Another possible topology is one for hotspots, where there is no 158 customer premise or CPE, but where a CGN serves a bunch of customers 159 who don't trust each other and hence fairness is an issue. One 160 important difference with the previous topology is the absence of 161 NAT444. This, however, has no impact on CGN requirements since they 162 are driven by fairness and robustness in the service provided to 163 customers, which applies in both cases. 165 3. Requirements for CGNs 167 What follows is a list of requirements for CGNs. They are in 168 addition to those found in other documents such as [RFC4787], 169 [RFC5382], and [RFC5508]. 171 REQ-1: A CGN MUST support at least the following transport 172 protocols: TCP (MUST support [RFC5382]), UDP (MUST support 173 [RFC4787]), and ICMP (MUST support [RFC5508]). Support for 174 additional transport protocols is OPTIONAL. 176 Justification: These protocols are the ones that NATs traditionally 177 support. The IETF has documented the best current practices for 178 them. 180 REQ-2: A CGN MUST have a default "IP address pooling" behavior of 181 "Paired". The CGN administrator MAY change this behavior on 182 an application protocol basis. 184 * When multiple overlapping internal address ranges share 185 the same external address pool (e.g. DS-Lite 186 [I-D.ietf-softwire-dual-stack-lite]), external addresses 187 are paired with subscribers rather than internal 188 addresses. 190 Justification: This stronger form of REQ-2 from [RFC4787] is 191 justified by the stronger need for not breaking applications that 192 depend on the external address remaining constant. 194 Note that this requirement applies regardless of the transport 195 protocol. In other words, a CGN must use the same external IP 196 address mapping for all sessions associated with the same internal 197 IP address, be they TCP, UDP, ICMP, something else, or a mix of 198 different protocols. 200 The justification for allowing other behaviors is to allow the 201 administrator to save external addresses and ports for application 202 protocols that are known to work fine with other behaviors in 203 practice. However, the default behavior MUST be "Paired". 205 REQ-3: A CGN SHOULD limit the number of external ports (or, 206 equivalently, "identifiers" for ICMP) that are assigned per 207 subscriber. 209 A. Limits SHOULD be configurable by the CGN administrator. 211 B. Limits MAY be configured and applied independently per 212 transport protocol. 214 C. Additionally, it is RECOMMENDED that the CGN include 215 administrator-adjustable thresholds to prevent a single 216 subscriber from consuming excessive CPU resources from 217 the CGN (e.g. rate limit the subscriber's creation of new 218 mappings). 220 Justification: A CGN can be considered a network resource that is 221 shared by competing subscribers. Limiting the number of external 222 ports assigned to each subscriber mitigates the DoS attack that a 223 subscriber could launch against other subscribers through the CGN 224 in order to get a larger share of the resource. It ensures 225 fairness among subscribers. Limiting the rate of allocation 226 mitigates a similar attack where the CPU is the resource being 227 targeted instead of port numbers. 229 REQ-4: A CGN SHOULD limit the amount of state memory allocated per 230 mapping and per subscriber. This may include limiting the 231 number of TCP sessions, the number of filters, etc., 232 depending on the NAT implementation. 234 A. Limits SHOULD be configurable by the CGN administrator. 236 B. Additionally, it SHOULD be possible to limit the rate at 237 which memory-consuming state elements are allocated. 239 Justification: A NAT needs to keep track of TCP sessions associated 240 to each mapping. This state consumes resources for which, in the 241 case of a CGN, subscribers may compete. It is necessary to ensure 242 that each subscriber has access to a fair share of the CGN's 243 resources. Limiting TCP sessions per subscriber and per time unit 244 is an effective mitigation against inter-subscriber DoS attacks. 245 Limiting the rate of allocation is intended to prevent against CPU 246 resource exhaustion. 248 REQ-5: It SHOULD be possible to administratively turn off 249 translation for specific destination addresses and/or ports. 251 Justification: It is common for a CGN administrator to provide 252 access for subscribers to servers installed in the ISP's network, 253 in the external realm. When such a server is able to reach the 254 internal realm via normal routing (which is entirely controlled by 255 the ISP), translation is unneeded. In that case, the CGN may 256 forward packets without modification, thus acting like a plain 257 router. This may represent an important efficiency gain. 259 Figure 2 illustrates this use-case. 261 X1:x1 X1':x1' X2:x2 262 +---+from X1:x1 +---+from X1:x1 +---+ 263 | | to X2:x2 | | to X2:x2 | S | 264 | C |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e | 265 | P | | G | | r | 266 | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v | 267 | |from X2:x2 | |from X2:x2 | e | 268 | | to X1:x1 | | to X1:x1 | r | 269 +---+ +---+ +---+ 271 Figure 2: CGN pass-through 273 REQ-6: It is RECOMMENDED that a CGN have an "Endpoint-Independent 274 Filtering" behavior. 276 Justification: This is a stronger form of REQ-8 from [RFC4787]. An 277 "Address-Dependent Filtering" behavior is NOT RECOMMENDED. This 278 is based on the observation that some games and peer-to-peer 279 applications require EIF for the NAT traversal to work. In the 280 context of a CGN it is important to minimise application breakage. 282 REQ-7: When a CGN loses state (due to a crash, reboot, failover to a 283 cold standby, etc.), it MUST NOT reuse the same external IP 284 addresses for new dynamic mappings for at least 120 seconds. 286 Justification: This is necessary in order to prevent collisions 287 between old and new mappings and sessions. It ensures that all 288 established sessions are broken instead of redirected to a 289 different peer. The previous address pool MAY of course be reused 290 after a second loss of state. 292 The 120 seconds value corresponds to the Maximum Segment Lifetime 293 (MSL) from [RFC0793]. 295 One way that this requirement could be satisfied would be have two 296 distinct address pools: one dormant and one active. When 297 rebooting, the CGN would swap the dormant pool with the active 298 pool. Another way would be simply to wait 120 seconds before 299 resuming NAT activity. 301 REQ-8: Once an external port is deallocated, it SHOULD NOT be 302 reallocated to a new mapping until at least 120 seconds have 303 passed. The length of time and the maximum number of ports 304 in this state SHOULD be configurable by the CGN 305 administrator. 307 Justification: This is to prevent users from receiving unwanted 308 traffic. It also helps prevent against clock skew when mappings 309 are logged. 311 The 120 seconds value corresponds to the Maximum Segment Lifetime 312 (MSL) from [RFC0793]. 314 REQ-9: A CGN MUST handle the IPv4 ID field of translated packets as 315 described in [I-D.ietf-intarea-ipv4-id-update] section 9. 317 Justification: Refer to [I-D.ietf-intarea-ipv4-id-update]. 319 REQ-10: A CGN SHOULD support a port forwarding protocol such as the 320 Port Control Protocol [I-D.ietf-pcp-base]. 322 Justification: Allowing subscribers to manipulate the NAT state 323 table with a port forwarding protocol greatly increases the 324 likelihood that applications will function properly. 326 REQ-11: A CGN SHOULD support [RFC4008]. 328 Justification: It is anticipated that CGNs will be primarily 329 deployed in ISP networks where the need for management is 330 critical. 332 Note also that there are efforts within the IETF toward creating a 333 MIB specifically for CGNs [I-D.jpdionne-behave-cgn-mib]. 335 REQ-12: When packets pass from one side to the other, the DSCP 336 values MUST be preserved. If the CGN also includes diffserv 337 classifier and marker functionality it MAY change the DSCP 338 values. 340 Justification: See [RFC2983], in particular section 6. 342 REQ-13: When a CGN is unable to create a mapping due to resource 343 contraints or administrative restrictions (i.e. quotas)... 345 A. it MUST drop the original packet; 347 B. it SHOULD send an ICMP Destination Unreachable message 348 with code 3 (Port Unreachable) to the session initiator; 350 C. it SHOULD send a notification (e.g. SNMP trap) towards 351 a management system (if configured to do so); 353 D. and it MUST NOT delete existing mappings in order to 354 "make room" for the new one. 356 Justification: This is a slightly different form of REQ-8 from 357 [RFC5508]. Code 3 is preferred to code 13 because it is listed as 358 a "soft error" in [RFC5461], which is important because we don't 359 want TCP stacks to abort the connection attempt in this case. 360 Sending an ICMP error may be rate-limited for security reasons, 361 which is why requirement B is a SHOULD, not a MUST. 363 4. Logging 365 It may be necessary for CGN administrators to be able to identify a 366 subscriber based on external IPv4 address, port, and timestamp in 367 order to deal with abuse and lawful intercept requests. When 368 multiple subscribers share a single external address, the source 369 address and port that are visible at the destination host have been 370 translated from the ones originated by the subscriber. 372 In order to be able to do this, the CGN would need to log the 373 following information for each mapping created: 375 o internal source address 377 o internal source port 379 o external source address 381 o external source port 383 o destination address (but see below) 385 o destination port (but see below) 387 o timestamp 389 A disadvantage of this is that CGNs under heavy usage may produce 390 large amounts of logs, which may require large storage volume. 392 Readers should be aware of logging recommendations for Internet- 393 facing servers [I-D.ietf-intarea-server-logging-recommendations]. 394 With compliant servers, the destination address and port do not need 395 to be logged by the CGN. This can help reduce the amount of logging. 397 5. Bulk Port Allocation 399 So far we have assumed that a CGN allocates one external port for 400 every outgoing connection. In this section, the impacts of 401 allocating multiple external ports at a time are discussed. 403 There is a range of things a CGN can do: 405 Traditional: For every outgoing connection, allocate one external 406 port. 408 Random port set: For an outgoing connection, create a set of several 409 random external ports. Subsequent outgoing connections will use 410 ports from the set. When the set is exhausted, a new connection 411 causes a new set to be created. A set is smaller or equal to the 412 user's maximum port limit. 414 Consecutive port set: Same as the random port set, but the ports 415 allocated to a set are consecutive instead of random. 417 Note that this list is not exhaustive. There is a continuum of 418 behavior that a CGN may choose to implement. For example, a CGN 419 could use random sets of consecutive port sets. 421 The impacts of bulk port allocation are as follows. 423 Port Utilization: The mechanisms at the top of the list are very 424 efficient in their port utilization. In that sense, they have 425 good scaling properties (nothing is wasted). The mechanisms at 426 the bottom of the list will waste ports. The number of wasted 427 ports is proportional to size of the "bin". 429 Logging: Traditional allocation creates a lot of log entries. 430 Allocation by random or consecutive port sets create the same 431 number of log entries, but the entries in the case of consecutive 432 port sets are smaller because the sets can be expressed very 433 compactly by indicating a range (e.g. "12000-12009"). 435 With large set sizes, the logging frequency for random and 436 consecutive port sets can approach that of DHCP servers. 438 Traditional allocation can log destinations while random and 439 consecutive port sets cannot. This means that a CGN implementing 440 one of the latter two will rely on the remote peer to follow the 441 recommendations in 442 [I-D.ietf-intarea-server-logging-recommendations]. If this is not 443 acceptable, random or consecutive port sets cannot be used. 445 Security: Traditional and random port sets provide very good 446 security in that ports numbers are not easily guessed. Easily 447 guessed port numbers put subscribers at risk of the attacks 448 described in [RFC6056]. Consecutive port sets provides poor 449 security to subscribers, especially if the set size is small. 451 6. Deployment Considerations 453 Several issues are encountered when CGNs are used 454 [I-D.ietf-intarea-shared-addressing-issues]. There is current work 455 in the IETF toward alleviating some of these issues. For example, 456 see [I-D.boucadair-intarea-nat-reveal-analysis]. 458 The address sharing ratio is the ratio between the number of external 459 addresses and the number of internal addresses that a CGN is 460 configured to handle. See 461 [I-D.ietf-intarea-shared-addressing-issues] section 26.2 for guidance 462 on picking an appropriate ratio. 464 7. IANA Considerations 466 There are no IANA considerations. 468 8. Security Considerations 470 If a malicious subscriber can spoof another subscriber's CPE, it may 471 cause a DoS to that subscriber by creating mappings up to the allowed 472 limit. Therefore, the CGN administrator SHOULD ensure that spoofing 473 is impossible. This can be accomplished with ingress filtering, as 474 described in [RFC2827]. 476 9. Acknowledgements 478 Thanks for the input and review by Arifumi Matsumoto, Benson 479 Schliesser, Dai Kuwabara, Dan Wing, Dave Thaler, Francis Dupont, Joe 480 Touch, Lars Eggert, Kousuke Shishikura, Mohamed Boucadair, Reinaldo 481 Penno, Senthil Sivakumar, Takanori Mizuguchi, Takeshi Tomochika, 482 Tomohiro Fujisaki, Tomohiro Nishitani, Tomoya Yoshida, and Yasuhiro 483 Shirasaki. Dan Wing also contributed much of section 5. 485 10. References 487 10.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 493 C. Wang, "Definitions of Managed Objects for Network 494 Address Translators (NAT)", RFC 4008, March 2005. 496 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 497 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 498 RFC 4787, January 2007. 500 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 501 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 502 RFC 5382, October 2008. 504 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 505 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 506 April 2009. 508 [I-D.ietf-intarea-ipv4-id-update] 509 Touch, J., "Updated Specification of the IPv4 ID Field", 510 draft-ietf-intarea-ipv4-id-update-02 (work in progress), 511 March 2011. 513 10.2. Informative Reference 515 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 516 RFC 793, September 1981. 518 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 519 Translator (NAT) Terminology and Considerations", 520 RFC 2663, August 1999. 522 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 523 Defeating Denial of Service Attacks which employ IP Source 524 Address Spoofing", BCP 38, RFC 2827, May 2000. 526 [RFC2983] Black, D., "Differentiated Services and Tunnels", 527 RFC 2983, October 2000. 529 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 530 February 2009. 532 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 533 Protocol Port Randomization", BCP 156, RFC 6056, 534 January 2011. 536 [I-D.ietf-intarea-server-logging-recommendations] 537 Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 538 "Logging recommendations for Internet facing servers", 539 draft-ietf-intarea-server-logging-recommendations-04 (work 540 in progress), April 2011. 542 [I-D.ietf-intarea-shared-addressing-issues] 543 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 545 Roberts, "Issues with IP Address Sharing", 546 draft-ietf-intarea-shared-addressing-issues-05 (work in 547 progress), March 2011. 549 [I-D.ietf-pcp-base] 550 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 551 Selkirk, "Port Control Protocol (PCP)", 552 draft-ietf-pcp-base-13 (work in progress), July 2011. 554 [I-D.ietf-softwire-dual-stack-lite] 555 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 556 Stack Lite Broadband Deployments Following IPv4 557 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 558 in progress), May 2011. 560 [I-D.boucadair-intarea-nat-reveal-analysis] 561 Boucadair, M., Touch, J., Levis, P., and R. Penno, 562 "Analysis of Solution Candidates to Reveal a Host 563 Identifier in Shared Address Deployments", 564 draft-boucadair-intarea-nat-reveal-analysis-03 (work in 565 progress), June 2011. 567 [I-D.ford-shared-addressing-issues] 568 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 569 Roberts, "Issues with IP Address Sharing", 570 draft-ford-shared-addressing-issues-02 (work in progress), 571 March 2010. 573 [I-D.jpdionne-behave-cgn-mib] 574 Dionne, J. and M. Blanchet, "CGN Management Information 575 Base (MIB)", draft-jpdionne-behave-cgn-mib-00 (work in 576 progress), July 2011. 578 [I-D.shirasaki-nat444-isp-shared-addr] 579 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 580 and H. Ashida, "NAT444 addressing models", 581 draft-shirasaki-nat444-isp-shared-addr-05 (work in 582 progress), January 2011. 584 Appendix A. Change Log (to be removed by RFC Editor prior to 585 publication) 587 A.1. Changed in -02 589 o CGNs MUST support at least TCP, UDP, and ICMP. 591 o Add requirement from [I-D.ietf-intarea-ipv4-id-update]. 593 o Add informative reference to 594 [I-D.ietf-intarea-shared-addressing-issues]. 596 o Add requirement (SHOULD level) for a port forwarding protocol. 598 o Allow any pooling behavior on a per-application protocol basis. 600 o Adjust wording for external port allocation rate limiting. 602 o Add requirement for RFC4008 support (SHOULD level). 604 o Adjust wording for swapping address pools when rebooting. 606 o Add DSCP requirement (stolen from draft-jennings-behave-nat6). 608 o Add informative reference to 609 draft-boucadair-intarea-nat-reveal-analysis. 611 o Add requirement for hold-down pool. 613 o Change definition of CGN. 615 o Avoid usage of "device" loaded word throughout the document. 617 o Add requirement about resource exhaustion. 619 o Change title. 621 o Describe additional CGN topology where there is no NAT444. 623 o Better justification for "Paired" pool behavior. 625 o Make it clear that rate limiting allocation is for preserving CPU 626 resources 628 o Generalize the requirement for limiting the number of TCP sessions 629 per mapping so that it applies to all memory-consuming state 630 elements. 632 o Change CPE to subscriber where it applies throughout the text. 634 o Better terminology for bulk port allocation mechanisms. 636 o Explain how external address pairing works with DS-Lite. 638 A.2. Changed in -01 640 o Terminology: LSN is now CGN. 642 o Imported all requirements from RFCs 4787, 5382, and 5508. This 643 allowed us to eliminate some duplication. 645 o Added references to 646 draft-ietf-intarea-server-logging-recommendations and 647 draft-ford-shared-addressing-issues. 649 o Incorporated a requirement from 650 draft-xu-behave-stateful-nat-standby-06. 652 Authors' Addresses 654 Simon Perreault (editor) 655 Viagenie 656 2875 boul. Laurier, suite D2-630 657 Quebec, QC G1V 2M2 658 Canada 660 Phone: +1 418 656 9254 661 Email: simon.perreault@viagenie.ca 662 URI: http://www.viagenie.ca 664 Ikuhei Yamagata 665 NTT Communications Corporation 666 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 667 Tokyo 108-8118 668 Japan 670 Phone: +81 50 3812 4704 671 Email: ikuhei@nttv6.jp 673 Shin Miyakawa 674 NTT Communications Corporation 675 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 676 Tokyo 108-8118 677 Japan 679 Phone: +81 50 3812 4695 680 Email: miyakawa@nttv6.jp 681 Akira Nakagawa 682 Japan Internet Exchange Co., Ltd. (JPIX) 683 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 684 Tokyo 100-0004 685 Japan 687 Phone: +81 90 9242 2717 688 Email: a-nakagawa@jpix.ad.jp 690 Hiroyuki Ashida 691 its communications Inc. 692 541-1 Ichigao-cho Aoba-ku 693 Yokohama 225-0024 694 Japan 696 Email: ashida@itscom.ad.jp