idnits 2.17.1 draft-donley-behave-deterministic-cgn-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 18 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2013) is 3936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-04 == Outdated reference: A later version (-06) exists of draft-sivakumar-behave-nat-logging-05 == Outdated reference: A later version (-06) exists of draft-tsou-behave-natx4-log-reduction-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Donley 3 Internet-Draft C. Grundemann 4 Intended status: Informational V. Sarawat 5 Expires: January 12, 2014 K. Sundaresan 6 CableLabs 7 O. Vautrin 8 Juniper Networks 9 July 11, 2013 11 Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT 12 Deployments 13 draft-donley-behave-deterministic-cgn-06 15 Abstract 17 In some instances, Service Providers have a legal logging requirement 18 to be able to map a subscriber's inside address with the address used 19 on the public Internet (e.g. for abuse response). Unfortunately, 20 many Carrier Grade NAT logging solutions require active logging of 21 dynamic translations. Carrier Grade NAT port assignments are often 22 per-connection, but could optionally use port ranges. Research 23 indicates that per-connection logging is not scalable in many 24 residential broadband services. This document suggests a way to 25 manage Carrier Grade NAT translations in such a way as to 26 significantly reduce the amount of logging required while providing 27 traceability for abuse response. While the authors acknowledge that 28 IPv6 is a preferred solution, Carrier Grade NAT is a reality in many 29 networks, and is needed in situations where either customer equipment 30 or Internet content only supports IPv4; this approach should in no 31 way slow the deployment of IPv6. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 12, 2014. 56 Copyright Notice 58 Copyright (c) 2013 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Deterministic Port Ranges . . . . . . . . . . . . . . . . . . 4 75 2.1. IPv4 Port Utilization Efficiency . . . . . . . . . . . . 7 76 2.2. Planning & Dimensioning . . . . . . . . . . . . . . . . . 8 77 2.3. Deterministic CGN Example . . . . . . . . . . . . . . . . 8 78 3. Additional Logging Considerations . . . . . . . . . . . . . . 9 79 3.1. Failover Considerations . . . . . . . . . . . . . . . . . 10 80 4. Impact on the IPv6 Transition . . . . . . . . . . . . . . . . 10 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 8.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 It is becoming increasingly difficult to obtain new IPv4 address 92 assignments from Regional/Local Internet Registries due to depleting 93 supplies of unallocated IPv4 address space. To meet the growing 94 demand for Internet connectivity from new subscribers, devices, and 95 service types, some operators will be forced to share a single public 96 IPv4 address among multiple subscribers using techniques such as 97 Carrier Grade Network Address Translation (CGN) [RFC6264] (e.g., 98 NAT444 [I-D.shirasaki-nat444], DS-Lite [RFC6333], NAT64 [RFC6146] 99 etc.). However, address sharing poses additional challenges to 100 operators when considering how they manage service entitlement, 101 public safety requests, or attack/abuse/fraud reports [RFC6269]. In 102 order to identify a specific user associated with an IP address in 103 response to such a request or for service entitlement, an operator 104 will need to map a subscriber's internal source IP address and source 105 port with the global public IP address and source port provided by 106 the CGN for every connection initiated by the user. 108 CGN connection logging satisfies the need to identify attackers and 109 respond to abuse/public safety requests, but it imposes significant 110 operational challenges to operators. In lab testing, we have 111 observed CGN log messages to be approximately 150 bytes long for 112 NAT444 [I-D.shirasaki-nat444], and 175 bytes for DS-Lite [RFC6333] 113 (individual log messages vary somewhat in size). Although we are not 114 aware of definitive studies of connection rates per subscriber, 115 reports from several operators in the US sets the average number of 116 connections per household at approximately 33,000 connections per 117 day. If each connection is individually logged, this translates to a 118 data volume of approximately 5 MB per subscriber per day, or about 119 150 MB per subscriber per month; however, specific data volumes may 120 vary across different operators based on myriad factors. Based on 121 available data, a 1-million subscriber service provider will generate 122 approximately 150 terabytes of log data per month, or 1.8 petabytes 123 per year. 125 The volume of log data poses a problem for both operators and the 126 public safety community. On the operator side, it requires a 127 significant infrastructure investment by operators implementing CGN. 128 It also requires updated operational practices to maintain the 129 logging infrastructure, and requires approximately 23 Mbps of 130 bandwidth between the CGN devices and the logging infrastructure per 131 50,000 users. On the public safety side, it increases the time 132 required for an operator to search the logs in response to an abuse 133 report, and could delay investigations. Accordingly, an 134 international group of operators and public safety officials 135 approached the authors to identify a way to reduce this impact while 136 improving abuse response. 138 The volume of CGN logging can be reduced by assigning port ranges 139 instead of individual ports. Using this method, only the assignment 140 of a new port range is logged. This may massively reduce logging 141 volume. The log reduction may vary depending on the length of the 142 assigned port range, whether the port range is static or dynamic, 143 etc. This has been acknowledged in [RFC6269] and 144 [I-D.sivakumar-behave-nat-logging]. Per [RFC6269]: 146 "Address sharing solutions may mitigate these issues to some extent 147 by pre-allocating groups of ports. Then only the allocation of the 148 group needs to be recorded, and not the creation of every session 149 binding within that group. There are trade-offs to be made between 150 the sizes of these port groups, the ratio of public addresses to 151 subscribers, whether or not these groups timeout, and the impact on 152 logging requirements and port randomization security (RFC6056) 153 [RFC6056]." 155 However, the existing solution still poses an impact on operators and 156 public safety officials for logging and searching. Instead, CGNs 157 could be designed and/or configured to deterministically map internal 158 addresses to {external address + port range} in such a way as to be 159 able to algorithmically calculate the mapping. Only inputs and 160 configuration of the algorithm need to be logged. This approach 161 reduces both logging volume and subscriber identification times. In 162 some cases, when full deterministic allocation is used, this approach 163 can eliminate the need for translation logging. 165 This document describes a method for such CGN address mapping, 166 combined with block port reservations, that significantly reduces the 167 burden on operators while offering the ability to map a subscriber's 168 inside IP address with an outside address and external port number 169 observed on the Internet. 171 The activation of the proposed port range allocation scheme is 172 compliant with BEHAVE requirements such as the support of APP. 174 2. Deterministic Port Ranges 176 While a subscriber uses thousands of connections per day, most 177 subscribers use far fewer resources at any given time. When the 178 compression ratio (see Appendix B of RFC6269 [RFC6269]) is low (e.g., 179 the ratio of the number of subscribers to the number of public IPv4 180 addresses allocated to a CGN is closer to 10:1 than 1000:1), each 181 subscriber could expect to have access to thousands of TCP/UDP ports 182 at any given time. Thus, as an alternative to logging each 183 connection, CGNs could deterministically map customer private 184 addresses (received on the customer-facing interface of the CGN, 185 a.k.a., internal side) to public addresses extended with port ranges 186 (used on the Internet-facing interface of the CGN, a.k.a., external 187 side). This algorithm allows an operator to identify a subscriber 188 internal IP address when provided the public side IP and port number 189 without having to examine the CGN translation logs. This prevents an 190 operator from having to transport and store massive amounts of 191 session data from the CGN and then process it to identify a 192 subscriber. 194 The algorithmic mapping can be expressed as: 196 (External IP Address, Port Range) = function 1 (Internal IP Address) 198 Internal IP Address = function 2 (External IP Address, Port Number) 200 The CGN SHOULD provide a method for administrators to test both 201 mapping functions (e.g., enter an External IP Address + Port Number 202 and receive the corresponding Internal IP Address). 204 Deterministic Port Range allocation requires configuration of the 205 following variables: 207 o Inside IPv4/IPv6 address range (I); 209 o Outside IPv4 address range (O); 211 o Compression ratio (e.g. inside IP addresses I/outside IP addresses 212 O) (C); 214 o Dynamic address pool factor (D), to be added to the compression 215 ratio in order to create an overflow address pool; 217 o Maximum ports per user (M); 219 o Address assignment algorithm (A) (see below); and 221 o Reserved TCP/UDP port list (R) 223 Note: The inside address range (I) will be an IPv4 range in NAT444 224 operation (NAT444 [I-D.shirasaki-nat444]) and an IPv6 range in DS- 225 Lite operation (DS-Lite [RFC6333]). 227 A subscriber is identified by an internal IPv4 address (e.g., NAT44) 228 or an IPv6 prefix (e.g., DS-Lite or NAT64). 230 The algorithm may be generalized to L2-aware NAT 231 [I-D.miles-behave-l2nat] but this requires the configuration of the 232 Internal interface identifiers (e.g., MAC addresses). 234 The algorithm is not designed to retrieve an internal host among 235 those sharing the same internal IP address (e.g., in a DS-Lite 236 context, only an IPv6 address/prefix can be retrieved using the 237 algorithm while the internal IPv4 address used for the encapsulated 238 IPv4 datagram is lost). 240 Several address assignment algorithms are possible. Using predefined 241 algorithms, such as those that follow, simplifies the process of 242 reversing the algorithm when needed. However, the CGN MAY support 243 additional algorithms. Also, the CGN is not required to support all 244 algorithms described below. Subscribers could be restricted to ports 245 from a single IPv4 address, or could be allocated ports across all 246 addresses in a pool, for example. The following algorithms and 247 corresponding values of A are as follow: 249 0: Sequential (e.g. the first block goes to address 1, the second 250 block to address 2, etc.) 252 1: Staggered (e.g. for every n between 0 and ((65536-R)/(C+D))-1 , 253 address 1 receives ports n*C+R, address 2 receives ports 254 (1+n)*C+R, etc.) 256 2: Round robin (e.g. the subscriber receives the same port number 257 across a pool of external IP addresses. If the subscriber is to 258 be assigned more ports than there are in the external IP pool, the 259 subscriber receives the next highest port across the IP pool, and 260 so on. Thus, if there are 10 IP addresses in a pool and a 261 subscriber is assigned 1000 ports, the subscriber would receive a 262 range such as ports 2000-2099 across all 10 external IP 263 addresses). 265 3: Interlaced horizontally (e.g. each address receives every Cth 266 port spread across a pool of external IP addresses). 268 4: Cryptographically random port assignment (Section 2.2 of 269 RFC6431 [RFC6431]). If this algorithm is used, the Service 270 Provider needs to retain the keying material and specific 271 cryptographic function to support reversibility. 273 5: Vendor-specific. Other vendor-specific algorithms may also be 274 supported. 276 The assigned range of ports MAY also be used when translating ICMP 277 requests (when re-writing the Identifier field). 279 The CGN then reserves ports as follows: 281 1. The CGN removes reserved ports (R) from the port candidate list 282 (e.g., 0-1023 for TCP and UDP). At a minimum, the CGN SHOULD 283 remove system ports (RFC6335) [RFC6335] from the port candidate 284 list reserved for deterministic assignment. 286 2. The CGN calculates the total compression ratio (C+D), and 287 allocates 1/(C+D) of the available ports to each internal IP 288 address. Specific port allocation is determined by the algorithm 289 (A) configured on the CGN. Any remaining ports are allocated to 290 the dynamic pool. 292 Note: Setting D to 0 disables the dynamic pool. This option 293 eliminates the need for per-subscriber logging at the expense of 294 limiting the number of concurrent connections that 'power users' 295 can initiate. 297 3. When a subscriber initiates a connection, the CGN creates a 298 translation mapping between the subscriber's inside local IP 299 address/port and the CGN outside global IP address/port. The CGN 300 MUST use one of the ports allocated in step 2 for the translation 301 as long as such ports are available. The CGN SHOULD allocate 302 ports randomly within the port range assigned by the 303 deterministic algorithm. This is to increase subscriber privacy. 304 The CGN MUST use the preallocated port range from step 2 for Port 305 Control Protocol (PCP, [I-D.ietf-pcp-base]) reservations as long 306 as such ports are available. While the CGN maintains its mapping 307 table, it need not generate a log entry for translation mappings 308 created in this step. 310 4. If D>0, the CGN will have a pool of ports left for dynamic 311 assignment. If a subscriber uses more than the range of ports 312 allocated in step 2 (but fewer than the configured maximum ports 313 M), the CGN assigns a block of ports from the dynamic assignment 314 range for such a connection or for PCP reservations. The CGN 315 MUST log dynamically assigned port blocks to facilitate 316 subscriber-to-address mapping. The CGN SHOULD manage dynamic 317 ports as described in [I-D.tsou-behave-natx4-log-reduction]. 319 5. Configuration of reserved ports (e.g., system ports) is left to 320 operator configuration. 322 Thus, the CGN will maintain translation mapping information for all 323 connections within its internal translation tables; however, it only 324 needs to externally log translations for dynamically-assigned ports. 326 2.1. IPv4 Port Utilization Efficiency 328 For Service Providers requiring an aggressive address sharing ratio, 329 the use of the algorithmic mapping may impact the efficiency of the 330 address sharing. A dynamic port range allocation assignment is more 331 suitable in those cases. 333 2.2. Planning & Dimensioning 335 Unlike dynamic approaches, the use of the algorithmic mapping 336 requires more effort from operational teams to tweak the algorithm 337 (e.g., size of the port range, address sharing ratio, etc.). 338 Dedicated alarms SHOULD be configured when some port utilization 339 thresholds are fired so that the configuration can be refined. 341 The use of algorithmic mapping also affects geolocation. Changes to 342 the inside and outside address ranges (e.g. due to growth, address 343 allocation planning, etc.) would require external geolocation 344 providers to recalibrate their mappings. 346 2.3. Deterministic CGN Example 348 To illustrate the use of deterministic NAT, let's consider a simple 349 example. The operator configures an inside address range (I) of 350 100.64.0.0/28 [RFC6598] and outside address (O) of 203.0.113.1. The 351 dynamic address pool factor (D) is set to '2'. Thus, the total 352 compression ratio is 1:(14+2) = 1:16. Only the system ports (e.g. 353 ports < 1024) are reserved (R) . This configuration causes the CGN to 354 preallocate ((65536-1024)/16 =) 4032 TCP and 4032 UDP ports per 355 inside IPv4 address. For the purposes of this example, let's assume 356 that they are allocated sequentially, where 100.64.0.1 maps to 357 203.0.113.1 ports 1024-5055, 100.64.0.2 maps to 203.0.113.1 ports 358 5056-9087, etc. The dynamic port range thus contains ports 359 57472-65535 (port allocation illustrated in the table below). 360 Finally, the maximum ports/subscriber is set to 5040. 362 +-----------------------+-------------------------+ 363 | Inside Address / Pool | Outside Address & Port | 364 +-----------------------+-------------------------+ 365 | Reserved | 203.0.113.1:0-1023 | 366 | 100.64.0.1 | 203.0.113.1:1024-5055 | 367 | 100.64.0.2 | 203.0.113.1:5056-9087 | 368 | 100.64.0.3 | 203.0.113.1:9088-13119 | 369 | 100.64.0.4 | 203.0.113.1:13120-17151 | 370 | 100.64.0.5 | 203.0.113.1:17152-21183 | 371 | 100.64.0.6 | 203.0.113.1:21184-25215 | 372 | 100.64.0.7 | 203.0.113.1:25216-29247 | 373 | 100.64.0.8 | 203.0.113.1:29248-33279 | 374 | 100.64.0.9 | 203.0.113.1:33280-37311 | 375 | 100.64.0.10 | 203.0.113.1:37312-41343 | 376 | 100.64.0.11 | 203.0.113.1:41344-45375 | 377 | 100.64.0.12 | 203.0.113.1:45376-49407 | 378 | 100.64.0.13 | 203.0.113.1:49408-53439 | 379 | 100.64.0.14 | 203.0.113.1:53440-57471 | 380 | Dynamic | 203.0.113.1:57472-65535 | 381 +-----------------------+-------------------------+ 383 When subscriber 1 using 100.64.0.1 initiates a low volume of 384 connections (e.g. < 4032 concurrent connections), the CGN maps the 385 outgoing source address/port to the preallocated range. These 386 translation mappings are not logged. 388 Subscriber 2 concurrently uses more than the allocated 4032 ports 389 (e.g. for peer-to-peer, mapping, video streaming, or other 390 connection-intensive traffic types), the CGN allocates up to an 391 additional 1008 ports using bulk port reservations. In this example, 392 subscriber 2 uses outside ports 5056-9087, and then 100-port blocks 393 between 58000-58999. Connections using ports 5056-9087 are not 394 logged, while 10 log entries are created for ports 58000-58099, 395 58100-58199, 58200-58299, ..., 58900-58999. 397 In order to identify a subscriber behind a CGN (regardless of port 398 allocation method), public safety agencies need to collect source 399 address and port information from content provider log files. Thus, 400 content providers are advised to log source address, source port, and 401 timestamp for all log entries, per [RFC6302]. If a public safety 402 agency collects such information from a content provider and reports 403 abuse from 203.0.113.1, port 2001, the operator can reverse the 404 mapping algorithm to determine that the internal IP address 405 subscriber 1 has been assigned generated the traffic without 406 consulting CGN logs (by correlating the internal IP address with DHCP 407 /PPP lease connection records). If a second abuse report comes in 408 for 203.0.113.1, port 58204, the operator will determine that port 409 58204 is within the dynamic pool range, consult the log file, 410 correlate with connection records, and determine that subscriber 2 411 generated the traffic (assuming that the public safety timestamp 412 matches the operator timestamp. As noted in RFC6292 [RFC6292], 413 accurate time-keeping (e.g., use of NTP or Simple NTP) is vital). 415 In this example, there are no log entries for the majority of 416 subscribers, who only use pre-allocated ports. Only minimal logging 417 would be needed for those few subscribers who exceed their pre- 418 allocated ports and obtain extra bulk port assignments from the 419 dynamic pool. Logging data for those users will include inside 420 address, outside address, outside port range, and timestamp. 422 3. Additional Logging Considerations 424 In order to be able to identify a subscriber based on observed 425 external IPv4 address, port, and timestamp, an operator needs to know 426 how the CGN was configured with regards to internal and external IP 427 addresses, dynamic address pool factor, maximum ports per user, and 428 reserved port range at any given time. Therefore, the CGN MUST 429 generate a record any time such variables are changed. The CGN 430 SHOULD generate a log message any time such variables are changed. 431 The CGN MAY keep such a record in the form of a router configuration 432 file. If the CGN does not generate a log message, it would be up to 433 the operator to maintain version control of router config changes. 434 Also, the CGN SHOULD generate such a log message once per day to 435 facilitate quick identification of the relevant configuration in the 436 event of an abuse notification. 438 Such a log message MUST, at minimum, include the timestamp, inside 439 prefix I, inside mask, outside prefix O, outside mask, D, M, A, and 440 reserved port list R; for example: 442 [Wed Oct 11 14:32:52 443 2000]:100.64.0.0:28:203.0.113.0:32:2:5040:0:1-1023,5004,5060. 445 3.1. Failover Considerations 447 Due to the deterministic nature of algorithmically-assigned 448 translations, no additional logging is required during failover 449 conditions provided that inside address ranges are unique within a 450 given failover domain. Even when directed to a different CGN server, 451 translations within the deterministic port range on either the 452 primary or secondary server can be algorithmically reversed, provided 453 the algorithm is known. Thus, if 100.64.0.1 port 3456 maps to 454 203.0.113.1 port 1000 on CGN 1 and 198.51.100.1 port 1000 on Failover 455 CGN 2, an operator can identify the subscriber based on outside 456 source address and port information. 458 Similarly, assignments made from the dynamic overflow pool need to be 459 logged as described above, whether translations are performed on the 460 primary or failover CGN. 462 4. Impact on the IPv6 Transition 464 The solution described in this document is applicable to Carrier 465 Grade NAT transition technologies (e.g. NAT444, DS-Lite, and NAT64). 466 As discussed in [I-D.donley-nat444-impacts], the authors acknowledge 467 that native IPv6 will offer subscribers a better experience than CGN. 468 However, many CPE devices only support IPv4. Likewise, as of July 469 2012, only approximately 4% of the top 1 million websites were 470 available using IPv6. Accordingly, deterministic CGN should in no 471 way be understood as making CGN a replacement for IPv6 service. The 472 authors encourage device manufacturers to consider [RFC6540] and 473 include IPv6 support. In the interim, however, CGN has already been 474 deployed in some operator networks. Deterministic CGN will provide 475 operators with the ability to quickly respond to public safety 476 requests without requiring excessive infrastructure, operations, and 477 bandwidth to support per-connection logging. 479 5. IANA Considerations 481 This document makes no request of IANA. 483 6. Security Considerations 485 The security considerations applicable to NAT operation for various 486 protocols as documented in, for example, RFC 4787 [RFC4787] and RFC 487 5382 [RFC5382] also apply to this document. 489 Note that with the possible exception of cryptographically-based port 490 allocations, attackers could reverse-engineer algorithmically-derived 491 port allocations to either target a specific subscriber or to spoof 492 traffic to make it appear to have been generated by a specific 493 subscriber. However, this is exactly the same level of security that 494 the subscriber would experience in the absence of CGN. CGN is not 495 intended to provide additional security by obscurity. 497 7. Acknowledgements 499 The authors would like to thank the following people for their 500 suggestions and feedback: Bobby Flaim, Lee Howard, Wes George, Jean- 501 Francois Tremblay, Mohammed Boucadair, Alain Durand, David Miles, 502 Andy Anchev, Victor Kuarsingh, Miguel Cros Cecilia, and Reinaldo 503 Penno. 505 8. References 507 8.1. Normative References 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 513 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 514 RFC 4787, January 2007. 516 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 517 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 518 RFC 5382, October 2008. 520 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 521 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 522 June 2011. 524 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 525 Roberts, "Issues with IP Address Sharing", RFC 6269, June 526 2011. 528 8.2. Informative References 530 [I-D.donley-nat444-impacts] 531 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 532 Colorado, "Assessing the Impact of Carrier-Grade NAT on 533 Network Applications", draft-donley-nat444-impacts-04 534 (work in progress), May 2012. 536 [I-D.ietf-pcp-base] 537 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 538 Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp- 539 base-29 (work in progress), November 2012. 541 [I-D.miles-behave-l2nat] 542 Miles, D. and M. Townsley, "Layer2-Aware NAT", draft- 543 miles-behave-l2nat-00 (work in progress), March 2009. 545 [I-D.shirasaki-nat444] 546 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 547 and H. Ashida, "NAT444", draft-shirasaki-nat444-06 (work 548 in progress), July 2012. 550 [I-D.sivakumar-behave-nat-logging] 551 Sivakumar, S. and R. Penno, "IPFIX Information Elements 552 for logging NAT Events", draft-sivakumar-behave-nat- 553 logging-05 (work in progress), July 2012. 555 [I-D.tsou-behave-natx4-log-reduction] 556 ZOU), T., Li, W., and T. Taylor, "Port Management To 557 Reduce Logging In Large-Scale NATs", draft-tsou-behave- 558 natx4-log-reduction-02 (work in progress), September 2010. 560 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 561 Protocol Port Randomization", BCP 156, RFC 6056, January 562 2011. 564 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 565 NAT64: Network Address and Protocol Translation from IPv6 566 Clients to IPv4 Servers", RFC 6146, April 2011. 568 [RFC6292] Hoffman, P., "Requirements for a Working Group Charter 569 Tool", RFC 6292, June 2011. 571 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 572 "Logging Recommendations for Internet-Facing Servers", BCP 573 162, RFC 6302, June 2011. 575 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 576 Stack Lite Broadband Deployments Following IPv4 577 Exhaustion", RFC 6333, August 2011. 579 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 580 Cheshire, "Internet Assigned Numbers Authority (IANA) 581 Procedures for the Management of the Service Name and 582 Transport Protocol Port Number Registry", BCP 165, RFC 583 6335, August 2011. 585 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 586 T. Tsou, "Huawei Port Range Configuration Options for PPP 587 IP Control Protocol (IPCP)", RFC 6431, November 2011. 589 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 590 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 591 RFC 6540, April 2012. 593 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 594 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 595 Space", BCP 153, RFC 6598, April 2012. 597 Authors' Addresses 599 Chris Donley 600 CableLabs 601 858 Coal Creek Cir 602 Louisville, CO 80027 603 US 605 Email: c.donley@cablelabs.com 607 Chris Grundemann 608 CableLabs 609 858 Coal Creek Cir 610 Louisville, CO 80027 611 US 613 Email: c.grundemann@cablelabs.com 614 Vikas Sarawat 615 CableLabs 616 858 Coal Creek Cir 617 Louisville, CO 80027 618 US 620 Email: v.sarawat@cablelabs.com 622 Karthik Sundaresan 623 CableLabs 624 858 Coal Creek Cir 625 Louisville, CO 80027 626 US 628 Email: k.sundaresan@cablelabs.com 630 Olivier Vautrin 631 Juniper Networks 632 1194 N Mathilda Avenue 633 Sunnyvale, CA 94089 634 US 636 Email: olivier@juniper.net