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