idnits 2.17.1 draft-donley-behave-deterministic-cgn-04.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, 2012) is 4307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6146' is defined on line 510, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-04 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-25 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-05 == Outdated reference: A later version (-06) exists of draft-tsou-behave-natx4-log-reduction-02 Summary: 0 errors (**), 0 flaws (~~), 7 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, 2013 K. Sundaresan 6 CableLabs 7 July 11, 2012 9 Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT 10 Deployments 11 draft-donley-behave-deterministic-cgn-04 13 Abstract 15 Abuse response in a Carrier Grade NAT environment requires Service 16 Providers to be able to map a subscriber's inside address with the 17 address used on the public Internet. Unfortunately, many Carrier 18 Grade NAT abuse-response solutions require per-connection logging. 19 Research indicates that such logging is not scalable to many 20 residential broadband services. This document suggests a way to 21 manage Carrier Grade NAT translations in such a way as to 22 significantly reduce the amount of logging required while providing 23 traceability for abuse response. While the authors acknowledge that 24 IPv6 is a preferred solution, Carrier Grade NAT is a reality in many 25 networks, and is needed in situations where either customer equipment 26 or Internet content only supports IPv4; this approach should in no 27 way slow the deployment of IPv6. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 12, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Deterministic Port Ranges . . . . . . . . . . . . . . . . . . 5 70 2.1. Stability and Load-Balancing Considerations . . . . . . . 8 71 2.2. IPv4 Port Utilization Efficiency . . . . . . . . . . . . . 8 72 2.3. Planning & Dimensioning . . . . . . . . . . . . . . . . . 9 73 2.4. Deterministic CGN Example . . . . . . . . . . . . . . . . 9 74 3. Additional Logging Considerations . . . . . . . . . . . . . . 10 75 4. Impact on the IPv6 Transition . . . . . . . . . . . . . . . . 11 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The world is rapidly running out of unallocated IPv4 addresses. To 87 ensure IPv4 service continuity under the growing demands from new 88 subscribers, devices, and service types, some ISPs will be forced to 89 share a single public IPv4 address among multiple subscribers using 90 techniques such as Carrier Grade Network Address Translation (CGN) 91 [RFC6264] (e.g., NAT444 [I-D.shirasaki-nat444], DS-Lite [RFC6333], 92 NAT64 [RFC6146]etc.). However, address sharing poses additional 93 challenges to ISPs in responding to public safety requests or attack/ 94 abuse reports [RFC6269]. In order to respond to such requests to 95 identify a specific user associated with an IP address, an ISP will 96 need to map a subscriber's internal source IP address and source port 97 with the global public IP address and source port provided by the CGN 98 for every connection initiated by the user. 100 CGN connection logging satisfies the need to identify attackers and 101 respond to abuse/public safety requests, but it imposes significant 102 operational challenges to ISPs. In lab testing, we have observed CGN 103 log messages to be approximately 150 bytes long for NAT444 104 [I-D.shirasaki-nat444], and 175 bytes for DS-Lite [RFC6333] 105 (individual log messages vary somewhat in size). Although we are not 106 aware of definitive studies of connection rates per subscriber, 107 reports from several ISPs in the US sets the average number of 108 connections per household at approximately 33,000 connections per 109 day. If each connection is individually logged, this translates to a 110 data volume of approximately 5 MB per subscriber per day, or about 111 150 MB per subscriber per month; however, specific data volumes may 112 vary across different ISPs based on myriad factors. Based on 113 available data, a 1-million subscriber service provider will generate 114 approximately 150 terabytes of log data per month, or 1.8 petabytes 115 per year. 117 The volume of log data poses a problem for both ISPs and the public 118 safety community. On the ISP side, it requires a significant 119 infrastructure investment by ISPs implementing CGN. It also requires 120 updated operational practices to maintain the logging infrastructure, 121 and requires approximately 23 Mbps of bandwidth between the CGN 122 devices and the logging infrastructure. On the public safety side, 123 it increases the time required for an ISP to search the logs in 124 response to an abuse report, and could delay investigations. 125 Accordingly, an international group of ISPs and public safety 126 officials approached the authors to identify a way to reduce this 127 impact while improving abuse response. 129 The volume of CGN logging can be reduced by assigning port ranges 130 instead of individual ports. Using this method, only the assignment 131 of a new port range is logged. This may massively reduce logging 132 volume. The log reduction may vary depending on the length of the 133 assigned port range, whether the port range is static or dynamic, 134 etc. This has been acknowledged in [RFC6269]: 136 "Address sharing solutions may mitigate these issues to some extent 137 by pre-allocating groups of ports. Then only the allocation of the 138 group needs to be recorded, and not the creation of every session 139 binding within that group. There are trade-offs to be made between 140 the sizes of these port groups, the ratio of public addresses to 141 subscribers, whether or not these groups timeout, and the impact on 142 logging requirements and port randomization security (RFC6056) 143 [RFC6056]." 145 However, the existing solution still poses an impact on ISPs and 146 public safety officials for logging and searching. Instead, CGNs 147 could be designed and/or configured to deterministically map internal 148 addresses to {external address + port range} in such a way as to be 149 able to algorithmically calculate the mapping. Only inputs and 150 configuration of the algorithm need to be logged. This approach 151 reduces both logging volume and subscriber identification times. 153 This document describes a method for such CGN address mapping, 154 combined with block port reservations, that significantly reduces the 155 burden on ISPs while offering the ability to map a subscriber's 156 inside IP address with an outside address and external port number 157 observed on the Internet. 159 The activation of the proposed port range allocation scheme is 160 compliant with BEHAVE requirements such as the support of APP. 162 2. Deterministic Port Ranges 164 While a subscriber uses thousands of connections per day, most 165 subscribers use far fewer at any given time. When the compression 166 ratio (see Appendix B of RFC6269 [RFC6269]) is low (e.g., the ratio 167 of the number of subscribers to the number of public IPv4 addresses 168 allocated to a CGN is closer to 10:1 than 1000:1), each subscriber 169 could expect to have access to thousands of TCP/UDP ports at any 170 given time. Thus, as an alternative to logging each connection, CGNs 171 could deterministically map customer private addresses (received on 172 the customer-facing interface of the CGN, a.k.a., internal side) to 173 public addresses extended with port ranges (used on the Internet- 174 facing interface of the CGN, a.k.a., external side). This algorithm 175 allows an operator to identify a subscriber internal IP address when 176 provided the public side IP and port number without having to examine 177 the CGN translation logs. This prevents an operator from having to 178 transport and store massive amounts of session data from the CGN and 179 then process it to identify a subscriber. 181 The algorithmic mapping can be expressed as: 183 (External IP Address, Port Range) = function 1 (Internal IP Address) 185 Internal IP Address = function 2 (External IP Address, Port Number) 187 The CGN SHOULD provide a method for users to test both mapping 188 functions (e.g., enter an External IP Address + Port Number and 189 receive the corresponding Internal IP Address). 191 Deterministic Port Range allocation requires configuration of the 192 following variables: 194 o Inside IPv4/IPv6 address range (I); 196 o Outside IPv4 address range (O); 198 o Compression ratio (e.g. inside IP addresses I/outside IP addresses 199 O) (C); 201 o Dynamic address pool factor (D), to be added to the compression 202 ratio in order to create an overflow address pool; 204 o Maximum ports per user (M); 206 o Address assignment algorithm (A) (see below); and 208 o Reserved TCP/UDP port list (R) 210 Note: The inside address range (I) will be an IPv4 range in NAT444 211 operation (NAT444 [I-D.shirasaki-nat444]) and an IPv6 range in DS- 212 Lite operation (DS-Lite [RFC6333]). 214 A subscriber is identified by an internal IPv4 address (e.g., NAT44) 215 or an IPv6 prefix (e.g., DS-Lite or NAT64). 217 The algorithm may be generalized to L2-aware NAT 218 [I-D.miles-behave-l2nat] but this requires the configuration of the 219 Internal interface identifiers (e.g., MAC addresses). 221 The algorithm is not designed to retrieve an internal host among 222 those sharing the same internal IP address (e.g., in a DS-Lite 223 context, only an IPv6 address/prefix can be retrieved using the 224 algorithm while the internal IPv4 address used for the encapsulated 225 IPv4 datagram is lost). 227 Several address assignment algorithms are possible. Using predefined 228 algorithms, such as those that follow, simplifies the process of 229 reversing the algorithm when needed. However, additional algorithms 230 can also be supported. Subscribers could be restricted to ports from 231 a single IPv4 address, or could be allocated ports across all 232 addresses in a pool, for example. The following algorithms and 233 corresponding values of A are as follow: 235 0: Sequential (e.g. the first block goes to address 1, the second 236 block to address 2, etc.) 238 1: Staggered (e.g. for every n between 0 and ((65536-R)/(C+D))-1 , 239 address 1 receives ports n*C+R, address 2 receives ports 240 (1+n)*C+R, etc.) 242 2: Spread horizontally (e.g. the subscriber receives the same port 243 number across a pool of external IP addresses. If the subscriber 244 is to be assigned more ports than there are in the external IP 245 pool, the subscriber receives the next highest port across the IP 246 pool, and so on. Thus, if there are 10 IP addresses in a pool and 247 a subscriber is assigned 1000 ports, the subscriber would receive 248 a range such as ports 2000-2099 across all 10 external IP 249 addresses). 251 3: Interlaced horizontally (e.g. each address receives every Cth 252 port spread across a pool of external IP addresses). 254 4: Cryptographically random port assignment (Section 2.2 of 255 RFC6431 [RFC6431]). If this algorithm is used, the Service 256 Provider needs to retain the keying material and specific 257 cryptographic function to support reversibility. 259 5: Vendor-specific. Other vendor-specific algorithms may also be 260 supported. 262 The assigned range of ports MAY also be used when translating ICMP 263 requests (when re-writing the Identifier field). 265 The CGN then reserves ports as follows: 267 1. The CGN removes reserved ports from the port candidate list 268 (e.g., 0-1023 for TCP and UDP). At a minimum, the CGN SHOULD 269 remove system ports (RFC6335) [RFC6335] from the port candidate 270 list reserved for deterministic assignment. 272 2. The CGN calculates the total compression ratio (C+D), and 273 allocates 1/(C+D) of the available ports to each internal IP 274 address. Any remaining ports are allocated to the dynamic pool. 276 3. When a subscriber initiates a connection, the CGN creates a 277 translation mapping between the subscriber's inside local IP 278 address/port and the CGN outside global IP address/port. The CGN 279 MUST use one of the ports allocated in step 2 for the translation 280 as long as such ports are available. The CGN MUST use the 281 preallocated port range from step 2 for Port Control Protocol 282 (PCP, [I-D.ietf-pcp-base]) reservations as long as such ports are 283 available. While the CGN maintains its mapping table, it need 284 not generate a log entry for translation mappings created in this 285 step. 287 4. The CGN will have a pool of ports left for dynamic assignment. 288 If a subscriber uses more than the range of ports allocated in 289 step 2 (but fewer than the configured maximum ports M), the CGN 290 uses a port from the dynamic assignment range for such a 291 connection or for PCP reservations. The CGN MUST log dynamically 292 assigned ports to facilitate subscriber-to-address mapping. The 293 CGN SHOULD manage dynamic ports as described in 294 [I-D.tsou-behave-natx4-log-reduction]. 296 5. Configuration of reserved ports (e.g., system ports) is left to 297 operator configuration. 299 Thus, the CGN will maintain translation mapping information for all 300 connections within its internal translation tables; however, it only 301 needs to externally log translations for dynamically-assigned ports. 303 2.1. Stability and Load-Balancing Considerations 305 Using the procedure defined in this document assumes a deterministic 306 distribution of customers among deployed CGN devices. Balancing the 307 traffic among several CGNs based on their actual load may not be 308 supported because of the potential conflict of enforced algorithmic 309 mapping rule. When CGN redundancy group is used, the same mapping 310 rule, including in particular the external IP address, MUST be used. 311 Furthermore, traffic oscillation MUST be avoided (because, unless 312 state synchronization is used, the actual NAT state may not be 313 instantiated in the redundancy group). 315 2.2. IPv4 Port Utilization Efficiency 317 For Service Providers requiring an aggressive address sharing ration, 318 the use of the algorithmic mapping may impact the efficiency of the 319 address sharing. Using a dynamic port range scheme, dynamic port 320 assignment or a mix of static mapping and dynamic port assignment is 321 more suitable for those SPs. 323 2.3. Planning & Dimensioning 325 Unlike dynamic approaches, the use of the algorithmic mapping 326 requires more effort from operational teams to tweak the algorithm 327 (e.g., size of the port range, address sharing ratio, etc.). 328 Dedicated alarms SHOULD be configured when some port utilization 329 thresholds are fired so that the configuration can be refined. 331 2.4. Deterministic CGN Example 333 To illustrate the use of deterministic NAT, let's consider a simple 334 example. The operator configures an inside address range (I) of 335 100.64.0.0/28 and outside address (O) of 203.0.113.1. The dynamic 336 address pool factor (D) is set to '2'. Thus, the total compression 337 ratio is 1:(14+2) = 1:16. Only the system ports (e.g. ports < 1024) 338 are reserved. This configuration causes the CGN to preallocate 339 ((65536-1024)/16 =) 4032 TCP and 4032 UDP ports per inside IPv4 340 address. For the purposes of this example, let's assume that they 341 are allocated sequentially, where 100.64.0.1 maps to 203.0.113.1 342 ports 1024-5055, 100.64.0.2 maps to 203.0.113.1 ports 5056-9087, etc. 343 The dynamic port range thus contains ports 57472-65535 (port 344 allocation illustrated in the table below). Finally, the maximum 345 ports/subscriber is set to 5040. 347 +-----------------------+-------------------------+ 348 | Inside Address / Pool | Outside Address & Port | 349 +-----------------------+-------------------------+ 350 | Reserved | 203.0.113.1:0-1023 | 351 | 100.64.0.1 | 203.0.113.1:1024-5055 | 352 | 100.64.0.2 | 203.0.113.1:5056-9087 | 353 | 100.64.0.3 | 203.0.113.1:9088-13119 | 354 | 100.64.0.4 | 203.0.113.1:13120-17151 | 355 | 100.64.0.5 | 203.0.113.1:17151-21183 | 356 | 100.64.0.6 | 203.0.113.1:21184-25215 | 357 | 100.64.0.7 | 203.0.113.1:25216-29247 | 358 | 100.64.0.8 | 203.0.113.1:29248-33279 | 359 | 100.64.0.9 | 203.0.113.1:33280-37311 | 360 | 100.64.0.10 | 203.0.113.1:37312-41343 | 361 | 100.64.0.11 | 203.0.113.1:41344-45375 | 362 | 100.64.0.12 | 203.0.113.1:45376-49407 | 363 | 100.64.0.13 | 203.0.113.1:49408-53439 | 364 | 100.64.0.14 | 203.0.113.1:53440-57471 | 365 | Dynamic | 203.0.113.1:57472-65535 | 366 +-----------------------+-------------------------+ 368 When subscriber 1 using 100.64.0.1 initiates a low volume of 369 connections (e.g. < 4032 concurrent connections), the CGN maps the 370 outgoing source address/port to the preallocated range. These 371 translation mappings are not logged. 373 Subscriber 2 concurrently uses more than the allocated 4032 ports 374 (e.g. for peer-to-peer, mapping, video streaming, or other 375 connection-intensive traffic types), the CGN allocates up to an 376 additional 1008 ports using bulk port reservations. In this example, 377 subscriber 2 uses outside ports 5056-9087, and then 100-port blocks 378 between 58000-58999. Connections using ports 5056-9087 are not 379 logged, while 10 log entries are created for ports 58000-58099, 380 58100-58199, 58200-58299, ..., 58900-58999. 382 If a public safety agency reports abuse from 203.0.113.1, port 2001, 383 the operator can reverse the mapping algorithm to determine that the 384 internal IP address subscriber 1 has been assigned generated the 385 traffic without consulting CGN logs (by correlating the internal IP 386 address with DHCP/PPP lease connection records). If a second abuse 387 report comes in for 203.0.113.1, port 58204, the operator will 388 determine that port 58204 is within the dynamic pool range, consult 389 the log file, correlate with connection records, and determine that 390 subscriber 2 generated the traffic (assuming that the public safety 391 timestamp matches the operator timestamp. As noted in RFC6292 392 [RFC6292], accurate time-keeping (e.g., use of NTP or Simple NTP) is 393 vital). 395 In this example, there are no log entries for the majority of 396 subscribers, who only use pre-allocated ports. Only minimal logging 397 would be needed for those few subscribers who exceed their pre- 398 allocated ports and obtain extra bulk port assignments from the 399 dynamic pool. Logging data for those users will include inside 400 address, outside address, outside port range, and timestamp. 402 3. Additional Logging Considerations 404 In order to be able to identify a subscriber based on observed 405 external IPv4 address, port, and timestamp, an operator needs to know 406 how the CGN was configured with regards to internal and external IP 407 addresses, dynamic address pool factor, maximum ports per user, and 408 reserved port range at any given time. Therefore, the CGN MUST 409 generate a log message any time such variables are changed. Also, 410 the CGN SHOULD generate such a log message once per day to facilitate 411 quick identification of the relevant configuration in the event of an 412 abuse notification. 414 Such a log message MUST, at minimum, include the timestamp, inside 415 prefix I, inside mask, outside prefix O, outside mask, D, M, A, and 416 reserved port list; for example: 418 [Wed Oct 11 14:32:52 2000]:100.64.0.0:28:203.0.113.0:32:2:5040:0:1- 419 1023,5004,5060. 421 4. Impact on the IPv6 Transition 423 The solution described in this document is applicable to Carrier 424 Grade NAT transition technologies (e.g. NAT444, DS-Lite, and NAT64). 425 As discussed in [I-D.donley-nat444-impacts], the authors acknowledge 426 that native IPv6 will offer subscribers a better experience than CGN. 427 However, many CPE devices only support IPv4. Likewise, as of July 428 2012, only approximately 4% of the top 1 million websites were 429 available using IPv6. Accordingly, deterministic CGN should in no 430 way be understood as making CGN a replacement for IPv6 service. The 431 authors encourage device manufacturers to consider [RFC6540] and 432 include IPv6 support. In the interim, however, CGN has already been 433 deployed in some ISP networks. Deterministic CGN will provide ISPs 434 with the ability to quickly respond to public safety requests without 435 requiring excessive infrastructure, operations, and bandwidth to 436 support per-connection logging. 438 5. IANA Considerations 440 This document makes no request of IANA. 442 6. Security Considerations 444 The security considerations applicable to NAT operation for various 445 protocols as documented in, for example, RFC 4787 [RFC4787] and RFC 446 5382 [RFC5382] also apply to this document. 448 7. Acknowledgements 450 The authors would like to thank the following people for their 451 feedback: Bobby Flaim, Lee Howard, Wes George, Jean-Francois 452 Tremblay, Mohammed Boucadair, Alain Durand, David Miles, Andy Anchev. 454 8. References 456 8.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 462 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 463 RFC 4787, January 2007. 465 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 466 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 467 RFC 5382, October 2008. 469 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 470 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 471 June 2011. 473 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 474 Roberts, "Issues with IP Address Sharing", RFC 6269, 475 June 2011. 477 8.2. Informative References 479 [I-D.donley-nat444-impacts] 480 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 481 Colorado, "Assessing the Impact of Carrier-Grade NAT on 482 Network Applications", draft-donley-nat444-impacts-04 483 (work in progress), May 2012. 485 [I-D.ietf-pcp-base] 486 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 487 Selkirk, "Port Control Protocol (PCP)", 488 draft-ietf-pcp-base-25 (work in progress), May 2012. 490 [I-D.miles-behave-l2nat] 491 Miles, D. and M. Townsley, "Layer2-Aware NAT", 492 draft-miles-behave-l2nat-00 (work in progress), 493 March 2009. 495 [I-D.shirasaki-nat444] 496 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 497 and H. Ashida, "NAT444", draft-shirasaki-nat444-05 (work 498 in progress), January 2012. 500 [I-D.tsou-behave-natx4-log-reduction] 501 ZOU), T., Li, W., and T. Taylor, "Port Management To 502 Reduce Logging In Large-Scale NATs", 503 draft-tsou-behave-natx4-log-reduction-02 (work in 504 progress), September 2010. 506 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 507 Protocol Port Randomization", BCP 156, RFC 6056, 508 January 2011. 510 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 511 NAT64: Network Address and Protocol Translation from IPv6 512 Clients to IPv4 Servers", RFC 6146, April 2011. 514 [RFC6292] Hoffman, P., "Requirements for a Working Group Charter 515 Tool", RFC 6292, June 2011. 517 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 518 Stack Lite Broadband Deployments Following IPv4 519 Exhaustion", RFC 6333, August 2011. 521 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 522 Cheshire, "Internet Assigned Numbers Authority (IANA) 523 Procedures for the Management of the Service Name and 524 Transport Protocol Port Number Registry", BCP 165, 525 RFC 6335, August 2011. 527 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 528 T. Tsou, "Huawei Port Range Configuration Options for PPP 529 IP Control Protocol (IPCP)", RFC 6431, November 2011. 531 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 532 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 533 RFC 6540, April 2012. 535 Authors' Addresses 537 Chris Donley 538 CableLabs 539 858 Coal Creek Cir 540 Louisville, CO 80027 541 US 543 Email: c.donley@cablelabs.com 545 Chris Grundemann 546 CableLabs 547 858 Coal Creek Cir 548 Louisville, CO 80027 549 US 551 Email: c.grundemann@cablelabs.com 552 Vikas Sarawat 553 CableLabs 554 858 Coal Creek Cir 555 Louisville, CO 80027 556 US 558 Email: v.sarawat@cablelabs.com 560 Karthik Sundaresan 561 CableLabs 562 858 Coal Creek Cir 563 Louisville, CO 80027 564 US 566 Email: k.sundaresan@cablelabs.com