idnits 2.17.1 draft-ietf-softwire-stateless-4v6-motivation-00.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 : ---------------------------------------------------------------------------- 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 date (September 9, 2011) is 4612 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft France Telecom 4 Intended status: Informational S. Matsushima 5 Expires: March 12, 2012 Softbank Telecom 6 Y. Lee 7 Comcast 8 O. Bonness 9 Deutsche Telekom 10 I. Borges 11 Portugal Telecom 12 G. Chen 13 China Mobile 14 September 9, 2011 16 Motivations for Stateless IPv4 over IPv6 Migration Solutions 17 draft-ietf-softwire-stateless-4v6-motivation-00 19 Abstract 21 IPv4 service continuity is one of the most pressing problems that 22 must be resolved by Service Providers during the IPv6 transition 23 period -especially after the exhaustion of the public IPv4 address 24 space. Current standardization effort that addresses IPv4 service 25 continuity focuses on stateful mechanisms. This document elaborates 26 on the motivations for the need to undertake a companion effort to 27 specify stateless IPv4 over IPv6 approaches. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 12, 2012. 46 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Why Stateless IPv4 over IPv6 Solutions are Needed? . . . . . . 4 65 3.1. Network Architecture Simplification . . . . . . . . . . . 5 66 3.1.1. Network Dimensioning . . . . . . . . . . . . . . . . . 5 67 3.1.2. No Intra-domain Constraint . . . . . . . . . . . . . . 5 68 3.1.3. Logging - No Need for Dynamic Binding Notifications . 6 69 3.1.4. No Additional Protocol for Port Control is Required . 6 70 3.2. Operational Tasks and Network Maintenance Efficiency . . . 6 71 3.2.1. Preserve Current Practices . . . . . . . . . . . . . . 7 72 3.2.2. Planned Maintenance Operations . . . . . . . . . . . . 7 73 3.2.3. Reliability and Robustness . . . . . . . . . . . . . . 7 74 3.2.4. Support of Multi-Vendor Redundancy . . . . . . . . . . 7 75 3.2.5. Simplification of Qualification Procedures . . . . . . 8 76 3.3. Facilitating Service Evolution . . . . . . . . . . . . . . 8 77 3.3.1. Implicit Host Identification . . . . . . . . . . . . . 8 78 3.3.2. No Organizational Impact . . . . . . . . . . . . . . . 9 79 3.4. Cost Minimization Opportunities . . . . . . . . . . . . . 9 80 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.1. Dependency Between IPv4 and IPv6 Address Assignments . . . 11 82 4.2. IPv4 Port Utilisation Efficiency . . . . . . . . . . . . . 11 83 4.3. IPv4 Port Randomization . . . . . . . . . . . . . . . . . 12 84 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 89 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 When the global IPv4 address space is exhausted, Service Providers 95 will be left with an address pool that cannot be increased anymore. 96 Many services and network scenarios will be impacted by the lack of 97 IPv4 public addresses. Providing access to the (still limited) IPv6 98 Internet only won't be sufficient to address the needs of customers, 99 as most of them will continue to access legacy IPv4-only services. 100 Service Providers must guarantee their customers that they can still 101 access IPv4 contents although they will not be provisioned with a 102 global IPv4 address anymore. Means to share IPv4 public addresses 103 are unavoidable [RFC6269]. 105 Identifying the most appropriate solution(s) to the IPv4 address 106 exhaustion as well as IPv4 service continuity problems and deploying 107 them in a real network with real customers is a very challenging and 108 complex process for all Service Providers. There is nothing like a 109 "One size fits all" solution or one target architecture that would 110 work for all situations. Each Service Provider has to take into 111 account its own context (e.g., service infrastructures), policies and 112 marketing strategy (a document that informs Service Providers about 113 the impact of the IPv4 address shortage, and provides some 114 recommendations and guidelines, is available at [EURESCOM]). 116 Current standardization effort that is meant to address this IPv4 117 service continuity issue focuses mainly on stateful mechanisms that 118 assume the sharing of any global IPv4 address that is left between 119 several customers, based upon the deployment of NAT (Network Address 120 Translation) capabilities in the network. Because of some caveats of 121 such stateful approaches the Service Provider community feels that a 122 companion effort is required to specify stateless IPv4 over IPv6 123 approaches. This document provides elaboration on such need. 125 More discussions about stateless vs. stateful can be found at 126 [RFC6144]. 128 2. Terminology 130 This document makes use of the following terms: 132 State: as used in [RFC1958]. 134 Session state: refers to an information state as defined in 135 Section 2.3 of [RFC2663]. In particular, it 136 refers to the state maintained by the NAT so that 137 datagrams pertaining to a session are routed to 138 the right node. Note, TCP/UDP sessions are 139 uniquely identified by the tuple of (source IP 140 address, source TCP/UDP port, target IP address, 141 target TCP/UDP port) while ICMP query sessions 142 are identified by the tuple of (source IP 143 address, ICMP query ID, target IP address). 145 User-session state: refers to session state belonging to a given 146 user. 148 Stateful 4/6 solution (or stateful solution in short): denotes a 149 solution where the network maintains user-session 150 states relying on the activation of a NAT 151 function in the Service Providers' network 152 [I-D.ietf-behave-lsn-requirements]. The NAT 153 function is responsible for sharing the same IPv4 154 address among several subscribers and to maintain 155 user-session state. 157 Stateless 4/6 solution (or stateless solution in short): denotes a 158 solution which does not require any per-user 159 state (see Section 2.3 of [RFC1958]) to be 160 maintained by any IP address sharing function in 161 the Service Provider's network. This category of 162 solutions assumes a dependency between an IPv6 163 prefix and IPv4 address. In an IPv4 address 164 sharing context, dedicated functions are required 165 to be enabled in the CPE router to restrict the 166 source IPv4 port numbers. Within this document, 167 "port set" and "port range" terms are used 168 interchangeably. 170 3. Why Stateless IPv4 over IPv6 Solutions are Needed? 172 Below is provided a list of motivations which justify the need for a 173 stateless solution (in no particular order): 174 (1) Minimizes impact on OSS and logging systems. Ideally, it does 175 not require OSS & logging systems that wouldn't be there in a 176 pure IPv6 network. 177 (2) Does not require maintaining per-subscriber configuration on 178 active data plane network elements. 179 (3) Scales in terms of IP forwarding capacity, rather than amount 180 of dynamic state, or new session creation rate. 181 (4) Support a single architecture that allows 1:1 or N:1 (port 182 range) NAT44 usage without additional extensions. 184 (5) Preserves current engineering practices (e.g., anycast-based 185 load-balancing) 186 (6) Relies on IPv6 and supports transition to an IPv6-only network. 187 (7) Supports asymmetric routing to/from the IPv4 Internet. 188 (8) Maximizes the ease of deployment and redundancy of nodes. 189 (9) Readily supports a multi vendor environment (including 190 redundancy). 191 (10) Allows direct user-user traffic flows (i.e., allows for no- 192 tromboning) 193 (11) Retains today's user experience (NAT on CPE) and supports 194 today's operational model. 195 (12) Does not require deployment of (additional) dynamic signaling 196 protocols to the end-user CPE beyond those already used. 197 (13) Minimizes required non-regression testing effort. 198 (14) Does not require organizational changes. 199 (15) Assumes a clear separation between the service and the network 200 layer and therefore there is no interference between delivered 201 services and underlying network transfer capabilities. 203 This section elaborates further on the aforementioned motivations. 205 The technical and operational benefits of the stateless solutions are 206 possible because no per-user state [RFC1958] is maintained in the 207 Service Providers networks. 209 3.1. Network Architecture Simplification 211 The activation of the stateless function in the Service Provider's 212 network does not introduce any major constraint on the network 213 architecture and its engineering. The following sub-sections 214 elaborate on these aspects. 216 3.1.1. Network Dimensioning 218 Because no per-user state [RFC1958] is required, a stateless solution 219 does not need to take into account the maximum number of simultaneous 220 user-sessions and the maximum number of new user-sessions per second 221 to dimension its networking equipment. Like current network 222 dimensioning practices, only considerations related to the customer 223 number, traffic trends and the bandwidth usage need be taken into 224 account for dimensioning purposes. 226 3.1.2. No Intra-domain Constraint 228 Stateless IPv4/IPv6 interconnection functions can be ideally located 229 at the boundaries of an Autonomous System (e.g., ASBR routers that 230 peer with external IPv4 domains); in such case: 232 Intra-domain paths are not altered: there is no need to force IP 233 packets to cross a given node for instance; intra-domain routing 234 processes are not tweaked to direct the traffic to dedicated 235 nodes. In particular, stateless solutions optimize CPE-to-CPE 236 communication in that packets don't go through the interconnection 237 function since the address and port mapping has been realized 238 based on a well defined mapping schema that is known to all 239 involved devices. 241 3.1.3. Logging - No Need for Dynamic Binding Notifications 243 Network abuse reporting requires traceability [RFC6269]. To provide 244 such traceability, prior to IPv4 address sharing, logging the IPv4 245 address assigned to a user was sufficient and generates relatively 246 small logs. The advent of stateful IPv4 address allows dynamic port 247 assignment, which then requires port assignment logging. This 248 logging of port assignments can be considerable. 250 In contrast, static port assignments do not require such considerable 251 logging. The volume of the logging file may not be seen as an 252 important criterion for privileging a stateless approach because 253 stateful approaches can also be configured (or designed) to assign 254 port ranges and therefore lead to acceptable log volumes. 256 If a dynamic port assignment mode is used, dedicated interfaces and 257 protocols must be supported to forward binding data records towards 258 dedicated platforms. The activation of these dynamic notifications 259 may impact the performance of the dedicated device. For stateless 260 solutions, there is no need for dynamic procedures (e.g., using 261 SYSLOG) to notify a mediation platform about assigned bindings. 263 Some Service Providers have a requirement to use only existing 264 logging systems and to avoid introducing new ones (mainly because of 265 CAPEX considerations). This requirement is easily met with stateless 266 solutions. 268 3.1.4. No Additional Protocol for Port Control is Required 270 The deployment of stateless solution does not require the deployment 271 of new dynamic signaling protocols to the end-user CPE in addition to 272 those already used. In particular, existing protocols (e.g., UPnP 273 IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. 275 3.2. Operational Tasks and Network Maintenance Efficiency 276 3.2.1. Preserve Current Practices 278 Service Providers require as much as possible to preserve the same 279 operations as for current IP networking environments. 281 If stateless solutions are deployed, common practices are preserved. 282 In particular, the maintenance and operation of the network do not 283 require any additional constraints such as: path optimization 284 practices, enforcing traffic engineering policies, issues related to 285 traffic oscillation between stateful devices, load-balancing the 286 traffic or load sharing the traffic among egress/ingress points can 287 be used, etc. In particular: 289 o anycast-based schemes can be used for load-balancing and 290 redundancy purposes. 292 o asymmetric routing to/from the IPv4 Internet is natively supported 293 and no path-pinning mechanisms have to be additionally 294 implemented. 296 3.2.2. Planned Maintenance Operations 298 Since no state is maintained by stateless IPv4/IPv6 interconnection 299 nodes, no additional constraint needs to be taken into account when 300 upgrading these nodes (e.g., adding a new service card, upgrading 301 hardware, periodic reboot of the devices, etc.). In particular, 302 current practices that are enforced to (gracefully) reboot or to 303 shutdown routers can be maintained. 305 3.2.3. Reliability and Robustness 307 Compared to current practices (i.e., without a CGN in place), no 308 additional capabilities are required to ensure reliability and 309 robustness in the context of stateless solutions. Since no state is 310 maintained in the Service Provider's network, state synchronization 311 procedures are not required. 313 High availability (including failure recovery) is ensured owing to 314 best current practices in the field. 316 3.2.4. Support of Multi-Vendor Redundancy 318 Deploying stateful techniques, especially when used in the Service 319 Providers networks, constrain severely deploying multi-vendor 320 redundancy since very often proprietary vendor-specific protocols are 321 used to synchronize state. This is not an issue for the stateless 322 case. Concretely, the activation of the stateless IPv4/IPv6 323 interconnection function does not prevent nor complicate deploying 324 devices from different vendors. 326 This criterion is very important for Service Providers having a 327 sourcing policy to avoid mono-vendor deployments and to operate 328 highly-available networks composed on multi-vendors equipment. 330 3.2.5. Simplification of Qualification Procedures 332 The introduction of new functions and nodes into operational networks 333 follows strict procedures elaborated by Service Providers. These 334 procedures include in-lab testing and field trials. Because of their 335 nature, stateless implementations optimize testing times and 336 procedures: 338 o The specification of test suites to be conducted should be 339 shorter; 341 o The required testing resources (in terms of manpower) are likely 342 to be less solicited that they are for stateful approaches. 344 One of the privileged approaches to integrate stateless IPv4/IPv6 345 interconnection function consists in embedding stateless capabilities 346 in existing operational nodes (e.g., IP router). In this case, any 347 software or hardware update would require to execute non-regression 348 testing activities. In the context of the stateless solutions, the 349 non-regression testing load due to an update of the stateless code is 350 expected to be minimal. 352 For the stateless case, testing effort and non-regression testing are 353 to be taken into account for the CPE side. This effort is likely to 354 be lightweight compared to the testing effort, including the non- 355 regression testing, of a stateful function which is co-located with 356 other routing functions for instance. 358 3.3. Facilitating Service Evolution 360 3.3.1. Implicit Host Identification 362 Service Providers do not offer only IP connectivity services but also 363 added value services (a.k.a., internal services). Upgrading these 364 services to be IPv6-enabled is not sufficient because of legacy 365 devices. In some deployments, the delivery of these added-value 366 services relies on implicit identification mechanism based on the 367 source IPv4 address. Due to address sharing, implicit identification 368 will fail [RFC6269]; replacing implicit identification with explicit 369 authentication will be seen as a non acceptable service regression by 370 the end users (less Quality of Experience (QoE)). 372 When a stateless solution is deployed, implicit identification for 373 internal services is likely to be easier to implement: the implicit 374 identification should be updated to take into account the port range 375 and the IPv4 address. Techniques as those analyzed in 376 [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the 377 delivery of these internal services if a stateless solution is 378 deployed. 380 Note stateful approaches configured to assign port ranges allows also 381 to support implicit host identification. 383 3.3.2. No Organizational Impact 385 Stateless solutions adopts a clear separation between the IP/ 386 transport layers and the service layers; no service interference is 387 to be observed when a stateless solution is deployed. This clear 388 separation: 390 Facilitates service evolution: Since the payload of IPv4 packets is 391 not altered in the path, services can evolve without requiring any 392 specific function (e.g., Application Level Gateway (ALG)) in the 393 Service Provider's network; 395 Limits vendor dependency: The upgrade of value-added services does 396 not involve any particular action from vendors that provide 397 devices embedding the stateless IPv4/IPv6 interconnection 398 function. 400 No service-related skills are required for network operators who 401 manage devices that embed the IPv4/IPv6 interconnection function: IP 402 teams can be in charge of these devices; there is a priori no need 403 to create a dedicated team to manage and to operate devices 404 embedding the stateless IPv4/IPv6 interconnection function. The 405 introduction of stateless capabilities in the network are unlikely 406 to degrade management costs. 408 3.4. Cost Minimization Opportunities 410 To make decision for which solution is to be adopted, service 411 providers usually undertake comparative studies about viable 412 technical solutions. It is not only about technical aspects but also 413 economical optimization (both CAPEX and OPEX considerations). 415 From a Service Provider perspective, stateless solutions are more 416 attractive because they do less impact the current network operations 417 and maintenance model that is widely based on stateless approaches. 418 Table 1 shows the general correspondence between technical benefits 419 and potential economic reduction opportunities. 421 While not all Service Providers environments are the same, a detailed 422 case study from one Service Provider 423 [I-D.matsushima-v6ops-transition-experience] reports that stateless 424 transition solutions can be considerably less expensive than stateful 425 transition solutions. 427 +---------------+--------------------------------------+------------+ 428 | Section | Technical and Operation Benefit | Cost Area | 429 +---------------+--------------------------------------+------------+ 430 | Section 3.1.1 | Network dimensioning | Network | 431 +---------------+--------------------------------------+------------+ 432 | Section 3.1.2 | No Intra-domain constraint | Network | 433 +---------------+--------------------------------------+------------+ 434 | Section 3.1.3 | Logging | Network & | 435 | | | Ops | 436 +---------------+--------------------------------------+------------+ 437 | Section 3.1.4 | No additional control protocol | Network | 438 +---------------+--------------------------------------+------------+ 439 | Section 3.2.1 | Preserve current practices | Ops | 440 +---------------+--------------------------------------+------------+ 441 | Section 3.2.2 | Planned maintenance | Ops | 442 +---------------+--------------------------------------+------------+ 443 | Section 3.2.3 | Reliability and robustness | Network & | 444 | | | Ops | 445 +---------------+--------------------------------------+------------+ 446 | Section 3.2.4 | Multi-Vendor Redundancy | Network | 447 +---------------+--------------------------------------+------------+ 448 | Section 3.2.5 | Simple qualification | Ops | 449 +---------------+--------------------------------------+------------+ 450 | Section 3.3.1 | Implicit Host Identification for | Ops | 451 | | internal services | | 452 +---------------+--------------------------------------+------------+ 453 | Section 3.3.2 | Organizational Impact | Ops | 454 +---------------+--------------------------------------+------------+ 456 Table 1: Cost minimization considerations 458 4. Discussion 460 Issues common to all address sharing solutions are documented in 461 [RFC6269]. The following sub-sections enumerates some open questions 462 for a CPE-based stateless solution. There are no universal answers 463 to these open questions since each Service Provider has its own 464 constraints (e.g., available address pool, address sharing ratio, 465 etc.). 467 4.1. Dependency Between IPv4 and IPv6 Address Assignments 469 Complete stateless mapping implies that the IPv4 address and the 470 significant bits that are used to encode the set of assigned ports 471 can be retrieved from the IPv6 prefix assigned to the CPE. This 472 requirement can be addressed by either using the IPv6 prefix also 473 used to forward IPv6 traffic natively, or allocating two prefixes to 474 the CPE (one that will be used to forward IPv6 traffic natively, and 475 the other one to forward IPv4 traffic). 477 o Providing two IPv6 prefixes avoids the complexity that may be 478 related to the adaptation of the IPv6 addressing scheme to the 479 IPv4 addressing scheme. The drawback is the need to allocate two 480 prefixes instead of one to each CPE and to announce them 481 accordingly, possibly at the cost of jeopardizing the routing and 482 forwarding efficiencies. 484 o The use of a single prefix to cover both the forwarding of IPv6 485 and IPv4-in-IPv6 traffic avoids the need to maintain a double 486 information (e.g., for customer identification and management 487 purposes and for forwarding table maintenance purposes). This 488 scheme somewhat links strongly the IPv4 addressing scheme to the 489 allocated IPv6 prefixes. For Service Providers requiring to apply 490 specific policies on per Address-Family (e.g., IPv4, IPv6), some 491 provisioning tools (e.g., DHCPv6 option) may be required to derive 492 in a deterministic way the IPv6 address to be used for the IPv4 493 traffic based on the IPv6 prefix delegated to the home network. 495 4.2. IPv4 Port Utilisation Efficiency 497 CGN-based solutions, because they can dynamically assign ports, 498 provide better IPv4 address sharing ratio than stateless solutions 499 (i.e., can share the same IP address among a larger number of 500 customers). For Service Providers who desire an aggressive IPv4 501 address sharing, a CGN-based solution is more suitable than the 502 stateless. However 504 1: When port overloading is used, some applications are likely to be 505 broken. 507 2: in case a CGN pre-allocates port ranges, for instance to 508 alleviate traceability complexity (see Section 3.1.3) it also 509 reduces its port utilization efficiency. 511 4.3. IPv4 Port Randomization 513 Preserving port randomization [RFC6056] may be more or less difficult 514 depending on the address sharing ratio (i.e., the size of the port 515 space assigned to a CPE). Port randomization may be more difficult 516 to achieve with a stateless solution than stateful solution. The CPE 517 can only randomize the ports inside a fixed port range. 519 More discussion to improve the robustness of TCP against Blind In- 520 Window Attacks can be found at [RFC5961]. 522 Other means than the (IPv4) source port randomization to provide 523 protection against attacks should be used (e.g., use 524 [I-D.vixie-dnsext-dns0x20] to protect against DNS attacks, [RFC5961] 525 to improve the robustness of TCP against Blind In-Window Attacks, use 526 IPv6). 528 5. Conclusion 530 As discussed in Section 3, stateless solutions provide several 531 interesting features. Trade-off between the positive vs. negative 532 aspects of stateless solutions is left to Service Providers. Each 533 Service Provider will have to select the appropriate solution 534 (stateless, stateful or even both) meeting its requirements. 536 This document recommends to undertake as soon as possible the 537 appropriate standardization effort to specify a stateless IPv4 over 538 IPv6 solution. 540 6. IANA Considerations 542 No action is required from IANA. 544 7. Security Considerations 546 Except for the less efficient port randomization of and routing loops 547 [RFC6324], stateless 4/6 solutions are expected to introduce no more 548 security vulnerabilities than stateful ones. Because of their 549 stateless nature, they may in addition reduce denial of service 550 opportunities. 552 8. Contributors 554 The following individuals have contributed to this document: 556 Christian Jacquenet 557 France Telecom 559 Email: christian.jacquenet@orange-ftgroup.com 561 Pierre Levis 562 France Telecom 564 Email: pierre.levis@orange-ftgroup.com 566 Masato Yamanishi 567 SoftBank BB 569 Email: myamanis@bb.softbank.co.jp 571 Yuji Yamazaki 572 Softbank Mobile 574 Email: yuyamaza@bb.softbank.co.jp 576 Hui Deng 577 China Mobile 578 53A,Xibianmennei Ave. 579 Beijing 100053 580 P.R.China 582 Phone: +86-13910750201 583 Email: denghui02@gmail.com 585 9. Acknowledgments 587 Many thanks to the following individuals who provided valuable 588 comments: 589 +---------------+---------------+---------------+---------------+ 590 | X. Deng | W. Dec | D. Wing | A. Baudot | 591 | E. Burgey | L. Cittadini | R. Despres | J. Zorz | 592 | M. Townsley | L. Meillarec | R. Maglione | J. Queiroz | 593 | C. Xie | X. Li | O. Troan | J. Qin | 594 | B. Sarikaya | N. Skoberne | J. Arkko | | 595 +---------------+---------------+---------------+---------------+ 597 Special thanks to W. Dec who provided a summary of the motivation 598 items. 600 10. Informative References 602 [EURESCOM] 603 Levis, P., Borges, I., Bonness, O. and L. Dillon L., "IPv4 604 address exhaustion: Issues and Solutions for Service 605 Providers", March 2010, . 609 [I-D.boucadair-intarea-nat-reveal-analysis] 610 Boucadair, M., Touch, J., Levis, P., and R. Penno, 611 "Analysis of Solution Candidates to Reveal a Host 612 Identifier in Shared Address Deployments", 613 draft-boucadair-intarea-nat-reveal-analysis-04 (work in 614 progress), September 2011. 616 [I-D.ietf-behave-lsn-requirements] 617 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 618 and H. Ashida, "Common requirements for Carrier Grade NAT 619 (CGN)", draft-ietf-behave-lsn-requirements-03 (work in 620 progress), August 2011. 622 [I-D.matsushima-v6ops-transition-experience] 623 Matsushima, S., Yamazaki, Y., Sun, C., Yamanishi, M., and 624 J. Jiao, "Use case and consideration experiences of IPv4 625 to IPv6 transition", 626 draft-matsushima-v6ops-transition-experience-02 (work in 627 progress), March 2011. 629 [I-D.vixie-dnsext-dns0x20] 630 Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to 631 Improve Transaction Identity", 632 draft-vixie-dnsext-dns0x20-00 (work in progress), 633 March 2008. 635 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 636 RFC 1958, June 1996. 638 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 639 Translator (NAT) Terminology and Considerations", 640 RFC 2663, August 1999. 642 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 643 Robustness to Blind In-Window Attacks", RFC 5961, 644 August 2010. 646 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 647 Protocol Port Randomization", BCP 156, RFC 6056, 648 January 2011. 650 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 651 IPv4/IPv6 Translation", RFC 6144, April 2011. 653 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 654 Roberts, "Issues with IP Address Sharing", RFC 6269, 655 June 2011. 657 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 658 IPv6 Automatic Tunnels: Problem Statement and Proposed 659 Mitigations", RFC 6324, August 2011. 661 [UPnP-IGD] 662 UPnP Forum, "Universal Plug and Play (UPnP) Internet 663 Gateway Device (IGD) V 2.0", December 2010, 664 . 666 Authors' Addresses 668 Mohamed Boucadair (editor) 669 France Telecom 670 Rennes, 35000 671 France 673 Email: mohamed.boucadair@orange-ftgroup.com 675 Satoru Matsushima 676 Softbank Telecom 677 Tokyo 678 Japan 680 Email: satoru.matsushima@tm.softbank.co.jp 682 Yiu Lee 683 Comcast 684 US 686 Email: Yiu_Lee@Cable.Comcast.com 687 Olaf Bonness 688 Deutsche Telekom 689 Germany 691 Email: Olaf.Bonness@telekom.de 693 Isabel Borges 694 Portugal Telecom 695 Portugal 697 Email: Isabel@ptinovacao.pt 699 Gang Chen 700 China Mobile 701 53A,Xibianmennei Ave. 702 Beijing, Xuanwu District 100053 703 China 705 Email: chengang@chinamobile.com