idnits 2.17.1 draft-savola-v6ops-transarch-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2004) is 7379 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RELAY' is defined on line 866, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3439 (ref. 'ARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'PREMISES' -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. 'ADDRSEL') (Obsoleted by RFC 6724) == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-application-transition-00 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-v6onbydefault-00 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-onlinkassumption-00 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Savola 2 Internet Draft CSC/FUNET 3 Expiration Date: July 2004 4 January 2004 6 A View on IPv6 Transition Architecture 8 draft-savola-v6ops-transarch-03.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is 34 a subject of much debate. However, the big picture of the transition 35 doesn't seem to have been discussed sufficiently. Therefore, 36 different people have different assumptions on the process, which 37 makes planning the transition architecture very difficult. This memo 38 tries to point out some issues that will need consideration in the 39 transition architecture. 41 Table of Contents 43 1. Introduction ............................................... 3 44 2. Architectural Considerations ............................... 3 45 2.1. Fundamental Assumptions about IPv6 ..................... 3 46 2.2. General Principles ..................................... 4 47 2.3. Architecting the Transition ............................ 5 48 2.4. Transition Mechanism Deployment Considerations ......... 6 49 3. Transition Mechanism Considerations ........................ 7 50 3.1. Obtaining IPv6 Connectivity ............................ 7 51 3.2. Protocol Translation ................................... 8 52 3.3. Application Level Gateway or Proxy ..................... 8 53 4. Node Deployment Model Considerations ....................... 9 54 4.1. IPv4-only .............................................. 9 55 4.2. Dual-stack with Only IPv4 Connectivity ................. 10 56 4.3. Dual-stack w/ IPv4/6 Connectivity ...................... 10 57 4.4. Dual-stack with Only IPv6 Connectivity ................. 11 58 4.5. IPv6-only .............................................. 11 59 5. Service Deployment Model Considerations .................... 12 60 5.1. IPv4-only .............................................. 12 61 5.2. Separate IPv4 and IPv6 ................................. 12 62 5.3. IPv4/6 ................................................. 13 63 5.4. IPv6-only .............................................. 14 64 6. Implications of the Transition Architecture Considerations . 14 65 7. A View on Transition ....................................... 15 66 7.1. The Cost of Dual-stack Compared to IPv6-only ........... 15 67 7.2. Generic Protocol Translation in IPv6 ................... 16 68 7.3. Providing IPv6-enabled Services -- How? ................ 17 69 8. Acknowledgements ........................................... 18 70 9. Security Considerations .................................... 18 71 10. References ................................................ 18 72 10.1. Normative ............................................. 18 73 10.2. Informative ........................................... 19 74 Author's Address ............................................... 19 75 A. Example Mechanism: TCP/UDP Relay ........................... 19 76 Intellectual Property Statement ................................ 20 77 Full Copyright Statement ....................................... 20 79 1. Introduction 81 The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is 82 a subject of much debate. However, the big picture of the transition 83 doesn't seem to have been discussed sufficiently. Therefore, 84 different people have different assumptions on the process, which 85 makes planning the transition architecture very difficult. 87 This memo points out some issues that will need consideration in the 88 transition architecture, as well as point out a few views on certain 89 transition approaches. 91 As a semantic note, the phrase "IPv6 Transition" is used to refer to 92 the process of enabling the use of IPv6. In practice, the means 93 IPv4/IPv6 dual-stack co-existence. The term "transition" comes from 94 transitioning from IPv4-only networks to networks where IPv6 has been 95 enabled; it is not meant to imply IPv6 networks where IPv4 has been 96 disabled. 98 In section 2, the important architectural transition considerations 99 are introduced. In section 3, 4, and 5, the transition mechanism, 100 node deployment and service deployment considerations, respectively, 101 are discussed at more length. In section 6, the implications of the 102 transition architecture are summarized. In section 7, several 103 personal views on the IPv6 transition are described. 105 2. Architectural Considerations 107 This section lists some fundamental architectural considerations to 108 keep in mind in the transition process; most of these will be 109 discussed at more length later. 111 2.1. Fundamental Assumptions about IPv6 113 People have different assumptions what the transition to IPv6 and co- 114 existence with IPv6 means. This makes it more difficult communicate 115 and gain consensus on how IPv6 should evolve and be deployed. For 116 example [PREMISES] lists a number of questionable assumptions, like: 118 o at some point, IPv4 will become obsolete because of wide-spread 119 IPv6 adoption, 121 o IPv6 will not be adopted unless it provides the same solutions to 122 the perceived problems as IPv4 does (e.g. a form of local 123 addressing, NATs), or 125 o dual-stack IPv6 + natted-IPv4 is not an interesting replacement 126 for an already-natted IPv4 host. 128 This memo does not try to present or assume definitive answers to 129 these dubious premises. However, the author of this document mostly 130 agrees with [PREMISES] in that IPv6 is better served as an enabler of 131 a different model of networking than as an immediate replacement for 132 IPv4. 134 It is very important that the reader gives these assumptions a lot of 135 thought, as the approach to the IPv6 transition/co-existence will be 136 entirely different, given different assumptions. This is probably 137 the most important single point of confusion or miscommunication 138 between different people working on IP technologies. 140 2.2. General Principles 142 General principles which should be carefully considered when 143 architecting the transition include at least: 145 o security 147 o simplicity 149 o robustness 151 Actually, all of these are somewhat related; similar considerations 152 have also been noted in the Internet architectural principles [ARCH]. 154 Security is very important: the transition architecture in general, 155 or the transition mechanisms in particular, must not enable 156 significant security threats, as that might cause the holes to be 157 abused and make people hesitant to start the transition. 159 Simplicity is crucial: this includes the overall simplicity of the 160 transition architecture (for example, a limited set of mechanisms or 161 operational practices which have clear uses and different clearly 162 defined problems -- not too many tools to make the choices between 163 them too difficult), and the simplicity of the transition mechanisms 164 themselves. Simple systems have the tendency to work well even under 165 unexpected circumstances, and are less prone to security, robustness, 166 and other problems. If more complex systems have to be built, 167 they're better done using a set of simple building blocks. 169 Robustness is also essential: the mechanism and the architecture must 170 be reliable and robust, to encourage the adoption. The IPv6 and the 171 dual IPv4/6 architecture must not be less robust than the IPv4-only 172 architecture. For example, there are some IPv4 components (like 173 NATs, or worse, depending on some specific features on how NATs 174 operate) that are not always reliable. The success of IPv4/6 must 175 not be dependent on how these mechanisms (mis)operate, as creating 176 such a dependency could easily transfer these problems of IPv4 to 177 IPv6 -- and would negatively impacting the reliability and usefulness 178 of IPv6 as a whole. 180 2.3. Architecting the Transition 182 A plan how the IPv6 transition is to be done is needed. However, the 183 crystal balls are always a bit cloudy: it is difficult to predict how 184 the transition will progress. Therefore, when in doubt how to 185 proceed, one should choose an action that is least likely to hurt the 186 transition process in the future. 188 That is, it is important to move forward with the IPv6 transition, 189 even if by taking small steps. For example, deploying dual-stack 190 nodes or applications, even without IPv6 connectivity is an enormous 191 and critical step in the process, as that will enable the easier 192 adoption of IPv6 later on. Both of these steps will be necessary 193 anyway, so we've identified at least two "safe" actions: work done on 194 them is well spent. Such "safe" actions move the transition to the 195 right direction even though we may not have the yet gained a full 196 vision of the complete transition architecture. 198 When defining the architecture, there are typically different 199 building blocks to be used, from different classes as described 200 below. 202 "Mechanisms" are the building blocks to be used for to provide IPv6 203 connectivity, or to interoperate betweek IPv4 and IPv6. They are 204 further described in section 3; these are: 206 1. Providing IPv6 connectivity 207 2. Protocol translation 208 3. Application-specific protocol interoperability (i.e., ALG or 209 proxy) 211 "Deployment models for nodes" are the ways how IP nodes might be 212 deployed, including the different combinations of IPv4/6 capabilities 213 and connectivity. They are further described in section 3; these 214 are: 216 1. IPv4-only 217 2. Dual-stack with only IPv4 connectivity 218 3. Dual-stack w/ IPv4/6 connectivity 219 4. Dual-stack with only IPv6 connectivity 220 5. IPv6-only 222 "Deployment models for services" are the ways how IP services 223 ("applications") could be provisioned; this may be slightly different 224 from the node IP deployment model. They are further described in 225 section 4; these are: 227 1. IPv4-only 228 2. Separate IPv4 and IPv6 229 3. Both IPv4/6 230 4. IPv6-only 232 After discussing these in sections 3-5, conclusions are presented in 233 section 6. The subsection below provides a few considerations to 234 bear in mind when considering the details of different mechanisms or 235 deployment models. 237 2.4. Transition Mechanism Deployment Considerations 239 There are a few very important questions which must be addressed in 240 the cases where a transition mechanism deployment is deemed 241 necessary. For example: 243 o if I have an existing IPv4-only service (e.g., a web site) or if 244 I deploy IPv4-only service, whose burden is it to enable its use 245 by all clients I wish to make it accessible to? 247 o if I deploy IPv6-only service (e.g., a peer-to-peer application, 248 or a special web site), whose burden is it to enable its use by 249 all clients I wish to make it accessible to? 251 o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6 252 connectivity, whose burden is it to enable them to access all the 253 services they want? 255 o how much easier would it be to go for dual-stack approach 256 instead? 258 These are complex questions. One could examine this at least from an 259 architectural point-of-view in addition to considering where the 260 momentum of each approach lies. 262 That is, it would be desirable to architecturally try to ensure that 263 everybody is responsible to achieving the greatest amount of 264 interoperability while retaining the reasonable tradeoff of the 265 general principles (security, simplicity, and robustness). 267 On the other hand, one should realize the momentum of each scenario: 268 until the IPv6 usage levels are really significant globally (for 269 example, nearing 50%), it could be considered that that the new 270 deployments have a primary responsibility for ensuring this 271 interoperability. 273 So, it is not wise to assume IPv6 will gain enough momentum in the 274 short/medium term that you would not have to take care of being able 275 to reach the existing IPv4 services yourself, either using IPv4 or 276 IPv6. It is not reasonable to expect all the services to be 277 IPv6-enabled. On the other hand, it would be perfectly fine to get 278 someone else (e.g. a service provider providing extra IPv6 services) 279 to do it for you. 281 Of course, when considering an option like this, one should always be 282 very careful not to forget comparing the situation to the cost of 283 deploying a dual-stack solution. Typically, a dual-stack solution is 284 much easier to cope with than the alternative, and the total cost is 285 less. 287 3. Transition Mechanism Considerations 289 Now, the considerations associated with the basic transition building 290 blocks are discussed in more detail; these are: 292 1. Providing IPv6 connectivity 293 2. Protocol translation 294 3. Application-specific protocol interoperability (i.e. ALG or 295 proxy) 297 3.1. Obtaining IPv6 Connectivity 299 Obtaining IPv6 connectivity is an important step when moving from the 300 deployed base of dual-stack nodes to the use of IPv6-enabled 301 services. These do *not* have to happen simultaneously: indeed, it 302 can even be counter-productive to enable IPv6 connectivity 303 immediately (more of this below). 305 The connectivity methods could be classified in several ways, but 306 here is one: 308 o native 309 o tunneled over IPvX to a close tunnel end-point 310 o tunneled over IPvX (over longer distances) 312 The tunneled connectivity mechanisms could also be considered to 313 include subcategories "configured" and "automatic". A "configured 314 tunnel" implies that the tunnel endpoint -- especially for received 315 packets -- is known in advance, and is somewhat trusted. An 316 "automatic tunnel" implies a mechanism where the tunnel endpoints are 317 not known and there is a smaller degree of trust -- if any! 319 Otherwise, these should be self-evident. When considering the 320 robustness and simplicity principles, the first two seem to be 321 superior to more global connectivity mechanisms: when an underlying 322 network topology of a tunnel includes multiple different 323 administrative or technical entities, the probability of failures 324 increases tremendously. Similarly, the automatic mechanisms are 325 significantly more worrisome than configured ones, especially when 326 applied in a domain as large as the whole Internet. 328 As stated above, "premature" IPv6 connectivity could be knotty 329 problem because the operating systems try IPv6 by default if no 330 protocol has been specified explicitly. Therefore, when IPv6 331 connectivity is enabled (or, to a lesser degree, even IPv6 is enabled 332 -- more of this in section 4), it becomes critical to ensure that the 333 IPv6 connectivity is of equal qualityas IPv4 or that IPv6 is only 334 used by specific applications, for specific purposes. 336 That is, low-quality IPv6 connectivity could result in a visible 337 service degradation to the user, which would delay the moment when 338 the users feel comfortable with switching on IPv6 without too many 339 side-effects. These issues have been discussed at length in 340 [6BMESS]. 342 3.2. Protocol Translation 344 Protocol translation is used to refer to mechanisms which perform a 345 NAT-PT or SIIT -like automatic translation of all the packets, 346 regardless of content, or (typically) application compatibility. 348 These may work to some level of success for limited deployment 349 scenarios and sets of applications only, but do not seem to fulfill 350 robustness and simplicity principles in general. 352 A view on the problems of generic translation is presented in section 353 7.2. 355 3.3. Application Level Gateway or Proxy 357 It is well known that a protocol translator must have an ALG with it, 358 to deal with protocols (as simple as FTP) that contain direct 359 dependencies on IP addresses. However, ALGs may exist in the absence 360 of a protocol translator, and in this case they are better described 361 as proxies. 363 If all protocols of interest (e.g. SMTP, HTTP, SIP,...) are handled 364 by a proxy at the boundary between IPv4 and IPv6, no IP level 365 translation is needed. 367 A typical disadvantage of proxies is that their use must be 368 explicitly configured in the applications unless automated somehow. 370 The advantage of proxies -- or in general, mechanisms which have been 371 explicitly configured, on a service-by-service basis -- over generic 372 protocol translators is that their interface to the existing 373 infrastructure is well defined. If configured to act to proxy just 374 one service, it can be assumed that the proxy is restricted to that 375 service only, and understands the application details. 377 That is, proxies do not break applications that e.g. pass the IP 378 addresses in the payloads as by definition, the proxy acts as an 379 explicit endpoint in the communication. 381 4. Node Deployment Model Considerations 383 There are multiple ways how to deploy IP versions in the nodes, and 384 how to provide the connectivity to these IP versions. These are 385 discussed at more length here. Deployment models for IP nodes are: 387 1. IPv4-only 388 2. Dual-stack with only IPv4 connectivity 389 3. Dual-stack w/ IPv4/6 connectivity 390 4. Dual-stack with only IPv6 connectivity 391 5. IPv6-only 393 4.1. IPv4-only 395 This is an obvious model how nodes have been deployed in the past, 396 and will also continued, to some extent, be deployed in the future. 398 There are obviously two cases to consider here: 400 o IPv6 has not been implemented in the system being deployed at 401 all, or 403 o IPv6 has been implemented in the system (to some degree), but it 404 is not enabled in the kernel, library functions, etc. 406 The first is obvious: IPv6 just isn't there, so nothing can be done 407 about it, except maybe try to request the support to be included in 408 the future revisions, or to pick a different kind of system. 410 The second is a bit more subtle: either the vendor or the user has 411 decided that enabling IPv6 (whether explicitly, or by default) does 412 not make sense yet. This is understandable in the face of issues 413 which may result from doing that [ONBYDEF]. It is expected that when 414 sufficient experience has been gained from enabling IPv6 by default, 415 it will become more commonplace. However, even deploying IPv4-only 416 nodes which implement IPv6 is a step to the right direction. 418 4.2. Dual-stack with Only IPv4 Connectivity 420 This is an extension of the second case above: IPv6 dual-stack has 421 been deployed and enabled, but for some reason, there is only IPv4 422 connectivity. 424 Having only IPv4 connectivity, or only very limited IPv6 425 connectivity, may be intentional; if there are concerns about the 426 robustness of IPv6, some may consider it appropriate to wait prior to 427 starting to prefer IPv6 over IPv4 by not providing global IPv6 428 connectivity yet, as discussed in section 3.1. 430 Having dual-stack enabled but with only IPv4 connectivity implies 431 that the IPv6 loopback address is automatically configured, and each 432 interface has an IPv6 link-local address, and that all the IPv6 433 destinations are considered to be on-link. This is highly 434 problematic in most cases [ONLINK], as well because the getaddrinfo 435 AI_ADDRCONFIG flag will start returning IPv6 addresses when a link- 436 local address has been configured [RFC3493]. There are likely many 437 other issues like these, but these will be overcome and fixed as more 438 experience is gained from the deployment. 440 4.3. Dual-stack w/ IPv4/6 Connectivity 442 The next logical model is obviously deploying dual-stack nodes with 443 full IPv4/6 connectivity. This is the phase which is expected to 444 become dominant in the new deployments in the short/middle term, and 445 continue to increase gradually for a long time as IPv4 and IPv6 co- 446 exist in the Internet. 448 In this phase, it is critically important that the applications have 449 been developed properly; for example, [APPTRANS] gives some 450 guidelines on that. In particular, they must be able to gracefully 451 fall back when IPv6 connectivity does not work to IPv4, or vice versa 452 (depending on which protocol is preferred). 454 As this phase is expected to take the longest amount of time, it is 455 imperative to ensure that the scenario does not have any flaws. 457 4.4. Dual-stack with Only IPv6 Connectivity 459 Another deployment model is deploying just IPv6 connectivity on dual- 460 stack nodes. 462 One scenario where this could be applicable in the mid-long term 463 could be some special-purpose nodes or applications, which are known 464 before the fact that they will only need to communicate with IPv6 465 nodes and applications. These are very like very few in the 466 short/middle term, as the deployment base of IPv6 needs to be grown 467 first. 469 This model is obviously better than "IPv6-only" because it is still 470 possible to go back to dual-stack, just by enabling IPv4 471 connectivity. 473 Except for the very specific scenarios identified above, this 474 scenario does not seem to be relevant in a very, very long time. 476 4.5. IPv6-only 478 IPv6-only is the final deployment model. Either the IPv4 stack has 479 been removed, or it has been disabled completely. 481 IPv6-only deployments would imply that the nodes and applications 482 would never want to communicate with IPv4 nodes, or would do so 483 through a proxy or protocol translator. 485 Because the period of dual-stack infrastructure is expected to last 486 for a very, very long time, it does not make sense to deploy 487 IPv6-only infrastructures until about all the relevant IPv4 services 488 and nodes have been retired. If generic protocol translation would 489 be needed, this would seem like a clear indication that the 490 transition has not progressed as far as it should have been prior to 491 switching to IPv6-only. These issues have been discussed at more 492 length in section 7. 494 Therefore, it is completely premature to consider IPv6-only 495 deployments as of writing this memo. 497 5. Service Deployment Model Considerations 499 Similarly, there are multiple ways to deploy services. Here, we use 500 the term "service" to describe an application deployed by the 501 facilitator of the service (XXX: if you can think of more unambiguous 502 term to use, please send suggestions!). These are discussed at more 503 length here. The models are: 505 1. IPv4-only 506 2. Separate IPv4 and IPv6 507 3. IPv4/6 508 4. IPv6-only 510 We examine services from the "server's" (or in more general, the 511 facilitator of the service) perspective. How the support for using 512 services is deployed is assumed to, in most cases, be decided by the 513 node deployment model (section 4). 515 5.1. IPv4-only 517 Obviously, IPv4-only services is the initial deployment model. Most 518 current deployments are IPv4-only, but are slowly changing to also 519 enable IPv6 services. 521 This is the safest deployment in the sense that its problems are well 522 known, and there is ample experience of such IPv4-only deployments. 523 Unfortunately, doing so will not progress the IPv6 transition 524 process, and the dual-stack, IPv4/6-connected nodes will have to 525 reach these services over IPv4. 527 However, the deployment of IPv4-only services is not necessarily a 528 bad thing: one should not expect that all the services become 529 IPv6-enabled for a very long time. It could be argued that the 530 services will be IPv6 enabled when it makes sense for the service 531 provider to do it. This could be due to a specific application that 532 profits from features of IPv6, as a general dual-stack service 533 policy, etc. 535 5.2. Separate IPv4 and IPv6 537 Here, the term "Separate IPv4 and IPv6" is used to refer to services 538 that are not reachable the same way; for example, this could be the 539 service on the same (or different) host being available on 540 www.example.com and www.ipv6.example.com, a service provider 541 providing IPv6 SMTP mail exchange (MX) service for IPv4-only sites, 542 or the like; note that "separate" could be considered to include an 543 application level gateway of a sort. 545 One issue of separate IPv4 and IPv6 services is that they do not have 546 similar "fate-sharing" properties. One service could be down while 547 the other remains up. This is typically a negative thing, when IPv6 548 services are used less frequently than their IPv4 counterparts; IPv6 549 services could be down or not functioning properly (without timely 550 reaction from the administrators) while IPv4 works fine. 552 To summarize, one should be wary when deploying especially some forms 553 of separate services; a factor here is the stage of the transition. 554 They are often more difficult to manage and troubleshoot, and there 555 is the problem of service getting out-of-sync. 557 A mechanism which has been used to facilitate separate services is 558 described briefly in Appendix A. 560 5.3. IPv4/6 562 The obvious long-term deployment model for certain services at least 563 is IPv4/6, that is, the same application provides the support for 564 both protocol versions. 566 There are a number of pitfalls here relating how the applications are 567 developed [APPTRANS], but it should be expected that one will be able 568 to overcome and fix these issues to enable robust use of application 569 in every case. 571 IPv4/6 service deployment (at least for those applications which are 572 relevant for IPv4) is the best approach in the long run. The rate 573 and the timing of service deployment depends on many factors, e.g., 574 the extent of IPv6 deployment in the user base, and how aggressive 575 IPv6 deployment plan has been adopted for the service. 577 However, it should be noted that in the early stages of the 578 transition, this might lead to some bad effects to the users -- this 579 places some requirements on the quality and availability of IPv6 580 connectivity on all or most of the users of the service, as is 581 pointed out in section 3.1. 583 There certainly are many issues left to be worked out; these will not 584 be fixed unless the services will be actually used. At a critical 585 point, the "burden" of fixing problems caused by IPv6 service 586 deployment shifts to those who have not deployed it (properly) yet. 587 It is important to get to that point. This point is brough closer by 588 those who are in the "cutting edge", providing services despite 589 potential problems, paving the way for the mainstream deployment 590 phase. 592 5.4. IPv6-only 594 The last deployment model for services is IPv6-only. Obviously, it 595 is not suited for all the services in a very, very long time. 597 However, there are some uses for this model with some specific 598 applications. Some applications may be able to assume that they will 599 only be run over IPv6, for whatever reason (e.g., simplicity of not 600 having to implement NAT workarounds). This kind of approach might 601 make perfect sense in some specific scenarios where one can assume 602 that the users of the service are all able to use IPv6. On the other 603 hand, providing an IPv6-only service when all its users would not 604 have IPv6 capabilities would not be appropriate. 606 6. Implications of the Transition Architecture Considerations 608 Having described the different deployment model considerations, the 609 implications need to be considered. 611 Let's consider the deployment models for nodes and services, trying 612 to optimize for the scenario where the need for the mechanisms would 613 be minimized; that is: 615 +---------+---------+--------+------+---------+ 616 |Node\Srvc|IPv4-only|Separate|IPv4/6|IPv6-only| 617 +---------+---------+--------+------+---------+ 618 |IPv4-only| +++ | +++ | +++ | 2,3 | 619 +---------+---------+--------+------+---------+ 620 |DS w/IPv4| +++ | +++ | +++ | 1?,2,3 | 621 +---------+---------+--------+------+---------+ 622 |DS w/both| +++ | +++ | +++ | +++ | 623 +---------+---------+--------+------+---------+ 624 |DS w/IPv6| 1?,2,3 | +++ | +++ | +++ | 625 +---------+---------+--------+------+---------+ 626 |IPv6-only| 2,3 | +++ | +++ | +++ | 627 +---------+---------+--------+------+---------+ 629 The matrix is intuitive; all off-the-shelf working combinations are 630 listed with "+++". In the remaining four instances, the possible 631 transition mechanisms that could be applied are listed. 633 So, the easiest thing to do would be to ensure that the service or 634 deployment model matches one of these categories. However, some of 635 these are suboptimal, as they do not progress the transition (for 636 example, IPv4-only nodes and services). 638 To summarize, it would be desirable if the services would not be 639 deployed IPv4-only or IPv6-only, and the nodes dual-stack with both 640 IPv4/6 connectivity. 642 This is the goal we should be working toward. However, the goal can 643 be achieved using a big step, or a set of smaller steps. 645 As already described, these issues can also be viewed a bit more 646 pragmatically: the deployment base of IPv4 is so huge that assuming 647 mainstream IPv6 adoption in the short term is not necessarily 648 feasible. Therefore, deploying dual-stack nodes but without IPv6 649 connectivity is still a step in the right direction, and keeping the 650 services IPv4-only is not necessarily a huge problem. 652 That is, for example, early adopters give experience back to the 653 community which allows for smoother and more problem-free 654 introduction of IPv6 to the masses later on. Advocating strongly 655 that IPv6 should be deployed everywhere quickly might backfire and 656 turn out to be counter-productive -- as there are likely some issues 657 to be identified and worked out prior to the co-existence could be 658 deemed to be a trivial exercise. 660 7. A View on Transition 662 This section includes a few views on several aspects of the 663 transition. 665 7.1. The Cost of Dual-stack Compared to IPv6-only 667 An oft-cited argument against deploying dual-stack instead of 668 IPv6-only with some generic translation and proxying is that the 669 management of a dual-stack networks, address assignments etc. is a 670 significant burden and should be avoided. 672 In practice, this seems highly questionable. Naturally, the overall 673 complexity one should compare the dual-stack architecture against is 674 the IPv6-only architecture AND everything that's required to make it 675 work with a mostly-IPv4 universe. 677 For example, there is a routing protocol which allows a single 678 Shortest Path First (SPF) calculation for both IP protocols -- the 679 increase of management complexity seems close to negligible. 681 Even address assignments are quite straightforward. IPv6 has to be 682 done anyway; IPv4, if private addresses would be used, would be 683 straightforward, but the issues relating to IPv6-only networks and 684 protocol translation would result in about equal problems with 685 translated-IPv4 than with private IPv4 addresses. On the other hand, 686 if public IPv4 addresses are obtainable and desirable, the management 687 of those is a task, although not a major one. So, it seems that the 688 only addressing related concern seems to be being able to avoid the 689 paperwork with Regional Internet Registries (RIRs) relating to public 690 IPv4 addresses. 692 The desire to go straight to IPv6-only seems to be mainly caused by a 693 dream of fast transition to IPv6-only especially in some more evolved 694 networks. However, this seems counter-productive. (Of course, a 695 fast transition to a state where IPv6 applications are being 696 extensively used and IPv6 is becoming more and more dominant is a 697 separate subject.) 699 There is a class of dedicated devices and applications for which 700 IPv6-only may be warranted -- these are those that, for whatever 701 reason, are only to be deployed in IPv6-capable networks, and only 702 need to inter-operate with IPv6 nodes. Generic translation is not 703 necessary, and at most some form of simple application proxying is 704 used. When/if these emerge, they could be deployed in an IPv6-only 705 fashion .. but still, the network would be dual-stack. 707 It might be that this stanza could change significantly in (say) 10 708 years if the deployment gets off, but prior to major global 709 deployment happens (e.g., causing over 3/4 of services be available 710 over IPv6), any action toward generic IPv6-only networks, as a 711 generic replacement to IPv4 networks, seems premature. 713 7.2. Generic Protocol Translation in IPv6 715 One argument for generic protocol translation (referring to 716 translation done not just on a specific set of applications) in 717 IPv6-only networks (see above) is that protocol translation is not 718 that much different from NAT and the users would, in many cases, be 719 plagued by that too. 721 This is pretty close to the mark, for better and _worse_. 723 In particular, generic protocol translation eliminates the ideal that 724 applications are not munged by NATs in IPv6. A reason to deploy an 725 IPv6 application could be to be able to get rid of the problems of 726 NATs in the first place. 728 Thus, not polluting IPv6 with protocol translation seems to be 729 desirable goal on its own. In this light, it is more desirable to 730 just continue using IPv4 when needed, and keeping IPv6 as "high 731 quality". 733 That is, an IPv6 application could end up used to connect to IPv4 734 peers though a translator, when the "promise of IPv6" (which may have 735 been included in the design of the application) was that no 736 translation would be performed with IPv6. 738 This could be summarized so that we (the IPv6 deployers) cannot 739 change what IPv4 is: the applications and users already have certain 740 expectations of it and they deal (or don't) with them. However, we 741 can still ensure that IPv6 will not be riddled with IPv4's problems, 742 whether in the coexistence with IPv4 (important) or in the 743 communication between IPv6 nodes themselves (critical). 745 Encouraging generic protocol translation only seems to support the 746 wrong kind of IPv6 deployment (see above), and carrying the problems 747 of IPv4 NAT to IPv6. This seems counter-productive. 749 7.3. Providing IPv6-enabled Services -- How? 751 Providing IPv6-enabled services is an extremely tricky business which 752 has a number of caveats which should be taken into serious 753 consideration. 755 First, we'll assume that in the first phase, it is crucial to improve 756 the number of dual-stack (even without IPv6 connectivity) nodes. 757 This seems a reasonably safe assumption. 759 Now, a potential problem appears when someone wishes to provide also 760 IPv6-enabled service alongside with their IPv4 service: the first 761 priority, for all parties -- the service provider, the vendor of the 762 dual-stack nodes and the users -- is that enabling IPv6 will not 763 degrade the perceived performance of existing applications. 764 Otherwise, only few would be willing to deploy dual-stack nodes (or 765 connectivity), or enable IPv6 on their services. This also seems to 766 be a reasonable assumption on the goal to be work toward. 768 A temporary workaround would be to deploy the IPv6 services under 769 different service identifiers, like www.ipv6.example.com rather than 770 www.example.com. In general, this is a relatively safe mechanism, 771 but only carries so far: the potential IPv6 users will still use 772 www.example.com because they are not aware of the sub-domain. 774 A fix for this would be changing the default address ordering to 775 prefer A DNS records over AAAA records: then, IPv6 addresses could be 776 added for standard names without worries, and the nodes themselves -- 777 not the one implementing service -- would be capable of making a 778 decision when to switch the toggle the other way around. 780 The change in the default ordering should already be doable with a 781 custom Default Address Selection rule [ADDRSEL], but unless the 782 existence or deployment of such a rule would be commonplace, this 783 methodology would not work. So, it may be that the "deployment 784 window" for this approach has already passed. 786 The requirement for this problem to go away is globally stable and 787 robust IPv6 connectivity. It seems to take long until that is 788 achieved [6BMESS]; this was also briefly discussed ini section 3.1. 789 for some IPv4-enabled services to the IPv6 users. 791 8. Acknowledgements 793 Discussions with Brian Carpenter gave a push to writing this memo. 794 Discussions with Rob Austein, Suresh Satapati, and Juha Wiljakka 795 inspired into revising the memo. Suresh Satapati, Jim Bound, and 796 Michael Mackay provided feedback, helping in improving the document. 797 Keith Moore's "dubious premises" email helped a lot to spell out 798 which kind of fundamental differences of assumptions people have 799 about IPv6. 801 9. Security Considerations 803 Transition architecture discussion has no special security 804 considerations as such; however, one must be very careful not to 805 introduce an new security considerations when specifying and 806 deploying the transition architecture. 808 In the quick analysis above, mainly only the robustness and 809 simplicity principles were considered, leaving security to follow 810 from these. A more careful security review will be needed in the 811 future. 813 10. References 815 10.1. Normative 817 [ARCH] Bush, R., Meyer, D., "Some Internet Architectural 818 Guidelines and Philosophy", RFC3439, December 2002. 820 [PREMISES] Moore, K., "dubious premises: batch reply to "IPv6 821 adoption behaviour"", a message on ipv6@ietf.org list on 822 21 Oct 2003, http://www1.ietf.org/mail-archive/ 823 working-groups/ipv6/current/msg00398.html or 824 http://www.cs.utk.edu/~moore/opinions/ipv6/ 825 dubious-assumptions.html 827 10.2. Informative 829 [6BMESS] Savola, P., "Moving from 6bone to IPv6 Internet", 830 draft-savola-v6ops-6bone-mess-01.txt, work-in-progress, 831 November 2002. 833 [ADDRSEL] Draves, R., "Default Address Selection for IPv6", 834 RFC 3484, February 2003. 836 [APPTRANS] Shin, M., "Application Aspects of IPv6 Transition", 837 draft-ietf-v6ops-application-transition-00.txt, 838 work-in-progress, December 2003. 840 [ONBYDEF] Roy, S., et al., "Dual Stack IPv6 on by Default", 841 draft-ietf-v6ops-v6onbydefault-00.txt, work-in-progress, 842 October 2003. 844 [ONLINK] Roy, S., et al., "IPv6 Neighbor Discovery On-Link 845 Assumption Considered Harmful", draft-ietf-v6ops- 846 onlinkassumption-00.txt, work-in-progress, October 2003. 848 [RFC3493] Gilligan, R., et al., "Basic Socket Interface 849 Extensions for IPv6", RFC 3493, February 2003. 851 [RELAY] Hagino, J., Yamamoto, K., "An IPv6-to-IPv4 Transport 852 Relay Translator", RFC3142, June 2001. 854 Author's Address 856 Pekka Savola 857 CSC/FUNET 858 Espoo, Finland 859 EMail: psavola@funet.fi 861 A. Example Mechanism: TCP/UDP Relay 863 This appendix describes the use of one mechanism for controlled help 864 in IPv6 adoption, using the "separate IPv4 and IPv6" service model. 866 [RELAY] provides a mechanism to perform protocol interoperability on 867 a service-by-service basis which has decoupled interactions with DNS 868 from the service management. 870 TCP/UDP relay can be deployed at two different locations: on the 871 client side or the server side. On the client side, the usability 872 appears to be a bit questionable, bringing up many issues regarding 873 the interaction between the DNS and service proxying. However, on 874 the server side, it is much simpler. 876 That is, for example, a gateway between IPv4-only NNTP service and a 877 dual-stack relay at the NNTP service providers' network can be easily 878 and relatively reliably built with a TCP relay. This includes 879 publishing the address of the TCP relay pointing toward the NNTP 880 server in the DNS, configuring sufficient access-lists so that only 881 the NNTP service is reachable, and configuring access-lists that only 882 valid users have the access to use the relay service. The latter is 883 necessary because the IPv4-only service sees the connections 884 originating from the relay (and the real IPv6 source is lost); this 885 is unfortunate, but unavoidable. 887 Of course, in most cases, deploying IPv6-enabled services from the 888 start is the best, and simplest choice. However, the TCP/UDP relay 889 seems to be sufficiently simple and robust mechanism when used for 890 providing a gateway 892 Intellectual Property Statement 894 The IETF takes no position regarding the validity or scope of any 895 intellectual property or other rights that might be claimed to 896 pertain to the implementation or use of the technology described in 897 this document or the extent to which any license under such rights 898 might or might not be available; neither does it represent that it 899 has made any effort to identify any such rights. Information on the 900 IETF's procedures with respect to rights in standards-track and 901 standards-related documentation can be found in BCP-11. Copies of 902 claims of rights made available for publication and any assurances of 903 licenses to be made available, or the result of an attempt made to 904 obtain a general license or permission for the use of such 905 proprietary rights by implementors or users of this specification can 906 be obtained from the IETF Secretariat. 908 The IETF invites any interested party to bring to its attention any 909 copyrights, patents or patent applications, or other proprietary 910 rights which may cover technology that may be required to practice 911 this standard. Please address the information to the IETF Executive 912 Director. 914 Full Copyright Statement 916 Copyright (C) The Internet Society (2003). All Rights Reserved. 918 This document and translations of it may be copied and furnished to 919 others, and derivative works that comment on or otherwise explain it 920 or assist in its implementation may be prepared, copied, published 921 and distributed, in whole or in part, without restriction of any 922 kind, provided that the above copyright notice and this paragraph are 923 included on all such copies and derivative works. However, this 924 document itself may not be modified in any way, such as by removing 925 the copyright notice or references to the Internet Society or other 926 Internet organizations, except as needed for the purpose of 927 developing Internet standards in which case the procedures for 928 copyrights defined in the Internet Standards process must be 929 followed, or as required to translate it into languages other than 930 English. 932 The limited permissions granted above are perpetual and will not be 933 revoked by the Internet Society or its successors or assignees. 935 This document and the information contained herein is provided on an 936 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 937 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 938 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 939 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 940 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 942 Acknowledgement 944 Funding for the RFC Editor function is currently provided by the 945 Internet Society.