idnits 2.17.1 draft-chen-sunset4-cgn-port-allocation-03.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 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3719 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.penno-behave-rfc4787-5382-5508-bis' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'I-D.tsou-behave-natx4-log-reduction' is defined on line 588, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-07 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-04 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-07 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-05 == Outdated reference: A later version (-06) exists of draft-tsou-behave-natx4-log-reduction-04 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft China Mobile 4 Intended status: Informational T. Tsou 5 Expires: August 17, 2014 Huawei Technologies (USA) 6 C. Donley 7 CableLabs 8 T. Taylor 9 Huawei Technologies 10 February 13, 2014 12 Analysis of NAT64 Port Allocation Method 13 draft-chen-sunset4-cgn-port-allocation-03 15 Abstract 17 The document enumerated methods of port assignment in CGN contexts, 18 more focused on NAT64 environments. The analysis categorized the 19 different methods with several key features. The uses of existing 20 protocols are described corresponding to those features. The 21 document also shared the port-usage experiences, relevant findings, 22 evaluations and workarounds. It's expected the document could 23 provide a informative base line to help operators choosing a proper 24 method. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 17, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Port Consumption on NAT64 . . . . . . . . . . . . . . . . . . 3 62 3. Port Allocation Category . . . . . . . . . . . . . . . . . . 4 63 3.1. NAT vs NAPT . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Dynamic vs Static . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Centralized vs Distributed . . . . . . . . . . . . . . . 6 66 4. Port Allocation Solutions . . . . . . . . . . . . . . . . . . 6 67 4.1. Deterministic CGN . . . . . . . . . . . . . . . . . . . . 6 68 4.2. MAP-T and 4rd . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4. Dynamic Port Allocation . . . . . . . . . . . . . . . . . 8 71 5. Specific Considerations . . . . . . . . . . . . . . . . . . . 8 72 5.1. Log Volume Optimization . . . . . . . . . . . . . . . . . 9 73 5.2. Connectivity State Optimization . . . . . . . . . . . . . 10 74 5.3. Port Randomization . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 8.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 With the depletion of IPv4 address, CGN has been adopted by ISPs to 85 expand IPv4 spaces. Relying upon the mechanism of multiplexing 86 multiple subscribers' connections over a smaller number of shared 87 IPv4 addresses, CGN mapped IP addresses from one address realm to 88 another, providing transparent routing to end hosts. 89 [I-D.ietf-behave-lsn-requirements] defined the term of CGN. Several 90 proposals including DS-Lite[RFC6333], NAT64[RFC6145], [RFC6146], 91 NAT444 would likely fall into the scope. Focusing on the topic of 92 IPv6 migration, the memo elaborate the considerations in NAT64 93 environment, where there IPv6-only nodes are connected. 95 In regards to port allocations on NAT64, several aspects may have to 96 consider in order to deploy a suitable method. The below enumerates 97 the potential considerations. 99 o Specific features of port-usage in a NAT64 environment 101 o The category of different port-allocations methods 103 o The port allocation method to improve connectivity 105 o The port allocation method to optimize log volume 107 o The port allocation method to enhance security 109 The document trying to detail the analysis and relevant experiences. 111 2. Port Consumption on NAT64 113 With the merits of simplicity and efficiency, NAT64 will be likely 114 deployed. In those cases, NAT64 would enable internal IPv6-only 115 hosts to connect to external dual-stack networks. Compared with 116 NAT44, fewer ports consumed on NAT64. The reason for the fewer port 117 consumption is NAT64 are deployed to provide connectivity from one 118 address family to another. Only flows between different address 119 families require ports to be assigned. That is, a NAT44 might be 120 deployed in an IPv4-only environment. Since all traffic will have to 121 traverse the NAT, all flows will need ports. Conversely, NAT64 only 122 requires a port when one end is IPv4-only. Therefore, the more hosts 123 support IPv6, the fewer ports are needed on the NAT64. 125 There was a testing on the comparison of port consumption on NAT64 126 and NAT44. Top100 websites (referring to Alexa statistics) were 127 being assessed to evaluate status of port usage on NAT44 and NAT64 128 respectively. It's observed that the port consumption on NAT64 is 129 roughly only half on NAT44. 43 percent of top100 websites have AAAA 130 records, therefore the NAT64 didn't have to assign ports to the 131 traffic going to those websites. The results may be different if 132 more services (e.g. game, web-mail, etc) are considered. Whereas, 133 it's apparent the effects of port saving on NAT64 could be amplified 134 by increasing native IPv6 supports. 136 Apart from above, the port allocation can be tuned corresponding to 137 the phase of IPv6 migration. The use of NAT64 would advance IPv6, 138 because it provides everyone incentives to use IPv6, and eventually 139 the result is an end-to-end IPv6-only networks with no needs for port 140 allocations. As more content providers and service are available 141 over IPv6, the utilization on NAT64 goes down since fewer 142 destinations require translation progressing. In the trend of IPv6 143 migration, NAT64 may relax the multiplexing ratio of shared IPv4 144 address by either a delivered message or a centralized control. 146 3. Port Allocation Category 148 This section lists several methods to allocate the port information 149 in NAT64 equipments. It also described exemplified cases for each 150 allocation model. 152 3.1. NAT vs NAPT 154 NAT64 may not do Network Address Port Translation (NAPT), but only 155 Network Address Translation (NAT). In those cases, there is no 156 concern about port assignment. Some existing practices are listed 157 below from two aspects. 159 o Stateful 161 The stateful NAT can be implemented either by static address 162 translation or dynamic address translation. 164 In the case of static address assignment, one-to-one address mapping 165 for hosts between a IPv6 network address and an IPv4 network address 166 would be pre-configured on the NAT operation. Those cases normally 167 occurred when a server deployed in a IPv6 domain. The static 168 configuration ensure the stable inbound connectivity. 170 Dynamic address assignment would periodically free the binding so 171 that the global address could be recycled for later uses. Addresses 172 could be more efficiently used by a time-division manner. 174 o Stateless 176 The stateless NAT is performed in compliant with [RFC6145]. Public 177 IPv4 address is required to be inserted in IPv6 address. Therefore, 178 NAT64 could directly extract the address and no need to record 179 mapping states. A promising usage of stateless could be appeared in 180 IDC environment where there is IPv6 servers pools to receive inbound 181 connections from IPv4 users externally[I-D.anderson-siit-dc]. The 182 uses in other cases may be controversial. First off, the static one- 183 to-one mapping may didn't address the issue of IPv4 depletion. 184 Secondly, it introduced the dependency of IPv4/IPv6. That would 185 create new limitations since the change of IPv4 address would cause 186 renumbering of IPv6 addresses. 188 3.2. Dynamic vs Static 190 When the cases come to port assignment, there are two methods on port 191 allocations. 193 o Dynamic assignment 195 NAT64 normally do the dynamic assignment, since maximum port 196 utilizations could be achieved. In respect to port allocations, it 197 could be allocated with the granularity of per-session or per- 198 customer. Per-session assignment basically configured on NAT64 by 199 default for efficient port utilizations. However, a heavy log volume 200 may have to be recorded for lawful interception system. In order to 201 mitigate the concerns, NAT64 could dynamically allocate a port range 202 for each connected subscriber on-demand. It would significantly 203 reduce log volume. A proper port-range configuration may have to 204 consider two-folds. 206 a. The number of session initiations for each subscriber. A 207 subscriber normally uses multiple applications simultaneously, 208 e.g. map, online video or game. The number of concurrent 209 sessions are essential to determine the space of port range. It 210 has been learned from subscriber's behaviors that the average 211 session's number of a user's device is around 200~300 ports. 212 Several devices maybe appeared behind a CPE. Administors may 213 configure a range with 1000 ports to each CPE in fixed networks. 215 b. Impacts to NAT64 capacity. The preassigned port ranges occupy 216 the memory even there are unused ports. Therefore, it should be 217 cautious the impacts of port-range reservation to the capacity of 218 attempted concurrent sessions, especially in the case of NAT64 219 CGN served a centralized point to numerous subscribes. 221 o Static assignment 223 The static assignment makes a bulk of port reservations for each 224 internal address before subscriber's connection. The bulk of ports 225 could be either a contiguous or non-contiguous port range for the 226 sake of attack defense. [I-D.donley-behave-deterministic-cgn]has 227 described a deterministic NAT to assign a port range for internal IP 228 address pool in a sequence. The difference of the static method with 229 dynamic port-range is address/ports mappings have been established 230 before subscriber's connectivity attempts. Log recording may not be 231 necessary due to the stable mapping relations. The considerations of 232 port-range allocation and capacity impacts could also be applied to 233 the case of static assignment. 235 3.3. Centralized vs Distributed 237 There are increasing needs to connect NAT64 with downstream 238 NAT46-capable devices to support IPv4 users/applications on a 239 IPv6-only path. Several solutions have been proposed in this area, 240 e.g. 464xlat[RFC6877], MAP-T[I-D.ietf-softwire-map-t] and 241 4rd[I-D.ietf-softwire-4rd]. With the feature of double-translation, 242 the port allocation can be categorized as a centralized assignment on 243 NAT64 or a port delegation distributed to downstream devices (e.g, CE 244 connected with NAT64) . 246 o Centralized Assignment 248 A centralized method would make port assignments once IP flows come 249 to NAT64. The allocation policy is enforced on a centralized point. 250 Either a dynamic or static port assignment is made for received 251 sessions. 253 o Distributed Assignment 255 NAT64 could also delegate the pre-allocated port range to customer 256 edge devices. That can be achieved through additional out-band 257 provisioning signals(e.g. 258 ,[I-D.ietf-pcp-port-set][I-D.ietf-softwire-map-dhcp]). The 259 distributed model normally performed A+P style for static port 260 assignment. NAT64 should hold the corresponding mapping in 261 accordance with assigned ports. Those methods could shift NAT64 port 262 computations/states into downstream devices. The detailed benefits 263 was documented in [I-D.ietf-softwire-stateless-4v6-motivation]. 265 4. Port Allocation Solutions 267 4.1. Deterministic CGN 269 The deterministic port allocation has been described in 270 [I-D.donley-behave-deterministic-cgn].This algorithm allows an 271 operator to identify a subscriber internal IP address when provided 272 the public side IP and port number without having to examine the CGN 273 translation logs. Specific port allocation is determined by the 274 algorithm configured on the CGN. The following variables are 275 required to be configured: 277 o Inside IPv4/IPv6 address range (I); 279 o Outside IPv4 address range (O); 281 o Compression ratio (e.g. inside IP addresses I/outside IP addresses 282 O) (C); 284 o Dynamic address pool factor (D), to be added to the compression 285 ratio in order to create an overflow address pool; 287 o Maximum ports per user (M); 289 o Address assignment algorithm (A); 291 o Reserved TCP/UDP port list (R). 293 The reserved ports (R) from the port candidate list (e.g., 0-1023 for 294 TCP and UDP) can't be allocated to users. Deterministic port 295 allocation uses the compression ratio (C) to tune the available port 296 number allocated to per user. It also provides a method to allocate 297 the ports in a dynamic approach. The CGN calculates the total 298 compression ratio (C+D), and allocates 1/(C+D) of the available ports 299 to each internal IP address. Specific port allocation is determined 300 by the algorithm (A) configured on the CGN. Any remaining ports are 301 allocated to the dynamic pool, which offers a possibility to allocate 302 the extra ports when port resource is overused. The log information 303 generated from the dynamic pool must be recorded. 305 Address assignment algorithms are configured to regulate the port 306 assignment method to each subscriber. Subscribers could be 307 restricted to ports from a single IPv4 address, or could be allocated 308 ports across all addresses in a pool. The assigned ports could be 309 sequential, staggered, or cryptographically random. The CGN is not 310 required to support all algorithms. 312 4.2. MAP-T and 4rd 314 The MAP-T and 4rd are designed to allow the coordination between CPEs 315 and Border Relays (BR) to delegate a port segment to a CPE. A 316 mapping rules are pre-configured both on the CPEs and BRs in order to 317 derive the available port numbers from the delegated IPv6 prefix. 318 The port number is adjusted by the length of IPv4 prefix and EA-bits 319 and identified by Port-Set Identifier (PSID). Depending on the 320 mechanism, customer sites can be assigned shared public IPv4 321 addresses with restricted port sets. 323 Since the port segment is computed from delegated IPv6 prefix and 324 IPv4 prefix, it introduces the dependency between the IPv4 and IPv6. 325 The network planning should consider this restriction for the network 326 deployment. 328 4.3. PCP 330 Port Control Protocol can be used to reserve a single port[RFC6887] 331 or a port set[I-D.ietf-pcp-port-set] for applications. It requires 332 NAT is capable of PCP server. A set of port is retrieved through PCP 333 signaling. The port resource is managed by the lifetime indicated in 334 PCP request message. 336 4.4. Dynamic Port Allocation 338 In order to share the limited supply of IPv4 addresses available in 339 the network, the dynamic port allocation is a default behavior for a 340 stateful NAT64[RFC6146]. It will achieve maximum port multiplexing. 341 [I-D.tsou-behave-natx4-log-reduction]proposes a solution that allows 342 dynamic sharing of port ranges between users while minimizing the 343 number of logs that have to be generated. Briefly, ports are 344 allocated to the user in blocks. Logs are generated only when blocks 345 are allocated or deallocated. This provides the necessary 346 traceability while reducing log generation by a factor equal to the 347 block size, as compared with fully dynamic port allocation. 349 When the user sends out the first packet, a port resource pool is 350 allocated for the user, e.g., assigning ports 2001~2300 of a public 351 IP address to the user's resource pool. Only one log should be 352 generated for this port block. When the NAT needs to set up a new 353 mapping entry for the user, it can use a port in the user's resource 354 pool and the corresponding public IP address. If the user needs more 355 port resources, the NAT can allocate another port block, e.g., ports 356 3501~3800, to the user's resource pool. Again, just one log needs to 357 be generated for this port block. It can also take this idea further 358 by allocating non- contiguous sets of ports using a pseudorandom 359 function. Scattering the allocated ports in this way provides a 360 modest barrier to port guessing attacks. 362 The CGN can also remove the port block from the resource pool 363 allocated to a given internal address when there is no port used, and 364 make it available for other users. The timer for port block 365 deallocation is suggested to conform with the recommendations for NAT 366 behaviour for the protocol concerned, then the additional time that 367 might be configured as a guard for the block as a whole need not be 368 more than a few minutes. 370 5. Specific Considerations 371 5.1. Log Volume Optimization 373 [RFC6269] has provided a thoughtful analysis on the issues of IP 374 sharing. It pointed out that IP sharing may bring the impacts to law 375 enforcements since the information of source address would be lost 376 during the translation. Network administrators have to log the 377 mapping status for each connection in order to identify a specific 378 user associated with an IP address in a particular time slot. The 379 storage of log information may post a challenge to operators, since 380 it requires additional resources and data inspection process to 381 indentify users. It's desirable to compact the logging information. 382 Referring the categories of port allocation, the assignment could be 383 managed on either per-session or per-customer. The bigger 384 granularity would lead fewer log volume storage. A testing was made 385 to record the log information from 200,000 subscribers for 60 days. 386 The volume of recorded information reach up to 42.5 terabytes with 387 per-session log. Conversely, it only occupy 40.6 gigabytes with per- 388 customer log. There is even a method, which doesn't have to log any 389 information. 391 Whereas, high compression would cause low efficiency of port 392 utilization. A port allocation based on per-customer granularity 393 have to retain vacant ports in order to avoid traffic overflow. The 394 efficiency could be evaluated by port utilization rate. The 395 efficiency could be even lower if the method of static port 396 allocation is used. The ports were pre-allocated to customers 397 regardless online or offline status. Inactive users may also impact 398 the efficiency. The below table is trying to make a composite 399 analysis. 401 +-----------------+----------------- +-----------------+-------------------+ 402 |Type of log | Method of port | Log Volume(e.g. | Port utilization | 403 |records | allocations | 200,000 users | ratio | 404 | | | for 60 days) | | 405 +-----------------+---------------- -+-----------------+-------------------+ 406 |per-session |Dynamic NAPT | 43.5 Terabytes | 100% | 407 +-----------------+------------------+-----------------+-------------------| 408 |per-customer |Dynamic port-range| 40.6 Gigabytes | 75%(e.g.400 ports)| 409 +-----------------+------------------+-----------------+-------------------+ 410 |None Log |Deterministic NAT,| | 60% *75%= | 411 | |MAP,4rd | 0 | 45% | 412 +-----------------+------------------+-----------------+-------------------+ 413 Note:75% is evaluated for port utilization ratio. 414 60% is evaluated for the ratio of active subscribers. 416 The data shared in the table may roughly demonstrates the tradeoff 417 between port utilization and log volume compression. Administrator 418 may consider below factors to determine their own solution 419 o Average connectivity per customer per day 421 o Peak connectivity per day 423 o The amount of public IPv4 address in NAT64 425 o Application demands for specific ports 427 o The processing capabilities of NAT64 429 o The tolerance of log volume 431 5.2. Connectivity State Optimization 433 It's observed that port consumption would be significantly increased 434 once subscribers stick to a web page for VoD, online games or map 435 services. In those cases, multiple TCP connections may be initiated 436 to optimize the performance of data transmissions for video download 437 and message exchange. With the trends of the video traffic growth, 438 it likely presents a challenge for network operators that need to 439 optimize connectivity states and avoid port depletion. Those 440 optimizations may even be significant to the method of port-range 441 allocation, because a subscriber is only allowed to use a pre- 442 configured port resource. 444 The optimization could be considered from two aspects. 446 o Reducing the TIME-WAIT state. User's behavior normally correlates 447 with the system performance. It's rather common that users often 448 change video channels. It's investigated that 60% of video 449 watched for less than 20% of their duration. The user's access 450 patterns may leave a number of the TIME-WAIT states. Therefore, 451 acceleration of TIME-WAIT state transitions could increase the 452 efficiency of port utilization. RFC6191[RFC6191] define the 453 mechanism of reducing TIME-WAIT state by proposing TCP timestamps 454 and sequence numbers. 455 [I-D.penno-behave-rfc4787-5382-5508-bis]recommended applying 456 [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers 457 described in [RFC1323]) to NAT. It might a way to improve port 458 utilizations. 460 o Another consideration is using Address-Dependent Mapping or 461 Address and Port-Dependent Mapping[RFC4787] to increase the port 462 utilization. This feature has already been implemented as vendor- 463 specific features. Whereas, it should be noted that REQ-7, REQ-12 464 in[I-D.ietf-behave-lsn-requirements] may reduce the incent 466 5.3. Port Randomization 468 Port randomization is a feature to enhance the defense of hijack 469 flows. [RFC6056] specified that "A NAPT that does not implement port 470 preservation [RFC4787] ,[RFC5382] should obfuscate selection of the 471 ephemeral port of a packet when it is changed during translation of 472 that packet." A NAPT based on per-session normally follow the 473 recommendation. However, a simply algorithm on port assignment is 474 mostly desirable for a deterministic NAT even there is hijack 475 vulnerability. 477 6. Security Considerations 479 The non-contiguous port allocations could be considered to enhance 480 the security of port allocations. This document shares the 481 considerations in [RFC6056]. 483 7. IANA Considerations 485 This document makes no request of IANA. 487 8. References 489 8.1. Normative References 491 [I-D.ietf-softwire-map-dhcp] 492 Mrugalski, T., Troan, O., Dec, W., Bao, C., 493 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 494 for configuration of Softwire Address and Port Mapped 495 Clients", draft-ietf-softwire-map-dhcp-06 (work in 496 progress), November 2013. 498 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 499 for High Performance", RFC 1323, May 1992. 501 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 502 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 503 RFC 4787, January 2007. 505 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 506 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 507 RFC 5382, October 2008. 509 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 510 Protocol Port Randomization", BCP 156, RFC 6056, January 511 2011. 513 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 514 Algorithm", RFC 6145, April 2011. 516 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 517 NAT64: Network Address and Protocol Translation from IPv6 518 Clients to IPv4 Servers", RFC 6146, April 2011. 520 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 521 Timestamps", BCP 159, RFC 6191, April 2011. 523 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 524 Stack Lite Broadband Deployments Following IPv4 525 Exhaustion", RFC 6333, August 2011. 527 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 528 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 529 2013. 531 8.2. Informative References 533 [I-D.anderson-siit-dc] 534 Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data 535 Centre Environments", draft-anderson-siit-dc-00 (work in 536 progress), November 2012. 538 [I-D.donley-behave-deterministic-cgn] 539 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 540 and O. Vautrin, "Deterministic Address Mapping to Reduce 541 Logging in Carrier Grade NAT Deployments", draft-donley- 542 behave-deterministic-cgn-07 (work in progress), January 543 2014. 545 [I-D.ietf-behave-lsn-requirements] 546 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 547 and H. Ashida, "Common requirements for Carrier Grade NATs 548 (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in 549 progress), December 2012. 551 [I-D.ietf-pcp-port-set] 552 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 553 T., and S. Perreault, "Port Control Protocol (PCP) 554 Extension for Port Set Allocation", draft-ietf-pcp-port- 555 set-04 (work in progress), November 2013. 557 [I-D.ietf-pcp-port-set] 558 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 559 T., and S. Perreault, "Port Control Protocol (PCP) 560 Extension for Port Set Allocation", draft-ietf-pcp-port- 561 set-04 (work in progress), November 2013. 563 [I-D.ietf-softwire-4rd] 564 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 565 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 566 Solution (4rd)", draft-ietf-softwire-4rd-07 (work in 567 progress), October 2013. 569 [I-D.ietf-softwire-map-t] 570 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 571 T. Murakami, "Mapping of Address and Port using 572 Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work 573 in progress), February 2014. 575 [I-D.ietf-softwire-stateless-4v6-motivation] 576 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 577 Borges, I., and G. Chen, "Motivations for Carrier-side 578 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 579 softwire-stateless-4v6-motivation-05 (work in progress), 580 November 2012. 582 [I-D.penno-behave-rfc4787-5382-5508-bis] 583 Penno, R., Perreault, S., Kamiset, S., Boucadair, M., and 584 K. Naito, "Network Address Translation (NAT) Behavioral 585 Requirements Updates", draft-penno-behave- 586 rfc4787-5382-5508-bis-04 (work in progress), January 2013. 588 [I-D.tsou-behave-natx4-log-reduction] 589 Tsou, T., Li, W., Taylor, T., and J. Huang, "Port 590 Management To Reduce Logging In Large-Scale NATs", draft- 591 tsou-behave-natx4-log-reduction-04 (work in progress), 592 July 2013. 594 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 595 Roberts, "Issues with IP Address Sharing", RFC 6269, June 596 2011. 598 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 599 Combination of Stateful and Stateless Translation", RFC 600 6877, April 2013. 602 Authors' Addresses 604 Gang Chen 605 China Mobile 606 53A,Xibianmennei Ave., 607 Xuanwu District, 608 Beijing 100053 609 China 611 Email: phdgang@gmail.com 613 Tina Tsou 614 Huawei Technologies (USA) 615 2330 Central Expressway 616 Santa Clara, CA 95050 617 USA 619 Phone: +1 408 330 4424 620 Email: tina.tsou.zouting@huawei.com 622 Chris Donley 623 CableLabs 624 858 Coal Creek Cir 625 Louisville, CO 80027 626 US 628 Email: c.donley@cablelabs.com 630 Tom Taylor 631 Huawei Technologies 632 Ottawa 633 Canada 635 Email: tom.taylor.stds@gmail.com