Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: July 2004 January 2004 A View on IPv6 Transition Architecture draft-savola-v6ops-transarch-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition doesn't seem to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult. This memo tries to point out some issues that will need consideration in the transition architecture. Savola [Expires July 2004] [Page 1] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 Table of Contents 1. Introduction ............................................... 3 2. Architectural Considerations ............................... 3 2.1. Fundamental Assumptions about IPv6 ..................... 3 2.2. General Principles ..................................... 4 2.3. Architecting the Transition ............................ 5 2.4. Transition Mechanism Deployment Considerations ......... 6 3. Transition Mechanism Considerations ........................ 7 3.1. Obtaining IPv6 Connectivity ............................ 7 3.2. Protocol Translation ................................... 8 3.3. Application Level Gateway or Proxy ..................... 8 4. Node Deployment Model Considerations ....................... 9 4.1. IPv4-only .............................................. 9 4.2. Dual-stack with Only IPv4 Connectivity ................. 10 4.3. Dual-stack w/ IPv4/6 Connectivity ...................... 10 4.4. Dual-stack with Only IPv6 Connectivity ................. 11 4.5. IPv6-only .............................................. 11 5. Service Deployment Model Considerations .................... 12 5.1. IPv4-only .............................................. 12 5.2. Separate IPv4 and IPv6 ................................. 12 5.3. IPv4/6 ................................................. 13 5.4. IPv6-only .............................................. 14 6. Implications of the Transition Architecture Considerations . 14 7. A View on Transition ....................................... 15 7.1. The Cost of Dual-stack Compared to IPv6-only ........... 15 7.2. Generic Protocol Translation in IPv6 ................... 16 7.3. Providing IPv6-enabled Services -- How? ................ 17 8. Acknowledgements ........................................... 18 9. Security Considerations .................................... 18 10. References ................................................ 18 10.1. Normative ............................................. 18 10.2. Informative ........................................... 19 Author's Address ............................................... 19 A. Example Mechanism: TCP/UDP Relay ........................... 19 Intellectual Property Statement ................................ 20 Full Copyright Statement ....................................... 20 Savola [Expires July 2004] [Page 2] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 1. Introduction The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition doesn't seem to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult. This memo points out some issues that will need consideration in the transition architecture, as well as point out a few views on certain transition approaches. As a semantic note, the phrase "IPv6 Transition" is used to refer to the process of enabling the use of IPv6. In practice, the means IPv4/IPv6 dual-stack co-existence. The term "transition" comes from transitioning from IPv4-only networks to networks where IPv6 has been enabled; it is not meant to imply IPv6 networks where IPv4 has been disabled. In section 2, the important architectural transition considerations are introduced. In section 3, 4, and 5, the transition mechanism, node deployment and service deployment considerations, respectively, are discussed at more length. In section 6, the implications of the transition architecture are summarized. In section 7, several personal views on the IPv6 transition are described. 2. Architectural Considerations This section lists some fundamental architectural considerations to keep in mind in the transition process; most of these will be discussed at more length later. 2.1. Fundamental Assumptions about IPv6 People have different assumptions what the transition to IPv6 and co- existence with IPv6 means. This makes it more difficult communicate and gain consensus on how IPv6 should evolve and be deployed. For example [PREMISES] lists a number of questionable assumptions, like: o at some point, IPv4 will become obsolete because of wide-spread IPv6 adoption, o IPv6 will not be adopted unless it provides the same solutions to the perceived problems as IPv4 does (e.g. a form of local addressing, NATs), or Savola [Expires July 2004] [Page 3] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 o dual-stack IPv6 + natted-IPv4 is not an interesting replacement for an already-natted IPv4 host. This memo does not try to present or assume definitive answers to these dubious premises. However, the author of this document mostly agrees with [PREMISES] in that IPv6 is better served as an enabler of a different model of networking than as an immediate replacement for IPv4. It is very important that the reader gives these assumptions a lot of thought, as the approach to the IPv6 transition/co-existence will be entirely different, given different assumptions. This is probably the most important single point of confusion or miscommunication between different people working on IP technologies. 2.2. General Principles General principles which should be carefully considered when architecting the transition include at least: o security o simplicity o robustness Actually, all of these are somewhat related; similar considerations have also been noted in the Internet architectural principles [ARCH]. Security is very important: the transition architecture in general, or the transition mechanisms in particular, must not enable significant security threats, as that might cause the holes to be abused and make people hesitant to start the transition. Simplicity is crucial: this includes the overall simplicity of the transition architecture (for example, a limited set of mechanisms or operational practices which have clear uses and different clearly defined problems -- not too many tools to make the choices between them too difficult), and the simplicity of the transition mechanisms themselves. Simple systems have the tendency to work well even under unexpected circumstances, and are less prone to security, robustness, and other problems. If more complex systems have to be built, they're better done using a set of simple building blocks. Robustness is also essential: the mechanism and the architecture must be reliable and robust, to encourage the adoption. The IPv6 and the dual IPv4/6 architecture must not be less robust than the IPv4-only architecture. For example, there are some IPv4 components (like Savola [Expires July 2004] [Page 4] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 NATs, or worse, depending on some specific features on how NATs operate) that are not always reliable. The success of IPv4/6 must not be dependent on how these mechanisms (mis)operate, as creating such a dependency could easily transfer these problems of IPv4 to IPv6 -- and would negatively impacting the reliability and usefulness of IPv6 as a whole. 2.3. Architecting the Transition A plan how the IPv6 transition is to be done is needed. However, the crystal balls are always a bit cloudy: it is difficult to predict how the transition will progress. Therefore, when in doubt how to proceed, one should choose an action that is least likely to hurt the transition process in the future. That is, it is important to move forward with the IPv6 transition, even if by taking small steps. For example, deploying dual-stack nodes or applications, even without IPv6 connectivity is an enormous and critical step in the process, as that will enable the easier adoption of IPv6 later on. Both of these steps will be necessary anyway, so we've identified at least two "safe" actions: work done on them is well spent. Such "safe" actions move the transition to the right direction even though we may not have the yet gained a full vision of the complete transition architecture. When defining the architecture, there are typically different building blocks to be used, from different classes as described below. "Mechanisms" are the building blocks to be used for to provide IPv6 connectivity, or to interoperate betweek IPv4 and IPv6. They are further described in section 3; these are: 1. Providing IPv6 connectivity 2. Protocol translation 3. Application-specific protocol interoperability (i.e., ALG or proxy) "Deployment models for nodes" are the ways how IP nodes might be deployed, including the different combinations of IPv4/6 capabilities and connectivity. They are further described in section 3; these are: 1. IPv4-only 2. Dual-stack with only IPv4 connectivity Savola [Expires July 2004] [Page 5] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 3. Dual-stack w/ IPv4/6 connectivity 4. Dual-stack with only IPv6 connectivity 5. IPv6-only "Deployment models for services" are the ways how IP services ("applications") could be provisioned; this may be slightly different from the node IP deployment model. They are further described in section 4; these are: 1. IPv4-only 2. Separate IPv4 and IPv6 3. Both IPv4/6 4. IPv6-only After discussing these in sections 3-5, conclusions are presented in section 6. The subsection below provides a few considerations to bear in mind when considering the details of different mechanisms or deployment models. 2.4. Transition Mechanism Deployment Considerations There are a few very important questions which must be addressed in the cases where a transition mechanism deployment is deemed necessary. For example: o if I have an existing IPv4-only service (e.g., a web site) or if I deploy IPv4-only service, whose burden is it to enable its use by all clients I wish to make it accessible to? o if I deploy IPv6-only service (e.g., a peer-to-peer application, or a special web site), whose burden is it to enable its use by all clients I wish to make it accessible to? o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6 connectivity, whose burden is it to enable them to access all the services they want? o how much easier would it be to go for dual-stack approach instead? These are complex questions. One could examine this at least from an architectural point-of-view in addition to considering where the momentum of each approach lies. That is, it would be desirable to architecturally try to ensure that everybody is responsible to achieving the greatest amount of interoperability while retaining the reasonable tradeoff of the general principles (security, simplicity, and robustness). Savola [Expires July 2004] [Page 6] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 On the other hand, one should realize the momentum of each scenario: until the IPv6 usage levels are really significant globally (for example, nearing 50%), it could be considered that that the new deployments have a primary responsibility for ensuring this interoperability. So, it is not wise to assume IPv6 will gain enough momentum in the short/medium term that you would not have to take care of being able to reach the existing IPv4 services yourself, either using IPv4 or IPv6. It is not reasonable to expect all the services to be IPv6-enabled. On the other hand, it would be perfectly fine to get someone else (e.g. a service provider providing extra IPv6 services) to do it for you. Of course, when considering an option like this, one should always be very careful not to forget comparing the situation to the cost of deploying a dual-stack solution. Typically, a dual-stack solution is much easier to cope with than the alternative, and the total cost is less. 3. Transition Mechanism Considerations Now, the considerations associated with the basic transition building blocks are discussed in more detail; these are: 1. Providing IPv6 connectivity 2. Protocol translation 3. Application-specific protocol interoperability (i.e. ALG or proxy) 3.1. Obtaining IPv6 Connectivity Obtaining IPv6 connectivity is an important step when moving from the deployed base of dual-stack nodes to the use of IPv6-enabled services. These do *not* have to happen simultaneously: indeed, it can even be counter-productive to enable IPv6 connectivity immediately (more of this below). The connectivity methods could be classified in several ways, but here is one: o native o tunneled over IPvX to a close tunnel end-point o tunneled over IPvX (over longer distances) The tunneled connectivity mechanisms could also be considered to include subcategories "configured" and "automatic". A "configured tunnel" implies that the tunnel endpoint -- especially for received Savola [Expires July 2004] [Page 7] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 packets -- is known in advance, and is somewhat trusted. An "automatic tunnel" implies a mechanism where the tunnel endpoints are not known and there is a smaller degree of trust -- if any! Otherwise, these should be self-evident. When considering the robustness and simplicity principles, the first two seem to be superior to more global connectivity mechanisms: when an underlying network topology of a tunnel includes multiple different administrative or technical entities, the probability of failures increases tremendously. Similarly, the automatic mechanisms are significantly more worrisome than configured ones, especially when applied in a domain as large as the whole Internet. As stated above, "premature" IPv6 connectivity could be knotty problem because the operating systems try IPv6 by default if no protocol has been specified explicitly. Therefore, when IPv6 connectivity is enabled (or, to a lesser degree, even IPv6 is enabled -- more of this in section 4), it becomes critical to ensure that the IPv6 connectivity is of equal qualityas IPv4 or that IPv6 is only used by specific applications, for specific purposes. That is, low-quality IPv6 connectivity could result in a visible service degradation to the user, which would delay the moment when the users feel comfortable with switching on IPv6 without too many side-effects. These issues have been discussed at length in [6BMESS]. 3.2. Protocol Translation Protocol translation is used to refer to mechanisms which perform a NAT-PT or SIIT -like automatic translation of all the packets, regardless of content, or (typically) application compatibility. These may work to some level of success for limited deployment scenarios and sets of applications only, but do not seem to fulfill robustness and simplicity principles in general. A view on the problems of generic translation is presented in section 7.2. 3.3. Application Level Gateway or Proxy It is well known that a protocol translator must have an ALG with it, to deal with protocols (as simple as FTP) that contain direct dependencies on IP addresses. However, ALGs may exist in the absence of a protocol translator, and in this case they are better described as proxies. Savola [Expires July 2004] [Page 8] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 If all protocols of interest (e.g. SMTP, HTTP, SIP,...) are handled by a proxy at the boundary between IPv4 and IPv6, no IP level translation is needed. A typical disadvantage of proxies is that their use must be explicitly configured in the applications unless automated somehow. The advantage of proxies -- or in general, mechanisms which have been explicitly configured, on a service-by-service basis -- over generic protocol translators is that their interface to the existing infrastructure is well defined. If configured to act to proxy just one service, it can be assumed that the proxy is restricted to that service only, and understands the application details. That is, proxies do not break applications that e.g. pass the IP addresses in the payloads as by definition, the proxy acts as an explicit endpoint in the communication. 4. Node Deployment Model Considerations There are multiple ways how to deploy IP versions in the nodes, and how to provide the connectivity to these IP versions. These are discussed at more length here. Deployment models for IP nodes are: 1. IPv4-only 2. Dual-stack with only IPv4 connectivity 3. Dual-stack w/ IPv4/6 connectivity 4. Dual-stack with only IPv6 connectivity 5. IPv6-only 4.1. IPv4-only This is an obvious model how nodes have been deployed in the past, and will also continued, to some extent, be deployed in the future. There are obviously two cases to consider here: o IPv6 has not been implemented in the system being deployed at all, or o IPv6 has been implemented in the system (to some degree), but it is not enabled in the kernel, library functions, etc. The first is obvious: IPv6 just isn't there, so nothing can be done about it, except maybe try to request the support to be included in the future revisions, or to pick a different kind of system. Savola [Expires July 2004] [Page 9] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 The second is a bit more subtle: either the vendor or the user has decided that enabling IPv6 (whether explicitly, or by default) does not make sense yet. This is understandable in the face of issues which may result from doing that [ONBYDEF]. It is expected that when sufficient experience has been gained from enabling IPv6 by default, it will become more commonplace. However, even deploying IPv4-only nodes which implement IPv6 is a step to the right direction. 4.2. Dual-stack with Only IPv4 Connectivity This is an extension of the second case above: IPv6 dual-stack has been deployed and enabled, but for some reason, there is only IPv4 connectivity. Having only IPv4 connectivity, or only very limited IPv6 connectivity, may be intentional; if there are concerns about the robustness of IPv6, some may consider it appropriate to wait prior to starting to prefer IPv6 over IPv4 by not providing global IPv6 connectivity yet, as discussed in section 3.1. Having dual-stack enabled but with only IPv4 connectivity implies that the IPv6 loopback address is automatically configured, and each interface has an IPv6 link-local address, and that all the IPv6 destinations are considered to be on-link. This is highly problematic in most cases [ONLINK], as well because the getaddrinfo AI_ADDRCONFIG flag will start returning IPv6 addresses when a link- local address has been configured [RFC3493]. There are likely many other issues like these, but these will be overcome and fixed as more experience is gained from the deployment. 4.3. Dual-stack w/ IPv4/6 Connectivity The next logical model is obviously deploying dual-stack nodes with full IPv4/6 connectivity. This is the phase which is expected to become dominant in the new deployments in the short/middle term, and continue to increase gradually for a long time as IPv4 and IPv6 co- exist in the Internet. In this phase, it is critically important that the applications have been developed properly; for example, [APPTRANS] gives some guidelines on that. In particular, they must be able to gracefully fall back when IPv6 connectivity does not work to IPv4, or vice versa (depending on which protocol is preferred). As this phase is expected to take the longest amount of time, it is imperative to ensure that the scenario does not have any flaws. Savola [Expires July 2004] [Page 10] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 4.4. Dual-stack with Only IPv6 Connectivity Another deployment model is deploying just IPv6 connectivity on dual- stack nodes. One scenario where this could be applicable in the mid-long term could be some special-purpose nodes or applications, which are known before the fact that they will only need to communicate with IPv6 nodes and applications. These are very like very few in the short/middle term, as the deployment base of IPv6 needs to be grown first. This model is obviously better than "IPv6-only" because it is still possible to go back to dual-stack, just by enabling IPv4 connectivity. Except for the very specific scenarios identified above, this scenario does not seem to be relevant in a very, very long time. 4.5. IPv6-only IPv6-only is the final deployment model. Either the IPv4 stack has been removed, or it has been disabled completely. IPv6-only deployments would imply that the nodes and applications would never want to communicate with IPv4 nodes, or would do so through a proxy or protocol translator. Because the period of dual-stack infrastructure is expected to last for a very, very long time, it does not make sense to deploy IPv6-only infrastructures until about all the relevant IPv4 services and nodes have been retired. If generic protocol translation would be needed, this would seem like a clear indication that the transition has not progressed as far as it should have been prior to switching to IPv6-only. These issues have been discussed at more length in section 7. Therefore, it is completely premature to consider IPv6-only deployments as of writing this memo. Savola [Expires July 2004] [Page 11] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 5. Service Deployment Model Considerations Similarly, there are multiple ways to deploy services. Here, we use the term "service" to describe an application deployed by the facilitator of the service (XXX: if you can think of more unambiguous term to use, please send suggestions!). These are discussed at more length here. The models are: 1. IPv4-only 2. Separate IPv4 and IPv6 3. IPv4/6 4. IPv6-only We examine services from the "server's" (or in more general, the facilitator of the service) perspective. How the support for using services is deployed is assumed to, in most cases, be decided by the node deployment model (section 4). 5.1. IPv4-only Obviously, IPv4-only services is the initial deployment model. Most current deployments are IPv4-only, but are slowly changing to also enable IPv6 services. This is the safest deployment in the sense that its problems are well known, and there is ample experience of such IPv4-only deployments. Unfortunately, doing so will not progress the IPv6 transition process, and the dual-stack, IPv4/6-connected nodes will have to reach these services over IPv4. However, the deployment of IPv4-only services is not necessarily a bad thing: one should not expect that all the services become IPv6-enabled for a very long time. It could be argued that the services will be IPv6 enabled when it makes sense for the service provider to do it. This could be due to a specific application that profits from features of IPv6, as a general dual-stack service policy, etc. 5.2. Separate IPv4 and IPv6 Here, the term "Separate IPv4 and IPv6" is used to refer to services that are not reachable the same way; for example, this could be the service on the same (or different) host being available on www.example.com and www.ipv6.example.com, a service provider providing IPv6 SMTP mail exchange (MX) service for IPv4-only sites, or the like; note that "separate" could be considered to include an application level gateway of a sort. Savola [Expires July 2004] [Page 12] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 One issue of separate IPv4 and IPv6 services is that they do not have similar "fate-sharing" properties. One service could be down while the other remains up. This is typically a negative thing, when IPv6 services are used less frequently than their IPv4 counterparts; IPv6 services could be down or not functioning properly (without timely reaction from the administrators) while IPv4 works fine. To summarize, one should be wary when deploying especially some forms of separate services; a factor here is the stage of the transition. They are often more difficult to manage and troubleshoot, and there is the problem of service getting out-of-sync. A mechanism which has been used to facilitate separate services is described briefly in Appendix A. 5.3. IPv4/6 The obvious long-term deployment model for certain services at least is IPv4/6, that is, the same application provides the support for both protocol versions. There are a number of pitfalls here relating how the applications are developed [APPTRANS], but it should be expected that one will be able to overcome and fix these issues to enable robust use of application in every case. IPv4/6 service deployment (at least for those applications which are relevant for IPv4) is the best approach in the long run. The rate and the timing of service deployment depends on many factors, e.g., the extent of IPv6 deployment in the user base, and how aggressive IPv6 deployment plan has been adopted for the service. However, it should be noted that in the early stages of the transition, this might lead to some bad effects to the users -- this places some requirements on the quality and availability of IPv6 connectivity on all or most of the users of the service, as is pointed out in section 3.1. There certainly are many issues left to be worked out; these will not be fixed unless the services will be actually used. At a critical point, the "burden" of fixing problems caused by IPv6 service deployment shifts to those who have not deployed it (properly) yet. It is important to get to that point. This point is brough closer by those who are in the "cutting edge", providing services despite potential problems, paving the way for the mainstream deployment phase. Savola [Expires July 2004] [Page 13] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 5.4. IPv6-only The last deployment model for services is IPv6-only. Obviously, it is not suited for all the services in a very, very long time. However, there are some uses for this model with some specific applications. Some applications may be able to assume that they will only be run over IPv6, for whatever reason (e.g., simplicity of not having to implement NAT workarounds). This kind of approach might make perfect sense in some specific scenarios where one can assume that the users of the service are all able to use IPv6. On the other hand, providing an IPv6-only service when all its users would not have IPv6 capabilities would not be appropriate. 6. Implications of the Transition Architecture Considerations Having described the different deployment model considerations, the implications need to be considered. Let's consider the deployment models for nodes and services, trying to optimize for the scenario where the need for the mechanisms would be minimized; that is: +---------+---------+--------+------+---------+ |Node\Srvc|IPv4-only|Separate|IPv4/6|IPv6-only| +---------+---------+--------+------+---------+ |IPv4-only| +++ | +++ | +++ | 2,3 | +---------+---------+--------+------+---------+ |DS w/IPv4| +++ | +++ | +++ | 1?,2,3 | +---------+---------+--------+------+---------+ |DS w/both| +++ | +++ | +++ | +++ | +---------+---------+--------+------+---------+ |DS w/IPv6| 1?,2,3 | +++ | +++ | +++ | +---------+---------+--------+------+---------+ |IPv6-only| 2,3 | +++ | +++ | +++ | +---------+---------+--------+------+---------+ The matrix is intuitive; all off-the-shelf working combinations are listed with "+++". In the remaining four instances, the possible transition mechanisms that could be applied are listed. So, the easiest thing to do would be to ensure that the service or deployment model matches one of these categories. However, some of these are suboptimal, as they do not progress the transition (for example, IPv4-only nodes and services). To summarize, it would be desirable if the services would not be deployed IPv4-only or IPv6-only, and the nodes dual-stack with both Savola [Expires July 2004] [Page 14] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 IPv4/6 connectivity. This is the goal we should be working toward. However, the goal can be achieved using a big step, or a set of smaller steps. As already described, these issues can also be viewed a bit more pragmatically: the deployment base of IPv4 is so huge that assuming mainstream IPv6 adoption in the short term is not necessarily feasible. Therefore, deploying dual-stack nodes but without IPv6 connectivity is still a step in the right direction, and keeping the services IPv4-only is not necessarily a huge problem. That is, for example, early adopters give experience back to the community which allows for smoother and more problem-free introduction of IPv6 to the masses later on. Advocating strongly that IPv6 should be deployed everywhere quickly might backfire and turn out to be counter-productive -- as there are likely some issues to be identified and worked out prior to the co-existence could be deemed to be a trivial exercise. 7. A View on Transition This section includes a few views on several aspects of the transition. 7.1. The Cost of Dual-stack Compared to IPv6-only An oft-cited argument against deploying dual-stack instead of IPv6-only with some generic translation and proxying is that the management of a dual-stack networks, address assignments etc. is a significant burden and should be avoided. In practice, this seems highly questionable. Naturally, the overall complexity one should compare the dual-stack architecture against is the IPv6-only architecture AND everything that's required to make it work with a mostly-IPv4 universe. For example, there is a routing protocol which allows a single Shortest Path First (SPF) calculation for both IP protocols -- the increase of management complexity seems close to negligible. Even address assignments are quite straightforward. IPv6 has to be done anyway; IPv4, if private addresses would be used, would be straightforward, but the issues relating to IPv6-only networks and protocol translation would result in about equal problems with translated-IPv4 than with private IPv4 addresses. On the other hand, if public IPv4 addresses are obtainable and desirable, the management of those is a task, although not a major one. So, it seems that the Savola [Expires July 2004] [Page 15] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 only addressing related concern seems to be being able to avoid the paperwork with Regional Internet Registries (RIRs) relating to public IPv4 addresses. The desire to go straight to IPv6-only seems to be mainly caused by a dream of fast transition to IPv6-only especially in some more evolved networks. However, this seems counter-productive. (Of course, a fast transition to a state where IPv6 applications are being extensively used and IPv6 is becoming more and more dominant is a separate subject.) There is a class of dedicated devices and applications for which IPv6-only may be warranted -- these are those that, for whatever reason, are only to be deployed in IPv6-capable networks, and only need to inter-operate with IPv6 nodes. Generic translation is not necessary, and at most some form of simple application proxying is used. When/if these emerge, they could be deployed in an IPv6-only fashion .. but still, the network would be dual-stack. It might be that this stanza could change significantly in (say) 10 years if the deployment gets off, but prior to major global deployment happens (e.g., causing over 3/4 of services be available over IPv6), any action toward generic IPv6-only networks, as a generic replacement to IPv4 networks, seems premature. 7.2. Generic Protocol Translation in IPv6 One argument for generic protocol translation (referring to translation done not just on a specific set of applications) in IPv6-only networks (see above) is that protocol translation is not that much different from NAT and the users would, in many cases, be plagued by that too. This is pretty close to the mark, for better and _worse_. In particular, generic protocol translation eliminates the ideal that applications are not munged by NATs in IPv6. A reason to deploy an IPv6 application could be to be able to get rid of the problems of NATs in the first place. Thus, not polluting IPv6 with protocol translation seems to be desirable goal on its own. In this light, it is more desirable to just continue using IPv4 when needed, and keeping IPv6 as "high quality". That is, an IPv6 application could end up used to connect to IPv4 peers though a translator, when the "promise of IPv6" (which may have been included in the design of the application) was that no Savola [Expires July 2004] [Page 16] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 translation would be performed with IPv6. This could be summarized so that we (the IPv6 deployers) cannot change what IPv4 is: the applications and users already have certain expectations of it and they deal (or don't) with them. However, we can still ensure that IPv6 will not be riddled with IPv4's problems, whether in the coexistence with IPv4 (important) or in the communication between IPv6 nodes themselves (critical). Encouraging generic protocol translation only seems to support the wrong kind of IPv6 deployment (see above), and carrying the problems of IPv4 NAT to IPv6. This seems counter-productive. 7.3. Providing IPv6-enabled Services -- How? Providing IPv6-enabled services is an extremely tricky business which has a number of caveats which should be taken into serious consideration. First, we'll assume that in the first phase, it is crucial to improve the number of dual-stack (even without IPv6 connectivity) nodes. This seems a reasonably safe assumption. Now, a potential problem appears when someone wishes to provide also IPv6-enabled service alongside with their IPv4 service: the first priority, for all parties -- the service provider, the vendor of the dual-stack nodes and the users -- is that enabling IPv6 will not degrade the perceived performance of existing applications. Otherwise, only few would be willing to deploy dual-stack nodes (or connectivity), or enable IPv6 on their services. This also seems to be a reasonable assumption on the goal to be work toward. A temporary workaround would be to deploy the IPv6 services under different service identifiers, like www.ipv6.example.com rather than www.example.com. In general, this is a relatively safe mechanism, but only carries so far: the potential IPv6 users will still use www.example.com because they are not aware of the sub-domain. A fix for this would be changing the default address ordering to prefer A DNS records over AAAA records: then, IPv6 addresses could be added for standard names without worries, and the nodes themselves -- not the one implementing service -- would be capable of making a decision when to switch the toggle the other way around. The change in the default ordering should already be doable with a custom Default Address Selection rule [ADDRSEL], but unless the existence or deployment of such a rule would be commonplace, this methodology would not work. So, it may be that the "deployment Savola [Expires July 2004] [Page 17] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 window" for this approach has already passed. The requirement for this problem to go away is globally stable and robust IPv6 connectivity. It seems to take long until that is achieved [6BMESS]; this was also briefly discussed ini section 3.1. for some IPv4-enabled services to the IPv6 users. 8. Acknowledgements Discussions with Brian Carpenter gave a push to writing this memo. Discussions with Rob Austein, Suresh Satapati, and Juha Wiljakka inspired into revising the memo. Suresh Satapati, Jim Bound, and Michael Mackay provided feedback, helping in improving the document. Keith Moore's "dubious premises" email helped a lot to spell out which kind of fundamental differences of assumptions people have about IPv6. 9. Security Considerations Transition architecture discussion has no special security considerations as such; however, one must be very careful not to introduce an new security considerations when specifying and deploying the transition architecture. In the quick analysis above, mainly only the robustness and simplicity principles were considered, leaving security to follow from these. A more careful security review will be needed in the future. 10. References 10.1. Normative [ARCH] Bush, R., Meyer, D., "Some Internet Architectural Guidelines and Philosophy", RFC3439, December 2002. [PREMISES] Moore, K., "dubious premises: batch reply to "IPv6 adoption behaviour"", a message on ipv6@ietf.org list on 21 Oct 2003, http://www1.ietf.org/mail-archive/ working-groups/ipv6/current/msg00398.html or http://www.cs.utk.edu/~moore/opinions/ipv6/ dubious-assumptions.html Savola [Expires July 2004] [Page 18] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 10.2. Informative [6BMESS] Savola, P., "Moving from 6bone to IPv6 Internet", draft-savola-v6ops-6bone-mess-01.txt, work-in-progress, November 2002. [ADDRSEL] Draves, R., "Default Address Selection for IPv6", RFC 3484, February 2003. [APPTRANS] Shin, M., "Application Aspects of IPv6 Transition", draft-ietf-v6ops-application-transition-00.txt, work-in-progress, December 2003. [ONBYDEF] Roy, S., et al., "Dual Stack IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-00.txt, work-in-progress, October 2003. [ONLINK] Roy, S., et al., "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", draft-ietf-v6ops- onlinkassumption-00.txt, work-in-progress, October 2003. [RFC3493] Gilligan, R., et al., "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RELAY] Hagino, J., Yamamoto, K., "An IPv6-to-IPv4 Transport Relay Translator", RFC3142, June 2001. Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi A. Example Mechanism: TCP/UDP Relay This appendix describes the use of one mechanism for controlled help in IPv6 adoption, using the "separate IPv4 and IPv6" service model. [RELAY] provides a mechanism to perform protocol interoperability on a service-by-service basis which has decoupled interactions with DNS from the service management. TCP/UDP relay can be deployed at two different locations: on the client side or the server side. On the client side, the usability appears to be a bit questionable, bringing up many issues regarding the interaction between the DNS and service proxying. However, on the server side, it is much simpler. Savola [Expires July 2004] [Page 19] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 That is, for example, a gateway between IPv4-only NNTP service and a dual-stack relay at the NNTP service providers' network can be easily and relatively reliably built with a TCP relay. This includes publishing the address of the TCP relay pointing toward the NNTP server in the DNS, configuring sufficient access-lists so that only the NNTP service is reachable, and configuring access-lists that only valid users have the access to use the relay service. The latter is necessary because the IPv4-only service sees the connections originating from the relay (and the real IPv6 source is lost); this is unfortunate, but unavoidable. Of course, in most cases, deploying IPv6-enabled services from the start is the best, and simplest choice. However, the TCP/UDP relay seems to be sufficiently simple and robust mechanism when used for providing a gateway Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this Savola [Expires July 2004] [Page 20] Internet Draft draft-savola-v6ops-transarch-03.txt January 2004 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Savola [Expires July 2004] [Page 21]